Linux

Da ich seit gestern LPIC-1 zertifiziert bin (Co-Autor Maddin war es bereits seit einer Weile..), möchte ich mal ein paar Worte dazu hier verlieren. Während die Microsoft-Jünger aus dutzenden Schulungen (aka Gehirnwäschen bzw. Werbeveranstaltungen) wählen können, sieht es für Linux eher mau aus. Zwar bieten Suse und RedHat eigene Zertifizierungen an, die Beschränken sich dann aber tatsächlich nur die jeweilige Distrubution und sind nicht allgemein anerkannt.

Dafür wurde LPI gegründet und wird u.A. von IBM subventioniert. Derzeit gibt es 3 Stufen, die man als Administrator (für Entwickler etc. werden keine Zertifizierungen angeboten) erreichen kann: LPIC-1, LPIC-2 und LPIC-3. Die ausgestellten Zertifkate sind weltweit anerkannt, so dass man als Bewerber um einen Posten als Linux-Admin mit einer oder mehreren LPIC-Stufen unter Umständen (!) bessere Karten hat. Garantie gibt es dafür freilich keine. Bei LPIC-1 geht es um Grundlagen der Administration eines Linux-Rechners wie z.B. die Shell, Bootloader und Installation. LPIC-2 geht dann schon etwas mehr ans Eingemachte wie Serverdienste, Kernel oder Hardware. In der 3 (die es wohl in Deutschland noch gar nicht so richtig gibt, soweit ich informiert bin..) dann um Sicherheit oder Virtualisierung.

Auch wenn das auf den ersten Blick für einen Admin, der seit Jahren mit Linux arbeitet, einfach aussieht: Man sollte die Prüfungen nicht unterschätzen. Ich kann jetzt nur für LPIC-1 sprechen, aber mir sind auch einige Sachen begegnet, wo ich Lücken hatte. Zum Beispiel beim Thema X11 oder Drucker musste ich mir Vieles noch aneignen, da sie in meiner täglichen Arbeit als Server-Admin nie begegnet sind. Auch sed oder awk hatte ich noch nie groß benutzt, schließlich gibt es ja PERL. Fragen zu diesen Themen sind aber nunmal Bestandteile bei der LPIC-1 Prüfung, so dass man diese lernen muss.

Zur Übung hat sicher der Simulator auf lpi-academy.de als nützliches Tool erwiesen. Aber Vorsicht, die Fragen sind derzeit nicht auf dem neuesten Stand der Prüfung. Als Buch kann ich auf jeden Fall die LPIC-Reihe von Heinlein empfehlen, ebenso die Materialien von der Linup Front GmbH. Natürlich sollte man idealerweise noch einen entsprechenden Kurs in einem Trainings-Center belegen, um das Wissen aufzufrischen. Bei mir fand der Kurs im Com-Center Dresden statt und war mit Dozenten wie Heiko Schlittermann (bekannt u.A. aus der Linux-User-Group Dresden) recht informativ und hilfreich für die Prüfung.

Ohne entsprechenden Kurs und Erfahrungen mit Linux wird man die Prüfung allerdings wohl kaum bestehen. Es wird, im Gegensatz zu den MS-Zertifizierungen, nicht das auswendig lernen von Fakten abgefragt, sondern die Erfahrungen aus der Praxis im Umgang mit Linux. Dabei spielt die Distribution übrigens keine Rolle, es wird z.B. beim Paket-Management auf alle "Welten" wie Debian, Fedora oder RedHat eingegangen, was auf jeden Fall gut ist. Ich habe bereits in der Schulung gemerkt, dass die Teilnehmer ohne Vorkenntnisse zum Thema Linux echte Probleme hatten, dem Stoff zu folgen. Einige meinten auch, sie werden die Prüfung gar nicht erst ablegen, sondern es bei dem Kurs belassen, da keine Aussicht auf Bestehen der Prüfung besteht. Das ist natürlich schade, aber zeigt deutlich, dass die Anforderungen nicht zu gering sind und man sich als Inhaber des Zertifikates ein wenig freuen darf!

