Server endlich installiert

Ich bin entzückt: Nach 4 Tagen und etlichen unbeantworteten Mails hat der fast it Support endlichen den Server neu aufgesetzt. Ich frage mich nur gerade, was die sonst für Kunden haben, wenn in der Bestätigungsmail ein solcher Hinweis zu finden ist:

Eventuelle Warnungen Ihres SSH-Clients aufgrund eines neuen Schlüssels auf Ihrem Server können Sie ignorieren.
Bitte verwenden Sie für die SSH Verbindung zu Ihrem dedizierten Server das SSH 2 Protokoll.

Wer schon am Login über SSH scheitert, sollte lieber die Finger von einem eigenen Server lassen.
Heute Abend werde ich mich mal daran setzen den Server zu konfigurieren. Den root Login über SSH habe ich sofort abgeschaltet und auf PKey umgestellt. Alle anderen Dienste werden erst einmal iptables blockiert. Sicher ist sicher. Sonst muss ich schlimmstenfalls noch weitere 4 Tage warten, bis ich dazu komme den Server zu konfigurieren.

Wenn das Netzteil verreckt

Momentan stelle ich auf Basis von Debian Etch eine eigene Distribution für Terminalrechner zusammen. Dabei gilt es solche Probleme zu lösen wie etwa Anbindung von Touchscreens an X.Org, Ansteuerung eines Mikrocontrollers über CGI und nicht zuletzt Firefox für den Kioskmodus anzupassen.
An den Rande der Verzweiflung hat mich getrieben, dass mein Mini-ITX-Testsystem gelegentlich abgeschaltet hat. Da der Rechner bisher unter Sarge problemlos arbeitete, ging ich davon aus, dass der Grund für die Totalabstürze meine Kernelmodifikationen seien. Als die Box jedoch auch mit dem Standardkernel abstürzte, dränge sich mir der Verdacht auf, dass das Netzteil defekt sein könnte. Mit dem Multimeter konnte ich meinem Verdacht bestätigen: Liefern sollte das Netzteil eine Ausgangsspannung von 12V DC mit einer Toleranz von 5%. Mein Messwerte schwankten zwischen 9V und 14V.
Zwar ist auf dem Netzteil noch Garantie, aber bis das ausgetauscht ist dürfte einige Wochen ins Land ziehen. Momentan betreibe ich die Box an einem alten ATX-Netzteil, aber das ist keine sinnvolle Lösung, weil die Stromversorgung der 2.5″ Festplatte etwas wacklig ist.

Aufgeschraubtes Mini-ITX-System mit defektem Netzteil

Morgen werde ich versuchen bei Conrads einen Ersatz zu organisieren. Das hier sollte passen. Lediglich beim Stecker bin ich mir unsicher. Ob die wohl genormt sind?

Ubuntu Kernel 2.6.17-11 crasht NdisWrapper

Nach dem Update auf Kernel 2.6.17-11 verweigerte mein über NdisWrapper eingebundener D-Link DWL-G122 Revision C1 den Dienst. Ein Blick in /var/log/messages offenbarte auch schnell den Grund dafür:

Feb 26 21:34:46 linbook loadndisdriver: loadndisdriver: main(546): version 1.9 doesn't match driver version 1.8

Beheben ließ sich das Problem durch vollständiges deinstallieren des NdisWrappers und anschließende Neuinstallation:

sudo make uninstall
make distclean
make
sudo make install

Der Windowstreiber musste dann ebenfalls über sudo ndiswrapper -i /Dr71WU.inf eingebunden werden. Seitdem läuft wieder alles reibungslos. 🙂

Ob andere Distributionen von dem Problemchen ebenfalls betroffen sind, vermag ich nicht zu sagen.

Wenn doch sich bloß mehr Hersteller von WLAN-Chipsätzen an der Entwicklung entsprechender Kernelmodulen beteiligten oder wenigstens die Spezifikationen ihrer Hardware offenlegen würden, wäre das Leben so viel einfacher.

Doch ich möchte mich nicht beschweren: Unter unixartigen Betriebssystemen vermochte ich bislang jeden WLAN-Adapter zu installieren – auch wenn es schon mal umständlich gewesen sein mag.
Vor der Windows XP Installation auf dem Notebook meiner Schwester jedoch musste ich kürzlich kapitulieren: Der alte Adpater Marke Noname unterstützte leider nur WEP, so dass ein Wechsel der Hardware nötig war. Die alten Treiber ließen sich jedoch offenbar nicht vollständig entfernen, so dass der neue WLAN-Adapter (ebenfalls ein ein DWL-G122) nicht korrekt arbeitete. Die Verbindung zum AP wird sporadisch getrennt, die Bandbreite bricht ein und gelegentlich setzt es sogar einen Bluescreen. Das Problem konnte bis heute nicht gelöst werden und wird wohl in einer Neuinstallation des Betriebsystems münden. Möglicherweise gelingt es mir sogar meine Schwester für Ubuntu zu begeistern…. Also wenn jemand gute Argumente für Linux hat, die auch bei weniger geekigen Menschen ziehen: Immer her damit!

