Teilweise war sie schon länger online. Zur Übersicht über meine grafischen Programme sind nun auch noch die Konsolenanwendungen hinzugekommen, die ich regelmäßig benutze.
Warum noch eine Übersicht zu leichtgewichtiger Software? Der wichtigste Grund ist sicher, dass ich nun auf eine eigene Seite in meinem Blog verlinken kann und somit auch mehr Kontrolle über den Inhalt habe. Gleichzeitig spare ich mir damit auch in Zukunft bei jeder Neuinstallation auf einem älteren Rechner das Aufzählen geeigneter Software und verlinke nur noch kurz dorthin.
Ich denke die Softwareseite beantwortet ganz einfach die Frage, welche Software ich regelmäßig oder sogar täglich benutze und nicht notwendigerweise nur auf den ältesten Laptops.
Software, die dort nicht auftaucht, die ich aber trotzdem einsetze, wäre z.B. Gimp, LibreOffice, Wine, Programme zu Video- und Audiobearbeitung, Virtualbox und Icedove. Alles Programme, die ich sehr schätze, die aber für sehr alte Rechner nicht mehr wirklich leichtgewichtig und auch zwingend notwendig sind.
Ich hoffe die Seite gibt anderen eine Idee, welche Programme sich für ein ressourcensparendes Setup eignen. Sehr wahrscheinlich kommen in Zukunft neue hinzu, sofern ich sie häufiger benutze. Auf jeden Fall werde ich aber an der ein oder anderen Stelle noch Bilder und Screenshots hinzufügen, die Texte runder schreiben und auf andere Artikel verlinken.
Blogs und Webseiten scheinen nie fertig zu werden. 😉
Genug der Vorrede, hier geht es zur Softwareseite.
Festplattenlärm bekämpfen: hdparm
Der neue Thinkpad 600 ist eigentlich flüsterleise. Eher höre ich da schon die Zeiger der im Westflügel befindlichen Küchenuhr. Das gilt aber nur solange ich Slitaz benutze. Sobald ich wieder in die Kommandozentrale mit Debian Stable boote, läuft die Festplatte permanent auf Hochtouren.
Abhilfe schafft hier hdparm. Ein kleines, aber feines Werkzeug, um diverse Einstellungen der eigenen Festplatte zu tunen. Leise wird es wieder mit:
hdparm -S 60 /dev/sda
Mit diesem Befehl legt sich die Festplatte nach genau 5 Minuten oder 60x5 Sekunden wieder schlafen. Der Zahlenwert ist etwas wirr. Von 1-240 sind das immer Mehrfache von 5 Sekunden. Für die anderen möglichen Werte von 241-255 sollte man besser man hdparm zu Rate ziehen.
Damit man nicht nach jedem Neustart erneut diesen Befehl ausführen muss, genügt es ihn in die Datei /etc/rc.local zu schreiben.
Endlich wieder Ruhe.. 🙂
Loginmanager für die virtuelle Konsole
Die meiste Zeit meines Linuxlebens hat mich das Thema Loginmanager wenig beschäftigt. Sie verschwinden so schnell in den Hintergrund wie sie erschienen sind und ich brauche sie tatsächlich nur zum Login in meinen Desktop. Auffallend ist, dass jede Desktopumgebung ihren eigenen Loginmanager mitbringt, der in aller Regel eine Weiterentwicklung von xdm ist. KDM für KDE, GDM3 für Gnome, Slim als unabhängige Alternative und nun auch noch LightDM, welcher der neue Standard für Loginmanager werden und ebenfalls unabhängig von einer speziellen Desktopumgebung sein soll.
Wer sich nicht mit den Unterschieden auseinandersetzen möchte und tatsächlich nur einen Weg sucht sich in seinen Desktop einzuloggen, kann auch ganz auf einen grafischen Loginmanager verzichten. Die ressourcenschonendste Alternative ist sicherlich startx bei einem Login in eine virtuelle Konsole automatisch auszuführen.
In der Regel gibt es auf jedem Linuxsystem schon einen Loginmanager für die virtuelle Konsole. Bei Debian ist das getty. Aus Interesse habe ich das schlankere, aber mit weniger Funktionen ausgestattete, mingetty installiert und ausprobiert. Ich konnte allein vom Speicherverbrauch her keine großen Unterschiede entdecken. Um mingetty anstelle von getty zu aktivieren, muss die Datei /etc/inittab editiert werden.
1:2345:respawn:/sbin/getty 38400 tty1
Dort gibt es mehrere ähnlich aussehende Zeilen, bei denen nur der Pfad geändert und die Baudzahl für Modems entfernt werden muss. (Ja, da war mal was. 😉 ) Tut man das übrigens nicht, erscheint eine Fehlermeldung wie diese und man kann sich nicht mehr einloggen.
respawning too fast
Die neue Zeile:
1:2345:respawn:/sbin/mingetty tty1
Es ist auch möglich für jede virtuelle Konsole einen anderen Loginmanager festzulegen. Momentan habe ich drei virtuelle Konsolen für den Thinkpad 600 aktiviert. In den ersten beiden kommt getty zum Einsatz und in die dritte kann man sich mit Hilfe von Qingy einloggen.
Eine Besonderheit von Qingy ist, dass dieser Loginmanager auf das Framebuffer Device zugreift und somit auch ohne X ein grafisches Login bietet, welches sich durch verschiedene Themen weiter ausgestalten lässt. Qingy verbraucht etwas mehr Speicher als getty oder mingetty, bietet aber neben dem Augenschmaus auch Autologin, PAM-Unterstützung und einen Bildschirmschoner. Insgesamt ein interessantes Programm, was wie die anderen auch die wichtigste Aufgabe, den Login, problemlos erledigt. Der Pfad ist geringfügig anders als bei den anderen beiden.
1:23:respawn:/usr/sbin/qingy tty3
Also alles in allem die Alternativen sind da. Für ein reines Konsolensystem würde ich einfach bei dem voreingestellten getty bleiben, das einfach funktioniert. Wer mit seiner Desktopumgebung zufrieden ist, sollte auch mit dem mitgelieferten grafischen Loginmanager ausharren. Vielleicht entschließen sich aber Gnome und KDE in Zukunft auch auf das neue LightDM umzusteigen, welches mit Oneiric Ocelot der neue Loginmanager bei Ubuntu werden wird.
Softwarepakete konvertieren mit alien oder tazpkg
Ein Problem bei kleineren Distributionen ist häufig, dass sie aus Zeit- und Ressourcengründen nicht genauso viele Binärpakete wie größere Distributionen anbieten können. Neue Pakete mit Hilfe der distributionseigenen Werkzeuge zu kompilieren, ist die gängigste Methode um den Softwareumfang zu vergrößern.
Möchte man sich nicht erst in die eher fortgeschrittene Thematik einarbeiten, gibt es zumindest bei Debian und Slitaz eine Alternativmethode. Irgendwann kam jemand auf die Idee, dass es bei manchen Paketen nur notwendig ist die Struktur der integrierten Dateien anzupassen und das Paket einer fremden Distribution in das eigene Format umzuwandeln.
Ich wollte unbedingt mein favorisiertes Musikprogramm cmus auch mit Slitaz benutzen, weswegen ich mir die neueste Version aus Debian Sid heruntergeladen habe und mit Hilfe von tazpkg das Paket dann umgewandelt habe. Der Weg ist schnell erklärt.
- Cmus als .deb Paket manuell oder mit apt herunterladen
tazpkg convert"Paketname"
Das war es auch schon. Danach beginnt der Paketmanager das Paket in das Slitaz-Format umzuwandeln. Man sollte zumindest eine einigermaßen schnelle Kiste besitzen. Der Thinkpad 600 ist dafür ausreichend, bei einem Toshiba Satellite 220cs mit nur 16 MB RAM kann sich der Vorgang auch schon mal ein paar Stunden hinziehen. 🙄
Debian und Aliens
Debian hat für diese Art von Aufgabe ein vergleichbares Programm namens alien, mit dem sich z.B. Slackware- oder RPM-Pakete in das Deb-Format überführen lassen.
alien --to-deb /Pfad/zu/meinem/Paket.rpm
Die Methode muss nicht zwangsläufig bei jedem Paket funktionieren. Bei kleineren hatte ich aber bisher immer Erfolg. Die "saubere" Methode bleibt auch weiterhin ein Stück Software direkt aus den Quellen zu kompilieren. Aus diesem Grund gibt es ein solches Werkzeug bei Arch Linux erst gar nicht.
Partimage: Simple Backupmethode auch für ältere Rechner
Der neue Thinkpad 600 besitzt "nur" 128 MB RAM, womit die bequemste Backupmethode mit Clonezilla auf diesem Gerät für mich entfällt und ich eine Kernelpanic erhalte. Falls es doch jemand schon mit dieser begrenzten RAM-Zahl geschafft haben sollte, würde ich gerne wissen wie. 😉
Alles kein Problem, denn man kann natürlich auch direkt auf die Werkzeuge zugreifen, die Clonezilla unter einer ausgefeilten Oberfläche zum Einsatz bringt. Ich habe mich für Partimage entschieden, welches ich von der Debian-Squeeze-Installation aus benutze, um parallel installierte Distributionen zu sichern. Die Bedienung ist simpel. Zuerst wird die Partition für das Backup ausgewählt (in meinem Fall sda3) und dann in eine Image Datei geschrieben.
Der Zielpfad liegt bei meinem eingehängten USB-Stick in /media/data/. Mit F5 geht es danach zur nächsten Seite, wo man auswählen kann, ob man mit oder ohne Kompression sein Backup sichern möchte.
Viel mehr gibt es auch nicht zu sagen. Sowohl das Backup als auch die Rücksicherung funktionierten bisher immer einwandfrei. Je nach Größe des Abbilds dauert es auf dem alten Laptop mit USB 1.0 zwischen 5 und 20 Minuten ein Backup zu sichern.
Hardware für den Internetzugang mit freien Linuxtreibern
Als kurze Übersicht, hier sind die im letzten Beitrag erwähnten PCMCIA-Karten, die 100 % freie Linuxtreiber haben und sofort funktionieren. Empfehlenswert.
ASUS WL-107G
PCMCIA WLAN Karte von ASUS mit Ralink Chipsatz. Linuxtreiber: rt2500pci
Um die Fehlermeldung
phy0 -> rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16)
zu unterdrücken, ist es notwendig z.B. in der Datei /etc/rc.local folgenden Befehl einzutragen.
iwconfig wlan0 power off
3Com Megahertz 3CCFE574BT
PCMCIA zu LAN Karte von 3Com. Linuxtreiber: 3c574_cs
3Com Megahertz 3CCFE575CT
PCMCIA zu LAN Karte von 3Com. Linuxtreiber: 3c59x
Für die letzten beiden Karten ist noch ein zusätzlicher Adapter notwendig, mit dem sich dann ein RJ45-Stecker anschließen lässt. Besonders praktisch für ältere Hardware, die fast immer auch über einen PCMCIA-Slot verfügt und sich damit problemlos in jedes Heimnetzwerk einbinden lässt.
PolicyKit und der alltägliche Wahnsinn mit den Rechten
Alternativer Titel: "Problem gelöst...Jetzt erst recht!". Gestern erreichte mich ein Kommentar, was mich dazu brachte erneut über diesen merkwürdigen Bug "Not authorized" nachzudenken. Egal wie ich es anstellte, sobald ich versuchte etwas in Thunar als normaler Nutzer zu mounten, wurde ich mit einer Meldung von PolicyKit abgewimmelt.
Das Problem hat zwei Dimensionen. Zum einen scheint der Bug mit der Wahl des Loginmanagers zusammen zuhängen. Slim erkennt oder wählt hier zumindest nicht die richtigen Einstellungen, damit PolicyKit die Rechte für die einzelnen Nutzer des Systems setzen kann. Auch mit einer Lösung ohne Loginmanager hatte ich keinen Erfolg. Man könnte z.B. mit der xinitrc-Methode ebenfalls in eine grafische Desktopumgebung starten:
exec ck-launch-session dbus-launch openbox-session
Ich schaute mir noch einmal den entsprechenden Debian-Fehlerbericht an. Der letzte Eintrag verweist dabei auf den Loginmanager lightdm. Lightdm scheint ziemlich neu zu sein, denn es gibt keine Version für Squeeze. Er selbst nennt sich kompatibel mit aktuellen Entwicklungen von PolicyKit und PAM. Vielleicht hatte ich hier mehr Glück.
Tatsächlich lassen sich nach einer Installation von Lightdm wieder externe Speichermedien ohne Probleme auch in Thunar mounten. Nur die restriktive Einstellung, dass lediglich Administratoren interne Partitionen oder Medien mounten konnten, gefiel mir noch nicht richtig.
Damit auch interne Laufwerke oder Partitionen ohne die Rechte eines Admins eingehängt werden können, genügt ein kleiner Eintrag in /etc/polkit-1/localauthority/50-local.d/10-udisks.pkla.
Die Textdatei kann beliebig benannt werden. Wichtig ist nur, dass der Dateiname auf .pkla endet. Mehr Informationen dazu gibt es auch mit man pklocalauthority. Interessanterweise schlägt ubuntu.com vor, dass man den Nutzer zur Admingruppe hinzufügen sollte, wenn man interne Datenträger mounten möchte. Ich sehe dabei das Problem, dass dadurch auch andere Aktionen möglich werden, die besser nur durch root ausgeführt werden und nicht durch irgendeinen Benutzer auf dem System.
Am Ende erstellte ich die Datei 10-udisks.pkla mit folgendem Inhalt
[Storage Permissions] Identity=unix-group:disk Action=org.freedesktop.udisks.filesystem-mount;org.freedesktop.udisks.filesystem-mount-system-internal;org.freedesktop.udisks.filesystem-unmount-others;org.freedesktop.udisks.drive-eject;org.freedesktop.udisks.drive-detach;org.freedesktop.udisks.luks-unlock;org.freedesktop.udisks.inhibit-polling;org.freedesktop.udisks.drive-set-spindown ResultAny=no ResultActive=yes ResultInactive=no
Fügt man den normalen Benutzer zur Gruppe "disk" hinzu, kann dieser ab sofort wieder Partitionen oder Speichermedien auch intern mounten. PolicyKit ist sicher eine fortgeschrittene Möglichkeit Benutzerrechte zu definieren und diese auf verschiedene Anwendungen anzuwenden. Leider ist die Dokumentation zu sehr auf Entwickler ausgelegt. Als Endanwender erschließen sich manche Entscheidungen von Debian und PolicyKit nicht auf den ersten Blick. Danke auch für die Hinweise an diesen Post im Forum von Arch Linux.
Wem Debians restriktive Politik beim Mounten von Datenträgern bisher missfallen hat, kann mit einer kleinen Änderung dieses Verhalten schnell ändern. Man muss vorher nur wissen, dass es mit PolicyKit zu tun hat. 😉
Pacman und das Bedürfnis nach Sicherheit
In den letzten Tagen und Wochen habe ich mich öfter mit Pacman dem Paketmanager von Arch Linux auseinander setzen müssen. Kurioserweise ist er mir bei der Konfiguration von ConnochaetOS vertrauter geworden und weniger beim Umgang mit Arch Linux selbst. Irgendwann habe ich mich gewundert, wie Pacman eigentlich die Integrität der heruntergeladenen Pakete sicherstellt und nach Parallelen zu Debian GNU/Linux gesucht.
Ein wichtiges Hilfsmittel sind MD5-Hashes um zu bestimmen, ob ein vom Server heruntergeladenes Paket auch tatsächlich intakt auf dem eigenen Rechner ankommt. Auch Arch Linux greift genau auf diese Methode zurück. MD5 gilt seit einiger Zeit nicht mehr als ausreichend sicher und eignet sich daher auch nicht um die Echtheit von Paketen zu verifizieren.
Mittlerweile weiß ich auch, dass im Gegensatz zu Debians apt der Paketmanager von Arch Linux noch über keine ausreichende Implementierung zur Überprüfung von sicheren Paketsignaturen mit Hilfe von GnuPG verfügt. Bei meiner Suche nach Informationen bin ich dann auf einige lesenswerte und interessante Artikel gestoßen.
Zum einen wäre da der LWN Artikel "Arch Linux and (the lack of) package signing" und die Antwort darauf von Dan McGee, einer der Hauptentwickler von Pacman und Arch Linux. Kurz zusammengefasst wurde die Problematik am 23. März 2011 deutlich in den Fokus der interessierten Öffentlichkeit gerückt, obwohl das Problem schon seit mehreren Jahren im Bugtracker und Forum von Arch Linux bekannt war. Nach dem ich mir beide Artikel durchgelesen habe, denke ich, dass die Behauptung zutrifft, dass eine funktionierende Paketsignierung bei Arch Linux nicht existiert.
Weniger schwer wiegen da die verletzten Befindlichkeiten der Pacman-Entwickler und des im LWN-Artikels zitierten Arch-Nutzers, der die ganze Sache "ans Licht brachte". Offensichtlich gab es seit Jahren aus verschiedenen Gründen kein Interesse ein solches Sicherheitsfeature zu implementieren und gleichzeitig auch keine echte Hilfe von Seiten der Community. Die Entwicklung stagnierte. Die Frage ist nur, ob man ein solches Problem nur zur Aufgabe einiger Paketentwickler degradieren oder es nicht doch besser zu einer Aufgabe und zu einem Ziel der ganzen Distribution hätte machen sollen.
Natürlich ist jeder User immer ein Stück weit selbst für die Sicherheit seines Systems verantwortlich. Dennoch sollte es eine Möglichkeit geben zu überprüfen, ob es sich bei den heruntergeladenen Paketen auch wirklich um die offiziellen handelt und nicht möglicherweise doch um kompromittierte.
Seit dem Artikel sind sechs Monate vergangen und ein Blick auf die offizielle ArchLinux-Seite zeigt, dass man das Problem zumindest nicht versucht zu verbergen. Es gibt eine eigene Wikiseite zum Thema "Pacman package signing" und auch die FAQ listet unter dem Punkt "Warum man Arch nicht nutzen sollte" auf, dass man dann auf eine sichere Paketsignierung nicht verzichten muss.
Arch Linux ist nicht die einzige Distribution, die eine solche Verifizierung noch nicht vorgesehen hat. Sie wird deswegen auch nicht nutzlos. Selbst Debian hatte nicht von Anfang an eine Möglichkeit um die Echtheit von Paketen zu überprüfen. Doch im Gegensatz zu Arch Linux gab es bereits vor elf Jahren eine breite Diskussion zu diesem Thema. In der Dokumentation zur Absicherung von Debian finden sich hier zwei Links zu den wöchentlichen Neuigkeiten aus dem Jahr 2000 und 2001.
Wenn man etwas daraus lernen kann dann das, man sollte jede Distribution darauf überprüfen, ob sie zu den persönlichen Anforderungen passt. Wenn ich mich auf meine Software zu 100% in jeder Situation verlassen muss, greife ich eher zu Debian Stable als zu Arch Linux. Wenn ich der Meinung bin, dass das Risiko auf ein paar älteren privaten Laptops vernachlässigbar ist und die Distribution ansonsten wunderbar für mich funktioniert, werde ich die betreffende Distribution auch weiterhin verwenden. Ganz allgemein gesprochen kann es nicht schaden die vielen Drittquellen, wozu z.B auch die PPAs bei Ubuntu gehören, genauer unter die Lupe zu nehmen und nicht jedes Paket blindlings herunterzuladen. Schließlich sollte doch ein zentrales und vor allem sicheres Paketmanagement Linux von anderen Betriebssystemen positiv unterscheiden.
Aktuelle Neuigkeiten von Wine in Debian
Update: Das lange Warten auf ein neues Wine in Debian hat ein Ende.
Erst kürzlich bin ich beim Lesen von debian-devel, der Mailingliste der Debianentwickler, auf eine interessante Frage gestoßen. Jemand interessierte sich für den Status der bekannten Wine-Software in Debian. Seit geraumer Zeit sind die Pakete in Debian auf einem sehr alten Stand und idealerweise wäre das stabile Wine 1.2 die aktuellste Version in Debian Squeeze und 1.3 bereits in Unstable.
Klarheit schaffte dann schon nach kurzer Zeit der Paketverwalter von Wine selbst. Zum einen gab es bis vor kurzem Lizenzprobleme im Upstream-Paket Wine-Gecko, welches in Übereinstimmung mit Debians Gesellschaftsvertrag gebracht werden musste. Offensichtlich dauerte diese Überprüfung bis zum letzten Monat an und auch für die Kompilierung notwendige Pakete wie gcc-mingw32 mussten zuerst angepasst und aktualisiert werden. Ein älterer Fehlerbericht, der dieses Problem beschreibt, befindet sich hier.
Dazu kommt eines der verbreitetsten Probleme überhaupt - Zeit. Scheinbar gibt es mit Ove Kaaven nur einen Betreuer dieses umfangreichen Pakets. Es fehlt schlicht an Menpower. Alles in allem ließ er durchscheinen, dass er eventuell schon ab Oktober wieder an dem Paket arbeiten kann und es sogar schon für Multiarch vorbereitet. Spätestens zum Erscheinen von wheezy solle es fertig sein. 😉
Bis dahin gibt es noch die inoffiziellen Winepakete von Kai Wasserbäch, die aber nur für den Unstable-Zweig von Debian vorliegen. Sie waren zuerst nur als Testplattform gedacht um Fehlerberichte besser an das Entwicklerteam von Wine adressieren zu können. Wer sich nicht vor etwas Handarbeit scheut, kann auch versuchen Wine einmal selbst zu kompilieren. Das Ganze ist nicht wirklich schwierig. Wer es gleich richtig machen möchte, kann sich auch direkt ein Paket nach Debian-Art erstellen.
Debians Alternativen-System
Linux große Stärke ist die Vielfalt an verschiedenen Anwendungen. Auf jedem System lassen sich parallel mehrere Browser, E-Mail Clients, Editoren oder auch Pager installieren.
Ich hatte schon most als meinen bevorzugten Pager vorgestellt. Hat man zusätzlich noch less installiert, lassen sich die beiden mit Debian und seinen Derivaten mit Hilfe von update-alternatives als voreingestelltes Programm für einen Pager austauschen.
update-alternatives --display pager
update-alternatives --config pager
Mit den beiden Parametern lassen sich zum einen mehr Informationen über die Gruppe "pager" anzeigen und zum anderen die Alternativen hierfür neu festlegen. Nach der Auswahl der voranstehenden Zahl wird der symbolische Link von pager z.B. auf less gesetzt.
In der Regel wird die Einstellung automatisch bei der Installation des entsprechenden Softwarepakets vorgenommen. Mit update-alternatives lässt sich das jederzeit auch nachträglich manuell wieder ändern.