RackBlogger

Im Zusammenhang mit dem Serverausfall wurde nun das Problem lokalisiert - wie ich finde mal wieder sehr interessant. Nachdem sich der Server nämlich letzte Nacht kurz nach 04:00 Uhr wieder verabschiedet hat, habe ich heute mal nachgeschaut was da so für Cron-Jobs laufen. Ursprünglich hatte ich den Backup-Prozess in Verdacht, aber der läuft schon eine Stunde vorher. Um vier Uhr aber ist die Log-Analyse mit Webalizer dran. Und da musste ich mir nur eine Datei anschauen um meinen nächstbesten Verdacht zu bestätigen: die Datei “dns_cache.db” war über 1.2 GB groß.

So effizient Webalizer auch sein mag, mit einem soooo großen DNS-Cache kommt er wohl auch nicht mehr locker zurecht. Auf besagtem Server sind in letzter Zeit die Zugriffe massivst gestiegen - zukünftig wird diese Datei also nicht mehr nach einer bestimmten Zeit, sondern nach Erreichen einer bestimmten Größe gelöscht.

Auf zwei neueren Hosting-Servern testen wir übrigens bereits den optionalen (!) Einsatz von AWStats - wenn da keine Unregelmäßigkeiten auftauchen geht das in den Produktivbetrieb.

Unser Monitoring hat vorhin festgestellt, daß ein Server steht. Nach verschiedenen Eskalationsstufen wurde ich letztendlich aus dem Bett geklingelt. Der Server war von außen nicht mehr erreichbar - also habe ich die Fernkonsole geöffnet und da auch nur feststellen können, daß das System irgendwie eingefroren war.

Also - Reset ausgelöst und gewartet bis der Server wiederkommt. Dank der Fernkonsole (KVM-over-IP) konnte ich zum Glück zusehen, wie der Server seinen Filesystem-Check über hunderte Gigabytes ausführt. Früher wäre ich an der Stelle öfters fast verzweifelt, wenn der neu gebootete Server aus Sicht von Ping/SSH einfach nicht erreichbar wird (weil er eben noch beschäftigt ist). Ein FSCK kann mitunter (subjektiv) ewig dauern - ich saß schon öfters im Auto auf dem Weg ins Rechenzentrum, bis ich die SMS vom Monitoring bekam daß der jeweilge Server nun wieder oben sei.

An dieser Stelle also nochmal ein Lob auf die Fernkonsole.

Dann mal gute Nacht… oder guten Morgen…

Kurz und knapp: ab sofort enthält PHP auf unseren Servern auch die PDO-Schnittstellen zu MySQL, PostgreSQL und SQLite3.

Außerdem läuft nun auf allen “normalen” Webhosting-Accounts PHP 5.2.0. Nur die FastCGI-PHP-Umgebungen laufen noch auf 5.1.5; das Upgrade hierfür ist aber auch schon vorbereitet.

Gut, dass neue Bestellungen immer erst manuell geprüft werden - oft nur flüchtig, aber immerhin besser als gleich automatisiert einen Account anzulegen und Zugangsdaten herauszusenden.

So wird Herr Michael Ghost mit der Kontonummer 300000 bei einer Sozialbank wohl leider keine Zugangsdaten von uns bekommen. Die IP-Adresse ist einem jugoslawischen ISP zugeteilt - eine Anzeige wegen Urkundenfälschung würde in diesem Fall wohl nur wenig Sinn machen.

Viele große Kunden zu haben ist ja sehr schön. Wenn viele dieser Kunden aber auch viele Newsletter versenden, führt das zwangsläufig früher oder später zu Kontakt mit SpamCop.

So gab es auch vorhin wieder mehrere Reports von SpamCop bezüglich eines Newsletters, den ein Kunde gestern versendet hatte. Da wir es uns auch nicht erlauben möchten auf diversen Blacklists zu landen, hat der betroffene Kunde nun also die gelbe Karte bekommen - natürlich nicht ohne Hinweis darauf, wie “richtiger” Newsletter-Versand funktioniert. Unter anderem sollte der Versand personalisiert stattfinden, mit einem individuellem Unsubscribe-Link in jeder einzelnen Mail. So kann man notfalls einzelne Rückläufer (nicht zuletzt auch die AOL-Spam-Meldungen) identifizieren und umgehend aus der Mailingliste entfernen. Ein recht bekanntes Tool hierfür ist Jax Newsletter.

Hoffen wir mal, das meinen Worten auch Taten folgen.

Vorhin hat ein Kunde angerufen, der einige weitere Domains zu uns umziehen möchte. Bei einer dieser Domains ist ihm jedoch aufgefallen, dass er nicht mehr als Eigentümer (Owner-C/Admin-C) eingetragen ist, sondern diese nun einer völlig anderen Person gehört (deren WhoIs-Eintrag regelrecht nach Domaingrabbing schreit…).

Da er bei seinem alten Provider (nennen wir ihn mal “Strota”) niemanden erreicht, hat er sich bei der DeNIC erkundigt, warum die Domain den Eigentümer gewechselt hat. Antwort: die Domain wurde Anfang November von Strota gelöscht. Der Kunde hat seiner Aussage nach aber nie um die Löschung dieser Domains durch Strota gebeten, sondern diese für einen Providerwechsel freigegeben.

Nunja… dafür gibt’s schließlich DISPUTE-Anträge…

Nachdem ich eben beobachten durfte wie ein nicht wirklich unterdimensionierter Server so richtig in die Knie geht, wenn er in Verzeichnissen mit >80.000 Dateien arbeiten muss*, habe ich beschlossen, neue Server nicht mehr mit ReiserFS auszustatten.

Ext3 kommt aufgrund der langen Mounting-Dauer nach unsauberen Shutdowns nicht in Frage - also werde ich mich nun mal mit XFS vertraut machen. Was ich bisher so darüber lesen konnte macht das einen sehr schönen Eindruck. Vor allem soll XFS in Verzeichnissen mit vielen Dateien deutlich weniger Last erzeugen (scheint mit einer anderen Organisation des Datenstrukturen zusammenzuhängen - ReiserFS erzeugt offenbar bei großen Verzeichnissen sehr viele Pagefaults).
*) an dieser Stelle bitte keine Diskussion über Sinn und Unsinn solch großer Verzeichnisse… ich finde sowas auch nicht schön, manchmal lässt sich’s aber nicht mit vertretbarem Aufwand vermeiden.

Ein Kunde hat uns heute beauftragt, “ein paar” seiner extern registrierten Domains auf seinen Webspace mit aufzuschalten. Nachdem die Kosten geklärt wurden, kam heute die Liste: es sind über siebenhundert.

Im Gegensatz zu manchen Mitbewerbern berechnen wir übrigens nicht einen Euro monatlich für jede externe Domain - schließlich entstehen uns auch keine direkten Kosten. Obwohl das ein dicker Umsatzbrocken wäre…