Wohnzimmerhostblogger

Die Suchmeldung vom 15. Februar hat sich soeben geklärt! Super

Ich habe mich in letzter Zeit offensichtlich sehr ruhig verhalten. Zumindest hier im Blog, ansonsten habe ich alles andere als wenig kommuniziert.

Grund hierfür war unser Umzug bzw. "Zusammenzug".  Wo wir in der Vergangenheit den Klang des Wortes "Wohnzimmerhoster" (aber natürlich nicht die negative Wertung dieses Wortes in der Branche) hochhielten und von unseren Privatwohnungen aus arbeiteten (oder im Rechenzentrum bzw. beim Kunden vor Ort) haben wir uns nun im kleinen Team in einem Büro in der Stuttgarter Innenstadt zusammengefunden.

Für mich bedeutet das eine Verlängerung meines Arbeitsweges um 10 Minuten zu Fuß und - wie ich feststellen musste - weniger Arbeit nach Feierabend, denn den Laptop habe ich in den letzten Wochen dann abends primär in der Tasche und schlafend gelassen.

Über das Büro werde ich in den kommenden Wochen sicherlich noch mehr zu berichten haben. Mein eigentliches Anliegen:

Auch wenn ich eingangs erwähnte viel kommuniziert und entschieden zu haben: Ich habe ein wenig verschlafen unseren Telefonanschluss ins Büro umzulegen, weswegen wir bis einschließlich kommenden Montag telefonisch recht schlecht zu erreichen sind. Wer kein Glück haben sollte: Wir werden zeitnah über Anrufe informiert und geben unser bestes gleich zurückzurufen. So oder so sind E-Mail und Jabber/XMPP aber immer der beste Weg uns zu erreichen.

Ich habe niemals ein Geheimnis daraus gemacht, dass viele unserer Vorgänge verbesserungswürdig sind. Es wäre auch langweilig und vermutlich auch geschäftsschädigend wenn es nicht so wäre oder ich den Eindruck hätte wir wären schon "Perfekt" - schade wäre es dann auch, denn was sollte man den lieben langen Tag tun, wenn man nicht optimieren oder verbessern könnte? Für Däumchen drehen möchte ich nicht bezahlt werden.

"Bezahlt werden" ist ein gutes Thema! Wir haben bei uns keinen festen Rechnungslauf, sondern stellen Rechnungen so wie es gerade passt. Ich habe schon mehrfach darüber nachgedacht, diesen auf ein festes Datum zu legen, z.B. den 1. oder 14. eines jeden Monats, aber irgendwie missfällt mir das - es war ja immer schon ganz anders.

Die Rechnungsstellung an sich hat so oder so ziemlich viele Faktoren, die sich tweaken lassen. Vor ein paar Jahren konnte war es z.B. möglich, dass Domains sofort in Rechnung gestellt wurden, nachdem sie registriert bzw. in der Buchhaltung vermerkt wurden.  War ein bisschen blöd, wenn in relativ kurzen Abständen weitere Domains geordert wurden. Das generiert im ersten Schritt nur unnötig viele Rechnungen, im Nachgang aber auch unnötig viel Arbeit und Kosten. Deshalb schafften wir irgendwann die Möglichkeit Leistungen zu "priorisieren" bzw. so zu flaggen, dass sie nur abgerechnet werden, wenn eine "größere" Leistung wie z.B. Webhosting abgerechnet wurde.

... das funktionierte eigentlich recht gut, nur bildete sich so auch ein "Rückstau" an Leistungen die noch nicht abgerechnet wurden, der im mittleren vierstelligen Bereich lag. Für den Kunden natürlich toll, für uns eher unschön.

Zwischen den Jahren hatten wir daher noch einmal unsere Buchhaltungssoftware verbessert bzw. nachgebessert. So haben wir eine kundenspezifische "untere Grenze" eingeführt, ab der auch solch "nieder Priorisierte" Leistungen abgerechnet werden und z.B. auch das auslaufen des Fiskaljahres berücksichtigt wird und evtl. eine Rechnung erzwungen wird.

Funktionierte super und der Rückstau baute sich kontinuierlich ab (mittlerweile im oberen dreistelligen Bereich)! Bis vor kurzem...

Vor kurzem musste uns dann auffallen, dass ein Kunde in einem recht kurzen Zeitraum relativ viele Rechnungen von uns erhielt. Für das aktuelle Abrechnungsmodell war das absolut in Ordnung, denn der Kunde hatte in kurzen Abständen größere Mengen an Domains bestellt. Ich fand das aber nicht so lustig, den Kunden so häppchenweise mit Rechnungen zu stören, weswegen wir eine Art "Look ahead (and back)"  eingeführt haben:

Unsere Buchhaltungssoftware berücksichtigt nun bei der Rechnungsstellung auch, ob in nächster Zeit weitere Leistungen abzurechnen wäre und verhält sich dementsprechend "ruhiger". Auch wenn dadurch kurzzeitig der Cashflow einbrach fühlt sich diese neue Ruhe doch toll an - ich hoffe selbiges gilt für unsere Kunden bzw. besonders diesen einen

Gestern erreichte mich überraschend ein Päckchen per Express aus Berlin. Ich hatte nichts bestellt und dementsprechend auch nichts erwartet, zu alledem war die Lieferung auch sehr leicht und es stand kein Absender darauf, sodass ein Kollege "Anthrax" munkelte - ich war ein wenig verunsichert, hab den kleinen papp-braunen Kasten dann aber doch geöffnet.

Drinnen erwarteten mich ein paar kleine Gegenstände und ein Schreiben an mich als Blogger. Ein Rätsel war es! Ich sollte herausfinden, wer mir dort schreibt und nach Möglichkeit einen Blogpost unter Nennung der zu erratenden URL erwähnen. Das Rätsel war denkbar leicht:

So wie es auf dem Zettel vermerkt war schien es 1.336.336 Lösungsmöglichkeiten zu geben (wovon natürlich nur eine richtig war) jedoch lies sich diese Menge durch bloßes hinschauen schon auf 576 Möglichkeiten eingenzen. Der Weg dahinter war für jemanden, der im Domain-Reselling tätig ist keine Hürde. Also im Ernst...

Hat aber Spaß gemacht! Da es letzten Endes schamlose Werbung wäre, die Thematik an diesem Blog etwas vorbei geht und ich kein iPad brauche verschweige ich die URL hier. Dennoch hat sich da jemand Mühe gegeben, sodass es mindestens eine Erwähnung wert ist

Unser Domain-Registrar hat gerade ein Mailing rumgeschickt in dem man uns unser die Einführung einer sog. sponsored Top-Level-Domain (sTLD) informiert.

Dort wird ein wenig von Preisen gemunkelt und auch von der bevorstehenden Sunrise-/Landrush/Go Live-Phase gesprochen. Konkret geht es um die Domain-Endung .XXX - kann oder sollte man sich sowas auf die Fahnen schreiben oder in unser System für die Einführung neuer TLDs aufnehmen?

Das ist doch mal eine schöne Meldung zum Feierabend hin:

Koalition kippt Internetsperren (tagesschau.de)

Wie ich die Meldung gelesen habe musste ich mich selbst nochmal zurückerinnern - ja, da war doch mal was. Ich hatte es ehrlich gesagt etwas aus den Augen verloren und habe auch schon lange nichts mehr dazu gehört, was wohl primär am Einzug einer gewissen Partei in die Bundesregierung gelegen hat. Schade nur, dass im Angesicht der aktuellen Umwerfungen auf der politischen Bühne diese Meldung zu einer Randnotiz verkommt.

Nachdem ein Kunde gestern ein paar Probleme mit seinem zugesicherten Arbeitsspeicher bemängelt hatte, habe ich intern ein paar Nachforschungen angeregt um die Ursachen dafür zu finden und auch für die Zukunft ein paar mehr Daten zu haben.

Heraus gekommen ist dabei u.a. ein kleiner Benchmark, der die PHP-Optimizer APC, eAccelerator und XCache nicht auf die Geschwindigkeit in der Skripte ausgeführt werden sondern auf die Nutzung von Arbeitsspeicher hin untersucht. Unsere Ergebnisse teile ich gerne mit dem Rest der Welt.

Legt man die Daten nun neben einen der vielen Benchmarks bezüglich der Geschwindigkeit ergibt sich ein recht schlüssiges Bild. Mich persönlich alarmiert es insgesamt etwas, denn bisher rollen wir eAccelerator als voreingestellten Optimizer aus, der in Geschwindigkeitstest immer zufriedenstellend abschneidet, in unserem Memory-Test aber total versagt. APC hatten wir vor ein paar Jahren aus dem Standard weg degradiert, da der immer mal wieder Probleme mit unserem FastCGI-Setup zu haben schien.

