Transmission experience

[Michael Danilov <mike.d.ft402%gmail.com@localhost>]

Good afternoon,

I would like to share my way of setting up transmission-daemon for convenient, 
unattended and multiuser operation.

First, create a group, add a user as whom the daemon will be run.

        # group add torrent
        # user add -m -M750 -s/sbin/nologin -gtorrent

Make the basic directory structure as follows:

        # mkdir /home/torrent/config /home/torrent/data
        # chown -R torrent:torrent /home/torrent
        # chmod 700 /home/torrent/config
        # chmod 750 /home/torrent/data

If you want the group members to have write access to the data, set the access 
bits for "data" to 770 instead.

Write a rc script /etc/rc.d/torrentd as shown below, set its mode to 555:

        #!/bin/sh

        # PROVIDE: torrentd
        # REQUIRE: DAEMON

        . /etc/rc.subr

        name="torrentd"
        rcvar=$name
        command="/usr/pkg/bin/transmission-daemon"
        command_args="-g/home/torrent/config"
        pidfile="/var/run/${name}.pid"

        load_rc_config $name
        torrentd_user="torrent"
        run_rc_command "$1"
        check_process ${command} > ${pidfile}

Now add the following to your rc.conf. These flags are a good, safe start:

        torrentd=YES
        torrentd_flags="-C -r127.0.0.1" #no watchdir, restricted RPC

Time to launch the daemon and see if it works correctly, being run as the 
"torrent" user. If not, something is wrong, and you should not leave it running.

        # cd /
        # /etc/rc.d/torrentd start
        # ps aux
        # /etc/rc.d/torrentd stop

If everything is in order, it will create the configuration files in 
/home/torrent/config. Consult 
https://trac.transmissionbt.com/wiki/EditConfigFiles and set the following  
entries of /home/torrent/config/settings.json. As an example, we're using 
"hackme" for RPC password. Of course, you are going to need a better one for 
production run. In my case, I didn't need any kind of remote control 
Transmission offered, so I restricted RPC to localhost. In case you need it, I 
think it might be better to set up SSHd, if not, bind RPC to 0.0.0.0 and 
disable whitelist below, mind the flags in rc.conf as well.

        "download-dir": "/home/torrent/data",
        "rpc-authentication-required": true,
        "rpc-bind-address": "127.0.0.1", 
        "rpc-enabled": true,
        "rpc-password": "hackme",
        "rpc-username": "root",
        "rpc-whitelist": "127.0.0.1",
        "rpc-whitelist-enabled": true,
        "watch-dir-enabled": false

The password will be hashed.
        
Here are some more that might be useful in enhancing security:

        "blocklist-enabled": true,
        "blocklist-url": 
"http://list.iblocklist.com/?list=bt_level1&fileformat=p2p&archiveformat=gz";,
        "encryption": 2,

Fire up the daemon again, issue the following command:

        $ transmission-remote -nroot:hackme -l

It will print out the list of torrents, which should be empty for now. Consult 
the manual for other options.

You might find having to remember yet another password inconvenient. To avoid 
this, create a script in /root/bin with mode 700, that does the auth for you:

        #!/bin/sh
        transmission-remote -nroot:hackme $@

Members of the "transmission" group can not control the daemon, which might be 
inconvenient. There are two workarounds to this I've come up with yet, which 
are somewhat limited. If you know possible solutions to this problem, please 
let me know.

        a. You can create watch dir for torrents, writable by the group. This 
allows users only to add torrents. If torrents are not started automatically 
(see settings.json), the user in control must issue commands to start them. 
This is useful if you want to revise users' choice before downloading anything.

        b. Move the script we've created above to /usr/pkg/bin, set its owner 
and group to "root" and "torrent" respectively, and modes to 750, so that only 
the group can run it. In this case, the group can almost fully control the 
daemon's behaviour. Good on small systems with little number of users, but on 
bigger ones it will likely cause a mess.