“peer holds all free leases” on both DHCP servers //at 15:54 //by abe

At work we run a pair of ISC DHCP servers running Debian Lenny in a classical ISC DHCP failover setup which provide DHCP service to several subnets, some only with static IPs (e.g. for printers) and some with half static and half dynamic IPs.

Today I got a call from a user that her laptop doesn’t get an IP despite it’s correctly registered in our MAC address database from which we generate the “group { }” sections of the dhcpd.conf.

Everything looked fine, but every DHCPDISCOVER package got logged in the syslog on both servers like this:

Jan  7 14:34:39 dhcp1 dhcpd: DHCPDISCOVER from 01:23:45:67:89:ab via eth2: peer holds all free leases
Jan  7 14:34:39 dhcp2 dhcpd: DHCPDISCOVER from 01:23:45:67:89:ab via eth2: peer holds all free leases

Searching the web for this error message mostly results in mails which say “If have this on one server but not the other, you soon run out of IP addresses”, but none which mentions what happens if you got them on both sides. Following a coworker’s idea of adding “both servers” to the search term, I found Debian bug #563449 (dhcp3-server: Incorrect “peer holds all free leases” log entries) which turned out as configuration error or at least unexpected configuration (machine was blocked from getting an IP on purpose) and misleading error messages.

So I checked under which circumstances this computer would not get an IP despite it had a static IP configured:

  host somehost {
    hardware ethernet 01:23:45:67:89:ab;
    fixed-address 192.0.2.123;
  }

That computer would not get an IP address in any subnet which has different IP range and no dynamic IP addresses. And even if I comment out the “fixed-address” setting, it wouldn’t get an IP in any static-IPs-only subnet either.

And *bingo*, that computer was plugged into the printer subnet which has only static IPs, e.g. in the 198.51.100.x range.

So if you get the “peer holds all free leases” error message from both your DHCP servers, chances are very high that the mentioned MAC address should really not get an IP address on this network (as it does :-). The error messages are just somewhat misleading.

Hope, this saves someone some time. :-)

NSLU2 in a Tux Case //at 18:23 //by abe

It started harmless when Thomas asked on Linux User Group Switzerland mailing list if someone knows a tux-shaped alarm clock. But the topic of that thread quickly moved to two other things in tux shape: the Tux Droid, a device similar to the Nabaztag, but needs a Linux host with USB, and ACME Systems’ Tux-Server, a ETRAX CRIS based Foxboard inside a tux-shaped case.

We found out that Telion, the Swiss importer for Foxboards, also imports ACME Systems’ Tux Case — although the Tux Case is not mentioned on their website. Even better: They had a few old Tux Cases in stock which don’t fit anymore on current Foxboards since the position of the power socket changed. (So only one hole in the case was missing.) And they wanted to get rid of them quite fast: They offered us the Tux Cases for 10 CHF (6€) each instead of 28 CHF each (17€) if we buy all of them. Of course we couldn’t reject this offer and bought all five remaining cases.

Another part of the thread was about performance. Although ETRAX CRIS is used by its inventor AXIS in many of its products (they’re famous for the Linux based web-cams) many were not sure if the board’s performance would be sufficient for their ideas. Another disadvantage of the ETRAX CRIS architecture is that no mainstream Linux distribution supports it.

Another point was the Foxboard’s price (169€, ca. 268 CHF). Bones just mentioned that an NSLU2 costs only about 100 CHF (60€).

Probably on IRC someone (probably Bones, too) wondered if it’s possible to fit a NSLU2 into such a quite inexpensive Tux Case. We took Wikipedia’s picture of the NSLU2 board, compared the size of the USB ports on that picture, compared them with real-life USB ports and found out the size of the board that way. And when I got my Tux-Case I noticed that the NSLU2 board really could fit into the Tux-Case.

Since I’m already building a bigger NAS-like home server, I have no use for another, much slower NAS. But since I more or less gave up the also ARM-based Thecus N4100, another ARM-based machine in my hardware collection wouldn’t be bad.

