Netz - Rettung - Recht (Artikel mit Tag linux)

Linuxcounter-Projekt beendet

nospam@example.com (Thomas Hochstein) — Fri, 14 Dec 2018 07:02:00 +0000

Viele Jahre habe ich alle meine Rechner Daten zum Linuxcounter-Projekt beitragen lassen und regelmäßig den aktuellen Stand der Systemdaten - Speichernutzung, Load etc. - übertragen.

Dieser Tage aber mailte mir cron nicht das Ergebnis des API-Aufrufs, sondern eine Webseite - und siehe da, das Projekt ist (8 Jahre nach dem Relaunch und 26 Jahre nach dem Start) leider eingestellt worden.

Schade.

Das Linuxcounter-Projekt ist beendet.

isc-dhcpd, Windows-7-Clients und kein DHCP?

nospam@example.com (Thomas Hochstein) — Sat, 22 Jan 2011 07:42:00 +0000

Manche Dinge muß man nicht verstehen - und sie sind auch furchtbar schwer einzugrenzen.

Man stelle sich folgende Situation vor:

Ein Netzwerk, in dem ein Server (Debian Squeez) und ein Desktop (WinXP) stehen, außerdem ein WLAN-Accesspoint, über den zwei Laptops (einmal WinXP, einmal Win7) an das Netz angebunden sind. Auf dem Server läuft ein isc-dhcpd, also der DHCP-Server des ISC, der die Clients mit IP-Adressen versorgt. Beide Rechner, die unter Windows XP laufen, bekommen problemlos DHCP-Leases, und alles ist gut.

Jetzt kommt der Rechner unter Windows 7 hinzu - und nichts geht mehr. Nicht nur, daß der Rechner keine IP-Adresse zugewiesen bekommt; auch der andere, über WLAN angebundene Laptop verliert während dieser Versuche, per DHCP eine Adresse zu bekommen, reproduzierbar die Verbindung zum Server, so daß SSH-Verbindungen abbrechen und die DNS-Auflösung nicht mehr funktioniert. Andere bestehende Verbindungen von diesem XP-Laptop aus bleiben aber bestehen. Im Log des DHCP-Servers spielen der Win7-Client und der Server Pingpong mit DHCPDISCOVER und DHCPOFFER, kommen aber nie weiter zu DHCPREQUEST und DHCPACK, d.h. der Client fragt nach einer IP-Adresse, er bekommt eine angeboten, registriert das aber nicht und wiederholt seine Anfrage ad nauseam.

Nach langem Lesen und Probieren wird als Probe aufs Exempel ein weiterer Laptop mit Win7 ins Netz gebracht, um auszuschließen, daß das Problem beim Laptop liegt - und tatsächlich, auch dieser Rechner bekommt per DHCP keine IP-Adresse zugewiesen! Das Problem ist also offenbar ein generelles.

Googeln wird bei diesem Thema dadurch erschwert, daß es haufenweise Treffer gibt, die aber im wesentlichen alle mit diesem Problem nichts zu tun haben und oft nur die Unkenntnis der Beteiligten über DHCP, Windows und diverse andere Gegenstände erkennbar machen. *seufz*

Hätte jemand zu diesem Problem auf Anhieb einen Lösungsansatz gehabt? (Außer dem Mitschneiden des Netzwerkverkehrs zwischen dem Client und dem nicht-funktionsfähigen DHCP-Server im Vergleich zum Verkehr zwischen dem Client und einem funktionierenden Server.)

Die Lösung des Problems fand sich dann am Ende doch via Google (im Archiv einer Mailingliste der Greater New Hampshire Linux User Group) - und hat keine für mich erkennbare Verbindung zum Problem:

Es ist falsch, in der DHCP-Konfiguration das Statement server-identifier auf den Namen des DHCP-Servers zu setzen; dort muß offenbar entweder dessen IP-Adresse oder ein per DNS auflösbarer Hostname stehen (oder am besten gar nichts); den Namen des DHCP-Servers kann man stattdessen mittels server-name setzen. Wenn man diese Änderung in der Konfiguration des dhcpd vornimmt und ihn neu startet, ist urplötzlich alles gut …

Keywords: DHCP isc-dhcpd Windows Seven Vista Win7 fail no lease no IP address problem

