Howtos

Kristian Köhntopp erklärt schön einfach für Einsteiger, wie Procmail funktioniert.

Allerdings wird Procmail zunehmend unbeliebt. Eine einfachere Syntax hat Couriers Maildropfilter.

Ein Filter, der Mails, die nicht eine bestimmte Empfängeradresse tragen, in einen speziellen Ordner sortiert und alle anderen dorthin kopiert, sieht dort z.B. so aus:

if ( /^To:.*@datenritter.*/ || /^To:.*datenritter@mailhost.zuhause.local.*/ )
{
cc $HOME/Maildir/.komisches
to $HOME/Maildir
}
else
{
to $HOME/Maildir/.komisches
}

(Die to-Zeile im ersten Block kann man auch weglassen.)

Die Distribution Ubuntu dürfte mit ihrem Sinn für Benutzerfreundlichkeit wesentlich dazu beigetragen haben, dass sich der NetworkManager (Homepage), ursprünglich ein Projekt von Red Hat, durchgesetzt hat. Er konfiguriert Netzwerkschnittstellen automatisch und macht damit Linux-Notebooks eigentlich erst richtig benutzbar.

Die Idee, dass ein User die Netzwerkschnittstellen konfigurieren könnte, war der Linux-Welt lange Zeit fremd. Doch das Überall-Netz setzt sich durch und WLANs machen schnelle Wechsel erforderlich.

Zum Daemon gibt es grafische Helferlein, wie den KNetworkManager für KDE, mit denen auch Unbedarfte "mal eben schnell" den WLAN-Zugang einrichten können. Mittlerweile beherrscht er sogar VPNs.



Man versuche zum Vergleich, OpenVPN unter Windows für User ohne Administratorrechte aufzusetzen. Ein schlechter Scherz.

Dennoch ist es gut zu wissen, wie man dem NetworkManager bei Bedarf Einhalt gebietet, zum Beispiel wenn man sein VPN unabhängig eingerichtet hat. Denn der NetworkManager startet den DHCP-Client, wenn kein Server da ist, und ein auf der Konsole manuell konfiguriertes Interface setzt er schnell mal zurück.

Beispiele in der Dokumentation des Debian-Pakets erklären, welche Interfaces von NetworkManager kontrolliert werden, und welche nicht:

1.)
auto wlan0
iface wlan0 inet dhcp
-> This device is managed by NM.

1.a)
allow-hotplug eth0
iface eth0 inet dhcp
-> This device is managed by NM

2.)
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
-> This devices is *not* managed by NM because it has additional options.

3.)
iface wlan0 inet dhcp
-> This device is *not* managed by NM because it is not set to "auto".

4.)
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
-> This device is *not* managed by NM because it is configured as "static" and
has additional options.

5.)
Device is not listed in /etc/network/interfaces.
-> Device is managed by NM.

Da ein beispielsweise von OpenVPN erzeugtes TAP- oder TUN-Device normalerweise nicht in /etc/network/interfaces eingetragen ist, greift die Regel aus Beispiel 5, und der NetworkManager nimmt dem TAP-Device schnell wieder die IP weg, nachdem OpenVPN sie und die zugehörigen Netzwerk-Routen gesetzt hat.

Eine gleichzeitige manuelle Konfiguration gelingt hingegen, weil sie erst nach dem Eingriff stattfindet, und daher eine gewisse Zeit bestehen bleibt. Das Logfile von OpenVPN behauptet, alles sei ok. Die Verwirrung ist perfekt, der Administrator beißt wutentbrannt in die Tastatur.

Wenn man weiß, wie es geht, ist es einfach: Ein Eintrag iface tap0 inet manual in /etc/network/interfaces behebt das Problem. (Der NetworkManager sollte neu gestartet werden.) Das TAP-Device bleibt wie in Beispiel 3 unangetastet, das VPN funktioniert.

Wegen eines Fehlers beim Umkopieren eines großen Datenbestands sind mir die Änderungszeitstempel (modification time, mtime) abhanden gekommen. Ein weiterer guter Grund, ein Backup zu haben!

Um die Zeitstempel wiederherzustellen, ohne die Dateien selbst zu überschreiben, habe ich aus dem Backup eine Liste erzeugt, in der Dateipfade und Zeiten getrennt durch " #+# " gespeichert werden. Das geht z.B. mit stat, und zwar so:

#!/bin/sh

ifs_backup="$IFS"
TARGETDIR=/actual/place

find . | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
MODTIME=`stat -c %y "${DIRFILE}"|sed -s "s/\..*//"`
DIRFILE2="${TARGETDIR}"`echo -n "${DIRFILE}"|sed -s "s/^.//"`
echo "${DIRFILE2} #+# ${MODTIME}">> dirfilelist.txt
done


Die Einträge in dirfilelist.txt sehen dann etwa so aus:

/home/adorno/test/script.sh #+# 2009-06-06 15:23:00


Das folgende Script liest diese gespeicherten Daten und ändert die Dateien auf dem Zielsystem:

#!/bin/sh

ifs_backup="$IFS"

while true; do
COUNT=0
cat dirfilelist.txt | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
DIRFILE2=`echo "${DIRFILE}"|sed -s "s/\ #+#\ .*//"`
NEWMODTIME=`echo "${DIRFILE}"|sed -s "s/.*\ #+#\ //"`
if [ -e "${DIRFILE2}" ]; then
MODTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
touch -cm -d "${NEWMODTIME}" "${DIRFILE2}"
NEWTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
echo "${DIRFILE2} has modification time ${MODTIME}, changed to ${NEWMODTIME}. Result: ${NEWTIME}" >> mtimeset.log
COUNT=$((COUNT + 1))
else
echo ${DIRFILE2}" does not exist!" >> mtimeset_error.log
fi
if [ ${COUNT} -gt 10000 ]; then
echo "Deleting 10000 lines from dirfilelist.txt."
sed '10001,$w dirfilelist2.txt' dirfilelist.txt >/dev/null
mv dirfilelist2.txt dirfilelist.txt
break;
fi
done
done


Die äußere Schleife bewirkt, dass die Liste gleich um die abgearbeiteten Einträge (evtl. abzüglich einer Zeile zu wenig) bereinigt wird, verhindert aber, dass das Script terminiert. Man kann es also auch mal abbrechen, muss dafür aber die Logfiles im Auge behalten.

Die Scripte sind nicht unbedingt elegant, und natürlich gibt es viel Raum für Verbesserungen. Vor allem an der Geschwindigkeit lässt sich sicher noch etwas machen, wenn man z.B. Aufrufe von stat einspart.

Wie dem auch sei: Have a backup!