So stehen nun wohl alle Zeichen für XCache als eventuellen neuen Standard. Da haben wir aber (im Vergleich zu eAccelerator) weniger Erfahrungen gesammelt und haben nur wenige Seiten (aber auch recht große) die mit diesem Optimizer laufen. Ich werde in den nächsten Wochen wohl forcieren, dass wir hier Erfahrungen sammeln aber auch APC werden wir uns noch einmal anschauen. Am Schluss wird mit großer Sicherheit ein neuer Standard-Optimizer stehen. Bleibt die Frage, was wir mit dem gesparten Arbeitsspeicher tun - anteilig werden wir den bestimmt an unsere Kunden weitergeben.

Heute morgen hat ein - sagen wir mal - Anbieter von Online-Diensten unberechtigt von unserem Geschäftskonto abgebucht.

Sowas kann mir immer schön den Tag vermiesen. So ganz überraschend kommt es natürlich nie, schließlich kommunizieren wir diese Daten recht "freizugügig" überall hin - meistens um Geld für unsere Dienstleistungen zu bekommen. Das da auch mal Missbrauch stattfindet besagt allein schon die Statistik und ist daher wohl keine Überraschung.

Dem Anbieter mache ich auch keine wirklichen Vorwürfe, wobei ich mir recht sicher bin dass er keine schriftliche Einzugsermächtigung vorliegen hat, die aber natürlich auch "leicht" zu fälschen ist (zumindest in dem Umfang, dass es einer einfachen Prüfung stand hält). Ich bin vielmehr sauer und enttäuscht von dem jenigen, der dort diesen Betrug begeht.

Die Enttäuschung ist wohl was rein menschliches: Ich verstehe nicht, wieso Menschen derartigen Betrug wagen. Das bringt doch niemanden weiter und scheitert unter Garantie. Das es in Wahrheit tagtäglich wohl tausende Male passiert ist mir bewusst und so mag ich daran eigentlich auch keinen Gedanken verschwenden - immerhin kostet mich sowas schon mehr als genug Zeit.

Und dieser letzte Umstand macht mich sauer, denn ich bekomme die Info, dass da eine merkwürdige Abbuchung war, muss den Posten prüfen, mich mit dem abbuchenden Unternehmen in Verbindung setzen, den Fall dort vortragen, ein Blacklisting des Kontos erwirken und den Betrag rückbuchen lassen (Rücklastschriften sind ja böse, das geht eigentlich auch immer ohne). Zu guter letzt der größte Posten: Ich gehe zur Polizei und mache eine Anzeige. (Das machen wir mit jedem Fall so)

Letzteres tue ich meistens mit einer Verzögerung von 2-3 Tagen. Zum einen weil ich diese Atmosphäre überhaupt nicht mag, zum anderen weil ich bis dahin immer gerne an das Gute im Menschen glaube: Vielleicht kommt der Schuldige in der Zeit zur Besinnung, sieht ein dass er was dummes gemacht hat, und schreibt einfach mal eine entschuldigende E-Mail - einen Fehltritt hat doch jeder mal gut.

Ist bisher traurigerweise noch nie passiert und so bin ich mir auch dieses mal sehr sicher, dass ich meinen Termin am Donnerstag morgen wahrnehmen werde.

Am Wochenende war ich neben einem geschäftlichen Termin noch bei einem sehr guten Freund zu Besuch, der "zufällig in der Gegend" wohnt. Da er ähnlich wie ich eingestellt ist, waren unsere Gesprächsthemen auch eher technisch-lastig.

In einer kurzen Gesprächspause schaute ich seine Lebensgefährtin an und meinte:

So! Wir müssen nun ein Synonym für PHP finden, dass Dir auch mal etwas zusagt!

worauf hin sie mir nach einer kurzen Denkpause entgegnete:

Pinke Hochhackige Pömps

Sehr geil! :D 

Wir haben irgendwann dieses Jahr angefangen unsere Dokumente wie Angebote und Verträge im PDF/A1-Format zu generieren, abzuspeichern und zu versenden.

Gerade eben rief mich unsere Ansprechpartnerin bei einem unserer Distributoren an und meinte sie hätte Probleme den Lieferschein für eine Bestellung eines unserer Kunden zu öffnen. Auch die Logistik hätte es nicht geschafft das Dokument zu öffnen.

Ich habe daraufhin das Dokument noch einmal als "normale" PDF generiert, rübergemailt und schon hat es funktioniert. Merkwürdig, ganz naiv gesagt hätte ich es eher anders herum erwartet, da PDF/A ja auf den ganzen "fancy stuff" verzichtet...

