planetknauer.net

Hat man fetchmail erfolgreich konfiguriert und als Cronjob ein simples fetchmail -s eingerichtet, so wird sich der Cron Daemon über einen Fehler beschweren, wenn keine Mails im Postfach zur Abholung bereit lagen. Grund dafür ist, dass fetchmail nur 0 als Exit Code zurückgibt, wenn es erfolgreich Mails abgeholt hat. Lagen keine Mails im Postfach, lautet der Exit Code 1, was von Cron völlig berechtigt als Fehler bemängelt wird. Ein kurzes Studium von man fetchmail hat mir dann die Lösung gebracht, der Cronjob ist jetzt folgendermassen konfiguriert:

*/15 * * * * fetchmail -s || [ $? -eq 1 ]

Der rar-Archiver scheint eine praktische Funktion zu besitzen, nämlich das automatische Splitten beim packen. Ich muss diese Funktionalität mutmassen, da ich rar nicht zum packen verwende, da es unfrei ist. Und überhaupt gibt es in der freien Welt so viele Formate, dass ich dieses problemlos links liegen lassen kann. Jedenfalls resultiert das ganze in Dateien mit der Endung foobar.part1.rar, foobar.part2.rar etc. Das scheint wohl ganz praktisch zu sein für ein very poor man's Backup auf CDs.

Nun hatte ich neulich das Vergnügen, so eine Archivserie zu entpacken, bei welcher eines dieser Teilstücke verloren gegangen ist. Beim packen könnte man wohl angeben, dass ein "recovery volume" angelegt werden soll, womit der Verlust eines Teils kompensiert werden kann. Aber wer denkt schon an sowas Rar wird nun zwar anfangen zu entpacken, bricht dann aber bei der ersten Datei ab, welche sich (partiell) im verlorenen Teil befindet. Tja, nun hat man also den ersten Teil seines Backups, aber die Daten von hinter dem fehlenden Stück scheinen nicht zugänglich zu sein. Auch eine Suche mit Google hat hier nicht gross weitergeholfen, der Tenor war stets "kannst du vergessen, geht nicht". Aber das stimmt definitiv nicht! Man braucht sich also nicht zu ärgern, dass das Einlesen von 20 CDs oder das herunterladen von 100GB Daten für die Katz war. Zwar kennt rar den Parameter -kb, welcher defekt extrahierte Dateien behalten soll, aber das funktioniert in diesem Fall nicht. Der Entpackvorgang bricht trotzdem ab (hier für Klickibunti-Windosen).

Hier der Trick: Angenommen, part4.rar fehlt. Also erstellt man erst einen scheinbaren Teil 4. Am einfachsten kopiert man einen anderen Teil:
cp foobar.part3.rar foobar.part4.rar
Nun startet man den nächsten Entpackvorgang, schliesst jedoch die als defekt gemeldete(n) Dateien über den exclude-Parameter aus. Wichtig ist die korrekte Syntax zu beachten, nach dem -x darf kein Leerzeichen folgen und Dateinamen mit Leerzeichen müssen zwischen Hochkommata stehen:
unrar x -x'pfad/zu/defekter datei.xls' -x'pfad/zu/ebenfalls defekter datei.doc' foobar.part1.rar
Schon entpackt es weiter.

Natürlich fehlen letztendlich ein paar Daten unwiderbringlich. Aber sofern es sich um eine Notrekonstruktion aus einem defekten "very poor man's" Backup handelt, ist das doch schon besser als gar nichts mehr zu haben.