Selbst ich als "alter Hase", der seit vielen Jahren mit Linux beruflich als auch privat arbeitet habe bei den LPIC-Schulungen noch einige neue Dinge und Kniffe kennengelernt, kann die Zertifizierung daher eigentlich durchaus empfehlen. Allerdings ist der "Spaß" natürlich nicht ganz billig. Derzeit fördert aber das Arbeitsamt für berufstätige Admins, die länger als 4 Jahre im Job sind, die LPIC-1 und LPIC-2 Schulungen. Weitere Informationen dazu gibts hier. Wenn man also, wie ich, die Vorgaben des Amts erfüllt und einen Arbeitgeber hat, der die Zeiten dafür freiräumt, sollte man sich die Chance auf mehrere Tausende Euro Förderung für die Schulung(en) nicht entgehen lassen..

Jeder Linux-User mit einem aktuellen Kernel auf seiner Maschine kennt sicher die Meldungen aus dem dmesg-Buffer, die u.A. zur Bootzeit generiert werden. Aber auch nach dem Bootvorgang werden teils kritische Meldungen vom Kernel in dmesg geschrieben. Ein kleines Beispiel:

[3631596.049121] e1000: eth0: e1000_watchdog: NIC Link is Down
[3631647.485033] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX

Es war also offenbar zu irgendeinem Zeitpunkt an diesem Server die Netzwerkverbindung für einige Zeit getrennt. Nur wann genau war das? Gestern oder vor 3 Monaten? Bei Servern, die teilweise Monate (oder gar Jahre!) am Stück laufen, ist der Zeitpunkt kaum zu erraten. Die Angabe in den eckigen Klammern vor jeder Meldung stellt die Zeit seit dem Systemstart dar, leider nicht wirklich menschlich lesbar. Klar, man könnte mittels uptime und date nun die Sekunden manuell berechnen und somit einen Zeitpunkt ermitteln. Aber eigentlich gibt es dafür ja Perl!

Das kleine Perlscript dmesg.pl erledigt die Umrechnung on-the-fly für uns. Wir bekommen dann eine verständliche Ausgabe, hier für unser obiges Beispiel:

[ Wed Jul 1 10:33:11 2009 ] e1000: eth0: e1000_watchdog: NIC Link is Down
[ Wed Jul 1 10:34:02 2009 ] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX

Legt man nun einen Alias wie z.B. alias dmesg='perl /path/to/dmesg.pl' an (z.B. gleich in der .bashrc), bekommt man immer den lesbaren Output.

Das Script liest einfach die Uptime aus /proc/uptime in Sekunden aus und errechnet aus der aktuellen Unix-Time sowie den Einträgen aus dmesg dann den korrekten Zeitstempel. Aber Vorsicht, auf Maschinen, die bereits recht lange laufen, kommt es leider zu Differenzen. Den konkreten Grund konnte ich bisher noch nicht klären, vermutlich aber liegt es daran, dass die Kernel-Uptime nicht immer korrekt hochgezählt wird, v.A. unter Last. Ein weiterer möglicher Grund sind inkorrekte Zeitmessungen nach automatischen Taktänderungen der CPU, zumindest weist ein Bugreport auf kernel.org darauf hin. Auf meinem frisch gebooteten Linux-Laptop hingegen stimmte die Umrechnung stets zu 100%.

Falls Jemand eine andere Erklärung für die Differenzen hat oder das Script optimieren möchte, freue ich mich auf Kommentare. Die Bash-Variante war leider sehr langsam, daher die Perl-Lösung.

Um das normalerweise aus Sicherheitsgründen nur von localhost aus erreichbare Webinterface eines RAID-Controllers oder auch die webbasierte CUPS-Config eines entfernten Rechners zu erreichen, kann man sich der Forwarding-Funktionalität von SSH bedienen.

Hier ein Beispiel, um das auf einem Server arbeitende Webinterface eines 3Ware-RAID Controllers auf dem lokalen Rechner aufzurufen. Der entsprechende Dienst läuft auf Port 888 des entfernten Hosts und wird auf den Port 8080 unserene Rechners weitergeleitet:

ssh -L 8080:localhost:888 root@remotehost

