Unix

Heute habe ich mich endlich dazu aufgerafft, meinem Datenelend ein Ende gemacht und zwei Platten zu je 3TB (mit internen 4K-Sektoren und externen LBAs mit 512 Bytes) gekauft.

Pro: Mehr Platz als, ich jemals in der für mich absehbaren näheren Zeit brauchen werde. Aber 640K Hauptspeicher waren ja auch schon immer genug für jeden.

Contra: 10 Stunden Sync-Zeit für das RAID1, dass ich daraus gebaut habe. (Ja, ich bin ein wenig Paranoid, was Festplatten angeht. Die meisten meiner Daten fallen jetzt nicht in die Kategorie "überlebenswichtig", aber ich fände es blöd, wenn ich z.B. meine CD-Sammlung wieder neu rippen müsste, weil dies dann doch einige Tage in Anspruch nehmen würde. Echte lebenswichtige Daten habe ich als Backup auf a) Band, b) verschlüsselt in der Dropbox und c) auf DVD oder CD [die ich einmal im Jahr prüfe, ob die Lesbarkeit noch gegeben ist]) Immerhin setzt Linux den Sync an der letzten Stelle fort und fängt nicht immer von vorne an.

Ein wenig abenteuerlich war auch die Partionierung. Eine normale MSDOS-Partitionstabelle reicht nicht mehr, es muss eine GPT (GUID Partition Table) sein. Und da die Platten intern Sektoren mit 4KB-Größe arbeitet, möchte man auch dafür sorgen, dass die Partitionen und damit die Dateisysteme innerhalb der Partitionen an eben diesen 4KB-Sektoren ausgerichtet (aligned) sind. Sonst wird man eine erstaunliche Verlangsamung von Schreibzugriffen bis zu Faktor 10 erleben.

In meinem Fall habe ich die korrekte Partionierung mit parted durchgeführt.

1. Richtige Platte auswählen:
   > select /dev/sdX
2. Partitionstabelle anzeigen lassen, ob man auch wirklich die richtige Platte hat:
   > print
   
3. GPT erzeugen:
   > mklabel gpt
4. BIOS Boot Partition erzeugen. Dies wird gebraucht, weil direkt in der GPT kein Platz für das core.img von GRUB ist. Das Alignment ist hier egal, da auf diese Partition eh nur während der Installation von GRUB geschrieben wird.
   > mkpart primary 34s 2047s
   > set 1 bios_grub on
   Die 33 Sektoren am Anfang werden von der GPT eingenommen und fallen daher weg. Will man von dieser Platte nicht booten, so kann man sich diese Partition theoretisch schenken. Aber da man für die korrekte Ausrichtung bei 4KB-Sektoren intern und externen 512 Byte LBAs als kleinsten nutzbaren Sektor bei 40s ist und man nie weiss, ob man nicht doch einmal GRUB auf die Platte installieren will oder muss, sollte man die BIOS Boot Partition gleich mit anlegen, später geht das nämlich nicht mehr.
   Es ist übrigens egal, wo man die BIOS Boot Partition anlegt, generell wird aber empfohlen, diese an den Anfang, mindestens aber unterhalb der magischen Grenze von 2^32-1 Sektoren (also 2TB) anzulegen.
   
5. Dateisystem-Partition im kompletten restlichen Bereich anlegen und RAID-Flag setzen. Hierbei ist es wichtig, auf die Ausrichtung zu achten. Bei einem Verhältnis von internen zu externen Sektoren von 8 (also 4096B / 512B) muss der Start-Sektor also glatt durch 8 teilbar sein. 2048 erfüllt diese Kriterium. Für SSDs muss man ebenso rechnen, allerdings gilt es hier, die Größe des Flash-Erase-Blocks zu kennen, der meist 64KB oder 128KB ist. Bei einem Verhältnis von 131072/512 gilt also 256 als magischer Teiler. Präsentiert die SSD dagegen 4K-Sektoren nach aussen, so sinkt dieser Wert auf 32. Alles in allen würde 2048 diese Kriterien auch erfüllen, ist also ein guter über-den-Daumen Wert. (Wenngleich 2048 Sektoren bei 4K-Sektoren auch schon 8MB Verschnitt sind. Bei Plattengrößen von 256GB für SSDs oder 3TB für Magnetscheiben ist dies aber mehr als verschmerzbar, denke ich.)
   > mkpart primary 2048s -1s
   > set 2 raid on
6. Und nun das ganze Procedere für die zweite Platte wiederholen.

Danach dann wie gewohnt mit mdadm -C das RAID erzeugen, Dateisystem oder LVM drauf packen, fertig.

Ein klarer Fall von "Hä?!":

Ich stelle via tc eine maximale downstream Rate von 16000kbit ein.

Und was erhalte ich?

Eine maximale Downloadrate von ca. 4500kbit. Komisch.

OK, probieren wir einmal eine fertige Lösung, z.B. den guten alten Wondershaper (http://lartc.org/wondershaper/):

wondershaper eth1 16000 1000

Und wir erhalten:

Eine maximale Downloadrate von ca. 4500kbit. Hmmm.

Nehmen wir etwas anderes, das gerade im Linux Magazin besprochene tc-Script (http://www.linux-magazin.de/static/listings/magazin/2010/12/TC/):

trafficcontrol-inetgw eth1 16000 1000

Und wir erhalten:

Eine maximale Downloadrate von ca. 4500kbit. Hmmmmm!

Vermutlich bin ich zu doof, zu blöd, mein Kernel (2.6.32.x) ist zu alt, das Karma nicht richtig justiert, oder tc nimmt mir übel, das ich es früher einmal als undokumentiertes Stück esoterischen Code tituliert habe.

Ich glaube, ich werde meine Tage mit einer ungeshapeten Verbindung verleben müssen, denn einerseits funktionieren die fertigen Lösungen irgendwie nicht richtig und andererseits übersteigt die Logik und Syntax von tc einfach meinen Horizont. Ich habe nun schon so oft versucht, mir das anzueignen, aber die Dokumentation ist einfach grottig, die vorhandenen Beispiele in der Dokumentation sind für mich nichtssagend und die Beispiele im Netz sind ebenso unter- bzw. undokumentiert oder beziehen sich auf uralte Kernel und Methoden.

Ich geb's echt auf. Da administriere ich lieber Windows auf der Kommandozeile als noch einmal tc zu verstehen zu versuchen zu wollen.

Was ist wohl besser geeignet für einen Maildir-Storage von ca. 1TiB Größe?

• XFS, mit mkfs.xfs -f -d su=64k,sw=5 -l size=32768b,version=2 /dev/mapper/vg03-maildir_lv erzeugt
• oder ein ext4

Das ganze auf einem via FC-4GBit  angeschlossenen RAID5 mit 5 Platten und 64k Stripe-Size. Der Server hat mit 12GB genug Speicher für Cache und Co.

(ReiserFS3 fällt weg, da es praktisch ungewartet ist und es diverse Berichte gibt, dass es unter Last gerne mal zusammenbricht, Reiser4 muss auch wegen der sehr unklaren Entwicklungssituation ausscheiden.)

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)