Was wird benötigt?

1. Linux Kernel >= 2.6
2. dvd+rw-tools
3. ein Backupordner mit Symlinks auf die Backupverzeichnisse
4. ein Cronjob auf eine ausführbares Shell-Script
5. ein Shell-Script für das Anstossen des Brennvorgangs

Zu 1.: Warum Linux Kernel >= 2.6

Unter der Kernel Version 2.6 wird ein IDE DVD Brenner als SCSI Gerät mit einer SCSI-Emulation angesprochen. Da dies etwas umständlicher ist und man schliesslich selbst das Derivat auf dem Heimserver bestimmen kann, empfehle ich ein Kernel >= 2.6 zu verwenden.

Zu 2.: dvd+rw-tools installieren

Mit

apt-get install -u dvd+rw-tools

installieren wir das benötigte Programm-Bundle um DVDs beschreiben zu können.

Zu 3.: Backupordner mit Symlinks auf die Backupverzeichnisse

Mit

mkdir ORDNERNAME

erstellen wir einen Ordner, welche die Symlinks auf die Backup-Verzeichnisse beinhalten wird.
Anschliessend erstellen wir mit

ln -s ZIEL LINKNAME

in diesem Ordner die Symlinks auf alle Verzeichnisse welche gesichert werden sollen. Warum Symlinks? Mit Symlinks ersparen wir uns die Daten – die bereits auf der Platte vorhanden sind – zu kopieren, des Weiteren sprechen wir wie durch Zauberhand immer die aktuellen Dateien an.

Zu 4.: Cronjob auf Shell-Script

Je nachdem wieviele Daten in einem gewissen Zeitraum zu erwarten sind, sollte der Cronjob im entsprechenden Intervall aufgerufen werden. Bsp. werden über 4,7 GB (normaler DVD-Rom, Vorsicht! Die Herstellerangaben für 1 GB entspricht 1000 MB und nicht 1024 MB, d.h. eine DVD-Rom kann also mit ca. 4,3 GB gefüllt werden) in einen Monat erwartet, sollte entweder der Cronjob in kürzeren Zeiträumen ausgeführt werden oder man gestaltet das Shell-Script so, dass die Datenmenge auf mehrere DVDs aufgeteilt wird oder man benutzt andere Medien (bsp. Dual-Layer-DVD mit ca. doppelter Kapazität im Vergleich zur einfachen DVD-Rom). In meinem Fall genügt ein monatliches brennen, also sehe der Cronjob folgendermaßen aus:

# m   h     dom    mon   dow   command
0     11      15    *     *     /usr/local/bin/dvdbackup.sh >> /var/log/burning-dvd-backup.log

Dieser Cronjob wird jeden 15ten im Monat um 11:00 Uhr ausgeführt und ruft das Script dvdbackup.sh auf. Mit >> /var/log/burning-dvd-backup.log leitet man die “grundlegende” Ausgabe des Scriptes in eine Log-Datei um. Warum ich hier von “grundlegende” Ausgabe spreche erläutere ich im nächsten Schritt.

Zu 5.: Shell-Script

Mit vi oder touch erstellen wir eine Textdatei namens “dvdbackup.sh”. Diese machen wir mit

chmod 755 dvdbackup.sh

ausführbar. Anschliessend kopieren wir folgendes Listing – mit entsprechenden Anpassungen – in die Textdatei:

#!/bin/bash
cat /dev/null > /var/log/burning-dvd-backup.log

echo "$(date '+%b %d %H:%M:%S') debian-mrs creating monthly backup dvd:"
echo "---------------------------------------------------------------------------------"

#image von symlink ordner erstellen
echo "creating iso backup image"
mkisofs -f -l -iso-level 4 -o /storage/tmpbackup.iso /storage/symbackupfolder/ >> /var/log/burning-dvd-backup.log 2>&1

isosize=`ls -al /storage/tmpbackup.iso | awk '{print $5}'`