Ubuntu Edgy auf Dell Dimension 5150

Als ich versuchte Ubuntu Edgy auf meinem Dell Dimension 5150 zu installieren, brach der Installer schon beim Starten mit der Meldung Starting System log daemon: syslogd, klogd. ab. Zwar konnte das Problem durch den Bootparameter debian-installer/probe/usb=false behoben werden, doch sollte derartiges gar nicht nötig sein. An den USB-Bus angeschlossen sind ein Logitech Keyboard, eine alte Microsoft Maus sowie ein Lide30-Scanner von Canon. Bei der Installation von Dapper Drake auf gleicher Hardware gab es noch keine Probleme. Ich bin gespannt, wie sich Feisty Fawn schlagen wird. Selbst wenn Geräte am USB-Bus kaputt sind, sollte das System dadurch nicht einfrieren.

Wozu /media?

Gemäß den Empfehlungen des FHS sollte /media zum Einbinden von Wechseldatenträgern wie CD-ROMs, DVDs, USB-Sticks und ähnlichen in unixartigen Betriebssystemen genutzt werden. Warum nicht /mnt als „Mount point for a temporarily mounted filesystem“ ebenfalls für Wechseldatenträger genutzt werden sollte, die als solche ebenfalls nur temporär eingebunden werden, erschließt sich mir nicht ganz. Spätestens bei USB-Festplatten verliert die Unterscheidung zwischen /mnt /media meines Erachtens an Eindeutigkeit.

Meine Top 10 Unixshell-Kommandos

IBM hat unter Productivity tips einen interessanten Artikel veröffentlicht, der einige Tipps enthält, wie mensch seine Produktivität auf der Kommandozeile optimieren kann.
Als sehr aufschlussreich empfinde ich die vorgestellte Möglichkeit durch Kombination bekannter UNIX-Tools eine Statistik der am häufigsten in der Shell aufgerufenen Kommandos zu erstellen.

$ history|tail -1000|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}'|sort|uniq -c|sort -r

Auf dem MacBook:

92 cd
89 ls
44 vim
34 gcc
30 awk
31 make
17 sudo
13 wget
13 java
10 echo
9 top

Auf dem Server:

80 ls
51 cd
47 sudo
41 apt-get
40 tail
23 exit
17 df
10 grep
10 rm
10 chmod
9 cat

Um eine repräsentativere Statistik zu erstellen, wäre es ratsam mit history -c sparsamer umzugehen. 😉

ext2 unter Windows

Linux ist oft die letzte Rettung, um Daten von einer zerstörten Windows Partition zu retten. Das Problem ist nur, wohin die Daten sichern? Die Schnittmenge der von Windows und Linux unterstützten Dateisysteme bildet FAT32. FAT32 hat viele Unzulänglichkeiten, von denen in Praxis am schwersten wiegt, dass Dateien nicht größer als 4 GB sein dürfen. Das Spiegeln einer Partition mit dd wird damit unmöglich, ohne das Dump in mehrere kleine Dateien zu splitten.
Der Schreibzugriff auf NTFS-Volumes ist unter Linux nur auf Umwegen über captive Userland“treiber“ zu empfehlen, wenngleich der im Linux-Kernel implementierte NTFS-Support seit Version 2.6.12 nicht mehr als experimentell eingestuft wird. Captive kann jedoch leider nicht immer genutzt werden, da dazu der original Treiber ntfs.sys von Microsoft vorliegen muss. Außerdem ist der Zugriff über captive auf NTFS-Volumes sehr langsam, da ein erheblicher Overhead durch die API-Emulation entsteht.

Einen Ausweg aus der Misere bietet explore2fs, ein Open Source Tool für Windows, das es ermöglich ext2 und ext3 Partitionen und Images zu öffnen. Der Lesezugriff funktioniert damit auf ext2 und ext3 formatierte Volumes sehr zuverlässig, so dass es kein Problem darstellt auch größere Datenmenge von einer NTFS-Partition unter Linux zu sichern, um sie später unter Windows mit Hilfe vom explore2fs wiederherzustellen.

ProFTPD – langsame Logins

Dauert das Anmelden auf einem mit ProFTPD betriebenen FTP-Server ungewöhnlich lange, ist die Ursache zumeist ein DNS Lookup des Clients.
Abhilfe schaffen die folgenden Optionen in der proftpd.conf:

UseReverseDNS off
IdentLookups off

Wird eine eingehende aktive oder ausgegehende passive Datenverbindung angestoßen, versucht der FTP-Server die IP-Adresse des Clients in einen Namen aufzulösen. Das braucht ein wenig Zeit; und sofern die Auflösung der IP nicht möglich ist, weil zum Beispiel der DNS durch eine Firewall blockiert wird, wartet ProFTD bis zum Timeout durch die libc.
Ähnlich verhält es sich mit den IdentLookups: Hier versucht der FTP-Server mittels Ident-Protokoll den Benutzernamen des Clients zu erfragen – wird das Protokoll vom Client nicht unterstützt oder die Abfrage durch einen Portfilter (aka Firewall) blockiert, muss ProFTPD auf ein Timeout warten.