Linux

Hin und wieder schleichen sich nicht nur in Programmen, sondern auch in der Hardware Fehler ein, die es zu erkennen gilt. Linux reagiert in solchen Fällen meist mit einer Kernel-Meldung (zu sehen via dmesg) wie beispielsweise dieser hier:

[1437691.115778] Machine check events logged

Das sagt leider nicht wirklich viel aus darüber, was da nun eigentlich los ist bzw. los war. Sofern der Server noch stabil läuft, gibt es nicht gleich Grund zur Panik! Mit dem Tool mcelog kann man sich dann allerdings die gespeicherte Fehlermeldung ausgeben lassen.

Das sieht dann z.B. so aus:

MCE 0
HARDWARE ERROR. This is NOT a software problem!
Please contact your hardware vendor
CPU 0 1 instruction cache TSC b2404f941ca12
memory/cache error 'evict mem transaction, instruction transaction, level 1'
STATUS 9000000000000171 MCGSTATUS 0

Hier sehen wir immerhin, dass es sich um ein Hardwareproblem handelt, in diesem Falle hatte offenbar der Speicher ein Problem. Da das Problem aber hier nur einmal auftrat und seitdem nie wieder, bin ich noch nicht tätig geworden. Sollten derartige Fehler allerdings periodisch oder gehäuft auftreten, sollte man die Hardware austauschen bzw. auf Fehler prüfen, z.B. mit memtest.

Es ist allerdings natürlich sehr mühsam, auf dutzenden Servern permanent dmesg oder mcelog von Hand auszuführen. Aus diesem Grund hat mein Kollege ein kleines Script geschrieben, welches uns die Arbeit abnimmt. Als Cronjob laufend prüft es periodisch die Ausgabe von dmesg auf beliebig vielen Servern und meldet im Falle von neuen MCE's per Mail die Ereignisse. Dies ist überaus nützlich, zumal normalerweise jede MCE nur einmal aufrufbar ist. Nachdem mcelog einmal ausgeführt wurde, ist der Puffer nämlich sonst wieder leer.

Das Tool samt einer ausführlichen Anleitung gibts drüben im Adminwiki - Rückfragen können gern auch hier gestellt werden ...

Ich habe heute eine Upload-Funktion mit PHP gebaut, da fiel mir auf, dass Firefox 3.0.4 seltsamerweise ab und zu PDF's mit dem MIME-Typ "text/html" versieht. Dies ist natürlich nicht korrekt, denn PDF's sollten den Typ "application/pdf" besitzen. Leider kann ich nicht sagen, wann genau dies geschieht bzw. warum. An einem bestimmten PDF liegt's nicht, ich habe es mit unterschiedlichen Daten versuch

Im Opera unter Ubuntu sowie Firefox 3.0.4 und IE unter Windows funktioniert das gleiche Script problemlos, d.h. der MIME-Typ wird dort korrekt dargestellt. Um einen Fehler im Distributions-Firefox von Ubuntu auszuschließen, habe ich nochmal den Firefox direkt von mozilla.com versucht - das selbe Problem, allerdings auch nur zeitweise und nicht direkt reproduzierbar.

Derzeit scheint mozilla.com bzw. https://bugzilla.mozilla.org/ nicht erreichbar zu sein (wenn man's schonmal braucht ...). Sobald die Seiten wieder da sind, werde ich dieses Problem reporten. Das Uploadscript muss ich derweil wohl oder übel anpassen, so dass es von Linux-Clients auch Files vom Typ "text/html" annimmt. Sonst macht zumindest die MIME-Prüfung beim Upload keinen richtigen Sinn mehr ...

Das lokale System bzw. das Test-PDF scheinen auch in Ordnung zu sein:

rob@robtop:~$ cat /etc/mime.types | grep pdf
application/pdf       pdf

rob@robtop:~$ file test.pdf
test.pdf: PDF document, version 1.4

Was ist denn bei MySql/Sun eigentlich los? Erst wird hastig die GA (Generally Available) von Version 5.1 (aka 5.1.30-RC) released, also die Version für den produktiven Einsatz, dann meckert Monty auch noch öffentlich über die falsche Release-Politik und die Arbeitsbedingungen bei Sun rum.