DHCP-Server und automatische DNS-Zone-Updates

nospam@example.com (Thomas Hochstein) — Fri, 21 Jan 2011 18:46:00 +0000

Für lokale Netze ist ein DHCP-Server eine nützliche Einrichtung, ermöglicht er doch die automatische Adreßvergabe. Die meisten Consumer-DSL-Router (und nicht nur diese) haben entsprechende Funktionalitäten eingebaut; noch schöner und flexibler ist es aber natürlich, selbst einen entsprechenden Dienst bereitzustellen, weil man ihn dann genau so konfigurieren kann, wie man ihn gerne hätte, um neben der automatischen Vergabe von IP-Adressen auch bestimmten Rechnern feste Adressen zuzuweisen und zugleich im internen Netz eine Namensauflösung zu organisieren.

Dafür bedarf es im Prinzip dreierlei:

Zunächst benötigt man einen DHCP-Server (dhcpd), bspw. den des ISC, der dann so konfiguriert werden muß, daß er die erwünschten Adressen an die Clients zuweist.
Dann benötigt man einen DNS-Server, bspw. den BIND des ISC, der dann so konfiguriert werden muß, daß er Namen im lokalen Netz zu IPs auflöst und umgekehrt lokale IPs zu den richtigen Namen.
Und letztlich muß man in einem zweiten Schritt die beiden so miteinander verheiraten, daß der DHCP-Server dem DNS-Server erzählt, welche IPs er an welche Maschinen dynamisch vergeben hat.

All das ist vergleichsweise einfach unter Debian möglich.

Im folgenden Beispiel gehe ich davon aus, daß das lokale Netz den IP-Bereich von 10.0.0.1-10.0.0.254 (10.0.0.1/24) umfassen soll und die Domain example.org verwendet wird. Der Host, auf dem DHCP- und DNS-Server laufen, heißt server.example.org und hat die (fest konfigurierte) IP-Adresse 10.0.0.1.

1. Installation und Einrichtung des DNS-Servers

aptitude -r install bind9

Die DNS-Zonen für das lokale Netz sollen später dynamische Updates zulassen; aufgrund der dann notwendigen Schreibrechte für den Benutzer bind auf diese Dateien darf man sie unter Debian nicht in /etc/bind/ anlegen, sondern im dafür vorgesehenen Verzeichnis /var/lib/bind. Also legen wir eine Zone-Datei /var/lib/bind/example.org für die Vorwärtsauflösung an, in der auch schon die Maschinen stehen, die feste IP-Adressen vergeben bekommen sollen:

$ORIGIN .
$TTL 604800     ; 1 week
example.org            IN SOA  server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN example.org.
server                  A       10.0.0.1
desktop                 A       10.0.0.11
laptop1                 A       10.0.0.21
laptop2                 A       10.0.0.22

Und dasselbe dann für die Rückwärtsauflösung:

$ORIGIN .
$TTL 604800     ; 1 week
0.0.10.in-addr.arpa            IN SOA  server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN 0.0.10.in-addr.arpa.
1            PTR    server.example.org.
11            PTR    desktop.example.org.
21            PTR    laptop1.example.org.
22            PTR    laptop2.example.org.

Jetzt werden die Zonen in die Nameserver-Konfiguration eingebunden, und zwar durch Anpassen der Datei /etc/bind/named.conf.local:

zone "example.org" {
  type master;
  file "/var/lib/bind/zone.example.org";
};

zone "0.0.10.in-addr.arpa" {
  type master;
  file "/var/lib/bind/zone.10.0.0";
};

Nach einem Reload der Zonen (rndc reload) sollte die Auflösung vor- und rückwärts funktionieren, was man mit host laptop1.example.org und dann mit host 10.0.0.21 testen kann.

2. Installation und Einrichtung des DHCP-Servers

aptitude -r install isc-dhcp-server

Nun ist /etc/dhcp/dhcpd.conf (ggf. nach Sicherung der Originaldatei) anzupassen:

server-name Server;

option domain-name "example.org";
option subnet-mask 255.255.255.0;
option domain-name-servers 10.0.0.1; # der oder die DNS-Server

default-lease-time 86400; # 24 h
max-lease-time 172800;    # 48 h

