Bernds Blog

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.

Ich mag meine Distri manchmal. Manchmal auch weniger. Heute ist so ein Fall von »weniger«.

Seit ein paar Tagen steht das upgrade von openldap auf einem meiner Server an. Es ist zugegeben nur ein Lern- und Test-Setup, wird aber produktiv für den System-Login meiner Eltern benutzt. Das ebuild spuckt beim kompilieren aus, dass ich bitte vorher die Daten sichern und löschen soll.
Ok, ich halte mich ja gelegentlich an Anleitungen, daher habe ich das getan. Nachdem der Kompiliervorgang etwa eine halbe Stunde gedauert hat, hat die neue Version mysteriöse Dinge gemacht und ließ sich nicht starten. Ich weiß nicht was vorgefallen ist, aber nachdem ich selbst nach einer Stunde noch keinen Schritt weiter war, habe ich beschlossen die alte Version wieder zu installieren um endlich wieder einen System-Login zu ermöglichen. Nach Installation der alten Version lies sich der daemon wieder hübsch starten, aber es war keine Verbindung von nirgendwo her möglich. Auch hier wieder etwa eine Stunde debugging, dann habe ich aufgegeben und die Login-Daten in die /etc/passwd und co eingetragen.

Vielleicht wäre es mit dem Hinweis im heute veröffentlichten GWN einfacher gewesen. Ich weiß es nicht.
Zumindest stören mich zwei wesentliche Dinge:

1. Der GWN, der mir versucht, einige Hürden zu zeigen kommt hinterher, nachdem das Paket schon als stable markiert wurde!
2. Die offizielle Anleitung im ebuild (und die einzige Möglichkeit es auf normalem Weg installiert zu bekommen) erfordert eine downtime von über einer halben Stunde!

Ungeachtet dessen, dass ich die alte Version vorher hätte mit quickpkg in ein binpackage verwandeln können, es kann doch nicht sein, dass das Herunterfahren eines Services und Löschen seiner Datenbank über die Dauer des Kompiliervorgangs der richtige Weg ist! Durch die Fehlersuche und das nochmalige Kompilieren kam ich so auf eine stolze downtime von 2-3 Stunden.

Ich muss nicht erwähnen, dass zudem nach dem upgrade elementare Systemkomponenten nicht mehr funktiniert haben weil die LDAP-library nun anders hieß? Ein revdep-rebuild hat ebenfalls nochmal ne Stunde gedauert.

In diesem Punkt erlaubt sich Gentoo leider immer wieder böse Patzer, so dass ich kaum widersprechen kann, wenn jemand behauptet, Gentoo sei nichts für einen Server. Ich werd es weiter betreiben, aber ich bin auch immer wieder entrüstet über die Leichtigkeit mit der hier laufende Systeme getötet werden...

Seit einer herben Enttäuschung aus dem Vor-GAP-Zeitalter, das dazu geführt hat, dass man wegen des Defekts eines Mobilteils eine komplette Anlage mit 4 Mobilgeräten wegschmeißen konnte, steht auf allen meinen Mobilteilen »Siemens« drauf. Anfangs hatten sie einfach die einzigen brauchbaren Geräte im Angebot, später bekam ich immer wieder von herstellerübergreifenden Setups mit, dass irgend etwas nicht funktioniert hat.

Angefangen mit einem 3000er-ISDN-Kompett-Set mit Mobilteilen und Basisstation, wurden nach und nach alle 3000er Geräte durch 4000er ersetzt. Bei diesem Upgrade wurde die Basisstation um sinnvolle Dinge ergänzt, z.B. sieht man auf dem Mobilgerät, ob entgangene Anrufe da sind. Oder man kann die Uhr zentral stellen, Kleinigkeiten. Diese Features waren mit der zwischenzeitlich beschafften 4000er-ISDN-Basisstation möglich, mit der 3000er natürlich noch nicht. Ist verständlich.

