Wohnzimmerhostblogger

Bevor ich jetzt gleich zum letzten mal in diesem Jahr Feierabend mache wollte ich noch fix ein paar Grüße hier im Blog loswerden.

Vielen Dank an alle Leser, Kommentatoren und Kunden, die mir das Jahr über hier die Treue gehalten haben und auch in dem einen oder anderen Kommentar wertvollen Input für mich geliefert haben. Ich hatte des öfteren den Gedanken mich nicht im angemessenen Maße um den Blog gekümmert zu haben und werde das auch mit ins Jahr 2011 nehmen, allerdings nicht mit allzu viel Hoffnung Das Jahr 2010 hat ein paar spannende Herausforderungen für uns bereitgehalten und ich denke mal, dass es in den kommenden 12 Monaten nicht anders sein wird. Wenn ich die Zeit und Lust finde davon zu berichten, so werde ich das natürlich tun.

Meine Agenda ist zudem auch schon wieder ziemlich voll und es stehen auch ein paar Kunden-Projekte an, die mich sehr stark in Anspruch nehmen werden, doch fühle ich mich gut gerüstet und merke wie es voran geht. Just gerade eben habe ich auf Anregung eines Kunden hin einen Patch im Kundeninterface eingespielt, der einen Fehler in der neuen Benutzer-Verwaltung behebt, die wir diese Woche still und heimlich eingeführt haben.

Heute morgen haben wir in unserem Backend die Komponente, die die Rechnungen für unsere Kunden erstellt, komplett ausgetauscht und etwas flexibler und übersichtlicher gestaltet. Unser Jabber/XMPP-Server ist mittlerweile so beansprucht, dass wir ihm diese Woche ein Upgrade beim Arbeitsspeicher geben mussten, MUC werden wir vermutlich im Januar/Februar produktiv ausrollen und haben dann noch ein paar andere Dinge in der Hinterhand.

Es wird also spannend und bestimmt ein gutes Jahr!

Dem Rest der Menschheit möchte ich dieses auch wünschen.
Kommt gut ins Jahr 2011 und gestaltet es so, dass es euch gut geht, ihr glücklich werdet oder bleibt und wir in 356 Tagen getrost zurückblicken können und sagen "Das war super!"

Heute hat auf ein neues der Congress des Chaos Computer Clubs bzw. 27C3 begonnen.

Nachdem ich heute morgen schon ein paar VPN Gateway-Zugänge an Kunden verschenkt habe, mache ich nun gerne damit offiziell weiter: Wer auf dem 27C3 zu Gast und bereits Kunde bei uns ist, bekommt einen auf Anfrage für 3 Tage einen kostenlosen Zugang zu unserem VPN Gateway in der Größe "Frequent Flyer" (dynamische IP-Adresse, 10 GB Traffic, ohne Domain).

Testzugänge gibt es bis zum Jahreswechsel mit 1 GB Traffic und einer Gültigkeit von 48 Stunden anstelle der sonst üblichen 24.

Bei Interesse oder Fragen gerne eine E-Mail an mich direkt. Das Angebot besteht solange der Vorrat reicht und ist in der verfügbaren Menge an Zugängen beschränkt.

In letzter Zeit schüttel ich irgendwie regelmäßig den Kopf wenn ich mit OpenVPN zu tun habe, bzw. frage ich mich wie die Standardeinstellungen ohne Probleme funktionieren sollen.

Das TUN/TAP-Device für den VPN-Tunnel wird per default mit einer MTU von 1500 Byte konfiguriert, womit für die VPN-Verbindung die bei OpenVPN typischerweise auf UDP basiert eine maximale Nutzdaten-Größe von eben diesen 1500 Bytes entsteht. Addiert man hierauf nun den Overhead von UDP, IP und Ethernet oder PPP, landet man typischerweise weit über der MTU der eigentlichen Internet-Verbindung und Datenpakete werden verworfen.