Anschließend haben wir im Browser ganz einfach Zugriff auf https://localhost:8080 und können bequem die Einstellungen vornehmen, ohne uns vorher mühsam auf dem Server einzuloggen und in der Konfiguration des RAID-Controller-Dienstes (3dm2 wäre das in diesem Fall) den Remote-Zugriff zu aktivieren, was ja auch unter Umständen ein Sicherheitsrisiko sein kann.

Wenn wir die SSH-Session, die beim Login mit hergestellt wird, beenden, ist das Forwarding automatisch wieder deaktiviert. Zu beachten ist noch, dass lokale Ports kleiner als 1024 nur von root belegt werden können. Dafür gibt's aber i.d.R. keinen Grund ..

Weitere Info's dazu bekommt man im OpenSSH-Manual, mit SSH kann man nämlich noch viele weitere tolle Sachen anstellen, wie z.B. mit dem Schalter -X entfernte grafische Programme lokal auszuführen.

Es soll ja Leute geben, die löschen spontan /dev/null oder überschreiben es mit tollen Befehlen wie mv bla /dev/null. Mir ist das kürzlich witzigerweise auch passiert, da ich derzeit die LPIC-Zertifizierungen mache und daher viel am rumtesten bin. Da kann man schonmal die Shell der "echten" Box mit einer VM verwechseln. Wenigstens hat man die Lacher bei solchen Aktionen auf seiner Seite..

Normalerweise ist das kein Problem, so lange man es bemerkt. Wenn nicht, kann schnell mal die Festplatte vollaufen, schließlich schicken diverse Programme, Cronjobs usw. ihren Output nach /dev/null. Wie legen wir das nun also wieder neu an? Ein man null erklärt's:

mknod -m 666 /dev/null c 1 3
chown root:root /dev/null

Funktioniert einwandfrei und lässt uns vor lauter Freude gleich ein echo JUHUUUUU > /dev/null rufen
Mit /dev/zero funktioniert dies übrigens auch, siehe Manpage.

Bei einem meiner "Heavy Load"-Projekte nutze ich seit langer Zeit Pound als Loadbalancer und SSL-Proxy. In letzter Zeit sah ich allerdings immer mehr große Sites zu Nginx switchen, u.A. solche Größen wie wordpress.com. Das machte mich natürlich neugierig, so dass ich die Tage Nginx testweise auf einem der Loadbalancer aufsetzte, konfigurierte und testete.

Zuerst einmal muss man sagen, dass Nginx deutlich besser dokumentiert ist als Pound. Ich brauchte eigentlich keine weiteren Infos als das Wiki - für einen Pound-User nahezu ein Traum. Dort beschränkt sich die Doku eigentlich nur auf das Archiv der Mailingliste. Das kann u.U. sehr mühsam sein. Aufgrund der guten Doku war die Installation von Nginx aus den Sourcen (ich habe mich für die "stable" Version entschieden) sowie die anschließende Konfiguration kein Problem. Auch die Nutzung als SSL-Proxy lässt sich ähnlich wie in Pound konfigurieren, d.h. dass Nginx die SSL-Anfragen annimmt und als normale HTTP-Anfragen an die Backends weiterleitet. Der User bemerkt davon natürlich nichts und befindet sich permanent auf einer "normalen" SSL-Seite.

Ansonsten war die Umstellung eigentlich sehr einfach. Zu beachten ist bei Nginx, ebenso wie bei Pound, die Erhöhung des ulimit via Initscript, um Meldungen wie "too many open files" zu umgehen. So konnte Pound nun beendet und Nginx gestartet werden. Da als Server ein Quad-Opteron zum Einsatz kommt, habe ich Nginx mit 4 "Worker Processes" konfiguriert, um alle Cores optimal zu nutzen.

Das Ergebnis kann sich sehen lassen:



Wie man sieht, ist die CPU-Last massiv gesunken. Um mehr als die 2/3 mindestens, und dass obwohl zum Testzeitpunkt ziemlich viel los war auf dem Loadbalancer (~600-800 requests/sek). Die Load auf dem Server ist dauerhaft unter 0.1. Einfach genial, wenn man das mit der recht hohen CPU-Last und einer Load von 0.5-0.8 von Pound vorher vergleicht.

