RackBlogger

PHP gehört wirklich nicht zu meinen Lieblings-Sprachen. Und es wird mir auch zunehmend unsympathischer.

Neuestes Beispiel: ein Kunde hat ein Problem mit einem Script, welches unter anderem irgendwo Dateien auf seinen Webspace hochlädt (per PHP-File-Upload). Die neu erstellten Dateien haben aber “nur” die Rechte 0600, obwohl diese eigentlich 0644 haben sollten. umask() ist richtig gesetzt, ein explizites chmod() nach dem Upload ist nicht möglich (es handelt sich um ein gekauftes, codiertes Script), und bei seinem bisherigen Webhoster hat das Script nach Angaben des Kunden wohl einwandfrei funktioniert.

Andere Baustelle: eine Kundin zieht eine Contenido-CMS-Website auf einen Webspace bei uns um. Gleiches Problem: nach Uploads sind die Rechte immer falsch. In diversen Contenido-Foren weisen deren Entwickler die Notwendigkeit eines chmod() nach dem move_uploaded_file()-Aufruf von sich - “der Provider ist für eine anständige umask() verantwortlich”.  Wenn das Problem nur in der umask() bestehen würde…
Nun haben wir die Wurzel allen Ãœbels identifiziert: PHP selbst.

Bug #42291: wird eine Datei mit PHP hochgeladen und mit move_uploaded_file() auf ein Ziel verschoben welches im gleichen Filesystem wie die temporäre Datei liegt (=>rename), dann werden die Rechte fälschlicherweise auf 0600 gesetzt statt auf 0644. Da bei uns aus Sicherheitsgründen jeder Kunde sein eigenes tmp-Verzeichnis innerhalb seines geschützten Kundenverzeichnisbaums hat (also im gleichen Filesystem), tritt genau dieser Fall ein.

Der Workaround für die betroffenen Kunden ist also, diesen ein tmp-Verzeichnis auf einer anderen Partition einzurichten… ein kurzer Test hat das bestätigt.

In den letzten zwei Wochen haben wir einen neuen Server nach dem anderen aufgebaut, u.a. für ein recht interessantes VoIP-Projekt eines größeren Kunden (daher auch so wenige Blog-Beiträge…). Um nun die Ausfallsicherheit noch etwas mehr zu erhöhen, sind alle Server ab sofort über zwei Uplinks mit zwei verschiedenen Routern verbunden (Aktiv-Passiv-Failover). Sollte also im Rechenzentrum ein Router ausfallen, rebooten oder sonst irgendwie gestört sein, wird automatisch (per HSRP) auf den anderen Port umgeschaltet.

Anfang nächsten Jahres planen wir außerdem, die Switches auch redundant auszulegen; da fast alle neueren Server ohnehin Dual-Gigabit-Ethernet-Schnittstellen haben, kann somit noch mehr Redundanz erreicht werden.

Ach ja, nächste Woche tauschen wir auch noch eine Firewall aus - auch gegen ein redundantes Modell mit Hot-Failover (also ohne Abbruch bestehender Verbindungen).

Nur redundante Netzteile haben noch die wenigsten Server bei uns (nur ein paar extrem wichtige Exoten); sollte es wirklich mal das Netzteil eines ordinären Webservers zerreißen, reicht es in der Regel aus, die HotSwap-Platten zu ziehen, in einen bereitgehaltenen Ersatzserver zu stecken und anschließend das defekte Netzteil in aller Ruhe auszutauschen.

Habe ich schonmal erwähnt, daß ich KVM-over-IP einfach liebe?

Sonst hätten wir den folgenden Todesruf eines (zum Glück unwichtigen) Rechners nicht gesehen - per SSH war bereits alles tot:

Jeder unserer Neukunden erhält die Zugangsdaten zu seinem neuen Webspace-Paket per Post. So erreichen die Zugangsdaten nur dann den Auftraggeber, wenn die Anschrift korrekt ist.

