The Fresh Feeling

Nachdem ich in letzter Zeit regelmäßig bei der Audi AG in Ingolstadt unterwegs bin und dort mein Nokia E90 nicht benutzen kann, weil es eine Kamera hat, habe ich mir eine Alternative zugelegt: einen guten alten Nokia 9300i.
Zunächst hatte ich einige Probleme, den Communicator mit meinem Kontact zu synchronisieren, aber jetzt habe ich eine opensync-Konfiguration gefunden, die ziemlich gut funktioniert.
(weiterlesen…)

Seit einiger Zeit verwende ich Mustek 1248UB Scanner. Die funktionieren mit sane und Kooka recht gut.

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.)

Das E90 von Nokia und vermutlich etliche andere Handys, die per USB angeschlossen werden können, verleiten etliche Leute zu ziemlicher Akrobatik, was chmod unter /dev angeht. Störend ist das vor allem, wenn man mit opensync oder ähnlichen Tools zugreifen will.

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.

Heute hatte ich das Problem, die CAcert.org CA für curl nutzbar zu machen…
Leider findet man dazu rein gar nichts im Internet.

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!

Seit einiger Zeit nervten mich auf etlichen Servern, die ich bei Hetzner betreue, Meldungen wie:

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.

Nachdem ich eine ganze Weile versucht habe, den Net-SNMP unter FreeBSD in einem Jail zu betreiben, war die Lösung doch recht einfach.
Im Jail kann auf /dev/mem nicht zugegriffen werden, also deaktiviert man die entsprechenden Module mit einem Eintrag in /etc/make.conf:


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


Wer ein paar Schriftarten für X11 installieren will, aber keine root-Rechte auf einem System hat, kann sich wie folgt behelfen:

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.

Als Instant Messenger benutze ich seit einer kleinen Ewigkeit CenterICQ.
Das funktionierte auch bisher ganz prima. Nun bin ich aber von FreeBSD 6 zurück zu SuSE Linux 10 gewechselt, weil ich den VMware Player benötige, der ja unter FreeBSD bekanntermaßen nicht läuft.
Leider klappt das mit CenterICQ und der UTF-8 im KDE-Terminal nicht ganz so, wie’s gedacht ist.
In den unendlichen Weiten des Internet habe ich dann eine Lösung gefunden.

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.