Vor etwa einem Jahr habe ich mir einen neuen Server zusammengebaut. Eigentlich wollte ich damals eine CPU, welche drei Anforderungen erfüllt: x86 64bit, virtualisierungsfähig und sehr stromsparend. Leider konnte jede vorhandene CPU höchstens zwei der Kriterien erfüllen, insbesondere bei Intels Atom sind auch heute noch Punkt eins und zwei gegenseitig ausgeschlossen. Und das stromsparendste von AMD war der Athlon X2 240e, welchen ich zuletzt ausgewählt hatte. Monate später wurden dann die Atom-Konkurrenten von AMD veröffentlicht. Zwei Geräte für Tests mit Cluster- und sonstigen Basteleien mit einer derartigen Zacate-CPU habe ich mir nun besorgt, und zwar zwei ZBOXen von Zotac. Diese sind extrem günstig, komplett ausgestattet und befreit von Microsoftsteuern. Zum einen habe ich mir einen Nano gekauft, da dieser mit Fernbedienung geliefert wird, so dass ich diesen später zu einem Multimediarechner umfunktionieren kann. Und zum anderen einen ADO2, da dieser im Gegensatz zum Nano Platz für zwei Speichermodule bietet, so dass er auf 8GB RAM ausgebaut werden kann.

Bei so schönen Geräten muss natürlich erst mal die Hardware etwas genauer getestet werden, statt sie nur im Konsolenmodus zu betreiben. Dazu wollte ich ein paar Betriebssysteme installieren. Ubuntu Desktop 11.10 lässt sich fast problemlos installieren. Die Installation von Ubuntu Server 11.10, Debian 6 und CentOS 6.2 scheitert jedoch an einem Punkt: Beim Laden des Installers geht plötzlich die Tastatur verloren. Natürlich kann jedes Huhn Debian installieren, wenn genügend Körner auf der Tastatur liegen. Aber die Tastatur muss halt funktionieren. Interessanter- und glücklicherweise tritt das Problem beim Ubuntu Desktop nicht auf, so, dass sich dieser mässig bequem installieren lässt.

Das Problem mit den USB-Tastaturen lässt sich auch mit keiner BIOS bzw EFI-Konfiguration beheben. Ich habe alle USB-Einstellungen in jeder Kombination getestet, in letzter Verzweiflung sogar USB-Legacy deaktiviert. Dazu steht im BIOS-Setup, dass dadurch USB-Geräte nur noch in EFI-Applikationen zur Verfügung gestellt würden. Tja, das BIOS-Setup ist blöderweise keine EFI-Applikation, so dass ich nun ganz ohne Tastatur dastand und dies somit nicht mehr einfach korrigieren konnte. Daher musste ich erst mal das CMOS resetten, was zum Glück recht simpel ist. Man muss die Bodenplatte des Geräts entfernen, d.h. erst die vier Daumenschrauben lösen, welche auch als Standfüsse dienen, und dann an der eingekerbten Ecke den Fingernagel einsetzen und die Bodenplatte herausreissen. Nun hat man Zugriff auf alle relevanten Innereien, d.h. Festplatte, WLAN-Karte und RAM-Sockel, so dass man an dieser Stelle auch einfach ein RAM-Upgrade durchführen kann. Für den Reset muss einfach der gummierte, unbeschriftete Knopf zwischen WLAN- und Speichermodul ein paar Sekunden gedrückt werden. Eine bebilderte Anleitung dafür findet sich leicht, jedoch ist in dieser der Reset-Knopf nicht ersichtlich.

Die Geräte verfügen über kein BIOS sondern das modernere EFI. So schöne Vorteile (wie z.B. richtig grosse Platten ohne Workarounds) das bietet, so wüste Nachteile bei der Bootloader-Installation zieht es mit sich. Zur Installation von Ubuntu bin ich folgendermassen vorgegangen:

