Author: apo

Posted on

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.

Posted on

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.

  1. Cmus als .deb Paket manuell oder mit apt herunterladen
  2. 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.

Posted on

Slitaz und der Thinkpad 600 kurz und knapp

Keine Angst ich werde nun nicht jeden zweiten Tag (sagen wir jeden dritten) eine andere Distribution vorstellen, die sich auf dem Thinkpad 600 installieren lässt. Ich muss auch gar nicht mehr so ins Detail gehen, denn im Prinzip haben schon Debian und ConnochaetOS gezeigt, dass es ohne viel Aufwand möglich ist den Thinkpad 600 in Betrieb zu nehmen.
Für Slitaz interessiere ich mich nun schon seit einem Jahr und die kleine Linuxdistribution macht wirklich Spaß. Damit ich noch in einem Jahr weiß, was ich beachten muss, hier eine kurze Liste.

Vorbereitung

Alles begann wieder mit dem Download der Slitaz-LoRAM-Version, die lediglich 80 MB RAM voraussetzt. Um keine CD unnötig zu verbrennen und meinem alten 128 MB USB-Stick noch eine sinnvolle Rolle zukommen zu lassen, habe ich die ISO-Datei mit Hilfe von Tazusb wieder auf den Stick geschrieben. Mit Hilfe von Plop ging es dann in eine Liveumgebung.

Installation

Slitaz benutzt hier und auch nach der Installation den generischen VESA-Treiber, so dass die Auflösung noch nicht optimal ist. Das System lässt sich aber bedienen und man kann auf die Konsole oder in den Terminalemulator wechseln.
Bei meinem Setup (/dev/sda1 = Swap, /dev/sda2 = Debian und /dev/sda3 = Slitaz) und nur 128 MB RAM sollte man am besten die Swap-Partition vor der Installation von Slitaz aktivieren.

swapon /dev/sda1

Die Slitaz-Installation lässt sich wie gehabt mit slitaz-installer starten. Die Root-Partition ist dann natürlich /dev/sda3. Soweit so gut, die Installation ist wirklich unkompliziert und die Fragen des Installers sind leicht beantwortet. Sollte es eine Fehlermeldung wie "rootfs" nicht gefunden geben, hilft eventuell dieser Beitrag weiter.
Nach dem Reboot sollte als erstes die Grafikkarte mit dem richtigen Treiber angesprochen werden. Neomagic ist hier das Zauberwort. Das entsprechende Paket bei Slitaz heißt xorg-xf86-video-neomagic. Anschließend muss noch in der /etc/X11/xorg.conf in der "Driver"-Zeile vesa durch neomagic ersetzt werden. Fertig.
Nach einem Neustart sind die grafischen Beschränkungen des Vesa-Treibers aufgehoben und man kann sich auf die volle 1024x768 Pixel Auflösung stürzen. 😉

Sound

Ganz so einfach wie bei Debian und ConnochaetOS war es mit dem Einrichten der Soundkarte nicht. Erneut muss man wieder etwas alte ISA-Magie und Modprobe-Zauberei anwenden.
Nachdem ich mir die entsprechende Zeile ergoogelt hatte, trug ich alles in /etc/init.d/local.sh ein.

modprobe snd-cs4236 port=0x530 cport=0x538 irq=5 isapnp=0 dma1=1 dma2=0

Slitaz Hauptkonfigurationsdatei

In /etc/rcS.conf landen viele wichtige Slitazeinstellungen. Um die neue ASUS WL-107G WLAN-Karte nach jedem Reboot automatisch in Betrieb zu nehmen, genügt es das entsprechende Modul in der "LOAD_MODULES"-Zeile einzutragen.

LOAD_MODULES=" yenta_socket rt2500_pci"

Fazit

