#!/bin/blog » alix

ALIX sizing lesson and WPA configuration note

martin — Sun, 14 Dec 2008 12:17:56 +0000

Okay, there we have it. The ALIX, despite its generally good performance, can’t handle the workload of BackupPC and starts to swap really badly when backing up a fairly large system via rsync.

At least I’ve learned from this test how to configure the Wistron CM9 card for WPA on Debian:

iface ath0 inet static
        madwifi-base wifi0
        madwifi-mode sta
        wpa-driver wext
        wpa-ssid blah
        wpa-psk blubb
        address 192.168.1.100
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1

New ALIX 2d3

martin — Mon, 06 Oct 2008 17:44:11 +0000

I received my first new ALIX of the type 2d3 today. Apparently, this is the successor to the 2c3 and brings no major changes but just minor modifications. According to PC Engines:

• 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.

Playing with the ALIX LEDs

martin — Sat, 04 Oct 2008 06:24:36 +0000

I have started to use an ALIX machine by PC-Engines as my printserver using CUPS. Being the playful kid that I am, I wanted the machine to somehow indicate that it has queued print jobs, using the LEDs.

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.

Debians dünner Installer

martin — Tue, 30 Sep 2008 16:04:13 +0000

Ihr lieben Leute, wie konntet ihr mir das nur durchgehen lassen? Ihr wißt doch sonst alles.

Die Sache mit dem aufgeblähten Debian-Installer hat mir keine Ruhe gelassen und so habe ich dann doch mal in der Debian-Installationsdoku nachgelesen.

Um ein Debian-System in erträglicher Weise über die serielle Schnittstelle mit 9600 bps installieren zu können, muß man beim Boot lediglich das folgende Argument an die append-Zeile des Kernel anhängen:
DEBIAN_FRONTEND=text

Oder, bei der PXE-Installation, in /tftpboot/pxelinux.cfg/default den Default-Eintrag wie folgt erweitern:

LABEL install
        kernel debian-installer/i386/linux
        append vga=normal initrd=debian-installer/i386/initrd.gz -- console=ttyS0,9600n8 DEBIAN_FRONTEND=text

Damit präsentiert sich der Installer folgendermaßen:

Ich habe die Installation nicht komplett durchgezogen (die Installation auf dieser Alix ist ja schon fertig), aber ich denke, an diesem Installationsmodus gibt es wirklich nichts auszusetzen.

Cool übrigens, daß PuTTY auch ohne Probleme als serielles Terminal funktioniert.

Stromverbrauch PC-Engines ALIX 2c3

martin — Sun, 25 May 2008 11:11:48 +0000

Also, Kinder, ich habe mal gemessen, wie der Stromverbrauch der ALIX so aussieht.

9W während des Bootvorgangs.
6W idle.
9W unter Vollast (while true; do true; done).

Ehrlich gesagt habe ich nicht den Eindruck, daß die Auflösung meines Premium-ALDI-Leistungsmeßgeräts der Aufgabe so richtig gewachsen ist.

Alix-Update

martin — Fri, 16 May 2008 05:03:52 +0000

Meine neue ALIX 2c3 ist da. Eine interessante Änderung zur bereits vorhandenen ALIX ist, daß der IDE-Port jetzt bestückt ist. Ein Bauteil im Wert von wenigen Cent, das die Maschine für viele Leute deutlich aufwerten dürfte.

Des weiteren habe ich mir eine Entwicklungs-VMware für OpenBSD aufgesetzt, in der ich jetzt Flashdist-Images selbst bauen kann. Einen ~~herben~~ minimalen Dämpfer hat die aktuelle Bastelwelle allerdings dadurch bekommen, daß das bei Ubuntu mitgelieferte Minicom so miserabel ist, daß es nicht mal das kann, was es eigentlich sollte, nämlich ein Terminal emulieren:

Willkommen zu minicom 2.3-rc1

Optionen: I18n
Übersetzt am Dec 10 2007, 10:36:19.
Port /dev/ttyS0

               Drücken Sie CTRL-A  Z für Hilfe zu speziellen Tasten