Twitter wäre hierfür wohl die bessere Applikation, doch habe ich nur diesen Blog hier.
Auf den WorldHostingDays wurde ich just sehr freundlich begrüßt - in etwa mit den Worten:

Endlich mal jemand, der deutsch spricht!

Na dann...n.

Wir haben PHP heute morgen ein kleines Update spendiert und bieten ab sofort die Versionen 5.2.16 und 5.3.4 zusätzlich an.

Neukunden bekommen ab sofort die Version 5.2.16 auf ihr Webhosting geschaltet, Bestandskunden bleiben vorerst unangetastet können aber jederzeit ein Update per E-Mail erfragen.

Okay, das ging schneller als erwartet:

Unser Mailserver kennt nun das Sender Rewriting Scheme (SRS). Theoretisch gilt das für beide Richtungen, also das Umschreiben des Absenders wenn eine E-Mail weitergeleitet wird und das Umschreiben des Empfängers, wenn eine E-Mail an unsere SRS-Domain empfangen wird. Produktiv verfügbar ist aber vorerst nur zweiterer Dienst - der war einfach leichter zu testen und fällt auch eigentlich gar nicht auf, wenn wir den einfach dazu schalten.

Unsinnig eigentlich, denn ohne das shared secret aus unserem E-Mail-System ist es vermutlich niemandem möglich selbst E-Mail-Adressen zu bauen, die von unserem System akzeptiert werden. Vielleicht wollte da jemand einfach nur ein Kreuzchen auf der ToDo-Liste machen.

Dabei ist die andere Richtung viel interessanter und spannender. Wie ich letzte Woche bereits schrieb haben wir für die SRS-Einführung eigenes einen Patch für das von uns eingesetzte Postfix entwickelt. Wie schon dort angedeutet fehlten dementsprechend eigentlich nur noch zwei Dictionaries (bzw. Lookup-Tables). Eigentlich recht trivial, im Zweifel hätte es gereicht zwei Pipes in Richtung libsrs2 zu legen (wenn wir es denn einsetzen würden), aber das wäre nicht sehr "intelligent".

Der bereits erwähnte "Weg zurück", also das Umschreiben des Empfängers einer E-Mail an unsere SRS-Domain, funktioniert genau so. Darf man machen, da der erste Check hier ein Check der Domain ist und die ausschließlich für SRS verwendet wird. Der vorhergehende Schritt, das Umschreiben des Absenders gestalten wir jedoch etwas differenzierter:

1. Es werden keine Absender umgeschrieben, die von Domains kommen die ohnehin über unseren Mailserver laufen
2. Es werden nur Absender umgeschrieben, die von Domains mit aktivem SPF-Schutz kommen

Kleine persönliche Anmerkung: SRS hat erst einmal nichts mit OpenSRS am Hut. Das sind zwei unterschiedliche Dinge, letztere höre ich mir morgen vermutlich auf den WorldHostingDays im Europa-Park in Rust an

Das Sender Policy Framework (SPF) ist nun schon fast altes Zeug. Immer mehr Domains verfügen über einen solchen "Schutz" und dementsprechend öfter fallen nun E-Mails auf, die "klassisch" weitergeleitet werden sollten - sei es eine E-Mail die von GMX kommt, ursprünglich an eine bei uns gehostete Domain ging und wieder zurück an GMX geleitet wird - und es nicht funktioniert. Die Problematik ist zwar nahezu überall dokumentiert, aber mitunter doch recht schwer zu kommunizieren.

Das Problem ist bei uns eigentlich auch schon ewig bekannt: Seit 2006 setzen wir auf nahezu allen Domains SPF ein und auch der Lösungsansatz des "Sender Rewriting Scheme" (SRS) war uns ein Begriff. Nur mangelt es bis heute irgendwie an einer passenden Lösung für Postfix (so wie es bei uns zum Einsatz kommt).

Zwar gibt es hier und da ein paar Ansätze oder auch Aussagen a la "Wir haben es geschafft", aber konkrete Angaben bzw. Dokumentation oder etwas öffentlich verfügbares für den Produktiv-Einsatz fehlt gänzlich. In ein paar Foren findet man auch oft die Aussage SRS wäre ein Fall für einen Content-Filter. Letzteres ist sicherlich auch ein einfacher und schneller Weg das "Problem" anzugehen, doch scheint mir der Overhead hier recht enorm zu sein. Etwas schlankeres wäre mir doch lieber.

