RackBlogger

Eben habe ich mit einer Kundin telefoniert, die sich auf Platz 1 des internen Mailbox-Rankings befindet: 22.000 Mails mit über 2.5 GB. Das alleine wäre nicht sooo schlimm, würde sie nicht alle paar Sekunden neue Mails empfangen, wodurch die Quota-Prüfung bei diesem Postfach zum Flaschenhals wird. Auch der 5-minütige POP3-Check wirkt sich nicht sehr vorteilhaft auf die Performance aus.

Jedenfalls haben wir eben telefonisch besprochen, mit welcher Strategie dieses Postfach wieder auf eine gesunde Größe reduziert wird.

Da viele unserer Geschäftskunden ihre Mails sehr lange bei uns “archivieren”, um per IMAP immer und überall auf die gesamte Mailbox zugreifen zu können, möchte ich kein automatisiertes Löschverfahren einführen, mit dem z.B. alle Mails älter als xx Monate gelöscht werden. Wenn ein Postfach allerdings exponentiell anwächst und alle paar Wochen das Quota verdoppelt werden soll, versuche ich im persönlichen Gespräch eine passende Lösung zu finden.

Und allzu oft stellt sich nunmal heraus, dass die Kunden diese ganzen alten Mails eigentlich überhaupt nicht wirklich online brauchen - es würde vollig genügen, diese herunterzuladen und anschließend gleich auf dem Server zu löschen…

Oder auch “Karteileichensuche”.

Nachdem ich mal wieder in der Abrechnung von unserem Registrar Domains entdeckt habe, die ich sicherlich noch nicht dem entsprechenden Kunden in Rechnung gestellt hatte, habe ich eine kleine SQL-Anfrage erstellt. Diese holt alle Domainnamen aus der Datenbank und prüft, für welche Domain noch kein Datensatz in der Abrechnungs-Tabelle existiert. Das Ergebnis ist also eine Liste von Domains, die noch nie abgerechnet wurden.

Ich weiß gar nicht, wieso ich diese Abfrage noch nicht früher erstellt hatte - jedenfalls bekommen nun einige Kunden in den nächsten Tagen Post von uns. Ich hoffe, manche von denen können sich vor allem überhaupt noch an uns erinnern!

Was die Nachberechnung von seeehr lange fehlenden Domainposten betrifft lasse ich da übrigens Gnade walten - es wird nur der jeweils aktuelle Abrechnungszeitraum berechnet. Es wird also niemand eine Nachberechnung über mehrere Jahre oder so bekommen. Schließlich soll sich die versäumte Rechnungserstellung nicht zum Nachteil der betroffenen Kunden auswirken.

Am Dienstag Abend meldet unser Monitoring eine überaus hohe Antwortzeit bei einem der Webserver. Ich habe mich also per SSH auf der Maschine angemeldet und nach der Ursache gesucht. Die Server-Last lag nur bei etwa 15%, der Speicherverbrauch und auch die I/O-Werte waren im grünen Bereich. Aber der Apache-Webserver hat das Maximum der möglichen gleichzeitigen Prozesse erzeugt gehabt. Also - Logfiles durforstet und keine wirklich auffälligen Fehlermeldungen gefunden, außer das manche Clients nach einer bestimmten Zeit die Verbindung dann von sich aus beendet haben.

Es hat letztendlich rund 20 Minuten gebraucht, bis ich nach mehreren Apache-Neustarts und Beobachtungen dessen error_log-Datei das Problem identifiziert hatte: ein Kunde hat an dem Abend ein paar Domainweiterleitungen eingerichtet, und zwar mit der Proxy-Methode (d.h. die ursprüngliche Domain bleibt in der Adresszeile erhalten, und der Server holt über das Proxy-Modul die Inhalte von der Zieladresse ab). Dummerweise hat er dann sinngemäß folgendes eingetragen: “Für die Domain ###.de gilt: rufe alle Inhalte per Proxy von ###.de ab”.

Als dann noch just in diesem Moment genau dieser Kunde eine Mail mit dem Hinweis “Der Server ist etwas zäh…” geschrieben hat war mir klar, dass das so nicht weitergehen kann…

Die Konsequenz: unsere neue Admin-Software bekommt einen kleinen Pfadsuchealgorithmus verpasst, um Schleifen durch solche Weiterleitungen zukünftig zu erkennen und entsprechend abzuweisen.
(Es reicht nicht, nur Weiterleitungen von einer Domain auf die gleiche Domain zu verhindern, schließlich könnte man das gleiche Problem sonst durch zwei Weiterleitungen in der Form Domain1.de->Domain2.de, Domain2.de->Domain1.de auch provozieren).

Eine immer beliebtere Form der langfristigen “Kundenbindung” sind lange Vertragslaufzeiten. Ein Mitbewerber (naja… eher ein Marktführer in dem Bereich ) hat nun bei allen beworbenen Hosting-Paketen Vertragslaufzeiten von 24 (!) Monaten. Wünscht man eine kürzere Vertragslaufzeit (6 Monate), so erhöhen sich die monatlichen Kosten um einen Euro.

