Can't connect to daemon service - username/auth file location issue

[netpro]

Hey all, been a Windows guy all my life, hope this doesn't deterr you guys from helping me out here.

Background info (scroll down for the issue at hand):
A couple of years ago I ran a Ubuntu virtual machine to play around with it but since I had no 'real' use for it and my regular windows desktop covered all my needs I eventually dropped the whole thing.
I have an old Athlon XP with 512 mB of RAM doing light seedbox work running Win7 and back then I already considered running a linux distro on it but since it's integrated to a windows network digging into the whole samba configuration didn't seem to be worth the hassle.
Recently however, we upgraded our internect connection with a second WAN line so we jumped from 8 to about 40 mbps. This overtaxes the 'seedbox' as it is. I am recycling a dual core with 2 gigs RAM and gigabit ethernet for the 'seedbox' and am tempted to just drop win10 and utorrent on it again but wanted to try out something with some extra performance.
So I installed Debian in its most basic form at first to run Deluge as a service and do the rest remotely. I ended up with like two dozen firefox tabs (carefully bookmarked lol) split over 3 different screens to get the hang of the command line but ended up installing lxde anyway.
Anyway, I installed deluge, deluge-console and deluge-web.
I followed the thinclient setup guide http://dev.deluge-torrent.org/wiki/UserGuide/ThinClient and the service setup guide http://dev.deluge-torrent.org/wiki/User ... ce/systemd to get the daemon running as a service.
I can http in, no problem. I downloaded a torrent and got it off the samba share just fine.
Everything is default as per the guides except for:
- 'allow_remote' value set to true
- the client having been set to connection manager
- auth file under ~/.config/deluge/auth has been edited with

Code: Select all

testuser:testA:10
deluge:deluge:10

- deluged.service Umask set to 000

To further paint the picture of my setup, I have the following system users:
- root, of course
- testuser, password testA
- deluge, with password disabled as per guide and in usergroup deluge for the daemon service


The actual issue
Now here's the thing. If I http in and use the connection manager, I have to select localhost without a username or password and the daemon is connectable. Connecting to it asks for the default password (deluge) but NO username.

Using the box's IP address fails. Either with no user-pass, with user 'deluge', pass 'deluge', user "" pass 'deluge', user 'testuser' pass 'testA'.

If I stop the service and launch the daemon from the terminal logged in as 'testuser' using the 'deluged' command, I can connect with either user-pass combo in the auth file but I can't see the torrent I downloaded under the service. This leads me to the obvious conclusion that the service runs as the system user 'deluge' with no password like it's supposed to, but for the life of me I can't figure out which auth file it reads (clearly neither the root's nor testuser's auth file).

~/.config is, as far as I understand, <currentuser home>/.config right? So it seems logical that if I launch deluged from 'testuser', the auth file will be read from /home/testuser/.config/deluge/auth
But if the service is run from user 'deluge' with home folder in '/var/lib/deluge deluge' where's the auth file? I browsed back and forth through all possible directories to the point I'm completely mired!

Of course, su deluge doesn't work since the password is disabled.

Any pointers appreciated, or do let me know if I got this all wrong.

[Tvich]

All of this mess is "solvable"
A)
Do you want to go point by point and un-mess this situation? It might take some time.
For starters, look at /var/lib/deluge/.config/deluge/auth. If you didn't yolo this too much, it should be there. Is it there?
If not, try to remember, did you type

Code: Select all

-c /some/random/dir

anywhere while configuring systemd?
Also, in the auth file, there is a line (first line actually) called localhost:blabla:10.
If deluge-web (web interface program) is running from the same user as deluged (actual program), the webui uses that line to connect to daemon without user:pass.
Also config path is ~/.config/ but actual config is in ~/config/deluge
TLDR you probably didn't enable remote true as user deluge.
try:

Code: Select all

deluge-console -c /var/lib/deluge/.config/deluge "config -s allow_remote True"

or some variation.


B)
Do you want to wipe the server, put ubuntu on it, and input a couple commands on it and call it a day?

C)
You wanna try using docker? Might be the fastest solution?

