a sysadmin's life

Eine nette WD Raptor 10krpm SATA 73,4GB Disk:

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%       600         -
# 2  Short offline       Completed without error       00%       599         -
# 3  Extended offline    Completed: read failure       10%       598         144523362
# 4  Short offline       Completed: read failure       10%       598         144523362
# 5  Short offline       Completed: read failure       10%       598         144523362

Die spontane Wunderheilung wurde durch komplettes dd'en der Platte ausgelöst (was dann in der Folge vermutlich zum Sector remapping führte). Die Platte ist aus der Garantie raus, in ein Produktionssystem kommt die mir nicht mehr. Aber als Spoolspace für irgendwelche unwichtigeren Dinge dürfte die noch ganz gute Dienste leisten.

Am letzten Samstag war es soweit: Eine Ära ging zuende und der letzte Server verließ meine Wohnung in Richtung Rechenzentrum. Der Plan war eigentlich recht einfach: Die techn in ein neues Gehäuse pflanzen, die Systemplatten am 3ware durch ein paar größere Platten im gmirror an den internen SATA Ports ersetzen, Daten überspielen und die Downtime dann gleich noch für ein FreeBSD-Update nutzen.

Nach dem Frühstück fuhr ich in die Schloßstraße zu Acom, um noch schnell ein Y-Kabel zu kaufen, da mein neues Netzteil zwar viele SATA-Stromstecker (die ich aufgrund meines SATA-Gehäuses nicht brauchte), aber wenige herkömmliche Stromstecker hatte. Dann kamen noch ein paar letzte Vorbereitungen, dann der shutdown.

Der Umbau ins neue Gehäuse klappte ohne Probleme, nach dem Einschalten partitionierte ich die neue Platte (die zweite sollte dann mittels gmirror insert später folgen), dann fing ich an, die Daten zu kopieren. Das dauerte natürlich so seine Zeit. 2 Stunden oder auch ein wenig mehr.

Beim Booten fingen die Probleme dann an. Kernel nicht gefunden? Bootloader nicht gefunden? Was ist los? Lesefehler auf diversen Sektoren. Na toll, die Platte ist im Eimer. Vor einer Woche gekauft, das erste mal in Betrieb. Kann ja heiter werden. Ein SMART Test endet mit Lesefehlern (der short Test, der normal NIE was findet!). Ich versuche die Daten zu überschreiben, nach einer Sekunde kommt vom dd "end of device". Ahja.

Ich baue die Platte aus, gehe zu Acom, erkläre mein Problem und bekomme die Platte (Samsung...) ohne weiteres getauscht. Während ich warte erkläre ich einem Gespann aus zwei Acom-Mitarbeitern die Grundzüge von Redundanz mit einem RAID 5 bzw. einem RAID 6, da Unsicherheit herrschte, ob zusätzliche Platte die Redundanz dort erhöhen würden.

Zu Hause packe ich die Platte ins System, partitioniere, starte den SMART Test diesmal vorher. Der short offline test failed. Er failed auch auf der zweiten Samsung Platte. Ich denke kurz über das BIOS nach, das hatte mit den zwei WD 1-TB-Platten allerdings keine Sorgen. Ich boote nochmal - beide Platten melden sich konsistent mit einer Größe von 32 MB (was genau der Cache-Größe entspricht), darauf geschriebene Daten sind beim nächsten mal nicht mehr zu finden und der SMART test failed bei beiden Platten beim exakt gleichen LBA. Übrigens ein und demselben wie bei der Platte, die ich bereits zurückgebracht habe. Ein anderer Controller, selbst ein anderer Rechner ändert am Ergebnis nichts: Ich habe zwei RAM-Disks mit 32 MB Größe...

