Bernds Blog

Was soll denn sowas bitte?! (Thunderbird)

Die Tage kam bei schokokeks.org die Notwendigkeit nach einem zusätzlichen Server auf, der nichts anderes machen sollte als Backups von einigen bestehenden Maschinen entgegen zu nehmen. Der Server soll als virtuelles Gastsystem betrieben werden, da die erwartete Last minimal ausfällt. Da wir stets versuchen, IPv4-Adressen nicht zu vergeuden, wollte ich diesen Server als IPv6-only-System in Betrieb stellen.

Das hat grundsätzlich gut geklappt, es gab aber einige Stellen die (für mich unerwarteter Weise) Probleme bereitet haben.

1. OpenVPN kann nicht über IPv6. Mit der Version 2.3 soll das angeblich anders werden, die gibt es aber bisher noch nicht. Meine Lösung war, dass ich eine private IPv4-Adresse eingerichtet habe, die der physikalische Server auf einen anderen Server routet, der ebenfalls eine passende private IPv4-Adresse hat. Dadurch kann OpenVPN über diese IPv4-Verbindung kommunizieren.


2. Die normalen Gentoo-Mirror-Dienste beachten kein IPv6 und liefern im Round-Robin einfach irgendwas zurück, was ich dann nicht aufrufen kann. :( Die Lösung war, gezielt SYNC-Server und Distfiles-Mirror einzutragen die IPv6-Verbindung liefern. Die Listen gibt es hier (sync-Mirrors) und hier (Distfiles-Server). Jeweils die mit Sternchen sind IPv6-fähig.


3. Wir betreiben normalerweise lokale DNS-Resolver auf jedem Server. Für diesen speziellen Zweck ist das okay, aber man kann halt nur Namen auflösen, die auch über IPv6-fähige DNS-Server angeboten werden. IPv6-Paradebeispiel Heise online geht z.B. nicht, da deren DNS-Server keine IPv6-Adressen haben. Um etwas mehr Möglichkeiten zu haben, kann der Google-Public-DNS benutzt werden: 2001:4860:4860::8888.

Letztlich ist OpenVPN der einzige Grund, dass auf der Maschine überhaupt eine IPv4-Adresse eingerichtet ist. Und das soll sich ja angeblich mit dem nächsten Release, für das bereits ein RC angeboten wird, ändern. Ich bin jedenfalls gespannt.

Unsere normalen Serverdienste betreiben wir schon seit Jahren im Dualstack. Vor einigen Wochen wurde der Linux-Default-Resolver auch so geändert, dass er IPv6 bevorzugt, da hatten wir ein Localhost-Problem (Zugriffe auf localhost kamen dann von ::1 und nicht mehr von 127.0.0.1, da mussten einige Konfigurationen angepasst werden). Aber ansonsten bereitet uns der Dualstack-Betrieb keine Schwierigkeiten.

Gestern beobachtete ich ein ungewöhnliches Verhalten im courier-Mailserver, das ich gerne vom Autor bestätigt haben und ggf. als Bug reporten wollte.

Ich finde ja schon, dass es als Benutzer Freier Software auch dazu gehört, Bugs zu reporten und bestmöglich an deren Reproduzierbarkeit und Beseitigung mithelfen sollte. Aber manchmal geht mir echt der nicht vorhandene Hut hoch. So zum Beispiel gestern.

Courier hat keinen Bugtracker sondern nur eine Mailingliste. Ich schrieb also an die Mailingliste meine Beobachtung. Die Antwort ist, nunja, nicht wie erwartet ausgefallen.

Das Sourceforge-Archiv hat den Thread auseinander gepflückt, von daher hier die beiden Links zum Archiv:

Die ersten 3 Mails und die letzte Mail zu diesem Thema.

Mag mir vielleicht irgend jemand einen Tipp geben wie ich das so formuliert bekomme dass der Autor den Inhalt auch beachtet und nicht nur auf einer bedeutungslosen Nebensächlichkeit rumreitet?

Hier mal kurz eine Erfahrung von heute, auf dass dies vielleicht andere finden, die sich in der selben Situation wiederfinden.

Gestern Abend teilten mir meine Eltern mit, dass ihr Rechner keinen Login mehr macht. Egal welcher Benutzer sich anmeldet, es bleibt immer sofort nach Verschwinden der Login-Maske alles stehen.

Nach einigem Debugging habe ich erstmal aufgegeben (es war spät) und heute früh weiter gemacht. Im Netz habe ich auch nicht wirklich was gefunden was passend war.

Der Lösung näher kam ich als ich ein simples xterm (mittels xinit bzw. .xinitrc) gestartet habe und dort dann "strace kwin" aufgerufen habe. Damit zeigte sich, dass der Prozess beim Locking auf die ~/.qt/.qtrc.lock stehen blieb. Da das NFS-Homedir schon manchmal beim Locking Probleme hatte, habe ich also getippt, es kann daran liegen. Laut rpcinfo -p war aber der nfslockd aktiv.

Über einiges trial und error und den entscheidenden Fund im Netz, dass das Locking Probleme macht, wenn der Server die IP-Adresse des Clients nicht auflösen kann, bin ich dann darauf gestoßen, dass der bind auf dem Server aus mir unerklärlichen Gründen sich nicht für die lokale reverse-Zone zuständig gefühlt hat. Ein einfaches Restart des bind hat genau das behoben, ab dann waren auch lokale reverse-lookups wieder möglich.

Der NFS-Server hat die Situation aber nicht verkraftet, einen restart-Versuch hat er immer mit einem Segmentation fault verweigert. Als ich dann aber den Server-Rechner neu gestartet habe, hat wieder alles wunderbar funktioniert. ohne das ich irgend etwas ändern musste.

In den letzten Tagen gab es zwei interessante Vorkommnisse mit Mailinglisten unserer Fachschaft. Es sind jeweils Adressen auf der Mailingliste gelandet, die da nicht hin gehören.

1. Die -subscribe-Adresse befand sich plötzlich auf der Mailingliste

   
   Bei jeder Mail an die Mailingliste bekam der Absender eine »please confirm that you want to subscribe to ...«-Mail. Auslöser des Problems war eine Spam-Mail, die als Absender und als Empfänger die -subscribe-Adresse gesetzt hatte.



2. Ein unbedarfter Empfänger irgendwo in den USA war plötzlich auf unserer (deutschsprachigen) Mailingliste

   
   Auslöser war sein Autoresponder, der die Nachricht beantwortet hat. Der Request wurde von einer Spam-Mail provoziert und sein autoresponder hat ihn auf die Liste gesetzt.

Mir gefallen diese Vorkommnisse gar nicht. Eigentlich bin ich ein Freund von E-Mail-basierten Mailinglist-Managern (wie z.B. ezmlm oder der von uns benutzte couriermlm) da sie für den Benutzer einfach (ja, ich weiß, sichtweise) zu benutzen sind und vor allem kein Medienbruch stattfindet. Diese beiden Vorkommen sind aber der Beweis dafür, dass das mit dem double-opt-in so ganz trivial auch nicht über E-Mail machbar ist.

Ich seh schon den Kommentar im Voraus, dass couriermlm doch eigentlich bitte ein »YES« in der Betreffzeile haben möchte wenn man sich einträgt. Nur kann man diese Option auf einer überwiegend deutschsprachigen Mailingliste glatt mal vergessen. Schon alleine die Verwendung eines E-Mail-basierten Mailinglisten-Managers stellt einen gewissen Teil unserer Informatik-Studenten (!) vor ungeahnte Probleme. Das einfache Antworten auf die Mail konnten wir mit einer detaillierten, deutschsprachigen Anleitung hin bekommen, aber mit dem YES-eintragen, das hat nicht geklappt. ;-)
Aus diesen Gründen betreiben wir die Mailingliste mit ausgeschaltetem »YES«-Zwang, was uns jetzt vor das Problem stellt, dass Leute auf der Liste stehen, die das gar nicht wollen...