Für das Monitoring habe ich auch direkt ein paar nette Cacti-Templates gefunden, die prima funktionieren. Abschließend kann ich mich eigentlich nur fragen, warum ich nicht gleich Nginx genommen habe? Pound lief zwar jahrelang stabil und zuverlässig, die deutliche höhere Last und die schlechte Dokumentation von Pound sprechen aber eindeutig für den Einsatz von Nginx als Loadbalancer auf Sites mit hoher Last.

Nachdem mir Vista Business durch massive Arbeitsverweigerung und gähnende Langsamkeit auf diesem Mini-Vaio (im Grunde ein Netbook, nur teurer *g*) massiv auf die Nerven ging, habe ich kurzerhand Vista durch Ubuntu 9.04 ersetzt.

Die Installation ging, wie von Ubuntu gewohnt, einfach und schnell. Als Dateisystem habe ich hier erstmals das neue ext4-Filesystem gewählt. Allerdings konnte ich beim normalen Einsatz keine merklichen Unterschiede feststellen, große Datei- oder Ordnerstrukturen habe ich natürlich nicht. Natürlich (man muss als Linux-Fan sagen: leider) funktionierte folgende Hardware nicht auf Anhieb nach der Installation: das eingebaute Globetrotter UMTS/HSDPA-Modem, das eingebaute Mikrofon und die Motion-Eye Webcam. Die Cardreader habe ich noch nicht getestet, würde mich allerdings nicht wundern, wenn die auch nicht gingen.

Glücklicherweise wurde immerhin der Draft-N WLAN-Chip erkannt, so dass ich Updates und weitere Pakete via WLAN nachinstallieren konnte. So bekam ich nach einiger Foren-Lektüre die Webcam mit einem Treiber aus irgendeinem SVN zum laufen. Nach weiterer Lektüre fand ich dann heraus, dass man via in /sys/devices/platforms/sony-laptop/ befindlicher Files jeweils mit den Werten 0 oder 1 das WLAN, WWAN (UMTS), DVDRW, Bluetooth usw. steuern kann. Das UMTS-Modem aktiviert man dann also via echo 1 > sys/devices/platforms/sony-laptop/wwanpower. Funktioniert, aber wie bitte soll man denn z.B. als Anfänger darauf kommen? Hier hätte ich mir eine Auto-Detection bzw. Einstellungen dazu im Ubuntu-Kontrollzentrum gewünscht.

Nachdem jetzt die WWAN-Lampe bei mir brennt, konnte die Verbindung ins Netz hergestellt werden. Leider taugte der Gnome-Network-Manager trotz angeblichem UMTS-Support dazu nicht, da er schlicht immer das falsche Modem-Device verwendete (korrekt wäre /dev/ttyUSB0, er versuchte es immer mit /dev/ttyUSB1). In Ermangelung eigener Einstellungs-Möglichkeiten testete ich es dann mit wvdial (funktionierende Config für T-Mobile gibts hier). Das klappte auch problemlos, allerdings fehlte mir hier ganz klar die Anzeige der Empfangsstärke bzw. des Service (GPRS/EDGE/UMTS/HSDPA), der am Standort anliegt. Außerdem hätte ich eine weitere Lösung finden müssen, um den verbrauchten Traffic zu monitoren.

Dazu fand ich nach einer Weile das ultimative UMTS-Tool für Linux, nämlich umtsmon. Das Binary funktioniere auch auf anhieb unter Ubuntu und erkannte sogar das Modem (ein Neustart war allerdings nötig, da wvdial das Modem nicht korrekt freigab). Anbei mal ein Screenshot, denn das Tool lässt quasi keine Wünsche offen. Daran kann sich T-Mobile mit seinem lächerlichen "web'n'walk Manager für Windows" mal ein Beispiel nehmen. Man kann verschiedene Profile verwalten (Für TMO lautet der APN dann "internet.t-mobile"), SMS versenden und sogar eine Warnschwelle für das Kontingent festlegen. Einziger Wermutstropfen ist, dass ich das Programm nur als root zum laufen bekomme. Als normaler User startet startet es zwar, kann dann aber keine PPP-Verbindung aufbauen. Damit kann ich aber leben.

