Ich habe mich in den letzten Tagen mit einer wilden Mischung beschäftigt. Angefangen hat alles mit dem Artikel 15 Easy Ways To Speed Up WordPress: Why Slow Page Load Equals Slow Blog Growth. Ich hatte nämlich das Problem, das mein Blog sehr langsam geladen hat.
Linux
DNSSEC für die root
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:
- heise online – DNSSEC in der DNS-Rootzone gestartet
- DNSSEC visualisiert (am Beispiel der Domain nic.cz) bei DNSViz oder bei den VeriSign Labs.
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-baseGefunden 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.
Alternativen Serverport mit sftp verwenden
Beim ssh Kommando gibt es den Parameter -p um einen alternativen Port für den SSH-Server anzugeben:
ssh -p=2222 example.com
Beim sftp-Kommando muss man etwas in der Manpage stöbern, um den passenden Parameter zu finden:
sftp -oPort=2222 example.com
Leider nicht sehr einprägsam. 🙁
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 + clamscan.sh
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 EtchFalls 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.