authoritative;
ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.101 10.0.0.199;          # DHCP-Adressen werden zwischen .101 und .199 vergeben
  option broadcast-address 10.0.0.255;
  option routers 10.0.0.200;            # das Gateway ins Internet, bspw. der DSL-Router
}

Das genügt zunächst einmal; nach einem /etc/init.d/isc-dhcp-server restart sollte der DHCP-Dienst funktionieren und IP-Adressen zwischen 10.0.0.101 und 10.0.0.199 vergeben. Die vergebenen Adressen lassen sich unter /var/lib/dhcp/dhcpd.leases ersehen.

Im Logfile (standardmäßig /var/log/daemon.log) kann man die Vergabe der Leases verfolgen; dort ersieht man auch die MAC-Adressen der Hosts, die sich per DHCP Adressen holen. Mit Hilfe dieser MAC-Adressen kann man dann den Hosts, die feste Adressen per DHCP vergeben erhalten sollen (im Beispiel sind das desktop, laptop1 und laptop2), ebensolche zuweisen. Nehmen wir an, desktop hat die MAC-Adresse 00:30:05:5a:db:a0, dann müßte der entsprechende Eintrag in der /etc/dhcp/dhcpd.conf folgendermaßen lauten:

host desktop {
  hardware ethernet 00:30:05:5a:db:a0;
  fixed-address 10.0.0.11;
}

Nach einem erneuten Restart des DHCP-Servers wird desktop jetzt immer fest diese DHCP-Adresse zugewiesen bekommen.

3. Dynamische Aktualisierung der DNS-Zonen

Der letzte Schritt sorgt jetzt dafür, daß durch den DHCP-Server dynamisch vergebene Adressen (10.0.0.101-199) in den Zonen-Dateien des Nameservers mit dem entsprechenden Namen erfasst werden. Diese Updates kann man entweder durch jedes Programm, das auf dem Server läuft, erlauben, oder kryptographisch absichern. Ich stelle hier ersteres dar.

Die Konfiguration des DNS-Servers in /etc/bind/named.conf.local ist folgendermaßen zu ergänzen:

zone "example.org" {
  type master;
  file "/var/lib/bind/zone.example.org";
  allow-update { localhost; };
};

zone "0.0.10.in-addr.arpa" {
  type master;
  file "/var/lib/bind/zone.10.0.0";
  allow-update { localhost; };
};

Reloaden der Konfiguration nicht vergessen!

Die Konfiguration des DHCP-Servers in /etc/dhcp/dhcpd.conf ist folgendermaßen zu ergänzen:

[...]

ddns-update-style interim;
ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.101 10.0.0.199; # DHCP-Adressen werden zwischen .101 und .199 vergeben
  option broadcast-address 10.0.0.255;
  option routers 10.0.0.200; # das Gateway ins Internet, bspw. der DSL-Router
  ddns-domainname "gast.example.org"

  zone example.org. {
    primary 127.0.0.1;
  }

  zone 0.0.10.in-addr.arpa. {
    primary 127.0.0.1;
  }
}

Restart des DHCP-Servers nicht vergessen!

Nunmehr wird die Maschine, die sich - bspw. - als gastnetbook meldet und eine IP möchtet, bspw. die IP 10.0.0.105 zugewiesen bekommen; in die Nameserver-Zonen werden jetzt entsprechende Einträge für 10.0.0.105 und gastnetbook.gast.example.org vorgenommen. Das erfolgt zunächst in Dateien, die den Namen der jeweiligen Zone plus die Endung “.jnl” (für “Journal”) tragen; regelmäßig werden aber auch die Zonendateien aktualisiert.

Manuelle Änderungen der DNS-Zonen dürfen dann nicht mehr ohne weiteres vorgenommen werden! Zunächst müssen die dynamischen Updates unterbrochen werden, danach kann man Änderungen vornehmen und die dynamischen Updates wieder starten:

rndc freeze example.org
vim /var/lib/bind/zone.example.org
rndc thaw example.org

oder

rndc freeze 0.0.10.in-addr.arpa 
vim /var/lib/bind/zone.10.0.0
rndc thaw 0.0.10.in-addr.arpa

top ist gut, htop ist besser

nospam@example.com (Thomas Hochstein) — Fri, 21 Jan 2011 13:53:00 +0000

