Bernds Blog

Ich hatte vor einiger Zeit den Tipp erhalten, dass man mit »Disconnected IMAP« (oder auch »Cached-IMAP« genannt) bei KMail das Verhalten hin bekommt, das ich so lange gesucht habe: IMAP aber ein Cache, der mir erlaubt, zumindest die neuesten X Mails jederzeit schnell und ohne Netzverbindung verfügbar zu haben.

Gehört, getan, habe ich mein IMAP-Konto erstmal mit einem Rotations-script ausgestattet (alle Mails älter als 1 Monat wandert in eine andere Mailbox) und das was noch da geblieben ist dann per »Disconnected IMAP« eingerichtet. Erst einmal klang das alles recht gut, die Mailbox war extrem schnell da, man kann ständig jede Mailbox öffnen, auch wenn grade eine andere abgeholt wird.

Die erste Ernüchterung kam sehr schnell: Das Abrufen der Mailbox dauerte etwa 20 Mal so lange wie vorher. Jeder Ordner für sich dauerte fast so lange wie sonst der komplette Baum. Das liegt daran, dass KMail nicht nur nach neuen Mails schaut sondern auch lokale Änderungen (gelesen, ...) hochladen muss.

Ich habe als automatisches, periodisches Abholen eingestellt, sodass ich immer alle Mails sehe. Da man auch während des Abholens andere Ordner schon lesen kann, ist das kein Problem.
Was aber etwas störend war: KMail bzw. der ganze Rechner geriet etwas in Stocken, wenn der IMAP-Abruf-Vorgang lief. Erst fiel das gar nicht sonderlich auf, dann aber immer öfter (man erkennt irgendwann den Zusammenhang ;) ). Als ich bemerkt habe, dass man während des Abrufens keine Mail mehr vernünftig verfassen kann (das Fenster war oft für ~10 Sekunden reaktionslos), habe ich den Entschluss gefasst, wieder zurück auf normales IMAP zu stellen.

Da meine Mailbox jetzt sowieso relativ klein ist, geht auch da das Abrufen sehr flott.

Fazit: Disconnected-IMAP ist eine schöne Idee, funktioniert auch prinzipiell ganz gut, muss aber noch deutlich besser auf Nebenläufigkeit optimiert werden.

Ich nehme an, jeder, der unter Gentoo mal eine Netzwerkkonfiguration eingerichtet hat, die über den Trivialfall hinaus geht, stolpert über das irgendwie krude aber leistungsfähige Konzept des Netzwerk-Init-Scripts.

Leider ist die Doku dazu etwas mangelhaft und beschränkt sich nur auf einzelne Spezialfälle anstatt systematisch alle Möglichkeiten zu dokumentieren.

Heute habe ich eine lange Zeit damit verbracht, einen IPv6-Tunnel zu SixXS einzurichten. Bisher hatte ich das über ein eigenes init-script gelöst, aber das ist ja auch nicht das gelbe vom Ei.

Nach etwas herumprobieren kam ich dann auf eine funktionierende Konfiguration, deren Nennung ich auf den erweiterten Eintrag lege, damit das Layout durch preformatted text nicht zu sehr zerlegt wird.

Neulich erst mit Kubuntu erstmal ausprobiert, hatte ich auch gleich versucht, das auf meinem Gentoo-Desktop-Rechner laufen zu lassen.

Leider ist mir dabei nach dem Starten von compiz immer das System eingefroren. Warum weiß ich noch immer nicht, aber ich habe heute aufgrund mehrerer Anregungen einfach mal beryl ausprobiert. Und damit geht's!

Und von Beryl bin ich auch ansonsten sehr angetan. Das gconf-Feature von compiz hatte ich noch nicht getestet (da ich nicht erst das ganze gconf-Zeug installieren will), daher kann ich nur mit der Basiskonfiguration von compiz vergleichen. Aber man kann bei Beryl das einstellen, was ich wollte: Wobbeln nur bei Fenstern, nicht bei Tooltips, Passwort-Dialogen und so weiter.

Jetzt habe ich mal beryl als default-Window-Manager eingetragen, mal sehen ob ich das dauerhaft so lasse. :)

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.

