Aus dem Leben eines Szlauszafs - Bits'n'Bytes

1&1: Rechnungsversand mit ungültigem Absender

thh@inter.net (Thomas Hochstein) — Mon, 06 Jul 2009 22:00:00 +0200

Am Wochenende habe ich mich - endlich - mal wieder meiner Ablage gewidmet und Kontoauszüge, Rechnungen, Bestellungen, Gehaltsabrechungen, Steuerbescheide und was einem sonst noch so die sommerlichen Temperaturen verderben kann sortiert und abgelegt. Dabei stellte ich fest, daß mir für diverse Accounts bei 1&1 die Rechnungen aus dem Juni fehlten: Mai war da, Juli auch, Juni fehlt. Nachdem die Rechnungen per E-Mail versandt wurden, habe ich natürlich als erstes einmal nachgesehen, ob ich wohl vergessen hatte, sie auszudrucken; aber nein, es liegen auch keine E-Mails vor.

Eine genauere Untersuchung ergab dann, daß die Rechnungs-E-Mails nicht angenommen wurden, weil die entsprechenden E-Mails eine nicht-existente Absenderadresse aufwiesen:

2009-06-05 16:39:55 H=mbulk.1and1.com [212.227.126.221] F=<bill-iid-*********-200906051626-********************************@bounce.kundenserver.de> rejected RCPT <thh@*********.de>: Sender verify failed

Sehr nervig. Hilft also nur, den entsprechenden Mailserver (hier wohl mbulk.1and1.com) zu whitelisten. *brummel*

Bessere Verbindung durch Umstöpseln

thh@inter.net (Thomas Hochstein) — Sun, 05 Jul 2009 15:00:00 +0200

Manchmal läßt sich die Qualität der Netzwerkverbindung durch simples Umstöpseln des Netzwerkkabels geradezu durchschlagend verbessern:

Inter-| Receive | Transmit face | bytes packets errs drop fifo frame compressed multicast| bytes packets errs drop fifo colls carrier compressed eth0: 208559761 23066399 819028 0 0 0 0 0 2096539748 21039275 1840 0 0 3360058 3680 0 eth1: 43253328 452956 0 0 0 510 0 0 1767124698 1210761 0 0 0 0 0 0

Sieht so aus, als habe es die Netzwerkkarte im wesentlichen hinter sich:

Jul 5 14:13:32 xerxes kernel: [2762629.588855] eth0: link up, 10Mbps, half-duplex, lpa 0x0000

Jul 5 14:14:50 xerxes kernel: [2762707.126012] eth1: link up, 100Mbps, full-duplex, lpa 0x45E1

(Ja, es ist natürlich in Wirklichkeit eine 100Mb-Vollduplex-Verbindung.)

LILO makes the difference

thh@inter.net (Thomas Hochstein) — Wed, 10 Jun 2009 07:30:00 +0200

Dieser Tage war mal wieder ein Kernelupdate einzuspielen. Normalerweise mache ich das Maschine für Maschine, um bei möglicherweise auftretenden Problemen nur ein System bis zur Lösung lahmzulegen, und eigentlich nie abend, wenn ich eigentlich nur noch ins Bett gehen sollte. Dieses Mal dachte ich mir, das könne ich “noch eben schnell” erledigen - famous last words. Und weil es schnell gehen sollte, habe ich den Update-Prozess mehr oder weniger gleichzeitig gestartet und die ersten beiden Maschinen dann auch parallel rebootet. Während ich dann darauf wartete, daß sie ordnungsgemäß wieder hochkommen, hatte ich die übrigen Updates durchlaufen lassen.

Nur ... kamen die beiden rebooteten Maschinen nicht wieder hoch. Nada. Und natürlich handelte es sich dabei um gehostete Server, und natürlich um ältere solche, die über keine remote console verfügen. Nicht, daß mir das zwingend geholfen hätte.

Also hilft nur fluchen und ein Reboot in das sog. Rettungssystem, ein Minimal-Linux, das eine Untersuchung des Systems erlaubt. Und während ich noch grübelte und in den Logs nach möglichen Ursachen suchte, kam mir auch schon ein Gedanke - beides waren Altsysteme, die als Bootloader noch mit LILO, nicht grub, ausgestattet sind. Und ich konnte mich jedenfalls nicht bewußt erinnern, beim Upgrade irgendwelchen Output von LILO gesehen zu haben ... Also die Partitionen ins Rettungssystem mounten, in das Echtsystem chrooten, lilo ausführen, unmounten, das Echtsystem rebooten und das beste hoffen.

