planetknauer.net

Du kommst nach Hause. Der Homeserver ist nicht pingbar. Der angeschlossene Monitor bleibt schwarz. Nur der Reset-Knopf hilft. Ja sind wir denn hier bei Windows???

Piept. BIOS. Grub:

GRUB loading.
Welcome to GRUB!

error: incompatible license.
Entering rescue mode...
grub rescue>

dafuq? Nochmals. CTRL-ALT-DEL. Piept. BIOS. Grub. Grub Menü kommt. Kernel bootet. Waiting for /dev to be fully populated... dauert ewigs.

Dann die Meldung, dass /proc/sys/net/ipv6/conf/br0/autoconf nicht existiere und br0 darum nicht gestartet werden könne. br0 besteht aus eth0, hängt in der DMZ und wird für einige virtuelle Maschinen benötigt. Also, die Befehle zur Deaktivierung von ipv6-autoconf auf br0 in der /etc/networ/interfaces wieder rausgenommen, somit wird br0 halt den ipv6-Traffic der Maschine stören. Halb so wild für den Moment.

Nächster Spass: bond0 mit eth1 und eth2 zickt. Gemäss ifconfig -a gibt's auch kein eth2 in meinem System. Aber dmesg | grep eth2 meldet:

[ 2.328476] r8169 0000:0a:00.0 eth2: RTL8168c/8111c at 0xffffc90011b7c000, 00:e0:4c:69:75:28, XID 1c2000c0 IRQ 51
[ 2.328480] r8169 0000:0a:00.0 eth2: jumbo features [frames: 6128 bytes, tx checksumming: ko]
[ 98.151541] bonding: bond0: interface eth2 does not exist!

Aaaargh, was soll denn die Scheisse??? (ich vermute mal, dass die Dual-NIC mit eth1/eth2 hardwaremässig im Arsch ist...)

Also mal mit einer grml Live-CD gebootet. Alles bestens, eth1 und eth2 sind da, bonding lässt sich problemlos von Hand einrichten. Gut, nochmals in Debian booten. eth2 ist weiterhin nicht verfügbar... ääääh wie bitte? Also gut. Shutdown und Kaltstart. Tadaa, plötzlich ist alles wieder gut.

Was zum Teufel war das?

Egal, was man in /etc/profile.d/mycustomfile.sh definiert... Debian mit XFCE und lightdm liest es nicht ein. Dies ist offiziell so gewollt. Da gilt: korrekt konfigurieren. Da niemand so wirklich weiss, wie's geht, gilt: ausprobieren bis es klappt.

