Für inkrementelle Backups unter Debian Lenny kommt man an rdiff-backup wohl nicht vorbei. Es erstellt Rückwärts-Inkremente — der aktuelle (neuste) Backup-Stand liegt also jederzeit als einfache Datei vor. Vorherige Backup-Stände kann man aus dem aktuellen Stand und den Rückwärts-Deltas wiederherstellen. Das funktioniert entweder über die Kommandozeile oder mit einem Web-Interface wie z.B. rdiff-web.

Das Ganze funktioniert prinzipiell auch auf per SMB oder CIFS gemounteten Shares, zum Beispiel auf eine NAS-Box. rdiff-Backup kümmert sich sogar um das Quoten von Dateinamen, wenn das gemountete Filesystem im Gegensatz zum ext3-Filesystem des Lenny-Servers nicht case-sensitive ist. Allerdings funktioniert das erst so halbwegs reibungslos ab rdiff-backup 1.2.5 – für Etch ist also selber kompilieren angesagt.

In meinem Fall führte ein Backup auf die per SMBFS gemountete NAS aber zu einem komischen Quoting-Schema (“A-Z-”*/:<>?\\|;”). Das resultierte dann in langsamen Backups und rdiff-web wollte auch nicht mehr funktionieren.

Loopback Tricks

Diese Anleitung brachte mich dann auf eine Idee, mit der man die ganzen SMB-Eigenheiten umgehen kann: Man erstellt eine große Datei auf der NAS-Box, erstellt in dieser Datei ein ext3-Dateisystem und mountet es als Loopback-Device. Das Backup erfolgt dann direkt auf diesen ext3-mount. So geht’s:

dd if=/dev/zero of=/mnt/nas/backup.ext3 bs=1M count=100
mkfs.ext3 /mnt/nas/backup.ext3
mount /mnt/nas/backup.ext3 -t ext3 -o,sync,loop,rw,noatime /mnt/backup

Unter /mnt/nas ist die NAS-Box gemountet. Darauf erstellen wir die Datei backup.ext3 (100MB in diesem Beispiel). Das ext3-Dateisystem in dieser Datei mounten wir nach /mnt/backup.

Der Performance hilft das jetzt nicht unbedingt…

Wir messen nach:

Davor:

--------------[ Session statistics ]--------------
 StartTime 1232652246.00 (Thu Jan 22 20:24:06 2009)
 EndTime 1232652365.80 (Thu Jan 22 20:26:05 2009)
 ElapsedTime 119.80 (1 minute 59.80 seconds)
 SourceFiles 4670
 SourceFileSize 16749169 (16.0 MB)
 ...
--------------------------------------------------

Danach:

--------------[ Session statistics ]--------------
 StartTime 1232652246.00 (Thu Jan 22 20:24:06 2009)
 EndTime 1232652365.80 (Thu Jan 22 20:26:05 2009)
 ElapsedTime 48.20 (48.20 seconds)
 SourceFiles 4670
 SourceFileSize 16749169 (16.0 MB)
 ...
 --------------------------------------------------

Das war ein initiales Backup einer Dokuwiki-Installation. Ohne Quoting ist das ganze mehr als doppelt so schnell. Kann natürlich je nach Größe des Backup-Verzeichnisses, inkrementellen Backups oder Restores abweichen :)

Unterm Strich ———

Unterm Strich ist das Loopback-Device für mich die eindeutig bessere Lösung: Das Backup-Repo bleibt schön sauber, da nichts gequotet werden muss und alle SMB-Bugs in rdiff-backup sind ein für alle Mal Geschichte. Hardlink-Support gibts obendrein dazu. Leider kann man den letzten Backup-Stand nicht mehr direkt auf der NAS (von einem Windows-Rechner per Freigabe) einsehen. Hierzu muss man das gemountete ext3-Filesystem erneut mit Samba sharen. Außerdem muss man den Backup-Platz vorher belegen und die Performance ist wohl alles andere als optimal – aber irgendwas ist ja immer!

Mit nur einem Zeichen lassen sich CSS-Eigenschaften gezielt für den Internet Explorer 6 und 7 schreiben:

#meinElement {
    background: red;    /* alle Browser */
    *background: green; /* IE 7 und darunter */
    _background: blue;  /* nur IE6 */
}

So sieht das dann aus. Doch sind solche Anpassungen für bestimmte Browser in sparaten CSS-Dateien und per Conditional-Comment eingebunden weitaus besser aufgehoben. Aber zum schnellen Debuggen für zwischendurch kann man diese Hacks schonmal benutzen..

PHP ist schwach typisiert. Und das ist im Prinzip auch gut so! Dennoch passieren dadurch teilweise wirklich sonderbare Dinge:

"2d3" != "02d3"

Das ist einfach: Strings unterschiedlicher Länge können niemals gleich sein.

Aber:

"2e3" == "02e3"

Was läuft hier anders? Beim einfachen Vergleich (“==”) versucht PHP zuerst jeden String als Zahl zu interpretieren. Das gelingt im ersten Beispiel offensichtlich nicht, wohl aber im zweiten: “2e3″ wird als wissenschaftliche Notation (2 mal zehn hoch 3)  interpretiert und somit zur Zahl. Da bei Zahlen führende Nullen irrelevant sind, wird auch “02e3″ zur Zahl. Man könnte also genauso gut “2e3″ == 2000 schreiben.

