Allerdings machte der Scanner beim Einrichten unter openSUSE 11.0 Probleme (unter 11.1 habe ich es noch nicht getestet). YaST2 blieb einfach hängen, es tat sich nichts mehr.

Das Problem lies sich auf eine geradezu lächerlich triviale Weise beheben:
In der Datei /etc/sane.d/dll.conf gibt es eine Liste mit Konfigurationsdateien zu den jeweiligen Scannermodellen. Die sind standardmäßig alle auskommentiert. Sobald man den Kommentar vor der jeweiligen Datei löscht, die für die Konfiguration des Scanner gebraucht wird, funktioniert die Erkennung des Scanners.
Im Fall des Mustek 1248UB muss also die Zeile

#gt68xx

durch

gt68xx

ersetzt werden.
Schon klappt die Konfiguration mit YaST2 und Kooka erkennt den Scanner auch wieder.
(Achja: Das Firmware Image SBSfw.usb von der Treiber-CD für den Scanner muss noch ins Verzeichnis /usr/share/sane/gt68xx.)

Es gibt aber auch eine sehr schöne, saubere, geradzu elegante Lösung.
Man überlädt die udev-Regeln, die von openSUSE mitgebracht werden.

Für openSUSE 11.1 funktioniert das wie folgt:

Normalerweise werden die Gerätedateien unterhalb von /dev/bus/usb nach einer Regel angelegt, die in der Datei /lib/udev/rules.d/50-udev-default.rules steht. (Bei openSUSE 11.0 lag die Datei noch unter /etc/udev).
Die Regel lautet:

# libusb device nodes
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"

Diese Regel bewirkt, dass die Gerätedatei unterhalb von /dev/bus/usb mit dem Modus 644 angelegt wird. Außerdem gehört sie standardmäßig root:root.

Da die Datei bei einem Update wieder überschrieben würde, muss eine neue Datei anlegt werden, die /etc/udev/rules.d/99-local.rules heißen soll. (99 damit sie nach den Default-Regeln gelesen wird)
In diese Datei wird folgende Regel geschrieben:

# libusb device nodes
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0664"

Damit gehören die Gerätedateien in Zukunft der Gruppe uucp und alle Mitglieder der Gruppe können auf die Dateien schreiben.

Um in diese Gruppe zu gelangen, muss in der Datei /etc/group der Nutzeraccount bei der Gruppe root ergänzt werden:
root:x:1:gustav

Das war’s schon. Funktioniert prima.

Naja, der Trick, CAcert.org allen auf OpenSSL basierenden Anwendungen bekannt ist relativ einfach:

Man lädt die Zertifikate root.crt und class3.crt im PEM-Format von CAcert.org und speichert sie als ca-root.pem und ca-class3.pem im Verzeichnis /etc/ssl/certs.

Anschließend führt man als root folgendes Kommando aus:
c_rehash

Jetzt werden die Hash-Links auf die neu installierten CA angelegt und das war’s schon!

arplookup 88.XXX.XXX.XXX failed: host is not on local network

Diese tauchten jeden Tag in den Statuslogs der Server auf und machten das morgendliche E-Mail-Lesen zur Qual.

Nun habe ich endlich einmal die Zeit gefunden, diesen Meldungen auf den Grund zu gehen. Google liefert etliche Tips, doch einfach den Kernel zu patchen und die Meldungen auf diese Weise loszuwerden – nicht mein Stil, die Meldungen haben ja eigentlich einen Sinn.
Also bin ich irgendwann auf folgende Lösung gestoßen:

Man trägt eine statische Route in /etc/rc.conf ein, die die IP-Adresse auf das entsprechende Interface zuweist:


static_routes="gw"
route_gw="-host 88.XXX.XXX.XXX -interface re0"


Ein Aufruf von netstat liefert dann das den neuen Eintrag


Internet:
Destination Gateway Flags Refs Use Netif Expire
...
88.XXX.XXX.XXX 00:02:85:XX:XX:XX UHLS 1 0 re0
...


Leider mit der MAC-Adresse der lokalen Netzwerkkarte – was zwar die arplookup-Meldungen verschwinden lässt, dafür aber eine neue ständige Fehlermeldung hervorruft, die mindestens genauso nervt.


arp: 00:02:86:XX:XX:XX attempts to modify permanent entry for 88.XXX.XXX.XXX on re0


Doch diese Meldung kann mit dem Tool arp abgefschafft werden.

Diese trägt man in die ARP-Tabelle ein. Ich habe das, um es gleich statisch zu haben, in die Datei /etc/arptab geschrieben. Man schreibt einfach die IP-Adresse gefolgt von der korrekten MAC-Adresse:


88.XXX.XXX.XXX 00:02:86:XX:XX:XX


Jetzt muss das ganze noch aktiviert werden. Das geschieht mit dem Befehl:


/usr/sbin/arp -f /etc/arptab


Diesen Befehl kann man einfach in die Datei /etc/rc.local schreiben um die Änderung der ARP-Tabelle bei jedem Neustart verfügbar zu machen.


.if ${.CURDIR:M/basejail/usr/ports/net-mgmt/net-snmp}
CONFIGURE_ARGS=--with-out-mib-modules="host" --without-kmem-usage
.endif


Im Home-Verzeichnis legt man das Verzeichnis .fonts an und kopiert die Schriftarten dorthin.
Anschließend läßt man ein fc-cache laufen, um die Meta-Informationen der Schriftarten zu generieren.

Zu guter Letzt muß man den neuen Schriftartenpfad noch dem X11-Server bekanntmachen. Das geschieht auf diese Weise:
Mit xset fp+ ~/.fonts macht man das Verzeichnis als Font Path bekannt und mit einem anschließenden Aufruf von
xset fp rehash sagt man dem X11-Server er soll seine Informationen über Verzeichnisse, in denen Schriftarten installiert sind, aktualisieren.

Manche Programme, wie der Acrobat Reader müssen danach aber neu gestartet werden, um die neuen Schriftarten nutzen zu können. Die Prozedur klappt auf jeden Fall unter SuSE Linux und FreeBSD, und sollte auch unter allen anderen Systemen mit X11 funktionieren.

Statt des normalen Aufruf nutzt man das luit von X.org:

LANG=de_DE luit centericq

Normalerweise gibt man ja die Sprache anders an, z.B. LANG=de_DE.UTF-8.
Das funktioniert aber in diesem Fall nicht!

Auf jeden Fall habe ich gleich mal die CenterICQ.desktop-Datei für die KDE-Konsole hochgeladen
Einfach nach ~/.kde/share/apps/konsole/ kopieren.