minicom: ../iconv/loop.c:430: internal_utf8_loop_single: Assertion `inptr - bytebuf > (state->__count & 7)' failed.
                                   Aborted
martin@ubuntu:~$

Unfaßbar, ganz ehrlich. Und natürlich mal wieder eine Beta, was sonst, bei einem Produkt, das seit Jahren keine Innovation nötig hätte, auf die die ganze Welt gespannt warten würde.

Die massiven Paketverluste, die ich in zwei Wellen mit der m0n0wall-Beta hatte, treten leider auch unter OpenBSD auf. Eine Rücksprache mit dem Flashdist-Maintainer ergab, daß das durchaus darin liegen könnte, daß FreeBSD und OpenBSD den selben Hardwaretreiber für die "Via Rhine"-Netzwerkkarte benutzen. Hilfe ist aber auf dem Weg, denn bei FreeBSD wurde bereits eine komplette Neuentwicklung eingecheckt. Mal abwarten, wann die ihren Weg zu OpenBSD findet. Jedenfalls bin ich mit dem Problem nicht allein (es tritt auch auf Soekris-Hardware auf), und meine Hardware ist nicht defekt. Das beruhigt zumindest etwas.

Alix migriert auf OpenBSD

martin — Mon, 14 Apr 2008 16:17:06 +0000

Ein paar Monate nach Inbetriebnahme der Alix 2C3 haben ein paar kleine Problemchen überhand genommen. Ich hatte ständig mit Paketverlust (nicht zu beheben) und hängenden Schnittstellen (nur durch Reboot zu beheben) zu kämpfen.

Nachdem ich letzte Woche mehrmals den DSL-Router durchgetauscht und die Telekom zum Durchmessen der Leitung im Haus gehabt hatte, blieb leider nur noch ein Schuldiger übrig, und das war mein Alix-System. Am Wochenende habe ich dann die m0n0wall, die für die Geode-Plattform leider nach wie vor nur als Beta verfügbar ist, rausgeworfen und durch OpenBSD Flashdist ersetzt.

OpenBSD Flashdist ist ein ausgesprochen spartanisches System, auf dem nach der Installation praktisch keine Prozesse laufen. Hat man die Maschine dann maßlos um einen NTP-Daemon und den Paketlogger aufgerüstet, sieht die Prozeßliste wie folgt aus:

# ps ax
  PID TT  STAT       TIME COMMAND
    1 ??  Is      0:00.01 /sbin/init
15445 ??  Is      0:00.00 mount_mfs -s 1024 -i 1024 swap /dev
17625 ??  Is      0:00.08 mount_mfs -s 199132 swap /tmp
14300 ??  Is      0:00.01 syslogd: [priv] (syslogd)
13831 ??  I       0:00.13 syslogd -p /var/run/log
 9241 ??  Is      0:00.16 ntpd: ntp engine (ntpd)
30396 ??  Is      0:00.08 ntpd: [priv] (ntpd)
31199 ??  Is      0:00.04 /usr/sbin/sshd
15779 ??  Is      0:00.13 /usr/sbin/cron
 4135 ??  Is      0:00.01 pflogd: [priv] (pflogd)
31903 ??  I       0:01.78 pflogd: [running] -s 116 -i pflog0 -f /var/log/pflog
 8329 ??  Is      0:00.29 sshd: root@ttyp0 (sshd)
14774 p0  Is      0:00.02 -ksh (ksh)
29440 p0  R+      0:00.00 ps -ax
23450 00  Is+     0:00.01 /usr/libexec/getty std.38400 tty00
Natürlich liegt der 500-MHz-Prozessor damit zu 99% brach. Immerhin kann ich den in der Alix im schieren Überfluß vorhandenen Arbeitsspeicher als RAM-Disk für /var/log nutzen. Bei soviel brachliegender CPU-Leistung und Offenheit des Systems fällt es mir aber zugegeben schon ein wenig schwer, mich an meine eigene Policy zu halten, nach der auf der Firewall keine Services außer SSH (und das auch nur von innen) zu laufen haben. 
Will man die /etc/pf.conf editieren um etwas an den Firewallregeln zu ändern, kann man problemlos schnell das Root-Filesystem auf read-write umstellen:
# mount -o rw /
# vi /etc/pf.conf
# pfctl -f /etc/pf.conf
# mount -o ro /
Und siehe da: Nach der Umstellung sind die Paketverluste wie weggeblasen. Wenn ich an die Erfahrung denke, die ich mit meinem letzten OpenBSD-System gemacht habe, werde ich daran jetzt wohl jahrelang Freude haben. Oder auch nur vorläufig bis zum nächsten Bastelflash.



Ordnungsoffensive im Serverschrank
martin — Sun, 13 Jan 2008 11:06:52 +0000
Dieses Wochenende war’s in meinem Home-Office soweit: Die Kombination aus Firewall und Mailgateway wurde entzerrt, nachdem das Trägersystem, ein schnieker aber zickiger Compaq Deskpro SFF mit 300 MHz, zwischen den Jahren zunehmend Probleme gemacht hatte. Zuerst hat er sich in Form von Abstürzen am aktuellen CentOS-Kernel verschluckt, und zu guter letzt verstarb die Festplatte, von der aber ein Backup vorhanden war. 
Eine Alix 2C3 von PC Engines übernimmt jetzt die Paketfilterung und der Mailer läuft getrennt davon in einer DMZ. Da ist er auch wirklich besser aufgehoben, insbesondere weil er auch als Sprungbrett für SSH und Stunnel benutzt wird. 
Weil ich in der DMZ damit neben Bittorrent, Tor und I2P auf mittlerweile 3 Maschinen gekommen wäre, habe ich diese als virtuelle Instanzen auf ein einzelnes System konsolidiert. Natürlich nicht mit Xen oder UML oder KVM oder welche Virtualisierungstechnik derzeit mal wieder in Mode ist, sondern ganz reaktionär mit VMware. Nicht, weil ich von der technischen Überlegenheit der VMware überzeugt bin, sondern weil ich damit so viel Erfahrung habe, daß ich sie im Notfall auch nachts um vier mit zwei Promille und ‘nem blauen Auge auf andere Hardware umziehen kann.


(Originalfoto: Backbone #2 by AndiH, cc-by-nc)
Mit der Auswahl des Betriebssystems für die Alix habe ich mir ein klein wenig schwerer getan. Am Anfang war OpenBSD-Flashdist ein heißer Kandidat, aber ich habe mir nicht nur recht schwer damit getan, mein für heimische Verhältnisse einigermaßen komplexes Firewallregelwerk mit drei Netzwerkkarten unter pf abzubilden, sondern mir war auch unklar, wie diese angepaßte OpenBSD-Version mit Updates versorgt werden soll. Da half auch mein dickes OpenBSD-Buch nicht weiter. Des weiteren wurde mir das Thema “Flash-Geometrie” im OpenBSD-Umfeld zu stark thematisiert, so daß ich mich insgesamt nicht damit anfreunden konnte.
Nach einem sehr kurzen Ausflug zu Voyage Linux bin ich dann doch bei der alt eingesessenen m0n0wall mit ihrer aus Sicht des Fricklers nicht so sehr erotischen Ausstrahlung gelandet. Firewallregeln mit der Maus zusammenzuklicken mißfällt mir zwar ein wenig, aber wenn ich mich nicht autodidaktisch zum Spezialisten für embedded Linux fortbilden will, der alles über die virtuelle Festplattengeometrie von Flash-Disks (Herr, schmeiß Hirn vom Himmel!) und das Verlagern schreibbarer Betriebssystembereiche auf Ramdisks wissen will, ist der einfache Weg vielleicht doch der beste. 
Was mir an der m0n0wall besonders zusagt, ist, daß Updates in-place installiert werden, ohne daß man mit Rechner und Kartenleser hantieren muß. Insgesamt macht die m0n0wall einen sehr harmonischen und stimmigen Eindruck, auch wenn das Web-GUI noch in der CGI-Version von PHP 4 geschrieben ist.  
(Update, 14.04.2008: Ich habe am Ende doch noch auf OpenBSD umgestellt, da ich mit der m0n0wall meine Problemchen hatte.)
Jetzt bin ich an dem Punkt, wo alle Systeme im Haus vor mechanischen Festplattenproblemen sicher sind: Der Fileserver ist schon ewig gespiegelt, die VMware-Systeme jetzt ebenfalls, und die Firewall hat erst garkeine Festplatte mehr. Sehr schön.