Unix

Ich kann es nicht länger leugnen: Ich bin ein Late Adopter. Ja, ich weiss, ich schäme mich.

Worum es geht: Um UTF-8.

Bis gestern konnte ich noch friedlich und glückselig in meiner 8bittigen Welt leben, was schert mich neumodischer Kram. Ein Zeichen ist ein Zeichen ist ein Zeichen, basta.

OK, zugegeben, es war mit der Zeit immer schwerer, dem Drängen der Systeme nach UTF-8 gegen zu steuern, aber machbar war es immer noch. Und dazu kommt, dass nicht immer alles so sauber funktionierte.

Bei meinem ersten Versuch, auf UTF-8 umzustellen (irgendwann 2003), war weder die bash, noch die VGA-Konsole von Linux sowie viele andere Programme nicht darauf vorbereitet, was dann zu komischen und merkwürdigen Problemen führte. Also habe ich es bleiben gelassen und mich mit ISO-8859-15 zufrieden gegeben.

Aber dann kommt gestern nach Debian Sid ein neuer GDM (2.30), und plötzlich dringt der "Feind" UTF-8 weiter in mein Legacy-Territorium vor. Und läßt sich auch nicht mehr so einfach vertreiben.

Also denke ich mir: Warum nicht, versuche es doch einmal neu.

Zügig LANG nach de_DE.utf8 geändert und: Krude Zeichen im Terminal. Grund: rxvt kann kein Unicode, es muss das urxvt sein.

Und, oh Wunder, es funktioniert auf Anhieb. Umlaute werden korrekt dargestellt, lassen sich auch korrekt löschen (Das ist nicht selbstverständlich. Damals^TM wurde zwar ein 'ä' korrekt dargestellt, wenn man dieses aber mit der Rücktaste löschte, konnte man noch ein weiteres dargestelltes Zeichen löschen, dann intern war das 'ä' ja ein UTF-8-Zeichen, bestehens aus zwei Bytes.) und auch Programme wie mc können korrekt ihre ASCII-Art-Rahmen der Textoberfläche zeichnen.

Ein paar Probleme gab es dann aber doch noch: Die Konfiguration meines Newsreaders tin beinhaltete einige Umlaute, die mit einer UTF-8 locale nicht korrekt geparst werden konnten, aber recode hilft hier schnell und sicher.

Alles in allem hat mich die Umstellung auf 4 Systemen dann nur eine knappe Stunde gekostet und dafür bin ich auch wieder kompatibel mit den Ubuntu-Systemen meiner Kollegen, was sich vor allem in brauchbar lesbaren Einträgen im Commit-Log des internen SVNs äußert.

Willkommen in der Gegenwart, Sven!

Nach einer Stunde hadern, fluchen und verzweifeln bin ich endlich auf den Tricher gekommen, warum zum $deity das apt-pinning bei mir nicht funktionieren wollte:

Wenn man in der apt.conf ein Default-Release definiert hat, würfelt das die Pinning-Logilk durcheinander, weil hier dann für das dort eingestellte Release ein fester Wert von 990 genommen wird, egal, was man in der /etc/apt/preferences einstellt.

Da muss man natürlich erst einmal drauf kommen, weil das so in der Dokumentation nicht erwähnt wird. (Oder ich es schlichtweg ständig überlesen habe.)

Interessante Zeiten. Sehr interessante Zeiten.

Datenkorruption ist ja schon schlecht. Besonders schlecht ist es, wenn man es nicht merkt, sondern erst, wenn sich z.B. im Dateisystem Fehler (Dateien mit "komischen" Größen oder Rechte-Flags, Dateien, die sich nicht löschen lassen, etc.) zeigen.

Und ganz besonders doof ist es, wenn man nicht weiss, warum das Problem plötzlich auftritt oder erst gar nicht erahnen kann, seit wann das Problem aufgetreten sein könnte.

Hrmbl.

Liebes Lazyweb,
ich habe einen einfachen Wunsch. Ich möchte unter Gnome mit metacity als Windowmanager für ein spezielles Fenster/Programm alle Key-Bindings (wie ALT+F1, etc.) abschalten, so dass diese direkt an die Applikation durchgereicht werden.

