Difference between revisions of "Deluge"

From ArchWiki
Jump to: navigation, search
m (Daemon Setup)
(pull under installation)
 
(67 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}}
{{Article summary start}}
+
{{Related|rTorrent}}
{{Article summary text|Deluge is a lightweight, BitTorrent client written in python that offers users a powerful client/server architecture.  Once a headless daemon has been setup, user can interact with it in three ways including a WebUI, GTK-UI, and console interface.}}
+
{{Related|systemd}}
{{Article summary heading|Related Articles}}
+
{{Related|systemd/User}}
{{Article summary wiki|PeerGuardian Linux}}
+
{{Related|iptables}}
{{Article summary wiki|Ufw}}
+
{{Related|OpenSSL}}
{{Article summary heading|External Links}}
+
{{Related articles end}}
{{Article summary wiki|http://dev.deluge-torrent.org/wiki Official Deluge Wiki}}
+
{{Article summary end}}
+
  
==Installation==
+
[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].
{{Pkg|deluge}} is available from the [[official repositories]].
+
# pacman -S deluge
+
  
The gtk UI requires additional dependencies as does the webui.  Inspect the pacman output to determine which are right for the intended application.
+
== Installation ==
python2-notify: libnotify notifications
+
pygtk: needed for gtk ui
+
librsvg: needed for gtk ui
+
python2-mako: needed for web ui
+
  
==Daemon Setup==
+
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. Additional optional dependencies can be viewed using the [[#Querying package databases|pacman -Si]] command.
Deluge can run as a system daemon which is accessible to any system user or it can run in a non-daemon mode.  The focus of this article is on the daemon mode of operation.  Users wishing a more simplistic setup, i.e. running {{ic|/usr/bin/deluged}} as them-self should be able to read on and simply substitute the systemctl commands for the live files on the system.
+
  
{{Note|Advanced users are free to edit the configuration files in the deluge daemon home directory {{ic|/srv/deluge/.config/}} manually or from {{ic|/usr/bin/deluge-console}}. The rest of this guide is written using the gtk client to do this from convenience of a GUI.}}
+
{{Note|Currently, {{pkg|python2-twisted}} and its 4 other dependencies that pacman pulls in automatically when installing deluge are not removed due to a bug revolving around a dependency cycle, see: [https://bugs.archlinux.org/task/41031 FS#41031]. Users can circumvent this by removing the affected packages (assuming they are not needed by other packages installed on the system): {{ic|pacman -Rs deluge python2-twisted}}.}}
  
Start the deluge backend daemon like any other systemd service:
+
== Daemon ==
  # systemctl start deluged
+
Deluge works with a client/server model. The server is referred to as the daemon and runs in the background waiting for a client (console, gtk, or web-based) to connect. The client can disconnect but the daemon continues to run transferring the torrent files in the queue.
  
=== Create a User ===
+
Upon installation, pacman will create a non-privileged '''deluge''' user.  This user is meant to run the provided daemon, {{ic|/usr/bin/deluged}}. Users are able to start the daemon several ways:
To allow interaction with the daemon, create a user:password:level in {{ic|/srv/deluge/.config/deluge/auth}}.
+
# Systemd system service (runs as the deluge user).
For example:
+
# Systemd user service (runs as another user).
# echo "delugeuser:p422WoRd:10" >> /srv/deluge/.config/deluge/auth
+
# Running it directly (runs as another user).
{{Note|The user/password created does not have to match any system users... and to maintain good security practices it should NOT!}}
+
  
The number '''10''' corresponds to a level of 'Admin.'  Refer to the following table for additional values:
+
{{Tip|For the highest level of security, running {{ic|deluged}} via the systemd system service ({{ic|deluged.service}}) is recommended since the deluge user has no shell access (limited account) or other group affiliation on the host system.  In addition to the security benefits of running as the non-privileged deluge user, the system service can also run at boot without the need to start Xorg or a client.}}
 +
 
 +
=== System service ===
 +
 
 +
[[Start]] the service and optionally [[enable]] it if running at boot is  desired.
 +
 
 +
=== User service ===
 +
 
 +
{{Warning|If multiple users are running a daemon, the default port (58846) will need to be changed for each user.}}
 +
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
 +
 
 +
[Service]
 +
ExecStart=/usr/bin/deluged -d -P %h/.config/deluge/deluge.pid
 +
 
 +
[Install]
 +
WantedBy=default.target
 +
</nowiki>}}
 +
The deluge user service can now be [[start]]ed and enabled by the user.
 +
 
 +
The {{ic|deluged}} user service can also be placed in {{ic|$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 {{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/}}.
 +
 
 +
=== Shared directories for downloads/uploads ===
 +
When using the systemd deluged.service, the shared directory/directories need to be shared so that other users on the system are able to access the data.  The general strategy is to:
 +
 
 +
# Change the owner and group of the shared directory to deluge:deluge.
 +
# Set the [[File_permissions_and_attributes]] on the shared directory to at least 770.
 +
# Add your user (or the user/users needing to access the files) to the deluge group.
 +
 
 +
Example using {{ic|/mnt/torrent_data}}:
 +
# chown -R deluge:deluge /mnt/torrent_data
 +
# chmod 770 /mnt/torrent_data
 +
# usermod -a -G deluge YOURUSER
 +
 
 +
{{Note|When usermod is used to change group affiliation, a logout/login is required before changes take effect.}}
 +
 
 +
=== 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 [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).
 +
 
 +
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.}}
 +
 
 +
=== Plugins ===
 +
{{Note|Plugins should be compiled with Python2.7: e.g. {{ic|$ python2.7 ''setup.py build''}}.}}
 +
 
 +
A complete list of plugins can be found on the [http://dev.deluge-torrent.org/wiki/Plugins Deluge Wiki]
 +
 
 +
[https://github.com/ratanakvlun/deluge-ltconfig ltConfig] is a useful plugin that allows direct modification to libtorrent settings and has preset support.
 +
 
 +
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.
 +
 
 +
== Clients ==
 +
 
 +
=== Console ===
 +
 
 +
The console client can be run with:
 +
$ deluge-console
 +
Enter the {{ic|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 ===
 +
A web-client is also provided should users not want GTK or shell-based access to the daemon.  Just as with deluge daemon mentioned above, the web client as can be started several different ways:
 +
# Systemd system service (runs as the deluge user).
 +
# Systemd user service (runs as another user).
 +
# Running it directly (runs as another user).
 +
 
 +
{{Tip|For the highest level of security, running {{ic|deluge-web}} via the systemd system service ({{ic|deluge-web.service}}) is recommended since the deluge user has no shell access (limited account) or other group affiliation on the host system.  In addition to the security benefits of running as the non-privileged deluge user, the system service can also run at boot without the need to start Xorg or a client.}}
 +
 
 +
When the web client s 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".
 +
 
 +
Several things to note:
 +
* The web client offers many of the same features of the GTK+ UI, including the plugin system.
 +
* It is recommended to use HTTPS for the Web client to protect against a man-in-the-middle attack.
 +
* 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.
 +
* If multiple users are running a daemon, the default port (8112) will need to be changed for each user.
 +
 
 +
Once running, users may connect to the web client by browsing to http://hostname:8112 or if using encryption: https://hostname:8112
 +
 
 +
==== System service ====
 +
Deluge ships with {{ic|deluge-web.service}}, a systemd system unit, 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 or on an entirely different one. 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.
 +
 
 +
== 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"
 
{| class="wikitable" align="center"
Line 53: Line 200:
 
{{Note|In Deluge 1.35, these values have no effect, but multiuser options are under development.}}
 
{{Note|In Deluge 1.35, these values have no effect, but multiuser options are under development.}}
  
=== Define Options ===
+
=== Allow remote ===
#Load the gtk client {{ic|/usr/bin/deluge-gtk}}
+
#Disable '''classic mode''' from the Edit>Preferences>Interface.
+
 
+
A restart of the client is required for these changes to take effect.  Exit the client and reload it.
+
 
+
#Setup the client to point to the daemon from Edit>Connection Manager.
+
#Delete the dummy server by hightlighting it and clicking the "Remove" button.
+
#Create an entry to the daemon via the "Add" button populating the resulting dialog with either the IP address or the word "localhost" as the hostname.  Populate the "Username" and "Password" fields with the username and password used in the daemons setup. and then click the "+ Add" button.
+
 
+
Hostname: localhost
+
Username: delugeuser
+
Password: p422WoRd:10
+
 
+
If the correct credentials were populated, a green light should appear options for interaction  adjacent to the name of the server.  To connect, hit the "Connect" button.
+
 
+
Users can now configure their server from the GUI.  Most of the options are self explanatory and intuitive.  More details are available on the official [http://dev.deluge-torrent.org/wiki/UserGuide/BandwidthTweaking Deluge wiki] for details.
+
 
+
{{Note|When defining paths under Preferences>Downloads make sure that the the '''deluge''' user has read/write access to whatever is defined.  Remember that the daemon is running as system user '''deluge''' in system group '''deluge'''!}}
+
{{Note|If the expectation exists to allow access from other machines, be sure to enable Preferences>Daemon>Connections>Allow Remote Connections.}}
+
  
== Interacting with the Daemon ==
+
The default settings disallow remote connections. Change the "allow_remote" setting in {{ic|$HOME/.config/deluge/core.conf}}:
As previously mentioned, users have three options to connect to the daemon:
+
"allow_remote": true
#Deluge-GTK
+
{{Note|
#Deluge-Web
+
{{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}}:
#Deluge-console
+
config --set allow_remote true
 +
}}
  
=== Deluge-Gtk ===
+
=== Firewall ===
The gtk client has already been covered in the previous section.  Users should now have a fully functional client.
+
  
===Deluge-Web (Optional) ===
+
Open the port for remote access. The following example uses the default daemon port (58846):
{{Warning|Running the web client without encryption can be a bad idea. It is therefore recommended that users enable https.}}
+
  # iptables -A INPUT -p tcp --dport 58846 -j ACCEPT
To enable encrypted connections to/from the daemon, simply edit the '''https''' variable in {{ic|/srv/deluge/.config/deluge/web.conf}} changing the default value of '''false''' to '''true''' as shown:
+
See [[iptables]] for more information on firewall rules.
  "https": true,
+
  
Take note of the doublequotes and the trailing comma!
+
Users behind a NAT router/firewall must forward the port to access the daemon from outside the network if this behavior is desired.
  
Users wishing to regenerate self-signed certificates can refer to [http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#selfcert this link].
+
=== Connect ===
  
To run the web ui, simply start the web-daemon:
+
In the console client:
  # systemctl start deluge-web
+
  connect <host>[:<port>] <user> <password>
  
Point a browser to {{ic|https://localhost:8112}}.  Substitute the word '''localhost''' with an IP address if the server is elsewhere.
+
In the GTK+ client, ''Edit > Connection Manager > Add''.
When asked for a password, enter "deluge" as it is the default password.
+
  
The preferences in the web UI is ''highly'' similar to the gtk UI.  As explained in the previous section, edit the connection manager and define an entry to the daemon using the same credentials used in the setup step.  Once finished, users are free to remove the dummy server entry.
+
In the Web client, ''Connection Manager > Add''.
  
Hostname: localhost
+
==== SSH Tunnel ====
Username: delugeuser
+
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.
Password: p422WoRd:10
+
{{hc|/etc/systemd/system/extra_lo_addr.service|<nowiki>
 +
[Unit]
 +
Description=extra loopback address
 +
Wants=network.target
  
=== Deluge-Console (Optional) ===
+
[Service]
The CLI client {{ic|/usr/bin/deluge-consle}} can also be used to connect to a running daemon. Invoke it from a shell. To connect, simply type:
+
Type=oneshot
connect localhost delugeuser p422WoRd:10
+
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
  
==Troubleshooting==
+
[Install]
=== Magnet Links Are Broken with Chromium ===
+
WantedBy=multi-user.target
The following command should return "deluge.desktop":
+
</nowiki>}}
$ xdg-mime query default "x-scheme-handler/magnet"
+
  
If it returns a null, run this command:
+
  $ ssh -fNL 127.0.0.2:58846:localhost:58846 <ssh host>
  $ xdg-mime default deluge.desktop application/x-bittorrent x-scheme-handler/magnet
+
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.
  
Reference: https://bugs.archlinux.org/task/28011
+
== See Also ==
 +
* [http://deluge-torrent.org/ Deluge homepage]
 +
* [http://dev.deluge-torrent.org/wiki Deluge wiki]

Latest revision as of 19:50, 30 November 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. Additional optional dependencies can be viewed using the pacman -Si command.

Note: Currently, python2-twisted and its 4 other dependencies that pacman pulls in automatically when installing deluge are not removed due to a bug revolving around a dependency cycle, see: FS#41031. Users can circumvent this by removing the affected packages (assuming they are not needed by other packages installed on the system): pacman -Rs deluge python2-twisted.

Daemon

Deluge works with a client/server model. The server is referred to as the daemon and runs in the background waiting for a client (console, gtk, or web-based) to connect. The client can disconnect but the daemon continues to run transferring the torrent files in the queue.

Upon installation, pacman will create a non-privileged deluge user. This user is meant to run the provided daemon, /usr/bin/deluged. Users are able to start the daemon several ways:

  1. Systemd system service (runs as the deluge user).
  2. Systemd user service (runs as another user).
  3. Running it directly (runs as another user).
Tip: For the highest level of security, running deluged via the systemd system service (deluged.service) is recommended since the deluge user has no shell access (limited account) or other group affiliation on the host system. In addition to the security benefits of running as the non-privileged deluge user, the system service can also run at boot without the need to start Xorg or a client.

System service

Start the service and optionally enable it if running at boot is desired.

User service

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

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/.

Shared directories for downloads/uploads

When using the systemd deluged.service, the shared directory/directories need to be shared so that other users on the system are able to access the data. The general strategy is to:

  1. Change the owner and group of the shared directory to deluge:deluge.
  2. Set the File_permissions_and_attributes on the shared directory to at least 770.
  3. Add your user (or the user/users needing to access the files) to the deluge group.

Example using /mnt/torrent_data:

# chown -R deluge:deluge /mnt/torrent_data
# chmod 770 /mnt/torrent_data
# usermod -a -G deluge YOURUSER
Note: When usermod is used to change group affiliation, a logout/login is required before changes take effect.

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 [1] towards the bottom and [2]). 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.

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.

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

A web-client is also provided should users not want GTK or shell-based access to the daemon. Just as with deluge daemon mentioned above, the web client as can be started several different ways:

  1. Systemd system service (runs as the deluge user).
  2. Systemd user service (runs as another user).
  3. Running it directly (runs as another user).
Tip: For the highest level of security, running deluge-web via the systemd system service (deluge-web.service) is recommended since the deluge user has no shell access (limited account) or other group affiliation on the host system. In addition to the security benefits of running as the non-privileged deluge user, the system service can also run at boot without the need to start Xorg or a client.

When the web client s 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".

Several things to note:

  • The web client offers many of the same features of the GTK+ UI, including the plugin system.
  • It is recommended to use HTTPS for the Web client to protect against a man-in-the-middle attack.
  • 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.
  • If multiple users are running a daemon, the default port (8112) will need to be changed for each user.

Once running, users may connect to the web client by browsing to http://hostname:8112 or if using encryption: https://hostname:8112

System service

Deluge ships with deluge-web.service, a systemd system unit, 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 or on an entirely different one. 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.

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