• Zuerst habe ich von meinem bevorzugten Mirror das CD-Image für Ubuntu Live 64bit heruntergeladen und dieses mittels unetbootin auf einen bootbaren USB-Stick geschrieben. Diesen habe ich dann in den Zotac eingsteckt und das Gerät eingeschaltet.
• Wenn die Startpiepser ertönen (ähnlicher Klang wie die Telefone in 24), ein paar mal auf DEL hämmern, um ins BIOS-Setup zu gelangen. Unter "Boot" muss die Startreihenfolge angepasst werden, so dass zuerst ab USB-Stick gestartet wird.
• Jetzt erscheint der Bootloader und kann man entweder Ubuntu Live starten und dort das Setup aufrufen oder grad den Installer starten.
• Die Festplatte muss unbedingt manuell partitioniert werden, denn EFI verlangt eine EFI-Partition. Der gparted-Verschnitt des Ubuntu-Installers legt gleich eine GPT-Partitionstabelle an, so dass als erste Partition eine FAT32-Partition von mindestens 200MB angelegt werden kann. Die Schwierigkeit besteht darin, dieser noch das Flag bios_grub gesetzt werden muss. Unter Ubuntu Live ist das kein Problem, da partitioniert man einfach vorher rasch mit gparted. Wichtig ist, dass man die ganze Platte löscht und eine neue Partitionstabelle vom Typ GPT anlegt.
  Im reinen Installer-Modus wechselt man mittels ctrl-alt-F1 in die Konsole, startet mittels
  $ sudo parted
  eine parted-Shell und setzt das Flag rasch per Kommando
  set 1 bios_grub on
  (tatsächlich habe ich im Arch-Wiki gelesen, dass man das Flag boot setzen muss, aber dann meckern später EFI und grub-installer). Zurück zum Installer gelangt man durch alt-F7.
• Nun installiert man Ubuntu ganz normal fertig. Bloss neu starten sollte man noch nicht! Zuerst muss grub noch richtig installiert werden. Dazu wechselt man wieder in die Kommandozeile (bzw öffnet eine Shell in Ubuntu Live) und gibt folgende Befehle ein:
  $ sudo mount /dev/sda2 /mnt (/dev/sda2 muss ggf durch die korrekte Angabe für die Root-Partition ersetzt werden) und
  $ sudo grub-install --root-directory=/mnt /dev/sda (auch hier muss /dev/sda ggf durch die korrekte Angabe für die Platte, worauf Ubuntu installiert wurde, ersetzt werden).
• Jetzt kann man neu starten und Ubuntu sollte fehlerfrei booten. Die EFI-Warnmeldungen bezüglich Bildschirmauflösung und "file not found" kann man ignorieren.

Die Leistung der Geräte ist nicht schlecht. Sogar Nexuiz läuft passabel wenn der proprietäre AMD-Treiber fglrx installiert wird, bei 1024x768 ist es mit 40-70FPS absolut spielbar. Bei höheren Auflösungen kommt die Grafikeinheit aber an den Anschlag.

Mal wieder dicke Punkte für Linux als Rettungssystem. Kollege bringt mir seinen defekten PC mit einem Intel Matrix RAID. Natürlich RAID-Level 0, d.h. ohne Netz und doppelten Boden. Man müsste die Daten von den Disk versuchen zu retten, weil Backup ist nicht...

Na gut. Die Kiste fährt nicht hoch sondern piepst nur. Ergo Platten raus, in meinen alten Schrott-PC rein und die nächstbeste Live-CD (in diesem Falle CloneZilla) gestartet und mal geschaut, was da Sache ist. mdadm sollte ab Version 3.0 in der Lage sein, solche Non-Linux-SoftRAID Verbünde wieder zusammenzusetzen. Tatsächlich klappt das auch. Verwirrend ist jedoch, dass die physischen Festplatten als /dev/sda1 und /dev/sda2 (was ja eigentlich Partitionen wären) eingebunden sind und das logische Laufwerk, d.h. der Verbund, als /dev/sda (was eigentlich die erste physische Platte sein sollte) verfügbar ist. Tja, wo sind nun die Partitionen? Diese finden sich unter /dev/dm-[0-9] und können von dort ganz normal gemountet werden. CloneZilla hat NTFS-3G schon dabei, somit ist auch der Zugriff auf die Windows-Partitionen kein Problem.

