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?

Dwb und Jumanji: Zwei Webkit-Browser mit vi-ähnlicher Steuerung

Letzte Woche hat mich Georg auf einen interessanten Webkit-Browser namens Jumanji aufmerksam gemacht. Ich ergreife hier die Gelegenheit und stelle sowohl Jumanji als auch Dwb kurz vor. Beide setzen auf die Webkit-Engine und eine vi-ähnliche Steuerung und eignen sich als leichtgewichtige Browser-Alternative nicht nur für ältere Rechner.
Die Bilder stammen alle von meiner ArchLinux-Installation auf dem Inspiron 4000.

Jumanji

Jumanji ist ein minimalistischer WebKit-Browser, dessen Interface schlicht und platzsparend und deswegen auch sehr übersichtlich ist.


Die Bedienung lässt sich tatsächlich mit dem Stichwort vi-ähnlich auf den Punkt bringen. Genauso wie bei seinem berühmten Vorbild betritt man mit dem Doppelpunkt den Kommandomodus und kann von dort diverse Befehle aufrufen. Besonders praktisch ist es mit Hilfe von Tab-Vervollständigung von Befehl zu Befehl zu wechseln. Noch schneller geht es nur noch mit Tastenkürzeln, die man wie bei vi durch das “:map“-Kommando definieren kann.

Neue Tabs öffnet man entweder mit :tabopen oder mit der Taste t. Sie erscheinen in dezentem schwarz hinterlegt am oberen Bildschirmrand. Aktive erkennt man durch die geänderte Schriftfarbe. Interessant ist auch, dass man durch den Browserverlauf mit Tab-Vervollständigung navigieren kann. Mit der rechten Maustaste lässt sich ein kleines Menü aufrufen, um die Seite neu zu laden oder vor- und zurück zu wechseln.

Jumanji lässt sich bei Arch Linux aus dem AUR installieren. Wer yaourt benutzt, erledigt das mit:

yaourt -S jumanji-git


P.S.: Als Randnotiz fiel mir noch der Webseitengenerator der offiziellen Jumanji-Homepage auf. Hakyll ist eine Haskell-Bibliothek, um statische Webseiten zu generieren. Nur falls jemand dachte, es gäbe keine weiteren Alternativen zu den schon im Artikel und Kommentaren genannten Blogkompilierern. 🙂

Dwb

Im Gegensatz zu Jumanji existiert von Dwb seit kurzem eine offizielle Debianversion in Sid und Wheezy.

Dwb basiert ebenfalls auf der Webkit-Engine, besitzt vi-ähnliche Tastaturkürzel und Kommandos und zeichnet sich durch eine ebenso schlanke und effiziente Benutzerschnittstelle aus. Tatsächlich ähneln sich Jumanji und Dwb in vielerlei Hinsicht.
Der große Unterschied ist jedoch, Dwb hat das Konzept schon deutlich weiter entwickelt. Er ist umfangreicher, bietet mehr Kommandos und Funktionen. Genauso wie bei Jumanji lässt sich ein Adblock-Skript einbinden, darüber hinaus besteht aber auch die Möglichkeit Javascript oder Flash zu blockieren. Neue Tabs lassen sich mit O öffnen und d schließen. Lesezeichen werden mit M hinzugefügt und übersichtlich mit gB angezeigt und in einem neuen Tab geöffnet. Links kann per Tastatur gefolgt werden.
Besonders erwähnenswert ist auch, dass sich Einstellungen und Optionen auf einer Extraseite innerhalb des Browsers konfigurieren lassen und die Dokumentation in einem guten Zustand ist. Die Handbuchseite ist vorbildlich.


Die Suche funktioniert genauso wie bei Vi/Vim, indem die Taste / benutzt, der Suchbegriff eingegeben und schließlich n zur Vorwärtssuche ausgeführt wird.

Fazit

Mir gefallen tastaturgesteuerte, leichtgewichtige Webbrowser. Dwb hat bei mir aber gegenüber Jumanji die Nase vorn. Beide ähneln stark dem Vimperator-Plugin des Firefox, setzen aber stattdessen auf die Webkit-Engine und ordnen sich in die Reihe von Webbrowsern wie Vimprobable, Uzbl oder Surf ein.
Webkit-Browser sind nicht wirklich ungewöhnlich, was für die Engine spricht.
Der Speicherverbrauch und auch die Reaktionsgeschwindigkeit lässt sich am besten mit der von Surf vergleichen. Wie im letzten Test, habe ich wieder ps_mem.py als Maßstab benutzt.

Jumanji:
Private: 19MB + Shared: 1,3MB = 20,3MB
Dwb:
Private: 21,1MB + Shared: 2MB = 23,1MB