Jetzt habe ich mir für Analog eine Basisstation gegönnt. Da ich mein altes Mobilteil gerne weiter mit benutzen möchte, hab ich mich wieder für Siemens entschieden, das S455 sah mir passend aus und hat gleich ein zeitgemäßes Mobilteil.

Die große Enttäuschung kam nun als ich das alte Mobilteil wirklich angemeldet habe. Sämtliche Komfortfunktionen, die das 4000er nur mit der neuen (4000er) Station konnte, sind weg. Es wird völlig auf das nötigste GAP-Kompatibilitätsprotokoll reduziert, noch nichtmal das Anzeigen der entgangenen Anrufe funktioniert. Ich bin ja schon froh, dass die Anzeige der Rufnummer beim Anruf überhaupt klappt.

Siemens, ich verkünde hiermit feierlich, dass ich mich richtig verarscht fühle und mich in Zukunft bei gleichen Rahmenbedingungen sicherlich für ein Konkurrenzprodukt entscheiden werde.

Fußnote: Hier noch meine erste richtig schmerzvolle Erfahrung mit Siemens-Schurlostelefonen...
Wir haben auf dem Hof momentan noch die 3000er Station mit den 4000er Mobilteilen im Einsatz und können dort auch gerne auf die Komfort-Features verzichten. Dort ist auch ein Gigaset-Repeater im Einsatz.

Was nicht auf der Packung steht, aber von der Hotline bereitwillig zugestanden wurde: Ein Repeater kann nur max. 2 Verbindungen abwickeln. Bei Anschluß der 4000er Basisstation benötigen aber die Mobilteile im Standby einen Message-Kanal zur Basis, über den sie z.B. über entgangene Nachrichten informiert werden.
Geht man jetzt mit 3 Mobilteilen in den Empfangsbereich des Repeaters, so ist eines unbrauchbar. Das äußert sich so, dass man erstmal keinen Unterschied sieht, aber wenn man abheben will oder ein Anruf kommt, bleit das Display unverändert, es ist weiter im Standby und lässt sich nicht mehr aufwecken. Auch wenn man wieder im Empfangsbereich der Station ist. Man muss es aus- und wieder einschalten. D.h. Repeaterbetrieb ist mit > 2 Mobilteilen bei einer neueren Basisstation unmöglich. Wird von der Hotline zugegeben, es gibt keine Alternativ- oder Konkurrenzprodukte zum Siemens-Repeater. Einzige Möglichkeit ist ein Netzwerk aus Basisstationen, die aber dann über eine Telefonanlage verkabelt werden müssen. Danke, Siemens, wenn wir ein Kabel legen könnten, bräuchten wir keinen Repeater.

Seit einigen Tagen kann mein Laptop (Gentoo stable mit einigen Ausnahmen) keinen Sound mehr abspielen. Jedes Programm stürzte umgehend mit einer Meldung wie dieser ab:
$ alsaplayer
alsaplayer: conf.c:3144: snd_config_iterator_first: Zusicherung »node->type == SND_CONFIG_TYPE_COMPOUND« nicht erfüllt.
alsaplayer interrupted by signal 6

Die Lösung ist rechts simpel: DMix ist beim aktuellen alsa (alsa-lib) fest eingebaut und muss nicht mehr in der ~/.asoundrc als modul eingebunden werden. Wenn man das aber (wie bisher) trotzdem macht, ergibt das obige Fehlermeldung.

Der Tipp mit dem downgrade der alsa-lib löst das Problem natürlich auch, aber ich finde die Änderung oder einfach Löschung der Konfigurationsdatei klingt irgendwie besser. :)

Ich hab's getestet, auch ohne DMix in der Konfiguration kann ich mehrere Sounds parallel abspielen. ;-)

Update: Dieser Eintrag leidet grade heftig unter Comment- und Trackback-Spam. Daher sind Trackbacks und Kommentare in diesem Beitrag jetzt deaktiviert.