Kurz die Daten auf eine externe USB-Disk gesichert, und gut ist.

Ab und zu braucht oder möchte man mal unter Debian Stable ein neueres Programm installieren. Oft findet sich dies in Unstable oder gar Testing, aber leider gibt's dann oft keinen Backport. Das ist aber kein Problem. Meine Backports bau ich anhand dieser Anleitung, mit einigen Ergänzungen. Hier erläutere ich dies am Beispiel des Messengers Pidgin:

Als erstes werden mir root-Rechten die benötigten Abhängigkeiten für den Bau des Pakets installiert:

# aptitude build-dep pidgin

Bis auf weiteres können alle weiteren Schritte als normaler User ausgeführt werden. Als nächstes wird die Source und die Debian-Modifikation von packages.debian.org heruntergeladen und in ein eigens für den Build erstelltes Verzeichnis kopiert:

$ mkdir pidgin
$ cd pidgin
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0.orig.tar.bz2
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0-3.debian.tar.gz

Nun wird entpackt:

$ tar -jxf pidgin_2.9.0.orig.tar.bz2
$ cd pidgin-2.9.0
$ tar -zxf ../pidgin_2.9.0-3.debian.tar.gz

Der nächste Schritt ist etwas fummelig. Allenfalls müssen Abhängigkeiten angepasst werden, weil das Debian-Skript eine neuere Version einer Abhängigkeit fordert als nötig und/oder für Debian Stable verfügbar ist. Fehlerhafte Abhängigkeiten können einfach bestimmt werden, indem man den nächsten Schritt ausführt und den Kompiliervorgang versucht zu starten. Zur Bereinigung von Abhängigkeiten mit unnötig hoher Version muss die Datei debian/control bearbeitet werden.
Einige benötigte Abhängigkeiten mit höherer Version lassen sich aus den Backports installieren, dies klappt mittels aptitude -t squeeze-backports install myrequireddependency (vorausgesetzt, das backports-Repository ist konfiguriert). Für einige ganz fiese Abhängigkeiten kann es nötig sein, dass man davon selbst ein Update gemäss dieser Anleitung erstellen und installieren muss.

Sind alle Probleme behoben, kann man nun den Compiler anwerfen lassen:

$ dpkg-buildpackage -rfakeroot -uc -b

Wenn dies erfolgreich war, erhält man ein installationsbereites .deb-Paket. Für die Installation sind natürlich wieder root-Rechte erforderdlich:

$ cd ..
$ su
# dpkg -i *.deb

Kaum zu glauben: Aber mit Treiberversion 11.7 steht nun endlich ein AMD-Treiber zur Verfügung, welcher sich ohne rumgepatche und langen händischen Kompilierorgien out-of-the-box auf Kernel 2.6.38 aus den Debian Backports installieren lässt. Wird ja auch so langsam Zeit, jetzt wo schon bald Kernel 3.1 vor der Türe steht...

Oh, Microsoft blättert 8.5Mia Dollars für Skype hin? Kein schlechter Deal für die Investorentruppe, die vor zwei Jahren 1.9Mia Dollar für 70% bezahlt hat. Und eBay guckt bestimmt blöd aus der Wäsche

Nun wird die Linux-Version vermutlich eingestampft. Na gut, machen wir doch gleich Nägel mit Köpfen:

aptitude purge skype
rm -rf /home/*/.Skype

Problem gelöst.

Wirklich gemocht hab ich den proprietären Binärblob ja nie wirklich.

AMD hat vorgestern Treiber 11.4 für Linux veröffentlicht. Der ist somit zwei Monate nach Kernel 2.6.38 erschienen. Ob der Treiber sich wohl gegen den Kernel kompilieren lässt?

Antwort: Leider nein:

AMD kernel module generator version 2.1
doing Makefile based build for kernel 2.6.x and higher
rm -rf *.c *.h *.o *.ko *.a .??* *.symvers
make -C /lib/modules/2.6.38-2-amd64/build SUBDIRS=/usr/src/fglrx-8.841/2.6.x modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.38-2-amd64'
CC [M] /usr/src/fglrx-8.841/2.6.x/firegl_public.o
/usr/src/fglrx-8.841/2.6.x/firegl_public.c: In function ‘KCL_GlobalKernelLock’:
/usr/src/fglrx-8.841/2.6.x/firegl_public.c:1903: error: implicit declaration of function ‘lock_kernel’
/usr/src/fglrx-8.841/2.6.x/firegl_public.c: In function ‘KCL_GlobalKernelUnlock’:
/usr/src/fglrx-8.841/2.6.x/firegl_public.c:1909: error: implicit declaration of function ‘unlock_kernel’
make[4]: *** [/usr/src/fglrx-8.841/2.6.x/firegl_public.o] Fehler 1
make[3]: *** [_module_/usr/src/fglrx-8.841/2.6.x] Fehler 2
make[2]: *** [sub-make] Fehler 2
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.38-2-amd64'
make: *** [kmod_build] Fehler 2
build failed with return value 2

Ich tippe ja drauf, dass man da noch über das entfernte BKL stolpert.

Bislang gab es relativ gute Pakete für Mumble 1.2.3 aus Debian Experimental, welche sich sauber unter Debian Squeeze installieren liessen. Unterdessen gibt es einen neuen Build, der auch grad das ganze QT aktualisieren will. Da dürfte ein ziemlich defektes System daraus resultieren. Logische konsequenz? Selber bauen natürlich

zuerst das alte Mumble deinstallieren:

aptitude purge mumble

Danach geht's eigentlich streng gemäss Wiki. Als nächstes muss man die benötigten Entwicklungspakete installieren:

apt-get build-dep mumble

Und nun die Source mit den gewünschten Parametern kompilieren. Ich brauch weder Server noch den Mumble 1.1 Clienten. Letzterer wird über den nicht dokumentierten Switch no-11x deaktiviert. Unter Debian werden die Lokalisierungen nicht gefunden und integriert, daher werden diese einfach ausgeschaltet. Vermutlich liesse sich das über Symlinks korrigieren

tar -zxf mumble-1.2.3.tar.gz
cd mumble-1.2.3
qmake-qt4 -recursive main.pro CONFIG+=no-server CONFIG+=no-embed-qt-translations CONFIG+=no-11x
make
su -c 'cp -r release /opt/mumble'
su -c 'cp icons/mumble.xpm /opt/mumble'

Und nun noch die Sache starten:

/opt/mumble/mumble

Sobald man mehr als zwei Monitore angeschlossen hat, beginnt Gnome bei der Multimonitorfähigkeit zu versagen. Ich habe zwei Monitore zu einem grossen Desktop zusammengefasst (AMD nennt dies in seinen proprietären Treibern BigDesktop) und einen weiteren Monitor separat laufen. Leider maximieren sich Fenster nun über den ganzen Dualscreen statt sich perfekt auf einen Monitor einzupassen. Besonders mühsam ist dies, wenn man ein Video im Vollbildmodus betrachten will. Mit nur zwei angeschlossenen Monitoren passiert dies nicht - selbst wenn diese zu einem grossen Desktop zusammengefasst werden. Interessanterweise sind aber das Hintergrundbild sowie die Panel perfekt an den Monitor angepasst. Da kommt als Verdächtiger folglich rasch der Window Manager, also Metacity in Frage.

Folglich habe ich diesen durch diverse andere Varianten ersetzt. openbox scheitert genau so am Multimonitor und mutter stürzt direkt mit Speicherzugriffsfehler ab. Aber xfwm4 aus Xfce4 funktioniert gemäss Wunsch. Allerdings braucht es dann noch einiges an Tweaking, bevor das ansonsten gewohnte Metacity-Verhalten wiederhergestellt ist (und ein paar sehr nette Komfortfunktionen dazugewonnen wurden).

Zunächst muss xfwm mit ein paar Accessoires installiert, gestartet und konfiguriert werden. Alle Angaben sind wie üblich für Debian und verwandte Systeme:

su
aptitude install xfwm4 xfce4-utils xfce4-settings
exit
xfmw4 --replace &
xfwm4-settings
xfce4-settings-helper

Der xfce4-settings-helper verschwindet sofort im Hintergrund und aktiviert die Tastenkürzel wie z.B. Alt-F2 wieder.

Jetzt stört mich nur noch, dass Fenster auch beim Scrollen mit dem Mausrad Fokus bekommen. Dies lässt sich über den xfce4-settings-editor abstellen, indem man den Wert des Eintrags /xfwm4/raise_with_any_button auf FALSE setzt.

Soweit so einfach. Kommen wir nun zum zeitlich aufwändigsten Teil. Um nun xfwm4 permanent als Standard einzurichten, gibt es unzählige Möglichkeiten. Ich habe nur eine gefunden, die "gefühlt fehlerfrei" funktioniert und diese ist technisch gesehen totaler Blödsinn. Und zwar habe ich in gnome-session-properties zwei neue Starter angelegt. Einer startet /usr/bin/xfwm4 --replace und ein zweiter /usr/bin/xfce4-settings-helper. Das ist natürlich insofern doof, da erst metacity und danach xfwm4 als Ersatz gestartet wird. Dies führt bei mir jedoch zu absolut keiner Startverzögerung, ganz im Gegensatz zu der Variante, eine ~./gnomerc anzulegen und darin die Zeile export WINDOW_MANAGER="/usr/bin/xfwm4" einzufügen. Das Resultat ist ein um 10 Sekunden verzögertet Start von Gnome. Das ist natürlich nicht akzeptabel. Ebenso gibt es die Variante im gconf-editor unter /desktop/gnome/session/required_components den Schlüssel windowmanager von gnome-wm zu xfwm4 zu ändern. Das Resultat hierbei war, dass gar kein Window Manager mehr gestartet wurde. Also noch schlimmer! Tja, und unter Debian gibt's noch die /etc/alternatives/x-window-manager. Diesen Symlink von /usr/bin/metacity auf /usr/bin/xfwm4 zu ändern bringt grad gar nichts, da dieser Symlink auf meinem System von gnome-wm (ist nur ein Shellskript) gar nicht ausgewertet wird.

Somit wär also ein Freitagabend verschwendet, weil Debian Stable ja sooo bugfrei ist.

Da heute LibreOffice 3.3 in stabiler Version freigegeben wurde, wird es höchste Zeit, das proprietär gewordene OpenOffice.org loszuwerden. Da LibreOffice schon im experimental-Zweig von Debian Einzug gehalten hat, lässt es sich sehr elegant auch unter Squeeze (derzeit noch testing) installieren.

Zuerst muss der experimental-Zweig zu apt hinzugefügt werden:

cat >> /etc/apt/source.list <<EOF
deb http://ftp.ch.debian.org/debian/ experimental main
deb-src http://ftp.ch.debian.org/debian/ experimental main
EOF
cat >> /etc/apt/preferences <<EOF
Package: *
Pin: release a=testing
Pin-Priority: 700

Package: *
Pin: release a=experimental
Pin-Priority: 600
EOF

aptitude update

Anschliessend kann bequem irgendwelche Software aus experimental hinzugefügt werden, indem mittels dem Parameter -t an aptitude/apt-get signalisiert wird, welcher Debian-Zweig verwendet werden soll. Die LibreOffice-Paket haben jedoch noch ein paar unsaubere Abhängigkeiten, so dass derzeit einige davon aus testing verwendet werden müssen.

aptitude install libhsqldb-java
aptitude -t experimental install libreoffice libreoffice-l10n-de libreoffice-gnome ttf-opensymbol

Irgendwie läuft der Ati-Kram noch nicht ganz zufriedenstellend. Immerhin hat es AMD unterdessen fertiggebracht, ihr Treiberpaket mit korrekten md5-Signaturen zu versehen. Ich hab daher auf meinem Debian Squeeze ein Kernel-Update auf 2.6.36.3 vorgenommen (mit dem 2.6.37 kann man den Ati-Murks unmöglich kompilieren) und dann den aktuellen Ati-Treiber versucht zu installieren. Nicht ganz trivial, aber es geht. Ich setze mal voraus, dass ein vollständiges build-environment samt gcc und xorg-dev installiert ist.

Erst ein Kernel-Update:

cd /usr/src
tar -jxf /path/to/linux-2.6.36.3.tar.bz2
cd linux-2.6.26.3
cp /boot/config-2.6.32-5-amd64 .config
make oldconfig
fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers --jobs=8
dpkg -i ../linux-image-2.6.36.3-custom_amd64.deb

Mit --jobs=8 wird der nagelneue Quadcore auch endlich mal etwas ausgereizt

Gut, danach reboot und Installation der Ati-Treiber samt der dubiosen Patches von hier:

sh ati-driver-installer-10-12-x86.x86_64.run
cd /
patch -p1 < /path/to/arch-2.6.36.patch
patch -p2 < /path/to/ati-drivers-2.6.36.patch
patch -p1 < /path/to/ati-drivers-fix_compilation-bug-297322.patch
patch -p1 < /path/to/sema_init.patch
cd /lib/modules/fglrx/build_mod
./make.sh
cd ..
./make_install
modprobe fglrx

Dann klappt's auch mit AMD. Die grosse Stolperfalle ist der zweite Patch, welcher anders codierte Pfadangaben drin hat und darum mit -p2 statt -p1 aufgerufen werden will. Der Rest ist ziemlich geradeaus.

Kann man wirklich sooooooooooo dumm sein???

$ sh ati-driver-installer-10-12-x86.x86_64.run
Created directory fglrx-install.qE5M0i
Verifying archive integrity...Error in MD5 checksums: 48c2e8ce1f504f07a0985afe489b26e3 is different from dfc5d2753d97882b67eb453b85ff8dbc

Zum Glück hat die Karte nur 38.- gekostet. Na ja, nächstes mal wieder nVidia.

Neulich bin ich mal gefragt worden, wie ich Backups mache. Die Antwort: Mit einem relativ simplen Cron-Skript und rdiff-backup per SSH auf den Fileserver. Das gibt ein schönes inkrementelles Backup, bei dem man beliebig weit zurückgehen kann, allerdings behalte ich nur die Daten der letzten zwei Monate. Rdiff-Backup braucht relativ wenig Rechenleistung, Bandbreite und Speicherplatz und funktioniert auch hervorragend über's Internet. Wird das Cron-Skript häufig genug aufgerufen, emuliert dieses Backup recht gut das Verhalten von Apples Time-Machine. Nachteilig ist lediglich, dass es in meinem Fall ein vom Clienten initiiertes Backup ist. Solange der zu sichernde Rechner die Daten auf den Backup-Server schreibt, ist ein Backup nicht sicher vor Manipulationen. Besser wäre es, wenn der Server vom Clienten lesen würde. Nur bräuchte der Server dann root-Login auf dem Clienten, was auch nicht unbedingt der Sicherheit förderlich ist...

Folgendes muss man auf dem Server einrichten:

• SSH-User für's Backup
• Im $HOME/.ssh/authorized_keys die public-SSH-Keys des root-Users der zu sichernden Systeme eintragen (ja, das Backup-Skript wird in der Regel als root laufen, da man z.B. auch /etc sichern will).
• Im Verzeichnis, welches die Backups enthalten soll, muss für jeden zu sichernden Rechner ein Verzeichnis erstellt werden, das so heisst, wie der Host (zu erfahren durch Eingabe von "hostname" auf dem Client)
• In diesen Verzeichnissen muss jeweils eine Verzeichnisstruktur erstellt werden, welche der $DIRECTORIES-Variable aus untenstehendem Skript entspricht.
• Zuletzt chownt man diese gesamte Struktur an den zuerst erstellen SSH-User.

Und so schaut mein Skript aus:

#!/bin/bash

### Settings ###
DIRECTORIES="/etc /home /usr/local/bin"
EXCLUDES="/home/*/.local/share/Trash"
SSHUSER="rdiff-backup"
SSHHOST="192.168.0.1"
REMOTEDIR="/mnt/backup/$(hostname)/"
RDIFF="/usr/bin/rdiff-backup"
RDIFFOPTIONS="ssh -p 2222 %s rdiff-backup --server"
FILEAGE="2M"