Bereits vor einiger Zeit hat mir das Bravszaf htop empfohlen, eine ~~graphische~~farbige Version des bekannten process viewers top, der die auf einem System laufenden Prozesse und weitere Informationen über die Ressourcenauslastung anzeigt. Inzwischen habe ich das auf mehreren Maschinen getestet und bin durchaus positiv beeindruckt.

Tip: Einfach mal ausprobieren.

Installation von Debian Squeeze

nospam@example.com (Thomas Hochstein) — Thu, 20 Jan 2011 21:47:00 +0000

Gestern schrieb ich schon, daß ich mal wieder wahrlich zu nichts komme (jedenfalls nicht zu den Sachen, die ich mir vorgenommen hatte) - daher mußte bislang auch die Einrichtung des neuen Rechners (die ich eigentlich in der ersten Woche des neuen Jahres abzuschließen hoffte) zurückstehen. Heute habe ich damit aber dann einmal - mit Unterstützung aus dem IRC - angefangen und ein Debian Squeeze (dessen Release ja unmittelbar bevorsteht) installiert. Da die Maschine per KVM-Switch an Monitor, Tastatur und Maus hängt, habe ich mich mittlerweile entschlossen, sie nicht nur als Server, sondern auch als Desktop zu nutzen, auch um einmal ein Gefühl dafür zu bekommen, wie sich ein Linux auf dem Desktop so anfühlt - denn obschon ich seit gut 10 Jahren mit Linux als Server-OS umgehen, arbeite ich auf dem Desktop immer noch unter Windows (zunehmend ergänzt um Tools aus der unixoiden Welt).

Aufgrund meiner bisher mangelnden Erfahrung mit der Installation eines Systems (ich kenne den Arbeitsgang in der Regel erst beginnend mit der Anpassung eines vom Provider aufgespielten Images und habe Erfahrung im wesentlichen mit dem Zugang via SSH, nicht mit der Arbeit an der Konsole …) und der Tatsache, daß Debian für das bevorstehende Release alle nicht-freie Firmware aus dem main-Archiv entfernt hat, befürchtete ich erhebliche Probleme, schließlich sind mir aus den vorgenannten Gründen im weitesten Sinne hardwarenahe Arbeiten (Treiber, Kernel, Partitionierung von Platten, Auswahl des Filesystems und Einrichtung von RAID, LVM und Co.) nicht wirklich vertraut. Der Ablauf erwies sich aber als angenehm einfach.

Nach dem Herunterladen eines Netinstall-Images aus den täglichen Snapshots und dessen Brennen auf CD wurde mir nach dem Boot angeboten, den graphischen oder den konsolenorientierten Installer zu starten, wobei ich mich für letzteres entschied; danach wurde ich durch die Ersteinrichtung geführt, bis … tatsächlich eine fehlende Firmware (rtl8168d-1.fw) gefunden wurde, sinnigerweise ausgerechnet für die (Realtek-)Netzwerkkarte (ohne die sich ein Netinstall dann vermutlich nicht so richtig erfolgreich gestalten dürfte). Glücklicherweise hatte ich mich bereits vorher informiert, wo Debian die nicht-freie Firmware jetzt versteckt hat, so daß ich den entsprechen Tarball herunterladen und via USB-Stick bereitstellen konnte. Das half aber nicht; weder der Tarball noch die ausgepackten Debs konnten den Installer glücklich machen. Weitere Suche mit dem Namen der vermißten Firmware führte dann zu einem Bugreport und dem entsprechenden Firmware-Paket mit Realtek-Firmware; ich habe dann entsprechend das dort verlinkte Tar-Archiv heruntergeladen, ausgepackt und - nach mehreren erfolglosen Versuchen - die Realtek-Firmware in das Root-Verzeichnis des USB-Sticks gepackt. Jetzt war der Installer glücklich.

Im weiteren Verlauf gelang es mir allerdings dennoch nicht, eine Netzwerkverbindung aufzubauen, was die weitere Installation etwas hinderte, insbesondere soweit Repositories eingebunden und Sicherheitsupdates geladen werden sollte; nach deren Abschluss und einem Reboot war jedoch eine Netzwerkverbindung vorhanden. Hilfreich für den absoluten Anfänger *hüstel* ist es übrigens in solchen Fällen zu wissen, daß man mit Alt-4 ein Terminal mit den Logs und Fehlermeldungen angezeigt bekommt, mit Alt-1 wieder zurückkomt und ggf. auf einem der anderen TTYs eine Shell starten kann. Dokumentiert ist das im Install-Manual.

