planetknauer.net

Wie verwandle ich einen Raspberry Pi, eine USB-WLAN-Karte und ein Paar USB-Lautsprecher in eine mobile Krachstation, welche die gleiche Musik wiedergeben kann, wie mein Hauptrechner? Nun, die Theorie wäre ja einfach: Auf dem Hauptrechner läuft mpd und dieser kann in quasi jedem gewünschten Format und Protokoll ausgeben. Dieser wird nun zwecks Steigerung der Verfügbarkeit erstmal auf den Intranet-Server gezügelt.


Der erste Versuch war, einen normalen Stream zu verwenden. Dazu wird wahlweise mpds integrierter Web/Streaming-Server gestartet (Nachteil: sobald man die wiedergabe pausiert, wird das Socket geschlossen, ein allfälliger Client wird deshalb terminiert), oder noch ein Icecast zwischengeschaltet (Vorteil: ein permanenter Stream, sobald mpd pausiert wird, strahlt Icecast ein (lautloses) Fallback-File in Endlosschleife aus). Leider hat diese Lösung einen riesigen Nachteil: Der Client hängt 2-10 Sekunden hinterher. Startet man die Wiedergabe, drückt man auf Pause oder wechselt manuell zum nächsten Lied, dauert es eine mittlere Ewigkeit, bis die Änderung beim Client ankommt. Fazit: für meinen Zweck unbrauchbar.


Na gut, zweiter Versuch. mpd Pipe-Output. Damit gibt mpd einfach einen rohen Audiostream per Pipe an ein anderes Programm weiter. Diesen Stream kann man entweder direkt per netcat übers Netzwerk raushauen oder aber, um das Netz nicht übermässig zu belasten, erst zu ogg codieren. Hierzu trägt man in der /etc/mpd.conf folgendes ein:

audio_output {
type "pipe"
name "my pipe"
command "oggenc -r -Q -q4 - | nc 192.168.0.60 8765"
}

Auf der Empfängerseite wird mittels xinetd ein passender Empfänger bereitgestellt. Dazu benötigt man einerseits eine Konfiguration für xinetd unter /etc/xinetd.d/oggplay:

service oggplay
{
port = 8765
type = UNLISTED
socket_type = stream
wait = no
user = root
server = /usr/local/bin/oggplay.sh
log_on_failure += USERID
disable = no
}

Leider scheint diese nur mit root-Rechten zu funktionieren, von xinetd aus gestartet kann ein Prozess des eingeschränkten Benutzers aus irgend einem Grund nicht auf die Soundhardware zugreifen (von einer Login-Shell aus geht das jedoch). Genauer untersucht habe ich das nicht, da ich ja erst mal einen Proof-Of-Concept wollte. Ebenfalls wird noch das eigentliche Player-Skript unter /usr/local/bin/oggplay.sh benötigt:

#!/bin/bash
/usr/bin/ogg123 -v -d wav -f- - | /usr/bin/aplay -v -D sysdefault:CARD=USB

Das funktionert soweit... nicht wirklich. Der erste Song konnte in aller Regel noch wiedergegeben, spätestens nach dem ersten Songwechsel waren dann aber massive Aussetzer in der Wiedergabe. Kein Wunder, hier wird ja auch überhaupt nichts gepuffert. Sehr traurig allerdings, dass es auch über Ethernet mit geringer Latenz/Jitter kein Bisschen besser funktioniert als über WLAN. Fazit: unbrauchbar.


Als nächstes habe ich dann zu ganz radikalen, verzweifelten Massnahmen gegriffen und im dritten Versuch angefangen, meine Systeme mit Pulseaudio zu verschandeln (und natürlich erst noch ein Diskimage gezogen). Auf dem Server werden folgende Pakete und Konfiguration benötigt:

aptitude install pulseaudio pulseaudio-utils mpd mpc

/etc/mpd.conf:

audio_output {
type "pulse"
name "Multicast RTP"
sink "rtp"
}

/etc/pulse/default.pa in Debian 6 / PA 0.9:

#! /usr/bin/pulseaudio -nF
load-module module-native-protocol-unix
load-module module-suspend-on-idle timeout=1
load-module module-null-sink sink_name=rtp description="Multicast RTP"
load-module module-rtp-send source=rtp.monitor

bzw unter Debian 7 / PA 2.0:

#! /usr/bin/pulseaudio -nF
load-module module-native-protocol-unix
load-module module-suspend-on-idle timeout=1
load-module module-null-sink sink_name=rtp sink_properties="device.description='RTP Multicast Sink'"
load-module module-rtp-send source=rtp.monitor

/etc/pulse/daemon.conf:

exit-idle-time = -1
default-sample-format = s16le

Das war's schon
Nehmen wir nun den Raspberry in Angriff. Zuerst werden ein paar PulseAudio-Konfigurationswerkzeuge installiert:

aptitude install paman paprefs pavucontrol

Des weiteren wird PulseAudio so konfiguriert, dass standardmässig die USB-Lautsprecher verwendet werden. Hierzu genügt die Zeile "default-sink = 1" in der Datei /etc/pulse/client.conf.
Startet man nun die grafische Oberfläche und aktiviert dort den RTP-Empfang per Klickibunti in paprefs, haut die Sache auch sofort hin. Das ist aber witzlos, wenn die Kiste ja nachher Headless und ohne angemeldeten Benutzer funktionieren soll. Folglich beendet man X11 wieder. In den Howtos zu diesem Thema (u.a. auch in den Raspberry-spezifischen Diskussionen wie hier und hier) wird gesagt, dass "einfach nur" in /etc/pulse/default.pa die Zeile "load-module module-rtp-recv" einfügt und PulseAudio durch Änderung in /etc/default/pulseaudio als Systemdienst eingerichtet werden soll. Eventuell muss man noch in der /etc/pulse/daemon.conf "resample-method = src-sinc-fastest" eintragen. Nach einem Neustart soll es auch schon laufen. Simpel, oder? Da muss ein Haken dran sein! Ist auch so. Davon zeigt sich das System nämlich überhaupt nicht beeindruckt und bleibt mucksmäuschenstill.
Was ist nun also der Unterschied zwischen der Kommandozielen- und der GUI-Konfiguration? Keine Ahnung. Auch "pacmd dump" hilft hier nicht weiter. Wie bekommt man den Dreck trotzdem zum laufen? Nun, wie so oft mit der beliebten Methode "von hinten durch die Brust ins Auge": Die Änderung in /etc/default/pulseaudio wird wieder rückgängig gemacht, so dass Pulseaudio nicht beim Systemstart gestartet wird. Danach trägt man in die /etc/rc.local einen fixen Aufruf des PulseAudio-Dienstes ein, und zwar mit folgender Zeile:

su pi -c 'pulseaudio -D --log-target=syslog --start --realtime --resample-method=src-sinc-fastest'

und Tadaaaa! Es lärmt, sobald der mpd anfängt zu spielen. Allerdings ist "Lärm" wirklich die passende Bezeichnung. Die Wiedergabe scheppert leicht, was wohl dem Resampling geschuldet ist.

Jetzt steht mir nur noch eines bevor: Auch meinen Desktop mit Pulseaudio zu ruinieren. Dies, nachdem das aktuelle Alsa-Setup doch prächtig funktioniert.

Nachdem ich die ganze Nacht über Alarmmeldungen von verdächtigen Zugriffen von der immer gleichen IP-Adresse erhalten habe, wollte ich dem zuständigen Besitzer Meldung machen. Nun, ein Reverse-DNS-Eintrag für die IP war nicht konfiguriert, aber gemäss whois gehört sie einer grösseren Uni in Deutschland. Also kurzerhand deren abuse@ Adresse angeschrieben, mit Logauszug und Symptomen. Daraufhin kommt die Antwort: Das ist kein Angriff, das ist ein Forschungsprojekt und repliziert das SSL Observatory. Ne, oder? Und dafür muss man hundert Mal auf POP3- und IMAP-Server zugreifen? Ohne den SSL-Handshake zu komplettieren? Das ganze von einer "anonymisierten" IP-Adresse? Vielleicht hätte man da ja auch jemanden fragen können, der sich mit sowas auskennt... grrrrmpf!

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

Vor dem Network Manager Applet in Debian Wheezy kann derzeit nur gewarnt werden. Der ist so vorsätzlich buggy, man könnte meinen, er wäre von allen grossen, kommerziell orientierten Softwarefirmen gemeinsam geschrieben worden:

• Beim Versuch zu einem WLAN zu verbinden, wird nach dem root-Passwort gefragt - nicht aber nach dem WPA-Schlüssel. Lösung: Unter "Verbindungen bearbeiten" sich durchklicken und den Schlüssel händisch eintragen.
• WLAN kann per GUI deaktiviert werden - aber keinesfall wieder aktiviert. Lösung: In der Kommandozeile als root mittels nmcli nm wifi on geht es wieder. Aber dafür installiere ich ja ein Klickibunti-Tool... damit ich nachher wieder in die Konsole gehen kann.

Die Post bietet an, dass man vorfrankierte Adressetiketten auf ihrer Homepage kaufen und ausdrucken kann. An sich ein nettes Angebot. Erstens sind die Preise für Pakete um einen Franken weniger unverschämt teuer, zweitens muss man nicht mehr am Postschalter stundenlang anstehen und drittens kann man sich an der eigenen Nase fassen, wenn es falsch frankiert ist und braucht sich nicht mit dem total unfähigen Personal der Post auseinanderzusetzen.

Natürlich gilt das nur, wenn es denn a) komfortabel nutzbar wäre und b) funktionieren würde.

Bezüglich des Komforts: Für jede Marke muss man erneut und von Hand alle Daten, inkl. Absenderadresse neu eingeben. Jedoch vorsicht, wenn man sich nun erst noch bei der Post registrieren muss, dann sind die Daten anschliessend verloren und man darf sie nochmals eingeben. Aber danach kann man eine einzige Etikette auf Papier drucken. Soweit ich das zumindest verstanden habe. Denn soweit bin ich noch gar nicht gekommen. Aufgrund des Bezugs zur Funktionalität: Ich warte immer noch darauf, dass ich mal ein Guthaben von meinem Postkonto überweisen kann. Das Login ist seit ca 30 Minuten am Laden. Also entweder muss ich nochmals von vorne anfangen und es mit der Kreditkarte versuchen, oder ich bleibe analog und kämpfe mich morgen früh zur Schalteröffnungszeit an die Poststelle. Müüüüühsam!!! grrrrrmpf!!!

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.

Pünktlich um 02:00 in der Nacht sind hier die Alarmsirenen losgegangen. Was los? Keine Ahnung. Das Permanentsignal (an- und abschwellender Ton von ca 30 Sekunden, danach 5 Sekunden Pause) deckt sich jedenfalls nicht mit einem der offiziellen Signale. Wäre ja auch zu einfach. Also mal ins vermutete nächstgelegene Lokalradio reingehört, man zahlt ja schliesslich als guter Bürger neben den Steuern für irgendwas auch den unverschämten staatlichen Abriss namens Billag.

Es dauert geschlagene verdammte 20 Minuten, bis sich dort mal jemand dazu bequemt eine Durchsage zu machen: Ha ha! Fehlalarm! Ätsch!!!
Alternativ irgendwie eine Information auf der Frontseite der Gemeindehomepage ist offenbar zuviel verlangt. Und die lokalen Zeitungsredaktionen befinden sich auch weiterhin im Tiefschlaf. Herzlichen Glückwunsch.

Und dafür wollt ihr mein teueres Steuergeld, liebe Behörden? Hoffentlich nicht! Denn diese saubere organisatorische Leistung qualifiziert sich durchaus für einen Sirenenalarm, das ist nämlich wirklich eine Katastrohpe! Und jetzt kann ich natürlich nicht mehr Schlafen, weil mein Adrenalinspiegel durch die ganze Scheisse auf dem Maximum ist!