So it didn’t took long and the idea was born to build the NSLU2 board into a Tux-Case and let the website tux.ethz.ch run on it. (I inherited its administration from Beat and it’s currently just a virtual host on one of our webservers.) Then it would be a server named Tux, serving Tuxes, looking like a Tux and running Tux’ operating system Linux. :-)

I ordered an NSLU2 at Brack for 117.60 CHF (ca. 70€). Played around with the original firmware for a moment, but it’s horrible from a security point of view: You can’t even change the admin password (default: “admin”) if no USB harddisk is attached. And no, a USB stick doesn’t suffice. So I didn’t wait long and tried to install Debian’s “armel” (ARM, Little Endian) port on it. But the NSLU2 refused the “new firmware” with the error message “Upgrade: no enough free space.”. While this is not in the Debian specific NSLU2 FAQ, it is mentioned in the general troubleshooting FAQ. As described in there, first upgrading to the most recent firmware version and then uploading the Debian installer worked fine.

After I had successfully installed Debian Lenny on a pqi 4 GB USB sticked into the NSLU2 and verified that everything is working fine, I opened the NSLU2 case and checked if it really would fit into a Tux Case.

It does, but very, very close. You’ll have to drill some holes and the ethernet socket will stick out Tux’s shoulder, but everything else should fit perfectly after a few mounting parts inside the Tux Case have been removed. As a proof of concept I laid the NSLU2 board on the Tux Case’s back:

Pictures taken with my Nokia E51

So later the LEDs will be in Tux’ one shoulder while the network socket will be in his other shoulder. And the USB stick will be inside his paunch via a USB hub.

MicroClient Sr. //at 01:16 //by abe

About a year ago, I bought a Norhtec MicroClient Jr., a complete 200 MHz MMX-compatible SoC (“Vortex86”) PC so small that it fits into your hand or onto VESA mountings. Althought thought as thin client, the machine has 128 MB RAM and runs Debian from either netboot, USB stick, CF card or 2.5” harddisk without problems and not even that slow.

Later last year, we needed more MicroClient Jrs. at work and since the MicroClient JrSX had a 300 MHz 486SX-compatible SoC processor (“Vortex86SX”) from MSTi and 128 MB DDR RAM instead of SD RAM, we expected them at least in the same performance range and bought a few for ETH and I also bought one for myself. Well, they were about three times slower, since the FPU is missing, not all programs from Debian Etch work fine, e.g. X doesn’t work without patching and recompiling (with Sid, X works, but not the kernel anymore – Update, 26-Jul-2008: See #454776 for a solution for this problem)…

BTW: I had both machines with me at FOSDEM ‘08 at the Debian booth and the MMX-compatible machine also at Chemnitzer Linux-Tage (CLT) at the Symlink booth and in Kurt Gramlich’s talk about ecological computers. So if you saw them there, just imagine the same case, with a twice to three times faster CPU and four times the amount of RAM, but with roughly the same carbon foot-print!

For our thin client purposes at work we now use ALIX boards from PC Engines (Mini-ITX format) with 500 MHz AMD Geode processors. They’re much faster than the MicroClient Jr. and need even less power.

Today, while surfing around on some Mini-ITX shops, I found some computer in obviously MicroClient Jr. case, but with 500 MHz VIA Eden processor and 512 MB of RAM. I first couldn’t believe it. They are selling it as eTC-2500. Since eTC-2300 was one of the brandings of the MicroClient Jr. which is called eBox-2300 officially by the manufacturer DM&P, I searched for eBox-2500, but didn’t find anything useful. Then I looked at the manufacturer’s product page at CompactPC.com.tw and found the eBox-4300 — so it’s really true, they managed to fit a board with 500 MHz VIA processor and half a Gig of RAM into the already fscking small space inside the MicroClient Jr. case, and even without needing more power: Still 15W from the power adaptor. Next stop was Norhtec’s Website. And yes, they also have a new MicroClient product: The MicroClient Sr.. I really need to have one of those for my MicroClient collection! ;-)

