Goodbye Woody, Welcome Sarge (Penultimate Part) //at 16:17 //by abe

Since security support for Woody ceased recently, and with Kazehakase I’ve found a reasonable successor in Sarge for Galeon 1.2.x, I’ve dist-upgraded my 10 years old Pentium I ThinkPad bijou to Sarge this weekend. Even the XFree86 4, which made so much hassles in Woody by not regcognising nor configuring the graphics card correctly, worked fine from scratch. Well, at least after installing xfonts-base and xfonts-75dpi — the -transcoded versions somehow gave only the error message “default font ‘fixed’ not found”.

So goodbye Galeon, goodbye GNU Emacs 20, goodbye XFree86 3.3. I hope, I won’t miss you. Only my desktop gsa at home still runs Woody, but will be dist-upgraded soon, too.

What though still stayed on my laptop from Woody is Siag Office, since there is no adequate replacement for such a nice office suite with such a low resource footprint.

But it has also an impact on the talks I hold. I held all talks with a patched version of lynx (e.g. with LSS support) as presentation tool on that laptop because initially I didn’t get X running on that box. What started as a makeshift became my hallmark…

But I didn’t manage to get Sarge’s lynx patched so that it gives me the same output as my old version did. So either I would have to reoptimise the layout of my talks for a new lynx version or just start with something new.

Madduck recently showed me python-docutils, which he uses for presentations. Maybe I’ll use that although I have a severe aversion against Python. So it may also be that I’ll stick with WML, but get some new ideas from python-docutils how to use HTML for presentations.

Update: Found out that the interesting part of his presentation technic wasn’t python-docutils but S5: A Simple Standards-Based Slide Show System which in entirely written in XHTML, CSS and JavaScript. S5 is really cool stuff, one of the first cases of useful use of JavaScript, and will surely be used for my next presentation — with Debian Sarge and Kazehakase on a Pentium I ThinkPad. ;-)

Dynamic vs Static Network Configuration //at 16:03 //by abe

A guest researcher today called us, because his laptop with Fedora Core 4 didn’t get any working IP address. That problem was solved quite quickly: The “Internet Connection Wizard” didn’t allow him to choose a dynamic configuration via DHCP. It was greyed out and the static configuration was one for a private 192.168.* network.

I quickly found out, that “Network Device Control” allowed us to switch to DHCP. After deleting /etc/resolv.conf, it also got the right DNS servers.

But whatever I restarted, it didn’t set a default route although it did get one by DHCP and had it documented in its lease file.

After about one and a half hour of debugging configurations and network configuration scripts I found out, that if the environment variable $GATEWAY is set, it ignores the one given by DHCP. Then I grepped for GATEWAY in the config file. But I just found the default gateway configured for the old, now greyed out static IP configuration.

Although I told myself “No, it can’t be!” I commented out the default gateway of the now unused static configuration. And yes, I wasn’t mistrustful enough about Fedora: It worked. You really have to change parts of the not selected static IP configuration to make the selected dynamic one to work.

Thanks, Fedora! *bangingtheheadontothetable*

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.

Parfüm im Kneipenklo //at 15:34 //by abe

Nachdem ich gestern einem Freund beim Umziehen half, lud er mich im Anschluß zum Essen ins Cheyenne in Oerlikon ein. Das “Goat Cheese Foccacia” mit Grillgemüse war extrem lecker und auch sonst schien das Lokal ganz nett. Bis zu dem Moment, an dem ich mir auf der Toilette die Hände waschen wollte…

Wie so üblich in nicht-privaten Toiletten greift man zu dem Behältnis rechts neben dem Waschbecken, drückt daran auf irgendeinen Knopf und bekommt dafür ein wenig Flüssig- oder gemahlene Seife auf die Hand. Aus diesem Spender kam allerdings extrem wenig und sehr dünnflüssige Seife. Also halt noch ein paar Mal draufgedrückt und Hände gewaschen.

Hmmm, irgendetwas stinkt hier bestialisch. Und zwar nach Parfüm. Und besonders viel taugen tut die Seife auch nicht. Und wieso ist links neben dem Becken nochmals ein anderer Seifenspender? Ich schaue mir den Spender rechts vom Becken nochmal genauer an. Vielmehr als ein französisch klingender Firmen- oder Produktname scheint nicht draufzustehen. Doch, da unten, eine URL: www.$firmenname-parfum.ch. Parfüm? Ja, spinnen die denn? Ich rieche an meiner rechten Hand und mir wird fast übel.

Ich habe dort dann mit der richtigen Seife meine Hände mindestens dreimal gewaschen, aber ganz weg wollte der Gestank trotzdem nicht gehen. Zuhause habe ich dann als erstes meine Hände nochmals mit parfümfreier Seife und einer Fingernagelbürste mehrmals gewaschen. So langsam kann ich meine rechte Hand wieder riechen (bzw. nicht mehr riechen, je nach Sichtweise ;-).

Offen bleibt jedoch die Frage: Was in aller Welt treibt einen Kneipenbesitzer dazu, einen Parfümspender, auf dem nicht einmal draufsteht, daß es ein solcher ist, auf der Herrentoilette zu installieren? Und dann auch noch an einer Stelle, die typisch für Seifenspender ist? Am liebsten würde ich ja denjenigen, der das verbrochen hat, solange in Parfüm baden, bis ihm schlecht ist.