Deluge Headless - Auth File Insight

[willdab]

Hi there, I want to add a user to the auth file in /var/lib/deluge./config/deluge/auth. However when I look in this file I am struggling to find it's curent relationship, there is one entry, 'localclient:RANDOMSTRING:10'. What account is this? And how can I connect to the server with the default deluge account (which I have changed the password of now) without it being referenced in this auth file? Please elighten me.

Kind regards,
Will

[mhertz]

Localclient mechanism is for clients to be able to login automatically to server when client and server both localhost and run under same user and is authenticated with localhost.conf of client deluge profile against said auth of server deluge profile. It's little hard to explain and make sense of honestly

If wanting have client login to server automatically without being same user, then copy localclient password from auth of server and into last line of localclient entry of hostlist.conf of client(overwrite old), or alternatively start fresh with copy auth of server into client(overwrite old) and delete hostlist.conf of client and start client so new matching hostlist.conf generated(afterwards auth of client not used anymore here - could easier just have copied hostlist.conf of server directly, instead of auth, but just not there unless having ever run a client(not server) under that account - alternatively run 'sudo -u deluge deluge-console', don't login just immidiately press ctrl-c and copy newly generated hostlist.conf to client, instead of auth middlestep.)

[mhertz]

Sorry, just wanted to apologize for posting wrong info and correct myself - I posted something wrong here and a couple of other posts recently, but will just post this correction here once, I hope acceptable.

Anyway, I came to think about something, and rereading the code made me understand something which I actually used to say in older times, but recently thought wrong so stated otherwise but now find actually correct before and wrong now...

My point is that localclient mechanism while can be used from connection manager usage as well, though there uses nomal login means i.e. hostlist.conf, but localclient mechanism can bypass that and use localhost auth file to login with(get_localhost_auth() from deluge.common), from localclient line, though obviously will not work if not localhost and same config-location, meaning run under same user, as reads the auth from get_config_dir(). This sounds evident indeed, but my point is that it's on client side also and not only server(e.g. auth also needed in ~/.config/deluge, in addition to e.g. /var/lib/deluge/.config/deluge), which was my mistake i.e. that client indeed need auth file also, to get matching localclient line to server auth, to login with. Another example of this is when using deluge-console, and running 'deluge-console info' i.e. non-interactive mode, need auth file in ~/.config/deluge, to match localclient line of auth in /var/lib/deluge/.config/deluge, to autologin through said localclient mechanism and show output, and not error out as password wrong, and counterwise that you need hostlist.conf for when running 'deluge-console' so interactively, and pressing return upon first prompt showing in connection-manager, to login as localclient user, though through "regular" login means.

Sorry for confusion.

[shinger]

Hello willdab,

Maybe the explanation of mhertz is too technical. It comes down to how deluge is been build (which is kind of awesome).

• Deluged (Deluge Daemon). This is a core part and because of that it stays very light weight.

• Deluge thin client

The thin client is nothing but a front. Something that your are just be able to interact with the core. This can be a webinterface, a so called gtk client (installed on your Windows/Linux/MacOS desktop system), but it can also be a console client or even a Android/IOS App.

The localclient is the user that can ONLY be used locally on the system which deluged (deluge Daemon) is installed on (if no changes have been made to it). So to use my setup as an example. I have it installed on a SBC (SIngle Board Computer..like a Rasberry Pi..those small computers that don't use almost any electricity). The webinterface packages (deluge-web) is also installed on that SBC. So when i visit the ipadres or website (in my case), the webinterface uses this localclient to connect to deluge daemon.

If you do a cat hostlist.conf (on the system where deluge daemon is installed on) you will see something like this.)

Code: Select all

{
    "file": 3,
    "format": 1
}{
    "hosts": [
        [
            "<ID>",
            "127.0.0.1",
            58846,
            "localclient",
            "<PASSWORD>"
        ]
    ]
}

As you can see the user is called localclient and it is connecting to it self 127.0.0.1 (localhost) on port 58846 which deluged (deluge daemon) is listening on).

Code: Select all

<user>@<SYSTEM>:~# ss -tulpn | grep 58846
tcp   LISTEN 0      50                     0.0.0.0:58846      0.0.0.0:*    users:(("deluged",pid=86902,fd=22))

If you wish to be able to connect to your deluge daemon instance (from another device), you need to create another user. This is how my auth file looks like.

Code: Select all

localclient:<PASSWORD>:10
<MY-NEW-USER>:<PASSWORD>:10

The 10 part means what kind of authorized level it has. In case of the 10, it means admin level. Here you also have the official documentation from Deluge. Very awesome piece of software . @mhertz, do correct me if i said something wrong, maybe one can use the localclient user it self, but i would discourage this behavior, but instead still make a new user.

https://dev.deluge-torrent.org/wiki/Use ... entication