Cosmetic Bug

I noticed these messages in BIND's logs today:

managed-keys-zone ./IN/internal: loading from master file 3bed2cb3a3acf7b6a8ef408420cc682d5520e26976d354254f528c965612054f.mkeys failed: file not found

The messages started after the upgrade to BIND 9.7.3 on Debian 6.0. I had not checked the logs before because BIND has worked fine since the upgrade, but new messages should always be investigated.

Thankfully, the message is the result of a cosmetic bug and is no cause for concern. BIND will only generate the file if the managed-keys statement appears in the configuration, but BIND checks for the file even when the managed-keys statement is missing, which renders looking for the file pointless.

Creating an empty file is the simplest work around, but I decided to leave the messages in the log, since I now know they are benign.

Insserv

Understanding insserv was easy enough but I am still not convinced that dependency based booting should be the default. It is a choice best left to the sysadmin. Anyhow, what's done, is done.

I solved the problem of NFS depending on DNS by creating an override file in /etc/insserv/overrides/nfs-kernel-server:

### BEGIN INIT INFO
# Provides:          nfs-kernel-server
# Required-Start:    $remote_fs nfs-common $portmap $time $named
# Required-Stop:     $remote_fs nfs-common $portmap $time
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Kernel NFS server support
# Description:       NFS is a popular protocol for file sharing across
#                    TCP/IP networks. This service provides NFS server
#                    functionality, which is configured via the
#                    /etc/exports file.
### END INIT INFO

and running

# insserv nfs-kernel-server

to update the start up order.

My rtorrent initscript is based on this one, which does not have the dependency header that insserv requires. I used the header from the initscript included in the SABnzb+ package since it seemed reasonable that rtorrent would have the same requirements. I inserted the following into the rtorrent initscript:

### BEGIN INIT INFO
# Provides:          rtorrent
# Required-Start:    $local_fs $network $remote_fs
# Required-Stop:     $local_fs $network $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: rtorrent BitTorrent client
### END INIT INFO

and ran

# insserv rtorrent.sh

to activate the script. I didn't bother using an override file since the script is not part of a package.

And thus ended my first squeeze upgrade. Extrapolating this experience, my customer's servers, which are very heavily customized, will likely require much more work than the previous upgrade. Oh, joy!

Progress (Or Is It?)

I upgraded one of my Debian servers to 6.0 (squeeze) today. This system is currently not that critical (it won't kill me if I can't watch TV ^_^) but it is about to become my new mail server, so this seemed like an appropriate time to do the upgrade.

The upgrade went smoothly but I miss the the good old days when a Debian upgrade consisted of three steps: change sources.list, run "apt-get update", and run "apt-get dist-upgrade". Although the upgrade completed successfully, there are still a few bits to be ironed out.

One of the problems is that the new dependency based initscript system (insserv) causes the NFS export to fail, because the DNS server has not started yet. The old System-V-like system never had this problem. The easiest solution is to use IP address in the /etc/exports file, but hard coding IPs seems backwards to me, so it looks like I'll be digging into the mysteries of insserv.

This is OK, since I have have a custom initscript which also has to be integrated with insserv, so learning it was unavoidable. The mildly annoying part is that insserv is already slated to be replaced in the next Debian release. It says a lot about the old, equally broken but well understood, System-V style startup which had been around since forever. Ah, progress!

Debian 6.0

Debian 6.0 "squeeze" was released today. This is both good news and bad news for those of us who run Debian "sid", and don't really care about the release.

It's good news because the flow of new software will return to normal. The flow slows to a trickle as the release gets closer, which is kind of annoying if you happen to be waiting for certain software. In my case, this would be the 2.6.38 kernel and the latest x.org radeon driver, which together are supposed to bring a significant improvement in performance to several AMD chipsets.

It's bad news because the first week after the release, the flow turns into a flood. This is usually when "sid" is most unstable and you really have to keep your wits about you, otherwise you can easily end up with a broken system. Thankfully, I've been through this many times before, so I'm quite used to it. Strangely, "testing" is often less stable than "sid" during this time.

The code name for the next Debian release is "wheezy", and no there is no release date for that. Debian doesn't work that way. ^_^