Der korrekte Weg:
erstelle eine Datei mit den nötigen export-Statements im Verzeichnis /etc/profile.d/ - wichtig ist, dass die Datei auf .sh endet. Aus Sicherheitsgründen sollte sie root gehören und auch nur durch root beschreibbar sein (chown root:root /etc/profile.d/* und chmod o-w /etc/profile.d/*). Der Dateiinhalt schaut dann z.B. so aus (der Rest meines Systems ist amerikanisch kolonialisiert mit en_US.UTF-8):

export LC_PAPER=de_CH.UTF-8
export LC_MEASUREMENT=de_CH.UTF-8
export LC_TIME=de_CH.UTF-8
export LC_MONETARY=de_CH.UTF-8
export EDITOR=vi

Als nächstes muss /etc/profile durch $HOME/.profile eingelesen werden. Dazu fügt man in die Datei folgende Zeile ein:

. /etc/profile

Damit auch grafische Anwendungen die Umgebungsvariablen mitbekommen, muss $HOME/.profile nun durch $HOME/.xsessionrc eingelesen werden. Wenn die Datei nicht existiert, kann man sie einfach mit folgendem Inhalt erstellen:

. $HOME/.profile

Somit hat man eine konsistente Profilumgebung in allen Konsolen und in grafischen Anwendungen.

Vorsicht, ~ für $HOME und source für . sind reine Bash-Aliase und dürfen nicht verwendet werden! Das ist die grosse Stolperfalle, welche es zu umgehen gilt und die so ziemlich überall unerwähnt bleibt (im Debian-Bugreport wie auch in diesem ansonsten hilfreichen Beispiel werden diese Bashismen verwendet)

Wichtig ist natürlich, dass die locale-Definitionen existieren. Unter Umständen müssen diese erst über den Befehl dpkg-reconfigure locales aktiviert und generiert werden.

Bis vor kurzem dachte ich, dass Infrarot an sich eine tote Datenübertragungstechnologie der Technikantike sei. Seit PDAs durch Smartphones ersetzt wurden und für die drahtlose Übertragung generell Bluetooth oder das omnipräsente WLAN genutzt wurden, welche den Vorteil haben, dass keine direkte, ungestörte Sichtverbindung bestehen muss, sind infrarotfähige Geräte eher selten geworden. Witzigerweise unterstützen die neusten Samsung-Telefone wieder Infrarot, mein altes S3 tut dies jedoch nicht.

Doch dann habe ich meinen ersten Tauchcomputer gekauft. Dieser war Teil eines preisgünstigen Komplettpakets inkl. Regulator. Wichtiges Kriterium war die Unterstützung durch Subsurface, damit ich die Tauchgänge auch mit meinen Linux-Computern auswerten kann. In der Tat steht das Gerät auf der Kompatibilitätsliste. Daher habe ich da auch gar nicht länger über das Übertragungsprotokoll informiert und sofort eingekauft.

Kaum angekommen wurde das Gerät ausgepackt und oh! Kein USB-Kabel mit dabei? mmmh, wie überträgt es dann? Oho, das Handbuch besagt Infrarot!? Was nun?

Nach kurzer Suche habe ich in meinem Hardware-Fundus ein altes IrDA-USB-Dongle wiedergefunden. Dies lag 10 Jahre lang unbenutzt umher, da es nicht durch lirc, die Linux-Software für Infrarot-Fernsteuerungen unterstützt wird. Dieses also auf Verdacht in den PC eingesteckt, den Tauchcomputer mit der Infrarot-Schnittstelle in Sichtweite hingelegt, Subsurface gestartet und den korrekten Tauchcomputer eingestellt. Sehr positiv: Subsurface stellt automatisch die korrekte serielle Schnittstelle (/dev/ttyS3) ein. Dann noch in Subsurface auf den "Importieren"-Knopf gedrückt und... der Tauchcomputer piept und Subsurface zeigt einen Fortschrittsbalken an. DAS ist doch mal ein positives Zeichen.

Wenn der Import nicht funktioniert, müssen folgende zwei Dinge geprüft werden: Erstens muss der Benutzer Mitglied in der Gruppe "dialout" sein. Zweitens muss unter Debian das Paket irda-utils installiert sein.

Doch wieso funktioniert mein IrDA-Adapter nicht mit lirc? Nun, für Fernbedienungen muss ein weiteres Protokoll, CIR, unterstützt werden. Mein Adapter vom Typ mcs7780 beherrscht aber wie fast alle USB-Adapter nur SIR, MIR und FIR und kann im Gegensatz zu seriellen Adaptern auch nur schwerlich manipuliert werden.

Welcher Adapter sollte nun gekauft werden? Das hängt natürlich primär vom Tauchcomputer ab, und welche Transfermodi dieser unterstützt. Leider schweigt sich der Hersteller in meinem Fall diskret aus (Nachtrag: Im Computer selbst kann der Tranfermodus zwischen Lo und Hi umgestellt werden - somit dürften SIR und FIR unterstützt sein). Generell scheinen die Adapter im Handel selten geworden zu sein und die Modellvielfalt ist eher gering. Gut verfügbar sind die Modelle von Polar für deren Uhren. Diese sind aber meiner Meinung nach unverhältnismässig teuer und unterstützen u.U. nur SIR. Generell sollte man daher immer zu einem Modell greifen, das alle drei gängigen Modi unterstützt.
Welche Modelle von Linux unterstützt werden, ist ebenfalls eher schwierig in Erfahrung zu bringen. Die verfügbaren Dokumentationen sind uralt und stammen teilweise aus Zeiten von Kernel 2.4. Und natürlich halten die Hersteller der Dongles in ihren Werbebroschüren oft geheim, welche Chips sie verbauen.

Fazit (tl;dr): Aus meiner Erfahrung ist klar, dass der Moschip msc7780 von Linux bestens unterstützt wird und für Datenübertragungen mit den meisten Infrarot-Endgeräten funktionieren sollte.

Als neues Spielzeug habe ich mir eine per Netzwerk schaltbare Steckerleiste besorgt, um abgestürzten Raspberries und ähnlichen Geräten auch aus der Ferne einen Neustart zu ermöglichen. Für die Steuerung gibt es ein Webinterface, eine proprietäre Software für ein proprietäres Betriebssystem und eine Handy-App, wofür das Gerät zum Server des Herstellers verbinden muss. Für eine Automatisierungslösung auf der Linux-Konsole muss daher etwas Kreativität und ein paar Zeilen Shellcode her. "Glücklicherweise" ist das Webinterface mit der ganz heissen Nadel gestrickt und Security als überflüssige Geldverschwendung abgetan worden, daher ist das Skript recht simpel ausgefallen:

#!/bin/bash
HOST="192.168.0.x"
PASSWORD="foo"
OUTLET=$1
STATE=$2
curl -sd "pw=$PASSWORD" http://$HOST/login.html | fgrep -q Status
if [ $? -eq 0 ]; then
curl -sd "ctl$OUTLET=$STATE" http://$HOST/status.html | fgrep -q Status
fi
curl -s http://$HOST/login.html | fgrep -q password

Das Skript legt man z.B. unter /usr/local/bin/gembird.sh ab und gibt ihm Ausführungsrechte (chmod +x). Anschliessend lässt es sich aufrufen via gembird.sh dosennummer neuer_zustand, also z.B. gembird.sh 4 0 um die vierte Dose auszuschalten.

Die Hauptarbeit des Webinterface-reverse-Engineerings hat zum Glück schon ein Kritiker auf Amazon übernommen, da der offizielle Herstellersupport nicht sehr hilfreich war. Merke: nächstes Mal die Frage stellen in der Art "ich möchte in Windows unter Cygwin..."

Erst den USB-Stick präparieren:

dd if=/dev/zero of=/dev/sdb bs=512 count=1
mkfs.vfat -F32 -I /dev/sdb
syslinux /dev/sdb
mount /dev/sdb /mnt/temp
cd /mnt/temp
tar -jxf /tmp/apu_tinycore.tar.bz2

Danach das APU vom USB-Stick booten und das BIOS updaten:

cd /mnt/sda
flashrom -w apu140405.rom
poweroff

Bonding ist super: mehrere Netzwerkkarten können zu einer zusammengefasst werden, um Geschwindigkeit oder Ausfallsicherheit zu erhöhen. In meinem Fall wollte ich einfach etwas mehr Speed für virtuelle Maschinen.

An sich ist die Konfiguration super simpel und gemäss Debian Wiki vorzunehmen. Das funktioniert mit dem Bonding-Mode balance-rr u.U., aber nicht mit virtuellen Maschinen, wenn diese mit dem Bonding-Interface an eine Bridge gehängt werden. Das resultierte in meinem Fall in:

br1: received packet on bond0 with own address as source address

Die Empfehlung lautet, stattdessen den Modus 802.3ad zu verwenden, sofern vom Switch unterstützt. Bei meinem Procurve 1810G muss dazu unter Trunks -> Trunk Configuration ein Trunk mit Mode "LACP Active" erstellt werden. Diesem werden alle Switchports zugewiesen, woran die im Bond verwendeten Netzwerkkarten hängen.

Damit nun das Bonding-Interface mit 802.3ad auch richtig initalisiert wird, fehlt dem System u.U. noch das Paket "ethtool", welches ebenfalls installiert werden muss:

aptitude install ethtool

Eine Kontrolle von /proc/net/bonding/bond0 zeigt, dass das Bonding-Interface jetzt korrekt hochfährt und die Slave-Interfaces einbinden kann (MII Status: up)

Als ich meinen Desktop und Server zusammenstellte, hatte ich bewusst für beide Geräte das gleiche Mainboard verwendet. Somit muss ich alle Mainboard-bedingten Probleme nur einmal lösen. Soweit hat das alles ganz gut funktioniert, aber unterdessen hat der Hersteller ein paar BIOS-Updates herausgegeben, welche Performance und Stabilität (nicht, dass das ein Problem wäre) verbessern würden. Na dann, spielen wir die mal ein. Da das Board von flashrom unterstützt wird, geht das total simpel direkt von Linux aus.

Erst das alte BIOS sichern:

flashrom -r old-bios.rom

Dann das neue BIOS flashen:

flashrom -w new-bios-image.rom

Vor einigen Wochen war erst der Desktop fällig. Nach dem Neustart durfte ich feststellen, dass die MAC-Adresse der Netzwerkkarte sich geändert hatte. Das ist halb so wild, da wird die /etc/udev/rules.d/70-persistent-net.rules gelöscht oder modifiziert und anschliessend neu gestartet.

Heute war der Server dran. BIOS geflasht, die udev-Regeln gelöscht, neu gestartet, alles bestens. Per SSH versucht anzumelden. Geht nicht. hmmm. Mal die Netzwerkkarten geprüft. Alles bestens. Ping von Server und Desktop zu jedem anderen Host klappt, nur nicht untereinander. dmesg geprüft:

br0: received packet on eth0 with own address as source address

Nochmals genau hingeschaut und ifconfig eth0 auf beiden Maschinen eingetippt und die MAC-Adresse genauer angeschaut. Un-glaub-lich! Identisch auf beiden Kisten. Die Deppen bei Asus haben es doch tatsächlich fertiggebracht, ein BIOS-Image zu verteilen, in welchem die MAC-Adresse für die onboard-Netzwerkkarte hartcodiert ist! Ja ist es denn wirklich so viel zuviel verlangt, wenigstens ein Mal mit Profis (oder zumindest nicht komplett inkompeteten Amateuren) zu arbeiten???

Würgaround:

ifconfig eth0 hw ether 00:e0:12:34:56:77

Unter Debian macht man dies permanent durch einen Eintrag in der /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp
hwaddress ether 00:e0:12:34:56:77

Nicht mehr ganz so trivial wird das, wenn nun eth0 gebridged wird, damit KVM oder XEN Virtual Machines das Netzwerk mitbenutzen können. In diesem Fall ist eth0 nicht in der interfaces konfiguriert (bzw auf manual gesetzt), so dass jegliche Einträge aus der Sektion nicht gelesen werden. Hier muss der Konfiguration von br0 ein pre-up Befehl mitgegeben werden:

iface eth0 inet manual

auto br0
iface br0 inet static
pre-up ifconfig eth0 hw ether 00:e0:12:34:56:77
bridge_ports eth0
address 192.168.0.XXX
netmask 255.255.255.0
gateway 192.168.0.XXX

Leider hat sich meine letzte Anleitung nicht komplett bewährt. RTP über WLAN hat einen sehr grossen Nachteil: Das WLAN wird durch die 1.5Mbit RTP-Traffic komplett mit UDP-Paketen geflutet und überlastet. Egal was für ein Access Point mit egal welcher Firmware - die Latenzen gehen bis zur Unbenutzbarkeit hoch, sobald Musik läuft.
Mit direkter Punkt-zu-Punkt-Verbindung über Pulseaudio tritt das Problem jedoch nicht auf.

Daher habe ich eine neuere, viel einfachere Konfiguration erstellt, welche serverseitig keine Installation von Pulseaudio mehr erfordert. Etwas Hilfe von Onkel Google haben mich zu dieser Anleitung geführt, welche ich etwas vereinfacht und an meine Anforderungen angepasst habe. Eine direkte Umsetzung dieser Anleitung war in meinem Fall nicht zielführend, da der Pulseaudio-Client (bzw module-tunnel-sink) eine einmal abgebrochene Verbindung nicht wieder aufbauen kann. Es müsste serverseitig das komplette mpd/pulseaudio-Konstrukt neu gestartet werden, wenn sich der Client (Raspberry oder Desktop) kurz aus dem Netzwerk abmelden (Netzwerk-Hickup, Neustart o.ä.).

Die Lösung: mpd einfach direkt zum Sink-Server verbinden lassen.

Sink-Konfiguration (rc.local-Eintrag auf dem Raspi):

pulseaudio -D --log-target=syslog --start --realtime --load=module-native-protocol-tcp auth-anonymous=1 listen=0.0.0.0

Zu beachten ist, dass so jeder Rechner im Netzwerk Audiodaten an den Raspi streamen kann.
Sink-Konfiguration Klickibunti: papref starten und im Tab "Netzwerk-Server" die Häkchen bei "Enable network access to local sound devices" und den zwei darunter liegenden Boxen setzen.
mpd-Konfiguration:

audio_output {
type "pulse"
name "Desktop"
server "192.168.0.6"
sink "alsa_output.pci-0000_05_06.0.analog-stereo"
}
audio_output {
type "pulse"
name "Raspeakr"
server "192.168.0.11"
}

Bricht die Netzwerk-Verbindung doch mal ab, so ist spätestens nach dem nächsten Songwechsel wieder Lärm da.

Allerdings ist die Lösung auch nicht 100% perfekt, leichte Aussetzer können vorkommen.

Der WR841N v8 von TP-Link ist eigentlich gar kein schlechter Router für seinen Preis. Der Billigstheimer kommt mit ganz tauglicher Hardware daher und die Software ist eigentlich gar nicht sooo schlecht. Allerdings sind die Latenzen doch eher hoch und der Jitter untragbar. Zum Glück unterstützt die neuste Version von OpenWRT auch die neuste Revision des Geräts. Also auf, frische Firmware aufspielen. Nun gibt es zwei Images mit unterschiedlichen Dateisystemen, jffs2 und squashfs. Gemäss der Beschreibung schien mir jffs2 doch die bessere Wahl zu sein. Grosser Fehler, das jffs2-Image bootet nämlich nicht sauber, das Resultat ist ein unbrauchbarer Ziegelstein.

Was tun? Nun, man kann verzweifeln und in anbetracht des lächerlichen Preises ein Ersatzgerät bestellen oder sich vom Ehrgeiz packen lassen und den unbrick-Prozess starten. Dazu mussten als erstes die PINs in den Serial Header gelötet werden. Die Löcher sind praktischerweise schon da, aber die PINs waren wohl zu teuer. Na gut, Lötkolben her und los.

Danach wird das eigentlich für den Raspberry Pi angeschaffte serielle Konsolenkabel angesteckt. Das PIN-Layout ist identisch mit v7, nur um 90° verdreht. D.h. der alleinstehende PIN ist weiterhin TX. Entsprechend wird das Kabel nun angesteckt und mit einem PC verbunden. Da die Versorgung nun über den seriellen Port erfolgt, startet der Router auch sofort und per minicom lässt sich der Bootprozess mitverfolgen:

minicom --device /dev/ttyUSB0 -b 115200

Scheinbar hängt der Bootprozess beim laden der USB-Module (ohci_hcd). Das lässt sich verhindern, indem man in den Failsafe-Mode bootet. Dazu muss man, wenn der Prozess für ca 1s steht und die entsprechende Meldung anzeigt, rasch f[enter] eintippen. Schon erhält man eine root-Konsole und kann mit debugging loslegen.

Tatsächlich löste sich das Problem nun recht simpel. eth0 war unter 192.168.1.1 verfügbar, allerdings war eth0 der blaue WAN-Port, keiner der gelben LAN-Ports. Ausserdem schien der DHCP-Server nicht in Betrieb zu sein, so dass dem angeschlossenen Computer manuell eine IP-Adresse vergeben werden musste:

ifconfig eth0 192.168.1.2 netmask 255.255.255.0

. Anschliessend musste auf dem Router noch die Weboberfläche gestartet werden:

/etc/init.d/uhttpd start

und schon konnte bequem per Klickibunti das korrekte Firmware-Image (squashfs) aufgespielt werden.

Das Resultat: ein superflotter WLAN-Router mit relativ tiefen und stabilen Latenzen - zum Spottpreis.

Und vermutlich wäre der Lötkolben gar nicht mal nötig gewesen. Scheinbar kommt man auch in den Failsafe-Mode, indem man direkt nach dem Einschalten den Reset-Knopf drückt. Konsolenzugriff erhält man in diesem Fall per Telnet.

Für eine kopflose Multimediabox unter Debian (bzw Raspbian, es handelt sich hier um einen Raspberry Pi) wollte ich die Lautstärkeregelung der angeschlossenen USB-Lautsprecher nutzen. Diese Tasten senden letztendlich einfach Keyboard-Signale. Unter X11 wird das von den meisten Window Managern und Desktop Environments unterstützt. In der Konsole ist das nicht ganz trivial, insbesondere, wenn kein Benutzer angemeldet ist. Mit dem in Perl geschriebenen magamkeys gibt es aber dennoch einen Weg. Leider ist die Software wieder einmal ein Paradebeispiel perfekt lückenloser Dokumentation (denn wo gar keine Doku ist, da können auch keine Lücken sein...), so dass ich selber etwas denken musste.

Abhängigkeiten:

aptitude install git dbus hal libnet-dbus-perl alsa-utils

Danach die Software per git auf das System holen:

git clone https://github.com/wertarbyte/magmakeys.git

Nun kommt der spassige Teil. Alles installieren, ohne das System unnötig zuzumüllen. Natürlich muss man das richtige Perl-Verzeichnis erstellen, die Version ergibt sich aus dem Befehl perl --version:

mkdir -p /usr/local/lib/perl/5.14.2/
cp -r magmakeys/lib/magmakeys/ /usr/local/lib/perl/5.14.2/
mkdir -p /usr/share/magmakeys
cp magmakeys/share/eventcodes.txt /usr/share/magmakeys/
cp magmakeys/bin/magmakeys /usr/local/bin/
cp magmakeys/initscript/magmakeys /etc/init.d/
chmod +x /etc/init.d/magmakeys
mkdir -p /etc/magmakeys/keys.d/
vi /etc/magmakeys/keys.d/amixer

Nun muss noch die Konfiguration für amixer erstellt werden. Ich will die per USB angeschlossene Soundkarte steuern, welche als Card 1 erkannt wird. Die interne Soundkarte ist Card 0. Ein Hinweis auf die Konfiguration findet sich einerseits im git-Repostitory, genommen habe ich etwas, das ich bei Gentoo gefunden habe:

# volume control
KEY_VOLUMEUP 1 /usr/bin/amixer -c1 set PCM 2%+
KEY_VOLUMEDOWN 1 /usr/bin/amixer -c1 set PCM 2%-
# keep changing the volume when holding the key
KEY_VOLUMEUP 2 /usr/bin/amixer -c1 set PCM 2%+
KEY_VOLUMEDOWN 2 /usr/bin/amixer -c1 set PCM 2%-
KEY_MUTE 1 /usr/bin/amixer -c1 set PCM toggle

Nun lässt sich die Software probeweise mal starten:

magmakeys -k /etc/magmakeys/keys.d/ -t /usr/share/magmakeys/eventcodes.txt

Beim Drücken auf die Tasten an den Boxen müsste sich etwas in der Konsole tun. Wenn das erfolgreich war, kann man den Dienst permanent starten. Dazu muss aber erst das Init-Skript leicht geändert werden: Aus der Zeile "# Required-Start: $remote_fs hal" wird hal gestrichen, da dieser eh über dbus initialisiert wird und kein eigenes Startskript mehr hat. Die Zeile lautet neu also "# Required-Start: $remote_fs". Und die Zeile "DAEMON=/usr/sbin/$NAME" wird zu "DAEMON=/usr/local/bin/$NAME", da ich das Skript nach /usr/local/bin kopiert hatte. Nun kann's losgehen:

vi /etc/init.d/magmakeys
/etc/init.d/magmakeys start
update-rc.d magmakeys defaults

Neulich hatte ich eine Diskussion über Open Source, Closed Source und Sicherheit. Mein Standpunkt war, dass ich mir sicher nicht proprietäre Software wie Dropbox oder Wuala installieren möchte. Natürlich ist Sicherheit hier mit ein Argument. Allerdings nicht nur die Sicherheit davor, dass kein Schadcode in der Software enthalten ist. Grad bei grösseren OpenSource-Projekten kann auch das nicht zu 100% ausgeschlossen werden. Grad die gewaltigen Codemengen, welche einige Firmen in Form von Treibern beitragen, kann kaum sinnvoll extern reviewed werden, da für ein komplettes Verständnis auch die Hardware-Spezifikation bekannt sein muss.

Es geht mir eher um eine andere Form von Sicherheit: Die Sicherheit, dass ich die Software auch morgen noch einsetzen kann. Denn proprietäre Software hat hier schon immer zu Problemen geführt. Entweder ist der Hersteller überhaupt nicht (mehr) willig, gewisse Plattformen zu unterstützen, oder er ist bei der Unterstützung neuer Plattformen einfach viel zu langsam. Letztendlich kann ich 90% allen Ärgers, den ich unter Linux je hatte, auf das 1% proprietäre Software schieben, den ich im Einsatz habe oder hatte.

Hier nur mal ein paar Beispiele aus meiner Erfahrung:

• VMWare Server (vor vielen Jahren): Nach dem Kernelupdate (Bugfix-Release) lassen sich die Module ums verrecken nicht mehr kompilieren.


• Adobe Flash Player: Erinnert sich noch wer an die Zeiten, als 64bit unter x86 noch neumodischer Schnickschnack war? Da hatte man die Wahl, entweder einen 32bit-Browser ins System reinzuwürgen, den semiproprietären nspluginswrapper zu verwenden, um das 32bit-Flashplugin unter 64bit-Browsern zu nutzen, oder aber eine der nicht funktionierenden freien Flash-Alternativen zu installieren. Oder einfach alternativ jahrelang auf Flash verzichten. Oh, Adobe hat ja neulich auch beschlossen, dass Flash für amd64 in Zukunft gar nicht mehr weiterentwickelt wird.


• Skype: Bis es endlich die offiziellen "64bit"-Pakete gab, konnte man die Software nur unter kompletter Verhunzung der Paketverwaltung ins System würgen. Und dann noch dieses neumodische Audiotreiberzeugs namens ALSA, lass mal noch ein paar Jahre beim obsoleten OSS bleiben... aber hey, das grauenhafte PulsAudio-Zeugs, das ist so schlecht, das unterstützen wir sofort und exklusiv.


• PowerVR Grafiktreiber (für die gute, alte KyroII): nett, dieses Kernel 2.6 Zeugs. Aber einen (instabilen) Treiber gibt's nur für Kernel 2.4. Wer's neuer will, der kann ja den VESA-Treiber nehmen. Doku für die freie Treiberentwicklung? bwahahaha, der war gut!


• nVidia-Grafiktreiber: Trotz Linus' Stinkefinger ja die Vorzeigefirma unter den proprietären Treiberentwicklern: Oh, alte Hardware wird nicht mehr unterstützt. Ausser mit alten Treiberversionen, die keine neuen Kernel unterstützen. Oh, und dieses neumodische KMS-Zeugs mit älterer Hardware... nun, hübsche Konsole, so mit extremer Verzerrung und nicht mehr leserbaren Bootmeldungen...


• AMD-Grafiktreiber: Lass mal den neusten AMD-Treiber auf einem 6 Jahre alten Kernel kompilieren... oh geht nicht, Kernel ist zu neu... Dazu hab ich mich ja schon mehrfach ausgelassen. Ganz davon abgesehen, dass die letzte Treiberversion für meine Hardware der 12.04 ist. Da kann ich nur hoffen, dass bis ich den Umstieg auf Debian 8 ins Auge fasse, der freie radeon-Treiber was taugt. Grad im Bereich Multimonitor.


• Druckertreiber für non-Postscript Drucker: Funktionieren nur mit sehr exotischen Distributionen, haben komische Abhängigkeiten, und natürlich nur für 32bit x86 Systeme.


• Wine und Windows-Spiele: Guter Witz. Ich hab da kaum je was zum laufen gekriegt. Auch wenn Wine der Meinung war, das Spiel hätte Platin-Unterstützung (d.h. perfekt)

Aber auch Hardware ist mühsam, sobald sie nicht über ausreichend freie Dokumentation verfügt:

• Noch einmal AMD und nVidia: Die freien Treiber waren jahrelang gar nicht brauchbar, unterdessen geht wenigstens so langsam mal das grundlegende.


• Windows-Only GDI Drucker: aaaaaaaaaargh!


• Nokia-Telefone: Viel Spass beim Zugriff mit Gnokii. Vielleicht geht es. Wahrscheinlich nicht.


• Pogoplug: Die Pro-Platine (auch im spottbilligen Pogoplug Pink verwendet) verwendet ein proprietäres SoC, in dessen Dokumentation nur ein freier Entwickler unter NDA Einsicht hat. Die Konsequenz: Das Gerät läuft nur mit Arch Linux ARM und uralt-Kernel 2.6.31. Und die wichtigsten Treiber für viele USB-Geräte fehlen darin.

A propos Pogoplug: Der sowie z.B. der Raspberry Pi benutzen die ARM-Architektur. Über die Verwendung von Skype, Flash oder Dropbox nachzudenken, ist absolut müssig.

Debian hat mich grad neulich 2x erschreckt. Zuerst hat es mir eine gewaltige Liste an sinnlosen Abhängigkeiten zu einem Paket installieren wollen. Danach hat mein Debian Testing/Wheezy beim Laden der Paketlisten Ewigkeiten rumgeladen und rumgerödelt. Das will ich ihm abgewöhnen. Zeit für eine FDH-Magerkur!

Dazu wird eine Datei /etc/apt/apt.conf.d/00lean angelegt (Name ist eigentlich egal) und mit folgendem Inhalt bestückt (nicht egal):

APT::Install-Recommends "0";
APT::Install-Suggests "0";
Acquire::Languages { "environment"; "en"; "de"; };

Leider lädt Debian damit bei der Paketlistenaktualisierung immer noch alle Übersetzungen runter. Daher muss erst mal /var/lib/apt/lists aufgeräumt werden. Grundsätzlich genügt es wohl, alle *_i18n_Translation-* Dateien in dem Verzeichnis zu löschen. Ich hab einen etwas sichereren und leicht bandbreitenbelastenderen Weg genommen und grad das ganze lists-Verzeichnis umbenannt und neu erstellt (falls was schief gegangen wäre, hätte ich das immer noch rückgängig machen können):

cd /var/lib/apt/
mv lists lists.old
mkdir lists
aptitude update

Nach erfolgreichem Update habe ich das Verzeichnis lists.old gelöscht.

Die neueren Versionen von Gnokii (0.6.30 und neuer) bieten eine neue Verbindungsoption zu s40-Telefonen: Den Phonet-Treiber. Leider ist die Dokumentation im Gnokii-Wiki dazu sehr spärlich und auch sonst weiss das Internet nicht viel dazu. Jedoch ist er relativ gut im Source-Tarball des Gnokii-Projekts beschrieben. Die Source brauchte ich sowieso, um das aktuelle Gnokii für mein Debian Squeeze zu kompilieren.

Die Idee hinter diesem Treiber ist, dass die Nokia-Telefone sich als USB-Modem einbinden lassen und eine virtuelle Netzwerkschnittstelle erstellt wird. Um diese ansprechen zu können, müsste gnokii im Prinzip mit root-Rechten ausgeführt werden. Man kann das jedoch umgehen. Einerseits muss man der gnokii-Applikation etwas mehr Capabilities zugestehen, andererseits muss man dafür sorgen, dass die Schnittstelle automatisch gestartet wird, wenn man das Telefon an den PC anschliesst:

Gnokii Capabilities setzen (als root):

setcap cap_sys_admin,cap_net_raw=+ep $(which gnokii)
setcap cap_sys_admin,cap_net_raw=+ep $(which xgnokii)

Um die virtuelle usbpn-Schnittstelle automatisch zu starten, werden unter Debian/Ubuntu folgende drei Zeilen in der /etc/network/interfaces benötigt:

allow-hotplug usbpn0
iface usbpn0 inet manual
up ifconfig usbpn0 up

Nun muss noch die gnokii-Konfigurationsdatei unter ~/.config/gnokii/config erstellt werden:

[global]
port = usbpn0
connection = phonet
model = series40
[connect_script]
TELEPHONE = 12345678
[disconnect_script]
[logging]
[flags]

Leider hat mich das nicht ernsthaft weiter gebracht. Das Billigst-Telefon (Nokia C1) lässt weiterhin keinen Zugriff auf die SMS-Inbox zu. Telefonbuch auslesen und bearbeiten sowie zumindest SMS versenden klappt sowohl über den AT- wie auch den Phonet-Treiber problemlos.

Nachtrag vom 24.10.: mit Debian Wheezy lässt sich zumindest die Ordnerliste anzeigen, jedoch wird jeder Ordner als leer angezeigt. Das Speichern von SMS funktioniert. SMS lesen scheint aber nach wie vor nicht zu klappen.

Vor etwa einem Jahr habe ich mir einen neuen Server zusammengebaut. Eigentlich wollte ich damals eine CPU, welche drei Anforderungen erfüllt: x86 64bit, virtualisierungsfähig und sehr stromsparend. Leider konnte jede vorhandene CPU höchstens zwei der Kriterien erfüllen, insbesondere bei Intels Atom sind auch heute noch Punkt eins und zwei gegenseitig ausgeschlossen. Und das stromsparendste von AMD war der Athlon X2 240e, welchen ich zuletzt ausgewählt hatte. Monate später wurden dann die Atom-Konkurrenten von AMD veröffentlicht. Zwei Geräte für Tests mit Cluster- und sonstigen Basteleien mit einer derartigen Zacate-CPU habe ich mir nun besorgt, und zwar zwei ZBOXen von Zotac. Diese sind extrem günstig, komplett ausgestattet und befreit von Microsoftsteuern. Zum einen habe ich mir einen Nano gekauft, da dieser mit Fernbedienung geliefert wird, so dass ich diesen später zu einem Multimediarechner umfunktionieren kann. Und zum anderen einen ADO2, da dieser im Gegensatz zum Nano Platz für zwei Speichermodule bietet, so dass er auf 8GB RAM ausgebaut werden kann.

Bei so schönen Geräten muss natürlich erst mal die Hardware etwas genauer getestet werden, statt sie nur im Konsolenmodus zu betreiben. Dazu wollte ich ein paar Betriebssysteme installieren. Ubuntu Desktop 11.10 lässt sich fast problemlos installieren. Die Installation von Ubuntu Server 11.10, Debian 6 und CentOS 6.2 scheitert jedoch an einem Punkt: Beim Laden des Installers geht plötzlich die Tastatur verloren. Natürlich kann jedes Huhn Debian installieren, wenn genügend Körner auf der Tastatur liegen. Aber die Tastatur muss halt funktionieren. Interessanter- und glücklicherweise tritt das Problem beim Ubuntu Desktop nicht auf, so, dass sich dieser mässig bequem installieren lässt.

Das Problem mit den USB-Tastaturen lässt sich auch mit keiner BIOS bzw EFI-Konfiguration beheben. Ich habe alle USB-Einstellungen in jeder Kombination getestet, in letzter Verzweiflung sogar USB-Legacy deaktiviert. Dazu steht im BIOS-Setup, dass dadurch USB-Geräte nur noch in EFI-Applikationen zur Verfügung gestellt würden. Tja, das BIOS-Setup ist blöderweise keine EFI-Applikation, so dass ich nun ganz ohne Tastatur dastand und dies somit nicht mehr einfach korrigieren konnte. Daher musste ich erst mal das CMOS resetten, was zum Glück recht simpel ist. Man muss die Bodenplatte des Geräts entfernen, d.h. erst die vier Daumenschrauben lösen, welche auch als Standfüsse dienen, und dann an der eingekerbten Ecke den Fingernagel einsetzen und die Bodenplatte herausreissen. Nun hat man Zugriff auf alle relevanten Innereien, d.h. Festplatte, WLAN-Karte und RAM-Sockel, so dass man an dieser Stelle auch einfach ein RAM-Upgrade durchführen kann. Für den Reset muss einfach der gummierte, unbeschriftete Knopf zwischen WLAN- und Speichermodul ein paar Sekunden gedrückt werden. Eine bebilderte Anleitung dafür findet sich leicht, jedoch ist in dieser der Reset-Knopf nicht ersichtlich.

Die Geräte verfügen über kein BIOS sondern das modernere EFI. So schöne Vorteile (wie z.B. richtig grosse Platten ohne Workarounds) das bietet, so wüste Nachteile bei der Bootloader-Installation zieht es mit sich. Zur Installation von Ubuntu bin ich folgendermassen vorgegangen:

• Zuerst habe ich von meinem bevorzugten Mirror das CD-Image für Ubuntu Live 64bit heruntergeladen und dieses mittels unetbootin auf einen bootbaren USB-Stick geschrieben. Diesen habe ich dann in den Zotac eingsteckt und das Gerät eingeschaltet.
• Wenn die Startpiepser ertönen (ähnlicher Klang wie die Telefone in 24), ein paar mal auf DEL hämmern, um ins BIOS-Setup zu gelangen. Unter "Boot" muss die Startreihenfolge angepasst werden, so dass zuerst ab USB-Stick gestartet wird.
• Jetzt erscheint der Bootloader und kann man entweder Ubuntu Live starten und dort das Setup aufrufen oder grad den Installer starten.
• Die Festplatte muss unbedingt manuell partitioniert werden, denn EFI verlangt eine EFI-Partition. Der gparted-Verschnitt des Ubuntu-Installers legt gleich eine GPT-Partitionstabelle an, so dass als erste Partition eine FAT32-Partition von mindestens 200MB angelegt werden kann. Die Schwierigkeit besteht darin, dieser noch das Flag bios_grub gesetzt werden muss. Unter Ubuntu Live ist das kein Problem, da partitioniert man einfach vorher rasch mit gparted. Wichtig ist, dass man die ganze Platte löscht und eine neue Partitionstabelle vom Typ GPT anlegt.
  Im reinen Installer-Modus wechselt man mittels ctrl-alt-F1 in die Konsole, startet mittels
  $ sudo parted
  eine parted-Shell und setzt das Flag rasch per Kommando
  set 1 bios_grub on
  (tatsächlich habe ich im Arch-Wiki gelesen, dass man das Flag boot setzen muss, aber dann meckern später EFI und grub-installer). Zurück zum Installer gelangt man durch alt-F7.
• Nun installiert man Ubuntu ganz normal fertig. Bloss neu starten sollte man noch nicht! Zuerst muss grub noch richtig installiert werden. Dazu wechselt man wieder in die Kommandozeile (bzw öffnet eine Shell in Ubuntu Live) und gibt folgende Befehle ein:
  $ sudo mount /dev/sda2 /mnt (/dev/sda2 muss ggf durch die korrekte Angabe für die Root-Partition ersetzt werden) und
  $ sudo grub-install --root-directory=/mnt /dev/sda (auch hier muss /dev/sda ggf durch die korrekte Angabe für die Platte, worauf Ubuntu installiert wurde, ersetzt werden).
• Jetzt kann man neu starten und Ubuntu sollte fehlerfrei booten. Die EFI-Warnmeldungen bezüglich Bildschirmauflösung und "file not found" kann man ignorieren.

Die Leistung der Geräte ist nicht schlecht. Sogar Nexuiz läuft passabel wenn der proprietäre AMD-Treiber fglrx installiert wird, bei 1024x768 ist es mit 40-70FPS absolut spielbar. Bei höheren Auflösungen kommt die Grafikeinheit aber an den Anschlag.

Mal wieder dicke Punkte für Linux als Rettungssystem. Kollege bringt mir seinen defekten PC mit einem Intel Matrix RAID. Natürlich RAID-Level 0, d.h. ohne Netz und doppelten Boden. Man müsste die Daten von den Disk versuchen zu retten, weil Backup ist nicht...

Na gut. Die Kiste fährt nicht hoch sondern piepst nur. Ergo Platten raus, in meinen alten Schrott-PC rein und die nächstbeste Live-CD (in diesem Falle CloneZilla) gestartet und mal geschaut, was da Sache ist. mdadm sollte ab Version 3.0 in der Lage sein, solche Non-Linux-SoftRAID Verbünde wieder zusammenzusetzen. Tatsächlich klappt das auch. Verwirrend ist jedoch, dass die physischen Festplatten als /dev/sda1 und /dev/sda2 (was ja eigentlich Partitionen wären) eingebunden sind und das logische Laufwerk, d.h. der Verbund, als /dev/sda (was eigentlich die erste physische Platte sein sollte) verfügbar ist. Tja, wo sind nun die Partitionen? Diese finden sich unter /dev/dm-[0-9] und können von dort ganz normal gemountet werden. CloneZilla hat NTFS-3G schon dabei, somit ist auch der Zugriff auf die Windows-Partitionen kein Problem.

Kurz die Daten auf eine externe USB-Disk gesichert, und gut ist.