Wandering Thoughts archives

Getting console messages in X

As a system administrator, I like to see console messages even when I'm in X (which is almost all of the time). On my systems, console messages come from high priority kernel messages, high priority notes from syslog, and sometimes messages from init, and I like to know about all of these.

In theory, xterm's -C command line switch should do this nicely, and indeed it did for years. These days, there are two unfortunate problems with it:

• back in 2001 or so, the xterm people decided that -C should quietly ignore your request if you didn't own /dev/console.
• around about the 2.6.9 or 2.6.10 kernel, the Linux kernel people decided that you couldn't redirect console messages unless you were root.

I strongly disagree with xterm's paranoia, since it's pointless if xterm is unprivileged (which it almost always is, and the code could always just check). If xterm has no special privileges, the user can just write their own program to do the appropriate TIOCCONS operation; all blocking -C from working does is inconvenience people.

So back in 2001 I grumbled and wrote my own ten line program to do the needed TIOCCONS ioctl, and there things sat until recently.

Getting around the 'only root can use TIOCCONS' problem is a little bit more work. Since I'm the only user of my machine, I just made my getconsole program from 2001 setuid root and group-executable only by me. A more general solution would be a program that checks the ownership or permissions of /dev/console and only does the TIOCCONS if the person running it has appropriate access.

It's possible that xconsole in recent distributions already does this, but I personally suspect not. Certainly the Fedora Core 4 version shows no likely signs of this.

An impending Debian derailment

The current official plans are for Debian to release Etch (the next version of their distribution) in December 2006, already more than a year and a half after Sarge, their last release. (Since Sarge shipped with already obsolete versions of programs, it will effectively be even longer.)

Unfortunately, I believe Debian has made some decisions that will significantly slow down Etch and even subsequent releases. This matters to me because old, stale versions of programs has been my major problem with Debian; the slower Debian releases come, the staler the programs get.

As part of its social contract, Debian requires everything in Debian to be 'free', as defined in the Debian Free Software Guidelines (DFSG). Over the past (somewhat long) while, Debian has decided that two things are not DFSG compatible and thus can't be in the main distribution in Etch:

• documentation licensed under the GNU Free Document License (see here for one discussion of why).
• firmware images included in kernel drivers that don't have source code (with a DFSG compatible license). (See here or here for a summary of the Debian position on this.)

This would be fine if Debian could get the upstream developers to agree with this and to work to change things. Unfortunately, most of the upstream developers disagree with Debian (somewhat violently in some cases, especially for the kernel) and thus both issues are Debian's problem alone.

People have a lot of reactions to all of this, many of them grumpy. As for me, I think that Debian's adherence to its principles in the face of significant problems is commendable but as a system administrator my first reaction is 'my god, they're taking on a lot of work', since Debian will have to rip each package apart to separate the DFSG-free and non-DFSG-free bits. And then do it all over again every time the upstream releases a new version of the package.

Ongoing work equals delays (or ancient versions of software, because there isn't enough person-power and time to upgrade the version). So I see a derailment in the future for Etch.

How Linux names network interfaces

The usual explanation of how network interfaces get their names is that they're named based on what's in /etc/modprobe.conf (/etc/modules.conf if you're still running a 2.4 series kernel). You'll have lines like:

alias eth0 sk98lin
alias eth1 3c59x
alias eth2 e100

And indeed this usually works, and when your system boots nicely the 3Com 'Marvell' gigabit card is eth0, the 3Com 'Cyclone' 100mbit card is eth1, and the Intel 100mbit card is eth2. Then one day you boot your system single-user without network interfaces enabled and decide to bring up just eth1, so you do 'ifup eth1' (or just 'modprobe eth1'). And the world explodes in your face, because the nice simple explanation is a white lie.

How the Linux kernel really names network interfaces is that network interfaces are named in the order they're found: the first network interface found is eth0, the second is eth1, and so on. The names in the 'alias' lines in /etc/modprobe.conf don't get passed to the kernel; they just help make the normal configuration more generic.

So when you do 'modprobe eth1' on a bare system modprobe maps 'load eth1' to 'load the 3c59x driver', the driver finds a card with a single network interface, and as the first found it becomes eth0. Kaboom. (Similar things can happen if you remove a network card.)

If you want stable names, the kernel does support renaming network interfaces; the usual approach is to name interfaces based on MAC addresses. On modern kernels you can use udev rules (see here); there's also nameif, and your distribution may already support it with the right magic settings.

(On Red Hat and Fedora Core, I believe that you set HWADDR in the ifcfg-* file in /etc/sysconfig/network-scripts. I'm not sure what Debian uses.)

The kernel uses registration order based naming for other things too; the most famous (or infamous) case is SCSI drives, where the first one found is sda, the second one sdb, etc. (The kernel treats SATA drives as SCSI devices, so more and more people may have to care about this one.)