Archive for Mrz. 2009
Sobald man anfängt, mehrere Systeme per FAI zu installieren, macht es unter Umständen Sinn sich ein lokales Debian Repository anzulegen. Dieses kann dann alle zur Systeminstallation notwendigen Dateien beinhaltet .
apt-get install debmirror debian-keyring debian-archive-keyring# Verzeichniss erstellen groupadd mirror useradd -g mirror -d /mirror -c "Debian Mirror" mirror mkdir -p /mirror/debian chown mirror:mirror /mirror -R
# keys importieren # Nun müssen noch Schlüssel aus dem archiv Schlüsselbund importiert werden gpg --no-default-keyring -a --keyring /usr/share/keyrings/debian-archive-keyring.gpg \ --export F42584E6 | gpg --no-default-keyring --keyring ~/.gnupg/trustedkeys.gpg --import - gpg --no-default-keyring -a --keyring /usr/share/keyrings/debian-archive-keyring.gpg\ --export 6070D3A1| gpg --no-default-keyring --keyring ~/.gnupg/trustedkeys.gpg --import -
# main, contrib, non-free debmirror /mirror/debian --passive --progress --nosource \ --host=ftp.de.debian.org --root=/debian \ --dist=lenny \ -section=main,contrib,non-free --arch=i386 --cleanup \ --getcontents --pdiff=none # security updates debmirror /srv/mirror/debian-security --progress --host=security.debian.org\ --root=debian-security/ --dist=lenny/updates,etch/updates \ --section=main,contrib,non-free --meth=http --arch=i386 --passive
Damit nun das Repository auch von andere Clients verwendet werden kann, sollte der Zugriff per HTTP konfiguriert werden. Dazu kann
die /etc/apache2/httpd.conf wie folgt angepasst werden
<Directory /mirror> Options Indexes FollowSymLinks AllowOverride None Order allow,deny allow from all </Directory> Alias /debian /mirror/debian
Nun muss noch auf den entsprechenden Clients die /etc/apt/sources.list angepasst werden
deb file:/mirror/debian/ lenny main contrib non-free deb file:/mirror/debian-security/ lenny/updates main contrib
Um das Repository nun aktuell zu halten, hab ich ein ein bereits existierendes Script angepasst. Die Angepasste Version kann hier herunter geladen werden
und sollter ausführbar als /usr/local/bin/mirror gespeichert werden.
Damit das Repository nun automatisch aktualisiert wird, muss noch ein Cron Eintrag hinzugefügt werden.
55 5 * * * /usr/local/bin/mirror >/dev/null 2>&1
Am 26.05.2009 wurden die Schlüssel für die Debian Repositorys erneurt (Link: Linux-Magazin). Der neue Schlüssel kann auch manuell nachinstalliert werden.
gpg --keyserver hkp://subkeys.pgp.net --keyserver-options verbose --recv 55BE302B gpg --output ~/.gnupg/trustedkeys.gpg --export 55BE302B
Nachdem ich gerade ein Linux System auf dem OpenVPN läuft auf Debian 5 geupdatet habe wollte ich den OpenVPN Zugriff von meiner Maschine (Vista) aus testen, doch leider ging kein Ping durch. Die OpenVPN Verbindung wurde aufgebaut, doch es kam keine Verbindung zustande.
Ein Test auf einer anderen Maschine (XP) ergab, dass von dieser Maschine eine OpenVPN Verbindung aufgebaut werden konnte sowie auch ein Ping durch ging.
Im Log von OpenVPN sah das Ergebniss wiefolgt aus:
NOTE: FlushIpNetTable failed on interface [46] {F5E6244E-31DA-446A-B92F-5244C7CFFEA9} (status=5) : Zugriff verweigert
TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
route ADD xx.xx.xx.xx MASK 255.255.255.0 yy.yy.yy.yy
Der angeforderte Vorgang erfordert erh”hte Rechte.
ERROR: Windows route add command failed: system() returned error code 1
route ADD yy.yy.yy.yy MASK 255.255.255.0 yy.yy.yy.yy
Der angeforderte Vorgang erfordert erh”hte Rechte.
ERROR: Windows route add command failed: system() returned error code 1
Das Problem war in diesem Fall das fehlende Admin Recht um die Routen zu erweitern. Um das Problem zu lösen gab es zwei Möglichkeiten. Entweder man startet die OpenVPNGui als Administrator (rechte Maustaste) oder man deaktiviert die Benutzerkontensteuerung.
Als weitere Sinnvolle Option hat sich für Vista noch die Folgende Clientseitige Änderung der config heraus gestellt. Unter Windows XP gab dies keine Probleme.
route-method exe route-delay 2
Es ist immer wieder zu lesen, dass nur die aktuellen OpenVPN Versionen unter Vista funktioniere. Dies kann ich so nicht bestätigen. Ich setzte auch unter Vista erfolgreich die Version openvpn-2.0.9-gui-1.0.3-install.exe ein.
Relax and Recovery (read) ist eine für Linux entwickelte Backup Lösung die genau für das sorgen soll, was der Name vermuten lässt. Es sichert ein System und ermöglicht eine sehr einfache Wiederherstellung. Als besonders angenehm empfinde ich die Tatsache, dass es bereits ein fertiges .deb Pakete dafür gibt.
Im einzelnen sichert das System alle lokalen Daten und erstellt eine Iso-Datei mit der das System im Notfall gebootet werden kann. Das System kann anschließend über die rear console wiederhergestellt werden.
Ich hab rear unter Debian getestet. Es hat ohne Probleme funktioniert. Eventuell auftreten Fehlermeldungen hatten keinen Einfluss auf die Funktion des wiederhergestellten Systems.
NFS Server
Für die Ablage des Backups wird kann ein NFS-Server oder eine Freigabe benutzt werden.Die Installation eines NFS-Servers ist unter http://www.debianhelp.co.uk/nfs.htm beschrieben.
Die Schnellübersicht der Schritte sieht wie folgt aus:
Laut Anleitung kann jedes Ziel zur Sicherung nutzen, das gemountet werden kann. Interessant ist in diesem Zusammenhang evtl. der Artikel Debian: ftp, ssh, share per fstab mounten.
Um das Debian Paket von rear installieren zu können werden folgende weitere Pakete benötigt
apt-get install dosfstools mingetty mkisofs mtools syslinux syslinux-common binutils lsb iproute
Nun muss noch die Datei /etc/rear/local.conf angepasst werden.
BACKUP=NETFS NETFS_URL=cifs://192.168.1.210/mta-relay_backup$ #NETFS_OPTIONS=credentials=/etc/rear/user.credentials
Die letzte Zeile st nur notwendig, wenn für die Zugriff auf das Share ein Benutzer erforderlich ist. Ist dies der Fall, so muss neben der Angabe der credential Datei diese Datei selbst noch mit den Zugangsdaten angelegt werden
username=Administrator password=geheimespassword
Sie sollten in diesem Fall auf die Zugriffsrechte dieser Datei achten!
Um die Sicherung auf einer Dateifreigabe abzulegen, müssen noch folgende Pakete installiert werde
apt-get install smbfs samba-tools smbclient
Anschließend sollte man die Verbindung zur Freigabe prüfen
smbclient -L 192.168.0.2 -U administrator
Es kann vorkommen, dass dieser Vorgang bereits mit folgender Meldung abbricht
Domain=[STRAHLENZENTRUM] OS=[Unix] Server=[Samba 2.2.12]Server requested plaintext password but 'client use plaintext auth' is disabled tree connect failed: SUCCESS - 0
In diesem Fall müssen in der smb.conf im Abschnitt [global] folgende Einträge erweitert werden.
client lanman auth = Yes lanman auth = Yes
Wurden alle Pakete sowie rear installiert, kann das Backup über den Befehl
rear mkbackup
gestartet werden.
Wer das ganze richtig testen möchte, sollte auch die erste 10 MB der lokalen Festplatte löschen.
dd if/dev/zero of=/dev/sda bs=10M count=1
Es ist auch ohne weiteres möglich das Iso-Image auf einen USB Stick zu kopieren um so ohne CD-Rom Laufwerk das System wiederherzustellen.
dd if=ReaR.iso of=${USBSTICK}
Es macht unter Umständen keinen Sinn, Verzeichnisse mittels rear zu sichern, die für den Betrieb des Systems nicht zwingend erforderlich sind. Ein Beispiel wäre dafür das Cache Verzeichniss von Squid. Das Verzeichniss selbst kann schnell mehrere Hunder MB groß werden, die jedoch nicht gesichert werden müssen. Ausschließen lässt sich so ein Verzeichniss über die Datei /etc/rear/default.conf. Dort gibt es eine Zeile die wiefolgt aussieht:
BACKUP_PROG_EXCLUDE=( '/tmp/*')
Es reicht, das Auszuschließende Verzeichniss in den Klammern zu ergänzen.
ACKUP_PROG_EXCLUDE=( '/tmp/*' '/var/spool/squid/*' '/var/lib/amavis/virusmails/*' '/var/lib/amavis/infected_files/*' '/var/lib/amavis/tmp/*')
Jede Datei auf der Fesplatte wird durch ein Inode repräsentiert. Ein Inode selbst enthält den Standort der Datei auf der Festplatte, den Inhalt der Datei selbst sowie Berechtigung, Dateitype etc. Der Dateinamen den der User angezeigt bekommt enthält lediglich die Information über die Inode Nummer die auf das dazugehörige Inode verweißt.
Die Inode Nummer kann man sich auch direkt anzeigen lassen
bash# ls -i debian-500-i386-netinst.iso 63721 debian-500-i386-netinst.iso
In diesem Fall ist 63721 die Inode Nummer die die eigentliche Datei identifiziert. Die Zuordnung der Datei zur Inode Nummer erfolgt über den sogenannten Hardlink. Der Clou von Hardlinks ist, dass es auf eine Inode Nummer mehrere Hardlinks geben kann.
Angenommen, Sie legen einen Hardlink namens debian_netinst.iso an, der auf die “Datei” debian-500-i386-netinst.iso verweist…
ln debian-500-i386-netinst.iso debian_netinst.iso
werden Sie spätestens beim auslesen der Inode Nummer sehen, dass diese identisch ist.
bash# ls -i debian-500-i386-netinst.iso debian_netinst.iso 63721 debian-500-i386-netinst.iso 63721 debian_netinst.iso
Weiter angenommen Sie haben nun einen Hardlink auf dem Dateisystem erstellt der sich in einer ganz anderen Ordnersturkur befindet wie ein bereits vorhandener, so kann es passieren, dass sie Tage später die ältere “Datei” – eigentlich ja Hardlink löschen. Was passiert nun..?
bash# rm debian-500-i386-netinst.iso bash# ls -i debian_netinst.iso 63721 debian_netinst.iso
Ganz einfach, das System erkennt, dass die Inode Nummer noch an andere Stelle referenziert wird und entfernt lediglich den Hardlink. Das Inode selbst bleibt erhalten und somit auch alle andern Hardlinks auf diese Datei.
Lediglich beim entfernen des letzten Hardlinks wird die Datei entgültig gelöscht. Übrigens, Hardlinks funktionieren nur innerhalb der gleiche Partition, das liegt daran, dass jede Partition nur ihre eigenen Inodes kennt. Für Partitionsübergreifende Verlinkungen müssen Symbolische Links (ln -s) verwendet werden.
Der ein oder andere wird sich jetzt gefragt habe, woher er denn weiß, dass die Datei die er gerade gelöscht hat keinen weiteren Hardlink hatte. Dies kann man wiefolgt erkennen
bash# ls -l -rwxr-xr-x 1 root root 169388032 23. Sep 16:12 debian-40r... -rwxr-xr-x 2 root root 157204480 14. Feb 17:04 debian-500... -rwxr-xr-x 2 root root 157204480 14. Feb 17:04 debian_netin...