Deluge

Deluge is a 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

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:

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 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:

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:

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:

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] 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):

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.

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.

The python2-mako dependency is needed for the web client to work. When the web client 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".

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

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.

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:

Firewall

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.

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.

Troubleshooting

No module named service_identity

Upon running deluged or deluge-console, one may receive a message like the following:

:0: UserWarning: You do not have a working installation of the service_identity module: 'No module named service_identity'.
Please install it from <https://pypi.python.org/pypi/service_identity> and make sure all of its dependencies are satisfied.
Without the service_identity module and a recent enough pyOpenSSL to support it, Twisted can perform only rudimentary TLS
client hostname verification. Many valid certificate/hostname mappings may be rejected.