devilspie ist zwar ein netter Ansatz, aber kann das, was ich brauche (derzeit noch) nicht.

Was ist also zu tun?

Mit Grüßen,
dein Sven

Nein, das wird kein HowTo, wie man einen Server innerhalb weniger Minuten fix und fertig aufgesetzt bekommt, sondern lediglich ein Dank an Steve Kemp, der mir und meinen Kollegen durch das Schreiben der xen-tools das Erstellen von neuen Xen-Domänen unendlich einfacher gemacht hat.

Thanks Steve!

Gegeben sei ein Rechner mit Yukon2-Netzadapter (mit sky2 v1.5 unter Linux 2.6.18.2) und die Notwendigkeit, hier VLANs hinzuzufügen und auch wieder zu entfernen.

Das Hinzufügen einen VLANs (entweder via /etc/network/interfaces) oder auch manuell mittels vconfig funktioniert ohne Probleme, das zusätzliche Interface ist verfügbar und benutzbar.

Interessant wird es, wenn man ein VLAN wieder entfernen will, dann funktionieren andere VLANs auf dem gleichen Master-Interface nicht mehr.

Beispiel:

eth0 (Master, keine IP)
eth0.4 (192.168.100.4)
eth0.1023 (192.168.120.1)
eth0.1965 (192.168.140.20)

Jetzt füge ich mittels "vconfig add eth0 42" ein weiteres VLAN hinzu:

eth0 (Master, keine IP)
eth0.4 (192.168.100.4)
eth0.1023 (192.168.120.1)
eth0.1965 (192.168.140.20)
eth0.42

Soweit keine Probleme. Wenn ich jetzt aber mittels "vconfig rem eth0.42" dieses Interfaces entferne, so sind alle anderen VLAN-Interfaces an eth0 auch tot, nur das ungetaggte eth0 funktioniert noch.

Wobei sich "tot" nur darin äußert, dass keine Pakete mehr rein oder raus laufen, die Interfaces bleiben UP und sind vorhanden.

Auch der aktuelle 2.6.19-rc5 mit sky2 v1.10 zeigt das gleiche Verhalten, andere Treiber, z.B der skge oder auch e100/e1000 etc. sind nicht betroffen.

Der für mich interessante Teil besteht jetzt darin, den Leuten auf der netdev-Liste dieses Phänomen zu erklären, damit das Problem jemand finden und fixen kann.

Heute bin ich endlich dazu gekommen, ein sehr merkwürdiges Problem mit mysql-server-5.0 von backports.org auf einem Debian Sarge AMD64-System zu untersuchen.

So startete der mysqld ab und zu beim Booten nicht, sondern das Init-Scripte gab nur aus, in /var/lib/mysql wäre zu wenig Platz, was aber kompletter Unsinn ist, denn diese Ausgabe erfolgt nur, wenn weniger als 4MB frei sind, während auf dem fraglichen System über 300GB verfügbar waren.

Der Fehlschlag beim Start trat aber nicht immer auf, in nicht vorhersehbaren Intervallen war der Start möglich oder er schlug fehl.

Nach näherer Betrachtung stellte sich dann das folgende Verhalten von df heraus:

root@xen-16:~# while sleep 1; do BLOCK_SIZE= df --portability /; done
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8MiB 175KiB 1.5MiB 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159K 178307K 1553259K 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8 178 1.6 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159M 178307M 1553259M 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8M 178k 1.5M 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159 178307 1553259 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.9MB 179kB 1.6MB 11% /

Man beachte hierbei die sich verändernde Darstellung bei aber immer gleichem Aufruf von df.

Dieses Verhalten, das nur auf AMD64 und auch nur dann auftritt, wenn BLOCK_SIZE= gesetzt (eigentlich gelöscht) wird, hat größeres Stirnrunzeln verursacht.

Die Versionen der coreutils in Debian Etch und Sid zeigen diese Verhalten nicht (mehr).

