Grund genug für meinen Mitbewohner, den Kanal unseres WLAN-Access-Points mal in eine bisher wenig genutzte Region zu verschieben: Kanal 13. Nachtigall ick hör Dir trapsen, war da nicht mal was, mit Kanälen, die in den USA verboten sind, in Europa aber nicht? Muss wohl so sein, und da Debian ja fürsorglich ist, ist die Einstellung für USA default – obwohl, wenn man sich die Lösung ansieht, kann man Debian vermutlich nicht mal die Schuld in die Schuhe schieben.

Was also, wenn das Notebook jetzt nur Netze bis Kanal 11 anzeigt? Dann legt man unter Debian eine Datei in /etc/modprobe.d/ an. Wie die heißt, ist nicht so wichtig, bei mir heißt die wlan_EU.conf, auf .conf sollte sie wohl enden. Drin steht bei mir folgendes:

options cfg80211 ieee80211_regdom=EU

Eine Zeile, reicht aus. Die übergibt dem Kernelmodul cfg80211 beim Laden die passende Option und dann sind alle Kanäle sichtbar. An einigen Stellen im Weltnetz steht das “EU” noch in Anführungszeichen, also wenn’s ohne nicht klappt, dann vielleicht mit.

Vor einigen Tagen nun gab es in Debian Squeeze ein Update von udev 149 auf 150. Das Paket verweigerte dann aber die Installation mit dem Hinweis, dass der verwendete Kernel zu alt sei. Das war durchaus nervig, weil dadurch auch die Updates anderer Pakete nicht mehr eingespielt wurden, also hieß es: Kernel-Update.

Einfach mal schnell Kernel-Update gestaltete sich dann leider nicht so einfach. Debian hat Xen quasi aus der Distribution rausgeworfen bzw. bietet keine dedizierten Xen-Kernel mehr an. Gut, das ließ sich noch relativ problemlos lösen. Die Wahl fiel auf linux-image-2.6.30-bpo.2-686-bigmem von backports.org, denn dort heißt es:

This kernel also runs on a Xen hypervisor. It supports only unpriviledged (domU) operation.

Also fix den Kernel in der Dom0 installiert. DomU runtergefahren, Config angepasst, Kernelmodule ins Dateisystem der DomU kopiert, DomU gestartet und dann – nichts. Beim Hochfahren blieb die virtuelle Maschine einfach hängen, und zwar schon so früh im Bootprozess, dass ich keine Ahnung hatte, woran das lag.

Der nächste Schritt bestand dann darin eine weitere VM zum Testen aufzusetzen und die Suchmaschine der Wahl zu befragen. Ich weiß nicht, wo ich überall gelesen habe und was ich alles probiert habe. Am Ende funktionierte der Kernel, es waren nur Anpassungen an der Xen-Config notwendig, daher erstmal hier die Config und dann noch ein paar Kommentare dazu:

kernel  = '/boot/vmlinuz-2.6.30-bpo.2-686-bigmem'
ramdisk = '/boot/initrd.img-2.6.30-bpo.2-686-bigmem'
memory  = '128'
root    = '/dev/xvda1 ro'
disk    = [ 'phy:heaven/falbala_root,xvda1,w',
            'phy:heaven/falbala_swap,xvda2,w' ]
name    = 'falbala'
vif  = [ 'mac=00:16:3e:7d:4b:a2, bridge=eth0' ]
extra = 'xencons=hvc0 console=hvc0'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Wie man sieht, sind die Block-Devices, die in die VM gereicht werden, LVM Logical Volumes. Hier musste ich die Durchgereichten von /dev/sda* auf /dev/xvda* wechseln. Das hat definitiv mit dem verwendeten Kernel zu tun, der die Blockdevices nur noch dort ähm findet, oder so. Ich denke das war die entscheidende Änderung. In der mit »extra« beginnenden Zeile, habe ich die Angaben für die Xen-Konsole noch angepasst, irgendwo hatte ich gelesen, dass das jetzt hvc0 und nicht mehr xvc0 heißen muss. Die entsprechenden Änderungen an /etc/fstab und /etc/inittab innerhalb der virtuellen Maschine mussten natürlich auch noch vorgenommen werden, aber danach lief die DomU wieder und auch das Update von udev ließ sich problemlos einspielen. :-)

FH_DATE_PAST_20XX