NOW=$(date +"%Y-%m-%d")
GZIP="$(which gzip)"
STATUSFILE="/var/tmp/rdiff-backup-status"
LOCKFILE="/var/lock/rdiff-backup-lock"
DUMPDIR="/home/backup"

if [ -e "$LOCKFILE" ]; then
echo "Lockfile exists, quitting..."
exit 255
fi

touch "$LOCKFILE"

### Packages List ###
dpkg --get-selections | $GZIP > $DUMPDIR/dpkg.$NOW.txt.gz
RETVAL=$(($RETVAL + $?))

### File based Backup ###
for DIR in $DIRECTORIES; do
EXCLUDESLIST=""
for EXCLUDE in $EXCLUDES; do
SIZE=$(expr match "$EXCLUDE" "$DIR")
if [ $SIZE -gt 0 ]; then
EXCLUDESLIST="$EXCLUDESLIST --exclude $EXCLUDE"
fi
done
$RDIFF $EXCLUDESLIST --remote-schema "$RDIFFOPTIONS" $DIR $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RDIFFRETVAL=$?
RETVAL=$(($RETVAL + $RDIFFRETVAL))
if [ $RDIFFRETVAL = 0 ]; then
$RDIFF --force --remote-schema "$RDIFFOPTIONS" --remove-older-than $FILEAGE $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RETVAL=$(($RETVAL + $?))
fi
done