if [ $isosize -lt 4697620480 ] ; then
        echo "burning iso backup image on dvd"
        growisofs -dvd-compat -Z /dev/hda=/storage/tmpbackup.iso >> /var/log/burning-dvd-backup.log 2>&1

        echo "eject dvd"
        eject
else
        echo "can't write iso backup image, because iso is to large"
fi

echo "remove iso backup image"
rm /storage/tmpbackup.iso

echo "---------------------------------------------------------------------------------"

Download dvdback.sh

dvdbackup.sh

Was macht das Script?
1. Mit cat /dev/null > /var/log/burning-dvd-backup.log leere ich die Log-Datei.

2. Die Ausgaben mit echo sind genau die Ausgaben die ich durch den Cronjob in die Log-Datei umleite.

3. Mit mkisofs -f -l -iso-level 4 -o /storage/tmpbackup.iso /storage/symbackupfolder/ >> /var/log/burning-dvd-backup.log 2>&1 erstellt man ein ISO-File namens tmpbackup.iso von dem erstellten Backup-Ordner, der wiederum durch die Symlinks die entsprechend zu sichernenden Ordner enthält. Die “spezielle” Ausgabe von mkisofs leite ich mit >> /var/log/burning-dvd-backup.log 2>&1 auch in die Log-Datei um. 2>&1 entspricht hierbei, dass alle Standardausgaben sowie Fehlermeldungen umge-”piped” werden.

4. Die erste if-Bedinung (if [ $isosize -lt 4697620480 ] ;) prüft die Größe des Images und vergleicht diese mit der maximalen Kapazität MEINER Rohlinge! Jeder DVD-Rohling ist unterschiedlich, mit atip kann man die freien Blöcke einer DVD ermitteln und mit 2048 Bytes (Blockgrösse) multiplizieren, nun hat man die maximale Kapazität der DVD in Bytes und ersetzt diese mit 4697620480.

5. Wenn das ISO-Image grösser als die maximale Kapazität meines Rohlings ist, wird der Brennvorgang abgebrochen, da ich nach oben noch ca. 500-800 MB Luft habe, ist das für mich die einfachste Lösung gewesen. Stattdessen kann man natürlich das ISO-Image mit split in mundgerechte Stücke zerteilen und hiervon wieder ISO-Images erstellen, die dann in einer Schleife nacheinander gebrannt werden (mit manuellen DVD Wechseln) oder man legt mehrere Backup-Verzeichnisse mit unterschiedlichen Symlinks an, um so bereits zu Beginn mehrere ISOs zu planen und anschliessend zu erstellen.

6. Passt das Image auf den Rohling, wird es nun mit growisofs -dvd-compat -Z /dev/hda=/storage/tmpbackup.iso >> /var/log/burning-dvd-backup.log 2>&1 gebrannt. Statt /dev/hda muss eventuell etwas anderes eingetragen werden, in meinem Fall ist das DVD Laufwerk über /dev/hda ansprechbar. Um den Gerätenamen herauszufinden, genügt ein Blick per vi in die /etc/fstab. Der zu indentifizierende Eintrag sollte so

<b>/dev/hda</b>        /media/cdrom0   udf,iso9660 user,noauto     0       0

oder ähnlich aussehen. cdrom0 oder ido9660 sind typischen Hinweise auf ein CD-Rom oder DVD-Laufwerk.

6. Abschliessend wird mit eject die DVD ausgeworfen und mit rm /storage/tmpbackup.iso das temporäre ISO-Image gelöscht.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Linux-Server mit Debian GNU/Linux. Das umfassende Handbuch und Praxisbuch für die Versionen Etch (Debian 4.0) und Sarge (Debian 3.1): Das umfassende Praxis-Handbuch von Eric Amberg
• Shell Skript Programmierung: Kommandos, Techniken, Konzepte. Die wichtigsten UNIX-Tools. Lösungen für den Systemadministrator von Patrick Ditchen
• Linux in a Nutshell von Ellen Siever, Stephen Figgins, Aaron Weber, und Lars Schulten

