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à. 🙂

Wbar: Bericht von der Entwicklung einer neuen Debian-Version der leichten Schnellstartleiste

Irgendwie hat mich in den letzten Wochen die Lust am Paketeerstellen für Debian gepackt. Während MediathekView gut vorankommt und ich noch auf das Feedback eines Debianentwicklers warte, der sich das Paket gerade ansieht, sitze ich hier an Version 2.3.0. der "Warlock Bar", auch kurz Wbar genannt.
Die Frage, die man sich nicht nur bei Debian manchmal stellt: "Wie findet man den richtigen Einstieg?". Ich wendete mich schnell der FAQ der Debian-Mentoren zu. Entgegen allen Gerüchten ist Debian gar kein ganz so elitärer Haufen, der sich gerne gegenüber der Außenwelt abschottet. Für Newbies im Paketeerstellen gibt es Freiwillige, die sich den Fragen angehender Paketverwalter stellen, sei es auf der Mailingliste debian-mentors oder im gleichnamigen IRC-Channel #debian-mentors im OFTC.net.
Von dort gelangte ich auf die Übersichtsseite der Arbeit-bedürfenden und voraussichtlichen Pakete, in Englisch kurz wnpp genannt.
Schnell sieht man hier, dass ca. 600 Pakete auf einen Nachfolger als Paketverwalter warten und die Mehrzahl davon sogar verwaist ist. Hier kümmert sich außer dem QA-Team niemand mehr darum. Irgendwann blieb mein Blick dann an wbar kleben, da mir der Name bekannt vorkam. Im Jahr 2009 bin ich zum ersten Mal auf diese leichtgewichtige Anwendung gestoßen und habe sie dann 2010 als Schnellstartleiste für Fluxbox auf dem Toshiba Portégé 3110CT installiert.
Wieder zwei Jahre später schließt sich der Kreis. Denn genau diese Version, die ich damals benutzt habe, ist auch heute noch die aktuellste. Leider. Zum einen gab es erst wieder 2011 ein paar Neuerungen des neuen Entwicklers zu vermelden, der das Projekt übernommen hatte und schließlich fehlte dem Paketverwalter die Zeit, um das Paket weiter zu betreuen. Wir schreiben Juni 2012 und wbar wird als "verwaist" markiert.
Also dachte ich, wäre es eine coole Idee ein leichtgewichtiges Programm zu betreuen, dass immer noch auf einem der älteren Laptops läuft, aber von niemandem mehr gewartet wird!

Wbar 2.3.0 - Neuigkeiten aus dem Changelog

Da Details zur Paketerstellung erfahrungsgemäß keine Begeisterungsstürme unter den Lesern dieses Blogs entfachen, fasse ich mich kurz, verweise auf das Changelog im Quellpaket, dass ich gleich verlinke und lasse später einfach Bilder sprechen.

  1. Es gibt eine neue Veröffentlichung! Version 2.3.0 ausgecheckt aus dem Subversion-Repo am 16.08.2012 ist meine aktuelle Arbeitsversion.
  2. Die Konfiguration findet nun ordnungsgemäß global unter /etc statt und nicht mehr unter /usr/share/wbar. Die Bearbeitung von ~/.wbar ist weiterhin für den lokalen Benutzer möglich.
  3. Es gibt ein neues grafisches Programm namens wbar-config, das die Konfiguration und Gestaltung von wbar sehr vereinfacht, aber vollkommen optional ist.
  4. Das Paket wird mit LDFLAGS=Wl, --as-needed gebaut, wodurch überflüssige Abhängigkeiten wegfallen, was sicher nicht nur Fans von leichtgewichtigen Desktops freuen dürfte.
  5. Das Paket ist gehärtet.
  6. Alle empfohlenen Abhängigkeiten sind jetzt nur noch vorgeschlagen. Auch das hält den Rechner schlank. Ob es dabei bleibt, hängt aber von einer Lizenzfrage ab.
  7. Des Weiteren habe ich noch einige Tippfehler und Sprachunebenheiten ausgebessert (und mich dabei hoffentlich nicht selbst in die Nesseln gesetzt *schluck*).

