Debian

DNSSEC für die root

von

Seit gestern liefern die DNS root Nameserver nicht mehr den DURZ aus, sondern sind mit einer echten Signatur versehen. Der Übergang verlief in meinen Augen weitgehend unbemerkt. Probleme sind mir keine bekannt. Damit ist ein wichtiger Schritt getan um DNSSEC weiter zu etablieren. Jetzt heißt es auch erstmal die DNS Resolver neu zu konfigurieren, damit die Validierung von der root aus korrekt klappt. Hier noch ein paar interessante Seiten zu diesem Thema:

Bind9 Views

von

Eine Sache, die ich beim DNS-Server Bind9 bisher nicht kannte sind Views. Damit kann man abhängig von der anfragenden IP-Adresse bestimmte Einstellungen aktiv setzen und so z.B. Rekursion erlauben oder verbieten, oder abhängig von der IP andere Zonefiles ausliefern. Ein Anwendungsbeispiel wäre z.B. an die IP 127.0.0.1 (localhost) eine unsignierte Zone auszuliefern, die von einem signierenden Proxy wie OpenDNSSEC per AXFR abgeholt und signiert wird. Die signierte Version der Zone wird dann an alle öffentlichen IP-Adressen ausgeliefert.
Ein sehr guter Artikel mit Praxisbeispielen ist Views in BIND 9 – O’Reilly Media.

XFS lebt wieder

von

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

von

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

von

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

Debian + pppd + IPv6

von

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

Debian + jabber + SSL

von

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

Debian Etch + SysCP + clamscan.sh

von

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.

Debian Etch + SysCP + SpamAssassin

von

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.