Mein Zweithirn

Vor einiger Zeit hab ich mal über Accessfs geschrieben [1]. Mittlerweile sind wir bei Kernelversion 2.6.30. Leider gibt es auf der Herstellerhomepage Patches nur bis Version 2.6.26, daher habe ich mal einen für 2.6.30 gebaut [2].

Quellen:
[1] http://zweithirn.friiks.de/archives/148-Unprivilegierte-Prozesse-auf-privilegierten-Ports.html
[2] http://subversion/repository/fem-overlay/trunk/sys-kernel/xen-sources/files/accessfs-2.6.30-0.22.patch

Zuletzt habe ich mal wieder einen neuen Server aufgesetzt, natürlich mit Gentoo.

Leider hatte ich keine Gentoo Boot-CD am Start, so dass ich auf ein Knoppix 5.1 zugegriffen habe, was für eine Gentoo-Installation ja egal sein sollte.

Sollte.

Die zwei Festplatten im Rechner sollten als Software-RAID 1 konfiguriert werden. Also "Linux raid autodetect" Partitionen angelegt (partition type FD) und mit mdadm die Raiddevices erstellt und damit den Raidsuperblock geschrieben.

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/hda1 /dev/hdb1

Das ganze formatiert, eingehangen und mit nem Gentoo bestückt.

Nachdem alle wichtige Pakete emerget, der Kernel gebacken und der Grub konfiguriert und in den MBR geschrieben wurde, stand neustarten an.

So weit so gut, jedoch erklärte der Kernel panisch, er könne sein Rootdevice nicht finden. Weiter oben im Log sah mal das md-Subsystem hochfahren, ohne jedoch für den Betrieb im RAID konfigurierte Geräte zu finden.

md: raid1 personality registered for level 1
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
...
md: unknown device "md0" or unknown block device (9,0)
VFS: Kernel panic (something about root= parameter not set right).

Es hat eine Weile gedauert, bis ich dahinterkam, woran es lag.

Für den RAID-Superblock gibt es 2 sehr unterschiedliche Formate (metadata format), Version "version-0.90" und "version-1". Genaue Details und Unterschiede findet man in einem Kernerlwiki [1]. 

Wenn "md" in den Kernel einkompiliert wurde (nicht als Modul!), ist er in der Lage, RAID-Devices automatisch zu erkennen und zusammenzusetzen. Das geht aber nur mit Metadata-Version 0.90. Für die andere Version muss ein Userspace-Programm aufgerufen werden. Um dies vor dem Einhängen der Rootpartiton zu erledigen (um davon booten zu können), bräuchte man dazu eine initiale Ramdisk (initrd), was unter Gentoo wiederum relativ unüblich ist. [2]

Da Knoppix ein Debianderivat ist, gehört dort eine initrd natürlich dazu. Daher erstellt das mdadm unter Knoppix standardmäßig RAIDs mit Version-1-Superblöcken, unter Gentoo jedoch mit Version 0.90 als Standardwert, wie in der Manpage angegeben.

Deswegen war der Kernel ohne initrd auch nicht in der Lage, die Devices zusammenzusetzen.

Neuerstellen des RAIDs mit Metadata-Version 0.90 sorgte für Abhilfe.

Unter Knoppix/Debian:

mdadm --create /dev/md0 --metadata=0.90 --level=1 --raid-devices=2 /dev/hda1 /dev/hdb1

Quellen:
[1] http://linux-raid.osdl.org/index.php/RAID_superblock_formats
[2] http://bugzilla.kernel.org/show_bug.cgi?id=7208#c3

Für das Subversionrepository verwenden wir Websvn als Frontend.

Nach einem PHP-Update funktionierte plötzlich das MultiViews-Feature [1] nicht mehr, mit dem Websvn kürzere und lesbarere URLs realisiert.

[error] [client x.x.x.x] Negotiation: discovered file(s) matching request: /var/www/localhost/htdocs/websvn/wsvn (None could be negotiated).

Im Bugtracker hatte bereits jemand das Problem gemeldet [2]. Ursache ist ein Update der mod_php5.conf für das Apachemodul. Dort wurde die Einbindung von PHP auf die vom Hersteller empfohlene Weise umgestellt [3]. Dabei wird auf SetHandler statt AddType gesetzt:

# Set it to handle the files
<FilesMatch "\.ph(p5?|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>

<FilesMatch "\.phps$">
SetHandler application/x-httpd-php-source

</FilesMatch>

Um PHP mit MultiViews wieder zu aktivieren, reicht ein

AddType application/x-httpd-php .php

in der entsprechenden Vhost-Konfiguration oder in einer .htaccess.

Quellen:

[1] http://httpd.apache.org/docs/2.2/content-negotiation.html
[2] http://bugs.gentoo.org/show_bug.cgi?id=256941
[3] http://www.php.net/manual/en/install.unix.apache2.php Example #1 Installation Instructions - Schritt 15 

Nach einer Weile googlen und ausführliches FAQ [2] lesen, hab ich nun eine stabile Konfiguration, in der alle Tasten zumindest zwischen Client und Server funktionieren.

Meine ~/.x11vncrc:

rfbauth /home/pegro/.vnc/passwd
display :0
forever
bg
skip_lockkeys
nomodtweak

rfbauth kümmert sich um die Authentifizierung

forever lässt den Dienst weiterlaufen, wenn sich der Client abmeldet

bg schickt den Dienst in den Hintergrund (starten des Daemon durch "x11vnc" ohne Parameter)

skip_lockkeys ignoriert alle einrastenden Tasten (Capslock, Scrolllock, ...) verhindert auch nerviges Einrasten der Alt-Taste nach einem Fensterwechsel mit Alt+Tab

nomodtweak schaltet einen Mechanismus ab, der bei unterschiedlichen Tastaturlayouts hilft, z.B. ein fehlendes AltGr auf der Tastatur zu emulieren

Den letztgenannten Mechanismus hab ich deaktiviert, da die meisten VNC-Clients, die ich getestet habe, dieses Verhalten scheinbar selber übernehmen und es dadurch zu komischen Effekten kam.

Als brauchbar haben sich folgende Clients erwiesen:

Mac OS X: RealVNC Enterprise Edition Viewer
Linux: KRDC, RealVNC Viewer, ...
Windows: RealVNC Viewer

Quellen:

[1] http://www.karlrunge.com/x11vnc
[2] http://www.karlrunge.com/x11vnc/faq.html#faq-altgr