Summary: | net-p2p/deluge - Add deluged/deluge-web daemon info messages to prevent confusion | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jonathan Vasquez (RETIRED) <fearedbliss> |
Component: | Current packages | Assignee: | Paolo Pedroni <paolo.pedroni> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | jstein, k_f, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=697888 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jonathan Vasquez (RETIRED)
2016-12-22 20:57:13 UTC
I also want to note that it is fine if the user runs both the deluged and deluge-web daemons only if they don't use the 'deluge-web' daemon to start another 'deluged' process. So if the user wants to have one deluged daemon that starts regardless if the deluge-web daemon starts or not, then they should add another user to their 'auth' file so that they could re-use that account when using either a remote thin-client or the web-ui in order to re-attach their session to the same underlying 'deluged' process. (In reply to Jonathan Vasquez from comment #1) > I also want to note that it is fine if the user runs both the deluged and > deluge-web daemons only if they don't use the 'deluge-web' daemon to start > another 'deluged' process. So if the user wants to have one deluged daemon > that starts regardless if the deluge-web daemon starts or not, then they > should add another user to their 'auth' file so that they could re-use that > account when using either a remote thin-client or the web-ui in order to > re-attach their session to the same underlying 'deluged' process. The 'correct' (or call it 'easier', or 'more natural') way to run the daemon and the web-ui is to start both the deluged and deluge-web services, and then connecting the web-ui to the already running daemon, pressing the "Connection Manager" button, adding (if necessary, I don't actually remember if the localhost daemon is in the list by default) the daemon running on localhost to the "Connection Manager", then selecting it and pressing "Connect". I seem to remember this being all in the FAQ on the project web page. Hey Paolo, That's pretty much what I did. The info is more or less on the FAQ but not directly. Meaning that it is pretty confusing for users because the thing is that the FAQ does mention that a 'localclient' account is created for accounts running locally, however, when it mentions on adding another user, it isn't clear on if this is or isn't needed depending on what situation. Basically the information could be expressed clearer. Atm, since I want to connect from both my desktop machine and also the server machine (The server machine is running 'deluged'), I have both 'deluged' and 'deluge-web' started, I actually made a copy of the systemd service files and modified them a bit (Adding User=%i) and throwing them in my /etc/systemd/system directory. This allows me to run the daemons as my user rather than having to create a 'deluge' user, and allows systemd to run the daemons as that user. Also it protects me from any changes that happen during deluge updates. Anyways, I also had to add a second user account that I want to use for both my desktop machine (remote connection) and even if I want to use the web-ui, I have to use the second user account. I can't use the 'localclient' account that automatically gets created on the server machine. So it seems that the localclient account is only if you want to connect on the server machine only if the server web-ui created the daemon. I can't start up the 'deluged' service, and use the localclient to attach to it. You can test this as well by starting deluged, and noticing that if you have two entries in your connection manager: 1. localclient - 127.0.0.1:58846 2. <second user name> - LAN IP:58846 you will notice that the second one will be online (because the LAN IP is where the deluged daemon is running) and the first one will be disconnected and requires you to "Start Daemon" before it becomes online. Starting a daemon at this point will start up a second 'deluged' process, which isn't good. Especially since your core.conf file seems to be overwritten during 'deluged's shutdown process. So I suppose you could have two core.conf writes at each deluged shutdown which could cause different settings to be written depending what that deluged daemon had at the time. Lots of info above but hopefully it helps a bit. What is the status on this? I'm on holiday right now. I'll see to this when I'm back. Thanks for the interest. I think upstream documentation is clear enough. |