Ich stehe mit beiden Platten bei Acom, bin jetzt das dritte mal an diesem Tag hier. Ich befürchte schon Schlimmes - wenn mir ein Kunde so kommen würde, würde ich mir ja auch erstmal meine Gedanken machen. Der Mitarbeiter am Tresen hört sich mein Problem an. Noch bevor er etwas sagen kann kommt von der Seite ein anderer Acom-Mitarbeiter (oder der Chef oder sonstwer) und tönt: "Das kann gar nich sein! Wir verkaufen da viele von und keiner hat Probleme! Sie müssen das mit FAT32 formatieren!!!" In meinem Kopf formuliert sich gerade ein passender Gegenschlag zu diesem ausgewachsenen Blödsinn von der Seite - nicht nur, daß das technisch von vorn bis hinten falsch war, aber man sagt auch einem Kunden nicht ins Gesicht, daß man ihn für dumm hält - doch der Mitarbeiter, der mich bedient rettet die Situation, indem er klarstellt, daß der 32-MB-Bug bei den Samsungs sehr wohl bekannt sei. Er testet die Platten und bestätigt mein Ergebnis nochmal.

Er bietet mir an, die Austausch-Platten erst an einem Rechner schnell zu testen - ich lehne aber dankend ab, denn das Problem trat (zu seiner Überraschung) bei mir teilweise erst nach mehrmaligem Booten auf und bestehe darauf, die Platten gegen WDs (gegen Zahlung der Preisdifferenz) zu tauschen. Der gute Mensch erkennt wohl meine Verzweiflung ob der vorgerückten Stunde und willigt trotz einigen administrativen Aufwands ein. Ich zahle meine 10 EUR, packe die Platten ein und gehe nach Hause. Der letztlich problemlose Umtausch und die Bemühungen meines Gegenübers trösten mich über den dummdreisten Spruch seines Kollegen hinweg.

Es ist 19:38 Uhr, Samstag abend, seit fast 8 Stunden ist gruft offline und noch sind keine Daten überspielt. Ich schraube die erste Platte in den Rahmen des RAID Sets. Ich hole die zweite Platte aus der Tasche, will sie auch gerade einschrauben... "Samsung"... "SAMSUNG"???? Was zur Hölle ... ich hab hier meine zwei alten Samsung-Platten und nicht die WDs. Es ist 19:42 Uhr. In 18 Minuten macht Acom zu. Ich greife zum Telefon. "Mein" freundlicher Mitarbeiter erzählt mir, daß er mich noch im SSC gesucht hatte und sogar versucht hatte anzurufen (ich hatte die Nummer nicht weiter gelesen, sondern dachte, daß war ein versuchter Anruf von Timo nach einem Gesprächsabbruch auf der Voicemail). Ich frage, ob er auch 10 Minuten nach acht noch da wäre, er sagt "ja, klar, das bin ich Ihnen schuldig!" - der Mann ist wirklich gut, daß nach all dem Chaos die falschen Platten in der Tüte landeten ist menschlich, das nehm ich ihm nicht übel.

Um 20:05 Uhr bin ich das vierte mal bei Acom im SSC. Ich kriege meine WDs im Tausch gegen die Samsungs ausgehändigt. Der Mitarbeiter, der mir morgens das Y-Kabel verkaufte grinst mich an und meint: "Das vierte mal hier???" - "Ja, mein persönlicher Rekord für einen Tag..."

Zu Hause schraube ich die Platten rein und fange an zu kopieren. Endlich geht alles. Timo kommt vorbei, wir essen erstmal was beim Schwaben gegenüber.

Nach dem Kopieren der Daten gibt es noch kleinere Boot-Probleme von der Platte. Schließlich piepst gruft nichtmal mehr beim Anschalten. Durch Karten mischen, RAM fest drücken und gutes Zureden läßt sich das Problem aber auch beheben (ich kenn das schon, wechselt man an dem Board einmal die Hardware...). Das FreeBSD-Update kneif ich mir, wir bringen den Kasten ins Rechenzentrum. Um 00:15 Uhr verlassen wir selbiges, Timo bringt mich noch nach Hause. Während die Dienste noch alle runtergefahren sind, synchronisieren sich die Platten. Sonntag morgen wird alles wieder hochgefahren.

