www.h-ein.de

$HOME sweet $HOME

Mittwoch, 17. Oktober 2007, 04:02 Uhr
Kategorie: Blog » OpenBSD
Achtung, öffnet in einem neuen Fenster. Drucken

Da schreibt man sich ein kleines Backup-Script, das mit Hilfe von dump schöne (inkrementelle) Backups des eigenen OpenBSD-Servers auf externe Wechselplatten schreibt und diese Backups der Sicherheit wegen mit GnuPG verschlüsselt, da will man das ganze auch auomatisch laufen lassen. Aber wofür hat UNIX den cron daemon?

Nach vielen Tests des Scripts dann schnell eine Zeile

45 0 * * * /usr/local/bin/mybackup

in root's crontab eingetragen, und das Backup sollte laufen. Doch die Überraschung am nächsten Morgen beim Blick in die Logdatei war groß:

DUMP: broken pipe

Hmmm… was ist da schiefgelaufen? Wie eingangs schon erwähnt werden die von dump(8) erzeugten Daten durch GnuPG verschlüsselt. Das geschieht im Script mit folgender (beispielhaftem) Kommando-Kette:

dump -0auf - /home | \
gpg -e -r »Secure Backup« -o /backup/home_level0.dump.gpg

Wie schon erwähnt funktioniert das Script tadellos beim manuellen Aufruf. Was macht cron(8) beim Aufruf des Scrips so anders?

Nach vielen Versuchen, die Aufrufe des Scripts zu ändern und hinzugefügten und wieder gelöschten Debugging-Einträgen im Script selber, Umbiegen der Standard-Filediscriptoren und anderen mehr oder weniger verzweifelten Ansätzen zur Lösung stolperte ich über folgende Zeil ganz am Anfang von root's crontab(1):

HOME=/var/log

Und da ging mir dann ein Licht auf. GnuPG sucht standardmäßig nach den Schlüsselbunddateien im Verzeichnis ${HOME}/.gnupg/. Wird das Backup-Script nun von cron gestartet, wird die Umgebungsvariable HOME auf den Wert /var/log gesetzt – und dort gibt es keine passenden GnuPG-Schlüssel, was dazu führt, dass GnuPG nicht läuft und es kommt zur “broken pipe”. Workaround für dieses Problem: entweder, man setzt die Variable HOME im Script explizit auf den richtigen Wert (z.B. in diesem Fall HOME=/root) oder man nutzt den Paramater —homedir=/root für den Aufruf von GnuPG. Beides führt zum Erfolg und hinterlässt wieder eine Erfahrung mehr: nachdem man schon das ein oder andere mal über fehlende PATH-Variablen in cron-Scripts gestolpert ist, merkt man sich das nun auch für HOME. *g*

Mein Script läuft jetzt und sichert meine Daten — ich kann wieder ruhig schlafen.

»Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive.«

Banner