Eine Abhilfe würde die Verwendung von einer TCP-basierten Verbindung schaffen - mit unserem VPN Gateway ist immerhin beides möglich. Hier würden die Nutzdaten fragmentiert und entsprechend der maximalen MTU auf dem Weg zum VPN-Server übertragen. Allerdings ist TCP im Vergleich zu UDP nicht optimal für VPN-Verbindungen geeignet - um es zu veranschaulichen: Eine VPN-Verbindung ist eine Art "virtuelles Kabel", das dementsprechend auch die Eigenschaften wie ein reales Kabel haben sollte. Dazu gehört auch die Eigenschaft Pakete zu verlieren. UDP schickt die Daten einfach so raus und achte nicht auf Reihenfolge oder ob diese auch ihr Ziel erreichen, TCP hingegen sorgt dafür, dass die Nutzdaten immer in Reihenfolge und auch komplett ihr Ziel erreichen - das ist auch gut, solange das "Kabel" nicht ohnehin schon dafür sorgt. Ohne nun noch weiter in die Tiefe zu gehen: Eine VPN-Verbindung über TCP zu tunneln ist Mist und eigentlich nur für den Notfall bzw. wenn es nicht anders geht eine Option.

Man kann nun nicht behaupten, OpenVPN hätte hier nicht vorgesorgt, im Gegenteil: OpenVPN kennt die Konfigurations-Parameter "tun-mtu" und "link-mtu". Beide definieren einen MTU-Wert, der sich auf das TUN/TAP-Device auswirkt. tun-mtu tust das für das TUN/TAP-Device direkt, wohingegen link-mtu den Paket-Overhead für den Transport über das Netzwerk abzieht und die MTU des TUN/TAP-Device entsprechend setzt.

Nun wird OpenVPN mit "tun-mtu" voreingestellt auf 1500 ausgeliefert, was zu dem eingangs erwähnten Problem führt. Sinnvoller wäre es eigentlich "link-mtu" mit diesem Wert zu versehen. Wenn man dann aber noch die weite Verbreitung von DSL-Zugängen auf Basis von PPPoE berücksichtigt, sollte dieser Wert noch kleiner ausfallen, mindestens 8 Byte.

Nun hocke ich aber nicht immer in Stuttgart im Büro, sondern fahre oft auch durchs Land, sodass ich schon so einige fremde Netzwerke, Hotspots oder UMTS-Verbindungen gesehen habe. In Konsequenz haben wir uns nun dazu entschlossen unseren VPN Gateway mit einer link-mtu von 1400 zu betreiben. Zwar sorgen die 100 Byte weniger, dass mehr Frames generiert werden müssen, doch habe ich persönlich die Erfahrung gemacht, dass es so weitaus seltener zu Verbindungsproblemen kommt - besonders bei SSL-Handshakes.

Zu Migrationsproblemen kommt es hierbei nicht, da ja nur die Menge der zu senden Daten herab gesenkt wird. Solange die dann ihr Ziel erreichen, werden sie dort auch akzeptiert - an einem MRU-Schalter wird in der Regel nicht gedreht.

Eigentlich bin ich ja ein Fan von RFCs, denn Sie beschreiben irgendeine Technik für jedermann mehr oder minder verständlich und meistens recht eindeutig, sodass schlussendlich auch jeder seine eigene Software darauf aufbauen kann und die Interoparabilität gesichert ist. Da ist es eigentlich ein Krampf, wenn irgendwelche Unternehmen oder Entwickler hingehen und irgendetwas abweichend von einem RFC tun.

Heute möchte ich mich in die Reihe der RFC-abweichler einreihen - aber nur optional und aufgrund eines expliziten Kundenwunsches. Der Ausgangspunkt war eine Joomla-Installation eines Kunden, die stets URLs wie www.domain-des-kunden.de//images/unterverzeichnis/bild.jpg generierte. Auf den ersten Blick ist hier vielleicht nichts falsch, höchstens das "//" wirkt optisch unschön.