Und, siehe da: das war die Lösung.

Jetzt frage ich mich nur: War das immer schon so, daß man bei einem Debian nach dem Kernelupdate von Hand lilo ausführen mußte? Oder wurde das früher - unter Sarge oder Lenny - nicht automatisch von einem postinstall-Script gemacht? kopfkratz Und wenn letzteres: wie stelle ich dieses Verhalten wieder her?

Aufräumen schafft Platz

thh@inter.net (Thomas Hochstein) — Mon, 08 Jun 2009 07:25:00 +0200

/ lief voll.

Aufräumen hilft.

Nach dem - inzwischen auf allen Rechnern abgeschlossenen - Upgrade auf Debian Lenny beklagte ich unter anderem ein Volllaufen des Root-Filesystems auf einer Maschine, das ich damals bei der Einrichtung etwas arg knapp bemessen hatte. Mittlerweile stellte sich heraus, dass der verbliebene Platz noch nicht einmal mehr für das Einspielen von Kernel-Updates ausreichte; so geht das natrülich auf Dauer nicht.

Auf der Suche nach einer Lösung stellte ich dann - glücklicherweise - fest, dass der große Platzverbrauch seine Ursache vor allem darin hatte, dass von allen jemals aktiv gewesen Kernel noch die zugehörigen Module auf der Platte lagen, insgesamt vier Verzeichnisse voll. Nach Beseitigung eines dieser Modul-Verzeichnisse (zugehörig zu einem schon weggeputzten Kernel - sah es mit dem Platz dann schon viel, viel besser aus, und auch das Kernel-Update ließ sich brav installieren.

So soll es sein.

Geht, geht nicht, geht, ...

thh@inter.net (Thomas Hochstein) — Sat, 23 May 2009 16:31:45 +0200

Nein, es soll heute nicht um Fahrtrichtungsanzeiger, vulgo Blinker, gehen, sondern um einen großen deutschen Freemailanbieter, der sog. “Fun-Domains” anbietet, d.h. die Registrierung von E-Mail-Adressen nicht nur unter der Hauptadresse des Dienstes (“example@freemailer.example”), sondern auch unter weiteren Domains anbietet (“example@cooler-hase.example”).

Dieser Anbieter hat offenbar derzeit Probleme mit der Synchronisation der Benutzerdaten zwischen seinen Mailservern, was mir deshalb auffiel, weil eine E-Mail an eine bestimmte Adresse nicht zustellbar war, bei einer Überprüfung der Adresse diese aber gültig erschien. Nachdem dennoch eine weitere Mail als unzustellbar zurückging, habe ich das Phänomen gestern dann etwas systematischer - unter Zuhilfenahme eines entsprechenden Scripts - untersucht, mit überraschendem Ergebnis.

Gegenstand der Versuchsreihe war die Zustellung einer E-Mail an die Adresse “example@quantentunnel.de”, die eigentlich existieren sollte.

1. Versuch:

mx0.gmx.net GMX Mailservices ESMTP {mx019}
EHLO testhost.example.org
250 mx0.gmx.net GMX Mailservices
MAIL FROM:<mailtest@testhost.example.org>
250 2.1.0 ok {mx019}
RCPT TO:<example@quantentunnel.de>
250 2.1.5 ok {mx019}
QUIT
221 2.0.0 GMX Mailservices {mx019}

Geht! - Also, 2. Versuch:

mx0.gmx.net GMX Mailservices ESMTP {mx071}
EHLO testhost.example.org
250 mx0.gmx.net GMX Mailservices
MAIL FROM:<mailtest@testhost.example.org>
250 2.1.0 ok {mx071}
RCPT TO:<example@quantentunnel.de>
550 5.7.1 We do not relay - access denied {mx071}
QUIT
221 2.0.0 GMX Mailservices {mx071}

Geht nicht?! - Hm. 3. Versuch:

mx0.gmx.net GMX Mailservices ESMTP {mx116}
EHLO testhost.example.org
250 mx0.gmx.net GMX Mailservices
MAIL FROM:<mailtest@testhost.example.org>
250 2.1.0 ok {mx116}
RCPT TO:<example@quantentunnel.de>
250 2.1.5 ok {mx116}
QUIT
221 2.0.0 GMX Mailservices {mx116}

Geht doch?!

Offensichtlich ist der Freemail-Anbieter den naheliegenden Weg gegangen, zur Lastverteilung hinter den nach außen mit nur einem Namen (mx0.gmx.net) und einer IP-Adresse (213.165.64.100) auftretenden Maileingangsserver (MX) in Wahrheit eine ganze Farm von Servern zu stellen. Wenn man sich mit diesem Maileingangsserver verbindet, wird man dann durch einen Loadbalancer auf irgendeine aus einer Vielzahl von tatsächlichen Maschinen verbunden, die nur an ihren Angaben im SMTP-Dialog zu erkennen und zu unterscheiden sind (siehe oben bspw. “mx116”).

Und der Erfolg einer Mailzustellung ist derzeit offensichtlich davon abhängig, welchen tatsächlichen MX aus diesem Pool man “erwischt”. “mx019” und “mx116” kennen die Adresse, “mx071” nicht ...

Backscatter

thh@inter.net (Thomas Hochstein) — Thu, 21 May 2009 14:00:00 +0200

Volle Queue dank Backscatter.

Die Domain eines “Kunden” war dieser Tage von einem Spam-Run in der schon üblichen Weise betroffen, daß der Bösewicht erfundene Absenderadressen aus der Kundendomain verwendet hat. Unzustellbarer Spam geht dann als Bounce an den vermeintlichen Absender, also den Kunden. So weit, so gut, kennen wir alle.

Dumm nur, daß der Kunde einen Catch-All-Account verwendet, also alle E-Mails an beliebige Adressen der Domain annimmt; noch dümmer, daß er für diesen Catch-All-Account eine Weiterleitung definiert hat, bei der der Zielprovider die Bounces als Spam ausfiltert und die Annahme ablehnt. Einerseits ist das potentiell geeignet, den hiesigen Server in eine Blacklist zu befördern, andererseits bleiben diese Bounces dann als “double bounces” in der Mailqueue liegen. Das Ergebnis kann man an der Graphik ablesen ...

Munin-Plugin und BIND 9.5.1 revisited

thh@inter.net (Thomas Hochstein) — Mon, 18 May 2009 07:40:00 +0200

Ich hatte bereits geschildert, daß das Munin-Plugin für BIND nicht mit dem Format der Statistikdatei von BIND 9.5.x umgehen kann, und auch eine Lösung vorgeschlagen, die bei mir dafür gesorgt hatte, daß die Lücke in den Munin-Daten für BIND sehr schmal blieb. Leider mußte ich jetzt - nachdem ich, bedingt durch Zeitmangel, erst nach längerer Zeit wieder einmal einen Blick auf diese spezielle Grafik werfen konnte - feststellen, daß sich ein neues, bald zwei Wochen messendes Loch aufgetan hat.

Der Grund ist einfach: BIND 9.5.1 schreibt die Statistikdatei nicht immer wieder neu, sondern hängt die neuen Informationen am Ende an. So wird die Datei immer länger; hier waren es jetzt > 33 MB. Und da das Munin-Plugin die Datei schlicht zeilenweise liest und dabei auf das (letzte) Auftreten bestimmter Schlüsselbegriffe achtet, um die entsprechende Zeile dann auszuwerten, dauert das ab einer gewissen Dateigröße einfach so lange, daß dabei ein Timeout des entsprechenden Plugins entsteht.

Weiß jemand zufällig, ob man BIND 9.5.1 beibringen kann, die Statistiken wie früher immer neu zu dumpen, statt sie an die alte Datei anzuhängen? Sonst wird sich wohl ein Cronjob der Sache annehmen müssen, der die Datei rotiert - oder regelmäßig löscht.

Kein Anschluß unter dieser Nummer

thh@inter.net (Thomas Hochstein) — Sat, 16 May 2009 17:16:00 +0200

Da trudelte doch am gestrigen Freitag eine Anfrage über das Kontaktformular auf meiner Homepage mit der Bitte um Hilfe bei einer bestimmten Fragestellung (im Zusammenhang mit Newsgroups und einer schulischen Aufgabe) ein. Man weiß ja nie, wie sehr es dabei eilt, also nutze ich heute die anstehende Zugfahrt und stelle eine ausführliche Antwort - der Mailclient zählt rund 170 Zeilen, inkl. Quotes - mit Links zu weiterführenden Texten zusammen, die ich von unterwegs noch absende (immerhin habe ich jetzt ja eine funktionierende UMTS-Karte ).

Und was ist das Ergebnis? Die angegebene E-Mail-Adresse des Fragestellers (bei einem großen deutschen Freemailanbieter mit drei Großbuchstaben) ist nicht existent. Supersache.

(Vielleicht sollte ich nächstes Mal einfach gar nicht erst antworten. Spart Zeit, die ich eigentlich nicht habe ...)

INN und SSL/TLS (Debian Lenny)

thh@inter.net (Thomas Hochstein) — Mon, 27 Apr 2009 20:55:00 +0200

Das Internet ist schon lange kein friedlicher Ort mehr, an dem jeder jedem trauen kann - und deshalb wurden die ursprünglichen, unverschlüsselten Kommunikationsprotokolle schon lange durch kryptograhpisch abgesicherte Variationen ersetzt. Telnet verwendet heute wohl niemand mehr offen im Netz, stattdessen gibt es SSH; auch im Mailverkehr pflegt man - hoffentlich - zumindest das Paßwort beim Abruf über POP3 via APOP und beim Versand via SMTP über eine SMTP-Aut-Variante mit Verschlüsselung zu sichern, wenn man nicht ohnehin die ganze Kommunikation SSL-verschlüsselt, und auch diejenigen, die FTP noch nicht durch SCP/SFTP ersetzt haben, nutzen hoffentlich wenigstens SSL, um die Paßwortübertragung zu verschlüsseln.

So weit, so gut, aber schon vor einer ganzen Weile fiel mir auf, daß diese Regel für Netnews (NNTP) offenbar nicht gilt (und für UUCP oft auch nicht ...); denn zu seinem oder seinen Newsserver(n) verbindet man sich oft genug noch unverschlüsselt, obwohl auch dort ein Paßwort übertragen wird. So ging es zumindest mir, und ich habe mich am vergangenen Wochenende entschlossen, dagegen etwas zu unternehmen und auch die Verbindung zumindest zu meinem eigenen Newsserver zu verschlüsseln.

Das ist - mit dem INN 2.4.5-Paket aus Debian Lenny - eigentlich ganz einfach:

Ein SSL/TLS-fähiger nnrpd ist bereits vorhanden (nnrpd-ssl). Wer nicht das vorgenannte Paket verwendet, muß den INN (oder zumindest den nnrpd) ggf. mit “configure --with-openssl” noch einmal kompilieren.
Schlüssel muß man sich erzeugen, sofern noch nicht vorhanden. Vorhandene Zertifikate bzw. Schlüssel sollte man vielleicht am einfachsten kopieren; standardmäßig werden sie in /etc/news gesucht. Das ist verhandelbar respektive konfigurierbar, aber das Zertifikat und der Schlüssel müssen dem User news gehören und die Rechte 600 aufweisen.
Die Konfigurationsdatei /etc/news/sasl.conf muß editiert (oder ggf. angelegt) werden, um die korrekten Pfade zum Zertifikat und dem privaten Schlüssel des Servers aufzunehmen. “tls_cert_file” und “tls_key_file” sind die relevanten Parameter.
Danach muß der nnrpd-ssl nur noch veranlasst werden, auf Port 563 (NNTPS) zu lauschen. Das kann man u.a. über den (x)inetd erreichen, indem man bspw. folgende Konfigurationsdatei in /etc/xinet.d/ einwirft:

service nntps
{
   socket_type     = stream
   protocol        = tcp
   wait            = no
   user            = news
   group           = news
   server          = /usr/lib/news/bin/nnrpd-ssl
   server_args     = -S -p 563
}

Voraussetzung dafür ist, daß die /etc/services den Service “nntps” kennt.

Voila. Wer mag, kann auch noch eine CA daran anflanschen und bspw. Nutzer statt via Paßwort auch via Zertifikat authentifizieren, indem er die readers.conf entsprechend anpaßt, aber daran habe ich keinen Bedarf; mir genügt die Verschlüsselung der Verbindung zwischen Server und Client.

(Danke an Viktor Kafke für die entsprechenden Tips.)

Mailman 2.1.12: listadmin.pl 2.40 läuft nicht mehr

thh@inter.net (Thomas Hochstein) — Sat, 18 Apr 2009 17:18:00 +0200

Die Titelzeile faßt es eigentlich schon zusammen: seit dem Upgrade meiner Mailman-Installation auf die aktuelle Version 2.1.12 mag das praktische Perlscript listadmin.pl, über das ich bereits berichtet hatte, seinen so hilfreichen Dienst nicht mehr versehen (auch nicht nach Update auf die aktuellste Version 2.40, die wohl aus dem Jahr 2007 datiert), offenbar deshalb, weil der Parser über geänderte Webseiten (geänderte Mailman-Templates) stolpert.

Solange keine administrativen Aufgaben zu erfüllen sind, läuft es problemlos durch (so soll es sein); wenn man es auf nicht mehr existente Listen losläßt, beschwert es sich und läßt die Liste aus (auch das ist vernünftig und akzeptabel):

ERROR: unexpected contents, please send /tmp/dump-0.144370685638027-list@domain.example.html to $address -- skipping list

Wenn es aber etwas zu tun hätte, weil sich Anfragen in der Moderations-Queue befinden, dann bricht es leider einfach zusammen:

fetching data for list@domain.example ... Died at ./listadmin.pl line 802.

Grund ist offensichtlich ein Stolpern des Parsers:

sub parse_subscription {
    my ($mmver, $config, $parse, $data) = @_;

    $parse->get_tag (“td”) || die;
    my $address = $parse->get_trimmed_text (“/td”) || die;
    my $tag = $parse->get_tag (“input”) || die;
    my $id = $tag->[1]{“name”};
    $parse->get_tag (“/table”) || die;
$parse->get_tag (“/tr”) || die;
    $data->{$id} = { “subscription” => $address };
}

In der hervorgehobenen Zeile verlassen sie ihn. Offenbar sucht listadmin.pl erst nach zu genehmigenden oder abzulehnenden Beitrittsersuchen, bevor es die weiter unten auf der Seite folgenden zu moderierenden Beiträge abarbeitet, und erkennt letztere fehlerhaft als erstere, weshalb es die falsche Routine zum Parsen derselben aufruft, die dann aus dem Tritt gerät.

Allerdings ist mir der Parser auf Anhieb erstmal etwas zu hoch, daher meine Frage: Gibt es vielleicht schon eine aktuellere Version des Scripts? Oder hat sich schon jemand damit beschäftigt und einen Patch in der Hinterhand? Falls ja: Bitte melde Dich!

Debian Lenny: erste Erfahrungen

thh@inter.net (Thomas Hochstein) — Fri, 17 Apr 2009 20:12:00 +0200

Platzverbrauch auf / gestiegen.

Speicherauslastung unter dem Strich unverändert.

Nachdem ich in den letzten Tagen einige Maschinen - heimische und Mietserver, letztere mit und ohne serielle Konsole - von Debian Etch auf Lenny hochgezogen haben, sind mir dabei einige Gemeinsamkeiten aufgefallen. Zunächst vielleicht das wichtigste: die in den Release Notes angesprochenen Probleme mit neu nummerierten Devices oder gar Problemen beim Auffinden des Root-Filesystems beim Reboot (Device enumeration reordering, System boot hangs on Waiting for root file system) sind bei mir glücklicherweise in keinem Fall aufgetreten; das verlief vielmehr alles durchaus problemlos, sei es mit LILO als Bootloader (ggf. an Verkleinerung der RAM-Disk denken, Prepare initramfs for LILO!) oder mit grub. Das hat mich besonders erleichtert, weil, wie gesagt, nicht alle entfernten Maschinen über eine serielle Konsole und damit über die Möglichkeit eines einfachen Zugriffs bei Bootproblemen verfügen.

Auch ansonsten verliefen die Upgrades an und für sich - bei der in den Release Notes empfohlenen Vorgehensweise - erfreulich unproblematisch. Das gehört auch zu den Dingen, die ich an Debian besonders schätze: der Upgrade-Prozeß ist in der Regel schmerzlos, gut dokumentiert und getestet. Hilfreich insbesondere, wenn man sich in den eher zentralen und maschinennahen Bereichen nicht so besonders auskennt und/oder keinen unmittelbaren Zugriff auf das System hat.

Mehr Entropie ...

... zumindest manchmal.

Schon allein ein Blick auf Munin zeigt aber einige Veränderungen, die sich aus den in den Beitrag eingestreuten Graphiken ergeben. Dass der Platzverbrauch im Rootverzeichnis - genauer wohl in /libs - gestiegen ist, hatte ich schon vorgestern nach dem Update der ersten Maschine berichtet. Das ist aber natürlich nicht die einzige Veränderung - es gibt auch positives zu berichten. So hatte ich zuerst den Eindruck gewonnen, daß die Speicherauslastung zurückgegangen ist, nicht nur, soweit sich die Buffer nach dem Reboot erst einmal wieder füllen müssen, sondern auch, soweit der von Applikationen in Anspruch genommene Speicher betroffen ist. Das scheint mir aber ein Irrtum gewesen zu sein; mit der Zeit steuert die Auslastung wieder dem bisherigen Wert zu. Was sich aber definitiv direkt um Größenordnungen erhöht und insoweit verbessert hat, ist die zur Verfügung stehende Entropie, wichtig für die Erzeugung von Zufallswerten, insbesondere auch im Zusammenhang mit der Verschlüsselung. Auf den meisten Maschinen ist die Erhöhung eine generelle, auf einer Maschine ist sie zumindest eine temporäre. Zumindest auf einer Maschine hat sich auch die Anzahl der MySQL-Queries spürbar verringert; das erscheint mir aber eher zufällig zu sein (oder steckt vielleicht irgendwo im neuen INN drin - denn der dürfte auf dieser Maschine für die SQL-Queries in erster Linie verantwortlich sein).

Deutlich weniger MySQL-Queries.

Ansonsten finden sich die meisten Veränderungen, wie in den Release Notes schon angekündigt, rund um den Apache herum: die Konfigurationsdatei wurde deutlich entschlackt und die Konfiguration von Modulen in die entsprechenden Module - in mods-available/ - verschoben, phpMyAdmin wird nicht mehr über einen Symlink, sondern direkt über einen Alias aus der Serverkonfiguration (in conf.d/phpmyadmin.conf, ein Symlin auf /etc/phpmyadmin/apache.conf) eingebunden, und mod_suphp muß auf einen anderen MIME-Type reagieren (application/x-httpd-php statt x-httpd-php) und wird per default für /usr/share, wo die in Debian gepackageten Webapplikationen liegen, deaktiviert (in mods-available/suphp.conf). Das erfordert ggf. einige Nacharbeit. Hat man zum Beispiel bisher den https-Zugriff auf phpMyAdmin dadurch erzwungen, daß das DocumentRoot für den normalen, unverschlüsselten Zugriff auf den Server nicht auf /var/www/ zeigt, sondern auf ein anderes Verzeichnis, so daß phpMyAdmin nur beim Aufruf per https gefunden werden konnte, hilft das jetzt nicht mehr, denn per Alias-Direktive wird es immer eingebunden. Hier kann man stattdessen an der passenden Stelle ein SSLRequireSSL in /etc/phpmyadmin/apache.conf einsetzen. Wenn man auch die Webapplikationen (weiterhin) nicht unter mod_php, sondern unter mod_suphp laufen lassen will (vielleicht schon deshalb, weil man mod_php gar nicht installiert hat), dann sollte man die entsprechenden Änderungen in mods-available/suphp.conf auskommentieren.

Schließlich beschwerte sich pam_env bei mir seit dem Upgrade, daß es /etc/default/locale nicht finden könne. Ein Anlegen der Datei beseitigt diese Fehlermeldungen aus dem Logfile.

Eine Sache ist mir allerdings noch etwas schleierhaft, und zwar hatte ich zumindest auf einer Maschine das Problem, das php-cgi ab und an segfaultet:

Apr 16 19:50:37 machine kernel: [113175.233973] php-cgi[2618]: segfault at b6d62eae ip b638e3cf sp b6b940b8 error 4 in libgcc_s.so.1[b6387000+c000]
Apr 17 01:25:27 machine kernel: [134723.984243] php-cgi[31344]: segfault at b6c94eae ip b62c03cf sp b6ac60b8 error 4 in libgcc_s.so.1[b62b9000+c000]
Apr 17 18:08:37 machine kernel: [199692.119127] php-cgi[21780]: segfault at b6d2be90 ip b6d2be90 sp b6b5d3ac error 4 in librt-2.7.so[b771f000+7000]
Apr 17 18:14:32 machine kernel: [200072.558515] php-cgi[22441]: segfault at b6cd9e90 ip b6cd9e90 sp b6b0b3ac error 4 in libtasn1.so.3.0.15[b759d000+f000]

Das tut es eben nicht immer, nur manchmal, vorher nicht und seitdem auch nicht mehr. Google hat mir eine entsprechende Anfrage eines Nutzers auf der Debian-User-Mailingliste aus dem Februar präsentiert, die allerdings bisher AFAIS ohne Antwort geblieben ist; dort scheinen mir dieselben Symptome dargestellt zu sein. Fällt jemand etwas dazu ein?

Apache 2.x, php-cgi, mod_suphp und "No input file specified!"

thh@inter.net (Thomas Hochstein) — Fri, 17 Apr 2009 17:03:00 +0200

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.

Debian Lenny und Munin

thh@inter.net (Thomas Hochstein) — Thu, 16 Apr 2009 20:33:00 +0200

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 ...

Debian Lenny und Belkin Sentry Bulldog

thh@inter.net (Thomas Hochstein) — Wed, 15 Apr 2009 20:27:00 +0200

/ 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.

Viele bunte Sm^WInterrupts.

nut ist sozusagen die universelle Variante der Bulldogge: ein Daemon, der mit vielen verschiedenen USV sprechen kann, plus Client zur Auswertung und Steuerung des Inputs, plus optional ein Webinterface - und vor allem für Debian paketiert.

Die Installation und Konfiguration erwies sich anhand eines Tutorials als recht einfach, wenn auch für meinen Geschmack unnötig kompliziert - denn der Autor (oder der Debian Maintainer) liefert keine Konfigurationsdateien mit, noch nicht einmal in Form komplett auskommentierter Rohfassungen, die man vor einem ersten Start erst bearbeiten muß, sondern nur Samples, die in /usr/share/doc/nut/examples/ liegen und sinnvollerweise erst einmal ins Konfigurationsverzeichnis kopiert, umbenannt und dann editiert werden müssen. Das ginge m.E. auch einfacher. Mit der mitgelieferten Doku und dem genannten Tutorial lassen sich aber alle nötigen Schritte einfach nachvollziehen (von einem Fehler bei der Beschreibung der Freigabe des Zugriffs auf die serielle Schnittstelle abgesehen; dort steht im Tutorial udevadm control trigger, richtig wäre aber udevadm trigger).

Einige Tests später läuft der Daemon dann fröhlich vor sich hin, versteht sich auch mit der USV gut, und die Weboberfläche sieht richtig schick und elegant aus. Da ist es auch zu verschmerzen, daß der Belkin-Client sich natürlich nicht mehr mit dem Server verbinden kann. Mit “mal eben vom Windows-Desktop aus nach der USV schauen” ist’s also Essig, genauso mit der dort mitgeführten Ereignis-Dokumentation und diversen Auswertungen, Listen und Graphiken, die - ehrlich gesagt - aber ohnehin nur begrenzten Wert hatten. Die positive Wirkung auf die Systembelastung läßt sich jedenfalls aus den eingestellten Graphiken leicht ablesen.

Bleibt jetzt nur noch abzuwarten, ob im Ernstfall auch der Shutdown funktioniert - aber das festzustellen bleibt uns hoffentlich noch längere Zeit erspart.

Debian Lenny

thh@inter.net (Thomas Hochstein) — Tue, 14 Apr 2009 22:30:00 +0200

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

One done, (at least) four to go.