Wenn ich jetzt noch das eingebaute Mikrofon zur Arbeit bewegen kann, könnte ich sogar mit Video von unterwegs aus skypen. Schon toll, über was für Selbstverständlichkeiten man sich als Linux-User doch voller Erwartung freuen kann. Aber dieses "Gefrickel" macht natürlich auch Spaß - mir zumindest. Und für die tägliche Arbeit mit der Bash und einem Browser ist die Ubuntu-Lösung deutlich angenehmer und schneller zu bedienen als das träge Vista Business. Vom gefühlt 5 mal so schnellen Bootvorgang ganz zu schweigen.

Mein kleines Tool um Debian Systeme automatisiert upzudaten, UPDIAN, wird ja bereits von einigen Leuten erfolgreich eingesetzt. Ich benutze es natürlich auch noch nahezu täglich. Da es kürzlich das Update auf Debian Lenny gab, habe ich mich kurzerhand dazu entschlossen, UPDIAN zu erweitern.

So verfügt es nun über Multi-SSH. Damit ist es möglich, ein beliebiges Shell-Commando auf allen eingetragenen Servern auszuführen. Im Beispiel des Distributions-Upgrades war das apt-get dist-upgrade. Die Ausgabe der einzelnen Server wird wie gewohnt geloggt.

Bei Interesse findet sich UPDIAN in der aktuellen Version auf: http://klikics.de/updian/

Für alle Pidgin-User unter Debian oder Ubuntu war heute früh erstmal Stress angesagt, Pidgin funzt nämlich nicht mehr. ICQ hat wohl mal wieder die User von Fremdsoftware ausgesperrt, was ja schon öfter der Fall war. Leider stellen weder Debian noch Ubuntu bisher Pakete für die aktuelle Version 2.5.5 bereit, immerhin gibts aber schon einen Bugreport auf pidgin.im.

Wer nicht von Hand compilen will, findet auf getdeb.org fertige Ubuntu-Pakete (zuerst den Rest, dann erst das Pidgin-Paket installieren). Sicherheitshalber habe ich die Pakete auch hier nochmal in einem Archiv zusammengefasst, erfahrungsgemäß hielt zumindest pidgin.im dem Ansturm bei den letzten dieser Änderungen seitens ICQ nicht stand

Download hier (8,9 MByte): pidgin_2.5.5_getdeb.tar.gz

Manchmal ist es nötig, diverse Files in einem Arbeitsgang umzubenennen. So war dies vorhin zum Beispiel nötig, um mehrere hundert Digicam-Bilder mit der Endung .JPG in .jpg umzubenennen, da ein Joomla-Gallery-Plugin nur Bilder mit *.jpg erkennt. Klar hätte man auch das Plugin bearbeiten können, umbenennen erschien hier aber die einfachere Lösung zu sein. Anstatt mühsam ein Bash-Script mit einer Schleife zu schreiben, kann man auch einfach das nette Programm mmv (Multiple Move) benutzen (zu haben als Debian- und Ubuntu-Paket via apt).

So ist es mit dem simplen Befehl

mmv -v '*.JPG' '#1.jpg'

ganz einfach möglich, sämtliche Bilder umzubenennen. Da reguläre Ausdrücke unterstützt werden, ist man mit mmv sehr flexibel, in unserem Fall bleibt durch den Platzhalter #1 auch der Dateiname vor der Endung erhalten.

Ein ganz anderes Problem sind die ständigen Scans und Bruteforce-Angriffe auf offene SSH-Server (Port 22). Zwar sollte man generell SSH von außen (zumindest als root) verbieten oder zumindest den sshd auf einem Port >1024 lauschen lassen, dies ist aber nicht in jedem Fall möglich. Abhilfe schafft hier DenyHosts, da es nach einer definierbaren Anzahl von fehlerhaften Logins die IP des potentiellen Angreifers in die Datei /etc/hosts.deny einträgt, woraufhin das System Netzwerkverkehr von dieser IP aus nicht mehr annimmt. Nach einer ebenfalls konfigurierbaren Zeitspanne werden die IP's dann auch automatisch wieder entfernt.