Diesre Eintrag berichtete von meinen Erfahrungen bei der Migration eines größeren Webservers mit Benutzer-Homepages von einer alten Sun E150 auf eine neue Dual-DualCore Opteron-Maschine.

Leider stürzte Firefox ab, bevor ich den Eintrag fertigstellen konnte. Daher gibt es jetzt nur die kurze Fassung.

Das es nicht einfach ist, einen Webserver zu bauen, der mit potentiell "feindlichen" Scripten und Programmen beladen werden wird (lies: Webserver für Studenten und Mitarbeiter), war mir ja schon von Anfang an bewusst.

Aber die Arbeit, die ich bisher investieren musste, zeigt mir doch, wie unausgegohren dieses Feld immer noch ist. Auch die verfügbare Doku ist eher dünn gesäht und auf objektive Vergleiche, was wann wo wozu warum womit wogegen nutzbar ist, findet man nur selten.

Ich bin daher Marc für seine Dokumentation mehr als dankbar, weil er mir zumindest die Arbeit abgenommen hat, die verbreitesten Lösungen zu suchen, zu sammeln und zu bewerten.

Marc berichtete ja schon von seinen Versuchen, allerdings ist seine Problemstellung etwas anders als meine, so dass ich glücklicherweise zu einem anderen Ergebnis kommen konnte.

Mir reicht daher suExec für alle normalen CGI-Scripte (Shell, Perl, Ruby, Python, ELF, ...) und suPHP für den Rest, da ich die User nur über mod_userdir verwalten muss und keine einzelnen Kunden oder virtuellen Domänen voneinander trennen muss.

Glücklicherweise, denn ein eigenes PHP für jeden User (über 1500) oder andere manuelle Verrenkungen wären nicht lustig gewesen. Das System soll so einfach wie möglich bleiben, damit auch ein uneingeweihterer Admin damit klar kommt, ohne auf Dinge wie veränderte Init-Scripte, erweiterte Apache-Komponenten oder manuell gepatchte Wrapper "hereinzufallen" (was zwangsläufig passiert, egal wie gut die intenre Dokumentation dazu ist).

Bitte, bitte, $DEITY, lass den Schmerz vergehen.

Warum werde ich gleichzeitig mit

1. einem uralten und halbkaputten Solaris 2.6
2. 35GB zu tranferierneden Daten auf einer Sun Enterprise 150
3. Cisco IOS 12.3(T)
4. Kernel 2.6.17
5. und den daraus resultierenden bekannten "Interessantheiten" im Bezug auf Window Scaling

geschlagen?

Es macht wirklich keine Freude, wenn man mit 50KB/s diese Datenmengen transferieren muss und einem dabei immer wieder der Transfer-Prozess auf der Datenquelle "abhanden" kommt.

Für alle ungeduldigen Liferea und Debian-Sid-User habe ich neue Pakete der aktuellen Version 1.0.14 gebaut, die mit dem neuen XulRunner-Support ausgestattet sind. Dies ermöglicht endlich vernünftig gerenderte Ansichten in Liferea direkt, ohne das ein externer Browser gestartet werden muss.

Die Pakete findet man im Download-Bereich. (Sorry, kein via apt-get benutzbares Verzeichnis, das kommt später evtl. einmal.)

Auf meinen Eintrag bzgl. der "genialen" Produktivität in der letzten Woche und bezogen auf die MCE-Meldungen (Maschine Check Exception, eine Methode von Athlon- und Pentium4-CPUs dem System mitzuteilen, wenn ihnen etwas nicht gefällt bzw. Fehler aufgetreten sind.) habe ich ein paar Mails bekommen, in denen mir vorgeschlagen wird, das MCE-Reporting des Linux-Kernels doch abzuschalten, dann wäre das Problem weg.

Liebe Leute, nur wenn man die Augen vor einem Problem verschließt, verschwindet es nicht automatisch auch.

Leider kann man diese Art der Problemlösung immer häufiger in diversen Linux-Webforen lesen, wo die dortigen User einfach immer nur immer wieder das nachplappern, was irgendwann ein Unkundiger mal von sich gegeben hat.

Probleme gehören bemerkt, diagnostiziert und dann ausgemerzt und nicht einfach ignoriert, in der Hoffnung, dass es sich von selbst gibt.

Und dies, um einmal philosophisch zu werden, gilt nicht nur für Hardware-Probleme.

("Die drei Affen", Eintrag in der Wikipedia)

Achtung: Dieser Eintrag ist noch technischer als sonst und erschließt sich nur einem kleinen Teil von Debian-kundigen Personen.

Endlich. Lange habe ich darauf gewartet und musste bisher immer selbst die von apt abhängigen Pakete (vorweg die ganze python*-apt-Familie) rekompilieren, damit sie auf die experimentelle Version passten.

Aber jetzt endlich sehen meine verzückten Augen im changelog von apt 0.6.44:

* apt pdiff support from experimental merged

Das Gepfriemel hat für mich ein Ende und damit dürfte auch die Last auf die Mirror-Server abnehmen, wenn nur noch die Unterschiede zwischen zwei Paketdatenbank-Versionen übertragen werden müssen.

Heute, am Samstag, werde ich einmal den Linuxtag in Wiesbaden besuchen, mal schauen, auf wen man so alles trifft. Sicherheitshalber stecke ich ein paar Karten mit meinem PGP-Fingerprint ein, vielleicht ergibt sich ja die Möglichkeit für ein paar Keysignings.

An Vorträgen habe ich mir vor allem den über Xen 3 von Steven Hand vorgenommen, evtl., je nachdem, wie früh ich dort ankomme, schaffe ich ja auch den X Window-Vortrag von Egbert Eich.

Oder besser gesagt: Gar kein Zufall mehr. Oder anders gesagt: keine Entropie mehr übrig.

Nachdem ich mich jetzt schon länger wunderte, warum die Mails über meinen neuen Server nur tröpfelten und warum zwischen 8 und 9 gar kein Mailverkehr mehr aufgezeichnet wurde, bin ich dem Ganzen auf die Spur bekommen: OpenVPN und vor allem Exim saugen so stark am Entropie-Pool des Linux-Kernels, dass dieser sehr oft leer ist, was zur Folge hat, das alles Cryptographische nicht mehr richtig funktioniert.

Der Kernel bezieht einen seine Entropie aus Interrupts, die nicht vorhersagbar sind, z.B. von Maus und Tastatur. Ein Server im Rack hat aber selten Maus und Tastatur angeschlossen, also fällt diese Quelle weg. Dann werden die IRQs von Festplatten- und Floppy-Kontrollern ausgewertet, aber Floppy ist auch nicht und die Entropie vom IDE-Kontroller reicht nicht aus, um den Pool entsprechend gefüllt zu halten.

Was ist also zu tun?

Es gibt mehrere Lösungen, die beste davon ist natürlich ein Hardware-RNG (Random Number Generator), wie ihn manche Chipsätze anbieten, nur leider gibt es den bei mir auch nicht.

Dann kann man das Rauschen am Mikrofon-Eingang einer Soundkarte benutzen, aber eine Soundkarte ist auch nicht vorhanden.

Als weiteres kann man einfach künstliche IDE-Interrupts erzeugen, wie es z.B. regen-entropy.sh aus dem Debian-Exim-Wiki macht, allerdings erzeugt es eine recht hohe Last auf dem Server und ist nur als Notlösung zu betrachten.

Ich habe dagegen einen anderen, allerdings nicht weniger kritisch zu betrachtenden Work-Around implementiert, in dem ich SA_SAMPLE_RANDOM dem request_irq()-Call im vom Server benutzen Netzkarten-Treiber (e100 bei mir) hinzugefügt habe.

Natürlich bin ich mir bewußt, das ich damit eine Entropie-Quelle anzapfe, die von aussen kontrolliert werden kann, so daß hierbei die Zufälligkeit der Werte aus /dev/random negativ beeinflußt werden könnte, allerdings ist ein denkbarer Angriff hieraus doch eher theoretischer Natur, so daß ich den Vorteil, den ich daraus ziehen kann, höher bewerte als das dadurch mögliche Angriffmuster.