Difference between revisions of "Deluge"

From ArchWiki
Jump to: navigation, search
(Installation: Add note about deluge not supporting latest libtorrent)
 
(76 intermediate revisions by 18 users not shown)
Line 1: Line 1:
[[de:Deluge Installation]]
+
[[Category:Internet applications]]
 +
[[de:Deluge]]
 
[[es:Deluge]]
 
[[es:Deluge]]
 +
[[ja:Deluge]]
 
[[ko:Deluge]]
 
[[ko:Deluge]]
[[Category:Internet Applications]]
+
{{Related articles start}}
[http://deluge-torrent.org/ Deluge] is a full-featured  BitTorrent client for Linux, OS X, Unix and Windows. It uses  libtorrent in its backend and features multiple user-interfaces including: GTK+, web and console. It has been designed using the client server model with a daemon process that handles all the bittorrent activity. The Deluge daemon is able to run on headless machines with the user-interfaces being able to connect remotely from any platform. Deluge is not designed for any one desktop environment and will work just fine in GNOME, KDE, XFCE and others. Deluge is  Free Software and is licensed under the  GNU General Public License.
+
{{Related|rTorrent}}
 +
{{Related|systemd}}
 +
{{Related|systemd/User}}
 +
{{Related|iptables}}
 +
{{Related|OpenSSL}}
 +
{{Related articles end}}
  
==Install==
+
[http://deluge-torrent.org/ Deluge] is a lightweight but full-featured BitTorrent application written in Python 2. It has a variety of features, including but not limited to: a client/server model, DHT support, magnet links, a plugin system, UPnP support, full-stream encryption, proxy support, and three different client applications. When the server daemon is running, users can connect to it via a console client, a GTK+-based GUI, or a Web-based UI. A full list of features can be viewed [http://dev.deluge-torrent.org/wiki/About here].
[[pacman| Install]] {{Pkg|deluge}} from the [[official repositories]].
+
  
==Configuration==
+
== Installation ==
If you want to run Deluge as user just run:
+
# deluge -u [gtk|web|console]
+
  
===daemon===
+
Install {{Pkg|deluge}} and optionally {{Pkg|python2-service-identity}} as users may experience a lengthy warning and have their client reject many valid certificate/hostname mappings.
Please note, deluge works perfectly fine without its daemon running. The install process should create the defaults "deluge" user and group, with user deluge being a member of group deluge. You can change deluge's default user or group in deluge.conf
+
  
 +
Note: The latest release of deluge (1.3) does not support the latest {{Pkg|libtorrent-rasterbar}} (1.1)[http://forum.deluge-torrent.org/viewtopic.php?t=53939#p223925], resulting in connection problems.  Until deluge is updated, the only fix is to install libtorrent 1.0 which is not supported.
  
In case of systemd journal logging errors, it be necessary to copy /usr/lib/tmpfiles.d/deluge.conf to /etc/tmpfiles.d.
+
The GTK+ UI requires additional dependencies as does the Web UI:
 +
*{{Pkg|python2-notify}}: libnotify notifications support
 +
*{{Pkg|pygtk}}: requirement for the GTK+ UI
 +
*{{Pkg|librsvg}}: requirement for the GTK+ UI
 +
*{{Pkg|python2-mako}}: requirement for Web UI
  
 +
=== Plugins ===
 +
{{Note|Plugins should be compiled with Python2.7: e.g. {{ic|$ python2.7 ''setup.py build''}}.}}
  
The rest of this guide will assume you use the default '''deluge''' user. This is that user's default home directory and therefore its configuration location is in {{ic|/srv/deluge}}. This should be fine under most circumstances. Note that this is NOT the default download location, it only holds its configuration and ssl certificates. You will be able to change all other options later on once you get a client working.
+
A complete list of plugins can be found on the [http://dev.deluge-torrent.org/wiki/Plugins Deluge Wiki]
  
Next, start the [[daemon]] to generate its default configuration in its home directory:
+
[https://github.com/ratanakvlun/deluge-ltconfig ltConfig] is a useful plugin that allows direct modification to libtorrent settings and has preset support.
  
==Graphical Clients==
+
It offers additional settings like {{ic|announce_ip}} (IP to announce to trackers), {{ic|half_open_limit}} (Remove maximum half-open connections limit) and more possible privacy and (seed) speedboost features.
  
===GTK UI===
+
== Daemon setup ==
The GTK UI needs to have {{Pkg|pygtk}} and {{Pkg|librsvg}} installed on the clients.
+
If the deluge daemon is running stop it.
+
  
In order to connect remotely via the GTK UI, there should be something like this in {{ic|/srv/deluge/.config/deluge/core.conf}}:
+
{{Warning|If multiple users are running a daemon, the default port (58846) will need to be changed for each user.}}
"allow_remote": true,
+
Deluge comes with a daemon called {{ic|deluged}}. If it is not running when one of the clients is run, it will be started. It is useful, however, to have it started with systemd to allow torrents to run without starting a client and/or Xorg. This can be accomplished in one of two ways: a system service or a user service.
  
Now add yourself to the authentification file:
+
=== System service ===
# echo "yourusername:yourpassword:10" >> /srv/deluge/.config/deluge/auth
+
  
The authentification level is not used at this time. Read [http://dev.deluge-torrent.org/wiki/UserGuide/Authentication more] about that.
+
A system service will allow {{ic|deluged}} to run at boot without the need to start Xorg or a client. Deluge comes with a system service called {{ic|deluged.service}}, which can be [[start]]ed and enabled without change, which will run the deluge daemon as the '''deluge''' user, which is created by the package.
  
Start the Deluge daemon again.
+
To run the daemon under a different user, copy {{ic|/usr/lib/systemd/system/deluged.service}} to {{ic|/etc/systemd/system/deluged.service}} and change the User parameter within the file, such as the '''archie''' user:
 +
User='''archie'''
  
Now start the GTK UI. If you prefer, you can edit the preferences in {{ic|~/.config/deluge/gtkui.conf}}, but there's also a nice configuration tool in the UI.
+
=== User service ===
  
Look for '''classic mode''' and disable it. Then go to Edit -> Connection Manager and add your daemon.
+
A user service will allow {{ic|deluged}} to run when {{ic|systemd --user}} is started. This is accomplished by creating a user service file:
 +
{{hc|/etc/systemd/user/deluged.service|<nowiki>
 +
[Unit]
 +
Description=Deluge Daemon
 +
After=network.target
  
===Web UI===
+
[Service]
The web UI daemon runs on the server and the clients only need a web browser. You need to install {{Pkg|python2-mako}} on the server.
+
ExecStart=/usr/bin/deluged -d -P %h/.config/deluge/deluge.pid
  
First, start the web UI [[daemon]], named ''deluge-web'', and login at {{ic|http://''ip-address'':8112}}. Where ''ip-address'' is the name of your Deluge server or its private or public IP address. When asked for a password, enter "deluge" as it is the default password.
+
[Install]
 +
WantedBy=default.target
 +
</nowiki>}}
 +
The deluge user service can now be [[start]]ed and enabled by the user.
  
The preferences in the web UI should be rather self explanatory and the first obvious thing to do is to change your password.
+
The {{ic|deluged}} user service can also be placed in {{ic|$HOME/.config/systemd/user/}}. See [[systemd/User]] for more information on user services.
  
====Automatically Connect To Daemon====
+
== Configuration ==
If you want to avoid clicking "connect" everytime you start the Deluge web UI, edit the {{ic|web.conf}} file in your configuration directory (usually {{ic|/srv/deluge/.config/deluge}}). 
+
It should have a line like this towards the bottom:
+
'''
+
"default_daemon": ""
+
  
Change it to:
+
Deluge can be configured through any of the clients as well as by simply editing the JSON-formatted configuration files located in {{ic|$HOME/.config/deluge/}}. '''$HOME''' refers to the home directory of the user that {{ic|deluged}} is running as. This means that if the daemon is running as the '''deluge''' user, the default home directory is {{ic|/srv/deluge/}}.
'''
+
"default_daemon": "127.0.0.1:58846"
+
  
This assumes that your Deluge port is the default 58846.
+
=== Firewall ===
  
====SSL====
+
Deluge requires at least one port open for TCP and UDP to allow incoming connections for seeding. If deluge complaining that it cannot open a port for incoming connections, users must open port(s) to be used. In this example, ports 56881 through 56889 are opened for TCP and UDP:
In case you want SSL for the web UI, you need to generate a new cert/key set. To do this, first stop the web UI daemon and then append to {{ic|/srv/deluge/.config/deluge/ssl/}}:
+
# iptables -A INPUT -p tcp --dport 56881:56889 -j ACCEPT
 +
# iptables -A INPUT -p udp --dport 56881:56889 -j ACCEPT
 +
User who are behind a NAT router/firewall must setup the corresponding ports to be forwarded. UPnP may also be used, but that will not work with the local firewall on the system because it requires predefined ports.
 +
{{Note|One can limit this to a single port, just be sure to enable both TCP and UDP.}}
  
# openssl req -new -x509 -nodes -out deluge.cert.pem -keyout deluge.key.pem
+
On many default configurations, when using iptables with connection tracking (conntrack) set to drop "INVALID" packets, sometimes a great deal of legitimate torrent traffic (especially DHT traffic) is dropped as "invalid." This is typically caused by either conntrack's memory restrictions, or from long periods between packets among peers (see [http://libtorrent.rakshasa.no/wiki/RTorrentUsingDHT] towards the bottom and [http://www.linuxquestions.org/questions/showthread.php?p=5145026]). Symptoms of this problem include torrents not seeding, especially when the torrent client has been active for more than a day or two continuously, and consistently low overhead traffic (in one experience, less than 3KiB/s in either in or out) with DHT enabled, even when deluge/libtorrent has been continuously running for more than forty-eight hours and many torrents are active. For this reason, it may be necessary to disable connection tracking of all torrent traffic for optimal performance, even with the listening ports set to ACCEPT (as the causes for dropping INVALID packets, for instance conntrack's memory problems, may supercede any rules to accept traffic to/from those ports).
  
Next you need to edit {{ic|/srv/deluge/.config/deluge/web.conf}} and change the '''pkey''' and '''cert''' configuration directives to use your new self-signed certificates and also enable SSL:
+
To fully turn off connection tracking for torrents, specify ports for both Incoming and Outgoing traffic in Deluge, for instance, 56881-56889 for incoming connections and 56890-57200 for outgoing connections.
...
+
{{Note|Limiting incoming connections is not recommended with libtorrent as this will limit the ability to keep multiple connections to the same client, even for different torrents.}}
"pkey": "ssl/deluge.key.pem",
+
...
+
"cert": "ssl/deluge.cert.pem",
+
...
+
"https": true,
+
  
Afterwards just start the web UI daemon again.
+
Then issue the following commands (after substituting the relevant port ranges):
 +
# iptables -t raw -I PREROUTING -p udp --dport 56881:57200 -j NOTRACK
 +
# iptables -t raw -I OUTPUT -p udp --sport 56881:57200 -j NOTRACK
 +
# iptables -t raw -I PREROUTING -p tcp --dport 56881:57200 -j NOTRACK
 +
# iptables -t raw -I OUTPUT -p tcp --sport 56881:57200 -j NOTRACK
 +
# iptables -I INPUT -p icmp --icmp-type 3 -j ACCEPT
 +
# iptables -I INPUT -p icmp --icmp-type 4 -j ACCEPT
 +
# iptables -I INPUT -p icmp --icmp-type 11 -j ACCEPT
 +
# iptables -I INPUT -p icmp --icmp-type 12 -j ACCEPT
 +
The ICMP allowances are desirable because once connection tracking is disabled on those ports, those important ICMP messages (types 3 (Destination Unreachable), 4 (Source Quench), 11 (Time Exceeded) and 12 (Parameter Problem)) would otherwise be declared INVALID themselves (as netfilter would not know of any connections that they are associated with), and they would potentially be blocked.
 +
{{Warning|A port range of 1024:65535 would break every DNS query.}}
  
====Apache configuration====
+
== Clients ==
  
As of this writing, it is possible to use ProxyPass and ProxyPassReverse with Apache to run your Deluge web UI with a web server. To do so, add the following lines to your {{ic|httpd.conf}}.
+
=== Console ===
  
Uncomment the Virtual Hosts line:
+
The console client can be run with:
 +
$ deluge-console
 +
Enter the {{ic|help}} command for a list of available commands.
  
Include conf/extra/httpd-vhosts.conf
+
=== GTK+ ===
  
That is all the editing that needs to be done for the {{ic|httpd.conf}}. Next, navigate to the {{ic|extra/}} folder and edit the {{ic|httpd-vhosts.conf}} file. Append to the file, the following:
+
{{Note|It is wise to disable Classic Mode in ''Edit -> Preferences -> Interface'' for daemon (server) setups.}}
 +
The GTK+ client can be run with:
 +
$ deluge-gtk
 +
or:
 +
$ deluge
  
{{bc|<VirtualHost *:80>
+
The GTK+ client has a number of useful plugins:
    ServerAlias subdomain.example.com
+
* AutoAdd - Monitors directories for .torrent files
    ProxyRequests off
+
* Blocklist - Downloads and imports an IP blocklist
    ProxyPass / http://127.0.0.1:8112/
+
* Execute - Event-based command execution
    ProxyPassReverse / http://127.0.0.1:8112/
+
* Extractor - Extracts archived files upon completion '''''(beware of random high disk I/O usage)'''''
</VirtualHost>
+
* Label - Allows labels to be assigned to torrents, as well as state, tracker, and keyword filters
 +
* Notifications - Provides notifications (email, pop-up, blink, sound) for events as well as other plugins
 +
* Scheduler - Limits active torrents and their speed on a per-hour, per-day basis
 +
* WebUi - Allows the Web UI to be started via the GTK+ client
 +
 
 +
=== Web ===
 +
 
 +
{{Note|It is recommended to use HTTPS for the Web client to protect against a Man-in-the-middle attack.}}
 +
{{Warning|
 +
* If multiple users are running a daemon, the default port (8112) will need to be changed for each user.
 +
* The deluge Web client comes with {{ic|deluge}} as default password. Please update the password to something more secure.
 
}}
 
}}
 +
The Web UI can be [[start]] by running {{ic|deluge-web}} or by enabling the Web UI through the GTK+ UI. It offers many of the same features of the GTK+ UI, including the plugin system.
 +
 +
==== System service ====
 +
Deluge comes with a system service file called {{ic|deluge-web.service}}, which is used to [[start]] the Deluge Web UI.
 +
 +
The Deluge Web UI uses a Connection Manager, allowing managing of multiple Deluge clients running under the same host.
 +
It's however also possible to connect and manage Deluge clients running under a different host.
 +
 +
Remember to [[start]] and optionally [[enable]] the {{ic|deluged}} service to allow the Web UI connect to the host Deluge client.
 +
 +
==== User service ====
 +
 +
A user service will allow {{ic|deluge-web}} to run when {{ic|systemd --user}} is started. This is accomplished by creating a user service file:
 +
{{hc|/etc/systemd/user/deluge-web.service|<nowiki>
 +
[Unit]
 +
Description=Deluge Web UI
 +
After=deluged.service
 +
 +
[Service]
 +
ExecStart=/usr/bin/deluge-web --ssl
 +
 +
[Install]
 +
WantedBy=default.target
 +
</nowiki>}}
 +
The deluge user service can now be [[start]]ed and enabled by the user.
 +
 +
The {{ic|deluge-web}} user service can also be placed in {{ic|$HOME/.config/systemd/user/}}. See [[systemd/User]] for more information on user services.
 +
 +
==== Setup ====
 +
 +
When {{ic|deluge-web}} is initially started, it will create {{ic|$HOME/.config/deluge/web.conf}}. The password in this file is hashed with SHA1 and salted. The default password is "deluge".
 +
 +
Users may  be greeted by a warning from the browser that the SSL certificate is untrusted. Add an exception to this in the browser to continue on. See the [[OpenSSL]] page for information on creating your own certificate.
 +
 +
== Headless setup ==
 +
 +
Deluge is quite useful on a headless system, often referred to as a seed box, because of its client/server model. To set up deluge on a headless system, set up the daemon as shown above.
 +
 +
=== Create a user ===
 +
 +
To allow interaction with the server remotely, create a user in {{ic|$HOME/.config/deluge/auth}}. For example:
 +
$ echo "delugeuser:p422WoRd:10" >> $HOME/.config/deluge/auth
 +
{{Note|
 +
* The user/password created does not have to match any system users, and to maintain good security practices it should '''not'''!
 +
* The user/password in this file are not hashed or salted like in the web client config.
 +
* The user/password must match the user/password found in /srv/deluge/.config/deluge/auth otherwise the authentication fails.
 +
}}
 +
 +
The number '''10''' corresponds to a level of '''Admin'''.  Refer to the following table for additional values:
 +
 +
{| class="wikitable" align="center"
 +
|-
 +
! Level Name !! Level Value
 +
|-
 +
| None || 0
 +
|-
 +
|Read Only || 1
 +
|-
 +
| Normal || 5
 +
|-
 +
| Admin || 10
 +
|}
 +
 +
{{Note|In Deluge 1.35, these values have no effect, but multiuser options are under development.}}
 +
 +
=== Allow remote ===
 +
 +
The default settings disallow remote connections. Change the "allow_remote" setting in {{ic|$HOME/.config/deluge/core.conf}}:
 +
"allow_remote": true
 +
{{Note|
 +
{{ic|$HOME/.config/deluge/core.conf}} is automatically created at the first configuration change, if it does not exist you can set the value via {{ic|deluge-console}}:
 +
config --set allow_remote true
 +
}}
 +
 +
=== Firewall ===
 +
 +
Open the port for remote access. The following example uses the default daemon port (58846):
 +
# iptables -A INPUT -p tcp --dport 58846 -j ACCEPT
 +
See [[iptables]] for more information on firewall rules.
 +
 +
Users behind a NAT router/firewall must forward the port to access the daemon from outside the network if this behavior is desired.
 +
 +
=== Connect ===
 +
 +
In the console client:
 +
connect <host>[:<port>] <user> <password>
 +
 +
In the GTK+ client, ''Edit > Connection Manager > Add''.
 +
 +
In the Web client, ''Connection Manager > Add''.
  
==Troubleshooting==
+
==== SSH Tunnel ====
 +
An SSH tunnel can be created to use an encrypted connection on any client. This requires an extra loopback address to be added, but this can be automated at boot. Without this step, the connection would be considered local. The actual command to establish an SSH tunnel cannot be automated as it requires user input. There are a few possible ways to go about doing that.
 +
{{hc|/etc/systemd/system/extra_lo_addr.service|<nowiki>
 +
[Unit]
 +
Description=extra loopback address
 +
Wants=network.target
  
=== Downloads don't start ===
+
[Service]
As of libtorrent-rasterbar version 0.16, Deluge will not download torrents that are added by a magnet link.
+
Type=oneshot
* https://bugs.archlinux.org/task/29414
+
RemainAfterExit=yes
* https://bbs.archlinux.org/viewtopic.php?id=151249
+
ExecStart=/sbin/ip addr add 127.0.0.2/8 dev lo
 +
ExecStop=/sbin/ip addr del 127.0.0.2/8 dev lo
  
=== Web UI doesn't store settings ===
+
[Install]
For some yet unknown reason, the web interface with Deluge 1.3.3 refuses to properly store the incoming (listen) ports configuration. This can manually be edited in core.conf. The Deluge bugtracker mentions this is fixed, it is not in 1.3.3.
+
WantedBy=multi-user.target
 +
</nowiki>}}
  
{{hc|/srv/deluge/.config/deluge/core.conf|...
+
$ ssh -fNL 127.0.0.2:58846:localhost:58846 <ssh host>
"enc_prefer_rc4": true,
+
The port '''58846''' should be replaced with the port the deluge server is running on and '''<ssh host>''' should be replaced with the server hosting both deluge and the SSH server.
"listen_ports": [
+
  49160,
+
  49249
+
],
+
"dht": false,
+
...}}
+
  
=== Daemon won't start on fresh install ===
+
== See Also ==
There seems to be an issue creating a folder with the correct permissions when the package installs, try:
+
* [http://deluge-torrent.org/ Deluge homepage]
# chmod u+x /srv/deluge
+
* [http://dev.deluge-torrent.org/wiki Deluge wiki]

Latest revision as of 16:13, 13 July 2016

Deluge is a lightweight but full-featured BitTorrent application written in Python 2. It has a variety of features, including but not limited to: a client/server model, DHT support, magnet links, a plugin system, UPnP support, full-stream encryption, proxy support, and three different client applications. When the server daemon is running, users can connect to it via a console client, a GTK+-based GUI, or a Web-based UI. A full list of features can be viewed here.

Installation

Install deluge and optionally python2-service-identity as users may experience a lengthy warning and have their client reject many valid certificate/hostname mappings.

Note: The latest release of deluge (1.3) does not support the latest libtorrent-rasterbar (1.1)[1], resulting in connection problems. Until deluge is updated, the only fix is to install libtorrent 1.0 which is not supported.

The GTK+ UI requires additional dependencies as does the Web UI:

Plugins

Note: Plugins should be compiled with Python2.7: e.g. $ python2.7 setup.py build.

A complete list of plugins can be found on the Deluge Wiki

ltConfig is a useful plugin that allows direct modification to libtorrent settings and has preset support.

It offers additional settings like announce_ip (IP to announce to trackers), half_open_limit (Remove maximum half-open connections limit) and more possible privacy and (seed) speedboost features.

Daemon setup

Warning: If multiple users are running a daemon, the default port (58846) will need to be changed for each user.

Deluge comes with a daemon called deluged. If it is not running when one of the clients is run, it will be started. It is useful, however, to have it started with systemd to allow torrents to run without starting a client and/or Xorg. This can be accomplished in one of two ways: a system service or a user service.

System service

A system service will allow deluged to run at boot without the need to start Xorg or a client. Deluge comes with a system service called deluged.service, which can be started and enabled without change, which will run the deluge daemon as the deluge user, which is created by the package.

To run the daemon under a different user, copy /usr/lib/systemd/system/deluged.service to /etc/systemd/system/deluged.service and change the User parameter within the file, such as the archie user:

User=archie

User service

A user service will allow deluged to run when systemd --user is started. This is accomplished by creating a user service file:

/etc/systemd/user/deluged.service
[Unit]
Description=Deluge Daemon
After=network.target

[Service]
ExecStart=/usr/bin/deluged -d -P %h/.config/deluge/deluge.pid

[Install]
WantedBy=default.target
 

The deluge user service can now be started and enabled by the user.

The deluged user service can also be placed in $HOME/.config/systemd/user/. See systemd/User for more information on user services.

Configuration

Deluge can be configured through any of the clients as well as by simply editing the JSON-formatted configuration files located in $HOME/.config/deluge/. $HOME refers to the home directory of the user that deluged is running as. This means that if the daemon is running as the deluge user, the default home directory is /srv/deluge/.

Firewall

Deluge requires at least one port open for TCP and UDP to allow incoming connections for seeding. If deluge complaining that it cannot open a port for incoming connections, users must open port(s) to be used. In this example, ports 56881 through 56889 are opened for TCP and UDP:

# iptables -A INPUT -p tcp --dport 56881:56889 -j ACCEPT
# iptables -A INPUT -p udp --dport 56881:56889 -j ACCEPT

User who are behind a NAT router/firewall must setup the corresponding ports to be forwarded. UPnP may also be used, but that will not work with the local firewall on the system because it requires predefined ports.

Note: One can limit this to a single port, just be sure to enable both TCP and UDP.

On many default configurations, when using iptables with connection tracking (conntrack) set to drop "INVALID" packets, sometimes a great deal of legitimate torrent traffic (especially DHT traffic) is dropped as "invalid." This is typically caused by either conntrack's memory restrictions, or from long periods between packets among peers (see [2] towards the bottom and [3]). Symptoms of this problem include torrents not seeding, especially when the torrent client has been active for more than a day or two continuously, and consistently low overhead traffic (in one experience, less than 3KiB/s in either in or out) with DHT enabled, even when deluge/libtorrent has been continuously running for more than forty-eight hours and many torrents are active. For this reason, it may be necessary to disable connection tracking of all torrent traffic for optimal performance, even with the listening ports set to ACCEPT (as the causes for dropping INVALID packets, for instance conntrack's memory problems, may supercede any rules to accept traffic to/from those ports).

To fully turn off connection tracking for torrents, specify ports for both Incoming and Outgoing traffic in Deluge, for instance, 56881-56889 for incoming connections and 56890-57200 for outgoing connections.

Note: Limiting incoming connections is not recommended with libtorrent as this will limit the ability to keep multiple connections to the same client, even for different torrents.

Then issue the following commands (after substituting the relevant port ranges):

# iptables -t raw -I PREROUTING -p udp --dport 56881:57200 -j NOTRACK
# iptables -t raw -I OUTPUT -p udp --sport 56881:57200 -j NOTRACK
# iptables -t raw -I PREROUTING -p tcp --dport 56881:57200 -j NOTRACK
# iptables -t raw -I OUTPUT -p tcp --sport 56881:57200 -j NOTRACK
# iptables -I INPUT -p icmp --icmp-type 3 -j ACCEPT
# iptables -I INPUT -p icmp --icmp-type 4 -j ACCEPT
# iptables -I INPUT -p icmp --icmp-type 11 -j ACCEPT
# iptables -I INPUT -p icmp --icmp-type 12 -j ACCEPT

The ICMP allowances are desirable because once connection tracking is disabled on those ports, those important ICMP messages (types 3 (Destination Unreachable), 4 (Source Quench), 11 (Time Exceeded) and 12 (Parameter Problem)) would otherwise be declared INVALID themselves (as netfilter would not know of any connections that they are associated with), and they would potentially be blocked.

Warning: A port range of 1024:65535 would break every DNS query.

Clients

Console

The console client can be run with:

$ deluge-console

Enter the help command for a list of available commands.

GTK+

Note: It is wise to disable Classic Mode in Edit -> Preferences -> Interface for daemon (server) setups.

The GTK+ client can be run with:

$ deluge-gtk

or:

$ deluge

The GTK+ client has a number of useful plugins:

  • AutoAdd - Monitors directories for .torrent files
  • Blocklist - Downloads and imports an IP blocklist
  • Execute - Event-based command execution
  • Extractor - Extracts archived files upon completion (beware of random high disk I/O usage)
  • Label - Allows labels to be assigned to torrents, as well as state, tracker, and keyword filters
  • Notifications - Provides notifications (email, pop-up, blink, sound) for events as well as other plugins
  • Scheduler - Limits active torrents and their speed on a per-hour, per-day basis
  • WebUi - Allows the Web UI to be started via the GTK+ client

Web

Note: It is recommended to use HTTPS for the Web client to protect against a Man-in-the-middle attack.
Warning:
  • If multiple users are running a daemon, the default port (8112) will need to be changed for each user.
  • The deluge Web client comes with deluge as default password. Please update the password to something more secure.

The Web UI can be start by running deluge-web or by enabling the Web UI through the GTK+ UI. It offers many of the same features of the GTK+ UI, including the plugin system.

System service

Deluge comes with a system service file called deluge-web.service, which is used to start the Deluge Web UI.

The Deluge Web UI uses a Connection Manager, allowing managing of multiple Deluge clients running under the same host. It's however also possible to connect and manage Deluge clients running under a different host.

Remember to start and optionally enable the deluged service to allow the Web UI connect to the host Deluge client.

User service

A user service will allow deluge-web to run when systemd --user is started. This is accomplished by creating a user service file:

/etc/systemd/user/deluge-web.service
[Unit]
Description=Deluge Web UI
After=deluged.service

[Service]
ExecStart=/usr/bin/deluge-web --ssl

[Install]
WantedBy=default.target

The deluge user service can now be started and enabled by the user.

The deluge-web user service can also be placed in $HOME/.config/systemd/user/. See systemd/User for more information on user services.

Setup

When deluge-web is initially started, it will create $HOME/.config/deluge/web.conf. The password in this file is hashed with SHA1 and salted. The default password is "deluge".

Users may be greeted by a warning from the browser that the SSL certificate is untrusted. Add an exception to this in the browser to continue on. See the OpenSSL page for information on creating your own certificate.

Headless setup

Deluge is quite useful on a headless system, often referred to as a seed box, because of its client/server model. To set up deluge on a headless system, set up the daemon as shown above.

Create a user

To allow interaction with the server remotely, create a user in $HOME/.config/deluge/auth. For example:

$ echo "delugeuser:p422WoRd:10" >> $HOME/.config/deluge/auth
Note:
  • The user/password created does not have to match any system users, and to maintain good security practices it should not!
  • The user/password in this file are not hashed or salted like in the web client config.
  • The user/password must match the user/password found in /srv/deluge/.config/deluge/auth otherwise the authentication fails.

The number 10 corresponds to a level of Admin. Refer to the following table for additional values:

Level Name Level Value
None 0
Read Only 1
Normal 5
Admin 10
Note: In Deluge 1.35, these values have no effect, but multiuser options are under development.

Allow remote

The default settings disallow remote connections. Change the "allow_remote" setting in $HOME/.config/deluge/core.conf:

"allow_remote": true
Note:

$HOME/.config/deluge/core.conf is automatically created at the first configuration change, if it does not exist you can set the value via deluge-console:

config --set allow_remote true

Firewall

Open the port for remote access. The following example uses the default daemon port (58846):

# iptables -A INPUT -p tcp --dport 58846 -j ACCEPT

See iptables for more information on firewall rules.

Users behind a NAT router/firewall must forward the port to access the daemon from outside the network if this behavior is desired.

Connect

In the console client:

connect <host>[:<port>] <user> <password>

In the GTK+ client, Edit > Connection Manager > Add.

In the Web client, Connection Manager > Add.

SSH Tunnel

An SSH tunnel can be created to use an encrypted connection on any client. This requires an extra loopback address to be added, but this can be automated at boot. Without this step, the connection would be considered local. The actual command to establish an SSH tunnel cannot be automated as it requires user input. There are a few possible ways to go about doing that.

/etc/systemd/system/extra_lo_addr.service
[Unit]
Description=extra loopback address
Wants=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip addr add 127.0.0.2/8 dev lo
ExecStop=/sbin/ip addr del 127.0.0.2/8 dev lo

[Install]
WantedBy=multi-user.target
$ ssh -fNL 127.0.0.2:58846:localhost:58846 <ssh host>

The port 58846 should be replaced with the port the deluge server is running on and <ssh host> should be replaced with the server hosting both deluge and the SSH server.

See Also