Grund genug sich einmal den smtp-Client von Postfix anzuschauen und mal herauszufinden, was das Ding in die Richtung alles kann. Grundsätzlich bin ich bei Postfix gewöhnt alles irgendwie über Dictionaries umzuschreiben und so Daten nahezu endlos umzubiegen. Ein gutes Beispiel wäre hier sicherlich die Struktur unserer Relay-Funktionalität, die sich auch auf einzelne E-Mail-Adressen beschränken lässt und sich Domains so im gemischten Betrieb verwalten lassen. Oder natürlich auch die Anbindung von Zarafa-Mailboxen im Multi-Tenancy- sowie gemischten Betrieb mit normalen POP3/IMAP-Mailboxen - aber ich schweife ab.

Der SMTP-Client von Postfix kennt mit den smtp_generic_maps tatsächlich auch ein Dictionary um den Absender einer E-Mail umzuschreiben, also eigentlich wäre hier genau der richtige Punkt um mit einer SRS-Implementation anzusetzen. Ein einziges Problem gibt es dann allerdings:
Die smtp_generic_maps kommen sowohl für den Absender wie auch den Empfänger zum Einsatz und man kann technisch bedingt nicht unterscheiden, wonach genau gerade gesucht wird.

Die Lösung des Problems ist daher ganz einfach: Die smtp_generic_maps auseinander friemeln. Genau das tut ein Postfix-Patch (für 2.8 Patchlevel 1) von uns, den ich just in unser Build-System geschickt habe: Neben den smtp_generic_maps führt der Patch die smtp_sender_maps ein, die nur für MAIL FROM:-Einträge konsultiert werden.

Fehlt eigentlich nur noch das passende Dictionary, dass die Verarbeitung bzw. Konvertierung der Absender-Adressen vornimmt. Für den Moment behalte ich näheres dazu aber für mich bzw. überlasse das gerne der Community, zumal wir da noch nichts produktives haben - unsere SRS-Bibliothek hat noch Probleme mit SRS1 nach SRS1. Mal davon abgesehen, dass der Weg zurück noch gar nicht gebaut ist

Wir haben in der letzten Tagen eine Zarafa-Instanz bei uns aufgesetzt. Nun haben wir ja unsere eigene Hosting-Plattform und die richtet sich nicht gerade nach den offiziell von Zarafa unterstützten Betriebssystemen - nun ist die Frage, geht man den von Zarafa vorgeschriebenen Weg oder verbiegt man der Giraffe ein wenig den Hals?

Ich hatte mich in dieser Sache für den zweiten Weg entschieden. Auf Dauer schien es mir der bessere Weg zu sein, zumindest verkleinert es die Zahl der "Fremdkörper" die sich bei uns auf den Servern befinden. Aus dieser Entscheidung resultierten jedoch 3 wesentliche Probleme:

1. Zarafa ist auf eine Webserver-Umgebung mit mod_php ausgelegt
2. Die Webaccess-Oberfläche benötigt die Zarafa-eigene MAPI-Erweiterung für PHP
3. Z-Push ebenfalls auf mod_php ausgelegt

Um das Feld von hinten aufzuräumen: Die einzige Sache, die Z-Push an mod_php bindet, ist ein Aufruf der Funktion apache_request_headers(). Das Problem ist schon im Jahr 2007 im Z-Push-Forum diskutiert worden, hat es aber wohl nie in die offizielle Distribution geschafft - warum auch immer. Neben dem Patch, der in besagtem Forum zu finden ist, haben wir auch einen eigenen Patch geschrieben.

Punkt #1 ist im Vergleich zu #2 auch weniger kritisch. Es scheitert hier im wesentlichen daran, dass die .htaccess-Datei in /usr/share/zarafa-webaccess einfach so php_flag-Direktiven verwendet, die den Apachen dazu veranlassen einen 500er zu werden, wenn mod_php nicht vorhanden ist. Ich finde ja, dass es grundsätzlich guter Stil ist <IfModule>-Direktiven zu verwenden, auch oder gerade wenn man ein bestimmtes Modul voraussetzt.
Die Einstellungen, die man in der php.ini anpassen sollte sind:

register_globals = Off

magic_quotes_gpc = Off
magic_quotes_runtime = Off

post_max_size = 32M
upload_max_filesize = 30M

short_open_tag = On

log_errors = On
error_log = error.log

... das meiste war bei uns ohnehin so voreingestellt. Weiter sollte das Verzeichnis /var/lib/zarafa-webaccess/tmp auch noch für den Benutzer unter dem der FastCGI-Prozess ausgeführt wird schreibbar sein.