Ich muss zugeben, ich war selbst auch verwundert über plötzliche Veröffentlichung der 5.1.30 als GA, schließlich sind noch rund 20 offene Bugs im Bugtracker zu finden. Dennoch läuft die 5.1 seit Version 5.1.22-RC bei mir im Produktiveinsatz, und das inzwischen (mit der 5.1.29-RC) auch recht stabil. Anfangs gabs zwar 1-2 Bugs, die mir negativ auffielen, die sind aber inzwischen allesamt behoben. Sowohl im Single-Betrieb mit mysqld und MyISAM-Tabellen als auch im Cluster-Betrieb (ndb_mgm und ndbd) kann ich keine echten Probleme mehr feststellen - auch unter starker Last nicht.

Insofern scheint mir die Kritik etwas überzogen zu sein - obwohl Monty wahrscheinlich weiss, was er schreibt. Er steckt schließlich ganz gut in der Materie drin. Er fordert wieder mehr Macht und Antrieb von der Community, z.B. durch freie Forks wie Drizzle. Ich muss sagen, die Idee hinter Drizzle gefällt mir auch sehr gut. Man wird sehen, was sich daraus entwickelt.

Im Oktober hatte erst MySql-Mitbegründer David Axmark gekündigt, da er sich in einem Großunternehmen wir Sun nicht mehr wohl fühlte. Ich kann es ihm nachfühlen ...

Eben las ich die für mich als Linuxfan freudige Nachricht, dass nach dem iPod (ipodlinux.org) auch das iPhone mit Linux läuft. Zwar läuft es nur sehr puristisch, d.h. keine Treiber für WLAN, den Touchscreen, Bluethooth usw. - aber es läuft immerhin, wie man auf dem Video sehen kann. Und dank Bootloader kann man jederzeit wieder auch die normale Apple-Firmware booten, ohne vorher technischen Aufwand betreiben zu müssen.

Generell ist es ziemlich cool, Linux auf alle möglichen technischen Plattformen zu portieren. Natürlich stellt sich die Frage nach dem Sinn, benutzbar wird wohl in diesem Fall auch nie richtig werden. Dazu ist die ursprüngliche Oberfläche einfach zu schön und ausgereift. Aber interessant ist es auf jeden Fall

In der Vergangenheit waren ja die Linux-Implementierungen auch manchmal deutlich besser als das Original. Man denke da nur an XBMC, das MediaCenter für die alte XBOX damals. Absolut traumhaftes Programm, welches ich samt XBOX heute noch im Einsatz habe Ohne XBMC wäre die alte Konsole wahrscheinlich schon längst im Keller gelandet.

Die iPhone-Variante scheint sich sogar recht einfach installieren zu lassen (Anleitung), allerdings werden wohl wichtige Teile des NOR-Speichers überschrieben, um den Boatloader zu installieren. Das vorher erstellte Backup sollte man daher unbedingt sicher verwahren. Mir ist das ehrlichgesagt zu heiss, da ich auch kein Gerät übrig habe derzeit. Es kommt übrigens Ubuntu 8.10 zum Einsatz, natürlich in ARM-Architektur entsprechend der ARM-CPU im iPhone.

Bin sehr gespannt, was da noch auf uns zukommt, Linux rocks on ...

Sehr interessiert verfolge ich seit einiger Zeit die Entwicklung von MySql-Cluster 6.4, also der nächsten Generation. Die aktuelle 6.3.19 läuft zwar sehr schnell und stabil, dennoch gibt es noch Raum für Verbesserung und Optimierung. So bringt die 6.4 endlich das online hinzufügen von Nodes mit sich, so dass man dazu nicht den ganzen Cluster stoppen muss. Das macht die Skalierung sehr viel handlicher und minimiert die Downtimes enorm. Außerdem werden endlich Threads unterstützt, so dass man aus einem Server mit mehreren CPU's bzw. Core's endlich sinnvoll auslasten kann. Aktuell langweilen sich sämtliche CPU's/Core's fast die ganze Zeit, während auf einem die Hauptlast liegt.

Im Blog eines Entwicklers der MySql-AB kann man nachlesen, dass 8 Core's dann wohl die Idealbesetzung sind. Ein Glück, dass ich damals Boards mit 2 CPU-Sockeln in den Nodes verbaut hab