Ich habe die letzte Woche intensiv versucht, meine W-LAN-Verbindung so einzustellen, dass ich WDS-Modus (zwei Access-Points unterhalten sich) mit WPA-Verschlüsselung betreiben kann. Leider hat dies sowohl mit OpenWRT als auch mit DD-WRT nicht funktioniert. Da auf der Beschreibung der Router explizit sowohl WPA- als auch WDS-Support steht, hab ich heute dann die Original-Firmware installiert, in der Hoffnung, dass die das wenigstens hinbekommt.

Wenn ich das einstellen will:

WPA-PSK does not function under the WDS mode

Ja, danke. Dann ist mir auch klar, warum das unter OpenWRT bzw. DD-WRT nicht geht.

Frage an die Leser: Geht das mit anderen Geräten, die keinen Broadcom-Chip haben?

Letzte Woche ist mir im Server meiner Eltern (Fax- und Dateiserver sowie Router und noch ein bisschen Kleinkram) die Festplatte gestorben und hat alle Daten darauf in die ewigen Festplatten-Jagdgründe genommen (Ja, ein nicht topaktuelles Backup war vorhanden).

Da ich also dann sehr schnell ein neues System gebraucht. Vorher war Gentoo installiert, aber da habe ich mich schon seit geraumer Zeit daran gestört, denn die Upgrades waren immer so heikel, da ich keinen physikalischen Zugriff darauf habe. Also wurde als Feldversuch der Server mit der Serverversion von Ubuntu-Linux eingerichtet. Installation war Ubuntu-Typisch in wenigen Minuten vorbei.

