Zugschlusbeobachtungen

I apologize for inadvertently password protecting last night's article about Nagios, Parent Hosts and traceroute on the Internet. Somehow, my Iceweasel has the firm opinion to enter my Blog's admin password in all form fields labeled "password" on blog.zugschlus.de, and the article entry form happens to have one like that. And last night, I forgot to delete it. Sorry.

Thanks to mika for making me aware of that.

Nagios has the - very useful - feature of "parent hosts". If it deems a host A being down, it first checks its parent host, B, and reports A only as down if B is up. This goes back recursively until a host with state "up" is found and only the first "down" host is actually reported. This keeps on-call people from being bombed with alerts in case of major network outages and makes sure that the alerts that are actually sent out do reasonably accurately describe the actual outage.

As an individual who has some "external" servers in various data centers on the Internet, I would like to not be alerted multiple times that my servers at ISP C, D, and E are down if there is an outage at the ISP F hosting my Nagios installation or at one of the various exchange points temporarily rendering the servers unreachable (without me being able to do anything).

The solution sounds easy but is surprisingly hard.

This is the third installment of my article about the Serial Console Server for the Poor. First installment here, Second installment here.

The first part of the article having covered the hardware and the udev part creating the device nodes, and the second part explaining how to solve the software part using ser2net, this part explains why ser2net was ditched in favor of cereal and how the console server operates with cereal now.

This is just a small reminder (for me and others) that Debian is currently migrating from console-tools to kbd (back again, yes, those who have been around for a few years remember).

This information is obviously a closely-guarded secret. Console-tools is still Priority: important, and kbd is still Priority: extra. However, kbd seems to be much better maintained (current uploads happening, while console-log has seen its last maintainer upload two years ago), and unfortunately, neither package description suggests which package is the way to go. And Debian-installer still installs console-tools by default.

However, a few bugs were filed a year ago by the console-tools maintainer to drop console-tools from depends as console-tools is going away. So I guess that he knows what he's doing...

Before I get around to adding console-tools back to console-log's depends (as I almost did accidentally), I'll better blog this to remind people of console-log going away. Maybe we'll get the Priorities changed just in time for lenny.

This is the second installment of my article about the Serial Console Server for the Poor. First installment here.

The last part of the article having covered the hardware and the udev part creating the device nodes, this part addresses the part of the software that connects the user to the device node.

The serial port is still the way to access network components out of band. It is slow, but reliable, and remarkably well standardized. It does not have technical whiz-bangs that can fail when one needs things to just work. That makes it the natural way to access critical infrastructure and still being sure that this access vector still works when most other things are down.

Every communication link has two sides, so there is a market for devices with a network link and a bigger number of serial ports to connect the actual devices to. Commercial vendors have a broad choice of serial console servers. Most of them, especially the small products with five to ten ports, are quite expensive, so I have been investigating how do build a serial console server with el cheapo hardware.

Today, I had the opportunity to try my UMTS initialization mechanism that I built this weekend with more recent hardware, a newer Option Globetrotter 3G Express Card with Vodafone branding (reporting itself to be a "Globetrotter HSDPA Modem" with Vendor ID 0xaf0 and Product ID 0x6701). To get the card connected to my test Notebook, a hp compaq nc8000, I had a "Expresscard in a PC card slot" adapter and a passive "Expresscard at a normal USB port" adapter. The USB adapter had cost about ten Euros, and I don't imagine the PC card adapter to be much more expensive.

For mobile UMTS/GSM, I have been using an Option 3G Data Card for two and a half years now. I blogged about getting the card to work (in German, sorry) on Linux in July 2005. I never found the time - until now - to automate the card initialization so that I had been using a horrible chat script for card initialization when the PPP connection was built.

I recently took the time to automate this, so that the PIN is transmitted to the card automatically when the card is plugged in. This article documents what I did.

On a side note: Unfortunately, the vendors' attitude towards Linux hasn't changed since 2005. Their Hotlines still deny that their products can be used with Linux at all, and they surely do not publish any documentation that can be of help. Otoh, Vodafone has published a software that supposedly aids usage of their products under Linux. I haven't tried it yet since it is not packaged yet for Debian. Additionally, Vodafone support media and sales do not seem to know about this effort, they still deny that their products work with Linux. Windows users happily install proprietary software products that do little more than sending a handful of AT commands to the emulated USB modem and hand over the connection to Windows' PPP Stack. A very unsatisfying situation.

Just for the record: Dear Vodafone DE, a week ago you missed the sale of a new USB UMTS interface because you don't even document it on Linux. This motivated me to look into the drawer that holds the old, non-HSDPA PC cards that have been decommissioned at the customers' site and use an old, used device. Your fault.

This article was updated, and the issue seems solved. Please look at the last paragraph before adding comments.

Exim has the habit of trying to find out about its host names and IP addresses when it starts up. This has, in the past, been an issue for the Debian packages, since a Debian system might be on a dial-on-demand modem line with expensive costs and thus should not do unnecessary DNS lookup when the MTA is started.

This article tries to describe the issue and which countermeasures debian took, and asks for tips how to solve this in the case of IPv6, where our past measures unfortunately do not directly apply.

I'd like to solicit opinions from people who are more experienced than me with Unix, the local resolver library including /etc/hosts and /etc/nsswitch.conf, DNS, and - especially - the customs that apply on a system running IPv6.

For various reasons, I have the kernel and the initrd that my notebook needs to boot Linux on an USB stick. I recently added the Debian Installer and grml to the stick to allow additional uses of the stick.

Sometimes a bug report is a labyrinth. #348046 is an example of this. It is a horrible mess of at least three different issues with half of the original participants having become unresponsive. I would like to pull the issues apart into different bug reports to be able to deal with them (and their probably unresponsive submitters) individually.

Obviously, cloning and renaming is not an option since this copies the mess.

So, it would probably be desireable to download the bug mbox and to bounce individual messages to new bugs (that have been created before), but the BTS recognizes the dupes and bins them. Blars has helped me by looking at BTS mail log, so it was clear that removing the X-Loop, X-Debian-PR, X-Spam, Resent- and Received headers from the mbox before loading it into mutt to do the actual bouncing works fine.

A command line to do this:

rm -f mboxout; < mboxbug formail -d -I Received -I X-Debian-PR -I X-Loop -I X-Spam -I Resent -s >> mboxout

After trying this in "production", one needs to send one message per BTS pulse, or one will totally mess up the order of the messages. That's a real pity and an annoyance.

For various reasons, I usually carry an USB stick with me that holds a single ext2fs and has grub installed. This blog entry quickly documents how to copy a Debian-Installer to it to be able to quickly install Debian without the need to burn a CD.

Sometimes, it is nearly as frustrating to use Debian than it is to use commercial software. For example, when one sees a simple bug completely unreacted on for more than one year. #405040 has passed its first anniversary since it was reported and touched for the last time. Visible reaction of the package maintainer: Nil.

It's a small thing, but an annoying one. And I still consider it unacceptable to let bugs rot for a year without the slightest trace of action.

In a nutshell: If your system is kind of older than sarge (as in installation date, updates done in the mean time don't matter), beware of 2.6.23.x or update your grub boot sector, which Debian doesn't do automatically on package installation.

Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues.