Eigentlich hatte ich nach dem Aldipod-Desaster vor ein paar Jahren beschlossen, keine Medion-Hardware mehr zu kaufen. Diese Woche habe ich mich aber doch wieder hinreissen lassen: Aldi hatte am Montag eine kleine Bluetooth-Laser-Maus für 20 Euro im Programm. Bluetooth klingt für mich insofern verlockend als dass ich die so am Notebook ohne Dongle benutzen können müsste. Und der Preis klingt für eine Maus die nur alle paar Wochen mal benutzt werden soll fair. Also: gekauft.

Für eine Notebook-Maus liegt die gut in der Hand, und Linux hat das Ding auch direkt gefunden. Trotzdem bin ich nicht glücklich: der Mauszeiger unter X wandert entweder schlagartig oder schrittweise auf eine Bildschirmecke zu. Ich habe in der xorg.conf alles ausprobiert was mir sinnvoll erschien, also die Einstellungen von ‚Driver‘ und ‚Protocol‘ ordentlich durcheinander gewürfelt. Arch Linux ist nicht für Frickelfreiheit bekannt, also mal eine Ubuntu Live-CD zu Rate gezogen — mit dem gleichen Ergebnis. Auch auf einem anderen Notebook mit GRML sah es genauso aus. Nur ein Arbeitskollege hatte mit seinem Windows-Notebook mehr Glück.

Ich dachte dass Bluetooth so sauber spezifiziert wäre dass die Geräte austauschbar wären? Nicht? Hat jemand Vorschläge was ich noch probieren könnte? Wenn nicht geht das Ding die Tage wieder in den Laden…

Ich habe seit ein paar Wochen ein mistiges Problem mit meinem Server zu Hause. Ich bin mir nicht bewusst eine Änderung gemacht zu haben die als Ursache her halten könnte, aber das ist ja immer so… ;-)

Vielleicht kann mir ja jemand aus der Leserschaft helfen:

Nach einer gewissen Laufzeit — beobachtet habe ich Zeiten zwischen einer und drei Wochen — fängt die Systemuhr an zu rasen. Alles ist wie immer, nur dass die Zeit etwa vier mal so schnell gezählt wird wie auf allen anderen Uhren. Der Server liefert die Zeit in mein Netz, also fängt früher oder später auch der Videorecorder und alles andere an zu spinnen. :-(

Auf dem Server (Debian Etch, 2.6.18-6-xen-vserver-686) läuft ein ntpd, an dessen Konfiguration ich aber ewig nichts mehr gemacht habe. Alle Versuche dem Spuk ein Ende zu bereiten sind bislang fehlgeschlagen. Nur ein Reboot hilft. Für ein bis drei Wochen zumindest…

Ich bin ratlos. Hat wer einen Tip?

Ich sitze hier meistens an einem Thinkpad mit englischer Tastatur. Normalerweise ist das echt praktisch, ich hab mich dran gewöhnt. Wenn ich aber zum Beispiel was in den Blog schreibe mache ich das üblicherweise doch unter Verwendung von Umlauten. Bis Gestern habe ich mich nicht wirklich darum gekümmert wie das komfortabel geht, habe mir ziemlich billig beholfen.

Ich löte zur Zeit wieder mal an einer Tastatur rum. Das aktuelle Modell verfügt über eine eigene Compose-Taste (die auch so beschriftet ist). Das hat mich neugierig gemacht und zu etwas gebracht das ich schon lange hätte herausfinden sollen: wie man eine Tastatur bedient. :-)

Mit einer Compose-Taste kann man Zeichen schreiben die man auf der Tastatur nicht sieht. Umlaute zum Beispiel. Wenn ich [Compose][„][a] drücke (also drei Tasten nacheinander, nicht gleichzeitig) kommt ein kleines ‚ä‘ dabei raus. Mit [Compose][o][c] gibt es das allseits beliebte Copyright-Zeichen: ©.

Unter Linux ist Compose per Default auf [Shift+AltGr] untergebracht. Also sollte man einfach [Shift+AltGr][s][s] drücken können und ein ‚ß‘ erhalten. Wer es komfortabler mag baut in seine Shell-Konfiguration folgende Zeile ein, damit erhält die Caps-Lock-Taste endlich eine sinnvolle Funktion:

xmodmap -e "remove Lock = Caps_Lock" -e "keycode 0x42 = Multi_key"

So sorgt man erst dafür dass die Taste nicht mehr ‚lockt‘ (entfernt also quasi die Feststellfunktion) und belegt sie dann mit dem Symbol ‚Multi_Key‘, und das steht für die Compose-Taste. Alternativ kann man das auch in seine ~/.Xmodmap einbauen, wenn man sowas pflegt. Jetzt sollte [CapsLock][‚][e] zu einem é führen.

Zumindest in grafischen Programmen (Firefox & Co.) hat das bei mir auch auf Anhieb geklappt. Für das Terminal-Fenster habe ich eine Weile gesucht, und noch keine wirklich befriedigende Lösung gefunden, da meine ersten Versuche blöde Nebeneffekte hatten. Ich verwende urxvt und bin damit eigentlich ganz zufrieden. Ob man darin Zeichen komponieren kann hängt offenbar von den locale-Einstellungen ab. Bei mir sind die bislang nicht gesetzt, stehen also wenn ich einfach ‚locale‘ ausführe alle auf POSIX. Wenn ich zum Beispiel LC_ALL auf de_DE setze kann ich komponieren, habe aber auch deutsche Manual-Pages. Letzteres will ich nicht. Wenn ich LC_ALL auf en_US stelle klappt beides, ich habe aber noch nicht rausgefunden ob das an anderer Stelle was zum Haken bringt. Und welche Auswirkungen hier de_DE.iso885915@euro oder de_DE.utf8 haben kann ich mir nur dunkel vorstellen. Hab mich halt noch nie damit beschäftigt. Das kommt dann Heute Abend — wenn mir hier niemand mit einem Tip zuvorkommt… *mitzaunpfahlrumfuchtel* ;-)

Wo kann ich nachlesen was alles passiert wenn ich beispielsweise nur LC_CTYPE auf en_US setze? Ich habe zwischendurch kaputtformatierte Man-Pages gesehen, und nach Konsumierung der locale-Manpage könnte ich mir vorstellen dass es daran lag. Allerdings habe ich auch echt unstrukturiert getestet, kann sein dass ich mich täusche…

Oh, noch eine interessante Sache die ich nebenbei gefunden (aber auch noch nicht ausprobiert) habe: wenn ich diesen Eintrag im Kubuntu-Wiki richtig verstehe kann man sich sogar eigene ‚Kompositionen‘ bauen. Also so dass man mit [Compose][b][t][w] wirklich ‚by the way‘ schreibt. Das will alles noch ausprobiert werden…

… zum Beispiel noch nicht wie angekündigt mein letztes Mikrocontroller-Projekt zu veröffentlichen, die meisten davon sind nicht so schön: Allgemeines Plattensterben zum Beispiel.

Meine Notebook-Platte ist komplett abgeraucht. Das Backup war zwar ein halbes Jahr alt, aber die wichtigsten Änderungen habe ich in der Versionsverwaltung gehabt. Auf einem anderen Rechner. Nachdem die 20GB im Notebook tot waren habe ich die 80GB aus dem MP3-Player da rein gebaut. Der Player hat dann eine 160er Platte bekommen die hier schon bereit lag. Nicht weil ich da so viel Platz brauche, sondern einfach weil’s geht (Zugegeben, nicht vollständig. Aber 160GB stecken da jetzt drin.). ;-)

Dann habe ich meinen Server hier zu Hause in ein anderes Gehäuse gebaut. Bislang war das ein einfacher Mini-Tower der früher unter irgendeinem Schreibtisch gestanden hat. Jetzt steckt er in einem stattlichen 19″-Gehäuse und beschallt den Schrank im Keller. Das wäre eine kleine Bastelei gewesen, wenn dabei nicht auch wieder eine Platte gestorben wäre. Übergangsweise habe ich die durch eine aus dem RAID ersetzt, aber das ist kein Dauerzustand. Und da ich das jetzt richtig ordentlich machen wollte habe ich direkt ein komplett neues RAID aufgebaut. Auf Dauer sollen in der Kiste drei 500er SATA-Platten werkeln, als Software-RAID5. Also mit insgesamt 1GB 1TB (natürlich, Danke Jürgen ;-) ) Platz, darauf dann ein LVM und dann die Daten. Hauptsächlich ist das Platz fuer Backups und VDR-Aufnahmen. Das neue RAID tut so auch schon, aber die Kiste kann nicht von SATA booten. Also kommt die /boot-Partition auf eine CF-Karte an IDE, damit nicht noch eine Platte laufen muss. Um das zu machen will ich vorher einen anständigen Kernel haben, und so kommt man vom hundertsten aufs tausendste… :-(

Momentan läuft da noch ein 2.6.11, den ich 2005 mal mit Xen-Unterstützung gebacken hatte. Mittlerweile kann Debian ab Werk Xen, und 2.6.18 klingt auch deutlich weniger antik (Naja… relativ). Jetzt lautet das Stichwort aber: Upgradepfad. Und da hakt es, weil ich damals froh war das Xen überhaupt zum Rennen gekriegt zu haben. Um Pakete habe ich mich nicht gekümmert, und das beißt sich jetzt natürlich mit den Debian-Paketen. Der erste Versuch Gestern Abend ist gründlich in die Hose gegangen, da musste ich zurückrudern. Jetzt liegt wohl RTFM an…

Ach ja, und wenn das alles erledigt ist kümmere ich mich auch wieder um das angesprochene Projekt. Veröffentlicht wird das auf jeden Fall noch.

frey:~# grep "model name" /proc/cpuinfo
model name : Intel(R) Atom(TM) CPU 230 @ 1.60GHz

Atom-BoardDas ist ein brandneues Intel D945GCLF Board, darin stecken 2GB RAM und ein PICO-PSU 120 Spannungswandler. Gekauft habe ich das als Ersatz für mein Epia, das ist vor einer Weile durchgebrannt. Auf dem Ding wird also wieder ein VDR laufen, und ein Debian.

Den alten Kernel konnte ich natürlich nicht benutzen. Abgesehen davon dass der für die C3-CPU von VIA gebaut war, war da auch der falsche Netztreiber drin. Und booten soll das Ding wieder per PXE, also ohne Festplatte. Anderen Treiber reincompilieren hat nicht gereicht um den alten 2.6.18 zum Netzboot zu bewegen. Mit einem frischen 2.6.25.7 sieht jetzt alles besser aus. Mal sehen wie es weiter geht…

Ich habe ein wenig in einem Vorbereitungsbuch für die LPI-Zertifizierung geblättert. Dokumentation und insbesondere das Lesen selbiger wird da ziemlich ernst genommen:

Achtung:Als Linux-Einsteiger neigt man leicht dazu, diesen Abschnitt auf die leichte Schulter zu nehmen. Für die Praxis ist die Verwendung der Online-Dokumentation aber absolut unentbehrlich, wenn man sich nicht ganz verloren vorkommen will. Der geübte Umgang mit der Dokumentation ist sehr, sehr wichtig! (Wirklich!)

Recht hat das Buch, und ich finde die Schreibweise sehr gelungen (das ist ein 1:1-Zitat). :-)

Eigentlich bin ich der Ansicht, dass einem auf einem Server nicht viel besseres passieren kann als ein Debian. Heute wurde dieser Eindruck böse getrübt, allerdings glaube ich weiterhin dass andere Systeme nicht besser sind. Höchstens ‚anders Scheiße‘. :-)

Was passiert ist? Ich habe endlich mal den angestaubten Apache einspunktirgendwas durch einen hypermodernen Apache 2 ersetzt. Das hat im Wesentlichen gut funktioniert, mit einem kleinen Dämpfer: ich benutze SysCP um den Server zu verwalten. Das Ding hat eine MySQL-Datenbank, und darin stehen unter anderem meine Mitbenutzer. Also Namen und (verschlüsselte) Passwörter der Leute die auf dem Server was zu sagen haben. Ich habe an einer Stelle verschiedene administrative Tools installiert, auf die eben diese Benutzer zugreifen können sollen. Sowas wie phpMyAdmin, aber auch die Oberfläche von SysCP selbst. Diese Seite war bis dato über libapache-mod-auth-mysql geschützt. Naheliegend, da die Namen und die Passwörter eh in einer Tabelle liegen. Dummerweise gibt es kein libapache2-mod-auth-mysql für Etch, und damit fingen die Probleme an…

Klar, ich hätte mir da eben selbst was stricken können. Wollte ich aber nicht, unter anderem weil absehbar ist dass das keine Dauerlösung werden würde. Und genau das ist es, was mich aufregt: Das Modul gab es für Sarge, das gibt es für Sid und das wird es für Lenny auch wieder geben. Nur eben für Etch nicht. Grund ist, dass der Maintainer die Klamotten hin geschmissen hat und zur Zeit der Veröffentlichung von Etch niemand den Job haben wollte. :-(

Naja, viele Versuche und einiges an Nerven später habe ich es dann doch geschafft, wieder gegen die SysCP-Datenbank zu autorisieren. Geholfen hat eine Kurzanleitung die ich hier zu meiner persönlichen Referenz noch mal wieder gebe. Ist zwar eigentlich für Ubuntu, hat aber auch auf Etch geklappt:

To get mysql authentication working in Gutsy, you have to manually compile mod_auth_mysql:

1. wget http://heanet.dl.sourceforge.net/sourceforge/modauthmysql/mod_auth_mysql-3.0.0.tar.gz
2. wget http://www.bleb.org/software/mod_auth_mysql-3.0.0-apache-2.2.3.patch
3. tar zxf mod_auth_mysql-3.0.0.tar.gz
4. apt-get install apache2-prefork-dev libmysqlclient15-dev; apt-get --purge remove libapache2-mod-auth-mysql
5. cd mod_auth_mysql-3.0.0
6. patch < ../mod_auth_mysql-3.0.0-apache-2.2.3.patch
7. sed -i 's|#include <mysql.h>|#include <mysql /mysql.h>|' mod_auth_mysql.c
8. apxs2 -c -lmysqlclient -lm -lz mod_auth_mysql.c
9. apxs2 -i mod_auth_mysql.la
10. echo 'LoadModule mysql_auth_module /usr/lib/apache2/modules/mod_auth_mysql.so' > /etc/apache2/mods-available/auth_mysql.load
11. a2enmod auth_mysql

Configure it as follows (adapt to your environment):

<location /mysqlauth>
  AuthName "test"
  AuthType Basic
  AuthUserFile /dev/null
  AuthBasicAuthoritative Off

  AuthMySQLEnable On
  AuthMySQLAuthoritative On
  AuthMySQLDB apache_auth_test
  AuthMySQLUser authtestuser
  AuthMySQLPassword something
  AuthMySQLUserTable auth
  AuthMySQLNameField username
  AuthMySQLPasswordField passwd
  require valid-user
</location>

Hope this helps someone.

Also mir hat es definitiv geholfen, Dank an mrts. Ich musste nur noch mittels AuthMySQLPwEncryption md5 angeben wie die Passwörter verschlüsselt sind.

Naja, ganz so dramatisch muss man das vielleicht nicht ausdrücken. Aber ab Morgen (Samstag) sind es nur noch 30 Jahre bis zum gefürchteten Y2K38-Bug, bei dem Unix-Systeme Probleme mit der Zeitzählung kriegen können.

(Ja, ich weiß auch dass viele Systeme bereits jetzt Gegenmaßnahmen ergriffen haben, und man sich 2038 wahrscheinlich mehr Sorgen darum macht dass die Grafikkarte nicht für Duke Nukem Forever reicht… ;-) )