Offene Baustellen sind momentan keine technischen Probleme, sondern ausschließlich Lizenzfragen. Aufmerksamen Menschen fällt der Zusatz "+dfsg2" am offiziellen Debianpaket auf. Das bedeutet, dass das Quellpaket der Entwickler schon zwei Mal "umgepackt" werden musste, um den Richtlinien für Debian und für Freie Software zu genügen. Konkret geht es darum, dass damals offensichtlich Icons aus dem bekannten MacOS-Dock für Wbar benutzt worden sind. Da diese aber unfrei sind, können sie mit Debian nicht vertrieben werden.
Ich stehe nun vor ähnlichen Problem. Zum einen liegt dem Quellpaket eine COPYRIGHT-Datei bei, worin die GPL-3-Lizenz enthalten ist. Die Projektseite genauso wie das alte Paket stellen jedoch klar, dass der Code unter GPL-2 steht. Im Prinzip kein Problem, da es maximal zwei Entwickler gibt, die frei entscheiden können, ob sie neuere Versionen nun unter GPL-3 oder weiterhin GPL-2 verfügbar machen. Welche von beiden es aber ist bleibt unklar.
Die zweite Sache sind die Icons. Das alte Verzeichnis mit den "Mac"-Icons gibt es mittlerweile nur noch im SVN. Neu hinzugekommen sind die Icons im "pixmaps"-Ordner. Eine gute Gelegenheit mal ein Bildschirmfoto von der aktuellen wbar-Version zu zeigen, so wie sie auf meinem angepassten Lubuntu läuft.
wbar 2.3.0
Mal von links nach rechts betrachtet: Das erste Symbol ist für wbar-config gedacht und ich ordne es optimistischerweise den Entwicklern zu. Dann kommt Pidgin und Anjuta. Anjuta steht unter der GPL-2, Pidgin ist ebenfalls ein freies Programm. Das nächste Symbol sieht lustig aus, ist aber nicht das offizielle Logo von Bluefish, dem Editor. Woher kommt es? Ok, den Gimp hat sicherlich jeder erkannt. OpenOffice, oha. "Bitte beachten Sie, dass das Logo nicht unter einer freien Lizenz steht. Und zum Schluss stehen da noch Synaptic und ein typisches Terminal-Symbol. Keine Ahnung, wer sie erstellt hat.
Also wenn es gut läuft, kann ich bis auf zwei Symbole alle zuordnen und die passende Lizenz finden und den ursprünglichen Rechteinhaber ausfindig machen. Da die Entwickler aber jederzeit diese Symbole auch wieder ersetzen können, fahre ich fast besser damit, einfach wieder das Paket gnome-extra-icons zu empfehlen, dass nachweislich nur freie Symbole enthält.
Beim Schreiben des Artikels ist mir dieser alte Screenshot von 2009 aufgefallen. Hier sieht man noch die Version von Wbar mit den unfreien Symbolen, bevor diese vom damaligen Paketverwalter entfernt worden sind. Das ist übrigens Fluxbox und Conky.


Das zweite Bild zeigt wiederum die aktuellen Symbole in der Version 1.3.3 von Wbar.

Fluxbox und Wbar
Ich habe die Entwickler angeschrieben und bin mal gespannt, ob es eine Antwort geben wird. Wie gesagt, es gibt Alternativen bei dem Lizenzproblem und technisch scheint das Paket gut zu funktionieren. Wer es ausprobieren will....ihr kennt den Spruch.
Update 28.09.2012:
- Neue Version 2.3.4 online
Update 10.01.2013
Ein offizieller Upload scheint nicht mehr weit entfernt. Die Downloadlinks werden deshalb in nächster Zeit ins Leere führen. Bitte benutzt dann die offizielle Version.

Quellpaket 2.3.4

dget -x ftp://46.182.19.209/debian/pool/main/w/wbar/wbar_2.3.4-1.dsc

Binärpaket wbar-2.3.4

i386
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar_2.3.4-1_i386.deb
amd64
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar_2.3.4-1_amd64.deb

Binärpaket wbar-config-2.3.4

i386
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar-config_2.3.4-1_i386.deb
amd64
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar-config_2.3.4-1_amd64.deb
Hier ist der aktuelle ITA-Bug von Wbar, #678865, der den aktuellen Stand dokumentiert.
Und noch ein erster Eindruck von wbar-config.

wbar-config 2.3.0
Die Rätselfrage wie gewohnt zum Schluss: Welche Schriftdatei ist standardmäßig in jeder Debianinstallation enthalten, damit ich von Wbar darauf verweisen kann, ohne Gefahr laufen zu müssen, dass sie doch nicht existiert? 😉

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 ™. 😉

Ich weiß, was du diesen Sommer getan hast: Fujitsu Siemens Lifebook E8020

Nur zur Beruhigung ich musste niemanden überfahren, um in den Besitz dieses Notebooks aus dem Jahr 2005 zu gelangen. Wie es der Zufall so will, habe ich letzte Woche etwas Urlaubsvertretung für einen Freund gespielt, nach dem Rechten geschaut und IT-Probleme gelöst. Also genau das, was ich sonst auch tue. :mrgreen:

Fujitsu Siemens Lifebook E8020
Neben allerlei Schlüsseln gab es auch dieses nützliche Fujitsu Siemens Lifebook E8020 gratis dazu. Leider nur für eine Woche. 🙁
Natürlich brauchte ich noch Kontaktdaten, Telefonnummern, E-Mail-Adressen und vor allem Passwörter. Anstatt die gesamte Firmendatenbank auf einen meiner Laptops zu überspielen, kamen wir auf die brillante Idee alles Notwendige auf den E8020 zu kopieren, wo die Daten Dank Festplattenverschlüsselung sicher verwahrt waren. Mit welchem Betriebssystem wir das bewerkstelligt haben?

Debian Squeeze mit Gnome 2

Keine wirkliche Überraschung oder? 😉 Die schnellste Lösung war ein Standard-Squeeze mit Gnome 2 zu installieren, auf dem die wichtigsten Programme liefen, die man für eine solche Sommeraufgabe gebrauchen konnte.
Debian Squeeze mit Gnome 2
Zum einen war da Iceweasel, was zur Internetrecherche wie gerufen kam und mit dem sich auch E-Mails mit Hilfe der Open-Source-Webmail-Software Roundcube abrufen ließ. Wandle die eingehenden Anrufe in Voice-Mails mit MP3-Anhang um und sende sie an den Webmail-Account und schon ist man über alle Katastrophen sofort im Bilde, sofern die Nachricht z.B. mit Totem akustisch entschlüsselt wird.
Kontaktdaten und Adressen sind in Datenbanken gespeichert, deren wichtigste Informationen sich auch in Textdateien speichern lassen. Benutze Nautilus, Texteditor der Wahl oder greife direkt auf das Gnome-Terminal zurück und in Windeseile sind alle wichtigen Stichpunkte und Ereignisse niedergeschrieben.
Die Standardpalette an Gnome-Anwendungen war ausreichend, um die Woche zu überbrücken, auch wenn ich keine Root-Rechte hatte und gerne noch den ein oder anderen Favoriten installiert hätte.

Fujitsu Siemens Lifebook E8020

Als ich den Laptop hier so rumstehen hatte, kam mir die Idee, die Gunst der Stunde zu nutzen und kurz die wichtigsten Kennwerte dieses leicht ergrauten Laptops vorzustellen.

Gut gefiel mir

  • Der helle, matte und große Bildschirm mit XGA-Auflösung.
  • Die vielen USB-Anschlüsse.

Nicht so toll war

  • Die Tastatur. Für meinen Geschmack zu "weich". Es gab keinen richtigen Druckpunkt. Überhaupt nicht mit dem Thinkpad 600 oder dem Dell Inspiron 4000 zu vergleichen, womit sich einfach gut tippen lässt.

Wie zu erwarten war, lag die theoretische Performance deutlich über meinen ansonsten so wertgeschätzten Oldies.

Kennwerte

lspci -vv sagt:

  • Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) | Kernel driver: agpgart-intel
  • VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00 [VGA controller]) | Kernel driver: i915
  • Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) | Kernel driver: hda-intel
  • PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode]) | Kernel driver: pcieport
  • USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI]) | Kernel driver: uhci_hcd
  • USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) (prog-if 20 [EHCI]) | Kernel driver: ehci_hcd
  • IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04) (prog-if 8a [Master SecP PriP]) | Kernel driver: ata_piix
  • SATA controller: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) (prog-if 01 [AHCI 1.0]) | Kernel driver: ahci
  • SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) | Kernel driver: i801_smbus
  • Ethernet controller: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11) | Kernel driver: tg3
  • CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 20) | Kernel driver: yenta_cardbus
  • SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller Subsystem: Fujitsu Limited. Device 131e | Kernel driver: sdhci-pci
  • Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05) | Kernel driver: ipw2200
  • FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) | Kernel driver: firewire_ohci

Wie man sieht, das Notebook wird sehr gut durch Linux unterstützt. Mit insgesamt 1 GB RAM, einer 40 GB Festplatte und einer Intel-Pentium-M-760-CPU mit 1,86 GHz getaktet, konnte absolut nichts schiefgehen. Dazu hielt der Akku noch weit über 4 Stunden. Nicht schlecht.
Insgesamt also ein solider Laptop für unterwegs, der zwar nicht ganz leicht ist (ca. 3kg), dafür aber gerade dann punktet, wenn man einen mobilen Rechenknecht sucht, den nichts so leicht aus der Bahn wirft und der Dank seiner vielen Anschlüsse sich immer noch für Präsentationen oder als "Hub" für diverse USB-Festplatten eignet. 🙂

Meine Woche mit Linux, Spielen und Musik: Limbo, Humble Music Bundle, ScummVM 1.5, Warsow 1.0 und Tryst

Mal ein paar Neuigkeiten aus der Welt der Linuxspiele. Jeder einzelne Artikel wäre zu kurz geraten, deswegen gibt es heute ein Potpourri an Themen zum Thema Spiele und Linux.