Doch falsch gedacht! Ein "//" am Anfang eines Pfades auf einer Domain ist in RFC 2396 Abschnitt 3.2 als "Authority Component" definiert, dementsprechend schneidet ein Webserver (der RFC-konform arbeitet) "//images" von der Adresse ab und wertet es als Authentifizierungs-Informationen aus. Wäre mir das nicht schon mal in Verbindung mit Subversion passiert, würde ich das vermutlich gar nicht wissen und ich kenne auch niemanden, der diese Regel spontan parat hätte.

Somit ist das Ergebnis dieser URL stets nicht das jenige, welches man erwarten würde. Da der Kunde auch recht wenig Interesse hatte in Joomla den Fehler zu suchen und dort wegzupatchen, habe ich - eigentlich mehr aus Spaß - ein Modul für den Apache HTTPd geschrieben das die arme wehrlose Webserver-Software RFC-unkonform macht.

Genau genommen macht das mod_ignore_authcomponent auf Wunsch zuvor geleistete Arbeit wieder rückgängig und stripped dabei einfach eines der Slashes am Anfang der Domain weg. Überraschenderweise hat das Modul auch gleich seit letzter Woche den Weg durch unser Build-System genommen und es heute Abend in unsere offiziellen Paket-Quellen geschafft. Bei Bedarf werden wir es wohl in den kommenden Nächten auf unsere Webserver ausrollen und einen entsprechenden Button bei uns im Kundeninterface einpflegen.

Wenn man den Blog hier streng auf Hosting-Themen beschränken würde, wäre dieses Thema wohl Off-Topic. Ich beschränke aber nicht derartig und werde nun voller Freude berichten.

Ein Kunde feierte am Freitag Abend seine Weihnachtsfeier, zu der ich auch gelanden war und mit großer Freude teilnahm. Der Höhepunkt war in diesem Jahr ein Menü aus 9 Gängen, dass - mit Verlaub - hervorragend war. Der Koch samt Cheffin wurde dazu extra aus Spanien eingeflogen und beide hatten offensichtlich auch jede Menge Spaß am Abend und dokumentierten fast fleißiger als jeder Gast dort das Geschehen und natürlich das Menü.

Nach der Feier wurde die Speicherkarte von einem der Geschäftsführer (sprich: Hätte es eine entsprechend Betriebsvereinbarung zur Nutzung der Computer gegeben, wäre die auch sinnlos gewesen) an einen Computer des Unternehmens angeschlossen - nur um eine Kopie der Bilder zu bekommen. Doch der Virenscanner schlug sofort an und löschte gerade zu Bedingungslos die ersten 2 KB Dateisystems auf der Speicherkarte, eine Wiederherstellung sollte nicht mehr möglich sein.

"Hah! Wieder eine gelegenheit zu puzzlen!" war wohl mein erster Gedanke und er sollte nicht mein letzter in dieser Sache sein.

Das Problem: In den ersten 512 Byte des Dateisystems stehen eigentlich alle Rahmendaten die zur Nutzung der restlichen Daten notwendig sind, nun standen dort nur noch Nullen. Erschwerend kam hinzu, dass ich eigentlich gar kein Wissen über das FAT-Dateisystem vorzuweisen hatte. Auf meiner Zugfahrt von der Feier nach Hause habe ich mich also erst einmal an ein intaktes FAT-Dateisystem heran getastet. Erst Dateisystem-Informationen ausgelesen, Verzeichnis-Informationen ausgewertet, Cluster lokalisiert und schlussendlich selbige verkettet und daraus ganze Dateien gemacht.

Ich würde ja die einzelnen Zwischenschritte zeigen, allerdings sind die mittlerweile in einer Art Bibliothek aufgegangen und vereinfacht worden.

Der Schritt zu der kaputten Speicherkarte (die ich als Image mitgenommen hatte) war dann eigentlich nur noch Parameter raten und die Verzeichnisse finden, wo alle Bilder liegen. Und siehe da: Ich habe alle Bilder aus dem Image retten können, fehlerfrei. B-)