Diese Anleitung basiert auf einer Debian etch Distribution. Die Installation auf anderen Linux Derivaten sollte jedoch ähnlich vonstatten gehen. Für weiterführende Informationen lohnt sich ein Blick auf die offizielle DenyHosts Webseite zu werfen.

DenyHosts installieren

Mit dem Befehl apt-get

apt-get install denyhosts

wird zum einen DenyHosts installiert und sofern noch nicht vorhanden, Python mit installiert. Da DenyHosts eine Anwendung die in Python geschrieben ist, ist eine installierte Version von Python zwingend erforderlich.
Unter /usr/share/denyhosts ist das Installationsverzeichnis nach absetzen des Befehls zu finden.

DenyHosts konfigurieren

Unter /etc/ findet man nach der Installation die Konfigurationsdatei denyhosts.conf von DenyHosts. Hier werden alle wichtigen Einstellungen für die Verfahrensweise von DenyHosts justiert. Folgend die wichtigsten Einstellungen:

SECURE_LOG = /var/log/auth.log // anhand der Beschreibungen in der denyhosts.conf, muß hier die richtige Wahl der Log-Datei, abhängig von der eingesetzten Distribution, erfolgen. Mit # kann auskommentiert werden

DENY_THRESHOLD_INVALID = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche von nicht vorhandenen Benutzern

DENY_THRESHOLD_VALID = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche von vorhanden Benutzern

DENY_THRESHOLD_ROOT = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche durch root. VORSICHT! Standardwert ist auf 1 begrenzt, wenn man mit dem root Benutzer arbeitet sollte hier erhöht werden.

DENY_THRESHOLD_RESTRICTED = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche von eingeschränkten Benutzern

ADMIN_EMAIL = mail@el-mediaagentur.com // E-Mail Adresse um über neue geblockte Hosts und/oder verdächtige Einlogversuche informiert zu werden

Alle Weiteren Einstellungen können auf dem Ursprungswert gelassen werden, ansonsten ist ein Blick in die Erklärungstexte der Konfigurationsdatei oder des Handbuches gefragt.

DenyHosts Daemon starten

Mit einem beherzten Absetzen von

/etc/init.d/denyhosts start // normaler Start
/etc/init.d/denyhosts start .purge // erlaubt die Variable PURGE_DENY zu nutzen um geblockte Hosts nach der Zeitspanne wieder aus der hosts.deny zu entfernen

auf der Konsole wird DenyHosts gestartet.

Wenn Werte in der Konfigurationsdatei geändert wurden, werden diese erst nach einem Neustart

/etc/init.d/denyhosts restart

in Kraft treten.

Hinweis

Das sportliche Ziel eines Angreifers ist sicherlich Root-Rechte zu erlangen. Wenn man mit dem Benutzer Root per SSH arbeiten muß, empfiehlt es sich über die SSH Konfiguration das direkte Einloggen des Root-Benutzers zu unterbinden. Stattdessen sollte über einen anderen Account, mit minimalen Rechten eingeloggt und dann mit su zu dem Root-Benutzer gewechselt werden. So hat der Angreifer zwei Passwörter als Barriere.

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Linux Server-Sicherheit von Michael D. Bauer
• Linux Hacker’s Guide. Sicherheit für Linux- Server und -Netze
• Praxisbuch Sicherheit für Linux-Server und -Netze von Barbara Oberhaitzinger, Helmar Gerloni, Helmut Reiser und Jürgen Plate

Folgende Vorgehensweise beschreibt die Konfiguration von Spamassassin, um sa-learn per E-Mail (Spam oder Ham per Anhang) zu trainieren.

Voraussetzung

Voraussetzung ist eine intakte Installation von Spamassassin und procmail. Lassen Sie sich nicht abschrecken von der Länge des How-Tos, der Mehrwert zur Bekämpfung von Spam ist nicht zu vernachlässigen.

