Christophs Weblog

Vierundzwanzig sind zu wenig

„Meine Nerven“ oder „Warum ich Gentoo hasse“

Wie den meisten ja bekannt ist, darf man bei Gentoo Linux regelmäßig aktuelle Softwareupdates installieren, damit auch immer alles auf dem neusten Stand ist. Sowas macht man meist „nebenbei“, schaut sich dann ein paar Logfiles an und gut ist’s.

Leider läuft nicht immer alles so glatt, so dass ich heute einige Stunden nach einem Fehler suchen durfte, was mich einiges an Nerven gekostet hat …

Es hat alles ganz harmlos angefangen: Verschiedene Updates liefen ohne Probleme durch und ich wollte gerade meine heutige Update-Session beenden, da viel mir meine qmail-Queue auf:

messages in queue: 25
messages in queue but not yet preprocessed: 0
Naja, das ist meist nichts besonderes, da sich dort auch viel Müll (meist Spam) rumtreibt – trotzdem habe ich mal ins qmail-qread geschaut und siehe da: eine Mail an einen mithelfenden Admin hing bei mir fest – das darf nicht sein.

Ein Blick in die qmail-Logfiles zeigte das Problem:

TLS_not_available:_connect_failedZuerst habe ich natürlich versucht mehr aus meinen Logfiles zu ziehen, habe die Mails erneut zugestellt, etc. Es betraf nicht nur einen Ziel-Host, sondern gleich zwei verschiedene und beide sprachen ESMTP und konnten STARTLS … also lag der Fehler doch wohl bei mir … (wo denn sonst :-/).

Trotzdem habe ich mir als erstes mal Logfiles von einem der Zielrechner besorgt und nach irgendwas brauchbarem gesucht. Aber außer einem

tcpserver: end 12128 status 256war nichts zu sehen.

Google hatte weder zum TLS-Fehler noch zum status 256 eine tolle Lösung parat. Der Status kann allerdings von einer RBL (Realtime Blocking List) verursacht werden. Naja, man klammert sich an jeden Zweig und so habe ich mit meiner IP mal http://www.mob.net/~ted/tools/rbl.php3 besucht – einem RBL-Checker, der auf mehr als 120 Blocklists nachschaut, ob meine IP drauf ist.

Ergebnis: block.blars.org und bl.reynolds.net.au blocken mich. Bei blars war mir das schon immer klar – den benutzt ja auch keiner. bl.reynolds.net.au war allerdings etwas überaschend. Jedoch brachte ein Blick auf http://bl.reynolds.net.au/ auch gleich ein paar Erklärungen – die Blocken seit drei Tagen das ganze Internet!

Setzt der Empfänger meiner Mails etwa diese RBL ein? Hmmm … angeblich nicht. Muss ich wohl glauben und weiter nach einem Fehler bei mir suchen.

Ich habe es ja die ganze Zeit vor mir hergeschoben, aber eine möglich Lösung ist natürlich qmail ohne ssl-Support zu kompilieren. Nur zum Ausprobieren habe ich das also mal gemacht. Sämtliche manuellen Versuche via telnet ohne STARTTLS klappten nämlich ohne Probleme.

Und siehe da: ohne ssl konnte qmail auf einmal wieder mit allen fraglichen Hosts kommunizieren. Aber jetzt auf einmal meldete mein kmail, dass mein SMTP-Server kein TLS mehr kann … Argl! Klar! Und das meldet der Server u. U. nicht nur bei mir sondern auch bei vielen anderen meiner User … Also musste sofort wieder ein qmail mit ssl-Unterstützung her!

Doch weiterhin das Problem: qmail-TLS funktionierte nicht. Jetzt konnte ich es wenigstens relativ einfach testen, indem ich via kmail versuchte eine Mail abzugeben. An diesem Punkt war ich mir dann leider auch sicher, dass ich selbst die Ursache für das Problem bin.

Als nächstes waren dann sämtliche Serverzertifikate dran. Alle neu generiert und Rechte überprüft – keine Auffälligkeiten. Die Zertifikate wurden problemlos neu erstellt aber nichts verbesserte sich.

Plötzlich erinnerte ich mich an einen Fehler den ich vor einigen Stunden beim login via ssh behoben habe:

-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
Und ich erinnerte mich an meinen mutt, der auf einmal keine gpg-Verschlüsselten E-Mails mehr verschicken wollte, ohne dass ich dafür eine direkte Erklärung hatte (aber qmail war ja erstmal wichtiger und darum wollte ich mich später kümmern)

root@setoy # ls -la /dev/urandom
crw-rw---- 1 root root 1, 9 7. Mai 01:15 urandom
brachte die Lösung: qmail hat kein Recht auf urandom zuzugreifen, aber braucht diesen Device für TLS – klar. Aber wie kann sowas sein? Ich habe zwar ein udev-Update eingespielt, doch wer rechnet mit sowas?

log_2005-05-21_10-40: * Note: If you are upgrading from a version of udev prior to 046
log_2005-05-21_10-40: * and you rely on the output of udevinfo for anything, please
log_2005-05-21_10-40: * either run 'udevstart' now, or reboot, in order to get a
log_2005-05-21_10-40: * up-to-date udev database.
… das habe ich auch brav nach dem update gemacht. Worauf aber bei diesem ebuild nicht hingewiesen wird: Es wurden wesentliche Änderungen an den udev Konfigurationsdateien vorgenommen.

Diese Änderungen holt man sich wie üblich per etc-update ins System, aber wenn man das udevstart DAVOR macht bzw. vor dem etc-update einen reboot, dann arbeitet das neue udev mit der alten Konfiguration und hat jede Menge Probleme.

Auf das eigentliche Problem wurde auf bugs.gentoo.org schon vor etwa 10 Tagen hingewiesen, aber der Reporter wurde nur abgespeist mit „You have probably some non-standard setup or whatnot“. Tja, da wird dann wohl noch der ein oder andere mit einer Standard-Konfiguration ebenfalls in diesen Bug laufen, der eigentlich keiner ist ….

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Christophs Weblog © 2009-2017