Die Startzeiten waren sogar noch schneller als bei Surf, obwohl das auch an dem selbstkompilierten ArchLinux-Paket liegen kann. Für die Zukunft werde ich dwb häufiger benutzen und denke, dass es eine gute Wahl war ihn in Debian aufzunehmen, da er sich durch seine umfangreiche vi-ähnliche Steuerung von den anderen Browsern in Debian positiv unterscheidet.

OS-tan: Mein verpasstes Internetphänomen

Scheinbar habe ich OS-tan vor einigen Jahren als Internethype verpasst, obwohl er sich bis heute wohl an verschiedenen Stellen fortsetzen soll und immer neue Kreationen hinzukommen. Kurz zusammengefasst ist OS-tan ein ursprünglich japanisches Phänomen, bei dem Betriebssysteme in Form von äußerst niedlichen Manga- und Animefiguren dargestellt werden und deren menschliche Eigenschaften die Stärken und Schwächen der Betriebssysteme symbolisieren sollen. Auf tomodachi.de findet sich ein interessanter und anschaulicher Artikel zu dem Thema.
Durch die Wunder des Internet bin ich nun nach all den Jahren auf diesen Begriff aufmerksam geworden. Danke K.Mandla. Sein kurzer Post aus dem Jahr 2007 hat mich auf die Seite von Jozu-kun, einer italienischen Künstlerin, gebracht, die eben diese OS-tans für Linuxdistributionen gestaltet hat.
Ich denke die Bilder sprechen für sich. Weitere Hintergrundbilder in besserer Qualität finden sich auf ihrer Desktop-Seite. Ist Debian wirklich so seriös? 🙂
Lizenz der Bilder: by-nc von Jozu-kun

Arch Linux

Debian

RedHat

Ubuntu

ConnochaetOS: Neue Software mit PKGBUILD selbst kompilieren

Ein Nachteil bei kleineren Linuxdistributionen ist, dass sie oftmals auf nur wenige Entwickler zurückgreifen können. Außerdem sind Webspace, Traffic und Zeit begrenzt und es fehlt einfach an Ressourcen, um jede verfügbare Software in einem Binärformat bereitstellen zu können.
Man kann dieses Problem in der Regel umgehen, indem man Werkzeuge wie Debians Alien oder Slitaz tazpkg benutzt, um Pakete fremder Distributionen in das eigene Format umzuwandeln. Das klappt bei kleineren Paketen oft sehr gut, man darf aber aber auch keine Wunder von so einer Transformation erwarten.
Bei Arch Linux und damit auch ConnochaetOS macht es keinen Sinn fremde Pakete umzuwandeln. Benutzer von Arch Linux werden mir sicher zustimmen, dass das Erstellen eigener Archpakete mit Hilfe von makepkg und dem Arch Build System(ABS) eine unkomplizierte Sache ist.
Um Pakete für ConnochaetOS zu bauen, empfand ich es am einfachsten mir das ABS zu installieren und die dort bereitgestellten PKGBUILDs an meine Bedürfnisse anzupassen.

pacman -S abs
pacman -S base-devel

Führt man danach als Benutzer root abs in einem Terminal aus, wird das Verzeichnis /var/abs mit den PKGBUILDs der verschiedenen Repos core, extra und community gefüllt. Die PKGBUILDs der Software befinden sich im namensgleichen Verzeichnis, welches nur noch auf den Rechner mit ConnochaetOS kopiert werden muss oder auch gleich an Ort und Stelle benutzt werden kann.
In meinem Fall wollte ich drei meiner Favoriten mtPaint, Irssi und C* Music Player für die i586 Architektur und ConnochaetOS übersetzen. Dazu genügt es, das sogenannte ARCH-Feld um den Eintrag ‘i586’ zu erweitern.
Für Irssi war das schon der einzige Trick. Mit

makepkg -s

im Verzeichnis, wo auch das PKGBUILD liegt, konnte ich dann das Paket kompilieren und mit

pacman -U Name_des_Pakets.tar.xz

installieren.
Beim C* Music Player alias cmus brauchte ich hingegen noch die Bibliothek libao und musste libpulse und libmpg als Abhängigkeiten streichen. Auf dem Thinkpad 600 benutze ich sowieso ausschließlich ALSA.
Für mtPaint wurde noch die Bibliothek lcms2 benötigt, die ich zum erfolgreichen Kompilieren zuerst übersetzen und installieren musste. Kurz zusammengefasst muss man also lediglich Pakete für i586 kompilieren und ggf. Abhängigkeiten entfernen, die man sowieso nicht gebrauchen kann. Zum Schluss kann man dann jedes beliebige Programm auch mit ConnochaetOS benutzen. Einziger Nachteil: Man muss sich in Zukunft um die Updates selbst kümmern.

Ihr könnt alle PKGBUILDs und auch noch ein paar zusätzliche von KMandla mit Hilfe des folgenden Links herunterladen.

