Backup leicht gemacht: Lokale und entfernte Sicherung mit Dirvish, Rsync und SSH

An mehreren Stellen habe ich hier schon meine ganz persönlichen Backup-Methoden vorgestellt.

  1. Keep it simple
  2. Partimage
  3. Partclone
  4. The Debian Way
  5. Apt-Clone
  6. Live-CDs (z.B. Clonezilla)

Die Reihe könnte man noch eine Weile mit weiteren guten Alternativen fortführen. Oft kombiniere ich auch die ein oder andere Variante, wenn mir Daten besonders wichtig sind. In den vergangenen Wochen habe ich mir endlich Dirvish näher angeschaut, das Rsync und SSH miteinander verbindet und mir wieder einmal die Frage gestellt: „Warum eigentlich nicht früher?“. 🙂 Wer sowieso schon Rsync und SSH kennt, aber sich die vielen Kommandos nicht merken oder sogar Skripte dafür schreiben möchte, kann ganz einfach auf Dirvish zurückgreifen, das diese Probleme schon vor einer Dekade gelöst hat.
Interessant ist Dirvish nicht nur für alle, die gerne nach besonders effizienten Lösungen für die Konsole suchen, sondern es besticht vor allem durch die einfache Konfiguration und der Möglichkeit die Sicherung vollautomatisch per Cron-Job ablaufen zu lassen und kann auch ganz leicht manuell bedient werden.
Im Folgenden beschreibe ich die Sicherung eines Laptops und eines entfernten vServer mit Hilfe von Dirvish, Rsync und SSH. Dabei werden alle Daten auf eine handelsübliche USB-Festplatte gesichert, die an den Laptop angeschlossen ist.

Backup eines lokalen Rechners auf eine USB-Festplatte mit Dirvish

aptitude install dirvish

Nach der Installation von Dirvish, welches auch automatisch Rsync als Abhängigkeit mitinstalliert, könnt ihr mit der Dokumentation in /usr/share/doc/dirvish/HOWTO.Debian.gz und im dazugehörigen Beispiel-Ordner sofort loslegen. Für die gesamte Konfiguration sind lediglich zwei Dateien entscheidend.

master.conf

Die Datei master.conf wird nach /etc/dirvish/master.conf kopiert. Hierin werden alle globalen Einstellungen festgeschrieben.

  • bank: Gibt den Pfad zum Speicherort der Sicherung an. In meinem Fall existieren zwei Verzeichnisse auf einer externen USB-Festplatte, der ich zuvor mit
    tune2fs -L backup /dev/mapper/udisks-uuid-und-noch-mehr-Text
    einen kürzeren und leichter zu merkenden Namen gegeben habe. Wenn man schon dabei ist, kann man sie auch gleich mit luksformat vorher verschlüsseln.
  • exclude: Definiert die Verzeichnisse, die nicht gesichert werden sollen.
  • Runall: Die zuerst angegebenen Namen bezeichnen die sogenannen Schließfächer (vault), in denen die Daten gespeichert werden. Ein Schließfach ist nichts anderes als ein Unterverzeichnis, das man nach dem zu sichernden Dateisystem benennen sollte. Der Zeitstempel definiert nicht den Zeitpunkt der Ausführung, sondern dient lediglich als Bezugspunkt. Sollte das Backup z.B. aus welchen Gründen auch immer später ausgeführt werden, wird die Sicherung auf 22.00 Uhr zurückdatiert, damit die Logik intakt bleibt.
  • expire-default: Kann z.B. never oder +15 days sein und gibt an, wie lange einzelne Sicherungen standardmäßig vorgehalten werden sollen.
  • expire-rule: Wer den Aufbau der Datei crontab kennt, weiß sofort um was es geht. Die erste Zeile besagt, dass am ersten Tag der Woche, dem Montag, erstellte Backups für 3 Monate vorgehalten werden sollen. Man kann mit Hilfe dieser Syntax weitere beliebige Zeiträume und Zeitpunkte definieren.
bank:
	/media/backup/dirvish/laptop
	/media/backup/dirvish/server
exclude:
	lost+found/
	proc/
Runall:
	laptop-root	22:00
	laptop-home	22:00
	server-root	22:00
expire-default: +15 days
expire-rule:
#       MIN HR    DOM MON       DOW  STRFTIME_FMT
	*   *     *   *         1    +3 months
#	*   *     1-7 *         1    +1 year
#	*   *     1-7 1,4,7,10  1
#	*   10-20 *   *         *    +4 days
#	*   *     *   *         2-7  +15 days

Der Laptop

Erstellt nun die zweite Konfigurationsdatei für das Schließfach laptop-root. In diesem Beispiel wäre das
/media/backup/dirvish/laptop/laptop-root/dirvish/default.conf.
Default.conf ist immer richtig und für die meisten Anwendungsfälle vollkommen ausreichend. Es lassen sich aber noch zusätzliche Konfigurationen erstellen (Branch).

