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!