Technik

Gerade eben im Jabber/XMPP-Support:

[11:35:23] <support@tiggerswelt.net> Du hast gleich einen reconnect...
[11:35:30] *** Kunde (xxxxxx.de) ist Offline

Hintergrund der Sache: Ich hatte einen Neustart des Jabber-Instanz des Kunden bei uns veranlasst, da er mich um ein selbst signiertes SSL-Zeritifkat für die Client-Verbindungen zum Jabber-Server erfragt hatte.

Als ich ein wenig Zeit am Bahnhof zu vertrödeln hatte, bin ich mal wieder auf eine uralte Seite bei uns im Wiki gestoßen. Wenn ich mich recht entsinne, wurde die Diskussion seinerzeit von meinem Helferlein angestoßen und ist irgendwann versackt - bis zu jenem Abend am Bahnhof.

Ich weiß ja nicht, wie wir uns das im Jahr 2007 vorgestellt hatten - vielleicht die besten Vorschläge, einen pro Status, auswählen und "hart" in den Server patchen - im Jahr 2013 habe ich dafür ein Modul mit dem Namen "mod_statustext" geschrieben. Es tut genau das, was der Name sagt: Auf VHost- bzw. Verzeichnis-Ebene lassen sich damit der Text hinter dem eigentlichen HTTP-Statuscodes per .htaccess überschreiben, unabhängig davon ob die Antwort von einem PHP-Skript oder direkt von der Festplatte kommt:

<IfModule mod_statustext.c>

  SetStatustext 200 "Bitteschoen"
  SetStatustext 304 "Alles beim Alten"

</IfModule>

Natürlich ist das nur eine Spielerei, aber dieses Alleinstellungsmerkmal läuft tatsächlich auf den neueren Webservern mit (Nicht auf diesem, der ist uralt.)

Letzte Woche habe ich in der Firewall den Port 22 (SSH) freigegeben. Also nicht direkt diesen Port, sondern ich habe einen anderen gewählt und leite diesen hinter der Firewall transparent auf den SSH-Port um.

Irgendwie ist das ein komisches Gefühl. Jetzt war der Port jahrelang dicht bzw. nur für bestimmte IP-Bereiche freigegeben und auf einmal ist er offen. Noch komischer ist das Gefühl, dass ich quasi im selben Atemzug einem Kunden die Rechte eingeräumt habe sich per SSH auf dem Server einzuloggen.

Zwar kann der Kunde auf der Shell nicht allzu viel anstellen - zumindest theoretisch und ich gehe solange davon aus, bis mich jemand vom Gegenteil überzeugt - aber der Upload per SCP, SFTP und Rsync sollte ohne Probleme möglich sein. Ich freue mich schon auf die Berichte und den Tag, wo ich das Feature für alle Kunden freigebe.

Letzten Freitag war auf heise.de im Ticker der Artikel

Links im Tarnkleid

zu lesen... Schon während ich las, was dort so geschrieben wird, musste ich mich übelst am Kopf kratzen, denn die dort beschriebene Technik kam mir sehr bekannt vor.

Am Scheinheiligsten fand ich da die Aussage "Google soll sich - laut Netzgerüchten - schon um einen Fix kümmern" - dabei ist doch Google die Stelle selbst, von der ich dieses Vorgehen kenne:

In den Suchergebnissen werden die Links zu den vorgeschlagenen Seiten stets normal ausgegeben, erst ein "onmousedown"-Event schreibt das tatsächliche Ziel des Links auf einen Tracking-Link von Google um:

<a href="http://de.wikipedia.org/wiki/Untergang" class="l" onmousedown="return rwt(this,'','','','2','AFQjCNHwaZF9llssqoei4h5-z3bBn6xr4w','','0CD4QFjAB','','',event)"><em>Untergang</em> – Wikipedia</a>

Das lässt sich auch ganz einfach testen: Mit der Maus über den Link fahren und den "Mouse-Over-Test" machen, Link mit rechts anklicken, Context-Menü wieder schließen und erneut den "Mouse-Over-Test" machen - voila.

Ich würde ja mal gerne wissen, wer solche "Netzgerüchte" streut und ob Google wirklich ein Interesse hat seine eigenen Tracking-Links auszuhebeln...

Ohne das ich es gerade mit harten Zahlen belegen könnte, aber:

Nachdem ich bei ein paar Kunden testweise APC abgeschaltet habe, ist die I/O-Last der betroffenen Server mehr als Offensichtlich zurück gegangen und in der Summe läuft es ohne Opcode-Cache gefühlt schneller als vorher (was natürlich nicht für einzelne Anfragen gelten muss).

