XFS lebt wieder

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.

XFS: Der erste Crash

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… 🙁

clamav gebändigt

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

scp – Dateien verschlüsselt kopieren

scp (secure copy) dient zum verschlüsselten Kopieren von Dateien und bedient sich eigentlich ganz einfach:

Ein oder mehrere Dateien auf einen anderen Server kopieren:

scp datei(en) user@host:/folder

Ein ganzes Verzeichnis rekursiv auf einen anderen Server kopieren:

scp -r order user@host:/folder

Ein oder mehrere Dateien von einem anderen Server kopieren:

scp user@host:/folder datei(en)

Ein ganzes Verzeichnis rekursiv von einem anderen Server kopieren:

scp -r user@host:/folder order

Das ganze setzt SSH-Zugang auf Quell-/Zielrechner vorraus.

Debian + pppd + IPv6

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 0x1b – 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. 🙂

Postfix Backup-MX

Bei einfachen Backup-MX Konfigurationen fällt auf, dass auf dem Backup-MX immer wieder Spam-Mails eingeliefert werden, obwohl der Primary-MX erreichbar ist. Ein möglicher Grund dafür könnte sein, dass gegenüber dem Primary-MX weniger Prüfungen über eingehende eMails laufen. Eine oft vernachlässigte Prüfung ist die der gültigen Empfänger-Adressen. Ein Backup-MX würde also einfach alle Empfänger-eMail-Adressen annehmen und versuchen diese dem Primary-MX zuzustellen. Dieser lehnt aber alle eMails an ungültige Empfänger ab. Also wird eine eMail an den Absender der Nachricht generiert. Bei Spam ist diese oft gefälscht, so dass der vermeintliche Absender eMail-Server unseren Bounce bounced. Dieser landet dann in der Regel beim Postmaster, was ein ziemliches Ärgernis darstellt.
Bei Postfix gibt es die Konfigurationsoption relay_recipient_maps, die eine Datei mit den gültigen Empfänger-Adressen auf dem Primary-MX setzt. Adressen die hier nicht vermerkt sind, werden gleich auf dem Backup-MX abgelehnt. Man darf nur nicht vergessen die Datei nach jeder Änderung mit postmap ins hash Format umzuwandeln. Die Konfiguration anhand der verlinkten Dokus klappte bei mir problemlos.

Debian Etch + SysCP + SpamAssassin

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.

Freude und Leid: Linux auf Laptops

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.

Mal wieder die Debian Schlüssel (Update 1)

Wie schon Anfang 2006 hatte ich mal wieder ein Problem mit den Debian Schlüsseln:

mordor:/tmp# apt-get update
[…]
Paketlisten werden gelesen… Fertig
W: GPG error: http://ftp.de.debian.org unstable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY A70DAF536070D3A1
W: Sie möchten vielleicht »apt-get update« aufrufen, um diese Probleme zu lösen

Die Lösung von 2006 brachte allerdings gar nichts, da es keine aktualisierten Schlüssel für 2007 gibt. Im Endeffekt muß man den angemeckerten Schlüssel von Hand von einem Keyserver importieren und mit apt-key importieren:

mordor:/tmp# gpg –keyserver random.sks.keyserver.penguin.de –search-key A70DAF536070D3A1
gpg: searching for „A70DAF536070D3A1“ from hkp server random.sks.keyserver.penguin.de
(1) Debian Archive Automatic Signing Key (4.0/etch)
1024 bit DSA key 6070D3A1, created: 2006-11-20
Keys 1-1 of 1 for „A70DAF536070D3A1“. Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key 6070D3A1 from hkp server random.sks.keyserver.penguin.de
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 6070D3A1: public key „Debian Archive Automatic Signing Key (4.0/etch)
“ imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
mordor:/tmp# gpg –armor –export A70DAF536070D3A1 > missing.asc
mordor:/tmp# apt-key add missing.asc

Auf einem anderen Server hatte ich das Problem, das der Keyserver den Schlüssel nicht hatte. In dem Fall kann man den Key auch von mir runterladen.

Update: Alternative Lösungsansätze

Den nötigen Schlüssel kann man auch so beziehen:

gpg –keyserver wwwkeys.eu.pgp.net –recv-keys 6070D3A1

An anderer Stelle habe ich auch noch das folgende gefunden, was bei mir allerdings nicht wirklich geklappt hat, da die Warnung kam, das die Signatur des Pakets nicht überprüft werden konnte:

apt-get install debian-archive-keyring
apt-key update