Diese Regel vergibt Punkte fuer alle E-Mails die ab dem 01.01.2010 datiert sind. Und nicht nur ein paar Zehntel, sondern bis zu 3.5 Punkte — bei insgesamt 5 nötigen Punkten für eine Spam-Klassifizierung macht das sehr viel aus. Effektiv wurde damit die Grenze für Spam auf 1.5 Punkte herabgesetzt.

Die Lösung ist im Apache-Wiki zu finden und wurde gleich noch mitgeliefert: In der lokalen Konfiguration muss diese Regel manuell deaktiviert werden, indem man die vergebenen Punkte auf 0.0 setzt. (Ein sa-update hatte bei mir keinen Effekt.)

Das ist mal ein schönes Beispiel dafür, dass insbesondere Regeln, die nicht global gültig sind und bleiben, regelmäßig begutachtet und gegebenenfalls überarbeitet werden müssen.

Seit einigen Tagen mag sich Eclipse unter Debian Sid auf meinem Arbeitsnotebook nicht mehr mit dem Internet verbinden. Die Fehlermeldungen sind, je nach Modul, verschieden, laufen letztendlich aber immer auf etwas in der Form “Network noch reachable” hinaus. Erst dann fällt auch auf, wie oft ich doch bei der Entwicklung auf das Internet zugreife: Subversion und Maven funktionieren nicht mehr, Updates und das Einspielen von Plugins ist unmöglich und irgendwann – ein wichtiger Hinweis auf die Fehlerursache – stellte sich heraus, dass gar keine Java-Anwendung mehr Zugang zum Netzwerk hat.

Nachdem ich zunächst nach Fehlern bei Eclipse gesucht habe, war die Lösung nun recht nahe: Ein Blick in die Fehlerberichte für das Paket sun-java6-jdk zeigt den Bug #560044, der genau mein Problem beschreibt. Offenbar hält SUNs Java sich nicht an die Konventionen für den Umgang mit IPv4- und IPv6-Verbindungen, so dass IPv4 gar nicht mehr funktioniert.

Der Fehlerbericht enthält am Ende auch einen Workaround, der bei mir funktioniert: In der Datei /etc/sysctl.d/bindv6only.conf die Variable net.ipv6.bindv6only von 1 auf 0 setzen, und schon dürfen IPv6-Sockets auch IPv4-Pakete empfangen. [Update: Mit dem Aufruf invoke-rc.d procps restart muss die Konfiguration dann noch neu geladen werden.] Problem solved.

Nun muss dieser Bug nur noch unter dem Google-Query “Debian Eclipse network connection error” erscheinen, dann wäre er auch keinen Blogeintrag mehr wert. 8-)

Ich habe gerade eine halbe Stunde damit verbracht, mal wieder diesem grandiosen xkcd-Comic gerecht zu werden. Los ging das mit einem Link, den ich bei qbi im Blog gefunden habe: Surviving the Perl/UTF-8 Madness. Der Name des Autors kam mir bekannt vor, ich glaube Tux hat ab und zu mal Links von dessen privatem Blog fallen lassen. Ich war also gespannt, was da kommt und wurde dann leider enttäuscht.

Worum geht’s? Es geht um Perl und wie Perl mit Encodings umgeht. Seit Perl 5.8 gibt es da ein sinnvolles Vorgehen, das sich aber anscheinend noch nicht rumgesprochen hat. Nachlesen kann man das sehr gut zusammengefasst im Tutorial perlunitut. Ich fasse das hier nochmal auf deutsch zusammen, weil es da anscheinend immer noch Missverständnisse gibt.

Wichtig zu wissen: Perl unterscheidet text/character strings von byte/binary strings (und das wirkt sich auf bestimmte Befehle wie print, uc, length usw. aus). Es wird häufig behauptet, die text strings wären UTF-8. Das mag so sein, ist aber völlig irrelevant und geht am eigentlichen Problem vorbei. Wie Perl diese text strings intern darstellt, kann einem total egal sein. Wichtiger ist, wie man damit umgeht und das fasst auch perlunitut korrekt zusammen:

1. Receive and decode
2. Process
3. Encode and output