[Update vom 23.01.2011: Offenbar handelt es sich bei dem Problem mit der Firmware für die Realtek-Netzwerkkarte noch um einen Bug, der mit dem ersten Point-Release behoben werden soll - sowohl hinsichtlich der Probleme des Installers, die Firmware auf dem USB-Stick zu finden, als auch hinsichtlich der fehlenden Netzwerkkonnektivität nach dem Finden der Firmware.]

Der Rest der Installation bis zum ersten Reboot verlief ereignislos, gut unterstützt und dokumentiert - es gelang mir auch auf Anhieb (naja, mit einigen Versuchen), aus meinen beiden Festplatten ein RAID 1 (mit gesonderter Bootpartition) zu erstellen, darüber LVM zu legen, die einzelnen Logical Volumes anzulegen und zu formatieren, ohne daß ich (abgesehen von Hinweisen zu der grundsätzlichen Auswahl des Filesystems und der Partitionierung) irgendeine Unterstützung via IRC gebraucht hätte.

Nach dem Reboot saß ich dann zum ersten Mal vor einer graphischen Konsole mit Gnome - und ich muß sagen, das gefällt mir bisher gut. Momentan muß ich mich dort noch zurechtfinden, aber immerhin kann die Maschine schonmal MP3s abspielen (nächster Eintrag auf der ToDo-Liste: Musikbibliothek mit korrekten MP3-Tags versehen … *seufz*).

Auch der Weg dorthin war allerdings nicht ganz ohne Probleme, denn ich mußte dem System noch beibringen, die On-Board-Soundkarte richtig anzusteuern. Insoweit hilfreich war nach längerem Googeln - wie gesagt, bei solchen Dingen war ich bislang völlig ahnungslos - ein Eintrag im Ubuntuusers-Wiki, dem ich die Lösung für mein Problem entnehmen konnte: die Datei /etc/modprobe.d/alsa-base.conf möchte um den Eintrag options snd-hda-intel model=auto ergänzt werden. Statt dem dort empfohlenen Reboot (das erschien mir so … Windows-artig) habe ich mich dann auf ein modprobe snd-hda-intel beschränkt - und auch das hat genügt.

Jetzt muß "nur noch" alles eingerichtet werden - insbesondere deshalb bestimmt ein großer Spaß, weil ich nach dem Einrichten des Basis-Systems den Fehler gemacht hatte, die zu installierenden weiteren Pakete mittels tasksel auszuwählen. Für den Desktop, von dem ich bekanntlich keine Ahnung habe, mag das noch eine gute Idee gewesen sein, aber der Rest - Mailserver, Webserver, Datenbankserver, … - entspricht nun wirklich gar nicht meinen (teilweise sicherlich speziellen) Vorstellungen. Also werde ich das in den nächsten Tagen einfach neu machen.

Insgesamt muß ich sagen, daß meine erste Debian-Installation (auf aktueller Hardware) mich sehr positiv überrascht hat.

Der einzige Punkt, bei dem ich mir mehr Dokumentation gewünscht hätte, war die richtige Vorgehensweise, um dem Installer die fehlende Firmware unterzuschieben. Schön zu wissen, daß man sich .debs herunterladen (die dem Installer aber AFAIS nicht helfen, also nur für Updates hilfreich sein dürften) oder die notwendige Firmware "bspw. via USB-Stick" bereitgestellt werden kann; noch schöner wäre aber zu erläutern, wo und wie man ggf. die einzelnen Firmware-Dateien findet und wo genau auf dem Stick sie dann bereitgestellt werden sollen. (Vielleicht habe ich die entsprechende Doku einfach nicht gefunden, das glaube ich in diesem Fall aber noch nicht einmal.) Der Kampf mit der Soundkarte dürfte hingegen für jemanden, der so ungefähr weiß, was er tut, nicht problematisch sein; die Anleitung im Ubuntuusers-Wiki ist auch völlig hinreichend. (Ob man sie aus der Installationsanleitung verlinken sollte, sei dahingestellt; ich habe, ehrlich gesagt, nicht einmal nachgeschaut, ob das nicht vielleicht sogar der Fall ist.)