find $DUMPDIR -ctime +7 -exec rm -f '{}' ';'
RETVAL=$(($RETVAL + $?))

echo $RETVAL > "$STATUSFILE"
rm -f "$LOCKFILE"
exit $RETVAL

Was bedeuten nun all die Variablen unter "Settings"?

• DIRECTORIES: Die zu sichernden Verzeichnisse.
• EXCLUDES: Nicht zu sichernde Verzeichnisse
• SSHUSER: Mit welchem User wird per SSH am Server angemeldet
• SSHHOST: Die Adresse des Backup-Servers. Entweder eine IP oder ein Hostname.
• REMOTEDIR: Das Basisverzeichnis, worin auf dem Server die Backups gespeichert werden.
• RDIFF: Pfad zum lokal rdiff-backup Binary
• RDIFFOPTIONS: Wenn man zusätzliche Optionen angeben will, z.B. einen alternativen SSH-Port. Kann man auch leer lassen
• FILEAGE: Nach wie vielen Tagen/Monaten/Jahren die Inkremente gelöscht werden sollen

mod_gnutls hab ich wieder durch mod_ssl ersetzen müssen. Grund:

[Tue Aug 17 09:21:32 2010] [notice] Apache/2.2.9 (Debian) mod_gnutls/0.5.1 configured -- resuming normal operations
page 7: illegal page type or format
PANIC: Invalid argument
PANIC: fatal region error detected; run recovery

Und die letzte Zeile wiederholt sich dann, bis das Logfile die Festplattenkapazität gesprengt hat. Dauert bei den paar freien GB auf dem vserver so ca 20 Minuten...