Netz - Rettung - Recht

Im Zusammenhang mit dem Update einer Maschine auf Debian Lenny bin ich auf das seltsame Phänomen einer - offensichtlich von PHP erzeugten - Fehlermedlung gestoßen: der Aufruf einer bestimmten Webseite (respektive des PHP-Scripts, das diese erzeugen sollte) ergibt nur die Meldung "No input file specified!". Google führt einen zu diversen Threads, die sich vor allem um die Konfiguration des richtigen Handlers für die Interpretation von PHP-Scripts und um hilflose Fragen von Benutzern, die eigentlich nur ein fertiges Paket installieren wollten und nun nicht mehr weiter wissen, drehen. Erst ein alter Blogeintrag in ixs’ Vodkamelone (nein, das hat nichts mit einem Kamel Nr. Eins zu tun!) von 2005 half mir auf die Sprünge.

Der Grund dieser Fehlermeldung ist offenbar ein ganz seltsames Zusammenspiel der Ausführung von PHP als mod_suphp, d.h. der CGI-Version von PHP in der Weise, daß Scripts unter den Rechten des jeweiligen Benutzers ausgeführt werden, mit der Vergabe von Datei- und Verzeichnisrechten. Die oben genannten Fehlermeldung tritt demnach genau dann auf, wenn zwar der Webserver auf die Datei bzw. ihr Verzeichnis zugreifen, sie also "finden" kann, der Benutzer selbst aber nicht. Dann findet der Webserver - unter der UID www-data - das Script, erkennt es, ruft den Handler auf, der als suid root installiert ist, sich Root-Rechte verschafft, damit auf die UID des Benutzers wechselt und dann mit diesen Rechten den PHP-Interpreter aufruft, um ihn das Script ausführen zu lassen. Dieser PHP-Prozess, der jetzt aber im Kontext des Benutzers läuft, kann dann selbst auf das entsprechende Verzeichnis nicht mehr zugreifen, das Script also auch nicht ausführen, und reagiert dann mit der obigen Fehlermeldung, denn er findet ja keine Datei, die er ausführen könnte.

Vielleicht hilfts ja jemanden, wenn ich ixs’ Analyse her noch einmal wiedergebe und verlinke.

Beim Upgrade eines Systems, auf dem ein Munin-Client läuft, von Debian Etch auf Debian Lenny sind ggf. einige Handgriffe nötig, damit Munin weiterhin ordnungsgemäß funktioniert.

Zum einen muß ggf. für die Apache-Statistiken der Konfigurationseintrag für mod\_status (wieder) ergänzt werden, weil er von der apache2.conf in die Modulkonfiguration in mods-available/status.conf umgezogen ist. "Allow from localhost 127.0.0.1" sollte sich dort finden, und ggf. "ExtendedStatus On".

Problematischer ist das Update von BIND auf Version 9.5.1; im Debian-Paket gibt es zwar ohnehin kein Plugin für den Nameserver, aber wer bisher das bind\_-Plugin von MuninExchange verwendet hat, stößt auf das Problem, das dieses nicht mit BIND 9.5.x kompatibel ist. Der Grund dafür liegt in dem unterschiedlichen Format der von BIND erzeugten Statistikdatei. Die neue Version ist da viel ausführlicher, hat aber eben auch ein ganz anderes Format.

Daher habe ich das Plugin quick’n’dirty auf das neue Format umgeschrieben. Ob es überhaupt noch möglich ist, die Statistiken nur für bestimmte Domains zu sammeln, wie es das bind\_-Plugin anbietet, weiß ich nicht; dieses Feature habe ich nicht benutzt. Jedenfalls kann man mit dem "neuen" Plugin nahtlos an die alten Munin-Graphiken anschließen; daher sammelt es auch nur (genau) die Daten, die auch das alte Plugin angeboten hat, auch wenn das neue Statistik-Format ggf. weitergehende Informationen bereit hält (mit einer Ausnahme: die Referrals scheinen nicht mehr geloggt zu werden). Meine Lösung ist nicht von der Perfektion weit entfernt, schon deshalb, weil sie teilweise Werte etwas willkürlich auf die alten Kategorien mappt (bspw. bei "failures"), aber es tut, und wie meine Graphen zeigen, sind die Werte von der Größenordnung her vergleichbar mit den früher erfassten. Dass BIND 9.5.x die Statistikdatei im übrigen nicht - wie offensichtlich früher der Fall - überschreibt, sondern die neuen Werte jeweils anhängt, stört gleichfalls nicht, weil das Plugin immer nur den letzten Match auswertet.

Wenn jemand Interesse daran hat - oder sich um eine Verbesserung kümmern möchte, für die mir momentan die Zeit fehlt, kann er sich das Plugin bind95 gerne herunterladen; Kommentare sind willkommen.

Wer seine bisherigen Munin-Graphen nahtlos weiterführen will, muß dafür sorgen, daß der symbolische Link - oder die Datei - in /etc/munin/plugins/ denselben Namen ("bind\_") wie bisher trägt, oder die Datensammlungen in /var/lib/munin/$DOMAIN/ entsprechend umbennen, d.h. von /var/lib/munin/$DOMAIN/$HOST-bind\_-\*.rrd nach /var/lib/munin/$DOMAIN/$HOST-bind95-\*.rrd. Und, wie immer: ein Backup schadet nicht …