Die kranke Installationsprozedur von DJBdns war mir bekannt und hat mich folglich auch nicht so sehr schockiert. :)

Größtes Problem war, dass beim Aufstellen am späteren Einsatzort das NFS sich ganz komisch verhalten hat. Mozilla-Firefox und -Thunderbird ließen sich nicht starten weil sie angeblich schon laufen (nein, an den Lock-Files lag es nicht), KMail brachte wahllos Zugriffsfehler beim IMAP-Cache und ein sofort eingerichtetes Backup per rsync auf einen anderen Rechner führte oft zu der Meldung »stale NFS handles« und danach gab es nurnoch »permission denied« in dem Verzeichnis. Ein heraus und wieder hineinwechseln behebt das Problem kurzfristig.

Nach etwa einem Tag erfolgloser Suche und vielen Fragen an viele andere ratlose Leute, bin ich zufällig an diesen Bugreport herangestolpert.

Der dort vorgeschlagene Workaround hat bei mir funktioniert: Die Option »no_subtree_check« in alle exports-Einträge aufnehmen.
Bisher traten bei mir keine derartigen Probleme mehr auf.

Ich programmiere zur Zeit (schon lange immer so nebenbei) an meinen Python-Bibliotheken zur Datenbank-Ansteuerung. Nichts allgemeines sondern sehr speziell auf die Zwecke des Keks zugeschnitten.

Die letzten Tage bin ich richtig schön weitergekommen, habe meine Bibliotheken ausgebaut, meine Objekte so weit es geht abstrahiert und auch Schreibzugriff auf die Datenbank damit ermöglicht. Eigentlich hat alles geklappt. Nun wollte ich das Frontend noch schnell darauf umstellen. Eigentlich kein Problem, denn ich muss ja nur die Attribute des Objekts füllen und commit() aufrufen.

Nur war dann beim Speichern der Daten immer nur die Hälfte in der DB. Beim debuggen war alles da, beim Testen aller Klassen war alles da. Nur nach dem Erzeugen der Objekte und vor dem DB-Zugriff muss irgenwas schiefeglaufen sein.