Aktuell umfasst auf dem entsprechenden System hier die Anzahl der Einträge stolze ~800 IP's mit steigender Tendenz - und zwar seit heute 0 Uhr! Dabei wird eine IP nach 3 fehlerhaften Logins gesperrt. Da sich auch Mailreports verschicken lassen, stach mir dadurch direkt der folgende Eintrag ins Auge:

Added the following hosts to /etc/hosts.deny:
174.129.96.xxx (ec2-174-129-96-xxx.compute-1.amazonaws.com)

Da wird doch nicht etwa eine gemiete Computing-CloudFront von Amazon's Webservices versucht haben, sich hier via SSH Zugang zu verschaffen? Aber klar, es handelt sich dort auch nur um *nix-Systeme, die von irgendwelchen Admins gemietet und gewartet werden, soviel ich weiss. Somit kann es gut sein, dass eine Reihe davon mit Rootkits versehen ist oder zumindest nicht mehr komplette unter der Kontrolle des eigentliches Admins steht ...

Jeder, der mehrere Linux-Server unter seiner Verwaltung hat, kennt sicher das Problem namens Logfiles. Sie fallen zu Dutzenden an und müssen in regelmäßigen Abständen kontrolliert werden. Denn ohne diese stetigen Sichtungen blieben die meisten Bugs, Sicherheitslöcher und andere Hard- und Softwareprobleme mit Sicherheit unentdeckt. Während natürlich bei 1-2 Servern locker von Hand die gängigen Logfiles unter /var/log durchgesehen werden können, stellt dies bei beispielsweise 50 Servern ein echtes Problem dar. Denn kein Admin hat Zeit und Lust, hier täglich die Logfiles zu checken und nach Problemen zu schauen.

Aber natürlich gibt es dafür Abhilfe. So steht unter Linux beispielsweise syslog-ng bereit, womit man die Logfiles ohne viel Aufwand auf einen zentralen Loghost lenken kann. Das ist schonmal die halbe Miete, allerdings entsteht hier schnell das Problem mangelnder Übersichtlichkeit. Schließlich kommen bei ein paar dutzend Servern schnell mehrere zehntausend (!) Log-Einträge pro Tag zusammen. Die hat man dann zwar zentral auf einem Server liegen, kann aber anhand der Masse dennoch keine einzelnen Einträge sinnvoll filtern. Glücklicherweise kann man syslog-ng aber recht einfach dazu bringen, die ankommenden Log-Zeilen in eine Datenbank zu schreiben - hier kommt MySql zum Einsatz, andere DB-Server sollten aber ebenso funktionieren.