Leider ist das mit den führenden Nullen nicht immer so:

"0012" != 0012

Hier kommt eine weitere Eigenschaft von PHP ins Spiel: Zahlen, die mit einer Null beginnen werden von PHP als Oktalzahl interpretiert. Nicht aber in Strings! Somit wird “0012″ zu 12(dec) und 0012 zu 12(oct).

Da die internen Konvertierungen und Interpretationen von PHP nicht immer offensichtlich sind, empfiehlt es sich, in gewissen Situationen den “===”-Operator (strikter Vergleich) zu verwenden. Dieser ergibt nur dann True, wenn auch die Variablentypen (int, string, ..) auf beiden Seiten übereinstimmen. Beim “===”-Operator findet niemals eine Konvertierung statt.

"2e3" !== "02e3"

Das macht Sinn. Aber auch hier gibt es Überraschungen:

2e3 !== 1000

Hmm..

echo gettype(2e3); // double

Aha!  Zahlen mit Exponentialdarstellung sind immer vom Typ double. Liegt wohl daran, dass man damit auch sehr kleine Zahlen darstellen kann ($angstrom = 1e-10;). Also gilt:

2e3 === 1000.0

Dieses Spiel ließe sich beliebig fortsetzen. Dennoch: die gezeigten Verhaltensweisen sind so gewollt und auch Dokumentiert. Diese Extremfälle zeigen lediglich, wie gefährlich (weil schwer nachvollziehbar/erkennbar) manchmal ein scheinbar einfacher Vergleich in PHP sein kann.

Heise hat es direkt an Neujahr berichtet: Spamassassin hat offenbar ein Jahr-2010-Bug. So werden alle Mails mit Datum 2010 mit dem FH_DATE_PAST_20XX-Flag versehen.

Spam-E-Mails haben oft ein Datum weit in der Zukunft, damit Sie im Mail-Client immer ganz oben erscheinen (clever!). Spamassassin versucht dem mit dieser Regel entgegen zu wirken. Leider wurde die Jahreszahl 2010 fest einprogrammiert (clever?), und nun offenbar von der Realität eingeholt :)

Da dieses Flag eine hohe Gewichtung hat, landen jetzt also auch normale E-Mails oft fälschlicherweise im Spam-Ordner (false positive). Das Problem betrifft nicht nur den Spamfilter von  GMX und 1&1 sondern im Prinzip jede Spamassassin-Installation.

Für Debian Lenny gab es für das Spamassassin-Paket noch am selben Tag einen bugfix (Spamassassin 3.2.5-2+lenny1.1~volatile1 aus dem Debian Volatile-Repo). Mittlerweile gibt es auch ein offizielles Regel-Update, was die Installation des Volatile-Bugfixes überflüssig macht. Ein einfaches sa-update reicht aus, um die Regeln auf den neusten Stand zu bekommen und den Jahr-2010-Bug zu eliminieren.

Wie finden wir nun heraus, ob der eigene Debian Lenny/Etch-Server von diesem Bug betroffen ist?

SA-Regeln liegen im Ordner /usr/share/spamassassin/, Regel-Updates im Ordner /var/lib/spamassassin/<sa-version>/updates_spamassassin_org

Die Dateien im Update-Ordner überschreiben die Standard-Regeln. Die betroffene Datei heißt 72_active.cf. Diese öffnen wir und suchen nach der FH_DATE_PAST_20XX-Regel:

sudo vi /var/lib/spamassassin/<sa-version>/updates_spamassassin_org/72_active.cf
  ##{ FH_DATE_PAST_20XX
  header   FH_DATE_PAST_20XX      Date =~ /20[1-9][0-9]/ [if-unset: 2006]
  describe FH_DATE_PAST_20XX      The date is grossly in the future.
  ##} FH_DATE_PAST_20XX

Wichtig ist der fett markierte Regex. Dieser trifft auch auch das Datum 2010 zu. Höchste Zeit für ein Update:

sudo sa-update

Wir öffnen die Datei erneut:

sudo vi /var/lib/spamassassin/<sa-version>/updates_spamassassin_org/72_active.cf
  ##{ FH_DATE_PAST_20XX
  header   FH_DATE_PAST_20XX      Date =~ /20[2-9][0-9]/ [if-unset: 2006]
  describe FH_DATE_PAST_20XX      The date is grossly in the future.
  ##} FH_DATE_PAST_20XX

Aus [1-9] wurde [2-9].  Spamassassin-Neustart:

sudo /etc/init.d/spamassassin restart

Problem gelöst! Zumindest bis zum Jahr 2020…

Dass damit das Problem nur aufgeschoben wird, ist aber bekannt. Die Regel soll längerfristig sowieso komplett abgeschafft werden.

Spamassassin aktualisiert sich übrigens unter Lenny i.d.R. automatisch via Cronjob (/etc/cron.daily/spamassassin). Hier muss man also nichts weiter tun. Ansonsten beseitigt ein manuelles sa-update diesen Bug ganz sicher, und bringt für mindestens 10 Jahre Ruhe :)