Wohnzimmerhostblogger

Es tut mir ja für die Kundin ein wenig leid, denn sie steht da als fast unbeteiligte in der Mitte und muss immerzu hin und her mitteln...

Ihr alter Provider (eher wohl ein Arbeitskollege, der das ganze mal als freundschaftliche Dienstleitung gemacht hat) beharrt darauf, dass der Transfer einer .de-Domain auch ohne AuthInfo-Code möglich ist. Er belegt das ganze auch mit Screenshots aus seiner Verwaltungsoberfläche, die in der Tat Auth-Codes nur für .com-Domains anbietet (aber streng genommen ist das ja ohnehin was anderes).

Ich würde ja anders, wenn ich könnte. In meiner vorletzten E-Mail fügte ich - ähnlich wie letztes Jahr schon für jemand anderen - schon Links zu den FAQ seines Anbieters bei, die Beschreiben wie man einen AuthInfo-Code anfordern kann. Da das nicht fruchten wollte, habe ich diesmal ein einschlägiges Zitat der DeNIC samt Link zur Seite beigefügt und drohe schon damit einen AuthInfo2 (AuthInfo-Code bei Nicht-Erreichbarkeit) zu beantragen (auf meine Kosten versteht sich).

Das lustigste an der Sache: Obwohl ich regelmäßig selbst Domaintransfers mit AuthInfo-Code durchführe, fange ich immer wieder an zu Zweifeln... Geht es vielleicht doch anders? Hat Dein Gegenüber vielleicht doch recht? Bist Du es, der es gerade kompliziert macht? Nein, nein, nein!!! Der KK ist seit Februar 2010 nicht mehr existent! Es geht nur noch "ChProv mit Authinfo-Code" - und das ist auch gut so!

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...

Im Februar hatte ich ja schon einmal PHP und Git thematisiert.

Gibt es Webhosting-Kunden, die hier mitlesen und das gerne auch mal ausprobieren wollen? Letztes Mal hatte ich noch beim Tarif ein paar Bedingungen gestellt, aber nachdem mein Tester aus zeitlichen Gründen wohl auch nicht dazu kommen wird, bin ich da etwas flexibler

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!

Letzte Woche wollte ich mich noch im Blog beschweren, ich verkniff es mir jedoch da ich nicht schlecht über das seinerzeit wirklich schöne Wetter schreiben wollte. Heute kann ich es ja wieder tun:

Das Positive an diesem Wetter bzw. der Rückkehr des Winters ist, dass mein kleiner privater Kühlschrank im Büro wieder funktioniert.

Genau genommen handelt es sich dabei um einen mit Kunststoff beschichteten Karton, den ich mit allerlei Leckereien gefüllt habe und draußen unter meinem Fenster zwischen Fassade und "Fassadenschmuck" platziert habe. Fällt kaum auf und hält super frisch. Letzte Woche musste ich ihn schon einmal reinholen und mich um den Inhalt kümmern, da draußen ja bekanntlich und eigentlich auch schönerweise keine Kühlleistung mehr erbracht wurde.

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!

Bevor ich es vergesse und die erste Woche des neuen Jahres (wo man es meiner Meinung nach problemlos sagen darf):

Ich wünsche allen hier verbliebenen Lesern ein gesundes, glückliches und frohes neues Jahr 2013! 

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!