War das eine Odyssee ... und da liegt noch ein Stück Weg vor uns!

Nach einigem Zögern hatte ich mich heute entschlossen, mein Nokia E90 mit der neusten Firmware (ja, die aus dem letzten Jahr) zu versorgen. Also flugs noch ein aktuelles Backup auf die Speicherkarte geschrieben, die Speicherkarte aus dem Handy gezogen und ab an den nächsten verfügbaren Windows-Rechner.

Zunächst zickte das Update-Programm auf dem EeePC etwas rum, aber im dreitten Versuch hat es dann schlußendlich geklappt und ich war beruhigt.

Also zurück zum Schreibtisch, die Speicherkarte ins Handy und schnell das Backup wieder zurückspielen... Äh - was? Die Speicherkarte ist paßwortgeschützt?! Also bei aller Liebe, das sollte ich vielleicht mal tun - aber ich hab es nicht getan. Genau aus der Angst heraus, im Zweifelsfall nicht an mein Backup zu kommen. Eine kurze Suche im Netz ergab nichts sinniges. Zweifel kommen auf. Hab ich doch ein Paßwort gesetzt? Ich probiere die üblichen Kandidaten für solche Fälle durch. Nichts. Ich probiere die unüblichen Kandidaten für solche Fälle durch. Auch nichts. Der Rechner mag die Karte im Kartenleser auch nicht mehr erkennen. Panik macht sich breit.

Ich hab dann ertsmal eine Runde Sport getrieben um das Adrenalin aus meinem Körper zu bekommen. Dann noch etwas gegessen, um Proteine nachzuschieben. Dann intensiver gesucht. Password-Recovery nicht möglich. Bei neueren S60 3rd Handys keine Chance. Mit viel Glück kriegt man die Karte formatiert, um unter verlust aller Daten wenigstens die Hardware weiternutzen zu können.

Und dann kam der entscheidende Fund in den Tiefen der Google-Ergebnisse. Die S60 3rd Edition Telefone haben ein nettes Feature: Man kann einstellen, das Handy per SMS zu locken. Das ist praktisch im Falle eines Diebstahls oder wenn man es mal irgendwo liegen läßt. Wendet man das Feature an, so muß man das Handy mit dem Entsperr-Code wieder entsperren, der gleiche, den man auch für die Timeout-Funktion (locken mit Code nach x Minuten) nutzt.

Der Trick: Wenn man das Handy per SMS lockt, dann wird die Karte mit dem SMS-Lock-Code geschützt! Das ist sicher sinnvoll, denn natürlich will ich nicht, daß in dem Falle jemand einfach die karte in ein anderes Nokia schiebt und mal meine Daten recovered. Allerdings kam es für mich deutlich unerwartet, daß die Karte dann plötzlich ein Paßwort hat. Das merkt man sonst auch nie, weil sich das handy nämlich das Paßwort im Normalfall irgendwo merkt und folglich nie danach fragt.

Toller Trick...

Ohne groß drumherum zu reden: Mein Arbeitgeber erlaubt mir, mich nach neuen Kollegen umzusehen:

• Sysadmin im ISP Umfeld, Unixoide Ausrichtung
• Enterprise-Windows-Spezialist
• Netzwerk-Guru, Cisco aber auch *ix basierte Lösungen

Wer sich da angesprochen fühlt, der darf mich gerne irgendwie kontaktieren für die Details.

