cleaned this up a bit
This commit is contained in:
parent
84ec14745e
commit
4dabc01089
17 changed files with 19 additions and 75 deletions
4
content/posts/_index.md
Normal file
4
content/posts/_index.md
Normal file
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "Blog"
|
||||
---
|
||||
Here I'll be talking about a bunch of things.
|
35
content/posts/a-trip-to-the-CFR-museum.md
Normal file
35
content/posts/a-trip-to-the-CFR-museum.md
Normal file
|
@ -0,0 +1,35 @@
|
|||
+++
|
||||
title = 'A Trip to the CFR Museum'
|
||||
date = 2024-01-26T20:02:16+02:00
|
||||
draft = false
|
||||
+++
|
||||
|
||||
I've had the chance these past days to go to the CFR museum in Bucharest, Romania, where they had a beautiful train model, as well as many other things, such as a whole steam locomotive in their frontyard. I highly suggest anyone visits this museum. It may not be as big but it makes up in quality. It's next to the North Railway Station and is served by STB routes 1, 10, 82, 97, 105, 182, 282, as well as the Gara De Nord 2 (M4) Metro Station (Also Gara De Nord station. If you want to go to GDN2, you'll have to switch at Basarab).
|
||||
|
||||

|
||||
*A huge steam locomotive parked outside of the CFR museum*
|
||||
|
||||

|
||||
*A scaled down design of a cargo terminal*
|
||||
|
||||

|
||||
*Model of 060-EA-042 locomotive*
|
||||
|
||||

|
||||
*Model of LDH diesel locomotive*
|
||||
|
||||
## The model
|
||||

|
||||
*Doutchebahn locomotive hauling passenger cars*
|
||||

|
||||
*Siemens Desiro train*
|
||||

|
||||

|
||||
*Pictures of the train model*
|
||||

|
||||
*LDH in action*
|
||||

|
||||
*Depot*
|
||||
|
||||
|
||||
I hope these pictures can be of some use.
|
25
content/posts/altsom-coardia-stream.md
Normal file
25
content/posts/altsom-coardia-stream.md
Normal file
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: 'The Altsom Coardia Stream and what it means for CFR'
|
||||
date: 2023-12-20T21:29:27+02:00
|
||||
draft: false
|
||||
---
|
||||
The first Class 101 trains from Altsom have arrived recently in Romania, and I have to say I am 3 weeks late to the party. I can't explain in words how big this is. This is CFR's first aquisition of new electric trains in 20 years. Below is a picture with the most common electric locomotives in Romania, the class 4x ones.
|
||||

|
||||
*A class 40 train of CFR Calatori at Bacau. Picture courtesy of Calin Strimbu.*
|
||||
|
||||
|
||||
These look like they belong in a scrap yard, don't they? A few years ago my parents were shocked at how old the locomotives were and they say that "they looked like they were 100 years old" and I don't blame them. We even have nearly 80 year old locomotives still in service. I'm not joking. Class 77 trains were produced from 1935 to 1942 and they still USE THEM, though it's for short routes.
|
||||

|
||||
*A class 77 train of CFR Calatori at Calimanesti station. Picture courtesy of Stefan Puscasu.*
|
||||
|
||||
|
||||
And here are the second newest trains of CFR calatori. Siemens Desiro, AKA Class 96
|
||||

|
||||
*A graffitied class 96 train of CFR Calatori at Bucuresti Nord. Picture courtesy of Stefan Puscasu.*
|
||||
|
||||
|
||||
And here we have the new Altsom trains.
|
||||

|
||||
*A brand new Altsom Coardia Stream train with a bit of snow. Picture courtesy of Observatorul Prahova*
|
||||
|
||||
Ever since the 2000s, CFR has started gaining the reputation of being **extremely** unreliable, with CFR having delays of **4 million minutes** ([source](https://www.digi24.ro/stiri/actualitate/calatorii-in-timp-la-cfr-trenurile-din-romania-au-intarziat-anul-trecut-cumulat-mai-bine-de-8-ani-2560019)) in 2022. Yikes. I don't know if the reason for these delays are rolling-stock related, but I have to say, I hope that's the case. I also don't even want to touch on the bathrooms of the passenger cars. Thank God I never had to take a number two in one of these, cause otherwise, I would've gotten all of the possible and impossible STDs. I won't show pictures, it's gross as hell, but if you are interested, google "veceu cfr". I am also interested in seeing if it will take less time to get there, as these trains can reach 200km/h, but we have horrible infrastructure. I hope the lines get modernized faster, so I can finally go to the beach in a decent timeframe.
|
70
content/posts/how-not-to-use-cloudflare.md
Normal file
70
content/posts/how-not-to-use-cloudflare.md
Normal file
|
@ -0,0 +1,70 @@
|
|||
+++
|
||||
title = 'How Not to Use Cloudflare'
|
||||
date = 2024-04-02T18:20:15+03:00
|
||||
draft = false
|
||||
+++
|
||||
Cloudflare is a DDoS mitigation platform which offers free proxying of your origin server. Unfortunately, this proxying is not well-used by some people, such as the person who inspired me to make this blog post. He has since fixed it. On Sunday, me and a friend of mine have exposed a vulnerability to one of our other friends, which we will be referring for privacy reasons as X. X has agreed to the "hacking" of his website.
|
||||
|
||||
## What is Cloudflare proxying?
|
||||
In order to mitigate DDoS attacks, Cloudflare must proxy your website throught one of their many proxy servers. This means, Cloudflare accesses your website instead of your user. While this may be a privacy concern, we will not adress it as it is not the point of this document, instead, I direct you to https://0xacab.org/dCF/deCloudflare/-/blob/master/README.md.
|
||||
|
||||
## The issue
|
||||
The person configured his webserver incorectly, and instead of denying all of the requests from IPs that are not of Cloudflare (see https://cloudflare.com/ips/), it allows any traffic on port 80. Port 80 is the default web port for unencrypted traffic. The individual did not have an SSL certificate, instead relying on one provided by Cloudflare. This is not reccomended and was used as part of the attack vector.
|
||||
|
||||
Due to the fact that they allow all IPs to request port 80, if we have his origin IP, which was easily found via https://search.censys.io/, we could send a direct request to the server. Below is showing a direct request to my server, if we access it from the direct IP, without any host headers.
|
||||
|
||||
```
|
||||
> curl http://107.189.28.28
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Welcome to nginx!</title>
|
||||
<style>
|
||||
body {
|
||||
width: 35em;
|
||||
margin: 0 auto;
|
||||
font-family: Tahoma, Verdana, Arial, sans-serif;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Welcome to nginx!</h1>
|
||||
<p>If you see this page, the nginx web server is successfully installed and
|
||||
working. Further configuration is required.</p>
|
||||
|
||||
<p>For online documentation and support please refer to
|
||||
<a href="http://nginx.org/">nginx.org</a>.<br/>
|
||||
Commercial support is available at
|
||||
<a href="http://nginx.com/">nginx.com</a>.</p>
|
||||
|
||||
<p><em>Thank you for using nginx.</em></p>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
This is the result of sending the same request but with the host header set to fzorb.xyz:
|
||||
|
||||
```
|
||||
>curl 107.189.28.28 --header "Host: fzorb.xyz"
|
||||
<html>
|
||||
<head><title>301 Moved Permanently</title></head>
|
||||
<body>
|
||||
<center><h1>301 Moved Permanently</h1></center>
|
||||
<hr><center>nginx/1.18.0</center>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
This is the response you get if you try going to http://fzorb.xyz/. It redirects you to the secure version, https://fzorb.xyz/.
|
||||
|
||||
## But why would you want to bypass the origin?
|
||||
We had more "humble" motive. The website in question checked your IP address before accessing the website so it wouldn't be from a certain country to join a Discord guild in order to prevent someone from joining. I found this absurd so I came up with the attack vector, and my friend did the actual exploiting of this vulnerability. This was used to prevent geoblocking. But this could also be used in worse ways, such as impersonating admins on a forum for example. In fact, Stack Overflow in its early days determined admins by their IP address, which in this case was 127.0.0.1. This is not secure at all.
|
||||
|
||||
## So how does this work?
|
||||
The webserver knows your IP address via a header called X-Forwarded-For. Cloudflare doesn't use that header, instead using CF-Connecting-IP. In the absence of Cloudflare, you can set CF-Connecting-IP to any value you want and the Webserver will think it is valid. You could set your ip to values like `1.1.1.1`, `1.3.3.7`, `69.69.69.69`, or even `420.420.420.420`, and the webserver can't know any better.
|
||||
|
||||
## How do I mitigate it?
|
||||
You can mitigate it via numerous ways. Here are the 2 ways you can do that:
|
||||
* Disable Cloudflare proxying: this is the option X chose. This may not be an option for you though if you are subject to frequent (D)DOS attacks.
|
||||
* Deny access of all Cloudflare IPs: there is a handy script on Github made by user Icseon, which uses iptables to deny all non-Cloudflare traffic on port 80 and 443. https://github.com/icseon/cf-iptables
|
||||
|
||||
I hope this blog post has been useful. While I do not use Cloudflare myself, I know many people that do.
|
31
content/posts/my-servers-2023.md
Normal file
31
content/posts/my-servers-2023.md
Normal file
|
@ -0,0 +1,31 @@
|
|||
+++
|
||||
title = 'My Servers (2023 edition)'
|
||||
date = 2023-12-20T20:11:58+02:00
|
||||
draft = false
|
||||
+++
|
||||
|
||||
Over the past 5 years, I have inherited my father's philosophy of self-hosting. It all started with my brand-new Raspberry Pi 4. I wanted to create a Minecraft Server for me and my friends to play on. Unfortunately, due to my lack of skill, I have had to offload the responsibility onto my father's server (which was really weak! an intel celeron j1800 was barely cutting it for versions newer than 1.12.2!). Eventually, during quarantine, my father had moved his entire suite of servers (mainly SBCs) to the j1800 and it was beginning to get quite horrible. We were lucky to even get 18 TPS when more than 2 people were on.
|
||||
|
||||
Eventually, I've decided that the j1800 wasn't good enough anymore, so I've decided to get an old laptop motherboard with an Intel Core 2 Duo. Due to me barely knowing shit, I was quite frankly hooking that poor laptop motherboard to a monitor and starting the Minecraft server in a new window, which wasn't and still isn't a good thing, as it required me to be at home, it wasn't an issue for spring 2020 though.. After 3 months of doing it this crappy way, my father spent an afternoon teaching me how to enable the sshd daemon and figuring out how to make the Minecraft server autostart. Eventually he convinced me to just use Docker, and I have to say, I **really** enjoyed it, so much so that until recently I **only** (with a few exceptions like nginx) used docker.
|
||||
|
||||
Nowadays, the only component that remained the same through all of these 3 years worth of administration was Docker. I have learnt a lot just during this year alone and my system adminsitration knowledge doubled compared to last year. The motive for this blog post is to reflect on my progress this year and what I have learnt.
|
||||
|
||||
# The components
|
||||
My suite of servers is comprised of the following few lads:
|
||||
* **Frantech/BuyVM** VPS:
|
||||
I use this as a VPN in order for me to be able to expose my services to the internet without needing to port forward on my home IP address.
|
||||
* **HP t620 Thin Client**
|
||||
This is the brains of the whole operation and I find it hilarious how last year I thought I'd be using a more beefy server, but this lad, which cost me 5 dollars by the way, went above and beyond for me. I strongly reccomend the HP t620 for hosting basic websites, fediverse instances and Minecraft servers (though you should use purpur or you will experience a lot of lag!).
|
||||
* **Raspberry Pi 4**
|
||||
I still use this guy for stuff that **must** only be accessed on my home network. Stuff like Bitwarden, althrough I also run a Jellyfin server meant for public use, by my friends of course.
|
||||
* **Wyse 3040**
|
||||
This lad is a new addition to my homelab. I run an experimental Terraria server on it.
|
||||
|
||||
# The stack
|
||||
For all critical services, I prefer to run them on bare metal, as to not depend on one too many daemons. As I was saying earlier in this blog post, I still use Docker after 3 years of non-stop use. Recently however, I have dabbled into some Proxmox shenanigans and for a while I was reconsidering my faith... until I saw how badly virtual machines performed on the t620. Arguably it isn't really a wise choice to run Proxmox on it and I've ultimately decided that I was better off with just Docker.
|
||||
|
||||
# My regrets
|
||||
I should have gotten more ram and I should've not had to rely on Wireless internet, which is a node which can fail within my setup. I should've used ethernet. Unfortunately, I cannot convince my father to help me extend an ethernet cable to my room.
|
||||
|
||||
# Conclusion
|
||||
I strongly enocourage self-hosting everything you can, as it helps fight decentralization and you can often times find it better to use free and open source alternatives to things such as ~~Google Reader~~ (I forgot that shut down), Google Calendar or Gmail.
|
112
content/posts/nitter.md
Normal file
112
content/posts/nitter.md
Normal file
|
@ -0,0 +1,112 @@
|
|||
+++
|
||||
title = 'Nitter in 2024'
|
||||
date = 2024-09-05T10:34:46+03:00
|
||||
draft = false
|
||||
+++
|
||||
Earlier this year, [Nitter has ceased development](https://github.com/zedeus/nitter/issues/1155#issuecomment-1913361757), due to the removal of guest accounts, but, you can still self host an alternative Twitter frontend, and we'll do it with something some love and some hate, Docker!
|
||||
|
||||
We will be using [Privacydevel's Nitter fork](https://github.com/PrivacyDevel/nitter) for this.
|
||||
|
||||
### Prerequisites:
|
||||
* A Linux server with Docker and Docker-compose installed
|
||||
* A few twitter accounts
|
||||
* A machine with a residential IP (for logging into your twitter alts, nothing else. You can use a smartphone for this)
|
||||
|
||||
### Step 1. Getting accounts
|
||||
For this you will need a residential IP, as the login script won't work otherwise. You can simply run it on your computer or on your phone using something like Termux.
|
||||
|
||||
After you get a bunch of alts, it is time to get their oauth tokens.
|
||||
```bash
|
||||
curl https://raw.githubusercontent.com/PrivacyDevel/nitter/master/twitter_oauth.sh -o twitter_oauth.sh
|
||||
vim twitter_oauth.sh
|
||||
```
|
||||
**twitter_oauth.sh**
|
||||
```sh
|
||||
...
|
||||
5 | username="yourUsernameHere"
|
||||
6 | password="yourPasswordHere"
|
||||
...
|
||||
```
|
||||
```sh
|
||||
bash twitter_oauth.sh
|
||||
```
|
||||
You'll end up with something similar in your terminal:
|
||||
```json
|
||||
{"oauth_token":"SECRET", "oauth_token_secret":"SECRET"}
|
||||
```
|
||||
Save it for later.
|
||||
|
||||
### Setting up Nitter
|
||||
```bash
|
||||
# Clone the instance. We will be using /srv/nitter
|
||||
$ git clone https://github.com/PrivacyDevel/nitter.git /srv/nitter
|
||||
# Now we have to edit the guest_accounts.json file
|
||||
$ vim guest_accounts.json
|
||||
```
|
||||
**guest_accounts.json**
|
||||
```json
|
||||
[{"oauth_token":"SECRET", "oauth_token_secret":"SECRET"}]
|
||||
```
|
||||
```bash
|
||||
# We'll also have to edit the docker-compose.yml file to pass the guest_accounts.json to the container.
|
||||
$ vim docker-compose.yml
|
||||
```
|
||||
```yaml
|
||||
version: "3"
|
||||
|
||||
services:
|
||||
|
||||
nitter:
|
||||
image: ghcr.io/privacydevel/nitter:master
|
||||
container_name: nitter
|
||||
ports:
|
||||
- "8080:8080" # Replace with "8080:8080" if you don't use a reverse proxy.
|
||||
volumes:
|
||||
- ./nitter.conf:/src/nitter.conf:Z,ro
|
||||
- ./guest_accounts.json:/src/guest_accounts.json:Z,ro
|
||||
depends_on:
|
||||
- nitter-redis
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test: wget -nv --tries=1 --spider http://127.0.0.1:8080/Jack/status/20 || exit 1
|
||||
interval: 30s
|
||||
timeout: 5s
|
||||
retries: 2
|
||||
user: "998:998"
|
||||
read_only: true
|
||||
security_opt:
|
||||
- no-new-privileges:true
|
||||
cap_drop:
|
||||
- ALL
|
||||
|
||||
nitter-redis:
|
||||
image: redis:6-alpine
|
||||
container_name: nitter-redis
|
||||
command: redis-server --save 60 1 --loglevel warning
|
||||
volumes:
|
||||
- nitter-redis:/data
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test: redis-cli ping
|
||||
interval: 30s
|
||||
timeout: 5s
|
||||
retries: 2
|
||||
user: "999:1000"
|
||||
read_only: true
|
||||
security_opt:
|
||||
- no-new-privileges:true
|
||||
cap_drop:
|
||||
- ALL
|
||||
|
||||
volumes:
|
||||
nitter-redis:
|
||||
|
||||
```
|
||||
```bash
|
||||
$ vim nitter.conf # Now you can edit the nitter.conf file. I won't be going into it as it is fairly straightforward.
|
||||
$ docker-compose up -d
|
||||
```
|
||||
|
||||
And voila! Now if you go to your server's IP on port 8080, you will be greeted by Nitter. Isn't that awesome?
|
||||
|
||||
Thanks to [Phin](https://filehaus.su) for helping me set it up.
|
59
content/posts/running-a-fediverse-server.md
Normal file
59
content/posts/running-a-fediverse-server.md
Normal file
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
title: "Running a fediverse server (for (nearly) free!)"
|
||||
date: 2023-07-09T09:30:00+03:00
|
||||
draft: false
|
||||
toc: true
|
||||
images:
|
||||
tags:
|
||||
- fediverse
|
||||
---
|
||||
|
||||
Running a fediverse server is now easier than ever, you can run it on hardware as low spec as a Raspberry Pi. With the recent twitter drama, it is extremely lucrative to create a fediverse account now. While you may find it easier to create an account on a more well-estabilished server, it isn't exactly the best idea. Why? Well, if you're going to make an account on a [well estabilished instance](https://joinmastodon.org/servers), you're subject to their moderation policies, and, you can get banned for some nonsensical reasons. By hosting a server, you're practically becoming censorship-resistant.
|
||||
|
||||
## Prerequisites
|
||||
* A domain name: I'd reccomend Cloudflare Domains or Porkbun.
|
||||
* A VPS: It's easy to get an Oracle Cloud Free Tier VPS.
|
||||
* Some linux experience
|
||||
|
||||
## Basic setup
|
||||
You will want to add your domain to Cloudflare, this isn't required, but it is reccomended as you may encounter bad actors trying to attack your instance. If you use Cloudflare Domains, this was already done for you.
|
||||
After you've added your domain to Cloudflare you must go to your ingress rules (instance page > vcn > subnet > security list) and add the following rules:
|
||||
```sh
|
||||
0.0.0.0/0 All Protocols All traffic for all ports
|
||||
```
|
||||
You may think that it is insecure, but we will be adding a firewall on our server now. We'll be using ufw since it is the easiest to set up for newbies.
|
||||
```sh
|
||||
sudo apt-get install ufw
|
||||
ufw allow 22
|
||||
ufw allow 80
|
||||
ufw allow 443
|
||||
```
|
||||
|
||||
## Picking your poison
|
||||
Oh well, this might be easy for some or hard for some, so I will cover each option.
|
||||
* **Mastodon**: Mastodon is the most widely-used server software on the fediverse (we're still suffering from Eugen's decisions from 7 years ago), however, it isn't the greatest. Why?
|
||||
* **Uses a lot of resources:** Mastodon is fat, which may turn you away if you want to run more than just a simple Mastodon instance on your server. Here is a comparison between Mastodon and Pleroma:
|
||||

|
||||
* **Less costumizable:** At most you can just edit the stylesheet with the default FE and add a banner. Pleroma-FE beats the fuck out of Mastodon when it comes to costumization. You can even replace Pleroma-FE with another frontend, such as soapbox.
|
||||
|
||||
If you still wish to use Mastodon, the documentation covers everything better than I could. https://docs.joinmastodon.org/admin/prerequisites/
|
||||
* **Pleroma**: Pleroma is a more sensible option if you wish to have something more light-weight. There are 3 versions:
|
||||
* **Vanilla**: The base version of Pleroma, active development has ceased unfortunately and the only updates you'll get are security fixes. (https://docs-develop.pleroma.social/backend/)
|
||||
* **Akkoma**: A fork of Pleroma that allows users to be more expressive than on Pleroma. (https://docs.akkoma.dev/)
|
||||
* **Rebased**: An improved version of Pleroma. (https://soapbox.pub/install/)
|
||||
|
||||
|
||||
All of them are trivially easy to setup and have one thing in common, the way that they are ran:
|
||||
* **From source:** you're compiling the source code every time you run the software. This opens up the posibilities of editing the source code on your server, which you may find useful in some cases. Though, depending on your server's specifications, it may take a while to run it.
|
||||
* **OTP**: OTP is the closest you can get to a binary release. It isn't compiled every time your run it, so startup times will be faster. Though, there are some limitations, most notably that you can't edit the source code
|
||||
|
||||
* **Misskey:** Misskey is by far the most feature-rich server we've covered, like Pleroma, it has many versions:
|
||||
* **Vanilla**: The base version of Misskey, without any forks. https://misskey-hub.net/en/
|
||||
* **Foundkey** Maintained by the same people who maintain Akkoma https://akkoma.dev/FoundKeyGang/FoundKey
|
||||
* **Firefish** A more advanced version of Misskey which implements the Mastodon API https://joinfirefish.org
|
||||
|
||||
|
||||
I'd personally use Firefish as it seems more estabilished than FoundKey at this point in time. I'd reccomend any Misskey version for beginners, as it is easier to run and setup than Pleroma or Mastodon.
|
||||
|
||||
## Conclusion
|
||||
Making a fediverse server is simple, but the hard part is maintaining it.
|
66
content/posts/running-a-music-server.md
Normal file
66
content/posts/running-a-music-server.md
Normal file
|
@ -0,0 +1,66 @@
|
|||
+++
|
||||
title = 'Running a Music Server (with Docker)'
|
||||
date = 2024-08-21T07:14:38+03:00
|
||||
draft = false
|
||||
+++
|
||||
|
||||
If you have a huge physical music collection or a desire to not pay for your music, running a Music server is a great way to organize your collection. This guide will be covering configuring [Navidrome](https://www.navidrome.org/) and [slskd](https://github.com/slskd/slskd/).
|
||||
|
||||
This tutorial will be assuming you're running your music server in the `/srv/music` directory, but it should be trivially easy for you to change where it is. We'll also be assuming you have `docker` and `docker-compose` installed.
|
||||
```bash
|
||||
# This tutorial assumes you're root
|
||||
# Firstly, we should create the /srv/music directory
|
||||
mkdir /srv/music
|
||||
cd /srv/music
|
||||
# Now we should create the compose.yml file
|
||||
nano compose.yml
|
||||
```
|
||||
**compose.yml**
|
||||
```yaml
|
||||
services:
|
||||
navidrome:
|
||||
image: deluan/navidrome:latest
|
||||
user: 1000:1000
|
||||
ports:
|
||||
- "4533:4533"
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
ND_SCANSCHEDULE: 1h
|
||||
ND_LOGLEVEL: info
|
||||
ND_SESSIONTIMEOUT: 24h
|
||||
ND_BASEURL: ""
|
||||
volumes:
|
||||
- "./navidrome:/data"
|
||||
- "./soulseek/downloads:/music" # you can change this to something else if you aren't using soulseek.
|
||||
# the slskd container is entirely optional if you do not want to engage in piracy.
|
||||
slskd:
|
||||
image: slskd/slskd
|
||||
container_name: slskd
|
||||
ports:
|
||||
- "5030:5030"
|
||||
- "5031:5031"
|
||||
- "50300:50300"
|
||||
environment:
|
||||
- SLSKD_REMOTE_CONFIGURATION=true
|
||||
volumes:
|
||||
- ./soulseek:/app
|
||||
restart: always
|
||||
```
|
||||
```bash
|
||||
# Now we should run the stack to generate config files
|
||||
docker-compose up -d
|
||||
# Wait around 20-30 seconds until shutting down the containers
|
||||
docker-compose down
|
||||
# Now we'll edit the slskd config
|
||||
nano ./soulseek/slskd.yml
|
||||
```
|
||||
If you're running this locally, i.e. you won't expose this to the internet, I suggest enabling `web.authentication.disabled`. Otherwise, setup an username and a password. Don't use common usernames. Also, you must create a soulseek account and add it to your slskd config (`soulseek.username` & `soulseek.password`)
|
||||
```bash
|
||||
# Now you can run your stack
|
||||
docker-compose up -d
|
||||
```
|
||||
Now, you must configure an administrator Navidrome account. Browse to `https://[your server ip]:4533/` and make your administrator account. Now you can add your music to whatever folder you configured, or `/srv/soulseek/downloads`. For soulseek, you'll have to browse to `https://[your server ip]:5030/` and login.
|
||||
|
||||
From here, you can go bananas.
|
||||
|
||||
Thanks for reading this quick tutorial.
|
Loading…
Add table
Add a link
Reference in a new issue