Slitaz Installationsschritte sind potentiell einfacher. Dafür richtet Slitaz weder die Neomagic-Grafikkarte noch die urtümliche ISA-Soundkarte automatisch ein. Etwas Nachhilfe ist erforderlich. Absolut umwerfend ist aber der geringe Verbrauch an Festplattenspeicher für all die Programme, die standardmäßig bei Slitaz installiert werden (<150MB). Immer dort, wo Festplattenspeicher noch eine Rolle spielt, spielt Slitaz seine Stärken aus. Genauso wie bei ConnochaetOS ist die Auswahl an vorkompilierten Paketen begrenzt, aber zum Anfang vermisst man die wichtigsten Programme auch nicht. Halten wir mal fest: Debian, ConnochaetOS, Slitaz auf dem Thinkpad 600 versus Müllgrube irgendwo in Afrika: 3:0

Posted on

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.

Posted on

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.

Posted on

Was bedeutet Freiheit?

Bei meiner Installation von ConnochaetOS kam ich bei dem Versuch meine WLAN-Karte in Betrieb zu nehmen zum ersten Mal mit dem Begriff "deblobbed" in Kontakt, was mich später dazu veranlasst hat ernsthafter darüber nachzudenken, was ich persönlich unter Freiheit und Freier Software verstehe und ob ich es damit bisher ernst gemeint habe.
Während meiner Suche stieß ich auf einen längeren Thread im Forum von ConnochaetOS, der sich ebenfalls mit der Thematik beschäftigte. Hier wurde eine Reihe von interessanten Aussagen getroffen, sowohl von Nutzern von ConnochaetOS als auch vom Hauptentwickler des Projekts Henry Jensen. Einige interessante Kernaussagen waren:

  1. WLAN- und USB-Adapter mit Freien Treibern sind verfügbar und bezahlbar. Es sollte kein Problem sein diese zu beschaffen. (Henry Jensen)
  2. Das offizielle Forum einer Freien Linuxdistribution sollte keine Ratschläge beinhalten, wie man ein unfreies Programm zum Laufen bringen kann. ( Richard Stallman Zitat aus einer E-Mail an Henry Jensen)
  3. Wenn Leute ConnochaetOS den Rücken kehren, weil es eine Freie Linuxdistribution ist, dann schätzen diese Leute ihre Freiheit nicht besonders. (Henry Jensen)

1. WLAN- und USB-Adapter mit Freien Treibern sind verfügbar und bezahlbar.

Wirklich, ich habe es versucht.
Da war zum einen meine WG511T WLAN-Karte von Netgear, bei der ich irrtümlich annahm, dass ein freier Treiber zur Verfügung stand, sie aber mit dem Modell WG511 und eben ohne T verwechselte. Das führte dazu, dass ich vor drei Jahren dann den Madwifi-Treiber selbst kompilieren musste. Das Problem löste sich schließlich von selbst als die Karte kaputt ging.
Beim nächsten Mal sollte alles besser werden. Ich wollte nun mit einem USB-Modell im Internet surfen und guckte mir dafür den Fritz-WLAN-USB-Stick von AVM aus. Hier wusste ich zwar, dass der Treiber proprietär war, fand es aber vertretbar, dass der Hersteller Linux unterstützte und zumindest einen eigenen Linuxtreiber anbot. Leider ahnte ich damals nicht, dass der Treiber nicht weiterentwickelt werden sollte und dazu noch Probleme verursachte, die mit den Windowstreibern nie auftraten, weswegen ich zu Ndiswrapper greifen musste.
Schließlich landete ich bei einer PCMCIA-WLAN-Karte von Linksys, die unter Linux mit dem Treiber b43 angesprochen werden kann. Leider ist die Firmware hierzu unfrei.
Ich denke Henry Jensen hat recht, wenn er behauptet, es sei kein Problem eine PCMCIA- oder USB-WLAN-Karte zu besorgen, die mit freien Treibern funktioniert. Man muss nur ein paar gute Quellen kennen, die einem den Kauf erleichtern und man sollte vor dem Kauf haargenau auf den Modellnamen schauen. Dabei spielt der Name des Herstellers weniger eine Rolle als der verwendete Chipsatz, der selbst bei ähnlich klingenden Produkten immer wieder anders sein kann.
Ich habe mich noch einmal nach Hardware mit Freier Software umgeschaut und daraufhin die PCMCIA-WLAN-Karte von Asus, Modell WL-107G mit Ralink-Chipsatz und zwei PCMCIA-zu-LAN-Karten von 3com gekauft. Das war dann zum einen das Modell Megahertz 3CCFE574BT und 3CCFE575CT. Ein weiterer positiver Effekt: Mit dem Erlös des alten WLAN-USB-Sticks von AVM konnte ich mir zwei der neuen Karten finanzieren. 6,95 € für das Asus-Modell waren auch nicht wirklich teuer.
Diese Links haben mir weitergeholfen:

Für ältere Notebooks mit PCMCIA-Slot ist deshalb der Netzzugang oft kein Problem. Problematisch wird es erst, wenn die Komponenten im Rechner integriert sind und sich schlecht austauschen lassen.

2. Das offizielle Forum einer Freien Linuxdistribution sollte keine Ratschläge beinhalten, wie man ein unfreies Programm zum Laufen bringen kann.

Was ist eine Freie Linuxdistribution eingentlich? GNU.org hat hierzu eine klar definierte Meinung. Aus den vier grundlegenden Freiheiten wird die Vorgabe abgeleitet, dass jedwede Dokumentation, die hilft unfreie Software auf einem System zu installieren oder die Vorzüge einer solchen Installation hervorhebt schlicht eine Freie Linuxdistribution disqualifiziert, was dazu führt, dass die Liste der nach GNU Definition Freien Distributionen sehr überschaubar ist.
Warum ist Debian GNU/Linux nicht darunter? Immerhin ist Debians Linuxkernel genauso wie der von ConnochaetOS vollkommen von unfreien Firmware Blobs befreit und der "Main"-Bereich des Produkts Debian besteht ausschließlich aus Freier Software. Nach GNU.org lautet das ausschlaggebende Argument gegen Debian, dass es möglich ist, die zusätzlich auf den Projektservern gehostete unfreie Software zu installieren oder sich darüber zu informieren.
Ich denke die Freie Software Bewegung hat Richard Stallman viel zu verdanken und seine vier definierten Softwarefreiheiten kann ich auch genauso unterschreiben. Ich widerspreche ihm aber in seinem Menschenbild. Freiheit bedeutet für mich auch, die Freiheit zu haben sich über Alternativen informieren zu dürfen und sich zur Not auch gezielt für unfreie Software zu entscheiden. Die Frage ist doch, benutzen mehr Menschen freie Software, weil sie davon überzeugt sind oder weil sie weniger über unfreie Software wissen? Anstatt die Möglichkeiten von Benutzern willkürlich einzuschränken, finde ich es besser die Entscheidung über die Installation freier oder unfreier Software dem Menschen vor dem Computer zu überlassen, ihnen nicht einen Weg zu diktieren sondern viel stärker auf Aufklärung und Information zu setzen.

3. Wenn Leute ConnochaetOS den Rücken kehren, weil es eine Freie Linuxdistribution ist, dann schätzen diese Leute ihre Freiheit nicht besonders.