Spannend ist natürlich die Frage, woran das genau liegt. Das kann ich gerade noch nicht mit Fakten belegen - ich werde aber nachforschen! Ist vielleicht ein guter Zeitpunkt um mal Optimizer+ von Zend auszuprobieren. Der kommt mit PHP 5.5 ja sowieso. Für den Moment habe ich APC hingegen gefressen, der brauch sich zumindest heute hier nicht mehr blicken lassen!

Vor ca. zwei Wochen habe ich mich mal daran gemacht und git, libgit2 sowie das dazu passende PHP-Binding für unsere (neuen) Webserver übersetzt.

git und libgit2 ließen sich ohne großes Murren bauen - bei git fiel nur auf, dass es perl und python an fester Stelle erwartet, was etwas doof war, sich aber leicht patchen lies.
php-git war hingegen schon etwas widerspenstiger. Zunächst musste mir auffallen, dass es sich statisch an libgit2 binden wollte und erwartete auch noch, dass die statische libgit2 im Unterverzeichnis der Extension liegt (also auch explizit für diese nochmal übersetzt werden sollte). Theoretisch ist das statische binden kein Problem, in der Praxis sehe ich aber lieber davon ab, da libgit2 ohnehin schon als shared library vorliegt und dann auch (aus diversen Gründen) so genutzt werden kann.
Schlussendlich wollte php-git dann aber gar nicht kompilieren. Was weniger an meinen Änderungen bis dahin lag, sondern eher dass die API der libgit2 an zwei Stellen nicht mehr dem Stand entsprach, den php-git erwartet hat. Nach ein wenig Lesen konnte die 4-5 falschen Zeilen Code anpassen und fertig war auch git als PHP-Extension.

Neben der Entwicklungsumgebung gibt es das alles bisher aber nur auf einem einzigen Server. Ich persönlich hänge gedanklich noch etwas bei Subversion fest und habe den Sprung zu git selbst noch nicht geschafft, weswegen sich um das Testen vorerst ein guter Freund von mir kümmert. Da gab es aber aus zeitlichen Gründen noch kein Feedback... Ich bin gespannt!

Wer es mal testen möchte kann sich gerne per E-Mail melden - einzige Voraussetzung ist allerdings ein bestehendes Hosting im Tarif "Advanced". 

Ich musste heute morgen feststellen, dass auf einigen MySQL-Servern die globale Einstellung "flush" auf "ON" eingestellt war.

Es ist sicherlich schön, wenn MySQL nach jedem Query das Betriebssystem anweist alle Daten auf die Festplatte zu schreiben. Dabei wird dann aber auch jegliche Caching-Strategie ausgehebelt und es fühlt sich an, als ob der Server mit angezogener Handbremse auf der Autobahn fährt...

Sobald ich den Schuldigen gefunden habe werde ich wohl die Peitsche auspacken müssen. Unter 20 Hieben wäre jegliche Strafe zu gering, wobei mich das an einen Post von 2007 erinnert...

Letztes Jahr schrieb ich ansatzweise wie wir es geschafft haben PHP via FastCGI in einem Chroot()-Jail auszuführen.

Der Ansatz seinerzeit arbeitete mit einem Patch für suExec und PHP, was auch gut funktionierte aber eigentlich wenig portabel ist. Der große "Mist" an der Sache war der Patch für PHP, denn PHP ist hier die Endanwendung und damit tendenziell nur eine von vielen. Was ist denn zum Beispiel, wenn am Ende nicht PHP sondern vielleicht Python, Perl oder Ruby arbeiten soll? Dann muss für jede dieser Anwendungen ein eigener Patch bereitgestellt werden.

Die neuste Inkarnation verzichtet daher auf den Patch für PHP, sondern bildet die selbe Logik die in suExec das chroot() erstellt auch in mod_fcgid ab, d.h. mod_fcgid erkennt wann ein chroot() wie erstellt wird und kann seinerseits alles Umgebungsvariablen anpassen. Das erlaubt beliebig viele Endanwendungen bei konstantem Aufwand. Zudem ist mod_fcgid die wesentlich kompaktere Anwendung als PHP - sehr schön!

Nachdem sich die Stimmen mehrten ich möge doch mal bitte eine neue Version meines Gettext-Patches für Wordpress auflegen, habe ich es mir recht weit oben auf die "Nice-to-have"-ToDo geschrieben und voila, da isser!

Fast ein Jahr nach der letzten Version habe ich mich dran gemacht und eine neue Test-Umgebung für Wordpress in der Version 3.5 aufgesetzt und meinen Patch dort installiert.