client: laptop
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak
        /proc/**

Die Datei ist ähnlich wie die Datei master.conf aufgebaut. Wichtig sind hierbei vor allem:
client: In diesem Fall laptop. Wenn dieser Name dem Rechnernamen entspricht (hostname), erkennt Dirvish automatisch, dass es sich um ein lokales Backup handelt und verwendet kein SSH.
tree: Welches Verzeichnis gesichert werden soll. In diesem Fall das gesamte Wurzelverzeichnis.
xdev: Kann den Wert 1 oder 0 annehmen. 1 bedeutet, dass die Sicherung auf das angegebene Dateisystem beschränkt bleibt und Dirvish z.B. eingehängten Verzeichnissen nicht folgen wird. Hat man wie ich /home auf eine andere Partition installiert, würde dieses beim Wert 1 nicht gesichert werden. Hierzu muss also ein weiteres Schließfach mit einer neuen default.conf angelegt werden oder man setzt xdev hier auf 0.
Des Weiteren lässt sich der Zeitstempel für das Backup festlegen und Verzeichnisse von der Sicherung ausschließen. Diese Regel gilt zusätzlich zu den in der master.conf getroffenen Einstellungen.
Für das Schließfach „latop-home“ müsst ihr noch einmal die Schritte gehen. Hier ändert sich nur der Wert der tree-Variable auf /home und ggf. die ausgeschlossenen Verzeichnisse.

Die erste Sicherung – Initialisieren

dirvish --vault laptop-root --init
dirvish --vault laptop-home --init

Am nächsten Tag könnt ihr dann mit

dirvish-runall

ein neues Backup erstellen, bei dem nur die geänderten Daten gesichert werden. Aufgrund der Verwendung von Hardlinks und der inkrementellen Natur der Datensicherung wird deswegen nur wenig Speicherplatz benötigt. Wird dieser doch einmal knapp, lässt sich mit

dirvish-expire

Platz schaffen, indem die in der master.conf definierten Regeln Anwendung finden.
Wer einen eigenen Heimserver betreibt, kann auch die Einstellungen in /etc/cron.d/dirvish beibehalten, die dafür sorgen, dass Dirvish automatisch um 04.22 Uhr ausgeführt wird. Wer den Rechner nicht 24/7 laufen lässt, sollte die Datei entfernen oder den Cron-Job auskommentieren.

Entfernte Sicherung eines vServers mit Hilfe von SSH

Wenn ihr bis hierher gefolgt seid, dann ist die Datensicherung eures vServers, auf die an euren Laptop angeschlossene USB-Festplatte, ein Kinderspiel.
Ihr benötigt dafür auf jeden Fall das Paket SSH, einen Account auf dem Server und SSH-Schlüssel. Weiterhin gehe ich davon aus, dass ihr wie im alten Beitrag beschrieben den Port des SSH-Servers geändert habt und Root sich nicht anmelden darf.
Diese Beschränkung heben wir nun wieder auf, da wir den kompletten vServer sichern wollen. Aber…Root darf nur ein einzelnes Kommando über SSH ausführen, den Rsync-Befehl, und sonst nichts.

Default.conf des Servers auf dem Backup-Rechner

client: server
rsh: ssh -p 44444 -i '/root/.ssh/id_rsa'
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak

Der entscheidende Unterschied zu der lokalen Sicherung der Daten des Laptops ist der geänderte Wert für client: und die Variable rsh. Am besten tragt ihr in /etc/hosts einen Alias für eure Server-IP ein und nennt diesen dann schlicht server.
Der Wert für rsh (remote shell) ist der SSH-Befehl, um sich mit einem SSH-Server und dem SSH-Schlüssel zu verbinden, der auf einem Nicht-Standardport Anfragen entgegennimmt.

Auf dem Server

In der Datei /etc/ssh/sshd_config den Wert für PermitRootLogin auf forced-commands-only setzen.
Danach noch dem öffentlichen SSH-Schlüssel in /root/.ssh/authorized_keys eine Bedingung voranstellen, die erfüllt sein muss, damit sich Root anmelden darf. (vor ssh-rsa schreiben)

command="rsync --server --sender -vlHogDtprxe.iLsf --numeric-ids . /",from="10.0.0.5",no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Mit from= lässt sich sogar die IP-Adresse einschränken, von der sich Root anmelden darf. Der Befehl selbst lässt sich leicht mit htop auf dem Server herausfinden, wenn man ein Dirvish-Backup beobachtet oder man macht es wie Thor Dreier mit einem Hilfsskript, von dem auch dieser exzellente Dirvish-Tipp stammt. Sein Artikel aus dem Jahr 2005 ist auf jeden Fall empfehlenswert.

Fazit

Dirvish ist eine alte, aber noch lange nicht ergraute Lösung zum Sichern von Daten. Mit Hilfe auch gerne etwas älterer Hardware, habt ihr im Handumdrehen eine Backup-Lösung für alle Rechner zu Hause und für das Rechenzentrum in Schweden. 😉

Partition verschwunden: blkid rettet den Tag

Ich war etwas überrascht als ich eines Tages Lubuntu startete und meine Swap-Partition verschwunden war. Während ich noch darüber grübelte, was ich zuvor wieder angestellt hatte, kam mir als erstes die gute alte /etc/fstab in den Sinn. Wer 10 Jahre zurückdenkt schwelgt sicher noch in seeligen Erinnerungen über die manuelle Bearbeitung dieser Datei. (Ok, ich übertreibe ein wenig.) Neue Partitionen konnten und können dort manuell z.B. mit einer Zeile wie dieser eingehängt werden.

/dev/sda5    /mnt/daten    ext2    user, noauto   0      0

Mittlerweile gibt es mit sogenannten UUIDs eine flexiblere und vor allem präzisere Möglichkeit verschiedene Geräte und Partitionen einzigartig zu identifizieren. In meinem Fall erkannte ich schnell, dass sich die UUID der Swap-Partition aus mir unbekannten Gründen verändert hatte. Meine Vermutung ist, dass ein Zurückspielen eines Backups mit Partclone auf eine andere Datenpartition die Logik irgendwie aus dem Tritt gebracht hat.
Will man nun wissen, wie die aktuelle UUID lautet, kann man mit
blkid
Attribute von Blockgeräten abfragen. Diese aktuelle UUID ersetzt die alte in /etc/fstab, womit nach einem Neustart die Swap-Partition wiederhergestellt sein sollte. Voilà. 🙂

Mediathekview 3.0: Es ist angerichtet

Esst solange es heiß ist. Ich habe soeben Mediathekview 3.0 auf meinen FTP-Server hochgeladen.

Update 13.08.2012: Zusätzlich im Angebot nun auch Version 2.6.1, die letzte der 2er-Variante. Hier beschränken sich die Veränderungen nur auf das Notwendigste um Lintian-Fehler zu beseitigen und die Filmliste wieder funktionsfähig zu machen. Die Änderungen sind immer noch relativ groß, was es schwierig macht dafür eine Uploaderlaubnis nach Wheezy zu bekommen. Ich schicke den Patch auf jeden Fall an den Debian-Bugtracker und dann sehen wir einfach mal weiter.
Update 15.08.2012: Version 3.0 hat nun ein neues Menüicon, ein Changelog und die Kurzanleitung. So sieht das vorläufige neue Icon von W. Xaver, dem Entwickler von Mediathekview, aus.
Update 16.08.2012: Neue Anleitung.pdf für Version 3.0 und einige kosmetische Änderungen am Quellpaket.

Mediathekview 3 Icon
Update 22.08.2012: Wir nähern uns der finalen Version. Einen potentiellen Sponsor habe ich gefunden und es sieht so aus als ob ich auch der Paketverwalter von Mediathekview werde.
Update 28.09.2012: Fast geschafft. MediathekView 3.0 im September 2012.
Update 05.10.2012: Seit dem 03.10.2012 befindet sich Mediathekview in Debian Unstable. Von dort wird es „bald“ auch nach Ubuntu gelangen. Deswegen entferne ich nun die hier zur Verfügung gestellten Pakete. Danke an alle Tester!

Was euch erwartet

Hoffentlich ein funktionsfähiges Paket. 😉 Ich habe es mit Lintian erfolgreich geprüft, es lässt sich installieren, deinstallieren und upgraden. Obwohl ich so sorgfältig wie möglich vorgegangen bin, gibt es wie immer keine Garantie. Wer Spaß an der Blutigen Kante/Schneide hat darf zugreifen. Ich will hier aber nicht lesen müssen, dass ihr eure über Jahrzehnte gesammelte Arbeit verloren habt, weil ihr Mediathekview 3.0 ausprobieren wolltet und das Backup ja eigentlich um Mitternacht angelaufen wäre. 😈
Angst? Gut.
Das Paket ist fast „fertig“, es fehlen aber noch folgende Dinge (und ein geübter Blick eines Debianentwicklers):

  • Changelog. Es hat sich viel verändert. Ich kann aber noch kein abschließendes Changelog erstellen, da ich nicht mal weiß, ob das Paket überhaupt akzeptiert wird. Ich erstelle nun noch eine weiteres Paket in Version 2.6.1, das vermutlich größere Chancen hat den gestern erwähnten RC-Bug zu fixen. Das Paket hier wäre dann regulär für Unstable gedacht.
  • Menüicon. Ist immer noch das Icon aus Version 2.4 und skaliert leider nicht sehr schön. Wer eine Idee für ein gutaussehendes Icon hat…immer her damit.
  • Dokumentation. Gibt es auf der offiziellen Mediathekview-Seite. Da ich seit kurzem über Quellcode und PDF-Dokument der Kurzanleitung verfüge, kommt diese später noch nach /usr/share/doc/mediathekview.
  • Geänderte Empfehlungen. Ich habe die Empfehlungen leicht geändert. Flvstreamer ist weiterhin empfohlen. Jedoch gibt es nun für VLC und den Mplayer eine ODER-Bedingung. Die alte Empfehlung für mplayer-nogui habe ich entfernt, da es dieses Paket für Debian gar nicht gibt. (wohl aber bei deb-multimedia.org)

Wer noch eine Knobelaufgabe sucht, hier ist sie:
Mit Mediathekview lassen sich sogenannte Programmsets einrichten. Ihr könnt also zum Abspielen und Speichern jeweils separate Videoabspieler festlegen. Gesucht ist ein Befehl, mit dem es möglich ist rtmp- und mms-Streams direkt über Mplayer abzuspielen ohne Zusatzprogramme. Ich bin mit dem momentanen Standardset für Linux nicht zufrieden. Praktischerweise lassen diese Sets sich aber als XML-Datei exportieren und über die Projektseite herunterladen.
Wenn ihr also ein cooles Programmset habt, dass es ermöglicht mit Flvstreamer, VLC und Mplayer alle Videos abzuspielen und zu speichern, ist die Wahrscheinlichkeit groß, dass dies das neue Standardset wird. Behaupte ich einfach mal. 😉

Mediathekview 3 und Gnome 3

Mediathekview und Gnome3

Mediathekview 3.0: Bugs, Patches und Lösungen

In den letzten Wochen und Tagen habe ich versucht etwas Nützliches für Debian zu tun. Im Juni konnte ich noch meine Fehlerberichte der letzten Wochen vorstellen, die sich hauptsächlich mit den Spielen für meinen Spieleserver beschäftigten. Eine nicht ganz unlogische Schlussfolgerung war, wenn man sich intensiver mit einem Stück Software befasst, entdeckt man zwangsläufig Fehler.

LXAppearance

Dieser Binsenweisheit folgend meldete ich dann einige Wochen später einen Bug mit LXAppearance. LXAppearance ist meine bevorzugte Anwendung, wenn es darum geht das Icon- oder GTK-Thema meiner Fenstermanager-Lösungen auszutauschen. Im Regelfall kopiere ich ein neues Thema nach ~/.themes und neue Icons nach ~/.icons und wähle sie dann mit LXAppearance aus.
Mehr als merkwürdig war die Tatsache, dass LXAppearance immer dann abstürzte, wenn ich ein neues Icon-Thema installieren wollte. Da ich nicht jeden Tag das Aussehen des Desktops ändere, hat mich das bisher kaum gestört vor allem, weil das Thema trotz Absturz installiert worden war. Also erstellte ich einen Backtrace mit GDB und schickte ihn zusammen mit dem Core-Dump als Fehlerbericht #683146 zum Debian-BTS.

Aptitude

Es gibt Anwendungen, die man tagtäglich benutzt, aber von denen man dennoch gar nichts weiß. Ich probiere gerne neue Programme aus und so war es eines Tages an der Zeit mir Gnome-Packagekit näher anzuschauen. Ich bin mir sicher, dass die meisten Leser eher zu Konsolenwerkzeugen greifen und grafische Installationsprogramme verpönt sind. Gnome-Packagekit ist die Antwort der Gnome-Entwickler auf die Suche nach einer simplen, grafischen Anwendung, die Linuxpakete mit ein paar Mausklicks installieren und entfernen kann. Keine wirklich schlechte Sache, wenn man weniger technikaffinen Menschen Linux schmackhaft machen möchte.
Da ich wegen meines libcairo2-Problems (das übrigens nun gelöst ist, juhu) besagte Bibliothek mit Aptitude auf „hold“ gesetzt hatte, wunderte ich mich sehr, dass Gnome-Packagekit dennoch ein vollständiges Upgrade vornahm. Schon kurze Zeit später war der Fehlerbericht #683099 verfasst. Was ich dabei nicht bedacht hatte war, auch Aptitude konnte Schuld sein.
Tatsächlich benutzt Aptitude derzeit noch einen anderen Mechanismus, um Pakete auf „hold“ zu setzen, den apt-get nicht benutzen kann und umgekehrt. Da Gnome-Packagekit sich aber an Apt orientiert, führt das zu dem beschriebenen Fehler. Ich beneide den oder die derzeitigen Paketverwalter von Aptitude nicht. In der Vergangenheit wurden so viele Fehlerberichte gegen Aptitude verfasst, dass ich Probleme habe überhaupt noch die Übersicht zu behalten. Wäre ich der Maintainer von Aptitude, würde ich vermutlich zuerst einmal alle Fehlerberichte löschen und von Null anfangen. 😉

Mediathekview

Obwohl alle Fehlerberichte ihre Berechtigung hatten und ich versucht habe, so präzise wie möglich das Problem zu beschreiben, führte das nur in den wenigsten Fällen auch direkt zur Beseitigung des Problems.
Ich ging es also nun anders an. Anstatt Fehler zu melden, wollte ich jetzt nur noch Fehler lösen. Ihr denkt euer System sei fehlerfrei und nicht von schwerwiegenden Fehlern, sogenannten RC-Bugs, betroffen? Dann macht mal Folgendes:

aptitude install devscripts
rc-alert


Auf diese Art und Weise habe ich schließlich entdeckt, dass Mediathekview in einem kritischen Zustand ist. Ich habe noch nie einen Hehl daraus gemacht, dass ich von dem jetzigen Zustand des deutschen Fernsehens maßlos enttäuscht bin. Auf der anderen Seite bedeutet das nicht, dass ich Filme im Allgemeinen verabscheuen würde. Ganz im Gegenteil. Ich liebe Filme. Ich genieße Blair Witch Project genauso wie Frühstück bei Tiffany und Sieben, insbesondere wenn es gerade regnet, wenn man aus dem Kino kommt. 🙂 Mittlerweile substituiere ich die Zeit vor der Glotze mit Dingen wie Bloggen, was immer das auch sein mag.
Mediathekview war bisher mein Hilfsmittel, um nicht ganz den Anschluss an das aktuelle Fernsehprogramm zu verlieren. Natürlich gibt es Reportagen und Sendungen, die sehenswert sind und um das Auffinden dieser zu erleichtern gab und gibt es eben diese in Java geschriebene Anwendung.
Ich schaute mir also Fehlerbericht #681680 näher an. Scheinbar hinkt das Paket mittlerweile zwei Hauptveröffentlichungen hinterher. Der Fehlerbericht ist absolut zutreffend und würde dazu führen, dass Mediathekview aus Wheezy entfernt wird. Da ich also Interesse an dem Paket hatte, sah ich den Augenblick gekommen um an einem Patch zu arbeiten.
Sofort taten sich folgende Fragestellungen auf: Wie sollte ich das Problem angehen? Konnte ein kleiner Patch das bestehende Paket wieder funktionsfähig machen oder musste es ein vollständiges Upgrade auf die aktuelle Version 3.0 sein? Was war mit dem Paketverwalter los? Und wie gelangte der Patch schließlich in das offizielle Debian-Archiv?
Ich beschloss zuerst das Quellpaket herunterzuladen:

apt-get source mediathekview


Danach lernte ich Git und klonte das Mediathekview-3-Repo.
Nach vielen Fehlschlägen und vor allem viel Lesen, baute ich schließlich erfolgreich Version 3.0 mit Debian Sid.
Mediathekview3 mit Debian und VLC
Fortgeschrittene erkennen an dem Screenshot den neusten Fenstermanager, mit dem ich mich derzeit beschäftige. 🙂
Im Moment bin ich mit der Feinarbeit beschäftigt. Die Man-Seite auf den aktuellen Stand bringen, debian/control und debian/rules anpassen, Testen und viele weitere Kleinigkeiten verändern. Die Entwickler von Mediakthekview haben sogar einen Patch veröffentlicht, der es mit Version 2.6.1 ermöglicht, wieder automatisch Filmlisten herunterladen zu können. Nun muss ich ein Paket bauen, das möglichst wenig Veränderungen zur aktuellen Version aufweist, aber dennoch alle Bugs zufriedenstellend löst, damit es noch eine Chance hat in Debian Wheezy akzeptiert zu werden. Mehr dazu und anderen Unwichtigkeiten, bald ™. 😉

Keychain: Alternative zu Gnome-Keyring um SSH-Schlüssel zwischen Logins zu verwalten


An Gnome ist nicht alles schlecht. Das merkt man spätestens dann, wenn man sich näher mit der Situation von Archivmanagern wie Squeeze oder Xarchiver befasst und diese File-Roller gegenüberstellt. Ähnlich verhält es sich mit Gnome-Keyring und Seahorse. Beide Anwendungen vereinfachen das Verwalten von Passwörtern, GPG- und SSH-Schlüsseln enorm.
Die Kehrseite der Medaille ist, bei einer reinen Fenstermanager-Lösung oder bei LXDE werden viele Gnome-Bibliotheken und Ballast mitinstalliert.
Ich habe bisher noch keine perfekte leichtgewichtige Lösung gefunden, die alle meine Wünsche erfüllt. Insbesondere ist das automatische Entsperren aller Schlüssel im Schlüsselring von Gnome eine große Erleichterung, die ich in dieser Form vielleicht noch bei KDE vermute. Ein leichtgewichtiges Pendant zu Seahorse und Co., das aktiv betreut wird – Fehlanzeige.

Keychain

Ich habe mich mal wieder im Wiki von Arch Linux umgesehen und diesen Eintrag zum Thema SSH-Keys gefunden. Schließlich habe ich mich dafür entschieden mir Keychain näher anzusehen, eine in Shell-Skript geschriebene Anwendung, die meinen Anforderungen am besten gerecht wird.
Bisher sah mein Umgang mit SSH-Schlüsseln so aus. Zuerst wurden sie mit ssh-keygen erzeugt und wie im Artikel zur Absicherung des SSH-Servers beschrieben, dann entweder mit Hilfe von Gnome-Keyring in meinem Schlüsselbund dauerhaft gespeichert oder auf der Konsole mit ssh-agent und ssh-add für die Dauer einer Sitzung entsperrt.
Der Vorteil von SSH-Schlüsseln ist, sie verbessern nicht nur die Sicherheit, sondern sie sind auch bequem zu benutzen. Einmal entsperrt und man kann sich bequem ohne Passworteingabe zu einem entfernten Rechner verbinden.
Keychains Vorteil gegenüber der manuellen Methode ist, dass automatisch beim Einloggen in den Terminal ssh-agent und ssh-add ausgeführt werden. Üblicherweise muss man nach jedem Ab- und Anmelden und Wechsel der Sitzung den SSH-Schlüssel erneut entsperren. Mit Keychain startet ein dauerhafter Prozess des ssh-agent, der für jede neue Sitzung wiederverwendet wird. Das heißt, einmal entsperrt lässt sich der Schlüssel bis zum nächsten Reboot ohne weitere Passworteingabe benutzen.

keychain --quiet id_pc1_rsa id_pc2_rsa
[ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] &&
        . $HOME/.keychain/$HOSTNAME-sh
[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] &&
        . $HOME/.keychain/$HOSTNAME-sh-gpg

Dieser Code-Schnipsel wird entweder in der Datei ~/.bash_profile, oder wenn man ZSH benutzt in ~/.zshrc eingefügt. Keychain fügt automatisch die privaten SSH-Schlüssel id_pc1_rsa und id_pc2_rsa dem SSH-Agenten hinzu bzw. GnuPG-Agent, wenn dieser installiert sein sollte. Die Parameter für die laufende Sitzung werden standardmäßig in ~/.keychain/ gespeichert. Die Option –quiet sorgt noch dafür, dass nur Warnungen oder Fehlermeldungen ausgegeben werden, wenn man sich einloggt. Ansonsten würde eine ähnliche Meldung wie diese jedes Mal erscheinen.

* keychain 2.7.1 ~ http://www.funtoo.org
* Found existing ssh-agent: 2797
* Known ssh key: /home/apo/.ssh/id_pc1_rsa
* Known ssh key: /home/apo/.ssh/id_pc2_rsa

Fazit

Keychain ist eine leichtgewichtige Lösung um SSH-Schlüssel über Sitzungsgrenzen hinweg zu entsperren und bequem nutzen zu können. Auch für Cron-Jobs sicherlich eine nützliche Lösung. Das Handbuch man keychain ist empfehlenswert und informativ. Weitere Informationen gibt es wie immer in /usr/share/doc/keychain oder auf der Projektseite. Ich denke, der Gnome-Keyring und Seahorse sind weiterhin die bequemste Möglichkeit. Keychain ist für mich momentan jedoch ein sehr guter Ersatz auf einem leichtgewichtigen System.
Wie geht ihr mit dem Thema Passwörter und Schlüssel um?

Den Terminalmultiplexer GNU Screen im Solarized-Thema erstrahlen lassen

Hier ist eine kleine Notiz, wie man ganz einfach Anwendungen und die Shell in GNU Screen mit dem fantastischen Solarized-Thema aufpolieren kann. Die Lösung war schließlich ganz einfach, auch wenn ich zuerst gedacht hatte, es würde länger dauern das Problem zu lösen.
Bisher sahen Verzeichnisse und Dateien in Screen trotz meiner Umstellung auf „Solarized“ grau in grau aus.
rxvt-unicode ohne solarized
 
Ich fand schnell heraus, dass Screen einen eigenen Wert „screen“ für die $TERM-Variable hatte, der sich von meinem favorisierten Terminalemulator „rxvt-unicode-256color“ unterschied. In der ~/.screenrc lässt sich der Wert in der Theorie mit

term     rxvt-unicode-256color

ändern. Bei mir passierte jedoch nichts. Also warum nicht den Zustand akzeptieren und meine ZSH-Einstellungen in ~/.zshrc.local erweitern.

ZSH

if [ $TERM = rxvt-unicode-256color ] || [ $TERM = screen ]; then
        eval `dircolors $HOME/.dir_colors`
fi

Am Ende musste lediglich die if-Abfrage so erweitert werden, dass nicht nur in Rxvt-unicode-256color, sondern auch in Screen die Farbpalette Solarized geladen wurde.
 
rxvt-unicode mit solarized

Vim

Blieb nur noch Vim übrig. Hier ist die Syntax geringfügig anders. Um tatsächlich 256 Farben zu erhalten, muss t_Co auf 256 gesetzt werden, der Rest ist wieder nur eine Erweiterung der IF-Abfrage.

set t_Co=256
set background=dark
if (&term=="rxvt-unicode-256color" || &term=="screen")
        colorscheme solarized
endif

Danach erstrahlt sowohl der normale Terminalemulator als auch Screen in Solarized. Trivial. 🙂

SSH: Deaktivieren von StrictHostKeyChecking

Auf meinem Intel-Core-Duo-Rechner benutze ich verschiedene Betriebssysteme und betreibe ein Multiboot-System. Das hilft mir dabei Aufgaben und Software zu trennen, die ich nicht alle gemeinsam unter einem System installieren möchte.
Regelmäßig kommt es jedoch vor, dass ich mich per SSH von einem Laptop zu diesem Rechner verbinde oder Daten per scp austausche. Als vertrauenswürdiges Ziel habe ich dabei meine Debian-Testing-Installation mit Gnome 3 ausgewählt und den dortigen Host-Key zu meiner Datei ~/.ssh/known_hosts hinzugefügt.
Wechsele ich dann zu einem parallel installierten Betriebssystem, begrüßt mich diese Meldung hier.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

Der SSH-Klient macht hier alles richtig und warnt mich davor, dass die Identifikation des Rechners sich nun geändert hat. Das hat mich bisher nie richtig gestört. Entweder habe ich die Datei .ssh/known_hosts gelöscht oder mich von einem anderen Laptop eingeloggt, der diese Installation als vertrauenswürdig eingestuft hat.
Man kann aber auch das sogenannte StrictHostKeyChecking deaktivieren, indem man sich eine entsprechende Konfiguration in ~/.ssh/config anlegt. Prinzipiell würde ich nie auf die Idee kommen dieses Sicherheitsfeature auszuhebeln, insbesondere dann nicht, wenn ich mich im Internet zu einem entfernten Rechner verbinde. Mein Laptop und der Core Duo stehen jedoch nur wenige Meter auseinander und werden dazu oft noch per Kabel verbunden. Von daher ist das Risiko eines Man-in-the-Middle-Angriffs überschaubar.

Meine Lösung sieht nun so aus:
Ich habe die Datei ~/.ssh/config mit folgendem Inhalt angelegt.

Host loki
         StrictHostKeyChecking no
         UserKnownHostFile /dev/null

Wenn ich nun ssh loki eingebe, wird SSH diesen speziellen Host weniger streng prüfen und ich kann mich problemlos zum selben Rechner verbinden, selbst wenn sich das Betriebssystem geändert hat.
Anstatt loki lässt sich auch 192.168.1.207 schreiben und mit der Wildcard * sogar jeder Rechner von der strengen Überprüfung ausnehmen, was ich aber nicht empfehlen kann.
Eine weitere Möglichkeit bietet der Alias-Befehl.  z.B.

alias insecssh='ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"


Mit insecssh loki könnte man sich danach auch ohne Anlegen einer config-Datei zum entfernten Rechner verbinden.
Für die eigenen vier Wände ist das erst einmal ausreichend. 😉
Changelog:
01.09.2012 Alias insecssh der GRML-Konfiguration hinzugefügt.

snapshot.debian.org: Eine Zeitreise in die Vergangenheit des Debian-Archivs

Während meiner Experimente mit Debian Unstable, den Nvidia-Treibern und meinem Spielesystem habe ich als weitere Möglichkeit, neben Backports oder Upgrades auf experimentelle Pakete, einen sehr nützlichen Dienst von Debian in Anspruch genommen.

snapshot.debian.org

Dieser Service startete am 12. April 2010 und stellt eine Art Zeitmaschine dar, die es möglich macht alle Pakete seit 2005, die schon lange aus den aktuellen Repositorien verschwunden sind, erneut installieren zu können.
Am Beispiel des Grafikkartentreibers von Nvidia will ich kurz erklären, wie er funktioniert.

Paketsuche

Wenn ihr auf snapshot.debian.org steuert, lässt sich in der linken Navigationsspalte nach Quell- oder Binärpaketen suchen, die alle über den verlinkten Anfangsbuchstaben zu erreichen sind. In meinem Fall wollte ich eine ältere Version des Nvidia-Treibers ausprobieren, die weder in Wheezy noch in den Backports verfügbar war.
Nachdem man Kategorie n ausgewählt hat, befindet man sich auf einer Übersichtsseite aller Pakete mit Anfangsbuchstaben n. Aus dem Quellpaket nvidia-graphics-drivers werden die verschiedenen Binärpakete für Debian gebaut. Interessiert ihr euch für 275.36 seid ihr nur einen Klick vom Download der Quellen und der Binärpakete dieser speziellen Version entfernt.
Natürlich gibt es auch ein Suchfeld auf der Hauptseite, das die Suche etwas abkürzt, sofern man den exakten Namen des Pakets kennt.

Snapshot-Archiv in sources.list einbinden

Am interessantesten ist aber die Möglichkeit einen Snapshot des Archivs in die sources.list einzubinden und dann wie gewohnt mit apt-get oder aptitude Pakete zu installieren.
Neben den archivierten Paketen wird immer auch ein Link angeboten, der so aufgebaut ist, dass er anzeigt aus welchem ehemaligen Repo das Paket stammt (also z.B. Security, Backports, main, non-free, usw.) und sich dann in die sources.list mit dem vorangestellten deb einfügen lässt.

deb http://snapshot.debian.org/archive/debian/20111105T032915Z/ wheezy main contrib non-free

Der Snapshot stammt bei dem oben genannten Beispiel aus dem Jahr 2011 und wurde am 05.11. um 03.29 Uhr und 15 Sekunden Zulu-Zeit (UTC) archiviert. Wenn man nun die normale deb-Zeile deaktiviert hat, diese hier freischaltet und ein aptitude update macht, erscheint jene Fehlermeldung.

E: Release file for http://snapshot.debian.org/archive/debian/20111105T032915Z/dists/wheezy/InRelease is expired (invalid since 261d 16h 13min 14s). Updates for this repository will not be applied.

Hier wird signalisiert, dass die Pakete veraltet sind, weswegen Apt ein Update des Paketcaches verhindern will. Damit es trotzdem funktioniert, lässt sich Apt folgendermaßen belehren.
aptitude -o Acquire::Check-Valid-Until=false update
Danach lassen sich die älteren Pakete wie gewohnt installieren.

archive.debian.org

Noch ein kleiner Tipp. Wer auf der Suche nach der ganz alten Debian-Veröffentlichung ist, sollte archive.debian.org einen Besuch abstatten.

Gegen die Feuerwand: Mal wieder DRDoS-Attacke auf OpenArena-Server

Seit ein paar Tagen wird mein OpenArena-Server erneut mit einer sogenannten DRDoS-Attacke überzogen. Der oder die Angreifer senden dabei gefälschte IP-Pakete mit Hilfe von Spoofing an den Server, damit dieser wiederum Statusanfragen an Webserver und ähnliche Dienste weiterleitet, deren Kapazitäten irgendwann nicht mehr ausreichen, um die gerechtfertigten Anfragen zu beantworten.
Mit iftop sieht das im Moment so aus:

Ich bin mir nicht sicher, ob das Ganze überhaupt durchdacht worden ist, momentan rauscht einfach alles in die Firewall. Es wird nicht einmal geprüft, ob der Server verwundbar ist, sondern einfach stur immer die gleichen Anfragen geschickt. Dass die Attacke somit sehr ineffizient ist, scheint niemanden zu stören.
Ich bin mit dem Server einen Port weitergezogen, um irgendeine negative Auswirkung auf das Spielerlebnis auszuschließen. Die beim letzten Mal erstellten Firewallregeln und der gepatchte Server haben zuvor ihr Übriges getan.
Da zwar sehr viele Anfragen hereinkommen, jedoch keine beantwortet wird, kann man diesen Umstand wunderbar mit vnstat beobachten. Normalerweise ist der Wert des TX-Graphen (grau) größer als der RX-Graph (grün).
Vnstat-stündlicher-Netzwerkverkehr
Vnstat-täglicher-Netzwerkverkehr
Letztes Mal hat es knapp zwei Wochen gedauert bis der Spuk vorbei war. Mal schaun wie lange es dieses Mal dauert.

Upgrade auf Debian Wheezy: Toshiba Portégé 3110CT Pentium II 300 MHz mit 64 MB RAM

Zur Zeit verwende ich einen meiner ältesten Laptops, den Toshiba Portégé 3110CT zum Debuggen des OpenArena-Servers. Ich war es leid die ganzen Tests auf meinem Live-Server durchzuführen. Während ich die aktuelle Testing-Version 0.8.8-5 von OpenArena einspielte, kam mir die Idee gleich das ganze System auf Wheezy upzugraden.
Nach wie vor war auf dem Laptop aus dem Jahr 1999 Debian Squeeze in Betrieb gewesen, welches ich im Jahr 2010 zusammen mit Fluxbox und mit Hilfe von CD-ROM und PEX installiert hatte. Zusammen mit den üblichen Verdächtigen, Software ohne und mit X, verrichtete er bisher auch klaglos seine Arbeit. Ich benutze ihn immer noch hauptsächlich als Heimserver, da man ihm hier seine 64 MB Arbeitsspeicher selten anmerkt.

Eine Weile hatte ich auch überlegt Squeeze gegen ein anderes Betriebssystem wie Slitaz oder gar CRUX auszutauschen, die Überlegung jedoch schnell wieder verworfen, da es schlicht funktionierte. Ja, man darf Distro-Hopping auch mal widerstehen. 🙂
Zusätzlich ist es in den letzten zwei Jahren schwieriger geworden ein neues Betriebssystem via CD-ROM-Laufwerk zu installieren. Ich bin mir nicht sicher, ob man das früher bei vergleichbaren Subnotebooks von Toshiba jedes Mal machen musste, bei meinem durfte ich zumindest immer eine Tastenkombination (ich glaube es war CTRL+c) beim Starten drücken, damit vom CD-ROM-Laufwerk gelesen und gebootet werden konnte. Das scheint nun alles hinfällig zu sein, das CD-ROM-Laufwerk möchte nicht mehr und großen Bedarf für eine PEX-Installation habe ich auch nicht.
Wozu also in die Ferne schweifen, wenn ich Debian Squeeze durch ein Dist-Upgrade in Debian Wheezy verwandeln konnte? Nachdem ich die Quellen auf Wheezy umgeändert hatte, installierte ich zuerst apt und aptitude aus dem Wheezy-Repo. Prinzipiell, aber gerade auch wegen Multiarch, macht es Sinn hier zuerst gezielt ein Upgrade zu machen, damit der Paketmanager später alle Konflikte sauber auflösen kann. Dann folgte nur noch

aptitude full-upgrade


Das Problem bei jedem Dist-Upgrade scheint zu sein, dass neue Pakete installiert werden sollen, die man nicht unbedingt haben wollte. Nach dem Upgrade hatte ich unter anderem PolicyKit, ConsoleKit, ein paar Gnome3-Werkzeuge und -Bibliotheken zusätzlich installiert, die ich nicht gebrauchen konnte. Dieses Dilemma lässt sich umgehen, indem gezielt einzelne Pakete erneuert werden oder man entfernt schon vorher überflüssige Pakete, die neue Abhängigkeiten in das System einfließen lassen.
Man kann natürlich auch später Debian erneut auf minimal stutzen und den Aufräumtipps folgen und schon ist das System wieder in dem gewohnt schlanken Zustand. Mir hat sowohl Deborphan als auch Debfoster wieder einmal geholfen.
Weitere Überraschungen gab es danach keine mehr, weshalb ich mich nun einfach über weitere zwei Jahre mit Debian auf dem Toshiba freue und alle Finger kreuze, dass die Hardware weiterhin intakt bleibt. 🙂

Hier sieht man die aktuelle RAM-Auslastung und die Last auf dem Server. Ich vermute gdb ist daran Schuld, dass letztere um die 1.0 pendelt. Im Spiel selbst merkt man nichts davon.
Htop-Anzeige von Speedy
Der OpenArena-Server funktioniert in der Tat ziemlich gut auf dem Rechner. „Leider“ muss ich dazusagen, denn ich möchte ja, dass er abstürzt und die Ergebnisse auf dem Live-System bestätigt. 🙂
Bisher verfolge ich zwei Bugs #664637 und #681812. Letzterer lässt sich zu 100% reproduzieren, einen Backtrace mit dem GNU Debugger habe ich auch schon erstellt. Der erste Bug ist z.Z das Problem, da er mit der aktuellen OpenArena-Version nur noch sehr selten auftritt und er sich nicht gezielt auslösen lässt.
Ich verzichte an dieser Stelle auf einen Bericht meiner zahllosen gescheiterten Versuch einen Core-Dump des Servers zu erstellen. Erst nachdem ich ihn lokal getestet habe und er mit Root-Rechten läuft (böse, ich weiß), konnte ich für #681812 innerhalb von gdb mit dem Befehl generate-core-file diese Datei erzeugen, die immerhin 165 MB groß ist. Weitere Details spare ich mir, weil ich selbst noch dabei bin mich mit der Materie vertraut zu machen und Debuggen nun wirklich nicht den gleichen Spannungsfaktor wie ein guter Krimi hat. Sagte Nuff.