A good day //at 17:43 //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. ;-)

First two weeks with the Brompton //at 05:12 //by abe

It’s here! In contrary to the estimated delivery time of about ten weeks, my Brompton arrived at Velofix at Saturday the 16th of February after only three weeks. The orange color is much nicer than the apple green I initially favourited from what I saw in the catalouge and the axle dynamo also proved to be a good idea, so I’m really happy about my choice.

I used the Brompton to go to work everyday the last two weeks, even when it’s snowing like today:

Although I’m starting slowly and taking the bus (hey, it’s a folding bike! :-) for the steepest parts (either from Am Börtli to Waidbadstrasse or Gsteigstrasse)… I even managed to fold the bike although I saw the bus already coming around the corner when I still was in the saddle. That was the day I was at work in less then 10 minutes — Perfect timing. :-)

Since the local Höngg bus (route 38) only makes it’s round every 30 minutes, with the bike I’m now much more flexible and don’t have to hurry in the morning to catch the bus. (OTOH I had to notice that “being more flexible” doesn’t mean “having more time”… :-)

I also use it on the campus for visits in other buildings. Although there are mostly stairs between the different levels of the campus, it’s no problem with the Brompton since it’s easy to carry, even if not folded. It’s much more comfortable than daduke’s little kickboard scooter whose hard wheels don’t feel healthy for bones and especially knees on ETH Hönggerberg’s paths made out of washed-out concrete. Air tyres and rear suspension are much better… :-)

Regarding the choice of gears: The MountainDrive would surely be helpful in hilly Zürich, especially since my fitness isn’t the best one at the moment, but 6 gears are ok, too, and will be even more ok as soon as my fitness gets better. The slower transmission wasn’t a bad choice either, although a wider transmission range would have been better.

Following Bleeding Edge Software and still using Debian Stable //at 23:04 //by abe

Many Linux fans know that Debian Stable usually already lost the “b” when it’s being released. ;-) What seems not so well known (especially not by some DesktopBSD Marketing guy at last year’s LinuxDay.at :-) is that there is really a lot of people who really like this “stale” software collection — because it’s rock solid — especially compared to the ports in FreeBSD or DesktopBSD *evilgrin* which unnecessarily follow every new feature upstream introduces. This is really annoying in a server environment where you want as less changes as possible when updates are necessary due to security issues. My personal favourites here are Samba and CUPS. *grmpf*

Although I belong to those people who run Debian Stable even on brand-new hardware, I sometimes have to use the newest beta or alpha versions of some software to get it even only running. And doing so is fun but feels strange somehow, though. Currently I follow the pre-releases of three software makers quite close, due to a new laptop:

At the beginning of last semester I bought a brand-new Lenovo ThinkPad T61 (2,2 GHz Intel Core2 Duo T7500, 4 GB RAM, 160 GB HD, 1440x900 14” Widescreen) without preinstalled operating system (possible thanks to the ETHZ Neptun Project) and installed — of course — 64-bit Debian Stable on it.

While the Debian Installer from Etch worked fine even on such new hardware, not all features worked out of the box because some components were just too new.

So the first thing I did was installing 2.6.22 from Backports.org, quickly moving farther to vanilla 2.6.23. Nearly everything I needed worked except the wireless network card. It needs the iwlwifi driver which is officially in the Linux kernel starting at the upcoming 2.6.24 (said to be released during the next few days). So I run 2.6.24 pre-releases on the laptop since the first release candidate, always eagerly waiting for either the next RC or the final release. (And 2.6.24 looks impressively stable to me — even since the early release candidates. :-)

I even got the fingerprint reader working for login and sudo (but not xscreensaver) using libthinkfinger backported to Etch from Debian Experimental. I’m just not sure if this is a good idea since the back of the screen already has enough of my fingerprints on it. ;-)

