On 29 December 2011, at 11:07, Pandu Poluan wrote:
> I'm wondering: what's your recommended CLI Torrent client(s)? And why?
deluge.
I believe that when I checked it was the only client that could be run in
daemon and client mode.
The CLI front end isn't perfect, but it's ok, especially once you get used to
using the pageup / pagedwn keys (and working out the function-key equivalents
on a cramped MacBook keyboard).
`deluge-console` starts the curses interface and once it's running you can run
commands like `info` to show the status of torrents (use `info abce123` to show
the status of the torrent for which the hash begins with abc123). However you
can also run `deluge-console info` at the command line and grep the results. To
add parameters to commands applied from the bash prompt you need to quote them
- e.g. `deluge-console 'config -s max_download_speed 150'`
I mislaid my installation notes from a few months ago, but basically you emerge
deluge and have to create for yourself a deluge user, with limited permissions
and a home dir of something like /media/Torrents/. Edit /etc/conf.d/deluge to
accommodate this user and start the daemon.
Next you start the UI as the deluged user - I can't recall if this involved
`sudo -u deluge deluge-console` or whether it involved giving the user a shell
(afterwards return it to /bin/false) and `su - deluge`, but you will find a
~deluge/.config/deluge/ is created. Exit the client, stop the daemon and copy
this and all its contents to your own homedir (~stroller/.config/deluge/),
making sure you set ownership to yourself. Now when you start deluge-console as
your own user (having restarted the deluged daemon) it will connect using the
deluged credentials.
Caveats that I can remember are that you add your own user to the deluge group,
and you need to set permissions (umask?) on ~deluge so that files / directories
are created 660 / 770 (or at least readable). When a torrent finishes you copy
it from /media/Torrents/ to /media/Videos/ (or wherever) and then use the
deluge UI to delete it; the files are then removed from from /media/Torrents/.
When you add a torrent its torrent file is stored in as
~deluge/.config/deluge/state/abc123….torrent (where abc123… is the hash);
deluge has a function that can monitor a directory for new .torrents, and I
just made this directory ~deluge, then added the below to my .bashrc:
function torrent {
if [[ ! -n "$1" ]] ; then echo "Torrent what file?" >&2 ; return 1 ; fi
while [ "$1" ] ; do
if [[ ! -e "$1" ]] ; then echo "$1 isn't a file!" >&2 ; return 1 ; fi
if [ ! "$(file -b "$1")" == 'BitTorrent file' ]
then echo "$1 appears not to be a BitTorrent file!" >&2 ; return 1 ; fi
chmod 666 "$1" && mv "$1" "~deluge/${1##*/}.torrent"
shift ; done ; return 0 ;
}
These permissions allow deluge to keep its homedir clean - it can delete files
belonging to you, and create copies in its state folder. Alternatively you
could share the folder over Samba and ensure the permissions that way.
You ask specifically for a CLI client, but the gtk front end is really pretty
acceptable, and having already copied the .config/deluge/ stuff you can use it
over ssh & X11 on your Apple Mac. The first time you might need to go into the
app's prefs, enable "show remote servers" and connect using the new button that
appears in the toolbar. You can install the scheduling plugin using the gtk
client and arrange for your downloads to only run at offpeak times; once this
is saved you don't need to use the gtk client again. There's a webinterface;
it's a bit shit (in 1.3.2, I haven't tried it in 1.3.3; I think some
improvements are supposed to be coming) but it's ok.
I think I've used Enhanced CTorrent in the past on an old system - it seemed to
work ok but I think it has some flaws; it's been at least a couple of years so
I don't remember the details. I think it's rtorrent that everyone raves about
as "the best" command-line client, but IIRC you fundamentally have to run it
inside a tmux or screen session, and thus you can't have it initiated at boot
(not reliably, at least); it also doesn't have a separate daemon, and IMO this
is just iffy. On a headless box you're going to have to ssh in as the rtorrent
user, or run it as you and leave your files and privileges exposed. Yeah, as
far as I can see, most authors of BitTorrent clients overlook best practices
for security because "it isn't a real service" or, uh, no-one's actually looked
for exploits yet. Not that they've disclosed publicly, anyway.
deluge was the only client I could find that addressed this security issue
properly, was well enough supported and which had a good selection of clients.
I did look at, and try, Transmission; I can't recall why I rejected it.
Stroller.