Seit einiger Zeit betreibe ich einen IPv6-Block auf unserem Server, zusammen mit ein paar Subnetzen zu meinen Rechnern zu Hause. Alle Verbindungen sind momentan leider per 6-in-4-Tunnel realisiert, da keiner meiner Verbidungs-Provider IPv6 anbietet.

Seit ein paar Tagen nun funktionierte meine Verbindung nur noch ein bisschen, genauer gesagt konnte ich keine Verbindungen von schokokeks.org zu einem per Tunnel angebundenen Rechner aufbauen. Die Verbindung mit dem Tunnel nach außen sowie die Kommunikation verschiedener Tunnel untereinander war unberührt, aber vom Server weg ging es nicht.

Die einzige mit bekannte Änderung des Setups war das upgrade von kernel 2.6.14-irgendwas auf 2.6.17.4-grsec.

Ich habe jetzt mit Bastians Hilfe das Setup so umgestellt, dass ich keine Adressen mehr für die Tunnel-devices benutze und die routing-Tabelle direkt in das device selbst hineinroutet. Wusste garnicht dass das möglich ist, aber es funktioniert und das genannte Problem ist behoben.

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

Um manche X-Programme auf meinem Rechner von auswärts starten zu können, habe ich mir neulich tightvnc installiert und das hat auch erstmal recht gut geklappt. Nun wollte ich aber auch gnucash damit betreiben, was ja leider noch immer auf GTK1 basiert.

Beim Starten erhielt ich folgende Fehlermeldung:

Gdk-WARNING **: Missing charsets in FontSet creation
Gdk-WARNING **: ISO8859-15
Gdk-WARNING **: ISO8859-15
Fatal Error: gnucash_style_set_register...(): Cannot load fallback font: -adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-*

Nach einiger Zeit Googlen und vielen Flüchen über Linux & Schriften und vor allem über GTK1 bin ich darauf gestoßen, dass der FontPath für den X-Server den vnc startet nicht aus der normalen configfile kommt sondern fest im Script vncserver eingetragen ist. Natürlich fehlt dort der Pfad für die normalen X-Schriften.

Man ersetze also in /usr/bin/vncserver

$fontPath = "/usr/share/fonts/misc/,/usr/share/fonts/Type1/";

durch

$fontPath = "/usr/share/fonts/misc/,/usr/share/fonts/75dpi,/usr/share/fonts/100dpi,/usr/share/fonts/Type1/";

et voila, auch gnucash tut wieder.

marvin / # genlop -t openoffice

 * app-office/openoffice



     Mon Apr 24 21:38:03 2006 >>> app-office/openoffice-2.0.2-r2

       merge time: 4 hours, 27 minutes and 6 seconds.

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.

Seit heute haben wir auf dem keks MySQL 5.0 im Einsatz. Zuerst sah alles gut aus, dann haben wir aber bemerkt, dass Umlaute manchmal (genauer: in manchen Webanwendungen) korrekt (als UTF-8), meistens aber falsch (latin1) codiert geliefert werden.

Nun, der Fehler hat uns nen halben Tag gekostet, aber das Problem ist geflickt (ich will es nicht »gelöst« nennen).

Und zwar war MySQL vorher (vor 5.0) einfach inkonsequent, es hat Daten angenommen und Daten ausgeliefert, allerdings nicht auf den charset geachtet. D.h. wenn man die Daten als latin1 eingespielt hatte und mit latin1 wieder ausgelesen hat, dann hat alles gepasst, wenn nicht, dann halt nicht. Offenbar kann das aktuelle MySQL nun mit verschiedenen charsets korrekt umgehen, allerdings erfordert es dafür zwingend die Angabe des Charset. Und zwar muss man nun nach dem Aufbau der Verbindung erstmal das folgende Kommando absetzen um UTF-8 zu bekommen:
SET NAMES utf8;

phpMyAdmin und MediaWiki scheinen das zu machen, fast alle andere Software nicht.
Als Workaround kann man das da in die [msqld]-Section der my.cnf setzen:
init-connect='SET NAMES utf8'