Vielversprechend sind auch die Benchmark-Werte aus Jonas's Blog, so erreichte er gestern in Tests mit SCI-Karten stolze 1 mio. reads/s - auf einem Node! Man kann sich vorstellen, was so ein Cluster mit 64 oder gar 128 Nodes dann beantworten kann. In der Theorie dann sogar 100 mio+ reads/s. Angeblich will er mit TCP-Optimierungen dann auch via Ethernet solche Werte erreichen (1000 bzw. 10000 MBit/s). Würde mir natürlich sehr gefallen, denn in meinen 1HE-Kisten ist kein Platz mehr für SCI-Karten

Im Laufe der Zeit habe ich die verschiedensten Caching-Methoden ausprobiert, um irgendwelche Web-Applikationen zu beschleunigen. In der Regel will man damit Datenbanken entlasten, vor Allem wenn gleiche Query's tausendfach ausgeführt werden. Allerdings ist es in manchen Fällen so, dass der Aufwand den Nutzen nicht rechtfertigt bzw. sogar die Last durch das Caching höher ist, als durch die ursprünglichen Abfragen. Ich will hier mal am Beispie einer klassischen WebApp mit MySql-Backend ein paar Caching-Varianten samt meinen Erfahrungen darstellen. Zuerst einmal 2 Methoden, wie man mit MySql-Bordmitteln schon etwas erreichen kann:

Der MySql Query Cache speichert direkt auf dem MySql-Server die Ergebnisse einzelner Query's und liefert bei erneuter Abfrage nur das Ergebnis aus, ohne die Datenbank selbst erneut zu durchsuchen. Ganz abgesehen von den üblichen Limitierungen wie RAM und Anzahl der Query's im Cache ist das eigentliche Problem hier, dass nach JEDER Änderung in der entsprechenden Tabelle (INSERT/UPDATE) die Ergebnisse neu aus der Datenbank gelesen werden müssen (siehe z.B. hier). Somit fällt für mich der dieser Cache maximal unter "nice to have". Eine unter Last stehende Datenbank (in die meistens auch immer UPDATES oder INSERTS kommen) kann er aber wohl kaum entlasten ...

Eine weitere Alternative sind Tabellen vom Typ MEMORY. Leider unterstützt MEMORY keine BLOB- oder TEXT-Spalten, was sie z.B. für Volltextsuchen ungeeignet macht. Dennoch sind sie eine gute Alternative, wenn der DB-Server aufgrund vieler komplexer Abfragen sehr häufig auf die Festplatte zugreifen muss. Für Session-Tabellen beispielsweise ziemlich gut geeignet. Man sollte allerdings nicht vergessen, dass die Last nicht gänzlich vom DB-Server weggenommen wird, schließlich muss er die Anfragen weiterhin beantworten. Auch spielt natürlich der auf DB-Servern meist nur wenig vorhandene, freie RAM eine Rolle.

Caching-Methoden, die sich außerhalb des SQL-Servers abspielen:

Zuerst einmal gibt es natürlich Flatfiles, also einfache Textdateien, in denen man temporäre Daten als Cache ablegen kann. Bei kleinen Ergebnismengen, keiner hohen Last auf dem jeweiligen System und ausreichender Plattenkapazität kann auch dies einen Gewinn bringen. Allerdings ist es oft nicht sehr elegant zu bewerkstelligen, die alten Files zeitnah zu löschen bzw. vorhandene Files zu aktualisieren. Ein Cronjob kann da z.B. natürlich Abhilfe schaffen, man sollte aber die Limitierungen des jeweiligen Filesystems im Bezug auf maximale Ordner- und Datenanzahl nicht vergessen. Außerdem steigt die Load auf einem Server sehr schnell an, wenn diese Files sehr oft und zahlreich geöffnet/geschlossen werden. Auch ulimit kann hier eine Rolle spielen, sofern zu klein gesetzt.