P.S.
If you fix this up correctly, you won't have to think about it until hardware fails. But i think, you already went to far with lxde.
I strongly suggest, nuke the server, install ubuntu 16.04 server, and i'l paste a couple of line here and you will paste them with putty on to the server.

[netpro]

First of all, thanks for the help Tvich.

All of this mess is "solvable"
A)
Do you want to go point by point and un-mess this situation? It might take some time.

I'm not in a particular hurry.

For starters, look at /var/lib/deluge/.config/deluge/auth. If you didn't yolo this too much, it should be there. Is it there?

First snag, no, it's not there. In /var/lib/deluge there's only the Downloads directory.

If not, try to remember, did you type

Code: Select all

-c /some/random/dir

anywhere while configuring systemd?

It's possible but I don't recall doing any -c. What does it do?

Also, in the auth file, there is a line (first line actually) called localhost:blabla:10.
If deluge-web (web interface program) is running from the same user as deluged (actual program), the webui uses that line to connect to daemon without user:pass.

Yeah, that one's there in both auth files for the root and testuser respectively. Again, no idea from where the Deluge user is reading from. Because in order to work, it has to read the file from somewhere, right?

Also config path is ~/.config/ but actual config is in ~/config/deluge
TLDR you probably didn't enable remote true as user deluge.
try:

Code: Select all

deluge-console -c /var/lib/deluge/.config/deluge "config -s allow_remote True"

or some variation.

Again, nothing other than the Downloads dir in /var/lib/deluge

B)
Do you want to wipe the server, put ubuntu on it, and input a couple commands on it and call it a day?

I used debian instead of ubunty since from what I gather, it has the smallest footprint. For what specific reason would you choose ubuntu over debian for a bare bones server? In any case, I don't mind partitioning over and installing anything else but I really want to understand what's going on.

C)
You wanna try using docker? Might be the fastest solution?

First time I hear of it. I just quickly glanced it over. How much experience do you have with it? Does it work as advertised? And what I didn't get, is this more like a "library package" that if installed, you'll never miss a dll, service or other config item again or more like a VM/sandbox that interfaces between the app and OS? Don't you incurr in a performance penalty when using it because you have the additional layer between app and OS?

Thanks again!

[netpro]

Scratch my previous post, the .config is there. Forgot to use -a with the ls command. I hate being a noob. Dang it!

Edited the auth file, all working now.

[netpro]

Actually I'd still be interested in your replies for B) and C)

Also, I just reread the guide in http://dev.deluge-torrent.org/wiki/UserGuide/ThinClient and I now realize that the answer was right in front of me the whole time:

Note: The config location is either the default location with reference to the user that deluged is running as. Alternatively if using a service it will be specified in the service config files with -c <path> option.

[Tvich]

1.
I would try to switch to Ubuntu, unless you have strong reasons for using a different distro.
Most of the software you will be using on a home server, will be tested most on ubuntu (by far).
2.
Footprint is kind off a loaded question. Unless you are running Alpine etc from ram (or running linux on hardware that costs more than your car), don't even spend a minute thinking on size, or performance.
3.

I really want to understand what's going on

That's the right approach. And more in general: googling can give you quick answers and no understanding. I had to read a book to get linux on a basic level. Might save you time in the long run?

B)
Installing gui on a server is reason enough for nuking. So if you are reinstalling, why not use Ubuntu Server 16.4?
I don't know what you will be running on it (plex, sonarr), but it will be supported on Ubuntu. Debian is also a decent choice, but PPA's for bigger projects are reason enough to use Ubuntu Server.

C)
Docker is cgroups, chroot and copy on write black magic that, surprisingly, works really well.
https://en.wikipedia.org/wiki/Operating ... ualization
I, unfortunately, have quite a lot of experience with it
It works as advertised, as long as you wrap your head around it and do things their way. 2 years ago it was a joke, but now it works.
There is no performance penalty*
*I tried some basic docker vs native host tests, while running everything from ram on 10gbe and there was no difference.
There were also some tests done on deluged in docker and no measurable difference.