D.h. alles, was von außen kommt, egal ob von Nutzereingaben, aus Dateien oder Datenbanken, ist zunächst mal ein binary string. Wenn das Zeichenketten sind, mit denen ich Zeichenkettenoperationen durchführen will, muss ich die als erstes von byte strings in character strings umwandeln. Dazu kann ich binmode setzen, einen encoding Parameter bei open nutzen oder die decode-Funktionen aus dem Module Encoding bemühen, das ist faktisch alles das selbe, Tim Toady halt.

Der zweite Schritt ist klar: process, irgendwie auf den character strings rumackern. Beim dritten Schritt, dem output aus Perl raus dann der umgekehrte Weg: ich wandle meine character strings zurück in byte strings mit dem entsprechenden Encoding meiner Zielplattform, sei es nun STDOUT, ein file oder eine Netzwerkverbindung, egal und ebenfalls egal, ob das iso8859* oder UTF-8 oder sonstwas ist. Wenn man diese drei Schritte im Kopf behält und Worte wie utf-8 flag aus seinem Hirn streicht, kommt man mit Perl und Zeichensätzen klar.

Bisschen aufpassen muss man bei Fremdmodulen, da muss man im Zweifelsfall mal genauer hinsehen, wie die das handhaben. Was man vermeiden sollte: einfach davon ausgehen, dass Perl intern UTF-8 zur Repräsentation von character strings verwendet. Damit wird man über kurz oder lang auf die Nase fallen.

Neben perlunitut gibt es noch weitere gute Quellen zum Nachlesen:

• eine Einführung in die Problematik auf deutsch: Zeichenkodierungen oder „Warum funktionieren meine Umlaute nicht?”
• die Perl-Unicode-FAQ: perlunifaq

Wenn man tiefer eintauchen will, kann man auch noch perlunicode oder perluniintro lesen, aber das ist dann schon harter Stoff. ;-)

Opera hat festgestellt, dass KDE läuft.

Einige von Operas Tastaturkürzel (wie Strg+F4) könnten nicht funktionieren, da KDE diese reserviert hat.

Sie können die KDE Tastenkürzel im KDE Kontrollzentrum ändern.

WTF? Ich werde doch nicht mein ganzes System umstellen, nur weil ein einziger proprietärer Browser da gern seine eigenen Tastenkürzel hätte. Zumal ich bei Opera sowieso immer das Problem habe, dass ich mit Tastenkürzeln, die ich aus anderen Programmen kenne, dort ins Leere laufe oder völlig unerwartete Sachen auslöse. Wieso schlägt Opera nicht vor, wie man seine eigenen Tastaturkürzel ändert? Frechheit! Naja, bleibt es halt weiterhin nur der billige Pornobrowser …

Infolge der Aufrufe erreichten uns insgesamt 7 Einsendungen per Mail. Zwei davon waren schlicht falsch, zwei mussten bedauerlicherweise wegen Insider-Wissen ausgeschlossen werden – die klassische Nummer halt: Verwandte, Mitbewohner und Haustiere der Veranstalter sind von der Teilnahme ausgeschlossen – und zwei waren direkt richtig. Die siebte Antwort ließen wir wegen profunder Literaturkenntnis und einem sich überraschend auftuenden zusätzlichen Zusammenhang ebenso gelten. Ich zitiere aus dieser Einsendung:

Die Antwort lautet natürlich 42, wie denn auch sonst. Dargestellt sind
Kastanien – mit denen kann man eine schöne Zeit verbringen.

Zu tun hat das ganze natürlich mit dem Anhalter. Zaphod erzählt darin,
dass er einen Megafrachter überfallen hat, um Kastanien zu erbeuten.

Gemeint ist das Buch »Per Anhalter durch die Galaxis« von Douglas Adams. Im Original ist von conkers die Rede, sozusagen horse chestnuts, also gewöhnlichen Rosskastanien der Gattung Aesculus (nicht zu verwechseln mit sweet chestnuts aka Esskastanien aka Castanea).

Doch wie lautete die von uns zuvor von uns erwartete Antwort auf die dritte Frage? Ich zitiere aus einer anderen richtigen Einsendung:

Die sieben Kastanien können als 0101010 interpretiert werden. Wenn das Binärcode sei, ist das dezimale Pendant die Zahl 42.