Dann gibt es natürlich noch SQLite, was sich z.B. für kleinere Sachen als Auslagerung sehr gut eignet. Allerdings stößt man bei größeren Sachen schnell an die Filesystem-Grenzen, außerdem hatte ich in meinem Anwendungsfall mit recht hoher Last auf dem System zu kämpfen, wenn sehr viele Abfragen (nur SELECT's) auf die SQLite-DB's eingingen (Zugriff via PHP/PERL). Da war in diesem Fall sogar dann die Speicherung in Flatfiles effektiver. Außerdem hat man wieder das Problem mit der Wartung, denn man muss dafür sorgen, dass in den SQLite-DB's stets halbwegs aktuelle Informationen aus der MySql-DB liegen - je nach Notwendigkeit.

Nun kommen wir zu meinem klaren Favoriten memcached. Ich habe es selbst zigfach im Einsatz und bin einfach begeistert. Vor Allem die eingebaute TTL ist wunderbar, so muss man sich nicht darum kümmern, alte Einträge mühsam zu entfernen etc. Auch läuft memcached sehr stabil, verbraucht quasi null Rechenleistung und kann wunderbar hunderte Anfragen parallel bearbeiten. Ein besseres Caching-System kann man sich kaum wünschen. Allerding sollte man die Limitierung von maximal 1 MByte je Objekt beachten. In der Praxis stößt man aber nur sehr selten an diese Grenze. API's für die gängigen Scriptsprachen stehen bereit, so dass man seine WebApp damit recht einfach mit effektivem Caching versehen kann. Natürlich braucht man, je nach gewünschter TTL und Menge der Objekte entsprechend Server mit viel freiem RAM. Ansonsten ist memcached eine klare Empfehlung! Ein weiterer Vorteil ist, dass selbst bei einem Ausfall des memcached-Servers die Applikation weiterläuft, nur eben ohne Caching. Dank der Möglichkeit, memcached-Server verteilt aufzubauen, sollte das aber i.d.R. nicht vorkommen.

Natürlich macht es nicht in jedem Fall Sinn, einen Cache zu verwenden. Wenn man eine Website mit 20 Besuchern am Tag hat, kann man sich beispielsweise getrost lieber SEO widmen als Caching Auch bei sich permanent ändernden Anfragen/Ergebnismengen macht ein Cache wohl kein Sinn. Aber überall, wo sich Anfragen über einen recht kurzen Zeitraum zigfach gleichen und die Last auf der Datenbank recht hoch ist, macht ein Cache vielleicht durchaus Sinn. Wichtig ist auch, dass die Infrastruktur noch fähig sein sollte, auch ohne den Cache auszukommen (bzw. den Ausfall zu kompensieren), zumindest teil- oder zeitweise.

Am Wochenende wurde endlich das Telco-Release von MySql 5.1.29-RC mit NDB 6.3.19 freigegeben. Es wurden massenhaft Bugs behoben (Changelog), weswegen ich es heut direkt eingespielt habe. Das ist immer ein Akt, es müssen schließlich zuerst alle Management-Knoten, dann alle NDB-Knoten und zu guter letzt alle Server, wo mysqld rennt, auf den neuesten Stand gebracht werden. Besonders lange dauert jeweils der Neustart von ndbd auf den NDB-Knoten. Je nach Speicherauslastung und Config kann dieser Spaß schnell mal eine Stunde dauern - je Node! Das nennt sich dann "Rolling Restart" und erspart einem, das ganze Cluster herunterzufahren, was logischerweisee mit einer Downtime der Applikation verbunden wäre.

Auf jeden Fall habe ich die Chance mal genutzt, um ein kleines Benchmark beim kompilieren zu fahren. Ich habe also einfach mal die Zeit gemessen, wie lange make von mysql-5.1.29-ndb-6.3.19 dauert. Konfiguriert wurde jeweils --with-ndbcluster.

Da ich nur auf 2 verschiedenen Servertypen (QuadCore Xeon's und 2x Dualcore Opteron's pro Server, je AMD64-Architektur) kompiliert habe, fallen die Ergebnisse recht klein aus. Oben erst immer noch ein Teil von /proc/cpuinfo, danach die Ausgabe von time make:

model name : Dual-Core AMD Opteron(tm) Processor 2216 HE
cpu MHz : 2394.091
cache size : 1024 KB

real 12m28.244s
user 10m16.459s
sys 2m9.580s

und

model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
cpu MHz : 3166.775
cache size : 6144 KB

real 8m52.463s
user 6m56.326s
sys 1m17.081s

Wenig überraschend, dass der Xeon schneller fertig ist. Ich finde den Vorsprung von 1/4 aber doch schon beachtlich. Mal schauen, was dann die neuen AMD-CPU's so bringen werden (wenn verfügbar).

Ich weiss, dass viele Admins "Lighty" wegen seiner teilweise höheren Geschwindigkeit dem Apache vorziehen. Leider konnten das meine Tests in der Vergangenheit nicht bestätigen. Aber man muss natürlich mehrere Szenarien probieren. Also gab ich "Lighty" erneut die Chance, sich gegen den Apache zu beweisen. Und zwar auf einem Server, der nur Suchvorschläge für die User ausgibt, ähnlich dem Prinzip auf Google Suggest. Dabei sind in unserem Umfeld ~200 Requests/sec. auf ein PHP-Script zu beantworten, welches einige SQLite Datenbanken abfragt und die Ergebnisse ausgibt. Im Grunde ein sehr einfaches Script, aber die Masse der Anfragen macht hier die Last aus. Peaks von 300-400 Requests/sec. sind durchaus möglich.

Als Umgebung kam ein Debian GNU/Linux 4.0 AMD64 (Kernel 2.6.18-4-amd64) Server mit 2 Stück Dual-Core AMD Opteron(tm) Processor 2216 HE (sagt cat /proc/cpuinfo | grep Opteron | head -n1) @ 2.4 GHz, 4 GByte RAM und 2x WD-Rapor SATA-Platten an einem 3Ware-8000 Controller zum Einsatz. Ich würde das als duchaus leistungsfähiges System bezeichnen.

Zuerst wurde Lighty via apt-get in Version 1.4.13-4etch1 samt xCache (aus Sourcen) und PHP 5.2.0-8+etch5~pu1 (eingebunden via FastCGI) installiert, was aber nicht wirklich gut funktionierte. Denn nach einigen Minuten ging die CPU-Last auf 100% und der Server reagierte nicht mehr wie gewünscht auf Anfragen. Nach einigen Recherchen im Wiki auf der HP von Lighty stieß ich dann auf den wahrscheinlichsten Grund, eine Lösung war leider nicht zu finden. Seltsamerweise trat das Problem in der anschließend von Hand kompilierten Version 1.4.18 nicht mehr auf, so dass der Server ca. 24 Stunden unter Last durchlaufen konnte. Die Load bewegte sich bei 3.x im Schnitt und alle Anfragen wurden schnell beantwortet. Allein die Prozessanzahl war mit mehreren hundert PHP-Prozessen etwas hoch (8 Lighty-Prozesse mit je 64 PHP-Prozessen waren konfiguriert), was aber kein Problem war. Änderungen an der Anzahl der PHP-Prozesse brachten keinerlei Veränderungen an der Last.

Nun konnte der Apache in Version 1.3.34-4.1 (Debian-Paket) samt PHP-Modul libapache-mod-php5 in Version 5.2.0-8+etch5~pu1 zum Einsatz kommen. Statt xCache habe ich hier den eAccelerator v0.9.5.2 aus Sourcen zum Einsatz gebracht. Die Konfiguration gefiel mir sowieso deutlich besser also bei Lighty, schließlich kenne und benutze ich Apache seit vielen Jahren. Auch scheint mir das Finetuning hier etwas genauer möglich zu sein, zumindest was KeepAlive etc. angeht. Das KeepAliveTimeout wurde also auf 5 sec. gesetzt, MinSpareServers auf 15, MaxSpareServers auf 25 - die anderen Werte habe ich nicht verändert. Der Apache läuft nun seit rund 48h im Dauertest und hat eine mittlere Load von 2.x. Alle Anfragen werden ebenfalls problemlos beantwortet. Außerdem ist die Prozessanzahl deutlich geringer, da für PHP als Modul keine FastCGI-Prozesse "gespawnt" werden müssen wir bei Lighty.

In beiden Webservern wurde übrigens alle überflüssigen (also quasi alle ausser fcgi bzw. PHP) Module für den Test deaktiviert. Abschließend kann ich nur sagen, dass ich hier erneut keinen Vorteil für Lighty verbuchen kann und daher Apache auf diesem Server im Einsatz bleibt. Aber vielleicht finde ich ja noch das ideale Szenario für Lighty

In der aktuellen iX geht es (wieder einmal) um Spamfilterung. Viel kann man dabei heutzutage mit Blacklist-Abfragen bzw. Hash-Listen erreichen, die sich in alle gängigen MTA's bzw. Spamassassin einbinden lassen. Also habe ich direkt mal iXhash bei mir im Spamassassin eingebunden, eine Liste die von der iX gepflegt und bereitgestellt wird. Das Ganze gestaltet sich recht einfach, ist aber schlecht dokumentiert. Daher habe ich direkt mal einen kleinen Howto-Eintrag dazu im kürzlich wieder gestarteten AdminWiki gemacht Bisher habe ich durch diese recht kleine Liste (rund 40k Einträge im Mittel) zwar noch keine Treffer erzielen können, es hat aber auch keine negativen Folgen und funktioniert reibungslos.

Die diversen von mir gewarteten Mailschleudern basieren alle auf dem sehr schönen Howto von workaround.org, also auf Debian, Postfix als MTA, Dovecot als POP3(S)/IMAP(S) - Server und amavisd-new als Schnittstelle zu Spamassassin und ClamAV. Außerdem wurden die Installationen durch kleine Erweiterungen wie dem von mir geschriebenen Spamreporter-Script erweitert. Und ich muss sagen, es funktioniert vorzüglich - kaum noch Spams, False-Posivites oder Probleme. Die User sind alle zufrieden und der Admin dementsprechend auch Und die Wartung ist dank der Zuarbeit meines Kollegen Ronny auch denkbar einfach, er hat für die Konstellation von workaround.org kürzlich ein kleines Verwaltungsscript in PHP geschrieben, mit dem man über ein Webinterface neue Domains, User und virtuelle Aliase anlegen kann. Solltet ihr euch also noch mit Textfiles rumschlagen, wird es Zeit für ein Update auf postfix-mysql samt o.g. Konfiguration!

Nach diversen Problemen mit den Marvell-GBit-NIC's (siehe Posting hier weiter unten) in verschiedenen Thomas-Krenn Servern habe ich nun offenbar eine Lösung gefunden: Das Debian-Paket linux-image-2.6.22-2-686 aus dem Lenny- Zweig. Dieses lässt sich auch unter Etch installieren und scheint den Fehler mit ständigigen Hängern des sky2-Modules zu beheben. Zumindest läuft der entsprechende Server mit Netzwerkdurchsatz von ~15 MBit/sek. seit dem Update völlig problemlos (an einem 100 MBit-Switch - im GBit-Betrieb sollte es aber ebenfalls behoben sein).

Etwas verwirrend ist allerdings, dass sich offenbar im Kernel 2.6.22 eine ältere Version den Treibers befindet, nämlich die 1.14. Zumindest ist auf der Konsole mit dem 2.6.22er Kernel zu lesen:

~# dmesg | grep sky2
sky2 0000:02:00.0: v1.14 addr 0xdedfc000 irq 16 Yukon-EC (0xb6) rev 2

Auf einer Debian-Maschine mit 2.6.18-5-686 hingegen scheint Version 1.5 aktiv zu sein (die nur Probleme macht):

~# dmesg | grep sky2
sky2 v1.5 addr 0xdedfc000 irq 169 Yukon-EC (0xb6) rev 2

Die Version spielt hier aber keine Rolle, solange die Server stabil im Dauereinsatz laufen und nicht aller $kleine_zahl Tage die Netzwerkkarte hängt. Eigentlich sollte das eine Selbstverständlichkeit sein, aber leider scheint hier das Debian-Team ein wenig hinterherzuhängen - schließlich ist im aktuellen Etch immernoch bzw. schon wieder der seit Jahren bekannte Fehler vorhanden. Auf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396185#102 sind zumindest weitere Berichte zu finden.

Leider haben wir in diversen Servern von Thomas-Krenn NIC's der Marke Marvell Yukon2 Gigabit LAN auf dem Board, meist zusätzlich zu einem Intel Pro 100[0]. Keine Ahnung, warum hier nicht einfach 2 Intel-Chips draufgepackt wurden, schließlich gibts damit so gut wie keine Probleme. Der Marvell-Treiber sky2 macht hingegen unter Linux seit Ewigkeiten Probleme - bei mir auch noch im aktuellen Etch-Kernel 2.6.18-5-686. So kennen viele User folgenden Fehler:

NETDEV WATCHDOG: eth0: transmit timed out
sky2 eth0: tx timeout
sky2 eth0: transmit ring 263 .. 240 report=263 done=263
sky2 hardware hung? flushing

bzw. diesen "Auswurf" in /var/log/messages:

Nov 1 18:09:43 hostname kernel: sky2 status report lost?
Nov 1 18:10:41 hostname kernel: sky2 eth0: disabling interface
Nov 1 18:10:46 hostname kernel: sky2 eth0: enabling interface

In der Praxis geht dann mit dem Interface gar nichts mehr und es hilft nur ein Reboot oder manchmal auch ein rmmod sky2 && modprobe sky2, womit das Modul neu geladen wird. Mir ist dabei aufgefallen, dass Interfaces mit mehr Traffic den Fehler eher aufweisen. So rennt der das exakt identische Modul auf einigen Servern mit kaum Traffic auf dem jeweiligen Interface völlig problemlos, wo es hingegen auf anderen Servern mit Traffic von durchschnittlich 10 MBits/sek. aller 2-3 Tage zu obigem Fehler kommt. Angeblich soll die nächste Kernel-Version das Problem fixen, wünschenswert wäre es auf jeden Fall. Ansonsten sehe ich mich gezwungen, zumindest in diesem einen Server hier noch eine Intel Pro 1000 einzubauen und die Marvell auf dem Board zu deaktivieren. Oder gibts noch einen Trick, den ich bisher nicht herausgefunden habe?

Auf dem selben Server ist via dmesg auch noch folgender Fehler zu lesen:

BUG: warning at kernel/cpu.c:51/unlock_cpu_hotplug()
[] unlock_cpu_hotplug+0x2c/0x54
[] sched_getaffinity+0x67/0x6e
[] sys_sched_getaffinity+0x1f/0x41
[] sysenter_past_esp+0x56/0x79

Das scheint allerdings keine negativen Auswirkungen zu haben. In diversen Mailinglisten findet man zumindest viele User, die diesen Fehler auch bekommen. Wenn man Leidensgenossen hat, ist es gleich nur noch halb so schlimm

Leider ist die Sommerzeit wieder zu Ende, so dass in dieser Nacht die Uhren um eine Stunde zurückgestellt werden mussten. Unter Linux übernimmt das erfahrungsgemäß der ntpd automatisch, der sich auf Debian im Paket ntp-server verbirgt. Die Umstellung hat auch problemlos geklappt - nur cacti, mein installiertes RRD-Graphing Tool, kam damit nicht so ganz klar, wie folgende Grafik zeigt:



Ich kann das aber durchaus verstehen, denn schließlich kann cacti nun wirklich nicht wissen, dass auf einmal eine Stunde doppelt vorkommt
Für die "manuellen" Umsteller unter uns gibts unter http://www.uhrzeit.org/atomuhr.html eine zuverlässige Uhrzeit. Armband- und Küchenuhren tun sich ja mitunter schwer bei der Installation von ntp-server.

Auf unseren Webservern (32 Bit Debian Etch) mit je 8 x Xeon E5310 hatte ich bisher den Debian-Kernel kernel-image-2.6-em64t-p4-smp im Einsatz. Allerdings konnte ich via dmesg immer irgendeinen ACPI-Bug bewundern, der aber offenbar den Betrieb nicht weiter beeinflusste. Schlimmer war jedoch, dass der 3dm2 nicht funktionierte, so dass ich über einen Plattendefekt im 3Ware-RAID5 nicht informiert worden wäre. Sämtliche Tests mit den Files von 3ware.com und den Debian-Paketen von Jonas Genannt (http://jonas.genannt.name/) scheiterten, obwohl diese auf anderen Servern problemlos rennen. An dieser Stelle gleich mal einen lieben Dank an Jonas für die Pakete, schließlich sind diese auf allen Servern hier installiert.

Nunja, also setzte ich testweise den Kernel linux-image-2.6.18-5-686 auf einem der Server auf und siehe da, der 3dm2 ließ sich problemlos installieren und das Webinterface zeigte mir den Controller samt Platten an. Die Installation glückte zwar auch schon mit dem anderen Kernel, nur stand nach dem Login dann "NO CONTROLLERS" da. Auch der seltsame APCI-Fehler trat seither nicht mehr auf, ich hoffe das bleibt so. Ansonsten kann ich mit diesem Kernel keine Unterschiede erkennen, die Serverapps laufen problemlos wie zuvor. Es scheint also, ob ob ein 64 Bit-Kernel unter Umständen Probleme auf einem 32 Bit-System machen kann. Es gibt aber in diesem Fall eigentlich auch keinen Grund für 64 Bit, denn die Maschinen laufen nur mit je 2 GByte RAM und Apache als Hauptanwendung.

Die seit einer Weile bekannte Lücke in openssl wurde gestern endlich auch vom Debian-Team mit neuen Paketen behoben. Zwar habe ich jetzt keinen direkten Exploit gesehen, aber besonders bei solchen Sachen bin ich mit Updates immer ganz schnell

Seit meinem Release von Updian (siehe ein paar Postings vorher) zum automatischen Update von Debian-Servern verfolge ich, wie sich das bei Google in den Ergebnissen verbreitet. Es gab nämlich bisher nur sehr wenige Treffer zu "Updian" bei Google bzw. im europäischen Raum gar keine. Inzwischen gibts schon einige Treffer und ich bin gespannt, wie das weitergeht

Ich bin übrigens ab morgen eine Woche im Urlaub (Sonne, ich komme!) - in diesem Sinne bis bald und euch ebenfalls eine schöne Zeit

Jeder Admin, der dutzende Server zu betreuen hat, steht irgendwann vor dem Problem, dass die Distribution regelmäßig auf den neuesten Stand gebracht werden muss. Sei es durch Weiterentwicklung der installierten Pakete oder - was besonders kritisch ist - durch Patches für Sicherheitslücken. Einzeln auf jeden Server zu gehen kann da nach einer Weile schon ganz schön nerven, vor Allem wenn man beispielsweise den Testing-Tree (Lenny) von Debian einsetzt. Aber auch bei Stable (Etch) gibt es schonmal Updates, die dann auf allen Servern eingespielt werden müssen.

Zu diesem Zweck habe ich in in PHP "Updian" geschrieben, was für "DebianUpdater" steht. Man könnte es als minimalistischen Update-Manager für Debian bezeichnen, denn es ist damit möglich, diverse Server in kurzer Zeit auf den neuesten Stand zu bringen. Updian stützt sich dabei natürlich auf "apt-get". Das Management der Updates geschieht in einem einfachen Webinterface, wo man in einer Übersicht die Server aufgelistet bekommt, welche Updates bereithalten. Ein Klick auf den Server zeigt detailliert die Pakete samt Versionsnummern an, für die es Updates gibt (siehe Screenshot). Man kann also einfach auswählen, auf welchen Servern der Update-Cronjob beim nächsten Durchlauf ein apt-get upgrade ausführt. Die entsprechenden Ausgaben kann man sich unter "Logs" anschließend ebenfalls im Webinterface anschauen. Ebenfalls ist es möglich, die bei der Automatisierung störende Nachfrage bei neuen Versionen von Config's zu unterdrücken und immer die aktuelle Version zu behalten.

Es ist erforderlich, dass der passwortlose Zugriff via SSH vom Updian-Server auf die "Clients" konfiguriert ist, damit Updian seine Befehle absetzen kann. Diverse andere Einstellungen kann man in der mitgelieferten config.php anpassen. Updian versendet auf Wunsch auch eine Infomail an den Admin, wo es über neue Updates informiert. Weitere Infos und Installationshinweise finden sich in der beigelegten README.txt. Da ich bisher der einzige User dieser Software bin, habe ich es als v0.1 beta released, man sollte also nicht zuviel erwarten. Es erfüllt aber bisher hervorragend seinen Zweck

Über Anregungen, Feedback usw. zu dem kleinen Tool würde ich mich sehr freuen. Mir jedenfalls hat es schon eine Menge Arbeit erspart, vielleicht hilft es Dir ja auch

• Website von "Updian"
  
• Screenshot vom Webinterface