Those of you who know me might be aware that I have a fondness for cool and neato hardware which is possibly a tiny bit above that of the average geek. I have more nodes on my ThinNet than on my TP network, for example. Back in February, I had the random idea to call SGI Norway and ask them if they had anything they were about to throw out. I knew that they were working hard on moving from MIPS to Itanium, so perhaps some hardware was disappearing along the way. Oslo didn’t have anything, but when I called Bergen I found out that they were about to throw out a large amount of hardware, including some really nice boxes like an Onyx2 deskside workstation, and some Origin systems. For those of you who aren’t into SGI machines, I can sum it up by saying that these are really cool computers: Big, noisy as hell, heavy, and in terms of performance, nearly on par with a normal desktop nowadays. In short, fantastic educational toys. So, this was in February, and we were making arrangements for transport to Oslo, until one day I stopped receiving mail. I didn’t think much of it; email is asynchronous, and I figured he was busy doing something else. I was certainly very eager to get at the machines, but didn’t feel like nagging at him either. Finally, recently I sent him a polite reminder, and I get the rather rude response: Diagnostic code: smtp;550 cuda_nsu 5.7.1 <****@sgi.com>: Recipient address rejected: THIS USER IS NO LONGER WITH SGI. CONTACT help@sgi.com IF YOU NEED INFO. I tried calling the Bergen office, but the number was out of service. So I call the Oslo office - and I am told the Bergen office has been shut down, and all the equipment has been thrown out. This is the bummer of the century, for two main reasons:

1. I’m not getting cool hardware that I was totally looking forward to getting,
2. Great hardware has now been ground up for use in car tires.

For some odd reason, the second reason is infinitely more grating than the first. I feel like a museum curator being forced to watch someone feed a Picasso painting to a paper shredder. This really, really screwed up my day.

It might happen that you (I mean you, gentle reader of this blog) being a Debian developer or maintainer, just receive one of my numerous "Intent to NMU to fix pending l10n bugs" or "Announce of the upcoming NMU of ". The first gives you 10 days to react....then I send the latter which opens an 8 days translation update round. In such case, as the carefully written template for these (pretty long) mails says, please DON'T immediately upload. Speak to /me instead so that we coordinate the translation update round. That will also allow me to send you possible QA enhancements I found in your packaging while trying to build your package *and* translators to send more material. Some (rare) maintainers just uploaded immediately after getting these mails and they're now getting what could be expected: they're receiving new translations...and are then likely to be catched pretty soon by the patrol, again..:-). The "intent to NMU" mails are sent to the i18n mailing list and some translators find this to be a good opportunity to send translations in their language (that's why Finnish, Galician are for instance climbing up pretty quickly in statistics). The main intent of these NMUs is to get updates done, not doing NMUs so, of course, I will welcome uploads...it is however more efficient to coordinate them.