Vielleicht hängt das damit zusammen, dass wir immer mehr Kunden von diesem Anbieter (2) zu uns umziehen, und die keinen anderen Weg mehr sehen ihre Kunden länger da zu behalten?

Ich finde solche Mindestlaufzeiten jedoch nicht erstrebenswert. Zum einen: wer möchte sich denn im heutigen extrem schnelllebigen Technologie-Markt für mindestens zwei Jahre auf ein bestimmtes Leistungspaket festlegen? Und zum anderen: wenn die Kunden mit Preis und Leistung wirklich zufrieden sind, bleiben sie von alleine - und das auch viel länger als zwei Jahre. Wenn ein Kunde vorher kündigen möchte, hat das seinen Grund - und dann hilft es auch nicht wirklich ihn länger als nötig an sich zu fesseln…

Bisher lief das Lastschriftverfahren intern immer so: aus der datenbankbasierten Kundenverwaltung wurden mit einem recht komplexen Perl-Script Rechnungen generiert, die mehr oder weniger automatisch gedruckt und per Post versendet wurden. Anschließend wurden die Rechnungen in die FiBu übernommen (anfangs manuell, später in einem auch nicht unkompliziertem Batch-Verfahren). Bei Fälligkeit dieser Rechnungen (i.d.R. zehn Tage nach Rechnungserstellung) wurden dann aus der FiBu die DTA-Datei(en) für die Bank generiert. Diese wurden früher per Diskette bei der Bank eingereicht, seit einigen Jahren zum Glück direkt per HBCI an die Bank gesendet. Nach Gutschrift auf dem Konto mussten dann alle betroffenen Posten aus der FiBu als bezahlt markiert werden (was sich leider nicht automatisieren lies, aber trotzdem noch “relativ” schnell ging). So ein Abrechnungslauf hat immer gut und gerne einen halben Arbeitstag gekostet.

Die April-Abrechnung war nun die Prämiereveranstaltung für unser neues System: das interne Rechnungssystem generiert neben den ganzen Rechnungen automatisch die notwendigen DTAUS-Dateien bei Fälligkeit, und in der FiBu landet nur noch eine einzige Position als Sammelbuchung. Auf einem speziellen Beleg für die FiBu werden die Details der Einzelbuchungen und die enthaltenen Steuersätze ausgewiesen. Das erspart etliche Arbeitsschritte und unzählige Einzelbuchungen der FiBu. Die Verwaltung der “offenen Posten” wird auch gerade im internen System umgesetzt und von einem automatisiertem Abruf der Kontoauszüge via HBCI unterstützt.

Automatisierung, die (mir) Spaß macht.

Nach den Problemen mit PHP 4.4.5 wurde gestern die Version 4.4.6 freigegeben. Gleichzeitig startete aber auch der “Month of PHP Bugs” - ein Projekt einiger frustrierter Sicherheitsspezialisten. Die ersten Einträge existieren schon - mal schauen wie lange es dann bis zur Version 4.4.7, 4.4.8, 4.4.9, … braucht.

A propos… habe ich eigentlich schon erwähnt, daß ich (persönlich) PHP als Platform für “redistributable Applications” nicht zuletzt aus diesem Grunde für völlig ungeeignet halte? Als Hersteller einer PHP-Anwendung hätte ich Angst um die Lauffähigkeit meiner Anwendungen bei jedem einzelnen PHP-Update.

Klar, die C-Laufzeitumgebung ist auch nicht wirklich fehlerfrei, aber definitiv mit einer höheren Stabilität gesegnet als PHP.

Den Umzug mancher Domains (z.B. .com, .net usw.) muss ein Kunde immer ausdrücklich bestätigen; wenn wir einen Transfer einleiten, erhält der Kunde hierzu automatisch durch unseren Registrar eine E-Mail mit einem entsprechenden Bestätigungslink.

Bei einer bestimmten .net-Domain habe ich vorhin einen Kunden darüber informiert, dass wir den Transfer nun eingeleitet haben und er eine Mail mit dem beschriebenen Link erhalten hat.

Eben kam die Mail vom Kunden zurück, daß er den Link nun angeklickt hat. Was er nicht wusste: das bekommen wir so oder so mit, da sich der Domainstatus nach dem Klick entsprechend ändert.

Meine Antwort per Mail also:

“Das weiß ich bereits. Ich sehe ALLES!”

Heute haben wir nach der üblichen Quarantänephase PHP4 von 4.4.4 auf 4.4.5 umgestellt. Die Überwachung der einschlägigen Logfiles lieferte keine unerwarteten Fehlermeldungen, also gingen wir davon aus das alles läuft.

Pustekuchen. Eben rief ein Kunde an (danke, Stefan!) und meldete Probleme mit seiner osCommerce-Installation. Nachdem leider keine Fehler im PHP-Errorlog dieses Kunden protokolliert wurden, führte ich eines der Scripte manuell auf der Shell aus - Ergebnis: “Segmentation fault”.

Jedenfalls haben wir nach kurzer Analyse wieder alle Server auf 4.4.4 zurückgestellt und harren mal der Dinge. Das konkrete (reproduzierbare) Problem werde ich mir später in einer Testumgebung mit gdb nochmal näher anschauen - vielleicht findet sich ja die Wurzel allen Ãœbels…