Schritt 1: Procmail durch procmailrc konfigurieren

Procmail ermöglicht vor Auslieferung von E-Mails diese vorzubearbeiten, bsp. als Spam zu markieren, ins Nirvana zu schicken (/dev/null) oder Tools wie sa-learn damit zu konfrontieren.
Die Datei die die nötigen Anweisungen enthält befindet sich unter /etc/procmailrc. Procmail ist sehr mächtig und ermöglicht allerhand Einsatzzwecke, es lohnt sich ein Blick auf http://www.procmail.org/ zu werfen.
An folgende Beispiel-Konfiguration verdeutliche ich die Vorgehensweise von procmail (s. Kommentare)

DROPPRIVS=yes
#Logfile für debugging
LOGFILE=/var/log/procmail
#Für debugging [ON|OFF]
VERBOSE=ON
#Welche Shell soll benutzt werden
#SHELL=/bin/sh

#Mails die kleiner als 256000 Bytes sind, sollen mit spamc -f geprüft werden
:0fw
* < 256000
| /usr/bin/spamc -f

#Wenn die Mail an spam@domain.de ausgeliefert werden soll, dann soll das Script sa-wrap.pl mit der Option - -spam ausgeführt werden. Die sa-wrap.pl ermöglicht das Anlernen von Spam (schlechte E-Mails) und Ham (gute E-Mails) als Attachment, in Schritt 3 wird dieses Script behandelt.
:0
* spam@domain.de
{
:0fw
| /usr/local/bin/sa-wrap.pl - -spam
:0
/dev/null
}

#Wenn die Mail an ham@domain.de ausgeliefert werden soll, dann soll das Script sa-wrap.pl mit der Option - -ham ausgeführt werden.
:0
* ham@domain.de
{
:0fw
| /usr/local/bin/sa-wrap.pl - -ham
:0
/dev/null
}

#Alle E-Mails, die das SPAM-Level von mehr als 7 (Sterne) erreicht haben und an domain1.de etc. ausgeliefert werden sollte, wird zu /dev/null weitergeleitet, also gelöscht. Augenmerk ist auf TO.*undisclosed-recipients zu richten, hier werden auch die Mails behandelt die keinen eindeutigen Empfänger führen, manche Spam-Mails wollten hiermit gewisse Mechanismen austricksen
:0 w
* ^TO.*@domain1.com|TO.*@domain2.com|TO.*@domain3.de|
TO.*@domain4.de|TO.*@domain5.com|TO.*@domain6.de|TO.*@domain7.de|
TO.*undisclosed-recipients
* ^X-Spam-Level:.*\*\*\*\*\*\*
/dev/null

#Ab hier kommt ein Work-Around, um ein Problem mit procmail in gewissen Konstellationen zu beheben

# Work around procmail bug: any output on stderr will cause the “F”
#in “From”
# to be dropped. This will re-add it.
:0 H
* ! ^From[ ]
* ^rom[ ]
{
LOG=”*** Dropped F off From_ header! Fixing up. “

:0 fhw
| sed -e ’s/^rom /From /’
}

Die Syntax von procmail ist gewöhnungsbedürftig, aber wenn man das Schema verstanden hat, kann man das Script prima anpassen. Es gibt einige Quellen, wenn man procmail intensiver verstehen möchte. Damit das Logging und das spätere Zwischenspeichern und Entpacken der angehangenen Spam und Ham E-Mails in Zusammenhang mit procmail funktioniert, müssen wir /var/log/procmail, /var/log/sa-lear.log und /var/spool/unpack erstellen und die nötigen Rechte und Gruppen setzen:

$ touch /var/log/procmail.log
$ chown root:mail /var/log/procmail.log
$ chmod 666 /var/log/procmail.log
$ touch /var/log/sa-learn.log
$ chown root:mail /var/log/sa-learn.log
$ chmod 666 /var/log/sa-learn.log
$ mkdir /var/spool/unpack
$ chown root:mail /var/spool/unpack
$ chmod 777 /var/spool/unpack