Mit dem Patch ist es möglich die Struktur von Wordpress intern ein wenig dahingehend zu Ändern, dass anstelle der "PoMo"-Library - einer gettext-Implementation in PHP - die native gettext-Erweiterung von PHP zu verwenden. Das spart Arbeitsspeicher und bringt auch ein wenig mehr Geschwindigkeit für den Blog. Bei meinem Test auf einer wohlgemerkt "nackten" Wordpress-Installation verbesserte sich die Arbeitsspeicher-Situation immerhin um 14,3%. Alle anderen Zahlen überlasse ich lieber unabhängigen Enthusiasten.

Ein Umstand der mich persönlich etwas gefreut hat: Wordpress lief bei mir in einem Starter-Paket wie wir es seit Anfang Dezember 2012 ausliefern. Dort lief es ohne Probleme bereits von Haus aus und schien nach oben hin noch sehr viel Luft zu haben. (Wer eine Migration aus einem älteren Starter-Paket haben möchte, mag das gerne erfragen!)

Als ich heute morgen meinen Laptop wieder aufweckte drehte schon wieder der Lüfter nicht. Also das selbe Prozedere von gestern nochmal.

Hat gut funktioniert - der Lüfter drehte wieder einigermaßen schnell, knarzte aber wie erwartet. Nicht weiter schlimm, wenn man eigentlich nur noch auf die Post warten muss. Da das Gerät aber noch offen war und mir das Knarzen ein wenig auf die Nerven ging, nahm ich irgendwann einen Schraubendreher zur Hand und schlug mit der Spitze auf den oberen Bereich des Lüfters.

Wow! Jetzt schnurrt das Ding wie ein Kätzchen bei unerwartet hoher Drehzahl...
Ich mag aber trotzdem, dass sich der Postbote bald hier blicken lässt (was er wohlgemerkt tut, aber in der Regel bringt er nur Weihnachtsgeschenke mit)

Es ist schon etwas heikel...

Vergangenen Donnerstag legte ich meinen schlafenden Laptop zusammen mit einem Kofer in ein Gepäckfach im Kölner Hauptbahnhof. Als ich einige Stunden später das Gerät wieder abholte war es aus und der Akku vollständig entladen. Als ich ihn einschaltete drehte sich der Lüfter nicht mehr.

Also schraubte ich die treue Maschine auf und reinigte den Kühler ordentlich, woraufhin zunächst alles wieder funktionierte. Nach ein paar Stunden in Betrieb fing der Lüfter auf einmal an zu kratzen. Ärgerlich! Das hatte ich schon mal und habe es erst Anfang des Jahres durch Tauschen des Lüfters behoben. "Macht nichts!" dachte ich mir und bestellte gleich einen neuen Kühler.

Der Kühler steckt leider wohl noch in der Post. Nachdem am Montag bereits der Kühler wieder versagte und ich ihn mit einem Schraubendreher dazu brachte wieder leise zu drehen, merkte ich gerade, dass mein Laptop auf einmal wieder 80 °C heiß ist - nicht in Ordnung und nicht gut! Da ich aber gerne etwas mehr Uptime auf dem Laptop hätte, habe ich kurzentschlossen die Maschine im laufenden Zustand aufgeschraubt und dem Kühler einen erneuten Tritt verpasst.

Unangenehm mit defektem Kühler... Aber irgendwie auch cool diesen Blog-Post (nach langer Zeit) auf einem offenen Laptop zu tippen. Bitte, bitte, liebe Post, schenke mir die Zustellung des Kühlers zu Weihnachten! Der Laptop hier soll zwar ausgemustert werden, aber sterben soll er doch nicht!

Vor ein paar Jahren hatte ich schon einmal versucht PHP-Prozesse auf dem Webserver in ein chroot()-Jail zu stecken. Auch wenn ich seinerzeit ein paar Erfolge verzeichnet hatte, haben es meine damaligen Bemühungen nie in den Produktions-Betrieb geschafft - der Gedanke daran jedoch blieb.

Aus heutiger Sicht weiß ich gar nicht mehr, was ich seinerzeit alles angestellt habe, es war auf jeden Fall kompliziert. Wenn man den Punkt ein Jail zu bauen, dass alle notwendigen Anwendungen und Bibliotheken enthält, außen vor lässt hat man - wie im Titel bereits erwähnt - immer noch 4 Komponenten, die miteinander arbeiten müssen. Am wichtigsten hier ist, dass das was am Anfang in der Kette eingegeben wird am anderen Ende einen gültigen Wert besitzt. In einem "normalen" Setup ist das stets gegeben, in einer chroot()-Umgebung ist eine der wichtigsten Eigenschaften - der Pfad zur Skript-Datei, die ausgeführt werden soll - falsch. Was also tun?