ConnochaetOS kann genauso wie das GNU-Projekt jederzeit Regeln und Richtlinien festlegen, was ihrer Meinung nach Freiheit in Sinne von Softwarefreiheit bedeutet. Wer in dem Club nicht mitspielen möchte, muss es nicht. Das Ziel ältere Rechner zu unterstützen und gleichzeitig einen Linux-Libre-Kernel zu benutzen kann sich aber leicht ausschließen. Wo zieht man hier die Grenze? ConnochaetOS hat sich klar dafür entschieden im Zweifelsfall die GNU-Richtlinien vorzuziehen und damit auf Kompatibilität zu verzichten. Hoffentlich zahlt sich das irgendwann wenigstens durch eine Aufnahme in die GNU-Liste der Freien Distributionen aus.
Es ist einfach ein Freund von Schwarz-und-Weiß-Denken zu sein. Doch im Zweifelsfall entscheide ich mich lieber für die weitere Benutzung meiner Hardware anstatt sie auf den Müll zu werfen. Ich schätze meine Freiheit. Ich lehne nur diese aufgezwungene Freiheit ab, die zwar mein Bestes will, aber im Prinzip mich genauso einschränkt wie ein unfreies System und darüber hinaus im schlimmsten Falle den Rechner nutzlos macht.
Die einzige Distribution, die meiner Vorstellung von Freiheit am nächsten kommt ist Debian, wo ich standardmäßig ein freies Betriebssystem habe, das mir alle Freiheiten gewährt, ich aber nicht daran gehindert werde unfreie Komponenten zu installieren, wenn ich sie denn tatsächlich brauche. Die Entscheidung treffe ich und nicht das Betriebssystem.
Warum nicht das Ganze anders herum aufzäumen und hervorheben, dass es ohne Freie Software überhaupt keine aktuelle Software mehr für Rechner aus dem Jahre 1998 gäbe. Der Support für Windows 98 ist eingestellt. Es wird keine Windowssoftware mehr für diese Plattform geschrieben, geschweige denn neue Treiber entwickelt. Das sollte vermarktet werden.

Fazit

Es ist mit geringem Aufwand möglich Computerzubehör wie WLAN-Karten zu kaufen, deren Treiber auch als Freie Software vorliegen. Ich glaube nicht, dass man eine "bessere" Welt erschafft, indem man Menschen zu ihrem eigenen Glück zwingt. Es ist besser sich darauf zu konzentrieren die Dokumentation zu Linux zu verbessern und neue Freie Software zu schreiben als Freiheit zu predigen. Wer sich auch nur ein wenig für Technik interessiert kommt irgendwann selbst zur Einsicht wie wichtig freie, offene und transparente Standards sind. Und wer das nicht kann oder möchte, den muss man lassen. Auch das ist Freiheit.

Posted on

Erfahrungen mit ConnochaetOS auf dem Thinkpad 600

Am 11. August 2011 wurde ConnochaetOS in der finalen Version 0.9 freigegeben. Ich hatte im Juni schon über meinen ersten Eindruck berichtet und wollte nun diese Distribution auf dem Thinkpad 600 ausprobieren. Da die damalige RC-Version schon gut funktionierte, verzichtete ich auf den erneuten Download. Das System lässt sich natürlich später immer noch über den Paketmanager Pacman anpassen.
Bevor ich über die Erfahrungen erzähle, muss ich erst noch erklären, was ich mir bei der Aufteilung der Festplatte gedacht hatte. Ich wollte nicht jedes mal eine bestehende Installation überschreiben und partitionierte die Festplatte so, dass es eine Swap- und Root-Partition für Debian gab und noch eine dritte Partition für den Testkandidaten. Ich weiß, eine zusätzliche Bootpartition wäre sicher nicht verkehrt gewesen, aber ich wollte es so einfach wie möglich haben. Leider kommt bei nur 128 MB RAM ein komplettes Festplattenbackup mit Clonezilla nicht mehr in Frage. Doch auf der anderen Seite ist Clonezilla auch "nur" eine ausgeklügelte Oberfläche für diverse Backup-Werkzeuge, weswegen ich für später entschieden habe Partition Nr.3 von meiner bestehenden Debian-Installation mit Hilfe von partimage zu sichern.

Die Installation