ConnochaetOS_PKGBUILDs.tar

Hier ist noch ein PKGBUILD-Beispiel mit Irssi:

# $Id: PKGBUILD 125226 2011-05-25 19:11:10Z foutrelis $
# Maintainer: Giovanni Scafora <giovanni@archlinux.org>
# Contributor: Dan McGee <dan@archlinux.org>
pkgname=irssi
pkgver=0.8.15
pkgrel=5
pkgdesc="Modular text mode IRC client with Perl scripting"
arch=('i586')
url="http://irssi.org/"
license=('GPL')
depends=('glib2' 'openssl' 'perl')
optdepends=('perl-libwww: for the scriptassist script')
backup=(etc/irssi.conf)
source=(http://irssi.org/files/${pkgname}-${pkgver}.tar.bz2)
options=('!libtool')
md5sums=('1dcb3f511b88df94b0c996f36668c7da')
build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr
              --enable-ipv6
	      --with-proxy
	      --sysconfdir=/etc
	      --with-perl-lib=vendor
  make
  make DESTDIR="${pkgdir}" install
}

Arch Linux: Paketsignaturen mit GnuPG und Pacman 4

Vor drei Tagen wurde auf archlinux.org die gute Nachricht verkündet, dass Archs neuer Paketmanager Pacman 4 nun in den “Core”-Paketquellen verfügbar ist. Ich hatte im letzten September noch laut über die Sicherheitsarchitektur der Paketverwaltung nachgedacht und damals die Diskussion zu dem Thema näher verfolgt, die schon vor Jahren angestoßen wurde aber erst durch einen kritischen lwn.net Artikel an Fahrt gewann.
Währenddessen war man nicht untätig und 893 commits von 24 Helfern später, ist es nun gelungen eine Reihe von neuen Feature zu implementieren, darunter eben auch das Signieren von Paketen mit GnuPG.
Zuerst fiel mir auf, dass ich yaourt und dessen Abhängigkeit package-query vor einem Systemupgrade entfernen musste, da package-query auf Pacman in einer Version < 3.6 angewiesen war. Danach wurde zuerst Pacman aktualisiert, bevor ich mir das neue Sicherheitskonzept näher anschauen konnte.
Als erstes sollte man den neuen GnuPG Schlüsselbund mit pacman-key --init anlegen. Zum Thema Package Signing und Pacman-Key gibt es schon einen hilfreichen Eintrag im Wiki. Ausführlich wird der gesamte Prozess auch auf Allan McRaes Homepage erläutert.
Nachdem mit pacman-key sowohl Schlüsselbund und ein Grundgerüst an Konfigurationsdateien angelegt worden ist, kann man in /etc/pacman.conf seine persönlichen Vorstellungen von Sicherheit einstellen. Zur Zeit ist das Überprüfen der Paketsignaturen nämlich noch mit der Variablen SigLevel = Never abgeschaltet.
Mit SigLevel = Optional TrustedOnly werden Pakete auf ihre Signaturen hin überpüft, jedoch muss man jedem unbekannten Schlüssel noch einzeln vertrauen. Eine typische Fehlermeldung sieht dann am Anfang so aus:

pacman -S transmission-gtk
resolving dependencies…
looking for inter-conflicts…
Targets (1): transmission-gtk-2.42-2
Total Download Size: 0.61 MiB
Total Installed Size: 2.57 MiB
Proceed with installation? [Y/n]
:: Retrieving packages from extra…
transmission-gtk-2.42-2-i686 625.7 KiB 410K/s 00:02 [########################################] 100%
(1/1) checking package integrity [########################################] 100%
error: transmission-gtk: key “E8F18BA1615137BC” is unknown
:: Import PGP key 615137BC, “Ionut Biru “, created 2011-04-19? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Deswegen sollte man zuerst die sogenannten MasterKeys importieren. Diese fünf Hauptschlüssel werden dazu benutzt um die Schlüssel anderer ArchLinux-Entwickler zu unterschreiben. Gemäß dem Web of Trust ist das marginale Vertrauen in drei dieser Schlüssel ausreichend, um einen anderen mit ihnen unterschriebenen Schlüssel als gültig anzusehen. Selbst im schlimmsten Fall, wenn zwei der MasterKeys widerrufen werden müssten, wäre also das Sicherheitskonzept weiter in Takt.
Problematisch ist momentan die Verteilung dieser Schlüssel. Es gibt z.B. noch kein pacman-keyring Paket, mit welchem alle GnuPG-Schlüssel automatisch und benutzerfreundlich eingerichtet werden können. Außerdem haben noch nicht alle ArchLinux-Entwickler ihre GnuPG-Schlüssel unterschreiben lassen, weswegen es zu Warnmeldungen kommt. Dies ist auch der ausschlaggebende Grund, warum Arch Linux mit Pacman 4 standardmäßig noch auf die Validierung verzichtet.
Eine einfache Möglichkeit die fünf MasterKeys zu importieren, ist diese For-Schleife zu benutzen.

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
--no-permission-warning --command-fd 0 --edit-key $key
done

Halten wir mal fest, dass Arch Linux einen großen Schritt in Sachen Paketsicherheit nach vorne gemacht hat. Es braucht aber noch den letzten Feinschliff in den kommenden Wochen, um das Vertrauen in das neue System auch tatsächlich herzustellen.

rTorrent: Multiple watch-Ordner und fertige Downloads managen

Wenn wir heute schon beim Thema sind, möchte ich an dieser Stelle noch auf einen Tipp aus dem Wiki von Arch Linux zum Thema rTorrent hinweisen. Ich wusste, dass rTorrent verschiedene Ordner auf Torrents überwachen konnte. Mit einer weiteren Einstellung lassen sich die heruntergeladenen Dateien nach einem bestimmten Download/Upload-Verhältnis dann in vorher definierte Ordner verschieben.
Was mir jedoch fehlte, war die Möglichkeit einen schon fertigen Download nach einer Weile erneut zu seeden, indem ich lediglich den Torrent in den “watch”-Ordner kopierte und dann die komplette Datei von rTorrent automatisch erkannt und entsprechend verschoben wurde. Problematisch ist bei diesem Client jedoch, dass eine 100% fertige Datei, auf die rTorrent nachträglich aufmerksam gemacht wird, nicht automatisch verschoben werden kann. Dachte ich bis vor kurzem.
Für dieses spezielle Problem gibt es aber seit Version 0.8.6 eine Lösung. Ich bin mir nicht sicher, ob der Patch damals schon Eingang in Debian Squeeze gefunden hat, mit der aktuellen 0.8.9 Version in Unstable funktioniert es aber prächtig.
In der .rtorrent.rc sollten folgende Zeilen zu dem schon vorgestellten Setup hinzugefügt werden und ggf. meine alte system.method Zeile deaktiviert werden.

schedule = watch_directory_1,10,10,"load_start=~/downloads/watch/*.torrent,d.set_custom1=~/downloads/fertig/"
schedule = watch_directory_2,10,10,"load_start=~/downloads/watch/linux/*.torrent,d.set_custom1=~/downloads/fertig/Linux/"
system.method.insert=checkdirs1,simple,"not="$equal={d.get_custom1=,d.get_base_path=}""
system.method.insert=movecheck1,simple,"and={checkdirs1=,d.get_complete=,d.get_custom1=}"
system.method.insert=movedir1,simple,"d.set_directory=$d.get_custom1=;execute=mv,-u,$d.get_base_path=,$d.get_custom1=;d.set_custom1=;d.stop=;d.start="
system.method.set_key=event.download.hash_done,move_hashed1,"branch={$movecheck1=,movedir1=}"

Die Konfiguration scheint auf den ersten Blick etwas kryptisch zu sein, im Prinzip macht sie aber nur folgendes:
Zeile 1+2: Hier werden zwei verschiedene Ordner auf neue Torrents überwacht. Sobald hier ein neues Torrent hin verschoben wird und rTorrent läuft, beginnt automatisch der Download/Upload-Vorgang. Nach der Fertigstellung wird das Ergebnis je nach dem in welchem Ordner die Torrents gespeichert wurden, nach ~/downloads/fertig/ oder ~/downloads/fertig/Linux/ gespeichert.
Zeile 4: Überprüft ob das Torrent sich schon im Ziel Ordner befindet (false) oder eben woanders liegt (true).
Zeile 5: Überprüft ob das Torrent zu 100% komplett ist, der Wert aus Zeile 4 true zurückliefert und die Variable custom1 (der Zielpfad) existiert.
Zeile 6: Auf Basis der Ergebnisse aus Zeile 4+5 wird die fertige Datei in den Zielordner verschoben, rTorrent erkennt, dass das geschehen ist und verteilt den Download ab sofort aus dem neuen Zielordner.
Zeile 7: Wenn ein Torrent gehasht wird und in Ordnung ist, wird Zeile 6 ausgeführt. Zeile 7 ist also wichtig, falls eine Überprüfung des Torrents stattfindet. Alle Zeilen davor funktionieren auch, wenn kein Hashing mehr notwendig ist.
Mit diesen Zeilen kann ich also ein fertiges Linux ISO in den “todo”-Ordner verschieben und rTorrent erkennt an dem Ort der Torrent-Datei, wohin diese fertige Datei verschoben werden muss und seedet danach entsprechend meiner Einstellung weiter.

Opera 11.60: Crash nach Laptopmodell

Seit einigen Tagen habe ich ein paar seltsame Probleme mit Opera 11.60. Ich benutze den Inspiron 4000 Laptop auch mal gerne dazu verschiedene Webbrowser zu testen und präsentiere meine Erfahrungen dann mit unfehlbarer wissenschaftlicher Präzision und absoluter Unabhängigkeit in diesem Blog.

Nun gab es in den letzten Monaten ein Update von 11.50 auf 11.60 und ehrlich gesagt, erwartete ich bei so kleinen Zahlen keine großen Wirkungen. Doch Opera 11.60 verhielt sich auf dem Inspiron mit Debian Sid plötzlich nicht mehr ganz so wie erwartet. Während er letzten Sommer mit Version 11.50 noch problemlos funktionierte, gab es nun direkt nach dem Start schon den ersten Absturz. Die Fehlermeldungen sind kryptisch und anscheinend nur für die Entwickler gedacht, was mich aber bei einem closed source Programm nicht besonders überraschte.
Ich probierte es daraufhin mit dem parallel installierten Arch Linux, doch auch hier kam ich nicht einmal über das Bestätigen der EULA hinaus. Opera fror ein und versagte den Dienst.
Wenn das nun bei zwei verschiedenen Linuxdistributionen passiert, kann es doch nur an Opera liegen, oder? Ich gab dennoch nicht auf und installierte Opera auch auf dem Thinkpad 600 mit Debian Stable, wo dwm als Fenstermanager läuft. Leider auch hier das gleiche Ergebnis.
Klare Sache. Das musste doch sicherlich auch noch andere Leute betreffen. Eine ausgedehnte Internetsuche brachte aber nichts wirklich erhellendes, Abstürze ja, aber in den gleichen Threads auch wieder viele positive Kommentare, die bestätigten, dass Opera funktionierte.
Kurzum ich fand keinen Fingerzeig oder logische Erklärung für dieses Problem. Ich experimentierte also noch einmal mit speedy, dem Toshiba Portégé 3110CT. Auch hier lief Debian Stable und ich probierte es mit dem Awesome-Fenstermanager.
Erfolg! Opera ließ sich starten und auch mein Blog passte haargenau in die 800×600 Pixel Auflösung.

Was hier schief läuft, ich kann es nicht sagen. Opera scheint zumindest bei meinen Rechnern, sich seine Freunde ganz genau auszusuchen. Ich hoffe nur, dass das nicht der Anfang vom Ende bei der Unterstützung von älteren Rechnern und Linux bei Opera gewesen ist. Möglicherweise habe ich aber auch den großen “Oha”-Artikel einfach überlesen und alles funktioniert wie beabsichtigt. 🙁

Ein geschmackvolles Openbox-Thema

Ich hatte schon seit ein paar Wochen angedacht, ein neues Thema für meine Openbox Installation mit Archlinux auf dem Inspiron 4000 zu finden. Normalerweise hänge ich ziemlich lange an einer Kreation fest und investiere nicht zu viel Zeit in die wiederkehrende Neugestaltung meines Desktops. In der Regel greife ich auf gute Ideen von box-look.org zurück oder bediene mich bei der sehr guten Konfiguration von Crunchbang Linux.
Vor zwei Tagen entschied sich Urukrama erneut einen Jahresrückblick zu machen und präsentierte seine Desktops aus den Jahren 2010 und 2011.
Urukrama war vor ca. 3 Jahren mein Einstieg in die Welt der Fenstermanager und leichtgewichtigen Desktops und schon damals gefiel mir sein untrüglicher Sinn für geschmackvolle Themen. Ich habe mich also auch diesmal ein wenig inspirieren lassen.
Zuerst fiel mir eines seiner Hintergrundbilder auf, ein Gemälde von Caspar David Friedrich “Der Mönch am Meer”, weswegen ich auf der englischen Wikipedia Seite zum Künstler etwas ähnliches gesucht habe und schließlich das Bild “Mondaufgang über dem Meer” heruntergeladen habe. Interessanterweise unterscheidet es sich vom Bild aus der deutschen Wikipedia, ein Kunstkenner sollte diesen Widerspruch mal aufklären. 🙂
Mir gefiel es auf jeden Fall und mit Hilfe von feh war es schnell als Hintergrundbild gesetzt.
Als nächstes bediente ich mich beim Alghattas-Openbox- und Gtk-Thema von Urukrama. Nachdem man es entpackt hat, lässt es sich mit obconf in eine spezielle Obt-Datei umwandeln und installieren. Die mitgelieferte “.gtkrc”-Datei sollte nach ~/.gtk-2.0.mine kopiert werden, wodurch die GTK-Einstellungen nach einem Neustart von Openbox automatisch wirksam werden.
Danach installierte ich noch die Elementary Icons mit LXappearance und schließlich passte ich diese conkyrc so an, dass Conky linksbündig, horizontal und transparent angezeigt wurde. Nur an Tint2 von Crunchbang hielt ich wie bisher fest. Mir gefällt es so einfach.
Gut, dass sich über Geschmack nicht streiten lässt. 🙂

Das Jahr 2011 mit alten Rechnern in der Retrospektive

83 Millionen. Diese interessante Zahl veröffentliche vorgestern der IT-Branchenverband Bitkom und bezifferte damit die potentielle Anzahl von in deutschen Haushalten herumliegenden Althandys, wie heise.de berichtet. Grob geschätzt hat also jeder Deutsche irgendwo noch ein Mobiltelefon zu Hause herumliegen, dass er womöglich gar nicht mehr benutzt.
Für mich rief diese Zahl Erinnerungen an meine vor einiger Zeit veröffentlichten Ergebnisse zum Energieverbrauch meiner Computer wach. Wie viele ältere PCs, Laptops und Netbooks wird es wohl in Deutschland noch geben und wie viel Energie wurde in ihre Herstellung investiert, was wird verbraucht und vor allem was lässt sich mit all der Elektronik noch anstellen?
Ich gebe mich nicht der Illusion hin zu glauben, dass sich in naher Zukunft etwas an diesem IT-Trend ändern wird. Es ist wohl heute schon eher der Regelfall mehrere Handys, Smartphones, Tablets, Laptops und normale PCs gleichzeitig zu besitzen. Auf einen allgemeinen Willen, der Fortschritt und Nutzen sowie wirtschaftliche als auch ökologische Vernunft zusammenführt, müssen wir wohl noch eine Weile warten.
Bevor ich mich nun als Moralapostel aufspiele, der nicht wenige dieser IT-Goodies selbst besitzt, ist hier einfach mal ein Überblick über meinen Rechenpark und die Freie Software, die dort zum Einsatz kommt, was man damit noch machen kann und warum es sich lohnt an gebrauchter Hardware nicht nur festzuhalten, sondern sie einfach weiterhin wie einen neuen Rechner zu benutzen.

Core Duo

Wenn man einen klassischen Desktop-PC mit einem 2,8 GHz Dual-Core-Prozessor betreibt, stellt man schnell fest, dass es kaum eine Anwendung gibt, die man damit nicht zum Laufen bringen kann. Dieser PC gehört schon lange wieder zur Low-End Kategorie, aber ernsthaft, mir ist noch keine Applikation untergekommen, die hier drauf nicht funktionieren würde.
Anfang des letzten Jahres habe ich mich entschieden ein Multiboot-System aufzusetzen, wo heute noch Ubuntu, Debian Testing und Debian Sid parallel installiert sind. Die Vorteile überwiegen für mich eindeutig. Auf einer weiteren Partition teste ich gerne auch andere Distributionen oder benutze sie für meine Experimente zum Thema Softwareentwicklung.
Ich denke, ich habe damit eine Menge neue und gute Erfahrungen gemacht und das System erfüllt alle meine Erwartungen. Insbesondere Debian Testing hat mich überzeugt, weil es dieses Jahr bis auf meine Nvidia-Probleme zuverlässig und mit aktueller Software funktionierte. Trotz des für die Debianentwickler aufwändigen Wechsels von Gnome 2 zu Gnome 3 geriet Testing nie ins stottern. Für einen klassischen Arbeits- und Multimedia-PC hat sich Debian auf jeden Fall bewährt und die Vorurteile, dass es mit Debian viel schwieriger sei ein solches Setup einzurichten und zu pflegen, konnte ich für mich nicht bestätigen.
Auch ein leichtgewichtiges Spielesystem macht sich bezahlt, dass nicht nur eine gute Performance liefert, sondern auch eine praktische und gefahrlose Trennung zwischen wichtigen und optionalen Anwendungen ermöglicht.
Ubuntu habe ich letztes Jahr etwas vernachlässigt. Das liegt weniger daran, dass mir Gnome 3 gegenüber Unity besser gefällt, als dass ich bisher wenig Zeit für mein Projekt, Ubuntu als Videoschnittplatz zu benutzen, gefunden habe. Doch aufgeschoben ist nicht aufgehoben.

Dell Inspiron 4000

Seit 2008 benutze ich diesen mittlerweile 10 Jahre alten Laptop. Als Betriebssystem stand Debian Sid mit Openbox als Fenstermanager eindeutig im Fokus. Trotz des hohen Alters sorgen beide dafür, dass sich Anwendungen flüssig bedienen lassen. Bis zu diesem kleinen Missgeschick hat er mich auch oft unterwegs begleitet. Zur Zeit dient er als Couch-Laptop, wer sich unter dem Begriff etwas vorstellen kann. 🙂
Internetsurfen, Mails abrufen oder Feeds lesen lässt sich natürlich auch mit einem älteren Laptop erledigen. Wozu also immer den wesentlich energiehungrigeren Core Duo bemühen?
Sicherlich ist er auch weiterhin perfekt um als Testrechner für die brandneuste Entwicklung mit Debian zu dienen. Es macht einfach Spaß mit Sid zu arbeiten, auch wenn oder gerade deswegen, manchmal etwas nicht so funktioniert wie es sollte.
Als Zweitsystem dient mir Arch Linux, womit ich interessante neue Ideen kennenlerne und ausprobiere. Arch Linux gelingt es an manchen Stellen wie z.B. der Paketverwaltung noch etwas reaktionsfreudiger zu sein.
Ansonsten dürfen sowohl KolibriOS als auch der Plop Bootmanager auf Grund ihrer Vielseitigkeit und des schieren “WoW-Faktors” auf diesem Laptop nicht fehlen.
Bevor ich mit dieser Einteilung zufrieden war, habe ich noch verschiedene Distributionen mit dem Inspiron ausprobiert, darunter unter anderem Crunchbang und Linux Mint Debian.

IBM Thinkpad 600

Erst vor wenigen Monaten habe ich einen Thinkpad als mobilen Ersatz für den Inspiron 4000 erworben, den ich dann am liebsten neben MacBook Pro Besitzern aufbaue. :mrgreen:
Neben seinem Gastauftritt auf einem Weihnachtsmarkt als Jukebox, ist er vor allem mit einer Menge nützlicher Konsolenanwendungen bestückt, die von Debian Stable geliefert werden. Benötige ich eine grafische Oberfläche, komme ich mittlerweile mit dwm sehr gut zurecht, das zum einen ressourcensparend ist und sich zum anderen bequem über die Tastatur bedienen lässt.
Als Alternative hat sich das parallel installierte ConnochaetOS etabliert, dass durch eine gute Vorauswahl von leichtgewichtiger Software und den effizienten Unterbau von Arch Linux besticht. Mit Hilfe von Partimage tausche ich manchmal dieses Zweitsystem aus.
Auch Slitaz hat sich nicht schlecht geschlagen und beeindruckt vor allem durch seinen äußerst geringen Verbrauch an Festplattenspeicher und sehr effiziente Systemprogramme. KolibriOS und der Plop Bootmanager dürfen ebenfalls nicht fehlen.
Zusammengenommen vermisse ich nicht besonders viel mit dem Thinkpad, sieht man mal von der Fähigkeit ab h264 Videos ruckelfrei abspielen zu können. Hier muss die Pentium II CPU einfach passen.

Toshiba Portégé 3110CT

Toshiba ist mit diesem kompakten Subnotebook 1999 schon ein kleines Kunststück gelungen. Portabilität ist sicher seine große Stärke. Umso merkwürdiger scheint es da zu sein, dass ich dieses Geschenk zur Zeit hauptsächlich als kleinen Heimserver und Testplatz für Fenstermanager und Konsolenanwendungen benutze. Viel zu klagen hatte ich 2011 nicht, denn dank Debian Stable läuft der Rechner rund und stabil. Durch die geringe Größe nimmt der Laptop nicht besonders viel Platz weg und trotz des kleineren 64 MB Arbeitsspeichers, sind seine anderen Systemspezifikationen besser als die des Thinkpad. Das macht ihn leistungsfähig genug, um alle meine privaten Serveransprüche zu erfüllen.

Toshiba Satellite 220CS

Dieser 15 Jahre alte Laptop ist mit Sicherheit eine Herausforderung. Das Problem liegt weniger an der 1,4 GB großen Festplatte oder dem Pentium I Prozessor. Hätte dieser Toshiba etwas mehr RAM, ich könnte sehr wahrscheinlich von den gleichen Ergebnissen wie bei den anderen Computern erzählen. Die Herausforderung besteht tatsächlich darin ein geeignetes Betriebssystem zu finden, welches sowohl die Hardwareanforderungen von 16 MB RAM erfüllt und zum anderen zeitgemäße Software zur Verfügung stellt.
Den besten Kompromiss aus Geschwindigkeit, Bedienbarkeit und Softwareauswahl liefert hier zur Zeit Slitaz. Es ist eine der wenigen Distributionen, deren Installationsmedien selbst bei so wenig RAM noch funktionieren und die, typische Linuxkenntnisse vorausgesetzt, keine großen Hürden für den Anwender darstellen. Idealerweise bringt Slitaz mit tazpkg einen äußerst reaktionsfreudigen Paketmanager mit, mit dessen Hilfe das Installieren von Software ein Kinderspiel ist.
Zur Zeit eignen sich insbesondere Konsolenanwendungen für einen effizienten Einsatz und auch der Betrieb als Torrent-Sklave oder Jukebox ist möglich. Für die Zukunft sollte man sich auch Do-it-yourself-Distributionen wie CRUX merken, mit denen sich ein maßgeschneidertes und sehr effizientes System erstellen lässt, dass aber mehr Wissen des Anwenders voraussetzt.
Schon heute gibt KolibriOS mit einer grafischen Oberfläche ein gutes Bild auf dem Satellite 220CS ab, auch wenn sich damit nicht jedes Benutzerszenario abdecken lässt. Ebenfalls beeindruckend ist FreeDOS, das eine ideale Wahl für Rechner Anfang und Mitte der 90iger Jahre ist und mit dem sich mehr erreichen lässt als nur Spiele aus der damaligen Zeit zu spielen.

Fazit

Mein Blog gäbe es in dieser Form nicht, wenn es selbstverständlich wäre, ältere Hardware weiterhin mit Freier Software weiterzuverwenden. Menschen, die so etwas tun, etikettiert man gerne mit negativ konnotierten Begriffen wie nostalgisch, antiquiert und rückwärts gewandt. Ich kann nicht garantieren, dass die in diesem Blog beschriebenen Wege für jeden das Richtige sind, ich sage nur, sie funktionieren für mich.
Alle meine privaten Anwendungsfälle werden mit den alten Rechnern abgedeckt. Es lohnt schon allein aus informativen Gründen, sich näher mit der Thematik rund um Freie Software und ältere Rechner zu beschäftigen. Man muss nur offen für Neues sein und immer an die Vielzahl von Verwendungsmöglichkeiten zurückdenken.
Und irgendwann kommt der Zeitpunkt, wann sich das alles mit der aktuellen Hardware von heute wiederholen wird.

Alt-Gr-Taste unter X in Betrieb nehmen und Tastaturlayout auf Deutsch ändern

Letzte Woche wurde die Frage gestellt, warum die “Alt-Gr”-Taste des Thinkpad 600 bei Slitaz nicht funktionieren würde. Mir war dieses Problem damals nicht aufgefallen und für gewöhnlich muss ich mich zumindest bei Debian nicht um das manuelle Einstellen des Tastaturlayouts kümmern.
Der X-Server ist mittlerweile so smart, dass er alle Optionen automagisch einrichtet. Sollten aber Probleme mit dem Tastaturlayout auftreten, lässt sich die Einstellung für Xorg nach wie vor entweder in /etc/X11/xorg.conf oder mit einer Konfigurationsdatei in /etc/X11/xorg.conf.d/ manuell ändern. Der Abschnitt sieht dann für eine deutsche Tastatur ähnlich wie dieser aus:

Section “InputDevice”
  Identifier “Generic Keyboard”
  Driver “kbd”
  Option “XkbRules” “xorg”
  Option “XkbModel” “pc105″
  Option “XkbLayout” “de”
  Option “XkbVariant” “nodeadkeys”
EndSection

Tastaturlayout für ConnochaetOS und den Thinkpad 600 ändern

Später fiel mir dann auf, dass ConnochaetOS die AltGr-Taste des Thinkpad 600 ebenfalls nicht automatisch eingerichtet hatte, obwohl es eine extra angelegte /etc/X11/xorg.conf.d/20-keyboard.conf gab. Da ConnochaetOS auf Arch Linux basiert, konnte ich schnell eine Lösung für das Problem finden, dank dieses Beitrags im deutschen Arch-Linux-Forum.
Damit die AltGr-Taste wieder funktioniert, muss man einen Parameter für die Option “XkbOptions” mit Hilfe des Programms setxkbmap temporär übergeben oder permanent in der Datei 20-keyboard.conf eintragen.

Temporär

setxkbmap -option lv3:ralt_switch_multikey

Permanent

Option “XkbOptions” “lv3:ralt_switch_multikey”

Bei ConnochaetOS sieht die 20-keyboard.conf dann so aus:

Section "InputClass"
  Identifier "txkbmap keyboard catchall"
  MatchIsKeyboard "on"
  Option "XkbModel" "thinkpad"
  Option "XkbLayout" "de"
  Option "XkbVariant" "nodeadkeys"
  Option "XkbOptions" "lv3:ralt_switch_multikey"
EndSection

Die Systemeinstellungen und das Tastaturlayout für die Konsole lassen sich bei Arch Linux und ConnochaetOS in /etc/rc.conf ändern. Hilfreich ist der Artikel “Arch Linux auf Deutsch stellen” im Arch Linux Wiki.

Fehlerdiagnose

Mit dem Kommando xev lässt sich herausfinden, mit welchem Keycode eine Taste im Moment belegt ist, indem man die betreffende Taste danach einfach drückt. Mit xmodmap -pke wird eine komplette Übersicht angezeigt. Beide Befehle eignen sich gut für die Fehlerdiagnose.
In /usr/share/X11/xkb/rules/base.lst befindet sich die Dokumentation zu allen Optionen im Zusammenhang mit Xorg und xkb.