Datacenter. Die Geräuschkulisse entspricht der anheimelnden Athmosphäre, die ein startender Düsenjet verbreitet. Das allein würde bei den meisten menschen schon genügen, um sie innerhalb kürzester Zeit zur Überzeugung zu bringen, daß man an diesem Ort keine fünf Minuten arbeiten möchte. Fünf Minuten? Nicht wirklich genug, um 16 Platten aus einem RAID zu schrauben, zu beschriften und 16 neue Platten in die gleichen Rahmen wieder reinzuschrauben und sie einzusetzen. Das ist eher so eine Sache, die eine Stunde dauert. Damit die Sache aber nicht zu eintönig wird, wenn man auf dem kalten Boden vor dem Array sitzt hält so eine große Ansammlung Rechner durchaus ein paar Ablenkungen bereit. Beeee-beep! Achja, da wär ja noch ein kleinen RAID 10 in dem Server, wo ein Rebuild fällig ist. Also schnel auf den Controller zugreifen und das nervtötende Gepiepse abschalten und den Rebuild starten. Beeeeeeeeeeeeeeeeeeeeeeeeee..... Das eintönige Dauerpiepen, laut, durchdringend, genau aus dem Server neben meinem Ohr läßt sich prinzipell auch abschalten. Indem man das defekte Netzteil (redundant, es braucht ja Strom zum piepen!) ersetzt. Prinzipiell deswegen, weil natürlich kein Ersatzteil im Schrank liegt. Also piept es weiter. Die ganze Zeit.

