Got home from a party Sunday morning (at 0800, after a party), checked my mail and there were my plane tickets. Opensourceworldconference, here I come!

I think I have done one of the most hairy installations of Debian ever today. The situation: a host with a MegaRAID card, remotely, behind a firewall, to get Debian installed. No serial console.

First, you ssh through the firewall. Then you ssh to a machine on the internal network and run rdesktop to another internal server. From that rdesktop session, you run Internet Explorer and connect to the internal management card on the machine to be installed and get a text console through a Java applet.

Ok, so now you have a connection to the machine to be installed. It has its Debian CD in the CD-ROM player. Reboot the system, boot it, using video=vga16:off, since the text console doesn’t handle the frame buffer at all. Once it’s up, we chose Norwegian keyboard. Of course the installer doesn’t find the megaraid card. Out to a shell, and because of the choosing of a Norwegian keyboard, / is nowhere to be seen. After searching a bit around and mounting /dev/hda at /dev/a we did recover the slash. So, after discovering that being able to unpack the 5.7MB big drivers.tgz somewhere, we decide to reboot with a different ramdisk_size. 64MB is good.

So, reboot, repeat the procedure, though this time with American keyboard instead, since it actually works (and is a norwegian keyboard; something is clearly wrong somewhere, but sometimes two wrongs make a right). mkfs.ext2 /dev/ram1, mount it at /tmp2, unpack /cdrom/dists/stable/main/disks/current/bf2.4/drivers.tgz to /tmp2, unpack modules.tgz in there again, insmod the megaraid module (which is in /tmp2/lib/modules/2.4.18-bf2.4/drivers/kernel/scsi/megaraid.o), do the install.

So far, so good, I thought. Of course I was wrong. The kernel installed didn’t have initrd with the megaraid driver on, nor were it compiled in, so back to square one: boot with huge ramdisk, unpack drivers.tgz from the cd, unpack modules.tgz, insmod megaraid, mount /dev/sda5 /target. Then, chroot into /target, fix up sources.list, install a kernel, make sure the lilo config is correct, then umount everything and reboot again. Woo, it works.

I overslept class today, so I decided to stay home and do some useful work instead. So, I managed to upload a new version of Mailman and Apache2, this one seems a bit better than the last one, at least svn still seems to work. Woo.

I was supposed to do an Apache 2 upload today, but due to work taking a bit too much time, I ended up not having the time to do it. Been hacking apache all afternoon, though not the Debian part of it, just configuring and fixing it up; it sure is a complex beast.

Had a drift meeting on IRC where we discussed the crack of epsilon last week. Good to have everybody catch up. After dinner, I upgraded Advertpro and run the evil localhost proxy hack on the forum, which should speed it up somewhat. Also fixed up various other small stuff. Tired now. Sleep.

Writing multiarch proposals seems to be this week’s most popular sport. I’ve written my own proposal. This one should address most issues people have, without pissing off anybody too much. We need a was to say “this package depends on this package with this architecture”, but apart from that, my proposal seems fairly solid. (At least nobody’s been able to really pick it apart yet.) It doesn’t attack my sense of aestetics either, unlike some of the other proposals.

The ad system running on zeta.hardware.no was changed today from Advertpro running under mod_perl to a Tomcat based Java system. Seems to work fine so far, though I seriously dislike Tomcat’s XML based config files.

elmo prodded me on IRC that my mail host was refusing spam with a “550 Message classified as spam”. While this is correct, it causes double-bounces to go to postmaster@debian.org, which is unintentional. At Samfundet we have a setup which doesn’t bounce spam sent to lists, it just accepts it and nullroutes it. I don’t think that’s the right way, but it’s better than annoying postmaster@debian with bounces.

I’m using exim4, and this is how I solved it. I replaced my normal spam-bounce rule:

     deny message = This message was classified as SPAM
       spam = nobody:true
       condition = ${if >={$spam_score_int}{100}}{1}{0}}

with:

     deny message = This message was classified as SPAM
       spam = nobody:true
       condition = ${if and {\
                 {!match{$recipients}{tfheen@err.no}}\
                 {!match{$sender_address}{tfheen@debian.org}}\
                 {>={$spam_score_int}{100}}\
                 }{1}{0}}

     warn message = X-err-Devnull: spam
             log_message = Eaten by spam filter \
                         (score=$spam_score, req=10.0)
             spam = nobody

In addition, a special router is needed; mine is called 50_err_devnull:

# A special driver that redirect "X-err-Devnull"-ed mail (spam and
# virus sent to mailing lists, see the DATA ACLs) to /dev/null

err_devnull:
        driver = accept
        condition = ${if def:h_X-err-Devnull: {1}{0}}
        transport = devnull

Finally, the devnull transport:

# Archive the mail in /dev/null
devnull:
  debug_print = "T: devnull for $local_part@$domain"
  driver = appendfile
  file = /dev/null

This is a bit hard-coded and could probably be fixed a bit better, but it seems to work fine for me, at least.

amd64 and multiarch seem to be the hot topic of the day. I’ve been trying to chase down something which I thought was a linker bug. Of course, it wasn’t a linker bug, it was a silly assumption somewhere in gcc. Or, at least I like to believe it is, since else it’s a bug somewhere in my lib64c6 package. Anyhow, lib64c6-dev and lib64c6 are almost ready; there are always some bugs which creep in at the last moment. Upgrading gcc seemed to fix my problem compiling binaries.

Most of my evening has been spent discussing how to do 64 bit packages should be implemented. The consensus seems to lean towards having lib64foo and libfoo packages for amd64 and i386 respectively. How to fix the -dev package problem is yet to be decided.

I got tired of trying to fix my IPv6 tunnel broker, so I did a clever hack instead. On ip-up for my ppp0 (I’m running DSL with PPPoA, probably one of the very few people in Norway doing that, but nevermind), I ssh into the other tunnel point and set up the tunnel through that. After spending a few hours trying to get my gateway to forward packets from my laptop through the gateway, I managed to lock myself out of it. After a little more fiddling it just worked. Weird. If I’m able to find a fcdsl module which works under 2.6, I’ll try using that instead.