Limbo

Ja, Limbo, war das nicht schon im letzten Humble Indie Bundle V enthalten? Richtig. Damals hatte ich es mir schon als "spielenswert" herausgepickt und mich danach auf den Weg gemacht, um die düstere Welt eines kleinen Jungen zu erkunden. Da ich nicht zu viel spoilern will, sei hier nur gesagt, dass ich nicht einmal im Verlauf des Spiels gestorben bin und alle fiesen Fallen der Programmierer mit Hilfe der Matrix locker umgangen habe. (Was man nicht sehen kann, sind die Finger, die ich hinter meinem Rücken kreuze.)
Nein ehrlich, das Spiel ist von der Stimmung und Atmosphäre her sehr gelungen. Die Steuerung ist einfach zu erlernen, jedoch wird man praktisch ins kalte Wasser oder besser den Wald geworfen. Warum und wieso und wie es weitergeht, erfährt man durch das Ausprobieren des Spiels, was ich persönlich sehr spannend fand. Wer vollkommen in diese dunkle Fantasie eintauchen möchte, genug Geistige Gesundheit und Stabilitätspunkte auf dem Konto und keine Arachnophobie hat, dem kann ich das Spiel auf jeden Fall empfehlen. Linuxtechnisch ließ sich das Spiel unter Debian problemlos installieren. Es liegt aber nicht nativ vor, sondern wird mit Hilfe von Wine gespielt, dass im Deb-Paket von Limbo integriert wurde.
Limbo

Humble Music Bundle

Seit knapp einer Woche gibt es nun wieder was Neues von den Jungs und Mädels, die das Humble-Bundle-Projekt regelmäßig wieder auf die Beine stellen. Dieses Mal stehen keine Spiele, sondern Musik im Vordergrund. Sechs drm-freie Alben warten darauf gehört zu werden. Zumindest Christopher Tin, dessen Album Calling all Dawns im Bundle enthalten ist, scheint noch gewisse Probleme mit dem Begriff Linux zu haben: "Ehm Linux whatever that is."
Die Musik ist zwar nicht wirklich frei, jedoch bietet sich wie gehabt die Möglichkeit so viel zu bezahlen, wie man selbst für angemessen hält und wie bisher werden gemeinnützige Organisationen und natürlich die Künstler davon unterstützt.

ScummVM 1.5 erschienen

ScummVM
Auf holarse-linuxgaming.de habe ich zum ersten Mal vom neuen Release 1.5 "Picnic Basket" von ScummVM gelesen. Neben zwölf neu unterstützten Spielen gibt es dazu auch die passende neue Engine und eine Reihe von Fehlerbehebungen. ScummVM ist unter anderem jetzt auch auf dem Nokia 770 Tablet spielbar, dass mit Maemo betrieben wird. Dass ich ein großer Fan von ScummVM bin, hatte ich anderer Stelle schon einmal durchscheinen lassen. 🙂

Warsow 1.0

Nach sieben Jahren in der Betaphase wurde Warsow nun endlich in Version 1.0 veröffentlicht. Ich hatte es vor kurzem neben anderen bekannten FOSS-Spielen vorgestellt. Es hätte mit Sicherheit einen Platz auf meinem Server gefunden, wenn das Spiel nicht aus Wheezy entfernt worden wäre, da niemand sich um die Beseitigung der Bugs gekümmert hat. Es gibt mittlerweile Bestrebungen den Titel für Jessie auf Hochglanz zu bringen. Das Paket befindet sich auch weiterhin mit einer veralteten Version in Debian Unstable. Ich denke nach der Veröffentlichung von Wheezy wird es hier weitergehen und vielleicht sieht man es dann irgendwann auch auf linuxiuvat.de

Tryst

Auch zum Spieletitel Tryst gab es bei Holarse einen netten Artikel. Hierbei handelt es sich um ein Echtzeitstrategiespiel von BlueGiant Interactive. Auf einem fremden Planeten streiten Menschen und Aliens um die Vorherrschaft über Ressourcen. So weit so bekannt. Die Grafik ist Dank der Unigine Engine auf hohem Niveau. Interessanter als diese ist natürlich das Gameplay, was einen Kampf von bis zu 8 Spielern im Mehrspielermodus verspricht und mit Spezialfähigkeiten für jede Einheit wirbt. Optisch sieht es für mich auf den ersten Blick ein wenig nach Starcraft II aus, dass sich mit Wine auch unter Linux spielen lässt.
Das Beste von allem aber: Das Spiel wird laut diesem Forenbeitrag nach der Veröffentlichung auch für Linux nativ erscheinen. Ich bin gespannt.

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.