Des Übels Wurzel: Ich habe einen kleinen aber feinen Teil in Pythons Dokumentation übersehen: Klassenvariablen. Eine Klassenvariable (die man in der Klassen-Definition einträgt, anstatt sie mit self.var in einer Methode zu setzen) gilt für alle Objekte der Klasse und ihrer Subklassen gemeinsam. D.h. solange man mit einem Objekt arbeitet gibt es kein Problem. Erst wenn man mehrere Objekte der selben Klasse hat und an einer solchen Variable was ändert, dann passieren merkwürdige Dinge.

Auch wieder was gelernt. ;-)

Neulich hat Hanno bei uns das MediaWiki auf eine neue Version geupdatet. Es war von 1.4.15 auf 1.6.8. Daraufhin war die Datenbasis mysteriös kaputt. Genauer gesagt haben manche Seiten gefehlt, manche waren steinalt und manche noch aktuell.

Zur Sicherheit habe ich dann von neuem die Update-Prozedur nochmal mit einem alten Backup der Datenbank nachgestellt und kam zu exakt demselben Ergebnis.

Nach einiger Zeit an Recherche in den Untiefen der Datenbank von MediaWiki habe ich festegstellt, dass sich einiges am Datenbank-Schema geändert hat. Bisher waren die Tabellen 'old' und 'cur' für die Inhalte zuständig, dort wurden die alten resp. die aktuellste Version jeder Seite aufbewahrt.

Im neuen Schema gibt es jetzt (eigentlich logischer) die Tabellen 'page', 'revision' und 'text', die Informationen zu den Unterschiedlichen Seiten, deren Versionen und den entsprechenden Texten speichern. 'page' verlinkt dabei immer auf die aktuelle Revision einer Seite.

Das Debugging hat nun ergeben, dass der update-Wizzard von MediaWiki aus irgendwelchen unerfindlichen Gründen die Datenbank nicht korrekt konvertiert hat. Es wurden Seiten vergessen oder alte Versionen als aktuell markiert.

Als Lösung habe ich ein Programm geschrieben, das die alte 'cur'-Tabelle ausliest und im neuen Datenbank-Schema eine neue Version jeder Seite mit dem Inhalt aus der alten Tabelle erstellt.

Der Einfachkeit halber konvertiere ich nur Artikel im Namespace 0, also normale Artikel.

Ich habe einen LaserJet 5M, wie schon irgendwann mal hier erwähnt. Der gute ist per PostScript an mein Netzwerk angeschlossen und wird per CUPS benutzt.
Schon seit kurz nach dem Kauf habe ich das Problem, dass der Drucker manchmal und, wie ich fand, nicht reproduzierbar, den Job einfach abgebrochen hat ohne, dass im CUPS-Logfile oder am Druckerdisplay irgend ein Grund zu finden war. Ein kurzes "Processing Job" und dann der Rücksprung auf "Ready".

Wenn ich die Postscript- oder PDF-Datei dann auf den Server kopiert habe und dort ein "lpr" getätigt habe, hat es geklappt. Vielleicht war dies der Grund warum ich der Sache nicht so eifrig nachgegangen bin. Heute jedoch hat das Phänomen bei Nici auch Einzug gehalten als die Datei vom Server gedruckt werden sollte.

Einige Debug-Sessions später hatte ich (mit dem selben Postscript-Ausgangsmaterial) im Cups plötzlich einen Unterschied, der die Misere erklären konnte. Und zwar wurde bei Nici immer die PostScript-Option "Duplex=None" mitgegeben, bei mir nicht.
Die Frage war nun, warum ist das so und wer setzt diese Option. Per User!?

Antwort: ~/.lpoptions
Dort stand Duplex=None hinter dem Drucker-Eintrag. Hat KDE gesetzt.

Leider scheint der Drucker ohne Duplex-Einheit mit allem außer "Duplex=Notcapable" Probleme zu haben. Vielleicht verwirft er es, da die Duplex-Einheit diese Befehle auswerten müsste.

Jedenfalls lag es daran und ich hoffe, dass ich in diesem Eintrag genug Suchbegriffe eingestreut habe, sodass andere mit diesem Problem meine Lösung finden.