The next software of which I’m currently running an alpha version is 64-bit Opera 9.50 (aka Kestrel, available at snapshot.opera.com) because no earlier Opera version is available for 64-bit Linuxes. Here I had different experiences: The builds from October and November were already quite stable, but since December it crashes usually several times a day.

At work I also run the 64-bit Opera on my workstation, but stalled updating it when I noticed that it became so unstable. So my Opera at work has currently an uptime of nearly four weeks — and would have probably more if I hadn’t rebooted my workstation in Mid-December.

Somehow this hunting for new versions and eagerly waiting for every new (pre-)release makes me really fidgety sometimes. And my understanding for people doing this for there whole userland or even operating system has grown, but I still prefer to have stale but stable software on all my productive machines, even on my laptop — just with some few and handpicked excpetions.

The third but less thrilling thing I’m following are nVidia drivers for X. Since the free nv driver of X.org doesn’t support (and not only just doesn’t know) my graphics card yet and nouveau isn’t ready yet, I run the binary only and closed source driver from nVidia, waiting for that one release which supports Xen since I really would like to run a Xen guest with Debian Unstable for testing purposes and package building on my laptop. Until then I have to content myself with the much more unwieldy QEMU respectively KVM.

Anyway, I’m very happy with the T61 and Debian Stable and can easily connive at the few not (yet) perfect issues like missing Xen support by nVidia, broken ad-hoc mode in the wireless card, no internal card-reader (as announced in the Neptun specifications) and no native serial port.

Some useful links regarding the subject of this post:

• Linux Weather Forecast
• Opera Desktop Team
• Nouveau: Open Source 3D acceleration for nVidia cards
• ThinkWiki

Now playing: Jean Michel Jarre — Rendez-vous à Paris

Surfing on two screens? //at 22:31 //by abe

At work, I’ve got two screens on my Sarge workstation “snitch”. Since I want to switch virtual desktops independently on both screens, I don’t have a Xinerama setup but a Dual Screen setup. So my left and right screen do have different $DISPLAY (“:0.0” and “:0.1”) set.

This is neither a problem for FVWM nor xlock nor XScreenSaver. But it is a problem for nearly every modern web browser available which checks, if there’s already an instance of it running. So if you try to start a new instance of a web browser on the other screen, most graphical web browsers make more or less problems:

• Galeon 1.3 and Epiphany always opens new tabs or windows on the display where its first instance is running, i.e. ignores $DISPLAY completely except on the first call.
• Kazehakase (0.3.7) just opens a new tab in the running instance.
• Firefox 2.0 thinks it crashed and asks if it should restore tabs and windows. Haven’t tried any further.
• Opera 9.20 pops up a dialog, says, there seems already a copy of Opera running and asks if it should continue with startup. If you say yes, only the bookmarks of one of the two instances get saved, probably those of the one with the last added bookmark or the one which exited last.

The only graphical web browsers which simply just work on a Dual Screen setup are Konqueror, Links2 (called with the -g option for a GUI), Chimera 2, Amaya and of course Dillo. Unfortunately I’m neither a fan of KDE nor of Konqueror and I do want a web browser with CSS and tab support… And Amaya is, well, only a reference implementation… (Chimera 2 from Sarge btw. segfaulted on two of the four pages I tested it with. Seems to have problems with PNG images.)

So my current setup is to have Kazehakase as my main work web browser (with all the local web applications I need) on the right screen while I have Opera on the left screen for surfing, looking up documentation, testing web pages and other things.

BTW: I don’t use Gecko based browsers for surfing on that box at the moment, since there are some web pages (the spammer vandalised Kazehakase wiki for example, at least a few months ago) which manage to be rendered in such an ugly way by Gecko so that XFree86 with the binary Nvidia (at least the last five or six versions I tried) just crashes away — either at once or when you try to switch to a text console by pressing e.g. Ctrl-Alt-F1 while such a page is displayed.