DOWNLOAD der Beispiel procmailrc

procmailrc

Schritt 2: Einrichten der beiden E-Mail Adressen

Die im Huckepack gesandten Spam oder Ham E-Mails werden an zwei Adressen gesandt. Hier in der Beispiel procmailrc sind es spam@domain.de und ham@domain.de. Diese beiden Adressen müssen existieren. Wie diese erzeugt werden ist egal.

Schritt 3: Einrichten der sa-wrap.pl

Die sa-wrap.pl ist das Script welche die weitere Verarbeitung der Anhänge übernimmt und sa-learn zuführt. Im Beispiel Script von procmail liegt das Script unter /usr/local/bin/sa-wrap.pl.

DOWNLOAD sa-wrap.pl

sa-wrap.pl

Wenn man das Script anschaut, gibt es nur ein paar Möglichkeiten Einstellungen vorzunehmen

#
# Thanks to: Chung-Kie Tung for the removal of the dir
# Adam Gent for bug report
#
# v1.2

use strict;
use MIME::Tools;
use MIME::Parser;

#Debugging aus- oder einschalten [0|1]
my $DEBUG = 0;
#Entpackverzeichnis
my $UNPACK_DIR = ‘/var/spool/unpack’;
#Pfad zu sa-learn
my $SA_LEARN = ‘/usr/bin/sa-learn’;
#kann vernachlässigt werden
my @DOMAINS = qw/gtmp.org winnink.org/;
.
.
.

Die Pfade sollten natürlich angepasst werden, sofern man andere gewählt hat. Um die Fehlersuche zu unterstützen ist das Debugging wertvoll. Die Logs werden pro versandte E-Mail erzeugt und stadardmäßig unter /tmp abgelegt (spam.log.16377 etc.). Des weiteren werden zusätzliche Informationen in der /var/log/procmail abgelegt.

HINWEIS

Es gibt eine neuere sa-wrap.pl namens sa-wrapper.pl auf die ich nicht weiter eingehe, da ich zufriedener mit der alten Version bin. Mit einer Suche in Google oder einer anderen Suchmaschine nach sa-wrapper.pl wird man fündig werden.

Schritt 4: Der Test

Nach einem Neustart des Spamassassin Daemons kann man einen Test durchführen. Man nehme eine leere E-Mail und setze Spam oder Ham E-Mails als Attachement ein (wieviele Anhänge ist egal, es wird iterativ abgearbeitet) und schickt diese entwerder an spam@domain.de oder ham@domain.de, wobei natürlich hier die erstellten E-Mail Adressen genutz werden sollen und keine fiktiver Domainname. Wie überprüft man nun den Erfolg?
Ganz einfach auf der Kommandozeile

$ sa-learn –dump magic

wobei magic eine Kurzübersicht bietet. Es sollte so etwas hierbei herauskommen

$ /tmp # sa-learn –dump magic
0.000 0 3 0 non-token data: bayes db version
0.000 0 13938 0 non-token data: nspam
0.000 0 12353 0 non-token data: nham
0.000 0 169414 0 non-token data: ntokens
0.000 0 1170422819 0 non-token data: oldest atime
0.000 0 1205088456 0 non-token data: newest atime
0.000 0 1205058100 0 non-token data: last journal sync atime
0.000 0 1205040158 0 non-token data: last expiry atime
0.000 0 0 0 non-token data: last expire atime delta
0.000 0 0 0 non-token data: last expire reduction count

Wenn das Lernen erfolgreich war wird der Count von nspam oder nham erhöht worden sein. Man kann natürlich auch mit Hilfe der Logs den entsprechenden Erfolg einsehen.

Voila!

HINWEIS

Nicht jeder Spam wird nach dem Anlernen erkannt werden, manchmal muss man ähnlichen Spam mehrmals senden. Auch das Versorgen mit guten E-Mails (Ham) darf nicht vernachlässigt werden, da hierüber Vergleiche gemacht werden.

