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 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.part.4.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.

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.

Die gute zuerst: Free&Virgin sind pleite. Das sind die Chaoten, die ab und zu mal spontan ein Konzert ans andere Ende der Welt verschieben oder glauben, dass sie Musikfestivals organisieren könnten.

Nun die schlechte: Sie machen einfach unter neuem Namen weiter und heissen jetzt MASPE (Matthey & Sprenger Entertainment) bzw Starclick. Ich erwarte keine Verbesserung. Daher wird meine Boykottliste einfach prophylaktisch um die neuen Namen ergänzt.

Westvleteren Trappistenbräu. Wirklich sehr lecker!

Ab und zu braucht oder möchte man mal unter Debian Stable ein neueres Programm installieren. Oft findet sich dies in Unstable oder gar Testing, aber leider gibt's dann oft keinen Backport. Das ist aber kein Problem. Meine Backports bau ich anhand dieser Anleitung, mit einigen Ergänzungen. Hier erläutere ich dies am Beispiel des Messengers Pidgin:

Als erstes werden mir root-Rechten die benötigten Abhängigkeiten für den Bau des Pakets installiert:

# aptitude build-dep pidgin

Bis auf weiteres können alle weiteren Schritte als normaler User ausgeführt werden. Als nächstes wird die Source und die Debian-Modifikation von packages.debian.org heruntergeladen und in ein eigens für den Build erstelltes Verzeichnis kopiert:

$ mkdir pidgin
$ cd pidgin
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0.orig.tar.bz2
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0-3.debian.tar.gz

Nun wird entpackt:

$ tar -jxf pidgin_2.9.0.orig.tar.bz2
$ cd pidgin-2.9.0
$ tar -zxf ../pidgin_2.9.0-3.debian.tar.gz

Der nächste Schritt ist etwas fummelig. Allenfalls müssen Abhängigkeiten angepasst werden, weil das Debian-Skript eine neuere Version einer Abhängigkeit fordert als nötig und/oder für Debian Stable verfügbar ist. Fehlerhafte Abhängigkeiten können einfach bestimmt werden, indem man den nächsten Schritt ausführt und den Kompiliervorgang versucht zu starten. Zur Bereinigung von Abhängigkeiten mit unnötig hoher Version muss die Datei debian/control bearbeitet werden.
Einige benötigte Abhängigkeiten mit höherer Version lassen sich aus den Backports installieren, dies klappt mittels aptitude -t squeeze-backports install myrequireddependency (vorausgesetzt, das backports-Repository ist konfiguriert). Für einige ganz fiese Abhängigkeiten kann es nötig sein, dass man davon selbst ein Update gemäss dieser Anleitung erstellen und installieren muss.

Sind alle Probleme behoben, kann man nun den Compiler anwerfen lassen:

$ dpkg-buildpackage -rfakeroot -uc -b

Wenn dies erfolgreich war, erhält man ein installationsbereites .deb-Paket. Für die Installation sind natürlich wieder root-Rechte erforderdlich:

$ cd ..
$ su
# dpkg -i *.deb

Kaum zu glauben: Aber mit Treiberversion 11.7 steht nun endlich ein AMD-Treiber zur Verfügung, welcher sich ohne rumgepatche und langen händischen Kompilierorgien out-of-the-box auf Kernel 2.6.38 aus den Debian Backports installieren lässt. Wird ja auch so langsam Zeit, jetzt wo schon bald Kernel 3.1 vor der Türe steht...

Letztes Wochenende war ich am Sonisphere. Nun ja, hier eine kurze Kritik.

Positiv:

• Alle Bands, die ich sehen konnte, haben ausserordentlich gut gespielt.
• Für das Lineup sind CHF 180.- nicht zuviel. Sofern man alle interessierenden Band sehen könnte.
• Das Wetter war im Gegensatz zum letzten Jahr hervorragend. Logisch, war diesmal ja auch 3/4 Indoor.
• Man durfte fotographieren! Ist heute ja leider nicht mehr selbstverständlich.
• ÖV im Ticket integriert macht die Anreise bequem.

OK, kommen wir zu den negativen Punkten:

• Am Donnerstag erst mal über ne Stunde warten, bis man gnädigerweise reingelassen wurde. Tja, wenn man 10'000 Tickets verkauft, kann natürlich auch keiner damit rechnen, dass dann plötzlich 10'000 Leute vor der Türe stehen und rein wollen. Darum macht man auch nur drei kleine Tore auf und nimmt besonders sehschwache Securities, die dann Mühe haben die Tickets äusserst umständlich zu kontrollieren. Dies, nachdem man schon mühsam ein Bändchen tauschen musste. Konsequenz: Shakra verpasst. Ja, auch für die hab ich 180.- bezahlt.
• Thema Bändchen. Billigste Papierdinger, noch nicht mal individuell bedruckt. Souvenierwert gleich null. Stoffbändchen wären nicht nur ästhetischer gewesen, sondern auch sicherer. Standardbändchen kann jeder selbst kaufen, auch Diebesbanden. Kein Wunder, dass auf der Facebook-Fanpage so viel über Diebstahl gejammert wurde. Man hat es den Banden ja auch leicht gemacht, hineinzukommen.
• A propos Diebstahl: CHF 45.- und mehr für die Shirts ist eine Frechheit. Dasselbe Judas Priest Shirt habe ich am Swedenrock Festival für SEK 250.- erhalten. Das entspricht CHF 37.-
• Wer auch immer den Zeitplan erstellt hat: Foltert ihn zu Tode!!! Sowas darf man echt nicht dem hiphophörenden Praktikanten überlassen.
• Dass der Zeitplan noch leichte Korrekturen erfahren hat, war ja schön und gut. Allerdings sollte man sowas nicht ganz so kurzfristig z.B. wie am Morgen früh vornehmen.
• Subwoofer hat man wohl vergessen zu mieten...
• Videoleinwände sind toll, aber auf Höhe der Bühne montiert nutzen sie genau gar nichts.
• Unter "Market Place" verstehe ich etwas leicht anderes als einfach drei Frittenbuden, die nebeneinander stehen. Das hat auch der Jesuslatschenstand in der Nähe nicht mehr rausreissen können.
• Die Getränkepreise waren knapp OK, aber das Essen war mehrheitlich einfach zu teuer.
• Ich war schon lange nicht mehr an einer Indoor-Veranstaltung, an der so saumässig viel gequalmt wurde. Mir ist schon klar, dass die Nikotinjunkies grundsätzlich asozial sind, aber meist hilft es ihrem Gedächtnis (oder sozialen Gewissen), wenn man ein paar Rauchverbotschilder aufhängt und als Extremmassnahme ab und zu eine Durchsage macht.
• Während dem In Flames Konzert bildete sich plötzlich eine Versammlung von vier breitschultrigen, schwarz gekleideten Glatzköpfen mit patriotisch wirkendem Emblem auf dem Rücken. Neonazis, die vor Kreator geflohen sind? Nichts da, das war die Security-Nachtverstärkung. Und die ging sofort so filigran ans Werk wie die Axt im Walde. Raucher dazu bringen, mit ihrem asozialen Verhalten aufzuhören ist ja schon OK, aber über eine Distanz von 10m anleuchten, anschreien und abschliessend den Krebsstängel aus der Hand schütteln eben nicht. Oder: Einen neben seinen Kumpels schlafenden, besoffenen 16jährigen aufwecken ist auch eher grenzwertig, ihn mit dem lederbehandschuhten Schraubstock am Kinn zu packen und seine Sehkraft mit der Maglite ruinieren hingegen jenseits jeder Grenze. Klar könnte der unter Drogen gestanden haben. Aber etwas mehr Fingerspitzengefühl bei der Prüfung darf man ja wohl erwarten.

Das sind nur die Dinge, welche mir widerfahren bzw aufgefallen sind. Auf der Facebook-Fanseite tönt es gelegentlich noch wesentlich schlimmer. Ich habe keine Ahnung, was die nächstes Jahr für Bands organisieren müssen, damit ich da nochmals hingehe.

Na, liebe IFPI, wie gefällt es euch, wenn man euch nach eurem eigenen Massstab einstuft und mit eurem eigenen Vokabular betitelt?

Fragt einer, der letzten Monat 500.- für Festivaleintritte, 150.- für T-Shirts und 300.- für CDs ausgegeben hat... Also Geld genug um die Steuern regulär zu zahlen habt Ihr ja jetzt!!!

Und ich dachte eigentlich, dass man den Stand-By-Modus bei Stromverbrauchern* vermeiden und stattdessen ganz abschalten sollte. Tja, wieder was gelernt. Danke, Politiker!

*) was mit AKWs passiert, wenn man ihre Stromzufuhr abstellt, hat man ja in Japan mitbekommen...

k.A. was der Aufschrei in der Presse grad soll, in der Schweiz ist das seit Jahren gang und gäbe. Die fragwürdige "Köstlichkeit" heisst hier einfach "gstampfter Jud", und ja, ich hab mich hier schon mehrfach dazu geäussert.

Oh, Microsoft blättert 8.5Mia Dollars für Skype hin? Kein schlechter Deal für die Investorentruppe, die vor zwei Jahren 1.9Mia Dollar für 70% bezahlt hat. Und eBay guckt bestimmt blöd aus der Wäsche

Nun wird die Linux-Version vermutlich eingestampft. Na gut, machen wir doch gleich Nägel mit Köpfen:

aptitude purge skype
rm -rf /home/*/.Skype

Problem gelöst.

Wirklich gemocht hab ich den proprietären Binärblob ja nie wirklich.

AMD hat vorgestern Treiber 11.4 für Linux veröffentlicht. Der ist somit zwei Monate nach Kernel 2.6.38 erschienen. Ob der Treiber sich wohl gegen den Kernel kompilieren lässt?

Antwort: Leider nein:

AMD kernel module generator version 2.1
doing Makefile based build for kernel 2.6.x and higher
rm -rf *.c *.h *.o *.ko *.a .??* *.symvers
make -C /lib/modules/2.6.38-2-amd64/build SUBDIRS=/usr/src/fglrx-8.841/2.6.x modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.38-2-amd64'
CC [M] /usr/src/fglrx-8.841/2.6.x/firegl_public.o
/usr/src/fglrx-8.841/2.6.x/firegl_public.c: In function ‘KCL_GlobalKernelLock’:
/usr/src/fglrx-8.841/2.6.x/firegl_public.c:1903: error: implicit declaration of function ‘lock_kernel’
/usr/src/fglrx-8.841/2.6.x/firegl_public.c: In function ‘KCL_GlobalKernelUnlock’:
/usr/src/fglrx-8.841/2.6.x/firegl_public.c:1909: error: implicit declaration of function ‘unlock_kernel’
make[4]: *** [/usr/src/fglrx-8.841/2.6.x/firegl_public.o] Fehler 1
make[3]: *** [_module_/usr/src/fglrx-8.841/2.6.x] Fehler 2
make[2]: *** [sub-make] Fehler 2
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.38-2-amd64'
make: *** [kmod_build] Fehler 2
build failed with return value 2

Ich tippe ja drauf, dass man da noch über das entfernte BKL stolpert.