Seitics.de Weblog

In meinem ehemaligen Studentenwohnheim an der Hartmannstrasse in Erlangen gibt es einen Billard Raum, der zu meiner Zeit damals ständig versifft war. Darum ersann eine kleine Gruppe von Bewohnern ein Gerät, das den Zutritt zu dem Raum nur noch über einen sich verändernden Pincode erlaubte (neben einem normalen Türschlüssel für PIN-Unwillige), womit die Verursacher allerlei Schmutzes leicht anhand einer gespeicherten Zimmernummer herausgefunden werden konnten. Das Gerät scheint nach letzten Meldungen seine besten Zeiten allerdings schon hinter sich zu haben und ist nun nach vier Jahren Betrieb ausser Dienst gestellt worden.

Ihr findet den Quellcode für den AVR Microcontroller (um sämtliche Pincodes, Crypto-Keys, IP-Adressen usw. bereinigt) im Download Verzeichnis unter /pub/pinpad oder auch als ein grosses tar.gz-Archiv zum herunterladen. Die Sourcen sind von mir unter der BSD Lizenz veröffentlich. Ein kurzer Intro Text in englischer Sprache liegt auch bereit. Für eine optimale Anzeige des Quellcodes sollte euer Editor auf Tabstop=4 eingestellt sein.

Impressionen des Gerätes:

Nachdem ich jetzt jahrelang asketisch auf hartem Holz und einem uralten Bürostuhl aus der Metro gesessen bin, habe ich mir mal eine etwas bessere Sitzgelegenheit samt Hartbodenrollen bei Amazon geklickt.

Ich weiss nicht ob ich weinen oder lachen soll, aber ich kann nicht an mich halten und muss Jeff Atwood zu seiner Dummheit gratulieren.

Wie auch Fefe faktenfrei lamentierte, hat sich Jeff einen IBM/Lenovo Server gekauft und zwar ohne Festplatten. Nun bemängelt er, dass ihm Lenovo die benötigten Schlitten nur mitsamt Hard Disks verkaufen möchte und das zu "überhöhten" Preisen.

Da wir im Büro viel mit Lenovo und IBM zu tun haben, muss ich sagen: Selbst schuld. Und bevor es mir in den Kommentaren vorgehalten wird: Ja, wir verkaufen den Sjit auch. Aber wer die Branche nicht kennt, sollte sich kein Urteil anmassen und lieber Supermicro oder anderen "Whitebox" Krempel kaufen.

Zunächst ist die Hardware die er sich da zusammenklickte nicht verkehrt, denn jedes der echt wenigen Male wenn an einem IBM Server etwas kaputt ging, war das Ersatzteil oder ein Techie prompt zur Stelle und weiter gings. Nur hätte ihn jeder echte IBM Partner sofort auf die Festplatten hingewiesen, d.h. jetzt hinterher zu jammern zeugt nur davon, dass er sich vorher nicht über das Ding informiert hat. Das ist die erste Dummheit.

Die zweite Dummheit steckt in der Tatsache zu glauben, dass die Disks aus purer Profitgier teurer sind. Denn IBM gibt allen Serverbestandteilen (dazu gehören auch Festplatten) mindestens CRU mit, d.h. es kommt nach dem aufmachen eines sogenannten "Calls" bei IBM bereits nach wenigen Tagen, vorab, meist per UPS, eine Customer Replaceable Unit, eine vom Kunden austauschbare Einheit, also das Ersatzteil. Wenn er sich bei seinem Kistenschieber dagegen Festplatten ordert, heisst es dagegen wenn das Ding defekt ist, bitte einschicken. Aber welcher Eigentümer von so einem Server betreibt das Teil dann 2-6 Wochen ohne Ersatzfestplatte? Entweder ich benötige die Ausfallsicherheit und damit auch den zügigen Kundenservice, oder ich benötige sie nicht, aber wozu wurde dann der Server beschafft? Dann hätte auch ein Aldi PC als Datenbunker über die Windows Freigabe gereicht.

