Wohnzimmerhostblogger

Als ich heute morgen ins Büro laufen wollte, stand ich auf einmal vor einem Bauzaun. So ein Mannshoher aus Drath. Immerhin war das Ding nicht ganz so hoch wie wir Stuttgarter (inkl. Exil-Rheinländern) momentan solche Bauzäune gewohnt sind, sondern ganz human, normal. "Macht nichts", dachte ich mir, "gehst Du halt außen rum", und lief einen kleinen Umweg um von der anderen Seite heran ans Büro zu kommen.

Doch auch da wurde mir der Weg versperrt! Wie sich herausstellte, ist der Fußweg, der hier am Büro vorbei geht, nun gesperrt weil sie das Nachbarhaus abreißen - keine Überraschung, das machen die schon länger und ich weiß es auch aus erster Hand, da wir da "früher" unser Büro drin hatten. Aber das so weit vorne der gesamte Gehweg abgesperrt wird:

Muss das sein? Ich komme mir entweder vor wie auf einer Baustelle (wir sind sowieso hier von 3 Stück davon umzingelt) oder wie hinter einer Polizei-Absperrung wegen einer Bombe (war schon am 10. Januar so). Ich habe mal bei der Hausverwaltung angefragt, ob man da nicht was tun kann.

Am Montag schrieb ich ja über den Marktbegleiter, der bei Plesk ein Ticket aufgemacht hat um AuthInfo-Codes zu erfragen.

Es gibt Neuigkeiten! Nachdem gestern eine Frist des Kunden verstrichen ist, haben wir heute den Registrar (also das DeNIC-Mitglied, das die Domains eingekauft hat) der Domains ermittelt und kontaktiert - und siehe da:

Die AuthInfo-Codes wurden laut Registrar gestern morgen an den Hosting-Partner verschickt worden, den Kunden haben Sie aber bisher nicht erreicht. Dafür sind die Domains aber schon gekündigt worden. Der Registrar wird seinen Partner seinerseits kontaktieren und wie das Telefonat klang wohl etwas gesalzen.

Verrückt! Ich kann als Anbieter doch keine Domain kündigen wo ich genau weiß, dass der Inhaber ein Interesse hat die Domain zu halten - nur halt bei einem anderen Anbieter. Wenn mir hierdurch Kosten entstehen (z.B. durch die Verlängerung der Domain), dann werde ich diese Kosten auch eintreiben. Wir weisen bei einem fortgehenden Transfer nicht ohne Grund auf eine mögliche Verlängerung der Domain und damit verbundene Kosten hin, für uns gilt eine Domain zum Transfer erst dann als gekündigt, wenn der Transfer auch wirklich abgeschlossen ist.
Es ist natürlich auch anders möglich, das muss dann nur ganz klar kommuniziert sein. So fragte ein Kunde kürzlich nach AuthInfo-Codes für ein paar seiner Domains mit der Begründung er würde die Domains nicht mehr haben wollen, aber vielleicht würde ein Freund die Domains übernehmen. In jedem Falle aber sollten die Domains nicht verlängert werden. Klare Sache.

Ein Kunde schrieb mir kürzlich in einer E-Mail:

bitte bis 100,- keine sperren mehr

Der unmittelbare Hintergrund war, dass wir ihm eine 2. Mahnung geschickt hatten und parallel dazu (wie mehrfach angedroht) die Leistungen gesperrt hatten. Nachdem er 30 Minuten später seine Zahlungsabsicht bekundet hatte, hatten wir die Leistung auch gleich (binnen 10 Minuten, außerhalb der Geschäftszeit) wieder frei gegeben.

Ich kann den Kunden ja verstehen, dass es "echt gemein" ist, wenn wir bei solch einer Sperre auch den ausgehenden (aber wirklich nur den ausgehenden!) E-Mail-Kanal dicht machen und er nur noch E-Mails an @tiggerswelt.net schicken kann, aber im selben Satz die Wichtigkeit von geschäftlichen E-Mails zu erwähnen und 3,- Euro als Peanuts zu bezeichnen (die man dann nichtmal bezahlt) entzieht sich meinem Verständnis - genau wie in diesem Kontext stehende und oben genannte Bitte auch.

Dementsprechend habe ich auch diese Bitte zurückgewiesen, auch mit dem Hinweis, dass wir dann mit einer Sperre geschlagene 3 Jahre warten müssten ehe er überhaupt diesen Umsatz generiert hat. Wenn E-Mails wirklich so wichtig sind (und das glaube ich gerne) scheinen wir zu wenig Geld für diese Dienstleistung zu verlangen. Vielleicht sollte ich dem Kunden mal ein Upgrade anbieten - sagen wir 50,- Euro pro Monat - die Leistung bleibt die selbe, nur sperren wir ihn erst ab 100,- Euro - verprochen! Das wäre doch was

"Der harte Teil des Sommers ist vorbei - mein Kompressionsstrumpf rutscht wieder."

 :D

Ein Neukunde rief mich heute mittag an und klagte mir sein Leid mit seinem alten Anbieter:

Das Ticket, worin er um Herausgabe der AuthInfo-Codes zu seinem Domains bat, hatte man wohl übersehen, sicherte ihm aber zu sich umgehend darum zu kümmern. Anscheinend wusste der Support-Mitarbeiter am Telefon aber nicht, wie genau er denn einen AuthInfo-Code erstellt und an den Kunden schickt - er hätte bei Parallels / Plesk mal ein Support-Ticket aufgemacht und um Hilfe gebeten.

o_O

Entweder übernehmen wir da einen Kunden von einem echt guten Dienstleister, der noch nie nie niemals einen Kunden "verloren" hat (wogegen wohl der Wunsch des Kunden zu Wechseln spricht) oder da weiß jemand echt nicht was er tut.
Zugegeben: Auch wir haben fortgehende Domain-Transfers - primär mit der Begründung "Ich habe jetzt einen Root-Server" - und so gehört es dazu, dass jeder hier weiß, was bei solch einem Prozedere zu beachten und wie es durchzuführen ist (im Zweifel: einfach den Chef - inhouse - fragen).

Ich bin kurz davor einen neuerdings sog. "Shitstorm" zu starten, aber dazu bin ich gerade zu sprachlos und eigentlich sollte ich sowieso meine Klappe halten, denn vor einigen Jahren hatte ich mal vergessen, dass bei einem KK (er ruhe in Frieden) nach 7 Tagen ein Auto-ACK erfolgt und so für kurze Zeit eine Kundendomain zu einem anderen / falschen Provider wechselte. Damals war der transferierende Provider vor, ich sollte mal lernen meinen "Domain-Robot" richtig zu bedienen und ich hätte ihm vorwerfen sollen, er soll mal lernen wie man keine falschen KKs stellt (wobei meine Säumnis natürlich wesentlich schwerer wog). Daher gebe ich diese Aufforderung nun gerne weiter:

Lieber Marktbegleiter, bitte lernen Sie, wie man ihren Domain-Robot bedient! Dazu benötigen Sie vermutlich kein Plesk-Ticket! 

Für den Fall, dass Sie den Hetzner-Robot nutzen, lesen Sie hier nach. Sind Sie bei der Key-Systems GmbH Kunde, so gibt es dort z.B. einen entsprechenden API-Aufruf. Für die anderen Anbieter habe ich auf die schnelle leider keine öffentlich zugänglichen Informationen bekommen, denn auch meine freie Zeit ist knapp bemessen. Laut WHOIS sollte der Hinweis auf die Key-Systems GmbH auch vollkommen ausreichen

Nachtrag: Doku von InternetX (inkl. Plesk!!) gibt es hier.

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!

Gerade eben wurde ich gefragt, ob ich jemanden verprügel...

Da putzt man einmal seine Tastatur und schon hat man eine schwerfällige Enter-Taste.

Letzten Freitag habe ich für eine geschäftliche Reise ein Hotel-Zimmer gebucht.

Als ich heute auf der Webseite des Hotels vorbei schaute, war der Preis für das Zimmer um Stolze 18% gefallen. Ich mag ja nicht knauserig erscheinen, aber irgendwie unwohl habe ich mich dann doch gefühlt - immerhin hätte man das Zimmer noch kostenfrei stornieren und einfach neu buchen können. Da man als Gast ja nirgendwo ein schlechtes Gefühl haben soll, habe ich kurzerhand eine E-Mail geschrieben und neben einer Abrechnung mit der aktuellen Rate auch das Upgrade in eine höhere Zimmerklasse angeboten. Und siehe da:

Das Upgrade hat das Hotel akzeptiert - super! Ist vermutlich die beste Lösung für alle Seiten: Der Umsatz bleibt annähernd der selbe und ich bekomme etwas mehr Komfort. Wenngleich die höhere Zimmerklasse immernoch günstiger als der vereinbarte Preis ist, als Geste reicht das vollkommen aus.