Schon lange gewünscht, endlich kann ich es haben: Der Inlineskater-Remover! Das Ding garantiert mir freie Fahrt auf dem Velostreifen

Diesmal handelt es sich um eine Disk aus einem dubiosen NAS. Anscheinend pappt das /dev/sda1 und /dev/sda2 zu einem RAID-1 zusammen. Dies wird wohl so gemacht, um das System elegant aktualisieren zu können. Jedenfalls, musste da mal Hand an die Systemdaten angelegt werden.

Nun, Standardübung, nehmen wir mdadm:

mdadm --assemble /dev/md/0 /dev/sdb1 /dev/sdb2
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted

Wie? Kein Superblock? jaaa aber... parted ist da anderer Meinung:

parted /dev/sdb print
Model: WDC WD10 EARX-00N0YB0 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
3 15.7MB 528MB 513MB primary
1 528MB 2576MB 2048MB ext3 primary raid
2 2576MB 4624MB 2048MB ext3 primary raid
4 4624MB 1000GB 996GB ext4 primary

Was nun? Es handelt sich hierbei um ein Legacy-RAID ohne Superblock. Das setzt man nicht mit assemble sondern mit build zusammen:

mdadm --build /dev/md/0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdb2
mdadm: array /dev/md/0 built and started.

Nach der Resynchronisation erfolgt der erste mount-Versuch:

mount /dev/md/0 temp/
mount: unknown filesystem type 'linux_raid_member'

Na gut, erzwingen wir das Dateisystem:

mount /dev/md/0 temp/ -t ext3

Perfekt, alle Daten da

Grad mal schauen, ob das auch tut... Hab mir einen Twitter-Account @planetknauer angelegt, um neue Blog-Einträge darüber ankündigen zu können. Man muss ja auch irgendwann mal ein Bisschen mit der Zeit gehen


Jedenfalls schlägt mir Twitter vor, doch anderen Tweets zu folgen. Sehr gut. Sie haben wohl noch keine ausführlichen Profildaten von mir (oder können meinen Account nicht damit verknüpfen). Sonst würden sie mir wohl kaum Fussball und krass Gangsta Rap vorschlagen.

Nachtrag: Wär ja auch zu einfach gewesen, wenn das Plugin auf Anhieb funktioniert hätte. Musste natürlich erst sinnlos eine halbe Stunde verschleudern, bis es dann wirklich angefangen hat, die Updates auf Twitter rauszuposaunen. Was ich anders machen musste? Keine Ahnung... Hab das Plugin nochmals gelöscht, neu installiert und dann ging es.

Das Ziel: Existierende Dateien werden normal angezeigt. Bei nicht existierenden Dateien wird statt Error 404 der Erfolgsstatus 200 und ein Standard-Dokument ausgegeben.

Klingt einfach? Ist es nicht. Das liegt primär daran, dass dafür mod_rewrite braucht, wofür keine gescheite Dokumentation existiert (ist ja schön, wenn die offizielle Doku alle verfügbaren Variablen auflistet, sie aber nirgends erklärt...) und alle bestehenden Howtos irgendwo einen Fehler machen oder diesen zugegebenermassen sehr speziellen Fall überspringen.

So scheitern praktisch alles bestehenden Vorschläge an der fehlerhaften RewriteCond:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

-d und -f prüfen aber den absoluten Dateisystempfad, während REQUEST_FILENAME nur den Teil enthält, welcher in der URL nach dem Hostname steht, d.h. http://www.example.com/requested/filename.html. Somit werden diese Rewrite Conditions sowieso niemals zutreffen. Nun gibt es zwei Lösungen dafür. Entweder den ausschliessenden Weg, dass man alle existierenden Dateien von Hand explizit spezifiziert, z.B.

RewriteCond %{REQUEST_FILENAME} !^/robots.txt$
RewriteCond %{REQUEST_FILENAME} !^/favicon.ico$

Nur hat dies zwei Nachteile, es ist aufwändig und unflexibel. Na gut, die simplere Lösung ist es den vorangehenden Pfadnamen hinzuzufügen, dafür gibt es die glücklicherweise vom Namen her sprechende DOCUMENT_ROOT Variable (eine offizielle Dokumentation, wo diese beschrieben wird, ist aus irgendwelchen Gründen schwierig zu finden...), so dass eine funktionierende, flexible und universelle Regel etwa so aussehen könnte:

RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteRule ^.+$ /index.html [L]

Hat man fetchmail erfolgreich konfiguriert und als Cronjob ein simples fetchmail -s eingerichtet, so wird sich der Cron Daemon über einen Fehler beschweren, wenn keine Mails im Postfach zur Abholung bereit lagen. Grund dafür ist, dass fetchmail nur 0 als Exit Code zurückgibt, wenn es erfolgreich Mails abgeholt hat. Lagen keine Mails im Postfach, lautet der Exit Code 1, was von Cron völlig berechtigt als Fehler bemängelt wird. Ein kurzes Studium von man fetchmail hat mir dann die Lösung gebracht, der Cronjob ist jetzt folgendermassen konfiguriert:

*/15 * * * * fetchmail -s || [ $? -eq 1 ]

Der rar-Archiver scheint eine praktische Funktion zu besitzen, nämlich das automatische Splitten beim packen. Ich muss diese Funktionalität mutmassen, da ich rar nicht zum packen verwende, da es unfrei ist. Und überhaupt gibt es in der freien Welt so viele Formate, dass ich dieses problemlos links liegen lassen kann. Jedenfalls resultiert das ganze in Dateien mit der Endung foobar.part1.rar, foobar.part2.rar etc. Das scheint wohl ganz praktisch zu sein für ein very poor man's Backup auf CDs.

Nun hatte ich neulich das Vergnügen, so eine Archivserie zu entpacken, bei welcher eines dieser Teilstücke verloren gegangen ist. Beim packen könnte man wohl angeben, dass ein "recovery volume" angelegt werden soll, womit der Verlust eines Teils kompensiert werden kann. Aber wer denkt schon an sowas Rar wird nun zwar anfangen zu entpacken, bricht dann aber bei der ersten Datei ab, welche sich (partiell) im verlorenen Teil befindet. Tja, nun hat man also den ersten Teil seines Backups, aber die Daten von hinter dem fehlenden Stück scheinen nicht zugänglich zu sein. Auch eine Suche mit Google hat hier nicht gross weitergeholfen, der Tenor war stets "kannst du vergessen, geht nicht". Aber das stimmt definitiv nicht! Man braucht sich also nicht zu ärgern, dass das Einlesen von 20 CDs oder das herunterladen von 100GB Daten für die Katz war. Zwar kennt rar den Parameter -kb, welcher defekt extrahierte Dateien behalten soll, aber das funktioniert in diesem Fall nicht. Der Entpackvorgang bricht trotzdem ab (hier für Klickibunti-Windosen).

Hier der Trick: Angenommen, part4.rar fehlt. Also erstellt man erst einen scheinbaren Teil 4. Am einfachsten kopiert man einen anderen Teil:
cp foobar.part3.rar foobar.part4.rar
Nun startet man den nächsten Entpackvorgang, schliesst jedoch die als defekt gemeldete(n) Dateien über den exclude-Parameter aus. Wichtig ist die korrekte Syntax zu beachten, nach dem -x darf kein Leerzeichen folgen und Dateinamen mit Leerzeichen müssen zwischen Hochkommata stehen:
unrar x -x'pfad/zu/defekter datei.xls' -x'pfad/zu/ebenfalls defekter datei.doc' foobar.part1.rar
Schon entpackt es weiter.

Natürlich fehlen letztendlich ein paar Daten unwiderbringlich. Aber sofern es sich um eine Notrekonstruktion aus einem defekten "very poor man's" Backup handelt, ist das doch schon besser als gar nichts mehr zu haben.