[Update vom 23.01.2011: Vermutlich ist die Doku über das Bereitstellen zusätzlicher Firmware völlig korrekt und das Problem besteht im Installer bzw. dem konkreten Firmware-Paket. Siehe dazu auch die Errata-Seite des Debian-Installers.]

Backup mit duply und duplicity

nospam@example.com (Thomas Hochstein) — Thu, 13 Jan 2011 17:18:15 +0000

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

regelmäßig durchgeführt werden,
versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

Eine mögliche Umsetzung für einen Mietserver sieht - unter Debian Lenny - so aus:

duplicity und ncftp installieren: aptitude -r install duplicity ncftp

duply (in /usr/local/bin) installieren:

cd /tmp
wget -O duply_1.5.4.2.tgz http://sourceforge.net/projects/ftplicity/files/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.4.2.tgz/download
tar -xzf duply_1.5.4.2.tgz 
cp duply_1.5.4.2/duply /usr/local/bin/
rm duply_1.5.4.2.tgz 
rm -r duply_1.5.4.2

Alternativ (Debian Squeeze): aptitude -r install duply

Da der gesamte Server gesichert werden soll, läuft der Backupprozess am besten mit Root-Rechten. Wir brauchen jetzt also einen GPG-Key für root und richten dann das Backup ein:

cd /root
gpg --gen-key

Wenn nicht genug Entropie vorhanden ist, um den Key zu erzeugen, empfiehlt es sich, bspw. durch mehrere größere Downloads für Netzwerkverkehr und Belastung der Festplatten zu sorgen, um den Pool aufzufüllen. Key-ID und Paßwort des erzeugten Schlüssels benötigt man im nächsten Schritt zur Einrichtung des Backups; der Name des Backups kann frei gewählt werden:

duply *NAME* create
vim .duply/*NAME*/conf

In der Konfigurationsdatei sind nun zumindest einzutragen
- die ID des erzeugten GPG-Schlüssels (GPG_KEY),
- das Paßwort desselben (GPG_PW),
- das Backup-Ziel (FTP-Server und ggf. Verzeichnis, Benutzername, Kennwort: TARGET, TARGET_USER, TARGET_PASS) und
- den Pfad, der gesichert werden soll (im Zweifel "/": SOURCE).
Für die Einzelheiten und fortgeschrittene Konfigurationsmöglichkeiten sei auf die Kommentare innerhalb der Datei und die Dokumentation von duplicity und duply verwiesen.

Als nächstes erstellt man eine Liste der Dateien, die nicht gesichert werden sollen, die mindestens spezielle Verzeichnisse wie /dev und /proc enthalten sollte: vim .duply/NAME/exclude

/dev/\*
/proc/\*
/sys/\*
/tmp/\*
/var/tmp/\*
/var/run/\*

Danach kann man noch Scripts hinterlegen, die vor oder nach dem Backuplauf ausgeführt werden; bspw. kann es sich vor dem Backup empfehlen, Datenbanken zu dumpen. Diese Scripts heißen dementspechend pre und post, können zum Beispiel Shellscripts sein und müssen
- ausführbar sein (chmod 700 .duply/NAME/pre) und
- einen entsprechenden shebang (#!/bin/bash) enthalten.

Wenn das alles paßt, kann man nunmehr sein erstes Backup starten: duply *NAME* backup

Danach sollte man das komplette Verzeichnis .duply (das dann auch eine Kopie des GPG-Schlüssels enthält) sichern (nicht auf den Backupspace, sondern an einen sicheren Ort!).

Schließlich kann man noch in die Crontab von root einen entsprechenden Eintrag einfügen:

00 5 \* \* \* /usr/local/bin/duply *NAME* backup
00 6 1 \* \* /usr/local/bin/duply *NAME* full && /usr/local/bin/duply *NAME* purge --force

Fertig. Viel Erfolg!

In gleicher Weise ist es möglich, weitere Backups zu definieren, die bspw. nur /home oder /etc (oder /var/mail …) sichern, das dann aber häufiger.