Damit meine Code-Schnipsel, die mir hierzu verholfen haben, nicht verloren gehen, habe ich sie gleich mal online gestellt. Im Zweifel helfen sie vielleicht auch einem anderen Bastler. Die Fotos werde ich gleich manuell hochladen und so an ihre Urheber zurückgeben.

Zum Jahresende wird bei uns die Kundennummer 1337 "frei" - sprich der dahinterliegende Kunde gibt sein Webhosting bei uns (wegen Geschäftsaufgabe) auf.

Irgendwie schade, zumal das wohl eine Kundennummer ist über die sich andere mehr gefreut hätten. Allerdings können wir keine Kundennummern recyclen, daher wird die wohl auf ewig ungenutzt bleiben

Gut, dass es noch genug andere schöne Nummern gibt. 

Ich habe ja gestern schon von ein paar Patches für PHP 5.1.6 berichtet. Die Version ist zwar mittlerweile stein alt und niemand wird sie noch verwenden (außer wir, wenn der Kunde es so will ), aber der Vollständigkeit halber noch zwei Backports / Patches, die ich gestern unterschlagen habe:

• Patch um die Suhosin-Extension 0.9.32.1 zu nutzen (nur für PHP 5.1.6 notwendig)
• Heimverzeichnis des jeweiligen Benutzers in Fehlermeldungen abschneiden (für PHP 5.x)

Letzterer Patch ist sicherlich so ein tiggersWelt.net-spezifisches Ding, da bei uns Kunden typischerweise ein Heimverzeichnis nach dem Schema /home/{erstedomain.tld}/ erhalten und die Domain dann auch in den Fehlermeldungen für andere Domains des selben Kunden erscheint - das will man nicht immer sehen. Praktischerweise entspricht die "neue" Fehlermeldung dann auch direkt dem FTP-Pfad, den der Kunde zu sehen bekommt.

Es ist irgendwie immer ein Drathseilakt, wenn man Limits auf dem Webserver festlegt - wie lange darf ein Skript laufen, bevor der Webserver ihn automatisch beendet? Wählt man das Limit zu kurz, schreien etliche Kunden, wählt man es zu lange, schreien sie vermutlich wieder wenn man ein Skript amok läuft.

Ich finde die Aussage "Da läuft halt gerade ein Skript von Dir nicht rund und belegt alle Ressourcen" wenig befriedigend - auch oder gerade dann wenn ich der jenige bin, der sie gibt, und nicht der jenige, der sie bekommt. Aber in dem Moment ist alles andere unwirtschaftlich, wir können nicht die Zeit aufbringen herauszufinden, welcher Skript da gerade läuft und wo genau es hakt. Wenngleich wir natürlich auch hier unser Bestes zu geben versuchen.

Um ein wenig mehr Licht in die Angelegenheit zu bringen, haben wir uns nun aufgemacht und einen kleinen Patch in der FastCGI-SAPI von PHP eingebaut:

Die laufenden FastCGI-Server ändern nun ihren Prozess-Title und geben somit Preis was sie gerade tun, z.B. ob sie gerade eine Anfrage bearbeiten oder auf die nächste warten. Super! Nun muss es sich nur noch im Produktiv-Betrieb bewähren.

Bei der Gelegenheit haben wir noch ein paar Änderungen in den PHP 5.1er-Baum zurückgeführt, um PHP 5.1.6 mit OpenSSL 1.0 und neueren CURL-Versionen zu bauen. 

Wenn ich mir die Anzahl der Anfragen von Kunden anschaue, die gerne wissen wollen, ob wir was gegen das Spiegeln von Wikileaks haben, könnte man meinen das Internet würde bald nur noch aus eben dieser einen Wistleblower-Webseite bestehen

Und bevor hier noch jemand fragt: Natürlich haben wir dagegen nichts einzuwänden. Im Grunde sogar ganz im Gegenteil.