RackBlogger

Beim fröhlichen Patchwochenende ist mir wieder aufgefallen, dass Debian Linux ein Problem damit hat, wenn man für das /tmp-Verzeichnis das noexec-Flag setzt. Dieses sorgt dafür, dass keine Dateien in diesem Verzeichnis ausgeführt werden dürfen - eine durchaus gängige Sicherheitsmaßnahme gegen Rootkits & Co.

Manche Pakete entpacken allerdings das eine oder andere Script ins /tmp-Verzeichnis und wollen es dort ausführen, was dann zu hässlichen Fehlermeldungen bei APT führt.

Einziges Workaround: zum Beginn einer Wartung das /tmp-Verzeichnis ohne noexec-Flag remounten, dann Software aktualisieren, dann wieder mit noexec mounten…

Ein etwas größeres Tuning an den Mailman-Mailinglisten ist nun auch (fast) abgeschlossen. Wenn nun alles stabil in der Testumgebung läuft, werden die bestehenden Mailinglisten in Kürze umgezogen.
Es sei nur so viel gesagt: Mailman lässt sich auch prima in Exim integrieren (wer braucht schon Postfix), virtuelles Hosting mit gleichnamigen Mailinglisten in unterschiedlichen Domains ist nur unmöglich solange man nicht den Code patcht und nun sind auch alle Prozesse automatisierbar.

Frei nach Bernd das Brot: Ich will eigentlich schon längst weg.

Kommt doch ausgerechnet jetzt das ACK für eine wichtige Domain. Hmpf. Also schnell nochmal manuell checken das alles klar geht wenn das Update ausgeführt wird. Besser, potenzielle Probleme werden jetzt gefunden als morgen früh.

Da es um das ACK einer .de-Domain geht, frage ich mich natürlich, wer bei der United Domains AG denn um diese Zeit die ACKs rausschickt? Oder haben die sogar eine Software am Laufen, die ein (manuell bestätigtes) KK-ACK zu einem zufälligen Zeitpunkt oder besser mitten in der Nacht an die DeNIC sendet?

Einem unserer älteren Webserver ist heute der Speicherplatz auf der Daten-Partition ausgegangen. Von rund 100 GB waren nur noch etwa 500 MB frei, bis unser Nagios uns entsprechend gewarnt hat.

Da sich der Webspace der Kunden dort aber in Grenzen hält, stellte sich natürlich die Frage was so viel Speicher “frisst”. Der Ãœbeltäter war schnell gefunden: eine zum Debugging auskommentierte Löschfunktion unserer Log-Verwaltung. Das Verzeichnis mit allen Server-Logs war nämlich über 40 GB groß…

Da hat heute jemand im Online-Bestellsystem ein größeres Hosting-Paket bestellt. Der Auftraggeber war ein H. Meier mit der Rufnummer 089/123456789.

Wenige Minuten später kam dann über’s Kontaktformular diese Mitteilung:

Der Auftrag Nr. 13994 war ein Testlauf. Ich habe leider einmal zu oft “Weiter” geklickt.

Immerhin… sonst hätte ich den Herrn Meier unter dieser Nummer zu gerne mal zurück gerufen

Bei E-Mails mit dem Wort “Sponsoring” im Betreff rollen sich bei mir ja meistens die Zehennägel auf. Von der Grammatik bis zur fast unverfrorenen Erwartungshaltung mancher Zocker-Kids habe ich wirklich genug.

Heute traf aber mal wieder eine “nette” Anfrage ein - ein kleiner Ruderverein einer Schule aus Niedersachsen sucht zwei Domains, um deren auf irgendeinem Root-Server untergebrachten Webspace nicht mehr mit einer .de.vu-Domain versorgen zu müssen…

Das Problem ist allerdings, dass wir weder mit Rudern noch mit dieser Schule, Stadt oder Bundesland in irgendeiner Form etwas Näheres zu tun haben.
Weil’s aber so lieb geschrieben ist, werden wir die Domains (ausnahmsweise) mal für vorerst zwei Jahre übernehmen.

A propos PHP: seit über eineinhalb Jahren gibt es da den Bug #31892, welcher das merkwürdige Verhalten der Umgebungsvariablen PHP_SELF bzw. PATH_INFO in Abhängigkeit der php.ini-Einstellung cgi.fix_path_info beschreibt. Ein entsprechendes Patch ist nicht wirklich komplex (siehe mein Kommentar auf der PHP-Fehlerseite), aber scheinbar verlassen sich schon so viele PHP-Anwender auf diesen Fehler, dass dessen Beseitigung offenbar auch nicht (mehr) in Frage kommt.

Auch bei dem PHP-Update Ende letzter Woche haben wir (wie immer *seufz*) erst unser eigenes Patch einspielen müssen…

Falls jemand an den Patches interessiert ist, ich habe diese an die jeweils aktuelle PHP-Version angepasst: patch-31892-4.4.4.diff, patch-31892-5.1.5.diff.

Ein Kunde hat ein Problem: seine Bildergallerie läuft zu langsam. Es handelt sich dabei um die allseits beliebte Gallery2, die besagter Kunde mit den neuen ACL-Features nutzt. Das Problem in der Praxis: zur sauberen Umsetzung des Zugriffsschutzes werden auch Thumbnails nicht einfach nur als Links auf statische Bilder ausgegeben, sondern durch ein PHP-Script welches erst noch die benötigte Berechtigung zum Abruf des Thumbnails prüft. Ruft man also eine Gallerie-Übersicht auf, so erfolgt für jedes einzelne Vorschaubild ein PHP-Aufruf. Immerhin werden die Thumbnails innerhalb von Gallery2 gecached, also nicht jedes mal neu skaliert. Trotzdem ist der Aufbau der Seite auf diese Art und Weise doch eher zäh.

Nun - diesen Kunden haben wir zuerst auf einen etwas weniger ausgelasteten Webserver verschoben, aber offensichtlich ohne viel Performance bei seiner Gallery2 hinzuzugewinnen. Man muss dazu sagen, dass wir intern zur Umsetzung unserer “Security Policies” unter anderem auf die Eigenentwicklung seCGI setzen, die wir auch als Open Source Software veröffentlich möchten (siehe Blog-Eintrag dank informatik). seCGI sorgt dafür, dass jedes PHP-Script mit den Rechten des tatsächlichen Benutzers ausgeführt wird, und nicht mit den Rechten der Webserver-Software. Die neuesten Bugs in PHP (4 und 5) bestätigen wieder einmal, dass man sich nicht alleine auf open_basedir & Co. verlassen sollte.

Das Ergebnis ist nun, dass wir endlich mal umsetzen was schon länger auf der Wunschliste steht und halbfertig im Testsystem herumliegt: FastCGI. Für solche “Spezialkunden” werden dann 2-3 exklusive PHP-Prozesse unter deren eigener User-ID vorbereitet, welche wie mod_php alle Vorteile der Code-Optimierung und -Caching nutzen können. Da diese zusätzlichen Prozesse einen Teil der Server-Ressourcen exklusiv binden, wird FastCGI vorerst nur für wenige spezielle Anwendungsfälle eingesetzt werden. Mittelfristig soll FastCGI als Alternative zum “normalen” seCGI wahrscheinlich gegen einen geringen Aufpreis für jedermann nutzbar sein.