Ouch!

https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql

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!

Eigentlich will ich das Thema hier so öffentlich nicht allzu breit treten, aber es gibt da eine Sache, die mir wirklich sehr am Herzen liegt:

Ich hatte bekanntlich kürzlich eine Lungenembolie - was recht tödlich sein kann. Jetzt, wo sich alles etwas beruhigt hat, wieder Ruhe in mein Leben eingekehrt ist und ich eigentlich mit jedem gesprochen habe, mit dem es was zu besprechen gab, weiß ich, dass ich sehr viel Glück hatte - mein Hausarzt hatte mich seinerzeit eigentlich nur zum Radiologen überwiesen, da er die Lungenembolie ausschließen wollte, seiner Einschätzung nach war die Wahrscheinlichkeit eine zu haben so gering, dass er mich zwischendurch auch noch nach Hause gehen lies. Das EKG und die Blutuntersuchung waren nur minimal auffällig.

Im Gespräch nach meiner Entlassung aus dem Krankenhaus diskutierten wir die Frage, ob es richtig gewesen wäre, mich direkt ins Krankenhaus zu schicken. Aus heutiger Sicht sage ich natürlich "JA! Auf jeden Fall.", aber ich kann auch verstehen wenn man es bei so geringen Anzeichen wie sie bei mir vorlagen ruhiger angehen lässt - auch wenn es hier um eine lebensbedrohliche Erkrankung geht.
Die wesentliche Konsequenz, die ich für mich aus diesem Gespräch mitgenommen habe, ist dass ich meinen Hausarzt - wenn ich ihn schon besuche - mit jedem Detail zu quälen habe, ganz egal für wie unwichtig ich es selbst erachte. Denn hätte ich zu den Symptomen "Kurzatmigkeit" und "Tachykardie" nach erwähnt, dass ich kürzlich (da war es auch schon 2 Wochen her) richtig üble Schmerzen im rechten Bein gehabt habe, hätte ich wohl sofort im Krankenhaus gelegen.

Stattdessen habe ich es verschwiegen, weil ich es für nicht wichtig hielt. Im Gegenzug durfte ich dann am nächsten Morgen auf dem Weg von der S-Bahn bis zum Radiologen - eine Strecke von ca. 200m - nach der Hälfte Pause an einer Säule machen, weil ich schlichtweg überhaupt nicht mehr konnte. Hätte auch dort mein Kopf wie so oft über meinen Körper gewonnen und ich wäre weiter gelaufen, würde ich diese Zeilen vielleicht sogar nicht mehr schreiben.

Daher mein Fazit:
Ich bin kein Arzt und dementsprechend habe ich nicht die Kompetenz irgendwelche Wehwehchen für nichtig zu erklären. Das heißt zwar nicht bei jedem gleich zum Arzt zu laufen allerdings auch nicht sie zu verschweigen, wenn ich einmal dort bin. Ich bzw. meine Versicherung bezahlt den Arzt, damit er sich meine Geschichte anhört. Was davon relevant ist darf er dann selbst bewerten und den Rest muss er eben ertragen. Die Wikipedia (auch wenn oben verlinkt) ist ebenfalls kein Arzt und wird mir keine richtige Diagnose stellen sondern eher meine Angst schüren. (Besonders wenn man am Abend vorher den Befund auf der Überweisung dort sucht)

Mit dem "Ich" meine ich nicht mich selbst im speziellen, sondern ich poste es hier, damit es jeder für sich selbst mitnehmen kann - ich gehe (rückblickend) gerne mit negativem Beispiel voran, wenn es jemand anderen davor bewahren kann selbst in so eine Situation zu geraten.

Ich habe es Anfang des Jahres fast schon erwartet:

Mein Büro ist "vorne rechts" bei uns im Gebäude und hat zu zwei Seiten je eine Fensterfront. Passenderweise so, dass dort den gesamten Tag die Sonne rein scheint. Am Montag war es schon relativ unerträglich, sodass ich seitdem alle Rollos runtergelassen habe und versuche stets ordentlich zu lüften (was schwierig mit einer Kreuzung der Hauptverkehrsadern in Stuttgart vor dem Fenster ist).

Ich will ja nicht meckern, aber das wird ein heißer Sommer

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.