Grub, Kernel und initrd werden zwar geladen. Leider erfolgt innerhalb der initrd aber scheinbar ein Reset des USB-Systems. Ein normaler USB-Stick holpert da irgendwie drüber (das funktioniert mit /boot auf dem Stick problemlos), aber der Lok-IT sperrt sich sicherheitshalber automatisch.

Das ist schade, aber kein Beinbruch. Das letzte Wort wird da auch hoffentlich noch nicht gesprochen sein.

Es trifft zu, daß der USB-Bus beim Hochfahren zurückgesetzt wird und sich der Stick in diesem Moment aus Selbstschutz sperrt. Das ist aber überhaupt kein Problem. Man muß lediglich in /etc/fstab dafür sorgen, daß das System beim Hochfahren nicht versucht /boot zu mounten oder zu checken. Beide Daumen nach oben für meinen unknackbaren Terrorlaptop!

Und, nein, es wird kein HOWTO dazu geben. Wer dafür ein Kochrezept braucht, sollte besser die Finger davon lassen.

This is on one of two Ubuntu 10.04 LTS system, for which I have licensed the commercial Ksplice service.

P.S.: Sorry for inflicting my foul accent upon you.

# touch /tmp/foo
# chattr +i /tmp/foo
# rm /tmp/foo
rm: cannot remove `/tmp/foo': Operation not permitted

Unfortunately it is not possible to apply the same to a directory so it can never be deleted, even when it is empty. At least not, if the directory is supposed to be usable for anything, because immutability means that there can be no files written to it:

# mkdir /tmp/foo
# chattr +i /tmp/foo
# touch /tmp/foo/bar
touch: cannot touch `/tmp/foo/bar': Permission denied

My workaround is to create a hidden file in the directory and make it immutable:

# mkdir /tmp/foo
# touch /tmp/foo/.immutable
# chattr +i /tmp/foo/.immutable
# rm -rf /tmp/foo
rm: cannot remove `/tmp/foo/.immutable': Operation not permitted

This is how I migrated my LUKS container to a passphrase stored on USB media.

First, I filled the USB key with random data:
# dd if=/dev/urandom of=/dev/sdc

Then, I siphoned off 256 bytes from the USB key, to be used as the passphrase:
# dd if=/dev/sdc of=/home/martin/foo.key bs=1 count=256

foo.key is required temporarily. You may keep a copy of it stored in a safe place, or you may leave the interactive password in place as a fall-back measure. Which is what I’m doing.

The new passphrase can be added to the LUKS container like this:
# cryptsetup luksAddKey /dev/sda4 /home/martin/foo.key

Cryptsetup asks for “any passphrase”. That is one of the numerous possible passphrases that may be assigned to a LUKS device at once. Such as the interactive passphrase that is already in place.

When the new passphrase has been added, foo.key can be deleted.

Next, I determined the USB id of my USB key:
# ls -l /dev/disk/by-id/ | grep sdc
lrwxrwxrwx 1 root root 9 2008-12-04 21:31 usb-LG_XTICK_AAAAAAAAAAAAAAAAA-0:0 -> ../../sdc

I found that I needed a little helper script that extracts 256 bytes from the USB key and pipes them to stdout:

#!/bin/bash
# Script: /usr/local/sbin/dd-luks-key.sh
if [ -e $1 ]
then
dd if=$1 bs=1 count=256
fi

And now the change to /etc/crypttab:

# Old entry; ask for password:
#sda4_crypt /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee none luks
# New entry; execute the keyscript with the USB id as the argument:
sda4_crypt /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /dev/disk/by-id/usb-LG_XTICK_AAAAAAAAAAAAAAAAA-0\:0 luks,keyscript=/usr/local/sbin/dd-luks-key.sh

That’s it. I can now reboot with the USB key plugged in and observe how the system automatically mounts the LUKS container. The USB key is not partitioned, so Gnome will not automatically mount it. It can just be pulled anytime after bootup.

If I had chosen to delete the interactive passphrase, which is stored in key slot 0:
# cryptsetup luksDelKey /dev/sda4 0

Be advised that this is no real-deal tough-minded security, but something that will protect the machine only against the type of attackers (e.g. thieves) who are out for your hardware but not for your data. Don’t leave the USB key close to the laptop. Use this responsibly. Thanks!

I’m not conviced that I will stick with this, as it’s far below my usual standard of paranoia. Nevertheless, I have gained a few nice insights into the LUKS system.

Heute bin ich in gewisser Weise einen Schritt weiter, denn bei einem Kunden wurde ein SLES9 aus dem Internet gecrackt, weil der Angreifer sich über einen PHP-Exploit die /etc/passwd herunterladen konnte und darin Passwort-Hashes vorgefunden hat, die ein Administrator beim Anlegen von Usern per Copy&Paste dort eingebaut hat. Die hat er dann auf dem üblichen Weg mit etwas Geduld per Brute-Force geknackt. Ein Szenario aus den 1980ern. Ekelhaft.

• Increase USB current limit.
• USB headers as build option.
• USB ports 3 and 4 on header (not tested).
• Change optional serial header J12 to COM2.
• Add LED and switch pins to I2C header.
• Populate buzzer driver circuit, add pins for use as GPIO.
• Add option for power in header J18.
• Some enhancements to reduce EMI.
• Add second POSCAP to ruggedize 3.3V rail for high power radio cards.

I have highlighted the most apparent changes in the photograph (click to enlarge).

Migration of the pre-installed disk from my development ALIX 2c3 went fine, although I had to resolve a problem with some nasty mis-feature where Debian tries to keep persistent ethernet device names by hard-coding the MAC addresses into some obscure udev configuration file. The system complained about the following network issue, although eth0, eth1 and eth2 showed up properly in the output of dmesg:

Configuring network interfaces…SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device

Deleting the /etc/udev/rules.d/z25_persistent-net.rules file and rebooting resolved the problem immediately.

I never could quite get the hang of devfs or udev anyway. Here’s yet another reason to hate them.

Controlling the LEDs is fairly simple. I started on OpenBSD, found a very simple method for controlling them through gpioctl right away and quickly rolled it into this very simple shell script that allows for commands such as “led 1 on” or “led 3 off”, you get the idea.

I found that OpenBSD didn’t work too well for me as a CUPS printserver for multiple USB printers. The helpful OpenBSD mailing lists were down on that weekend, so I just decided to install Debian Linux onto the ALIX.

The Linux Kernels currently in circulation don’t however support the ALIX LEDs. Support is available, though. I downloaded the kernel module source from here (leds-alix_0.0.1.orig.tar.gz) and after compiling them and loading the leds_alix module, my shell script was ready to be extended into a “multiplatform” LED control wrapper.

(The LED drivers on Linux allow for a lot more fun, such as a “heartbeat” feature or acting as an “IDE” LED, but that’s not my point here. )

On top of my little shell wrapper, I have now implemented a Perl script, the “CUPS LEDs daemon”, cupsledsd, which starts cycling the LEDs when there are pending jobs and uses the wrapper for turning them on and off. Of course, this could easily be used for something more sophisticated, such as displaying the number of queued jobs.

Update, 2008-10-07: I found that the original cupsledsd, as posted above, was a bit too hard on the CPU, using 5-10% for just blinking. Here’s a Linux-only cupsledsd that uses no system() calls. It accesses the CUPS queue directly (searches for data files in /var/spool/cups, probably unsupported), writes directly to the Linux /sys filesystem and blinks more frantically while not using a significant amount of CPU.

The good news: Once you have the serial cable, using the GPSr for ntpd is a matter of seconds.

The Garmin must be instructed to spew out location data on the serial port, which can be accomplished through the interface configuration menu. The default of “GARMIN” for the serial port has to be changed to “NMEA-In / NMEA-Out”. After making this setting, you can use Minicom to connect to the serial port at 4800/8N1 where you will see a constant stream of data. The $GPRMC lines contain the information that is required for NTP. (Click here for details about the format.)

According to the ntpd documentation, the Garmin will be configured as a “generic NMEA GPS receiver“.

ntpd will require a symlink in /dev so it knows where to find the GPSr. In my case, the Garmin is connected to /dev/ttyS0. Hence, the symlink needs to be created as follows:

# ln -s ttyS0 /dev/gps0

ntpd accesses this device through a pseudo IP address that will be used in ntp.conf:

server 127.127.20.0

Behold the NMEA peer:

ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*GPS_NMEA(0)     127.0.0.1        0   64  377 0.00000  0.001443 0.03511

Be advised that it will take a few minutes until ntpd has synchronized with the GPSr. If you can’t get your NTP clients to synchronize with your NTP server, leave it alone for a while and try again later. Synchronization with the GPSr is complete as soon as the output from “peers” no longer starts with “=” but with an asterisk (as above). I learned this the hard way during Y2K testing in 1999 when an NTP server just wouldn’t synchronize. I restarted it over and over again. At the end of my tether, I went out for lunch and left the defunct server behind. When I came back, everything had just fallen into place, the clock was synchronized and so were the clients.

Dieses Problem kann sehr leicht umschifft werden, indem man in die Konfigurationsdatei des DHCP-Client, dhclient.conf, eine Zeile mit den Domains einträgt, die man gern zusätzlich in der Searchliste hätte:

request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, ntp-servers;
prepend domain-name "intranet.kunde1.de dmz.kunde1.de kunde2.de daheim.local example.com";

Die Obergrenze für diese Eintragung liegt, vorgegeben durch den Resolver unter Linux, bei 6 Domains und 256 Zeichen.

Die Konfigurationsdatei findet sich auf Ubuntu-Linux unter /etc/dhcp3/dhclient.conf.