Nachtrag: Bug in neueren Spamassassin Versionen

Vor kurzem stiess ich auf einen Bug in einer neuen Spamassassin Version. Die Logs führten folgendes auf

archive-iterator: invalid (undef) format in target list, 2
at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/
ArchiveIterator.pm line 727, line 1.

, wenn das Auftreten sollte muss die sa-learn unter /usr/bin/ angepasst werden. Die Hinweismeldung kommt durch ein nicht gesetztes Target auf. Was ist zu tun?

Lösung: /usr/bin/sa-learn anpassen

Index: sa-learn.raw
================================================================
— sa-learn.raw (revision 507745)
+++ sa-learn.raw (working copy)
@@ -402,7 +402,10 @@

# make sure the target list is in the normal AI format
if ($targets[$elem] !~ /^[^:]*:[a-z]+:/) {
- $targets[$elem] = target($targets[$elem]);
+ my $item = splice @targets, $elem, 1;
+ $elem–; # go back to this element again
+ target($item); # add back to the list
+ next;
}
}

- Zeile entfernen
+ Zeile einfügen

Die entpsrechende Zeilen könnt ihr an # make sure the target list is in the normal AI format erkennen.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• SpamAssassin von Alan Schwartz
• Mit Open Source-Tools Spam und Viren bekämpfen. Für Unix- und Linux-basierte Mailsysteme von Peter Eisentraut und Alexander Wirt
• Postfix Ge-Packt von Tobias Wassermann

HINWEIS:

Passwortlose Authentifizierung bürgt Gefahren, hier zwei Szenarien.
1. Ein Angreifer erlangt Zugang zum Zielhost und kann in einem fremden Account in die Datei ~/.ssh/authorized_keys schreiben.
2. Ein Angreifer hat Zugriff auf den Quellhost und dessen Dateien ~/.ssh/id_dsa oder ~/.ssh/id_rsa. Beide Dateien sind ausserdem nicht passwortgeschuetzt.

Wer die Gefahren ausschliessen kann, sollte weiterlesen.

Schritt 1: Schlüssel mit ssh-keygen generieren

Nach Ausführung von

$ ssh-keygen -t dsa

auf dem Quellhost (Ort und Passwort leer lassen und mit Return bestätigen), werden in $HOME/.ssh/ die Dateien ~/.ssh/id_dsa und ~/.ssh/id_dsa.pub erzeugt.

Schritt 2: Public Key auf Zielhost übertragen

Hier führen viele Wege zum Ziel. Der Inhalt der erzeugten Datei ~/.ssh/id_dsa.pub muß an die .ssh/authorized_keys des Zielhosts angehangen werden. Ob mit cat, ssh-copy-id oder anderen Übertragungsmöglichkeiten gearbeitet wird, ist grundsätzlich egal. Hier ein elegantes Beispiel:

$ cat ~/.ssh/id_dsa.pub | ssh user@remotehost ‘cat >> .ssh/authorized_keys’

Als remotehost ist eine IP oder Domain möglich.

HINWEIS:

Die Berechtigungen der authorized_keys müssen auf 0600 gesetzt werden. Sonst lässt der Rechner unter Umständen aus Sicherheitsgründen gar keine Verbindung per Schlüssel zu.

Schritt 3: Verbidungsversuch

Wenn ich alles hier korrekt geschildert habe und es so umgesetzt wurde, sollte folgender Verbindungsaufbau vom Client ohne Passwortabfrage funktionieren:

ssh user@remotehost

Wobei remotehost eine IP oder Domain sein kann.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Vorrausetzung für zur Nutzung von Rsync, ist natürlich eine funktionierende Installation des Tools auf beiden Servern (Sender, Empfänger). Ich werde nicht weiter auf die Installation eingehen, da diese sich recht einfach gestaltet, sofern man Paketmanger wie apt-get oder rpm bzw. yast oder ähnliches einsetzt.