Nachdem wetter.com sich kürzlich entschlossen hat, einen öffentlichen Beta-Test ihres neuen Designs zu machen, wollte ich ein netter Nutzer sein und ein Feedback geben. Nämlich daß dank super genialer moderner Technik ich auf der neuen Seite die Animation des Wetterradars nicht mehr anschauen kann (im Gegensatz zu einem einfachen, ressourcenschonenden Animated GIF auf der alten Seite. Flugs also das Webformular unter "Kontakt" ausgefüllt und schon kurz danach ... kam ein Out-of-Office Autoreply eines persönlichen Accounts bei der betreuenden Medienagentur.

Echt mal Jungs, das sollten wir nochmal üben. Und automische Out-of-Office Replies sind kein sonderlich guter Stil.

Manchmal fragt man sich, wer heute alles DNS Zonefiles anfassen darf. Und nach einer komplett verkorksten Konfiguration wundert man sich dann noch, warum man dem ein oder anderen keine Mails schicken kann.

Die Meister des Tages: pikolo.de

Warum beschwert sich der exim, wenn ein Absender diese Domain benutzt... Na schauen wir doch mal:

> host -t mx pikolo.de
pikolo.de mail is handled by 10 mx.pikolo.de.

Hmm. Sieht doch eigentlich gut aus.

> host mx.pikolo.de
mx.pikolo.de has address 85.25.61.100
mx.pikolo.de is an alias for w3.pikolo.de.
w3.pikolo.de is an alias for w3.pikolo.de.
mx.pikolo.de is an alias for w3.pikolo.de.
w3.pikolo.de is an alias for w3.pikolo.de.

Achso. Ja, nee, klar. Kapitalfehler: ein CNAME gemischt mit anderen RRs, in diesem Fall einem A Record. Viele ordentliche Nameserver würden diese Zone so nichtmal laden. Gut, das ist vielleicht schon ziemliches Expertenwissen. Aber mit einem kleinen Funken Logik hätte einem zumindest der zweite Fehler auffallen können: w3.pikolo.de als CNAME w3.pikolo.de zeigen zu lassen macht nun auch keinen Sinn. Und wenn wir schon dabei sind: ein MX darf auch nicht auf einen Namen zeigen, der ein CNAME ist. Nein, wirklich nicht.

Übrigens, der RR für www.pikolo.de sieht auch nicht viel besser aus. Aber die Clients werden's schon richten.

Liebe pikolos, nächstes mal bezahlt lieber jemanden dafür, der sich damit auch auskennt.

Auf dem Heimweg von einer Geburtstagsfeier erfreute uns die S-Bahn (OK, es war natürlich nur die Anzeige im Wagen!) damit, daß sie bei der Anzeige eines bestimmten Datensatzes reproduzierbar in einen Fehler lief - und anschließend bootete:

Nachdem vor einer Woche, am 02.05.2007, in Berlin am Hohenzollerndamm ein Telekom Verteilerkasten explodiert war, hatte ich ja schlimmste Befürchtungen über die Gründe geäußert. Eine nähere Beschäftigung mit dem Vorfall bestätigte die naheligendste Erklärung:

Eine Anfrage bei der Pressestelle der Berliner Polizei zum Stand der kriminaltechnischen Ermittlungen ergab folgendes: Aus einer unter dem Bürgersteig verlaufenden Gasleitung war Gas ausgetreten, das sich im folgenden, vermutlich durch die Anschlußkanäle für die Kabel des Verteilerkastens, in selbigem ansammelte. Ein Schaltvorgang im Kasten (z.B. Lüfter einschalten oder vergleichbares) brachte das zündfähige Luft-Gas-Gemisch schließlich zur Explosion. Die Ermittlungen sind derzeit noch nicht abgeschlossen, konzentrieren sich aber im wesentlichen auf die Frage, ob die ausgetretene Gasmenge im Toleranzbereich war oder ob es sich um eine stärker beschädigte Leitung handelte.

Die Pressestelle der T-Com kommentierte den Vorgang wie folgt:

Von den Multifunktionsgehäusen und ihrem Innenleben geht keinerlei Gefahr aus. Die Multifunktionsgehäuse werden weder mit Gas, Hochspannung oder explosiven oder gefährlichen Stoffen betrieben. [...] Mit dem Gehäuse oder der Technik von T-Com hat die Explosion somit glücklicherweise nur am Rande zu tun. Auch wir sind bestürzt über den entstandenen Schaden und sehr erleichtert, dass keine Personen zu Schaden gekommen sind.

Und für alle Verschwörungstheoretiker, die jetzt vermuten, daß die Pressestellen da lediglich eine Panik verhindern wollen (ich schließe ja schnell mal von mir auf andere - was würde ich mich fragen, wenn ich das lese?): Die Spuren der Aufräumarbeiten unterstützen diese Aussagen, der halbe Bürgersteig war aufgebuddelt, um an in der nähe befindliche Leitungen zu gelangen.

Nach heutigem Erkenntnisstand also einfach nur ein Unfall, ausgelöst durch eine Kette von unglücklichen Ereignissen. Wir können wieder vorbeigehen an den Kästen, die uns das noch schnellere DSL bescheren.

Ich möchte mich hiermit bei dem Leser meines Blogs bedanken, der mir die Antwort der T-Com weitergeleitet hat, sowei Herrn Hafenrichter von der T-Com, der das Zitat bezüglich der Verteilerkästen gegeben und genehmigt hat. Auch inen Dank an die Pressestelle der Polizei, von der ich bereits kurz nach meiner Anfrage telefonisch mit den obigen Informationen versorgt wurde.

Es gibt da einen Dienst, der es immer wieder in sich hat, was die vielfältigen Möglichkeiten angeht, ihn absolut fehlerhaft zu konfigurieren. Es handelt sich um einen POP3-Sammeldienst. Eigentlich keine große Sache: Man gebe Server, Username und Paßwort eines Accounts an und eine Ziel-Adresse. Die Mails werden per POP3 aus dem einen Account abgeholt und dabei wahlweise gelöscht und auf den anderen ausgeliefert.

Der Klassiker: Man hole die Mails von held@ge-em-ix.de ab und leite sie weiter an ... richtig: held@ge-em-ix.de. Das ergibt einen wunderbaren Mailloop, der zunächst zu einer wundersamen Vermehrung von Mail führt, im schlimmstkonfigurierten Falle zu einem Verlust.

Der Klassiker, Profi-Version: Man hole seine Mails von held@ge-em-ix.de ab und liefere sie an held@schnafoo.de aus. Auf held@schnafoo.de konfiguriere man eine Weiterleitung auf ... richtig: held@ge-em-ix.de.

Mailvernichtung, Alzheimer Art: Man hole seine Mails von held@ge-em-ix.de ab und liefere sie an h.held@schnafoo.de aus. Aber eigentlich nur, weil man vergessen hat, daß man eigentlich die Adresse hans.held@schnafoo.de hat.

Mailvernichtung, Penible Art: Man nutze den Service, weil man die Sache mit der Weiterleitung nicht verstanden hat und hole die Mail vom eigenen Account ab. Beim Einrichten befolgt man die bebilderte Anleitung auf's penibelste und trägt - wie auf den Bildern der Anleitung zu sehen - als Zieladresse (und das ist jetzt exakt das, was da drin stand, keine Anonymisierung!) user@beispiel.de ein.

Immer wieder ganz großes Kino.

Manchmal versucht so ein Häufchen aus Silizium und Plastik klüger zu sein, als es wirklich ist. Man nehme als Zutaten für den folgenden Anfall von Intelligenz: Einen Cisco Aironet Access Point, einen Netgear Power over Ethernet Switch und einen Cisco 2924 Switch. Verbindet man den Aironet mit dem PoE-Switch (der Netgear ist "dumm", also nicht managebar, er soll lediglich Strom liefern), dann passiert, was man erwartet: Der Access Point bootet, man kann ihn konfigurieren, er stellt fest, daß genügend Strom für alle Funktionen an seinem Port zur Verfügung steht. Prima!

Irgendwann ist die Konfiguration dann komplett und bereit, in ein vorbereitetes Netzwerk eingeklinkt zu werden. Was also tut der sachkundige Admin? Er konfiguriert auf dem zentralen 2924 einen Port, die die fraglichen Netze bereitstellt und verbindet diesen mit dem Uplink-Port des Netgear. Das, was nun folgt, kommt allerdings gänzlich unerwartet: Der Access Point stellt den Betrieb seiner Funkschnittstellen unversehens ein - wegen Mangel an Strom, wie man der Consolen-Meldung entnehmen kann. Aber Mangel an Strom? Wie bitte? Der 2924 hat doch ein eigenes Netzteil, den kann man gar nicht über PoE versorgen - wieso also mangelt es dem Access Point also plötzlich an Strom?

Des Rätsels Lösung: Der Cisco Switch sendet CDP Pakete mit diversen Infos. Der Netgear als dummer Switch leitet diese Pakete einfach nur weiter. Folglich denkt der Access Point, er hinge an Port Fas 0/19 des 2924 - der laut CDP allerdings kein Power over Ethernet zur Verfügung stellt. Der AP denkt also, er hätte nun gar keinen Strom und stellt lieber schnell seine Radios aus (mit passender Log-Meldung). Auf die Idee, daß dies zu loggen ihm nur gelingen kann, solnge er denn in Wirklichkeit noch Strom bekommt, kommt der AP allerdings nicht.

Die Sache ist relativ einfach lösbar (dies wird in der Logmeldung auch vermittelt), indem dem AP mitgeteilt wird, daß er unabhängig von CDP Konfigurationen davon ausgehen möchte, daß dort ein Inline Power Injector den Strom liefert. Ich frage mich allerdings an wievielen Stellen das nicht in der Konfiguration steht, weil an dem dummen PoE Switch kein weiterer Cisco Switch hängt. Dort könnte man ja spaßeshalber mal versuchen, ob man so eine WLAN Wolke mit ein paar gezielten CDP-Falschmeldungen nicht einfach ohne jegliche sonstigen Zugriffsrechte abschalten kann...

Auf einem unserer Switches fiel vor kurzem auf, daß eine MAC-Adresse zwischen zwei Interfaces flappt. Seltsam: An beiden Interfaces hängen einzelne Maschinen, keine hat die fragliche MAC. Eine rennt unter Windows, die andere unter FreeBSD.

Die aufgetauchte MAC paßte zu einem Intel bzw. MSI GigE Interface, aber zu nichts bei uns. Nichts, was wir kannten. Und nichts, was auf den fraglichen Ports hing. Ein tcpdump auf einem der fraglichen Ports förderte dies hier zu Tage:

blackbox# tcpdump -vni em0 ether host 00:0c:76:4e:04:c8
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
21:53:49.027909 arp who-has 172.16.100.103 (ff:ff:ff:ff:ff:ff) tell 172.16.100.103

Immer und immer wieder. Das fragliche Netz (und die fraglichen Rechner) haben ganz normale offizielle IPs, keine 172.16er. Nichts, was dem auch nur ähnlich sieht.

Und wer das jetzt für seltsam hält, der sollte sich dieses Posting vom anderen Ende der Welt mal durchlesen. Oder dieses.

Ja, da gibt es Leute, die haben exakt die gleiche MAC und IP Kombination aus ebenso unerklärlichen Gründen in ihren Netzwerken gesehen - und nie eine Lösung gefunden.

Mystisch.

Micro$oft hat eine Marktlücke entdeckt. Eine völlig neue Geräteklasse: Den Origami. Nicht so groß, wie ein Notebook, nicht so klein wie ein PDA oder Smartphone, On-Screen-Keyboard, nicht sonderlich viele Tasten. Mit dieser Neuigkeit ist M$ einfach mal ein großer Wurf gelungen. Sowas gab's noch nicht.

Falls jemand die Beschreibung nicht genau genug fand: Also im Prinzip ist das Ding exakt das gleiche, wie mein (viele Jahre altes) Siemens Webpad, nur mit etwas modernerer Hardware.

Wer eine Digitalkamera hat, die brav die Brennweiten in die EXIF Tags schreibt und schon immer mal wissen wollte, ob er mehr zu Tele- oder zu Weitwinkelfotografie neigt:

find . -name "*.[Jj][Pp][Gg]" | xargs -n1 exiftags | egrep "^Focal Length" | sed 's/^.*\: \([0-9][0-9]*\).*/\1/' | sort -n | uniq -c | sed 's/^[ ]*//g' | tr " " ":"

Viel Spaß.

Nach einer Idee von Timo Fuchs, dessen Original in php ich kurzerhand in einen Shellaufruf umgewandelt habe.

Nachdem vor einigen Tagen ja das FreeBSD 6.0 RELEASE rausgekommen ist und ich im Vorfeld (eifrige Leser meines Blogs erinnern sich vielleicht) ja schon einiges an Tests gemacht habe, habe ich mir heute eine Dosis Adrenalin gegönnt:

Der erste Application Server des Core Systems ist heute auf RELENG_6 upgedated worden! Das Update (via Sourcen) habe ich komplett remote vorgenommen. Zunächst die neue Welt und den neuen Kernel bauen, dann den Kern installieren, im Singleusermode die Welt installieren und ein paar geringe Anpassungen vornehmen. Im Multiusermode habe ich die alten Libraries entfernt und alle installierten Pakete neu installiert. Auch hier gab es keine Probleme. Und so ist der Server jetzt mit allen Diensten wieder online.

Die Belastungsprobe kommt dann morgen, wenn die Maschine wieder mit ins Loadbalancing aufgenommen wird. Besonders gespannt bin ich auf den direkten Vergleich in der Performance gegenüber der gleichen Hardware unter FreeBSD 5.4-STABLE (SunFire V20z, Dual Opteron Maschinen), auch wenn ich bei der genutzten Software keine erheblichen Unterschiede erwarte, da nur wenig Threading im Spiel ist. Aber durch deutlich weniger Giant-Locking soll FreeBSD 6 ja durchaus gerade auf SMP-Systemen auch ohne Threads noch ein wenig an Performance nachlegen.

Es bleibt also spannend, Neuigkeiten gibt es sicher bald an dieser Stelle!