A good day //at 23:32 //by abe

Today was a good day — at least if I average all the things happened today. And since Twitter.com is currently down and there’s no way all those things fit in 140 characters, I decided to pack them in a “short” blog post:

• This afternoon one backplane of our newest backup server caught fire. :-( No collateral damages though. :-) The machine is currently at the manufacturer and should be back on Monday.
• My EeePC (more about it in an upcoming blog post) recently overheated and switched off. It looked as if it since then didn’t turn off correctly anymore, but power and the fan stayed on although the operating system was shut down. Today I found out with help of the debian-eeepc-devel mailing list that my EeePC wasn’t damaged but the snd_hda_intel driver caused the machine to not shut down correctly. One rmmod line into /etc/default/halt and it shuts down perfectly and fast again. :-) See also the hint in the Debian Wiki.
• Even more: I’m sure that it not even has been turned by being hit by something through its neopren bag inside my backpack as I initially expected. It turned out that I must have not noticed that it wasn’t properly shut down and put it in the neopren case in that condition :-( since the power button simply doesn’t work when the lid is close. The good news: It doesn’t seem to have carried away any damage. :-)
• I had the same problem as Beat had: I couldn’t import certificates into my Nokia E51 mobile phone. I already tried to import the PEM and the DER versions of the CAcert root certificates but it just didn’t work. After Beat found out (Kudos to maol who pointed me to Beat’s blog posting), which certificate format is necessary, I found out that while the CAcert PEM certificates have the correct Content-Type header (application/x-x509-ca-cert) the DER certificates have not — they are served as text/plain. Downloading them to my server, adding the right content type to the config and downloading them from there again with the mobile phone worked fine and I now don’t need to acknowledge anymore the certificate of my IMAP server each time I want to read my e-mails on the mobile phone. :-)
• One more EeePC thing. During a discussion on the debian-eeepc-devel mailing list, I noted that the maximum summed up resolution of the internal and external display seems to be 800×800, but it turned out that you can configure that in your xorg.conf. :-) The screen section of my xorg.conf now looks like this:

  Section "Screen"
          Identifier      "Default Screen"
          Monitor         "Configured Monitor"
          SubSection "Display"
                  Virtual         2048 2048
          EndSubSection
  EndSection
  

  See also the xorg.conf in the Debian Wiki.

So if I sum up the smileys in this blog posting, I get 5 happy ones and only 2 sad ones. I think being happy outrun being unhappy today. ;-)

Now I want to dive into my bath tub to get this smell of burning servers off me and my cloths. ;-)

Nice Shell Bloomer //at 16:39 //by abe

While looking for users which still have “.” in their path, I found the following nice bloomer:

PATH=``$PATH:.:$HOME/bin''

It’s obvious what the user tried to do. But why the fuck does this (more or less man or info page alike) quoting syntax work?

It took me a moment to realise that this kind of “quoting” works in nearly all Unix shells: The two backquotes as well as the two single quotes become an empty string and are therefor completely useless in this case.

The user probably read some uglily localized man or info page (like the German ones in Debian Sarge) and did some copy and paste to his .bashrc. And since it “worked” he didn’t see any reason to change it again.

Fedora Legacy useless? //at 15:16 //by abe

For a (much too long) time, we ran our three AMD 64 bit virus scanners and spam filter boxes with Fedora Core 4. Since the the official support ended a few months ago when Fedora Core 6 Test 2 came out, so we decided to switch them over to support through the Fedora Legacy Project.

For testing purposes we first switched over one of the three boxes. But the test failed: Although the changes (as documented on the Fedora Legacy home page) seemed to work fine, not a single update came until the end of last week, even though there were partially remotely exploitable security issues in OpenSSL, OpenSSH, gzip, etc. during that time. There were also no announcements on the list since FC4 switched over to the Fedora Legacy Project, not for FC4 nor for any other distribution maintained by the Fedora Legacy Project.

So what the heck does the Fedora Legacy Project if not security updates?

I would be very happy if I could switch over those boxes to Debian or even Ubuntu, but there’s no BiArch support (running 32 bit applications on 64 bit operating systems transparently) in Debian (and therefore neither in Ubuntu) yet without a lot of manual fiddling and chroots, so we can’t run our 32 bit virus scanners on those 64 bit boxes with a debianesk operating system yet.

Today we’ve upgraded the last of those three boxes to Fedora Core 5.

Fixing server bugs on client side //at 15:35 //by abe

On my new job at ETH Zurich I stumbled over a lot of HTTP requests in the web server log file, obviously trying to fetch the automatic proxy configuration file (usually called proxy.pac) but requesting it with the last character missing and therefore requesting the nonexistent file proxy.pa:

195.176.XX.AB - - [16/May/2006:11:12:56 +0200] "GET /proxy.pa HTTP/1.1" 404 5261 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
195.176.YY.CD - - [16/May/2006:11:16:32 +0200] "GET /proxy.pa HTTP/1.0" 404 5235 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
195.176.ZZ.EF - - [16/May/2006:11:18:38 +0200] "GET /proxy.pa HTTP/1.0" 404 5235 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
195.176.YY.CD - - [16/May/2006:11:24:16 +0200] "GET /proxy.pa HTTP/1.0" 404 5235 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
195.176.ZZ.GHI - - [16/May/2006:11:31:44 +0200] "GET /proxy.pa HTTP/1.0" 404 5235 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
195.176.XX.J - - [16/May/2006:11:33:35 +0200] "GET /proxy.pa HTTP/1.1" 404 5261 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
195.176.ZZ.LMN - - [16/May/2006:11:35:18 +0200] "GET /proxy.pa HTTP/1.1" 404 5261 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"

WTF happend here? When I found a bunch of those request from a single host last night, I expected a local cut and waste typo on a single box. But during the day I got the same sort of defective requests from over 30 hosts in our network. So we looked at our dhcpd.conf, but all appearances of “proxy.pac” had its “c” at the right place.

WTF is happening here? After googling for a moment I found this mail on the squid users mailing list, stating the following:

WPAD worked reasonably well for WindowsNT and Windows2000; however, there was a problem with the file name in Windows2000 and the initial release of WindowsXP. The Microsoft DHCP Service returned the wrong byte count for the string returned for option 252. The DHCP Client compensated for this by decrementing the string length. This resulted in the file name being truncated when the ISC DHCP daemon was used. The solution was to define a symlink proxy.pa –> proxy.pac.

So in other words: Microsoft worked around a off-by-one bug in their own DHCP server by patching their DHCP client to parse faulty configurations — and obviously only faulty configurations by expecting some length statement to be always off-by-one. *hrrrrng*

Our solution was BTW to insert an appropriate Alias directive into our Apache web server hosting the file.