HINWEIS

Rsync ist gnadenlos! Vor der Nutzung von Rsync und dessen Parameter, sollte man sich ausgiebig damit auseinader gesetzt haben und eventuell Testläufe mit unsensiblen Daten durchführen. Rsync ist zu mehr imstande als dem folgenden Einsatzbeispiel, es lohnt sich ein Blick in die man page.

Rsync Syntax

Per Konsole sieht das Syntax-Schema von Rsync folgendermaßen aus:

rsync [OPTIONEN] <Source> <Destination>

<Source> bestimmt das Quellverzeichnis. <Destination> gibt das Zielverzeichnis auf dem entfernten System an. Wird nur einer dieser beiden Parameter gesetzt, gilt das aktuelle Verzeichnis als Quell-Verzeichnis.

Beispiel

Folgendes Beispiel verdeutlicht das automatisierte Synchronisieren von einem Webserver (Debian) auf ein entferntes System (Debian) per SSH. Wichtig hierbei ist, dass der Benutzer der den Befehl anstösst und auch der Benutzer der die Aktionen auf dem entfernten System ausführt, genügend Rechte auf die zu übertragenden Ordner bzw. Dateien besitzt.

#min hour day month dow user command
#—————————————–
#
30 4 * * * rsync -e ssh -a - -delete - -exclude=ordner1/ - -exclude=datei1 - -exclude=ordner2/ - -exclude=cfg*.php /var/www/ root@domain.de:/var/www >> /var/log/rsync.log

Was geschieht im Detail? Jeden Morgen um 4:30Uhr wird der Rsync durch den Cronjob angestossen.
Der Parameter

-e ssh

gibt an das die Synchronisation per SSH gesichert erfolgen soll. Die Option

-a

fasst die Optionen (-oDrlptg) zusammen:

• -o behält Besitzrechte bei (nur root)
• -D behält Gerätedateien bei (nur root)
• -r kopiert Unterverzeichnisse
• -l kopiert symbolische Links
• -p behält Rechte bei
• -t behält Zeiten bei
• -g behält Gruppenrechte bei

Der Parameter -a ist unumgänglich, wenn man das entfernte System als Ersatzserver betreiben möchte, da so gewährleistet wird das die Daten und deren Struktur 1 zu 1 (Rechte, Besitzer, Symlinks etc.) übertragen wird. Vorraussetzung für den Einsatz des Ersatzservers ist natürlich, dass dessen Strukturen sehr ähnlich sind, besonders im Bezug auf Benutzer und deren Rechte.
Was macht - - delete? Genau das was vermutet wird, es löscht alle Dateien auf dem entfernten System, die durch die Übertragenden Dateien ersetzt werden sollen. Bsp. die Datei test.txt existiert auf beiden Systemen. Auf dem Quell-Server wurde diese Datei geändert. Nun würde beim nächsten Synchronisationsdurchlauf die Datei auf dem Ziel-Server durch die Option - - delete entfernt und dann durch die Übertragung neu geschrieben werden.
Mit dem Parameter - - exclude schliesst man Ordner, Unterordner und Dateien aus der Synchronisation aus. Gerade im Bezug auf das Betreiben eines redudanten Servers möchte man nicht nach jeder Synchronisation die typischen Konfigurations-Dateien überarbeiten und mit den Daten des Ziel-Servers anpassen, dies lässt sich bsp. mit - -exclude=cfg*.php einrichten, sofern die Konfigurationsdateien nach diesem Schema erstellt wurden.
Was genau würde in dem oben genannten Beispiel von wo nach wo synchronisiert? Der vollst. Inhalt von /var/www/ würde in den Zielordner root@domain.de:/var/www synchronisiert. Man beachte, dass das Zielverzeichnis keinen abschliessenden Schrägstrich führt. Ersatzweise kann man auch eine IP (root@xxx.xxx.xxx.xxx) oder auch eine dynamische Adresse für die entfernte Synchronisation angeben.