Goldrichtig! Nun war irgendwann die Zeit für die Einsendungen abgelaufen und wir konnten uns nicht so recht einigen, wann und wie wir das auslosen wollten. Im September packten wir dann die Gelegenheit beim Schopfe. Auf einer privaten Geburtstagsfeier waren zwei von drei der Initiatoren und zwei von drei potentiellen Gewinnern anwesend. Im Kreise dieser (und anderer) Zeugen wurde nach zuvor erfolgtem Mapping ein klassischer W6 Würfel ein einziges Mal geworfen, woraufhin dann der Gewinner fest stand.

Leider können wir kein Bild präsentieren, weil der Gewinner den Gewinn noch nicht eingelöst hat. Stattdessen gibt es das Motiv jetzt auch in einer englischen Variante, die unten abgebildet ist. Entsprechende Shirts sind weiterhin in unserem Shirtshop erhältlich.

Alle Einsender werden mit Hinweis auf diesen Blogeintrag nochmal per E-Mail benachrichtigt.

Warum erzähle ich das?

Als Linux in verschiedenen Distributionen begann, den Desktop zu erobern und mit der Ausbreitung des Internets auch Viren, Würmer und andere Malware populär wurden, stellte sich eines heraus: So richtig betroffen waren nur die Windows-Nutzer. Einen Virus für Linux zu schreiben, war ungleich schwerer und die Zahl der Nutzer war doch nicht hoch genug, als dass es sich lohnte. Folglich ist der Linux-Nutzer (und jeder Nutzer anderer Betriebssysteme) gegen die Windows-Viren resistent. Was besagten Nutzer jedoch nicht davor bewahrt, unwissend Überträger zu sein. Denn niemand verhindert, dass er auf seiner Festplatte, seinem USB-Stick und in seinen E-Mails Dateien hat, die eine Form von Schädling enthalten. Ein Windows-Nutzer, der eine Datei eines Linux-Nutzers weniger argwöhnisch öffnet, weil er ihm vertraut, wird so doch das Opfer einer Attacke gegen sein System. Ein Vertrauensbruch, der so nicht beabsichtigt war.

Jeder Windows-Nutzer lernt beizeiten, einen Virenscanner zu installieren, um sich gegen Schädlinge zu schützen. Linux-Nutzer fühlen sich sicher und brauchen solche Software nicht. Damit werden sie zum idealen Überträger, da sie nicht einmal wissen, was sich auf ihrer Platte tummelt.

Aufgefallen ist mir das, als mir jemand schrieb, in einer von mir hochgeladenen Datei (die ich auch von anderer Stelle per USB-Stick empfangen habe) einen Virus entdeckt zu haben. Zwar handelte es sich um einen Fehlalarm, trotzdem macht dies eines klar: Selbst wer nicht betroffen ist, sollte seinen Datenbestand hin und wieder nach Viren untersuchen!

Freie Virenscanner gibt es zum Beispiel mit ClamAV, die man per Cron-Job regelmäßig über seine Daten jagen kann. USB-Sticks lassen sich bei Bedarf automatisch überprüfen, wenn man auf die Daten zugreift, und schon ist das Netz ein wenig dichter und die Gefahr, selbst zur Virenschleuder zu werden, ein Stück geringer.

Erster Schritt:

aptitude install texlive-full vim-latexsuite

Ja ich weiß, das ist das Rundum-Sorglos-Paket, was mir auch sehr viel Kram auf die Platte spült, was ich nie nutzen werde. Macht nichts, so ist das halt mit Rundum-Sorglos-Paketen. vim-latexsuite will noch aktiviert werden – wie, musste ich auch erst im Netz wiederfinden. Sehr hilfreich:

man vim-addons

Soweit so gut, als nächstes habe ich dann den Ordner ~/texmf aus meinem Backup zurückgespielt. Einfach mal `texhash` eingeben hat dann allerdings noch nicht dazu geführt, dass das System da was mit anfangen wollte, also wieder Doku wälzen. Ergebnis:

mktexlsr ~/texmf

Führte erstmal dazu, dass ich das gewünschte Dokument kompilieren konnte, aber ich bekam noch Warnungen, dass was mit den Fonts nicht stimmte:

LaTeX Font Info:    Try loading font information for OMS+lmss on input line 110
.
LaTeX Font Info:    No file OMSlmss.fd. on input line 110.

LaTeX Font Warning: Font shape `OMS/lmss/m/n' undefined
(Font)              using `OMS/cmsy/m/n' instead on input line 110.