/ läuft voll.

Das Upgrade meines heimischen Servers von Debian Etch auf Debian Lenny hat im großen und ganzen gut funktioniert; neben dem unvermeidlichen Abgleich geänderter Konfigurationsdateien ("nehme ich die neuen Defaults und Kommentare in meine bestehende Datei, oder übernehme ich die Datei und ziehe die lokalen Änderungen nach?") ergaben sich nur einige Kleinigkeiten (der selbst kompilierte Exim wollte nach Entfernen einiger "obsolote" Libraries neu kompiliert werden; locate war plötzlich verschwunden; die Apache-Konfiguration muß angepaßt werden), wenn man einmal davon absieht, daß /lib offenbar deutlich gewachsen ist, so daß es sich nun rächt, daß ich damals beim Partitionieren mit dem Platz für / etwas arg sparsam war. Daran wird sich allerdings, so fürchte ich, ohne weiteres nichts tun lassen.

Erhöhte Auslastung des Prozessors.

Darüber hinaus stellte sich - ebenfalls Munin sei Dank - bei genauerer Betrachtung aber auch heraus, daß sich die Systemauslastung spürbar erhöht hatte. Außerdem war die Anzahl der Timer-Interrupts geradezu explodiert. Nun, es hätte ja sein können, daß das einfach eine Folge des Upgrades ist - andere Software, mehr Software, wer weiß? Eine nähere Untersuchung der Angelegenheit ergab dann aber, daß der mutmaßliche Verursacher mit hoher Prozessorauslastung in top der Task upsd war, der für die Ansteuerung der USV sorgt (wobei Ansteuerung wohl etwas übertrieben ist; im wesentlichen soll er eine Handvoll Signale auswerten und loggen, bspw. "zu heiß", "zu kalt", "Batterie wird alt", "Störung" oder eben vor allem "Netzausfall" und "Batterieladung niedrig", und im letzteren Fall das System herunterfahren, was er in jüngerer Vergangenheit auch schon einmal erfolgreich getan hat).

Steiler Anstieg ist schon fast untertrieben.

upsd gehört zum Belkin Sentry Bulldog, einer vom Hersteller der USV ausgelieferten Software, die daneben auch noch den Netzwerkbetrieb erlaubt, insbesondere die Abfrage des Daemons über das Netz von einem entfernten Client aus und theoretisch auch eine Weboberfläche, die allerdings bestenfalls minimalistisch gehalten ist. Ich hatte damals bei Installation der USV mit einigem Aufwand eine alte Linux-Version für Redhat installiert und angepaßt, so daß sie lauffähig war, die ihren Dienst bis heute problemlos versehen hat. Ganz offensichtlich kann sie sich aber an die neuen Zeiten nicht so recht gewöhnen; also ist Abhilfe geboten, denn mit einer solch unnötig hohen Last wollte ich das System dann doch nicht auf Dauer laufen lassen.

Eine aktuelle Version des Herstellers war nicht in Sicht, aber wie man schon an den eingestellten Graphiken sieht, habe ich eine andere Lösung gefunden, und die heißt nut.

root@xerxes:~# cat /etc/debian_version
5.0.1

One done, (at least) four to go.

Wer Mailman-Mailinglisten betreibt, wird das Problem kennen: es sammelt sich mit der Zeit - jedenfalls bei offen auf den Webseiten angekündigten oder sonstwie verlinkten Listen - eine ganze Menge Spam an, der zwar in der Regel hängenbleibt, wenn man nur E-Mails von Listenteilnehmern automatisch auf die Liste durchreicht, der dann aber moderiert werden will. Der Aufwand ist dank eines bequemen Webinterfaces nicht so groß - tägliche Hinweismail überfliegen, einloggen, einen Haken bei "discard all", absenden, fertig -, aber wenn man das jeden Tag für ein halbes Dutzend Listen machen muß, ist das trotzdem ziemlich nervig, und man wünscht sich eine einfachere Lösung.

Mit listadmin hat man sie gefunden. listadmin ist ein Perlscript, das die betreffenden Listen und einige Vorgaben aus einer Konfigurationsdatei ausliest, für jede Liste das Webinterface aufruft und dann für jede zu moderierende Mail Absender, Betreff und Moderationsgrund angibt und auf eine Eingabe wartet. Man kann sich dann Teile oder die ganze Mail ansehen und sie entsprechend freigeben, bouncen oder verwerfen; darüber hinaus können auch automatisch Spam-Score-Header ausgewertet werden.

Das macht den Ablauf einfach: alle Listen in die Konfiguration stecken, einmal täglich das Script aufrufen, Default-Action auf "discard" setzen, und für jede Mail einmal <Enter> drücken, und dann noch einmal für jede Liste mit <Enter> die Übernahme der Änderungen bestätigen. Fertig. Kein Aufwand. Toll. Und das beste: listadmin nutzt das Webinterface, d.h. muß nicht auf dem Mailinglistenhost laufen, sondern kann auf einer beliebigen Maschine installiert werden.

(Man sollte allerdings eher nicht das Debian-Package aus stable benutzen, weil das nur Mailman 2.0 unterstützt, und diese Version dürfte in freier Wildbahn eher selten sein. Nachdem der Tarball aber nur aus Manpage und Script besteht, ist es nicht sehr aufwendig, das an der Paketverwaltung vorbei zu installieren.)