konakona.moe

Setting up slskd (a Headless Client for Soulseek)

I finally found a headless soulseek client and I can now perma-share from my NAS, with a client that runs on the server and that has an WebUI just like qBittorrent, today we are going to set up slskd the only client to my knowledge that works on the server.

You will have to have an user that will own the files that you download! The user that owns my file shares is the share user, it has permission to modify the files on my smb share and raid. Remember to replace it when you are following this guide! It works exactly like my qBittorrent guide, alternatively you could just run slskd with the root user if you are retarded.

Downloading slskd

slskd is a new project it seems, and they don’t have a Debian package, so we will have to download it directly from GitHub. https://github.com/slskd/slskd/releases.

Now copy the release for your platform and then change directory into /opt. Change the commands below if you have a new version!

1cd /opt
2wget https://github.com/slskd/slskd/releases/download/0.19.5/slskd-0.19.5-linux-x64.zip
3mkdir slskd
4mv slskd-0.19.5-linux-x64.zip slskd
5cd slskd
6unzip slskd-0.19.5-linux-x64.zip
7rm slskd-0.19.5-linux-x64.zip

systemd service

You will need to create a systemd service file for slskd. Create the file [email protected] at /usr/lib/systemd/system/.

 1[Unit]
 2Description=slskd service for user %I
 3Wants=network-online.target
 4After=local-fs.target network-online.target nss-lookup.target
 5
 6[Service]
 7User=%i
 8UMask=007 # This will set the permissions for the files to 770 (rwxrwx---)
 9WorkingDirectory=/opt/slskd
10ExecStart=/opt/slskd/slskd
11Restart=always
12
13[Install]
14WantedBy=multi-user.target

Now reload daemon to avoid systemd yelling at you: systemctl daemon-reload.

Starting the service and editing the config

Remember that share here is meant to be replaced with your <user that owns the files> as I talked about in the beginning!

Now start the service with systemctl start slskd@share in my case this user is share is I talked about in the beginning. Then verify the service with systemctl status slskd@share and then stop it (because we have to edit some configs that it generates on the directory of the share).

Now that the config file has been generated, edit it at ~share/.local/share/slskd/slskd.yml. There are only a couple of parameters we need to edit, here are some of the things I modified:

 1remote_configuration: true # Activate this so you can edit this from the WebUI
 2directories:
 3  incomplete: /home/share/.local/share/slskd/incomplete
 4  downloads: /mnt/raid/Media/Music/.soulseek
 5shares:
 6   directories:
 7     - /mnt/raid/Media/Music
 8web:
 9   port: 5030 # This is the port of the WebUI
10   https:
11     disabled: true # Nobody fucking cares about this its in your LAN
12   authentication:
13     disabled: true # I will talk about this later on the guide
14     username:      # But you can enable if for now if you won't expose
15     password:      # slskd to the internet.
16soulseek:
17   address: vps.slsknet.org
18   port: 2271 # do not change this
19   username: 
20   password: 
21   description: |
22     A slskd user. https://github.com/slskd/slskd     
23   listen_ip_address: 0.0.0.0
24   listen_port: 2235 # you can change this and you'll have to forward it on your router

Now (re)start slskd again with systemctl (re)start slskd@share and login into the WebUI with the IP of your NAS (ex: 192.168.1.5:5030), you should be able to change the config file by going into System > Options, the WebUI should be pretty intuitive.

Now you can enable the service: systemctl enable slskd@share.

Exposing slskd to the internet

I use Caddy as my web server because it just works for small applications like this, however there seems to be some kind of fuckery going on with Caddy, when I used the reverse_proxy directive, everything worked, but when I tried to login to the WebUI with the HTML form it wouldn’t let me in! There’s an open GitHub issue talking about this here: https://github.com/slskd/slskd/issues/939.

However I found an easy solution for this, by simply disabling the HTML form authentication, it just works! Because the problem is related to authentication, probably. Now you probably think that I went insane, exposing this to the internet but remember, HTTP Basic Auth exists!

~share/.local/share/slskd/slskd.yml

1web:
2   authentication:
3     disabled: true

/etc/caddy/Caddyfile

1yourdomain.tld {
2    basicauth * {
3        diowo <password hash> # `<password hash>` can be generated with `caddy hash-password`.
4    }
5    reverse_proxy localhost:5030
6    encode gzip
7}

Now restart caddy with systemctl restart caddy

Thanks for reading my guide, if you have any questions feel free to e-mail me, and I’ll try to help you.

Back to... Posts | Section

Created on: Monday, 26 February 2024