Transmission is the BitTorrent client. Period. All other implementations can go take a shower and watch the rest of the game from the bench, if you ask me ;-) (I know you didn't, but it's my blog, afterall...)

In Version 0.8.x transmission introduced a daemon, which listens on a local socket for commands such as adding, starting and stopping torrents. This means, you can simultaneously download multiple torrents from the terminal (you can't start multiple instances of the  'normal' commandline version of transmission, as they all will try to compete for the same port). This comes in handy if you want to download torrents from a remote server (which most likely will have a much fatter pipe to the internet than your desktop machine or notebook).

There is a FreeBSD port for Transmission, but it disables the daemon by default (and the maintainer has told me, that he's not interested in adding or supporting that feature), so I decided to build it manually. This is actually pretty straightforward: just run the usual `./configure ; make install`, bingo! Exce-hept... Transmission uses autoconf to generate its initial configuration. And getting autoconf was the hardest part here for me. In the end it just boils down to installing these packages first, before executing Transmissions `autogen.sh`: libtool15, automake19, autoconf261 (all located in `/devel` in the ports tree).

After installation you can now simply start transmission-daemon (no further parameters necessary, it creates its socket in your home directory and you can - and should! - run it without elevated privileges). You can now user transmission-remote to add torrents and monitor and control their progress. For now, this already makes for a big improvement in regard to my (modest) torrent usage, but I've already written a python client library for transmission-daemon and am now toying with the idea of writing a grok based web fronted for it... anybody interested, perhaps?

Today, the Zope instance hosting this site experienced frequent crashes (as in "every couple of minutes) in the form of coredumps of the zope process. Stumped, bewildered, frustrated and near tears I did what I always do in such cases: pour my little heart out on #plone ;-)

Sure enough, help was at hand. And today's tip of the hat goes to... drumroll... lurker, who alerted me to the fact, that python needs explicit 'huge stack' suppport on FreeBSD. A bit of googling supported this view and so I reinstalled python from the ports, but first ran make config and then enabled HUGE_STACK_SIZE:

After that I ran a few stresstests with ab and the instance easily withheld several thousand requests for the front page. Why this option isn't enabled by default is beyond me. So keep that in mind, kids, when you install python on your BSD boxen: size does matter ;-) (As if the term 'huge stack size' wasn't already obscene enough without such a foot-in-mouth reference...)

To run PostgreSQL in a FreeBSD jail you need to enable security.jail.sysvipc_allowed via sysctl in the jail host. i don’t know how often I have already forgotten this…

Personally, the snow sprint started off with a bit of a shock. Upon arrival at the location I did two things: try to post a blog entry and check my email. First I find out, that I can’t post any blog entries – plone ignores the changes?! At the same time I got email from three clients who report that they can’t edit any content on their plone sites – which, incidentially, are hosted on the very same machine as this blog…

The symptoms (listed to increase the likelihood of somebody experiencing them finding this entry ;-) were that editing or creating any content object in plone that involved a certain amount of data would fail: either the creation would fail with an error message regarding missing data (a.ka. "Title is required") or the modification would just result in an actually unmodifed object and Plone lying out of its teeth claiming, that all changes had been saved.

Luckily I was in the best possible company imaginable to solve such a problem ;-) Matt a.k.a. Hammertoe was kind enough to help me narrow down the problem. Pretty soon we had isolated it to Apache, rather than Zope or Plone itself. Luckily Matt had encountered a very similar problem and immediately remembered, that it was due to a bug specifically in apache version 2.55. Which made sense, because we upgraded our apache just a few days ago…

Fortunately the bug has already been fixed in the trunk and in the 2.0.x-branch. The remaining problem was then to build the new modules specifically on FreeBSD. For future reference (who knows when that will come in handy!) here are the steps:

• cd /tmp
• svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x
• cd /usr/ports/www/apache20
• make clean
• cp /tmp/2.0.x/modules/proxy/* work/httpd-2.0.55/modules/ don’t replace the folder as that would remove the config information – just copy the files from svn into the proxy directory!
• make deinstall ; make reinstall
• sudo /usr/local/etc/rc.d/apache.sh restart
• write emails to client informing them, that problem is fixed
• post to tomster.org

Thanks again, Matt for the hand-holding ;-)