Fangen wir mal am Anfang an: Der Webserver (httpd) nimmt eine HTTP-Anfrage entgegen, mod_fcgid fühlt sich für diese verantwortlich und startet (bei Bedarf) mittels SuExec einen PHP-FastCGI-Server.
Der einzige Teilnehmer in dieser Kette, der aktiv "weiß" dass ein chroot()-Jail existiert, ist SuExec, denn an diesem Punkt wird es auch initiiert. Bei einer einfachen CGI-Anwendung könnte SuExec auch die Umgebungs-Variablen umschreiben, bei FastCGI hingegen wird SuExec einmal ausgeführt und kann für "beliebig viele" Anfragen verwendet werden. Maßgeblich ist dabei nur die User-/Group-ID unter der der Skript ausgeführt wird, die Pfade hingegen können vollkommen verschieden sein (z.B. wenn mehrere Domains vom selben Benutzer verarbeitet werden).
Als Konsequenz hieraus müssen nun im FastCGI-Server (PHP) ein paar Anpassungen vorgenommen werden, denn PHP wird immer die vollen Pfade von außerhalb des chroot()s mitbekommen und wird damit nichts anzufangen wissen.

Als einfachste und naivste Lösung könnte man im neuen Root (sei es /home/chroot) einen gleich lautenden Link auf sich selbst erzeugen  (/home/chroot/home/chroot -> ../../). Das ist aber sehr dreckig und ich würde es als Methode für ein Produktiv-System nicht  zulassen.

Eine bessere Lösung bietet PHP selbst mit seiner doc_root-Direktive in der php.ini: Wird vom Webserver die Umgebungsvariable DOCUMENT_ROOT nicht übertragen, wird dieser Wert beim Suchen von Skripten zur Rate gezogen. Bis PHP 5.3 eigentlich auch nicht nutzbar, da der Wert nur global zu definieren war. Mit Einführung der konditionalen Sektionen in der php.ini ist dieses Feature jedoch recht brauchbar geworden. Allerdings muss man hier jede Domain bzw. jeden Pfad in einer weiteren Datei (der php.ini) konfigurieren - ein weiterer Punkt, wo sich Fehler einschleichen können - besonders wenn man plant, die php.ini komplett in fremde Hände zu geben.

Die für mich sinnvollste Variante war aber eher etwas mehr "Bewusstsein" für die chroot()-Umgebung in PHP zu wecken. Hierzu muss man PHP von außen einen Tipp geben, wo es sich befindet - am einfachsten über eine neue Umgebungsvariable, die in SuExec gesetzt und von PHP beim Finden der Skript-Datei genutzt wird. Der FastCGI-Server lässt diese Variablen auch zwischen den Anfragen intakt, sodass sie bis zum Ableben des Servers erhalten bleiben. Wir schreiben in diese Variable einfach vor dem Aufruf von chroot(), wohin diese Anfrage geht und gleichen sie in PHP dann mit den Variablen SCRIPT_FILENAME und DOCUMENT_ROOT ab. Bei Bedarf werden letztere Beschnitten und gut ists - für die ausgeführten PHP-Skripte sieht es nach einer ganz normalen Umgebung aus.

Kombiniert man das mit einem FTP-Server und einem SSH-Server (mit SCP, SFTP und RSync) die beide nach dem selben Schema chroot()s aufbauen wird es eine runde Sache. Ich freue mich!

Letzte Woche haben wir den Bestatterweblog von Serendipity auf Wordpress migriert. Seitdem ist er einen Ticken langsamer als vorher, allerdings ist der Autor auch wesentlich glücklicher als vorher.

Auch ich muss gestehen, dass Serendipity zwar flott läuft und für meine gelegentlichen Blog-Versuche vollkommen ausreichend ist, Wordpress sich aber schneller entwickelt. Zwar ist die Lokalisierung nach wie vor grauenhaft und ich finde, dass mein ggf. dreckiger Patch mal in den Core gemerged werden sollte und auf lange Sicht eine "echte" Implementierung her muss, die natives gettext vor einem Fallback bevorzugt (und nicht umgekehrt), aber so langsam scheine ich mich dann doch mit Wordpress anzufreunden.

Ist ja auch schon fast gezwungenermaßen. Das Ding wird so oft eingesetzt, dass es fast schon ein Wunder ist mal was anderes zu sehen, als jemand, der eher mit einem minimalistischen Ansatz liebäugelt, ist s9y zwar immernoch ein guter Kompromiss, aber wir sind hingegen mittlerweile so weit, dass wir eine Middleware haben, die aus allen Richtungen (z.B. Serendipity oder TwoDay) richtig gut nach Wordpress konvertieren kann. Frei nach der Regel: Wo ein Markt ist, da auch ....

