Unison: Cronjobs einrichten

Automatisierung durch Cronjobs

Wer so diszipliniert ist regelmässig daran denkt seine syncs per Hand anzustossen der muss gar nicht weiterlesen :-)- für den vergesslichen Rest - so wie mich - bieten Cronjobs eine elegante Möglichkeit, den Sync regelmässig durchzuführen. Auch ein Sync automatisch beim Systemstart ist denkbar, allerdings lässt mich eine Überlegung davor zurückschrecken: hat man auf System A eine Datei geschrottet, diese mit dem Server gesynct und kein Backup %), aber hat auf System B noch eine alte Version die man zurückspielen könnte, dann wäre ein automatischer Sync beim Systemstart B fatal (:eek:)! In so einem Fall kann man natürlich auch die Internetverbindung trennen um einen Sync per Cronjob zu verhindern XD

Voraussetzung dafür ist, dass das Home des $user auf dem Server automatisch beim Systemstart gemountet wird. Hierfür habe ich diese zwei Skripte hinterlegt und ausführbar gemacht: $user ist durch den entsprechenden Nutzer zu ersetzen!

/etc/network/if-up.d/mountsshfs

#!/bin/sh

# Not for loopback!
[ "$IFACE" != "lo" ]  | exit 0

# umount them first
mounted=`grep 'sshfs#' /etc/mtab | awk '{ print $2 }'`
[ -n "$mounted" ] && umount -l $mounted

# now mount
for mountpoint in `grep 'comment=sshfs' /etc/fstab | awk '{ print $2 }'`; do
        mount $mountpoint &
done

/etc/network/if-down.d/umountsshfs

#!/bin/bash

# Not for loopback!
[ "$IFACE" != "lo" ]  | exit 0

# unmount encfs
# must be done as user $user!

sudo -H -u $user fusermount -uz /home/$user/domina_klar/

# umount all sshfs mounts

umount -l `grep 'sshfs#' /etc/mtab | awk '{ print $2 }'`

Durch die beiden Skripte wird das sshfs-Verzeichnis beim Systemstart gemountet und beim Shutdown ungemountet, wobei ein ev. gemountetes Klartextverzeichnis erst mit den Rechten des Users ungemountet wird.

Einen Haken hat die Sache: diese Skripte laufen unter System-Rechten, deswegen muss ein ssh-keypair für root erstellt werden (ssh-keygen) und der Public-Key zum Server kopiert werden: `ssh-copy-id -i /root/.ssh/id_rsa.pub $user@www.zerties.org'

Kontrolle, ob das Ganze funktioniert hat: Als root(!) auf der lokalen Maschine den $user auf dem Server anmelden: `sudo ssh $user@server' Es darf keine Passwortabfrage erscheinen! Achtung! NICHT versuchen als root auf dem Server einzuloggen, das $user muss rein! Sonst wird die eigene IP nach ein paar Fehlversuchen geblacklisted und man kann sich nicht mehr verbinden und ist auf das Wohlwollen eines Admins angewiesen!

Um das Ganze zu testen das System am besten neu starten, es muss dann das home-Verzeichnis des $user auf dem Server unter /mnt/server gemountet sein, Ausgabe von `mount' etwa so:

sshfs#$user@server:/home/$user on /mnt/server type fuse (rw,noexec,nosuid,nodev,max_read=65536,¬
allow_other)

---

Die eigentlichen Cronjobs

Die Funktion von Cronjobs setze ich als bekannt voraus, daher hier die entscheidende Zeile in meiner crontab: (¬ = Zeilenumbruch)

1) Das Synchronisieren mit dem Server

5,35 * * * *    test -e /var/lock/domina && exit 0 || (touch /var/lock/domina;¬
(unison -batch domina ||  unison-gtk domina);rm /var/lock/domina) 

Schaut wild aus, erspart aber ein eigenes Skirpt ;):

• test -e /var/lock/domina && exit 0 : ist /var/lock/domina vorhanden, dann passiert nichts, denn dann läuft ein anderer Sync-Prozess noch - dies kann passieren, wenn man bei kleinem Upstream große Dateien hochlädt!
• touch /var/lock/domina : wenn nicht, dann erzeuge das lock-File
• unison -batch domina : synchronisiert im Batch-Mode, d.h. es werden keine Rückfragen zugelassen- das würde bei einem Cronjob mangels Konsole gar nicht gehen!
• || unison-gtk domina : Falls das schiefgeht (exitcode != 0) dann ist irgendetwas beim Snycen passiert, was eine Reaktion des Anwenders erfordert- also starten wir die GUI-Version nochmal ohne batchmode um zu sehen, was da nicht passt und dann zu entscheiden
• ;rm /var/lock/domina : Am Ende wird das lock-file wieder gelöscht

2) Mount des Klartext-Verzeichnisses sicherstellen

 */5 * * * *       test -e ~/.home_klar_check && (mount | grep home_klar > /dev/null || ¬
(zenity --question --text='vorlon unounted!- remount?' && (ssh-askpass | encfs -S ¬
~/.home_crypt/ ~/home_klar/ && touch ~/.home_klar.lock)))

Ängstlich wie ich bin überprüfe ich alle 5 Minuten, ob das home_klar auch wirklich gemountet ist:

• wenn .home_klar_check da ist, greppe aus der mount-liste ob es auch wirklich noch gemountet ist
• falls nein, mounte das das encfs wieder mit Passwort-Eingabe und erzeuge das File ~/.home_klar.lock (-> das brauchen wir dann später für UnisshencFirefox XD

---

Damit kommen wir zu einer häufig gestellten Frage: was ist, wenn beide Dateien zu unterschiedlichen Zeiten verändert wurden? Dann haben wir einen klassischen Versions-Konflikt und der User muss selbstständig entscheiden, was zu tun ist: Unison: Konflikt