Von daher reagiere ich erst einmal skeptisch, wenn ein Kunde, der die Zugangsdaten vor einer knappen Woche per Post erhalten haben sollte, nachfragt, wann wir ihm denn seine Daten schicken würden. Klar - es gibt exotische Ausnahmefälle:  Briefe gehen in sehr seltenen Fällen wirklich mal verloren, oder werden beim (Geschäfts-)Kunden falsch abgelegt/weitergeleitet.

Im Zweifelsfall schicken wir die Daten dann eben per Fax raus, oder klären die Sache telefonisch ab.

Nachdem das (angebliche? weil bisher noch nicht näher benannte) Spamurteil des Landgerichts Lüneburg durch die Blogosphäre geistert will ich auch noch ein Wort dazu sagen: alles kein Problem.

Unsere Kunden können individuell ihren Spamfilter konfigurieren und dabei (derzeit noch über den Support, in Kürze aber auch über’s Web-Frontend) nicht nur Greylisting und Content-Filter, sondern sogar Blacklists individuell aktivieren oder deaktivieren. Somit bleibt es dem Kunden selbst überlassen, ob er Spam empfangen “will”.

Auch ohne dieses Urteil hätte ich als Provider ein Problem damit, dem Kunden (auf welche technische Art auch immer) irgendwelche E-Mails vorzuenthalten, wenn er/sie explizit keine Filterung wünscht (und Ja - wir haben solche Kunden…)

So wie Dirk sich über Marktbegleiter mit eigenem Rechenzentrum aufregt, frage ich mich bei so manchem Marktbegleiter, was das mit dem “Hosting für Dummys” soll, bei dem gezielt unerfahrene/technikunwillige Kunden geworben werden. Der Leitspruch ist dann “Sie müssen gar nichts machen [ oder können ] - mit einem Knopfdruck ist Ihre Anwendung installiert!”.

Das mit der Installation mag zwar schon einfach sein - aber wer aktualisiert dann brav die ganzen Anwendungen? Egal ob WordPress, PostNuke, Mambo oder was-auch-immer - wenn der “unerfahrene Anwender” das nicht mal anhand der jeweiligen Anleitungen selber installieren kann, wie soll er es dann up-to-date halten?

Ich verstehe unter “Application Hosting” doch etwas mehr als “Application Installation“.

Nichts für ungut…

SWsoft, Hersteller von Verwaltungs- und Virtualisierungssoftware (u.a. Plesk, Confixx, Virtuozzo), war letzte Woche offenbar auf großer Einkaufstour. Am 11.09. wurde das Konkurrenzprodukt ENSIM pro aufgekauft, drei Tage später der Konkurrent Positive Software (ein Tochterunternehmen von Comodo) mit Produkten wie H-Sphere, NOC Monkey oder FreeVPS.

Der Markt konsolidiert sich also zunehmend in Richtung SWsoft (die nun übrigens auch ihr altes Logo ersetzt haben).

Nur gut daß wir unsere Server alle selber verwalten können.

Die technischen Anforderungen bei der DENIC sind enorm groß - keine Frage. Dennoch finde ich es langsam nervig, daß diese inzwischen schon wöchentlich Wartungsarbeiten an den Produktivsystemen haben - und zwar nicht nachts, sondern tagsüber.

Was nun den Vogel abschießt ist die Ankündigung einer großen Wartung und Umzug in ein anderes Rechenzentrum, was den Ausfall quasi aller DENIC-Dienste (außer den .de-Root-Nameservern ) mit sich bringt. Nein, nicht in einer Nacht von Samstag auf Sonntag um 03:00 (wie das jeder verantwortungsvolle Admin versucht), sondern an einem Dienstag von 10:00-16:00. Kein WhoIs, keine Domainregistrierungen, keine Updates, kein Transit, - einfach NICHTS geht dann.
Kein Wunder, daß man denen die .net-Zone nicht auch noch anvertrauen wollte…

(Dieser Artikel entstand in meiner unbekümmerten Sicht als Nicht-DENIC-Mitglied. Sollte es ernsthafte Gründe für diesen unglücklichen Zeitpunkt geben, lasse ich mich gerne eines Besseren belehren…)