Erstaunlich: Letzte Woche habe ich mich in einer freien Minute mal dran gemacht, ein wenig die Energie-Einstellungen meines Laptops zu "optimieren".

Er ist nun zwar etwas langsamer als vorher, jedoch primär was die Leistung der Grafikkarte angeht im Gegenzug ist er 10°C kühler (zumindest die GPU) und hält eine ganze Stunde länger. Wahnsinn!

Die Überschrift täuscht etwas - private Schlüssel habe ich schon seit Jahren einige. Alle habe ich eigentlich auch selbst generiert, aber die spannende Frage in diesem Post wird sein wie ich sie generierte und was diesen neuen (den ich sicherlich nie verwenden werde) davon unterscheidet.

Die Antwort ist natürlich ganz einfach: In der Regel generierte ich die private Schlüssel mit Programmen wie GnuPG oder OpenSSL - der normale Weg eben, so wie es quasi jeder tut. Den neuen Schlüssel hingegen habe ich mit komplett selbst geschriebener Software gebaut. Klingt auf den ersten Blick vielleicht einfach, andere mögen mit den Augen rollen, dass ich schon wieder so etwas getan habe - zweitere haben vermutlich recht:

Um "so weit" zu kommen, habe ich zunächst eine Library geschrieben, die Dateien mit Objekten nach ASN.1 (X.680/X.690) lesen und schreiben kann. Als größte Herausforderung stellte sich hierbei der Umgang mit Integer-Objekten dar, da diese nicht auf 32- oder 64-Bit beschränkt sind, sondern von vorne herein "beliebig" groß sein können - da die Library aber auf möglichst vielen System laufen soll, abstrahiert sie an dieser Stelle einfach zwischen den "nativen" PHP-Erweiterungen GMP, BigInteger, BCMath und hat Fallbacks zu Math_BigInteger (PEAR) und - naja... - normalen Integern.

Auf den ASN.1-Parser setzte ich anschließend eine Definition (genauer: Klassen-/Objekt-Definitionen) für X.509 Zertifikate und Keys - teilweise nach RFC 5280 (aber nicht komplett). Zu diesem Zeitpunkt konnte ich also recht leicht bestehende Daten (Zertifikate, Zertifikate-Anfragen und private Keys) einlesen und exakt die selben Daten wieder raus schreiben - eigentlich könnte ich sie auch "modifizieren", das würde bei signierten Zertifikaten allerdings kaum Sinn machen

Viel Spannender wurde es dann aber als ich anfing neue Daten erstellen zu wollen - wie generiert man z.B. einen privaten Schlüssel? Wie funktioniert im Detail überhaupt asymmetrische Verschlüsselung? Wie findet man effizient geeignet große Primzahlen und verifiziert, dass diese überhaupt prim sind?

Beim finden der Primzahlen, kam ich nach etwas Recherche zu dem Ergebnis: Gar nicht. Es gibt keinen "effizienten" Weg, um große zufällige Primzahlen zu finden. Das "zufällig" in der Aussage beschreibt vermutlich auch gleich recht schön, warum es nicht geht. Auch das Verifizieren der Primzahlen erwies sich als relativ deprimierend und ich blieb beim vermutlich allgemein anerkannten Miller-Rabin-Test.
Für den Rest las ich mich ein wenig in RSA-Kryptographie ein und studierte das RFC. Zum Schluss stellte sich dann aber heraus, dass mein größtes Problem wohl war, dass p < q nicht gleich q < p ist - ich hatte in meinem Programm an einer einzigen Stelle zwei Variablen vertauscht und wunderte mich über "komische" Ergebnisse - z.B. dass ein eigentlich 2048 Bit langer Schlüssel auf einmal nur 2047 Bit hatte.

Letzten Endes habe ich ihn aber bekommen: Meinen eigenen privaten Schlüssel - komplett selbst gebaut. (Und kann DER-kodierte X.509-Daten quasi mit bloßem Auge lesen) 

Um wirklich sicher zu gehen, habe ich noch 10.000 private Schlüssel mit OpenSSL generiert und von meinem Programm nachbauen lassen (ohne eigene Zufallsprimzahlen) - erfolgreich. Private Schlüssel wird wohl weiterhin OpenSSL für mich bauen, dazu misstraue ich mir selbst dann doch genug, bei dem weiterführenden Rest hingegen bin ich sehr offen - mal schauen.