Nach meinem ersten XFS Crash habe ich alles erfolgreich reparieren können. xfs_check und xfs_repair leisteten gute Dienste. Ärgerlich war nur dass ich die Platte in einen anderen Rechner einbauen musste, um die Reparatur durchführen zu können. Gemountete Filesysteme lassen sich leider schwer reparieren. Ich hoffe jetzt nur dass es eine einmalige Sache war und weder RAM- noch Festplattenschaden für den Filesystemfehler verantwortlich waren.
Ich setze jetzt schon ziemlich lange XFS ein und hatte noch nie ein Problem damit. Bis heute.
kernel: xfs_force_shutdown(hda3,0x8) called from line 1031 of file fs/xfs/xfs_trans.c. Return address = 0xc021644d
kernel: Filesystem "hda3": Corruption of in-memory data detected. Shutting down filesystem: hda3
kernel: Please umount the filesystem, and rectify the problem(s)
Am Wochenende muss ich mal schauen wie/ob ich das reparieren kann… 
Der Virenscanner clamav beanspruchte auffallend viel Rechenzeit, vor allem beim Starten oder nach Updates. Das Problem liess sich relativ einfach beheben. In der /etc/apt/sources.list noch folgenden Eintrag hinzufügen:
deb http://volatile.debian.org/debian-volatile etch/volatile main
Danach clamav aus dieser Quelle aktualisieren:
apt-get update
apt-get install clamav-daemon clamav-freshclam clamav-base
Gefunden im Server Support Forum
Als mir mein DSL-Provider Anfang des Jahres mitteilte, dass er nun testweise IPv6 anbietet, war ich direkt begeistert und habe mir auch ein Netz zuteilen lassen. Bis dato hatte ich nur die Möglichkeit mir IPv6 über einen Tunnel routen zu lassen. Die ersten Tests verliefen allerdings negativ, es ging einfach kein IPv6-Traffic über das ppp0 Interface. Im 0×1b – Blog fand ich dann den entscheidenden Hinweis:
Dem pppd muss explizit die Option +ipv6 mitgegeben werden, damit er sich dazu bequemt, etwas in der Art zu tun.
Seitdem steht in meiner /etc/inittab der Eintrag V3:23:respawn:/usr/sbin/pppd +ipv6 nodetach call dsl-provider. Übrigens sorgt respawn dafür, das der pppd nach jedem Beenden (durch z.B. Zwangstrennung) oder Absturz wieder neu gestartet wird. 
Nach einem Server-Wechsel habe ich meinen Jabber-Server neu installiert. Dabei hatte ich Probleme das SSL wieder zum Laufen zu bekommen. Eigentlich dachte ich, dass es mit so einem Eintrag getan sei:
<ssl>
<key ip='[IP-Adresse]'>/etc/jabber/jabber.pem</key>
</ssl>
Da lag ich leider falsch, da ich noch diese Zeile in der jabber.xml einkommentieren musste:
<ssl port='5223'>[IP-Adresse]</ssl>
Jetzt tuts wieder brav mit SSL.
Heute habe ich eine Lösung für die clamscan.sh Problematik gefunden. Unter Debian Etch scheint das Device /proc/self/fd/0 nur für root zugänglich zu sein. Abhilfe schafft ein cat -, das auch von stdin einliest. clamscan.sh muss also wie folgt angepasst werden:
#start
#MSG=$(cat /proc/self/fd/0) # stdin -> $MSG
MSG=$(cat -) # So klappts unter Etch
Falls man sicher gehen will, dass clamscan.sh auch wirklich lief, kann man noch die folgende Header-Zeile einfügen lassen:
MSG=$(echo "$MSG" | reformail -i"X-Virus-Scanned: by clamscan.sh (Debian)")
Das ganze kann man vor oder nach dem X-Virus-Status: einbauen.
Die Geschichte nervt mich inzwischen echt. Von der Maildrop 2.0.x + courier-authlib Problematik blieb zuletzt noch das SpamAssassin Problem übrig. Es äußerte sich im mail.log wie folgt:
localhost spamd[19964]: config: not parsing, administrator setting:
bayes_path /path/to/bayes
localhost spamd[19964]: config: failed to parse line, skipping:
bayes_path /path/to/bayes
Es scheint wohl so zu sein, dass SpamAssassin in neueren Versionen das Setzen dieses Pfades nur noch über die Konfigurationsdateien erlaubt. Nebenbei sei bemerkt, das diese Konfiguration, die ich auf mehreren Servern eingerichtet hatte, inzwischen nirgendwo mehr funktioniert. Also bleibt aktuell nur noch der Ausweg eine SQL-Datenbank für die Bayes-Daten zu benutzen. Da sitze ich zur Zeit dran und dann muß ich mir auch nochmal die clamscan.sh Problematik anschauen.
Nach der gestrigen Installation von maildrop 2.0.2 hoffte ich noch, dass es keine Probleme gibt. Aber es kommt immer anders als man denkt. In der SysCP Maildrop INSTALL Dokumentation fehlt nämlich ein sehr wichtiger Hinweis. Via Google habe ich ihn in einem Mailinglisten-Archiv gefunden: Wenn man maildrop mit der courier-authlib benutzt, muss maildrop in der Postfix master.cf mit root-Rechten ausgeführt werden:
maildrop unix - n n - - pipe
flags=DRhu user=root argv=/usr/bin/maildrop -d ${recipient}
Mit user=vmail klappts bei Debian etch nicht mehr. Jetzt kann das Setup weiter gehen. Als nächstes gehts ans Spamassassin trainieren und konfigurieren. Der meldet sich nämlich noch nicht.
Update 01.05.07 Leider weigert sich das Postfix pipe Kommando Befehle mit root-Rechten auszuführen. Diese Weigerung führt dazu, das die Zustellung über den maildrop Transport nicht funktioniert. Ich teste gerade eine andere Möglichkeit wie man maildrop ohne Patch verwenden kann.
Bei meinen letzten SysCP Installationen ergab die Gleichung ein Problem, da maildrop ohne MySQL-Support daher kam. Es war dann immer nötig maildrop selber zu compilieren, bzw. ein “fremd-compiliertes” maildrop zu verwenden. Ich habe diese Woche einen Server neu aufgesetzt und stellte erfreut fest, das dieses Problem nicht mehr auftritt. Allerdings kommt das maildrop nicht mit MySQL-Support daher, sondern mit der “Courier Authentication Library”:
errol:/etc/courier# maildrop -v
maildrop 2.0.2 Copyright 1998-2005 Double Precision, Inc.
GDBM extensions enabled.
Courier Authentication Library extension enabled.
Maildir quota extension enabled.
This program is distributed under the terms of the GNU General Public
License. See COPYING for additional information.
Bleibt zu hoffen das es hiermit keine Probleme gibt, auf den ersten Blick schaut auf jeden Fall alles gut aus.
Ja, auf dem BenQ Joybook R53 läuft Debian GNU/Linux. Und nein, man konnte das System nicht sinnvoll updaten. Heute stand aber eine Generalüberholung des Linux auf dem Laptop meiner Freundin an. Ich habe den Hinweis erhalten, dass mit Kernel 2.6.18 vieles besser wird. Leider arbeitete der selbst kompilierte Kernel nicht so wie gewünscht und beim Versuch den X-Server nach einem dist-upgrade wieder zum Laufen zu bringen, fror der Laptop beim Versuch X zu starten ein. Und das immer wieder, ohne Möglichkeit da von extern was dran zu ändern. Da das Debian wohl im Eimer war, stand eine Neuinstallation an.
Die Wahl fiel auf openSUSE 10.2, dessen Installations-DVD für einen geplanten Test von Xen bereit lag. Und siehe da, es tut. Es waren nur ein paar Kernel-Optionen nötig.