Recently, we’ve been getting a lot of the following on our IRC channel: <intangir> well xmms could do it
<intangir> and now xmms is no longer being updated
<intangir> its just been taking out of new debian and ubuntu repos ;(
<intangir> so audacious is the only thing that is close
<intangir> it must fill the void! This is incorrect for a number of reasons, I am sorry if your distribution or the internet has made you believe that we are some magical successor to XMMS. This is not the case. Furthermore, calling us a “disgrace to open source” because we have no interest in being like XMMS (even the winamp2 skins are due to be leaving at some point), does not make us want to help you. Now, why do people think Audacious is not acceptable replacement to XMMS? Well, not all people do, it’s more of the 5% of people who have specific use cases not covered in Audacious. Clearly if Audacious was not suitable, a lot of people would be blogging about it. Instead, we only see a few people blogging about it. However, that said, I think Audacious’s focus is probably not the right focus for an “XMMS replacement” solution, and I have a plan for that (although once I finish writing it, someone else will likely be maintaining it, as I don’t really care enough). More on that later.

I just uploaded openbox-3.4.7-2 to Debian unstable and wrote a patch that enables to set next or prev to the monitor attribute of the MoveResizeTo action. Without this patch you need to explicitly set a monitor number you want to send a window to but can't just toggle a window from one workspace to the other with one keybinding or to move it to the next/prev if you have 3 or more monitors. So if you use openbox with a xinerama setup it would be nice if you could test that and report bugs in case of errors.

A keybinding for that could like like:

I just uploaded openbox-3.4.7-2 to Debian unstable and wrote a patch that enables to set next or prev to the monitor attribute of the MoveResizeTo action. Without this patch you need to explicitly set a monitor number you want to send a window to but can't just toggle a window from one workspace to the other with one keybinding or to move it to the next/prev if you have 3 or more monitors. So if you use openbox with a xinerama setup it would be nice if you could test that and report bugs in case of errors.

A keybinding for that could like like:

On their "get the facts" site (as if), Microsoft recently posted a set of screencast demonstrating how much "easier" it is to install Perl and PHP on IIS than it is on Linux. Being bored, I had a look at these screencasts. The first covered installing stuff on Windows; in a 5 minute screencast, they first explain how you install ActivePerl, and have it handle perl scripts for a webserver through a CGI interface. This involves way too many steps to remember for me (including clicking through a wizard, going to the IIS management interface and enabling it, creating a directory and enabling that in the IIS interface as a CGI location, and more). Next, they do the same for PHP. Since they install PHP as a CGI binary rather than an ISAPI module, the setup isn't as complex—they conveniently reused many of the settings they'd done for perl—but it still required quite some steps. After having watched this screencast, I was wondering how they'd make it look harder on a Linux system. My guess was that they'd use Slackware and would compile apache, perl, and php from scratch or some such. That didn't turn out to be the case, however. They used ubuntu. To make the process look complicated, they refrained from using synaptic, instead opening an (almost full-screen) shell window, in which they use apt-get to install the libapache2-mod-php5 package. They conveniently also first installed the wrong version of apache, so that it would do all kinds of magical and confusing things. Really, however, after having installed this package, everything works—and they show that. The perl step should have been ignored. After installing apache on Debian or any of its derivatives, such as Ubuntu, support for Perl CGI scripts has already been installed and configured. Configuring that requires exactly zero steps. However, they still install libapache2-mod-perl, just to make it look a bit more confusing. It's not a very bad idea to do this, actually; installing mod_perl makes serving Perl scripts go quite a bit faster. But if you just want to have apache serve perl through CGI scripts, as they'd done on the IIS setup, all you need to do is install ubuntu, and make sure there's an apache installed. Period. But that's not all. They cheat. The installation of the perl and php modules on ubuntu includes the process of downloading the binaries and their dependencies; on the Windows screencast, the downloads have already been performed, and are placed on the desktop. This nicely avoids showing how you need to go to the ActivePerl and PHP websites, track down installers, download them, wait for your download to complete, and then manually start the installation process. To make things even more laughable, they install Perl and PHP as CGI handlers on Windows, but perform an installation of the same software through apache's C API. In other words, they told you how to install a fast and useful Linux system, and how to install a slow and less useful Windows installation (since a PHP setup that uses CGI will not support sessions or persistent database connections, amongst other things). And even with all that cheating and blundering, the Windows screencast still takes 5 minutes, as compared to the four for Ubuntu. I think Mahatma Gandhi forgot one line in his famous quote. It should have this:

Then they make complete and utter fools of themselves in a vain attempt to still look relevant

... right before the "then you win".

I did some 'playing' with Hecl the other day, to see what it might look like if implemented in a slightly different way, and I thought I'd share what I was thinking about. Keep in mind that

1. I haven't thought this through completely:-)
2. It's not something I'm going to just rush out and do in the near future. It's definitely a Hecl 2.0 sort of idea.

My notion was to make use of the ClassCommand feature to have at least simple types be hooked directly to the relevant Java types, and dealt with through methods, rather than commands. For instance:

$i + 10

instead of

+ $i 10

Where $i is, in the first case, a Java Integer, rather than a Hecl type. What it would be doing internally is something like this:

1. $i is recognized as the object to act on.
2. It's an Integer, so the corresponding ClassCommand is looked up and executed with + and 10 as arguments.
3. The classcommand for Integer has a + method that accepts an argument, in this case, 10, which is added to the value of $i, and returned as a new Integer.

Without a "real" (where real also means bloated, memory and space hungry) parser, Hecl is never going to have a C-like syntax - you still wouldn't be able to do foo = 1 + 2 + 3 - but this just might make a significant amount of people more comfortable with Hecl, which would be a good thing. You could do something like this:

set i 1
while   $i < 1000000    
    set i [$i + 1]
 

instead of

set i 1
while   < $i 1000000    
    set i [+ $i 1]
 

I actually built a really simple HeclInteger class that implements < and + as methods to Integer ObjectThings, in order to test out this idea, and it seems to run about as fast as the regular Hecl version. I welcome any thoughts or comments on the idea.

People rarely ask me about my amazing ability to remove fruitfly ovaries in under 10 seconds. "This skill makes me strangely attracted to you" they then inevitably fail to add, thus giving the lie to claims that a PhD in biology is a great way to impress women. In order to avoid future social embarrassment I have therefore decided to provide a step-by-step guide to removing ovaries from any fruitflies you may have to hand.

• Feed your fruitflies. Fruitflies like yeast, so give them a pile to munch on. A well-fed fruitfly is a happy fruitfly.
• A happy fruitfly is a fertile fruitfly, and has bigger ovaries. Since fruitflies are small, this makes your job easier.
• Knock your fruitflies out with carbon dioxide. When doing this, ensure that you don't knock yourself out with carbon dioxide.
• Separate your fruitflies into male and female flies. Female flies have larger abdomens and striped posteriors - male ones are thinner and have solid black markings.
• Dispose of the males. They don't have ovaries. Local laws may make it awkward for you to release animals from laboratory environments, so dump them into a bottle of ethanol. They'll probably die happy, to the extent that fruitflies can really be happy.
• Etherise the female flies. When identifying ether, try not to do so by smelling it.
• Once the female flies are thoroughly dead, transfer one to a small watchglass containing a quantity of phosphate buffered saline with a small quantity of detergent in it. Place this under a low magnification microscope.
• Grip the neck of the fly with a set of needle-nosed tweezers. Grip the very rear of the fly with another set of needle-nosed tweezers.
• Slowly move the tweezers apart. If you are lucky, the abdomen will split and you'll start pulling out internal organs. If you're unlucky, the head will come off. In this case you should move the first set of tweezers further down the body and try again.
• Continue pulling out internal organs until you find two objects that look like bunches of bananas. These are the ovaries, with each "banana" being an egg chamber containing an egg and associated support cells.
• (If your fruitfly contains no ovaries, it's not a female. Try again)
• Carefully separate the ovaries from the other chunks of tissue that are stuck to them, and transfer the ovaries to a tube containing phosphate buffered saline.
• Repeat until you run out of flies. Note that towards the end, it will become tempting to just tear the flies into small pieces rather than removing their ovaries. Bear in mind that the aim is to obtain fruitfly ovaries, not to kill flies. There are much easier ways of doing the latter.
• Dispose of the remaining bits of flies in accordance with any relevant legislation. Do not throw remaining bits of flies at coworkers.
• Fix the ovaries in formaldehyde and suspend in methanol. Freeze at -20 C.

See? It's all very easy.

(Note: This protocol involves chemicals known by the state of California to cause cancer, birth defects and general fucked-upness. Do not ingest methanol unless you want to demonstrate competitive inhibition in the form of a bottle of vodka. Value of fruitfly ovaries may go up as well as down. Do not taunt fruitfly ovaries)

It has been a long time since i posted an entry. Many things have happened. Many things have changed. Let’s summarize them. I no longer live in Finland. I moved out on January the 29th, almost exactly by the day 8 and half years after I moved there. Right now I am in Dublin, Ireland, but you never know for how long. In any case I am enjoying quite much. Not as dark as Finland in winter, not as rainy as people think it is. Yeah, it rains, but it was rainy in Finland too. And here in not as cold. I no longer work for Nokia. My employer has changed and I am enjoying every single bit of it. I have not resigned from Debian, although I have not been active for the last months. If you add the new job (hiring process), moving and settling down, you could understand the lack of time. At least I can. Now things are getting stable (I got my ADSL connected only last weekend, and my server at home with all the mail redirected only yesterday) so I am ready to restart with my commitments. Also my employer will allow me to do some Debian work, so I only need my GPG key to be reinstated in the keyring (there is a ticket for it, so I just have to wait). And finally, if you want to follow where I have been spending some of my time, follow my flickr photostream.

Recently I had to deal with POST requests on mod_perl 2 on a custom XML-RPC webservice server we have been developing and maintaining over the last year (we are actually moving it to REST some time in the middle future). It was time to move some of our base modules from a couple of CGIs to the power and muscle of mod_perl. So, while dealing with POST requests (like XML-RPC is actually specified) I faced the issue that I wasn t being able to get the POST data on the PerlResponseHandler phase. I was probably not reading it correctly, I got deeply into it and even read some libapreq source code. All I was getting was some nifty message like not supported . After reading some documentation (and, to my own shame, the Apache2::Request front page pod) I found out that the usual:

    use Apache2::Request;
    $req = Apache2::Request->new($r);
    @foo = $req->param("foo");
    $bar = $req->args("bar");

will not work on your POST if the content type is different than application/x-www-form-urlencoded or multipart/form-data. For example, say, XML-RPC! So, in case you actually need to read POST data on your mod_perl 2 handler where it s not a form or a file upload, you can read the data manually (I didn t find a simpler way to read the data, actually):

sub handler  
my $r = shift;

return Apache2::Const::HTTP_BAD_REQUEST unless
		$r->method eq "POST" and
		$r->headers_in-> 'Content-Type'  eq 'text/xml' and
		$r->headers_in-> 'Content-Length' ;

my $length = $r->headers_in-> 'Content-Length' ;

my $xml;

while ($length)  
		$r->read($xml, ($length [less than symbol] 2048) ? $length : 2048);
		$length -= length($xml);
 

	...

And you are ready for booze.

Audit your debian uploads My bank is sending me an e-mail every time I log into the home banking system, so that I can spot malicious logins. My credit card is sending me a SMS message every time it gets charged, so that I can spot mailicious charges. Can I get a notification of every Debian upload done with my key, so that I can spot if my key has been stolen? Let's work on that. As a start, thanks to Ganneff, here is how to do a one-off audit:

# go to merkel to access projectb, which is the postgresql database
# with all dak information
$ ssh merkel
merkel$ psql projectb
# look up the database id of my fingerprint
projectb=> select id, fingerprint from fingerprint where fingerprint like '%797EBFAB';
 id                  fingerprint                
    -----+------------------------------------------
     394   66B4DFB68CB24EBBD8650BC4F4B4B0CC797EBFAB
    (1 row)
# get a list of all uploads done with my key, sorted by date
projectb=> select * from source where sig_fpr=394 order by install_date desc;

First you get to do it (done); then you document it (done); then you automate it. It's quite trivial at this point, so enjoy the new Debian upload monitor. It's got search as you type to find your full fingerprint, then you get an HTML page with the log of your uploads in the last 2 months, and the page has an RSS feed that you can use to track your own uploads. Also, generating all this static content is acceptably fast:

merkel$ time ./deb-key-audit 
real    0m7.145s
user    0m4.244s
sys 0m0.384s

If you want to see the code, you can git clone http://merkel.debian.org/~enrico/keylog.git Currently it wrongly encodes UTF-8 characters: I suppose the strings come out of the database as ASCII instead of UTF-8. A patch would be welcome to fix that. I will now contact QA to see what we can do with it; if it ends up fitting in some bigger picture then it may be that the RSS links will change, but I'll post about it in that case.

As I just had the need to split up two huge mbox files by date and did not find a tool that does that easily, I thought I share what I used. Careful, it isn’t very clever, so if you use it: It comes with NO WARRANTY at all. If it eats your mail, you lost. Not my fault, you have been warned. The task it should solve reads

• split files of size 1.8Gb and 3.2Gb, all together nearly a million mails in them,
• do not use lots of memory for this,
• no need to interactively do anything,
• split based on Date: header.

There are various ways to do it, one would be to use mutt, with something similar to the following in a muttrc file somewhere

 unset confirmcreate
 set delete=yes
 set folder=/dev/null

and then a lot of lines looking similar to the following, just replacing the dates;

folder-hook . 'push "T~d01/03/2008-31/03/2008\n;s2008-03.mbox\n$%q"'

If you then start mutt using mutt -F theabovemuttrc -f themboxfiletosplit it will go and split it into the YEAR-MONTH based files. I got this way from Gerfried Fuchs, as I am no mutt user and wouldn’t have found the way to do it with mutt myself. Drawback: Mutt needs exact date entries in the push lines. Means you have to write 29/02 if you mean “last day of Februar”, a plain stupid 31/02 will be converted to 02/03. And I was way too lazy to list all the dates for the timeframe those mboxes cover. So, other solution. Ruby to the rescue! The following code does split the mbox into the files I want, based on the date header:

#!/usr/bin/ruby -w
# Split a mbox file into $year-$month files
# Copyright (C) 2008 Joerg Jaspert 
# BSD style license, on Debian see /usr/share/common-licenses/BSD
require 'pathname'
require 'rmail'
count = 0
File.open(Pathname.new(ARGV[0]), 'r') do  mbox 
  RMail::Mailbox.parse_mbox(mbox) do  raw 
    count += 1
    print "# count  mails\n"
    begin
      File.open(RMail::Parser.read(raw).header.date.strftime("split/mail-%y%m"), 'a') do  out 
        out.print(raw)
      end
    rescue NoMethodError
      print "Couldn't parse date header, ignoring broken spam mail\n"
    end
  end
end

This will go through the whole mbox and store them in split/mail-$year$ month files. It has a few things you should keep in mind, if you really want to use it:

• Spam mails often have a very broken Date header. Sometimes broken enough that it can’t be parsed. I discard the “can’t be parsed” ones, as I havent seen a valid mail with that. You might want to store it in a different file, so change the part within rescue.
• Again, Spam mails often have a very broken Date header. So you will get files for years way in the past or future. In my case I could simply delete all of them, as all of those had been spam, and I knew in which timeframe the good mails got into the mbox.

The above script took, niced down with nice -15 on an otherwise used server, about 25 minutes to split around one million mails from the above mentioned large files, with no noticable memory usage (only one mail at a time in memory). Comments: 5

I had some trouble finding out how to convert a color PDF to a grayscale one. I found a post on an Ubuntu forum giving the following recipe:

pdf2ps -sDEVICE=psgray original.odf
ps2pdf original.ps new.pdf

This works, but this has the unpleasant side effect to increase the size of the PDF and to lower the quality (for a reason which escapes me). So I looked again in the magic pdfwrite parameters, and I came up with the following solution, which works on my box (though the above page suggests it shouldn't):

gs -sOutputFile=biniou.pdf -sDEVICE=pdfwrite \
  -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray \
  -dCompatibilityLevel=1.4 Plot.pdf  /dev/null

This works fine, does not lower the quality of the produced PDF and in the case I tried even made it smaller...

There are situations where you might want to redirect some audio you're playing on your local computer to another computer's speakers, potentially in a different room, or even anywhere on the Internet. One of many possibilities to do that is to use the Enlightened Sound Daemon (EsoundD, or esd). It ships with a program called esddsp (apt-get install esound-clients) which can redirect various audio sources. First, you have to start the esd daemon on a console on the remote host (the one which should output the audio on some speaker, for example 192.168.0.xxx) e.g. like this:

  $ esd -public -nobeeps -tcp

You can do this as regular user (no need to be root) if you have the proper permissions. You also need to allow connections on port 16001 in your firewall settings. Then you can redirect audio to that daemon from another computer. In this example I'm redirecting some music using various players:

  $ esddsp -s 192.168.0.xxx:16001 mpg321 -o esd foo.mp3
  $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp3
  $ esddsp -s 192.168.0.xxx:16001 ogg123 -d esd foo.ogg

This also works fine for videos, in which case you can redirect the audio (but not video):

  $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp4

For the video player Miro, I've recently documented this in the Debian package's README.Debian file. Basically you have to edit ~/.xine/config and enable audio.driver:esd there, then start Miro with

  $ esddsp -s 192.168.0.xxx:16001 miro

Audio will be emitted on the remote host, video remains on your local PC. Some programs may also support esd natively, in which case esddsp is not required, e.g.

  $ ogg123 -d esd -o host:192.168.0.14:16001 foo.ogg

These last two weeks most of my time has been sucked into getting Python 2.5 as default into testing. That’s done now. I made use of the block uploads thingie ftpmaster implemented for the release team to use. Basically, if your package could disrupt an “almost there” transition, the upload will be rejected. The blocks were in place for 5 days, which I think it’s acceptable. As long as we don’t end blocking stuff for very long, I think we should be fine. See the end of this post for more about this. Though it was quite a bit of work, I’m very glad I took care it myself, since now I really feel I’m 100% back to Debian, after the time I spent off for health reasons. Update: Oh, and I forgot to say: having control over britney has really really helped. Thanks a lot Joerg for that.

---

Dudesconf Tomorrow I’m leaving to Coru a for Dudesconf, which is a kind of Debconf-ES. I’m giving an introductory talk to Git, a semi-lighting talk about grep-dctrl (30 min.), and (gasp) a talk about Debian packaging with a VCS. We may have a Debian Quiz as well. I’m so looking forward to it, since many people who’ll attend are amongst my most loved ones, and I already missed last year’s since I wasn’t fully recovered yet. See you there!

---

Minirok and Sevilla One of the reasons I wasn’t fully back to release management during the past 5 months or so is because I spent as much time as I had doing development for Minirok. I don’t think I mentioned here before, but I was participating in a Free Software Contest for college students organized by the University of Sevilla, Spain. Such effort finally paid off, since Minirok was elected as one of the finalists. This means next week I’ll go to Sevilla, to make a presentation of the project, and who knows what more. ;-) I’m very excited.

---

Finally, more on blocking uploads This Python 2.5 transition was the first time the block uploads feature was used, and there were a couple bumps along the way. In particular, a couple packages were blocked, when they shouldn’t have been (libqt4-ruby and evolution-sharp), and one needed package was not blocked, though Rene Engelhard thankfully spotted it very quickly (mono). The problem is it’s not completely straightforward to generate a list of all the stuff that could possibly affect the transition. What I did was to make a run of britney on an arch that had all the needed bits in place, and block all the packages that migrated together as a result of the hint. This fails in two ways:

• it can include stuff that is not needed for the transition, namely unrelated packages that happen to become candidates for testing by one of the their dependencies having migrated as part of the hint. This is what happened with libqt4-ruby and evolution-sharp.
• it can miss stuff that is needed, like packages that can migrate by themselves, so the main run prior to the hint migrates them, and hence do not show up as part of the hint, but that some package of the transition depend on. This is what happened with mono.

The second problem, though, can be fixed by parsing the excuses list and blocking stuff that some bits of the transition depends on. Easy enough. Yet, there are more cases when things can go wrong, for example a shlibs-bumping upload of a package (say, sqlite3) linked against by some package still needing a couple of builds (say, qt4-x11). For that, blocking uploads is not an option, since that’d be an insane amounts of packages that, furthermore, can be uploaded if they don’t bump shlibs, so I guess we’ll have to ask in the next release update that shlibs-bumping uploads are coordinated in -release too, at least when close to finishing a transition.

Or should I say dear Lucas? Although this is more relevant for the people wanting to talk to Lucas on IRC. I recommend to use the leading edge technology set forth in rfc 2821 and 2822 for this mode of communication. I admit this is extremely experimental technology, but it might be worth looking at nonetheless.

Please consider switching to screen+irssi, or bip+xchat, or irssi_proxy+irssi or xchat, etc. (This post and its comments has more details). It is very annoying when you ask me something while I’m away, then disconnect, and then when I finally answer you, you are not connected anymore. If I’m away and you are going to disconnect, please send your question by mail or jabber.

I installed Debian upon a new desktop machine yesterday, via a PXE network boot. It was painless. Getting xen up and running, with a 32-bit guest and a 64-bit guest each running XDMCP & VNC was also pretty straightforward. There is a minor outstanding problem with the 32-bit xen guest though; connecting to it from dom0, via XDMCP, I see only a blank window - no login manager running. GDM appears painlessly when I connect via VNC. The relevent configuration file looks like this:

# /etc/gdm/gdm.conf
[security]
AllowRoot=true
AllowRemoteRoot=true
[xdmcp]
Enable=true

The same configuration on the 64-bit guest works OK for both cases. (I like to use XDMCP for accessing the desktop of Xen guests, since it means that I get it all full-screen, and don't have to worry about shortcuts affecting the host system and not the guest - as is the case if you're connecting via VNC, etc). Weirdness. Help welcome; I'm not 100% sure where to look Anyway, once again, a huge thank you to the Debian Developers, bug submitters, and anybody else involved peripherally (such as myself!) with Debian! I love it when a plan comes together. SSL ObRandom: Where is the cheapest place to get an SSL certificate, for two years, which will work with my shiny Apache2 install? Somebody, rightly, called me for not having SSL available as an option on my mail filtering website. I've installed a self-signed certificate just now, but I will need to pay the money and buy a "real" one shortly. So far completessl.com seems to be high in the running:

• 1 year - 26
• 2 years - 49

For double-bonus points they accept Paypal which most of my customers pay with .. ObQuote: The Princess Bride