Mittlerweile habe ich schon einige Installationen mit Arch Linux bzw. ConnochaetOS hinter mir. An die Textinstallation gewöhnt man sich schnell. Sie bietet an einigen Stellen im Gegensatz zum Debian-Installer etwas zusätzliche Kontrolle und ist insgesamt sehr logisch aufgebaut. Wenn man Erfahrung mit linuxtypischen Begriffen hat sind die Hürden eher gering. Als Nachteil empfinde ich nur, dass die Installation auf Grund des K.I.S.S. Prinzips nur in Englisch durchgeführt werden kann und dass es keine Option gibt um die gesamte Festplatte wie bei Debian schon bei der Installation mit dm_crypt zu verschlüsseln. Am besten ihr bildet euch eine eigene Meinung. Die gesamte Installation wird auf der ConnochaetOS Seite in Bild und Text und sogar mit Videos erklärt. Am einfachsten ist es sicher auf die umfangreiche Dokumentation von Arch Linux zurückzugreifen z.B. auf die Anleitung für Einsteiger. Alles in allem verlief die Installation von ConnochaetOS problemlos.

Hardwareerkennung

Hier verdient sich ConnochaetOS ein großes Lob. Nach dem Reboot wurden alle Hardwarekomponenten des Laptops ausnahmslos erkannt und eingerichtet. Weder die Neomagic-Grafikkarte noch die sehr alte CS4237B-ISA-Soundkarte waren ein Problem und wurden automatisch so konfiguriert, dass man sofort mit einer Auflösung von 1024x768 in den Desktop startete und nach der Justierung der Lautstärke mit dem Programm alsamixer oder aumix Musik hören oder Videos abspielen konnte. Auch das Einrichten des Framebuffers mit dem Neofb-Treiber und die richtige Einstellung der Auflösung auf der Konsole geschah automatisch. Hier ist ConnochaetOS sogar benutzerfreundlicher als Debian.

Software

Während man bei Arch Linux nach der Installation beginnt das System Schritt für Schritt an die eigenen Bedürfnisse anzupassen, bietet ConnochaetOS passend für die Zielgruppe, ältere Computer, sinnvolle Voreinstellungen und eine gute Auswahl ressourcenschonender Software. Neben dem Webkit-Browser xxxterm gibt es sowohl Anwendungen für Büroarbeit, Bild- und PDF-Betrachter, Editoren, ein E-Mail-Programm und Software zum Abspielen von Musik und Videos. Für allgemeine Computeraufgaben und zum Surfen im Internet sind die Programme vollkommen ausreichend.
ConnochaetOS basiert zwar auf Arch Linux, hat aber alle Anwendungen für die i586 Architektur optimiert. Der Softwareumfang ist dadurch geringer und bei weitem nicht so groß wie bei Debian. Ist man also Debian gewohnt, muss man hier entweder Kompromisse eingehen oder sich im Forum von ConnochaetOS umsehen. Einige Teilnehmer bieten dort ihre selbst übersetzten Pakete zum Download an. Auch ein hier oft zitierter K.Mandla war dort kurzzeitig unterwegs und hat einige nützliche Informationen hinterlassen.
Als ConnochaetOS-Benutzer hat man zwei Möglichkeiten. Entweder man lädt die schon übersetzten Pakete manuell oder mit dem Paketmanager Pacman herunter. Die andere Möglichkeit wäre mit Hilfe des archtypischen Programms makepkg und einem sogenannten PKGBUILD sich das gewünschte Programm selbst zu bauen. Da ich hier selbst noch am Anfang stehe, verweise ich nur auf die Einträge im Arch Wiki. Die Dokumentation hierzu ist gut und das Ausprobieren hat bisher Spaß gemacht. Noch einfacher geht es, wenn man dem schon bereiteten Pfad folgt und sich K.Mandlas PKGBUILDS und Software herunterlädt.
Am Ende installierte ich noch scrot, um ein Bildschirmfoto machen zu können. Gerne gesehen hätte ich auch Osmo und MTPaint und einige meiner Konsolenfavoriten.

Netzwerk