LaTeX Font Info:    External font `lmex10' loaded for size
(Font)              <10> on input line 110.
LaTeX Font Info:    External font `lmex10' loaded for size
(Font)              <7> on input line 110.
LaTeX Font Info:    External font `lmex10' loaded for size
(Font)              <5> on input line 110.

Die Suche, wie man das beheben kann, war nicht so super aufschlussreich. Ich hab das dann wie folgt beheben können, wo bei ich nicht weiß, ob das jetzt die eleganteste Lösung ist:

\usepackage{textcomp}

Alles in allem, ich schau grad mal auf die Uhr, über eine Stunde, um den Kram zusammenzusuchen, um dann festzustellen, dass ich auch noch das Dokument übersetzen muss, weil es in Englisch geschrieben ist. *sigh*

Auf meinem neuen Netbook ist nun Windows XP Home vorinstalliert gewesen. Ich hab das mitbezahlen müssen und ich gebe zu, dass ich es draufgelassen habe, einfach um ab und zu nochmal Diablo II spielen zu können, ohne da im Linux große Verrenkungen anstellen zu müssen mit Installation, Spiele-3D-Grafik oder gar Wine. Nun ist es drauf und ich will es auch booten können. Der Installer von Debian Stable (Lenny) hatte das seinerzeit korrekt erkannt und in der Konfiguration von GRUB Legacy eingetragen.

Beim Upgrade auf GRUB 2 hat Debian diesen Eintrag nun schlichtweg ignoriert. Es hat auch keine neue Suche nach alternativen Betriebssystemen angestrengt, obwohl man vermutlich nur ein bisschen Code aus dem Installer hätte nutzen müssen. In der Liste der zum Boot möglichen Systeme tauchte Windows jedenfalls nicht auf.

Wie das nun bei dicken Rewrites so ist, die noch während des Beta-Stadiums ohne richtige Dokumentation auf die Nutzer losgelassen werden: man steht erstmal im Regen. Dazu kommt, dass der Distributor sich dann noch was ausdenkt, um das sauber in sein System zu integrieren. Bei der Suche, wo ich das nun eintragen müsste, hab ich dann folgendes herausgefunden:

Die neue Config-Datei von GRUB 2 ist /boot/grub/grub.cfg. Das erste was bei Debian drin steht:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

Soviel Hilfe hätte ich gar nicht erwartet. In /etc/default/grub kann man zunächst mal ein paar Optionen für den Kernel zum Laden setzen. Sowas wie quiet oder vga=789 oder ähnliches. Die Syntax ist selbsterklärend.

In /etc/grub.d liegen dann verschiedene Skripte:

-rwxr-xr-x 1 root root 3223 12. Sep 18:08 00_header
-rwxr-xr-x 1 root root 1152 12. Sep 17:56 05_debian_theme
-rwxr-xr-x 1 root root 3221 10. Aug 19:49 10_linux
-rwxr-xr-x 1 root root 4418 12. Sep 18:08 30_os-prober
-rwxr-xr-x 1 root root  281  7. Okt 23:07 40_custom
-rw-r--r-- 1 root root  483 10. Aug 19:49 README

Die sollte man auch alle brav in Ruhe lassen, wenn man sich nicht wirklich gut mit Shell-Scripting auskennt. Allerdings ist 40_custom genau der richtige Ort für unseren Eintrag um Windows zu booten. Dieser Eintrag sieht dann ungefähr so aus, bzw. gleich mal die ganze Datei, damit das klar wird:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Windows XP" {
    set root=(hd0,2)
    chainloader +1
}

Auch dies ist nur ein Shell-Script, das irgendwann im Update-Prozess für die Konfigurationsdatei von GRUB 2 ausgeführt wird. Bei der Angabe der Partitionsnummer aufpassen, da gab es eine Verschiebung um +1 gegenüber GRUB Legacy. Jetzt also noch den abschließenden Debian-spezifischen Befehl ausführen, um die neue grub.cfg zu schreiben und schon kann man wieder Windows booten:

update-grub

Update: Seit dem Update von heute, 24.01.2010, erkennt Debian Squeeze die Windows-Installation wieder automatisch. D.h. man kann den Inhalt aus /etc/grub.d/40_custom wieder rausnehmen. Einmal update-grub aufrufen sollte danach genügen, um Einträge für Windows in die Liste zu zaubern.