Um die Datensätze aus der DB übersichtlich via Web darzustellen, waren hier testweise diverse Webinterfaces für syslog-ng im Einsatz. So richtig überzeugen konnte allerdings Keines davon. Teils waren sie zu langsam, teils zu unübersichtlich. Deshalb haben wir uns entschlossen, ein eigenes Interface in PHP zu schreiben, welches die Daten aus der MySql-DB ausliest. Darin ist es problemlos möglich, nach einzelnen Hosts, bestimmten Events (Alert's z.B.), Programmen (Postfix, Apache etc.) oder Zeiträumen zu filtern. Auf dem Screenshot ist beispielsweise zu sehen, was das PHP-Plugin "Suhosin" an sicherheitsrelevanten Ereignissen auf mehreren Webservern abgefangen hat. Nett ist auch die Livelog-Funktion, die via AJAX immer die neusten Logs auf den Schirm bringt. Quasi ein tail -f auf alle Logfiles via Web ...

Und weil die Anwendung recht hilfreich ist, stellen wir sie natürlich der Allgemeinheit gern zur Verfügung. Eine detaillierte Anleitung meines Kollegen Ronny Tiebel zur Installation samt Downloads findet sich wie gewohnt drüben im AdminWiki. Fragen und Probleme können hier gern aufgegriffen werden.

Server, vor Allem unter Linux, laufen ja bekanntlich recht stabil und lange - auch ohne Reboot. Generell wird ein Reboot im Normalfall ja nur nach einem Kernelupdate nötig. Ich habe allerdings einen Debian-Etch Server laufen, der inzwischen eine beachtliche Uptime zu bieten hat. Da kann man locker von 100% Verfügbarkeit im ganzen letzten Jahr sprechen:

~# uptime
09:16:04 up 501 days, 13:45, 1 user, load average: 0.00, 0.02, 0.07

Gegen die Erstplatzierten des "Tugs Uptime Projects" habe ich damit noch keine Chance, gleich gar nicht gegen die ewige #1 mit 2 Jahren und 4 Monaten. Aber wer weiss, noch ist auch auf dem Server hier kein Reboot in Sicht. Das ursprüngliche Uptime-Projekt unter uptime-project.net ist ja leider vor knapp einem Jahr eingestellt worden.

In den dortigen Top10 ist sogar ein Win2000-Server mit SP4 vertreten, ja sogar ein XP ist mit über einem Jahr Uptime im Rennen. Da möchte ich lieber nicht wissen, für wieviele Angriffe der momentan offen steht. Vermutlich hängt er aber, wie mein Uptime-Mitstreiter, im internen Netz und ist von außen nicht erreichbar. Alles Andere wäre in gewisser Weise schon fahrlässig.

In der Topliste ist mir auch die große Anzahl von Debian-Systemen sofort aufgefallen. Das liegt wohl an den langen Release-Zyklen und natürlich auch an der Stabilität. Mein System beispielsweise ist nahezu auf dem neuesten Etch-Releasestand, nur ein einziges Kernelupdate fehlt. So läuft aktuell noch Kernel 2.6.18-5-amd64, unter /boot wartet aber schon die Version 2.6.18-6-amd64 auf ihren Einsatz. Da es aber keinen wirklichene Grund dafür gibt, lasse ich das System natürlich erstmal laufen. Zumindest bis zum nächsten Hardware- oder Stromausfall. Vielleicht schaff ichs damit mal in die Top3 beim Uptime-Contest ...

Eurem Einkauf kann ich übrigens folgende Hardware für Langzeiteinsätze empfehlen:
Chainbro Barebone Gehäuse mit Tyan Thunder Mainboard, Dualcore-Opteron's 2216 HE, WD Raptor SATA Platten samt 3Ware-8000-PCIx RAID-Controller

Achja, selbst mein Ubuntu-Desktop hier hat auch schon eine beachtliche Uptime zu bieten - der wird aber spätestens beim nächsten Release in 04/09 neu gestartet:

rob@dresden:~$ uptime
09:34:01 up 57 days, 22:31, 8 users, load average: 0.29, 0.28, 0.24

Wenn man auf mehrere Server exakt die gleichen Befehle absetzen will, kann das schnell nervig werden. Dies kann aber z.B. bei Updates, Paket-Installationen oder Config-Änderungen auf identischen Servern recht oft nötig sein. Sofern man nicht Zeit und Lust hat, verschiedene Terminals zu öffnen, um dort die Befehle einzeln abzusetzen (oder sonstwelche Tools zur Verteilung im Einsatz hat), kann man auch zu ClusterSSH greifen.

Damit ist es einfach und komfortabel möglich, an beliebig viele Hosts via SSH die gleichen Befehle abzusetzen. Das spart in manchen Fällen doch einige Arbeit. Ich habe mit recordmydesktop mal eine solche Session aufgenommen. Da leider sämtliche meiner Versuche scheiterten, das Video bei YouTube oder Vimeo im HD-Format hochzuladen (in den heruntergerechneten Formaten erkennt man leider überhaupt nichts), hier ganz klassisch mal der Downloadlink zu dem 7,6MByte großen .ogv-File (OGG-Video-Container, 1680 x 1040): cluster-ssh.ogv

Ubuntu ist nah dran am perfekten Linux oder auch Betriebssystem ansich. Aber auch hier gibts ein paar Sachen, die immer mal wieder nerven und womöglich recht einfach zu fixen wären. So habe ich, seitdem die 8.10 auf verschiedenen Rechnern bei mir läuft, immer wieder Probleme mit nautilus. Der GNOME-Dateimanager verschlingt in unregelmäßigen Abständen jede Menge CPU-Zeit und bremst das System merklich aus (siehe htop-Screenshot).

Da hilft dann nur ein beherztes "kill prozess_id" auf der Konsole, woraufhin sich nautilus in den meisten Fällen neu startet. In seltenen Fällen half sogar nur ein kompletter X-Neustart. Das Problem tritt auf mehreren Rechnern mit unterschiedlicher Hardware auf und ist daher wohl schlichtweg ein Bug. Da sich der Spaß nicht wirklich reproduzieren lässt, macht das eine Lösung schwer. Ich vermute einen Zusammenhang zwischen SMB-Verbindungen und dem Problem, da es öfter beim Durchsuchen von SMB-Freigaben auftritt.

Ein weiteres Ärgernis sind Probleme mit dem Synaptic-Touchpad meines Dell-Latitude. In unregelmäßigen Abständen zwingt mich ein Fehler in "psmouse.c" zu einem Reboot, da das Touchpad danach komplett tot ist. Via demsg erscheint dann der folgende Fehler:

psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 3

Auch hier scheint bislang keine Lösung verfügbar zu sein. Gängige Foren und Bugreports schieben das Problem auf den Powersaving-Daemon, der dynamisch die Taktrate der CPU-Core's anpasst. Bewiesen oder gelöst ist das aber offenbar noch nicht. Bis dies der Fall ist, bleibt in der Tat nur der Wechsel auf eine Text-Shell (via STRG + ALT + F-Taste 1 bis 6) samt dortigem Reboot. Ärgerlich und nervig. Wenigstens kann man seine geöffneten Programme vorher noch mit der Tastatur schließen und eventuelle Änderungen speichern.

Apropos "Foren". Bei der Suche nach Lösungen erheiterte mich das offizielle Ubuntu-Forum ubuntuforums.org immer wieder mit Proxy-Fehlern. Das Forum wird offenbar für den Lesezugriff komplett auf Proxy's zwischengespeichert, um die Server nicht mit unnötigen PHP- und Datenbankberechnungen zu quälen. Keine schlechte Idee, wenns denn funktioniert.

Also liebe Windows-User, ihr seid nicht die Einzigen mit fehlerhaften Betriebssystemen und Problemen bei der täglichen Benutzung. Dennoch halte ich Linux natürlich die Treue, denn Ubuntu ist sowohl für den Arbeitslaptop als auch für den Büro-Desktop bei mir die erste Wahl. Und wenn diese sowie einige andere Fehler noch behoben würden, kämen wir der Perfektion wieder ein Stück näher ...

So, genug gejammert für den heutigen Tag. Allerdings wäre ich gespannt, ob der eine oder andere Leser ebenfalls "Ubuntu-Gejammer" beisteuern kann ...

Da freut man sich über das Ubuntu-Update auf Firefox 3.0.5 und installiert es natürlich sofort, nur um sich dann zu ärgern. Nach dem benötigten Browser-Neustart direkt die Ernüchterung: keine Fensterrahmen sind mehr zu sehen. Das heisst, ich kann das Fenster nicht minimieren, schließen oder sonstwas. Mit der Tastatur funktioniert es glücklicherweise noch (STRG+W). Komischweise scheint nur Firefox betroffen zu sein, die restlichen Anwendungen starten problemlos mit Fensterrahmen.

Da ich auf die Schnelle im Netz keine Lösung für das Problem gefunden habe, bleibt nur die Deaktivierung vom Compiz unter "Erscheinungsbild" in den Einstellungen. Dazu stellt man einfach auf "Normal", was sämtliche optischen Animationen deaktiviert. Witzigerweise funktioniert es, wenn man erst Firefox mit den normalen Einstellungen startet und anschließend wieder die Effekte aktiviert. Nach einem erneuten Firefox-Neustart besteht das Problem allerdings weiterhin. Da bleibt also doch vorerst nur der Dauerbetrieb meines Laptops hier oder halt doch lieber der Verzicht auf die netten Effekte.

Falls Jemand eine Lösung hat, bitte Bescheid geben. Ich werde jetzt auch nochmal googlen ...

PS:
Ein Kollege berichtete eben, dass bei ihm das Problem nur im Zusammenhang mit Flash auftritt. Soll heissen, dass bei ihm der Rahmen z.B. beim Besuch von YouTube verschwindet. Das ist wenigstens etwas besser als bei mir, aber trotzdem unschön. Ein Flash-Update für Linux steht derzeit leider auch nicht zur Verfügung.