Man hat die Wahl das Netzwerk manuell z.B. in der /etc/rc.conf einzurichten oder den grafischen Netzwerkmanager Wicd dafür zu benutzen. Als ich letzteren im Menü wählte, tat sich erst einmal gar nichts. Hierzu musste man wissen, dass der Wicd-Daemon zuerst gestartet und die rc.conf angepasst werden muss. Die entscheidende Zeile sah bei mir dann so aus:

DAEMONS=(metalog netfs crond dbus wicd sshd)

Wer später auch einen SSH Server installieren möchte und vom eigenen Server abgewiesen wird, sollte in die /etc/hosts.deny schauen und die Zeile ALL: ALL: DENY löschen oder auskommentieren.
Nun wollte ich zuerst meine WLAN-Karte von Linksys mit dem Kerneltreiber b43 einrichten. Als ich die hierfür unfreie Firmware an den richtigen Ort kopiert hatte rührte sich aber nichts. Nach einem Blick in das Log mit dmesg stieß ich zum ersten Mal auf den Begriff "deblobbed". Kurzum der Libre-Kernel von ConnochaetOS widersetzt sich jeder unfreien Komponente und verhindert das Laden dementsprechender Firmware. Mittlerweile besitze ich aber Hardware mit freien Treibern, weswegen sich dieses Problem später aufgelöst hat. Mehr dazu im nächsten Beitrag.

Der Desktop

ConnochaetOS setzt auf IceWM als Fenstermanager. Um die Konfiguration anzupassen sollte man die Dateien aus /usr/share/icewm nach ~/.icewm kopieren. Ein neues Thema von box-look.org lässt sich ganz leicht installieren, indem das Verzeichnis nach ~./icewm/themes/ entpackt wird. Dieses wird dann wie bei IceWM gewohnt im Anwendungsmenü unter Einstellungen ausgewählt. Und so sieht ConnochaetOS mit dem zur Zeit am besten bewerteten "Elegance" Thema aus.

ConnochaetOS in Debians GRUB Menü eintragen

Die automatische Erkennung mit Hilfe von os-prober ist bei mir fehlgeschlagen. Manuell lässt sich ConnochaetOS bei Debian in der Datei /etc/grub.d/40_custom einbinden. Je nach dem mit welcher Methode man seine Festplatten einhängen möchte, muss die "root"-Zeile angepasst werden und die UUID geändert werden. Anschließend noch einmal update-grub ausführen.

menuentry "ConnochaetOS" {
set root=(hd0,3)
linux /boot/vmlinuz26-libre-lts root=/dev/disk/by-uuid/f8966bb4-ff65-478e-9032-8da14ad1077c rootflags= rootfstype=ext3 ro
initrd /boot/kernel26-libre-lts.img
}

Fazit

Ich empfand die Installation insgesamt als unkompliziert. Auf diesem speziellen IBM-Laptop war die Hardwareerkennung sogar exzellent. Auch die vorinstallierte Software ist für Otto-Normal-Benutzer ausreichend und verhält sich trotz des fortgeschrittenen Laptopalters von 13 Jahren immer noch angenehm schnell. Einziges Manko ist die geringe Auswahl an zusätzlichen Softwarepaketen. Hier muss man Eigeninitiative beweisen oder sich am besten im Forum von ConnochaetOS mit Gleichgesinnten austauschen.
Als zusätzlichen Bonus erhält man eine nach den GNU-Richtlinien freie Linuxdistribution. Wer Hardware mit unfreien Komponenten besitzt stößt hier aber schnell auf Probleme. Im schlimmsten Fall gibt es keine Hardwareunterstützung, weil der Libre-Kernel nur ausschließlich Freie Software unterstützt. Insgesamt macht es Spaß ConnochaetOS auf dem alten Laptop zu benutzen und ich kann guten Gewissens sagen, dass die Software den Rechner nicht überbeansprucht. Die Speicherauslastung nach einem Neustart liegt bei ca. 40 MB.

Posted on

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

Posted on

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.

Posted on

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.