Tty-Schnittstelle

Als zusätzliche Hilfe lasse ich in der Inittab des NSLU2 einen Getty-Prozess auf »/dev/ttyUSB0« starten. Wer einen von Linux unterstützten USB-to-Serial-Adapter in die zweite USB-Schnittstelle des Slug einsteckt und dann die RS232-Seite des Adapters mit einem Nullmodemkabel an die serielle Schnittstelle eines zweiten Rechners anschließt, braucht dort nur noch ein Terminalprogramm zu starten. Auf diese Weise bleibt immerhin ein Terminal-Login auf dem Slug möglich, wenn die Netzwerk-Konfiguration vermurkst ist. Wer sich einen zusätzlichen USB-to-Serial-Adapter zulegt und den an das Nullmodemkabel anschließt, braucht am zweiten Rechner keine RS232-Schnittstelle mehr.

Der USB-to-Serial-Adapter funktioniert zusammen mit einem Onewire-USB-Dongle hervorragend hinter einem USB-Hub, sodass sich beide Geräte die zweite USB-Schnittstelle des Slug teilen können. Als ausgesprochen störend erwiesen sich beim NSLU2 bestimmte Hardware-Eigenheiten. Von insgesamt sechs Geräten funktionierte nur bei zweien die Hardware-Clock, woran die Knopfzelle übrigens unschuldig war. Wer also Zeit und Datum braucht, ist auf eine Netzwerkverbindung samt NTP-Server angewiesen und sollte das Gerät nach dem Ntpd-Start besser eine Weile Däumchen drehen lassen, damit sich der Daemon zwischenzeitlich Uhrzeit und Datum holt.

Wohl als "Feature" hat Linksys dafür gesorgt, dass ein Slug nach einem Stromausfall grundsätzlich nicht wieder anläuft, bevor der Benutzer den Einschaltknopf gedrückt hat. Dieses Verhalten mag bei einem Network-Storage-Adapter akzeptabel sein, als der das Gerät ja verkauft wird. Ein Embedded-Device jedoch, das nach einem Stromausfall nicht automatisch wieder startet, ist nach meinen Maßstäben unbrauchbar. Dies Verhalten macht es als Asterisk-Host ebenso ungeeignet wie auch als Server für ein Sensorsystem, denn am Einsatzort des NSLU2 in Portugal gab es in den letzten sechs Monaten rund 70 Stromausfälle, aber fast nie einen Menschen, um den Knopf zu drücken. Wer dieses Feature ändern will, muss einen Transistor und einen Widerstand (Abbildung 2) auf die Rückseite der Slug-Platine löten [5].

Mittlerweile setze ich bei meinen Sensor-Netzwerken an zwei Münchener Standorten nur noch einen einzigen Slug, aber zusätzlich zwei Exemplare des Embedded-Computers Soekris Net5501 mit 512 MByte RAM ein [6]. Denn diese können neben Owfs noch zusätzliche Software laufen lassen und bedienen auch PCI-Hardware, Cups und Sane mit proprietären Binary-only-Backends, aber auch Asterisk mit Codec Conversion, Call Monitoring, Text-to-Speech-Software und PCI-ISDN-Karte. Ein weiteres Onewire-Netzwerk im bayerischen Erding, das ich aus der Ferne betreue, läuft auf einem weiteren Embedded-Rechner, dem Alix 2D13 mit 256 MByte RAM [7], der ebenfalls noch genügend Ressourcen für weitere Applikationen hat.

Abbildung 2: Einen Transistor und einen Widerstand einlöten – und schon startet der NSLU2 auch ohne manuellen Knopfdruck.

Passend dimensionieren

Wer lediglich eng umrissene Aufgaben zu bewältigen hat und den Speicherbedarf in Grenzen halten kann, der ist mit dem NSLU2 sicher ausreichend bedient. Sobald der Rechner aber zusätzliche Services erbringen soll, lohnt sich der Griff zur Alix- oder Soekris-Kategorie. Und obendrein ist das Preis-Leistungs-Verhältnis beim nicht einmal doppelt so teuren Alix zumindest nach meinen Maßstäben dramatisch besser. Wer noch mehr RAM, SATA und vier Ethernet-Schnittstellen braucht, wird zum Soekris greifen. Der Aktionsradius von Schnecken ist manchmal eben doch zu klein. (mhu)

Der Autor
Eitel Dignatz ist Strategieberater und Inhaber von Dignatz Consulting, München [http://www.dignatz.de/spot461 ].