• It has to run on Slackware
• It has to run as a daemon (in daemontools if possible)
• There has to be an easy way to control and view the status, like a web based GUI.

A few years ago I used mldonkey for it. Worked fine, but their torrent support was getting worse and worse. (basically they didn’t update their product for ages, and when they did it didn’t improve much). It had a web interface that worked nicely though, and it was easy to control. Another cute thing was that it also supported other protocols that I still used back then like Edonkey.

However, at some point I got fed up with it and searched for a better product. Especially since I didn’t care about the other protocols anymore I could search for a pure torrent client. Many of them only support running as a client with some kind of fancy GUI… not good for running on our server. But then I found Rtorrent.
While it was a bitch to run on my server since it demanded to run in a terminal (and therefore refused to run under daemontools) — a problem I made bearable by running it in screen under a new user that was accessible through ssh keys — it worked very nicely. I had it running with a web interface called wtorrent.
But then yesterday I got very needy and demanded that it used IPv6 to connect to others. Sadly it fails to do that. Don’t know if it’s a configuration problem or simply because the author doesn’t have enough time to fix it. I tried the latest development builds and compiling it with –enable-ipv6, but it doesn’t seem to listen. In other words: time for a new client.

So after some searching I ran into Deluge. It seems to fulfill all my requirements, so I decided to give it a shot. A few bonus points are immediately earned because Deluge uses the more commonly used libtorrent, not to be confused by the other libtorrent that rtorrent uses. The bonus points are because the rasterbar libtorrent has plugin support among things and in general is a bit more up to date on the whole torrent protocol as far as I can tell. (makes you wonder why rtorrent doesn’t use it).
Time for installation!
Slackbuild had no problems chewing through libtorrent and spitting out a nice slackware package. However, Deluge is built in python so some manual work to get a package from it. (I seriously need to get some time to work on slackbuild to support this stuff).

Voila, a nice package. After installing it, and creating a new user for it, it was time to see if it would work in daemontools.
However, I didn’t check any dependencies so trying to run the deluge program failed:

Meh, xdg… fine. Fortunately python has easy_install as perl has cpan, so I installed a bunch of required things for it (like twisted, pyopenssl, chardet, mako). For xdg easy_install didn’t work though, so I handed it to easy_install using this url. After this it started up, even in daemontools! Another success.
For those who are interested, my daemontools run file looks like this:

You obviously need to adjust the paths and interface and whatnot to your own ideals
After starting it for the first time it created some configuration and state files and is now waiting for connections. Woohoo.

So now, how do we connect to it? Seems like the web interface isn’t running yet. This is because deluge uses a client/server model where the daemon does
all the work, but it doesn’t deal with the interface side. So to run the web interface we have to start a separate deluge process. Let’s also put that in daemontools:

After firing this one up you can connect using your browser on port 8112. Default password is deluge. After logging in you get the connection manager which shows the running daemon that you started up earlier. (or at least, that’s what it did here):

Deluge Connection Manager

So what things are missing in the vanilla Qmail 1.03 package?

• IPv6 support
• A ton of antispam features like SPF, DomainKeys, MFCHECK, etc
• Authentication support
• Filter support for stuff like Spamassassin, ClamAV, /dev/null
• Virtual domains

Probably more, but these are things I care about. Some of these points are not entirely true, for instance you could add filter support by mangling the .qmail files for all users, but these are things you want centralized so all things have to pass the filter, not for only a few accounts.
In order to fix the missing features I use a few things.
First of all: John M. Simpson’s combined patch. This patch fixes more than half of the list. It’s a collection of smaller patches all rolled together in a nice patch that cleanly applies to qmail 1.0.3 as supplied by D.J. Bernstein. Thanks a lot to Mr Simpson! His pages also have a lot of notes and scripts on how to get qmail up and running, and how to run the services from daemontools. You might want to check them out.
Next, I use vpopmail to handle the virtual domains problem. Together with qmailadmin they make the virtual domains thing very easy.

Anyway, that is all old stuff. New stuff is having Qmail working correctly using IPv6.
It’s easy to get it up and running, basically just compile qmail as usual and patch ucspi-tcp using Fefe’s IPv6 patch. Make a few new qmail-smtp services for the IPv6 enabled addressses and go!
While this does work for receiving mail, it fails for a few things in the combined patch – like SPF checking.
You will run into stuff like:

Obviously this is a lie, but at least it’s dealt with gracefully. However, you want SPF checking for the IPv6 address!
Fortunately, Brandon Turner has patched this with a patch that applies to Qmail 1.0.3 when already patched with John’s patch. Enough patches for you?
After recompiling and restarting your services you will see that it works now. Thanks Brandon!

What does Slackware have to do with this?
Nothing, I just like the way it runs the qmail services :-p

Easy. Make sure ip forwarding is enabled though (check /proc/sys/net/ipv4/ip_forward, it should be 1) , and for IPv6 forwarding you need to enable /proc/sys/net/ipv6/conf/all/forwarding. Note that you must enable it on the -all- directory, only enabling it on a single interface won’t do what you’d expect (this took me a while to figure out ).
After requesting both a set of IPv4 and IPv6 addresses I stumbled upon Xen’s /etc/xen/scripts/vif-route script which doesn’t do anything with IPv6! Since I do want my IPv6 space routed to my domU (and probably to the others as well) I decided to molest the script a little. My modification assumes you provide both the IPv4 address and IPv6 range you want to use on the domU. Here’s the diff:
xen 3.4 vif-route patch to support IPv6 - Version - SHA: e82dd95b8725c326121603fbd6168b3f88f5b881
Note that my patch adds some extra logging as well, you can hack that out yourself if it annoys you.
If patching is too difficult for you, here’s the patched vif-route script:
Patched Xen 3.4.1 vif-route to support IPv6 - Version - SHA: 29a28f4a8cff787233c1163435c86730fd5346fa

Don’t forget to put your IP addresses in your domU’s config file:

After patching vif-route and enabling the script in xend-config.sxp you still have to set routes to the dom0 in your domU. Example for dom0 with 192.168.1.1 and 1234::1

Now it works (unless you did something stupid of course)

Simple question:
“Where in /proc can I find a list of IP addresses with corresponding interfaces?”

Simple answer:
Try /proc/net/if_inet6!

… that’s great…. but I really wanted the IPv4 addresses as well.
“/proc/net/if_inet4″ or “/proc/net/if_inet”? Noooooo….

Conclusion: KANKER LINUX!

Obviously I can get the address by calling ‘ip addr show‘, ‘ifconfig‘ or a heap of other solution involving calling ioctl on sockets or using the netlink interface… but seriously, blegh.

The most retarded thing is that pretty much every other statistic about my network devices is there… including active connections and whatnot, but ipv4 addresses? Nooooo….. *RAAH*