Nebenbei bemerkt kann man bei IBM eine sogenannte "Fixtime" auf bis zu vier Stunden buchen, die kostet dann natürlich entsprechend mehr Asche aber nach vier Stunden ist die Box, egal welches Bauteil es ist, repariert. Auch an Weihnachten oder im Hochsommer. Achtet mal darauf, wer "Reaktionszeit" und wer "Fixtime" in die Bedingungen schreibt. Reaktionszeit kann auch bedeuten: "Es ging jemand ans Telefon".

Der Dummheit Teil 3: IBM prüft die Festplatten auf Verträglichkeit mit dem System, denn ihr werdet es nicht glauben (aber ihr ahnt es sicher bereits): Die Chinesen haben manchmal nicht alle Bits im Register. Das geht dann von "Festplattensystem liefert I/O Fehler unter Linux alle 8 Wochen" aufgrund von fehlerhafter Drive Firmware bis hin zum eher harmlosen Problem eines nicht-funktionalen PFA Status. PFA?

PFA ist ein gutes Stichwort, es ist die vierte Dummheit. PFA bedeutet Predictive Failure Analysis, d.h. die Festplatte prüft sich ständig selbst und versucht zu erkennen, wenn es mit ihr schleichend oder auch galoppierend zuende geht. IBM tauscht eine noch funktionale Festplatte mit PFA Warnung aus. Langjährige IBM Kunden wissen das natürlich, für sie zählt auch nicht der Anschaffungspreis per se sondern die gesamten Kosten auf die Abschreibedauer von sagen wir drei Jahre.

Kommen wir bevor ihr mir alle endgültig einschlaft noch schnell zu Express Sellern und Promos, der letzten Dummheit, Nummer 5. Hier verkaufen die Distributoren palettenweise meist schon recht komplette Server (Remote Management oder RAID5/6 mit Batterie Cache schon inklusive, usw.) zu vergünstigten Preisen. In Summe hätte Jeff dann bei seinem Gesamtsystem den Aufschlag für die Festplatten locker hereinholen können, wenns denn z.B. keine 2.66 GHz Xeon CPU sein musste sondern auch ein 2.33 GHz Xeon getan hätte (bei Express Sellern sind manche Optionen vorgegeben).

Insofern ist es schlicht lächerlich, wenn Fefe von einem "Tier 1" Hardware Hersteller lieber zu einem "Tier 2" OEM Schuppen wie Sun tendiert. Viel Spass am Gerät wünsche ich! (Mit Dank an arw für die Lacher)

Kaum schaut man mal nicht drauf, legen mir die Kiddies diesen armen Low Power 5 Watt Eimer platt. Bei Renderzeiten um die 2 Sekunden pro Page Impression ist das auch nicht weiter schwer, zumindest weiss ich jetzt, dass die FreeBSD out-of-memory Funktionalität ganz passabel funktioniert. Die CGI Prozesse wurden bei den vielen Anfragen pro Sekunde erst beständig mehr, aber nach ungefähr 2/3 Swapbelegung hat der Kern dann einfach den Übeltäter (den Webserver Prozess) abgeschossen. Nicht schlecht.

Aber so kann man das natürlich nicht belassen, daher habe ich von CGI auf FastCGI umgestellt, was verhindert, dass mir jemand mittels DoS-Attacke die Box allzuleicht abwürgen kann. Zusätzlich ist mittels mod_evasive nun eine Bremse installiert, die bei zuvielen gleichzeitigen HTTP Verbindungen einen Fehlercode "503 Service Unavailable" abliefert, statt noch mehr Anfragen in das CGI zu pumpen.

Ihr werdet jetzt sicher denken "WTF! Deine Maschine ist ja noch lahmer als Fefes Gurken Celeron" und dem kann ich nicht widersprechen. Ausserdem habe ich kein LDAP, weil ich lieber in einen WYSIWYG Editor eintipper als Posts über phpldapadmin ins LDAP zu blasen. Insofern wird sich an den Renderzeiten so schnell nichts ändern, ausser ich bekomme den Cache Modus einwandfrei zum laufen. Und überhaupt, irgendwo fünf BladeCenter mit dicken NetApp Filern und Loadbalancer Cluster Krempel in ein RZ zu klatschen kann ja wohl jeder.