Voila!

Dem eifrigen Leser ist sicherlich aufgefallen, dass der geschilderte Vorgang so nicht funktionieren kann, denn der Cronjob würde zwar ausgeführt, aber dann zwecks Passwortabfrage (SSH-Login) in die Schranken gewiesen werden. Um den reibungslosen (passwortlosen) Verbidungsaufbau zu gewährleisten muss man einen öffentlichen Schlüssel bekanntmachen. Wie das funktioniert erfahren Sie in dem Beitrag SSH ohne Passwort Authentifizierung.

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Links zum Thema

• http://samba.anu.edu.au/rsync/ Rsync Webseite
• http://samba.anu.edu.au/ftp/rsync/rsync.html Rsync man page
• http://www.linux-user.de/ausgabe/2006/04/090-rsync/ Dateien abgleichen mit Rsync

REOBack ist frei erhältlich und unterliegt der GPL (General Public License).

DOWNLOAD der aktuellen Version unter:

http://sourceforge.net/projects/reoback/

Das Archiv mit

tar -xvvzf <Archivname>

im gewünschten Ort entpacken. REOBack wird durch zwei Dateien (files.conf und settings.conf) konfiguriert. Mit files.conf bestimmt man die zu sichernden Ordner und/oder Dateien. Die settings.conf bestimmt das Verhalten von REOBack.

settings.conf – Parameter

• host Hostname bzw. IP des Server der Reoback nutzt
• backupdays Anzahl der Tage, nach der Backups gelöscht werden (aus
  Sicherheitsgründen wird vom Programm immer die doppelte Anzahl der hier
  angegebenen Tage verwendet)
• files Pfad zu files.conf
• tmpdir Pfad zu Ordner für temporäre Dateien
• datadir Pfad zu REOBack Programmverzeichnis
• localbackup Pfad für den lokalen Speicherort der Backups
• keeplocalcopy lokale Kopie des Backups behalten oder löschen?
• remotebackup Soll das Backup remote übertragen werden?
• rbackuptype Wahl des Übertragungsprotokolls (FTP oder NFS)
• localmount Wird nur für NFS benötigt, kann unverändert bleiben
• remotehost Hostname bzw. IP des Server der das Backup per FTP empfangen soll
• remotepath Wo soll das Backup auf dem Ziel-Server abgelegt werden?
  (REOBack erstellt automatisch einen Ordner mit dem jeweiligen Datum darin)
• ftpuser FTP-Benutzer
• ftppasswd FTP – Passwort

files.conf – Parameter

Als erstes kommentieren wir alle Beispielzeilen mit # in der files.conf aus. Nun können wir am Ende der Konfigurationsdatei mit folgenden Parametern REOBack die Ordner bzw. Dateien mitteilen, die in Zukunft gesichert werden sollen:

• File Backup-Dateiname, aktuelles Datum wird automatisiert angefügt
• Skip alle Verzeichnisse die mit der Option Skip versehen sind werden bei der Sicherung nicht berücksichtigt.

Beispiel für files.conf

File: Test-Backup
/home/verzeichnis1
Skip: /home/verzeichnis1/backups
Skip: /home/verzeichnis1/reoback/data
/etc
/home/admin

Die zu sichernden Ordner jeweils in eine Zeile angeben.


Um die Sicherung mit REOback zu automatisieren, kann man einen Cronjob anlegen. Einfach das Shellscript run_reoback.sh im Cronjob aufrufen. Beispiel:

#min hour day month dow user command
#—————————————–
#
0 5 * * * PFAD_ZU_REOBACK/reoback-1.0/run_reoback.sh | mail -s “automatisches Backup” cron@domain.com

Hier wird jeden Tag um 5 Uhr morgens ein Backup angestossen. Mit ” | mail -s “automatisches Backup” cron@domain.com” wird die Ausgabe von REOBack direkt per E-Mail versandt. Sehr komfortabel um Fehler frühzeitig zu erkennen.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.