Bernds Blog

Vorweg: Man sollte das eigentlich nicht machen. MySQL 5.0 ist alt und zu Recht nicht mehr in den aktuellen Ubuntu-Repositories.

Ein Kunde setzt allerdings die Warenwirtschaft Sage GS-Office ein und da gibt es leider ein Problem. Auch wenn die WaWi mit MySQL 5.1 funktioniert, so arbeitet die Shop-Anbindung GS-Shop intern noch mit einer völlig veralteten Datenbankanbindung und verlangt unbedingt MySQL 5.0.

Praktischer Weise gibt es in den Repositories der LTS-Vorversion Hardy Heron (Immerhin von 2008!) binärkompatible Pakete. Man muss nur die APT-Zeile
deb http://security.ubuntu.com/ubuntu hardy-security main
einfügen und kann dann mysql-server-5.0 installieren.

Da die Server-Version von Ubuntu LTS 5 Jahre Support beinhaltet, wird der MySQL-5.0-Server folglich bis April 2013 mit Sicherheitsupdates versorgt. Ich bete dafür, dass bis dahin auch die letzte Software gemerkt hat, dass MySQL 5.0 veraltet ist.

Bedingt durch das neueste Ubuntu-Release vor gut einer Woche musste ich in den letzten Tagen ein paar Rechner aktualisieren. Dazu empfiehlt sich natürlich vorher ein möglichst gutes Backup.

In einem Fall musste ich einen Rechner komplett sichern, den ich nachher 1:1 wieder herstellen möchte (auf ähnlicher aber anderer Hardware). Damit das Restore nachher möglichst schnell und einfach funktioniert, entschied ich mich dazu, dass ich /dev/sda als Komplettimage sichern möchte. Leider habe ich keinen Rechner, auf dem ausreichend Platz für das komplette Image ist. Die Festplatte ist aber nur zu einem kleinen Teil wirklich belegt. Die Erwartung war also, wenn ich das Image sofort komprimiert abspeichere, dann müsste es auf jeden Fall passen, denn leerer Platz sollte gut komprimierbar sein.

Der Transfer sollte über eine netcat-Pipe laufen (ssh-tunnel wäre auch möglich, hat aber mehr overhead).

Das Problem an der Sache war, dass ich keine Informationen über den laufenden Fortschritt der Aktion sehen konnte. Auf dem Quellrechner kann man nicht sehen, wie viel von dem Device schon ausgelesen ist und auf dem Zielhost habe ich keine Ahnung, wie groß die endgültige komprimierte Datei werden würde.

Ein kurzes Überlegen brachte mich zu der Idee, dass es eigentlich eine triviale Aufgabe sei, ein Programm zu erstellen, das einfach Daten auf stdin liest, nach stdout schreibt und dabei mitzählt und die Zahl regelmäßig ausgibt.

Bevor ich selbst Hand anlegte, suchte ich kurz im Netz und fand auch recht schnell eine Lösung: pv, steht für »pipe viewer« und macht exakt genau dieses. Das Tool kann entweder einfach mitzählen oder man gibt ihm per Parameter die erwartete Gesamtgröße der Daten, dann erhält man eine wget-ähnliche Ausgabe mit Restzeit und Prozentbalken.

Das Tool gefällt mir so gut, dass ich es sogleich für diverse andere Aktionen ebenfalls einsetze.
Dies kann dann etwa so aussehen (bei einer tar-Pipe über netcat):

$ nc -l 10.0.0.2 1111 |gunzip| pv -s 40053354750| tar x

14,6GB 0:53:34 [ 5,2MB/s] [=========>                    ] 39% ETA 1:22:55

In diesem Beispiel habe ich auch gleich das gunzip vor pv gesetzt, damit ich die wirklichen Daten zähle und nicht die komprimierten. Auf dem Quellhost arbeitet hier ein einfacheres tar xz . | nc ....

Ach ja, Fußnote: Für das eingangs genannte Szenario sollte man das gute alte gzip benutzen. Da ich möglichst gut komprimierte Daten wollte (schließlich hatte ich wenig Platz), entschied ich mich für xz als Kompressionsprogramm. Das ist aber so dermaßen langsam, dass es auch auf meinem DualCore-Rechner nur etwa 1 MB pro Sekunde komprimierten konnte und damit den ganzen Vorgang auf viele Stunden ausgedehnt hat. Leeren Platz komprimieren hätte aber auch gzip hin bekommen.

Schon seit einer Weile stört mich, dass ein handelsüblicher Desktop-PC mit etwa 80 Watt Stromverbrauch und einem Geräuschpegel Marke »Kopfschmerzen« so viel Leistung erzeugt, dass man damit prinzipiell alles machen kann was man nie machen wird.

Daher habe ich versucht, mich an diversen Quellen über die neuen Minimalrechner, genannt »NetTop«, zu informieren. Nachdem das mehrfach missglückt ist und keiner Erfahrungen dazu hatte, habe ich mir jetzt einfach mal eine ASUS eeeBox B202 gekauft um damit selbst zu experimentieren.

Vor dem Kauf fällt auf, dass es dieses Gerät (wohlgemerkt unter der selben Modellbezeichnung) entweder mit einer Ausstattung von 2 GB RAM und einem Linux-Betriebssystem oder mit 1 GB RAM und Windows XP Home verkauft wird.
Eine RAM-Erweiterung ist zwar (nach diversen Berichten) nur mit Schraubendreher und sanfter Gewalt beim Öffnen des Gehäuses möglich, aber es stehen zwei Slots zur Verfügung.
Um das 1-GB-Modell also auf 2 GB zu erweitern benötigt man kostenverursachenderweise nur einen 1-GB-SO-DIMM-Riegel, der im freien Markt momentan ca. 10-15 € kostet.

Wenn man jetzt also unterstellt, dass das Linux-System keine nenneswerten Lizenzkosten verursacht und der Aufwand, en ASUS zur Anpassung von Windows betreibt in etwa gleich ist wie der, den ASUS zur Anpassung ihres Linux-Systems treibt, dann ist zu erwarten, dass das Windows-Modell um die Windows-Lizenz minus 10-15 € teurer ist. Da man natürlich nicht weiß, was eine Windows-XP-Lizenz für einen Großabnehmer kostet, muss ich das empirisch herausfinden.

Da sich das Angebot bzgl. der Verfügbarkeit und der Preise momentan mehrmals täglich ändert, ist der Preisspiegel meiner Bestellung jetzt nicht mehr so extrem nachzuvollziehen:
Letzte Woche wurde die Linux-Variante mit 2 GB RAM um etwa 20 € teurer verkauft als die Windows-Variante.
Das macht einen Windows-Lizenzpreis von -5-10 € pro verkauftem Gerät.

Da bei mir noch nicht absehbar war, wo genau das Gerät später eingesetzt wird und ob dafür die Windows-Lizenz eine Relevanz hat, habe ich mich für diese entschieden, da es mich insgesamt einfach billiger kommt, selbst wenn ich das RAM-Upgrade noch machen möchte.

Schließlich ist es also so, dass sich keiner wundern braucht, dass sich die Windows-Version so viel besser verkauft, da die Linux-Version wirtschaftlich einfach keinen Sinn macht. Und auf einem Desktop-Rechner den man für die tägliche Arbeit einsetzen möchte, würde ich auch ungern das on ASUS vorgekaute Minimalsystem einsetzen sondern lieber ein aktuelleres, Community-gepflegtes System.

Heute habe ich einen weiteren Linux-PC an eine Kundin ausgeliefert. Hier wurde ich letzte Woche gerufen, da der PC beim hochfahren immer Scandisk angeworfen hatte und das sich in einer Endlosschleife festgefressen hatte.

Ergebnis einer schnellen Diagnose mit der System-Rescue-CD: Auch hier war die Festplatte schlicht und einfach kaputt. Die Geräuschkulisse war zwar nicht besonders beängstigend, aber deutet auch in diese Richtung.

Da nach Austausch der Festplatte sowieso eine Neuinstallation ins Haus stand, habe ich auch hier die obligatorische Frage gestellt: "Für was brauchst du denn den Computer alles?" Da sich auch da schnell abzeichnete, dass die offensichtlichen Vorteile eines Linux-Systems (Kinder machen nicht versehentlich das System kaputt, keine ernsthaften Viren-Probleme) durch kein haltbares Argument zu entkräften waren, konnte ich auch hier deutlich machen, dass die Kundin mit einem Linux-System besser beraten ist.

Vor einigen Tagen wurde ich zu einem Kunden gerufen, der Probleme mit seinem "Server" hatte. In anführungszeichen deshalb, weil es sich um einen Arbeitsplatz-Rechner handelte, der in der Ecke stand und ein paar Freigaben im Netz publiziert hat.

Die Probleme des Servers waren schnell erkennbar, die ersten Sektoren der Festplatte waren komplett hinüber. Da sowieso eine neue Festplatte und damit eine Neuinstallation nötig war, habe ich gleich vorgeschlagen, das bisher eingesetzte Windows durch einen einfachen Linux-Server zu ersetzen. Windows-Dateifreigaben sind damit auch kein Problem und die Backups auf den im "Server" verbauten DVD-Brenner zu sichern dürfte mit K3B keine Probleme bereiten.

Ich entschied mich für Ubuntu 6.06 LTS. Das ist zwar schon etwas älter, wird aber noch eine Weile supported. Ich denke mal, in einigen Tagen kann ich dann gleich auf die neue 8.04 LTS aktualisieren. ich warte noch, weil ich denke dass es bestimmt noch Migrations-Probleme geben kann.

Dort arbeitet jetzt also seit etwa einer Woche ein Ubuntu-Server mit Samba und KDE/K3B zum Brennen von DVDs. Die Festplatte wurde durch einen Software-RAID-1-Verbund ersetzt, damit ein Platten-Ausfall erstens schneller bemerkt werden kann und zweitens vielleicht reparabel bleibt.

Der Kunde hat jetzt noch ein wenig Spaß, die knapp 40.000 Dateien, die von der Datenrettungs-Software des PC-Fachhändlers knallhart durchnummeriert zurück kamen inhaltlich zu bewerten und zu sortieren.

Mit dem Linux-PC ist der Kunde allerdings zufrieden, auch wenn es in seinem Tagesablauf keinen nennenswerten Unterschied zu vorher gibt.

Hier mal kurz eine Erfahrung von heute, auf dass dies vielleicht andere finden, die sich in der selben Situation wiederfinden.

Gestern Abend teilten mir meine Eltern mit, dass ihr Rechner keinen Login mehr macht. Egal welcher Benutzer sich anmeldet, es bleibt immer sofort nach Verschwinden der Login-Maske alles stehen.

Nach einigem Debugging habe ich erstmal aufgegeben (es war spät) und heute früh weiter gemacht. Im Netz habe ich auch nicht wirklich was gefunden was passend war.

Der Lösung näher kam ich als ich ein simples xterm (mittels xinit bzw. .xinitrc) gestartet habe und dort dann "strace kwin" aufgerufen habe. Damit zeigte sich, dass der Prozess beim Locking auf die ~/.qt/.qtrc.lock stehen blieb. Da das NFS-Homedir schon manchmal beim Locking Probleme hatte, habe ich also getippt, es kann daran liegen. Laut rpcinfo -p war aber der nfslockd aktiv.

Über einiges trial und error und den entscheidenden Fund im Netz, dass das Locking Probleme macht, wenn der Server die IP-Adresse des Clients nicht auflösen kann, bin ich dann darauf gestoßen, dass der bind auf dem Server aus mir unerklärlichen Gründen sich nicht für die lokale reverse-Zone zuständig gefühlt hat. Ein einfaches Restart des bind hat genau das behoben, ab dann waren auch lokale reverse-lookups wieder möglich.

Der NFS-Server hat die Situation aber nicht verkraftet, einen restart-Versuch hat er immer mit einem Segmentation fault verweigert. Als ich dann aber den Server-Rechner neu gestartet habe, hat wieder alles wunderbar funktioniert. ohne das ich irgend etwas ändern musste.

Eigentlich ein alter Hut, aber heute gebraucht und nicht sofort ne passende Doku gefunden: Wie richte ich mein Hotplug/Udev/HAL so ein, dass ein bestimmtes Gerät immer am selben Mountpoint gemountet wird.

In meinem Fall eine externe Festplatte.

Vorbereitung: Erstmal sollte man wissen, wie man das Gerät identifizieren kann. Mit lsusb -v sollte sowas in der Art heraus kommen:

Bus 004 Device 011: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               2.00

  bDeviceClass            0 (Defined at Interface level)

  bDeviceSubClass         0

  bDeviceProtocol         0

  bMaxPacketSize0        64

  idVendor           0x04b4 Cypress Semiconductor Corp.

  idProduct          0x6830 USB-2.0 IDE Adapter

  bcdDevice            0.01

  iManufacturer          56 Cypress Semiconductor

  iProduct               78 USB2.0 Storage Device

  iSerial               100 DEF107679C83

[...]

Besonders gut ist die "iSerial" geeignet, die Kombination aus idVendor und idProduct ist aber meist auch ausreichend (es sei denn man besitzt zwei baugleiche Geräte).

Beim Einstecken der Platte kommt udev zum Zug und erwartet eine Regel was er mit dem Gerät machen soll. Also habe ich eine neue Datei /etc/udev/rules.d/00_local.rules erstellt, die folgenden Inhalt hat:

BUS=="usb", KERNEL=="sd?1", SYSFS{serial}=="DEF107679C83", NAME="wechselplatte"

Bedenke: Ich möchte nur die Partition (sda1) ändern, die Platte selbst ist mir egal. Die Partition mit den Daten wird damit /dev/wechselplatte genannt.

Der nächste Schritt ist, HAL zu sagen, dass diese Partition bitte auch immer nach /media/wechselplatte gemountet werden soll. Dazu ändere ich die Datei /etc/hal/fdi/policy/preferences.fdi und füge kurz vor Ende diesen Block ein:

  <device>

    <match key="block.device" string="/dev/wechselplatte">

       <merge key="volume.policy.should_mount" type="bool">true</merge>

       <merge key="volume.policy.desired_mount_point" type="string">wechselplatte</merge>

    </match>

  </device>

Das war's, ab dann mountet z.B. KDE diese Platte automatisch nach /media/wechselplatte. Und ich kann digikam so einrichten, dass die Bilder dort gespeichert werden.

Vor einiger Zeit hat Dell mal bei ein paar Kunden angefragt, wie sie ihre mitgelieferte Software weiter ausbauen sollen. Dell war ziemlich überrascht, dass da jetzt plötzlich ein signifikanter Teil der Leute Linux drauf haben wollte.

Jetzt hat Dell eine neue Umfrage für alle geöffnet, in der man genauer festlegen kann, wie so ein mitgeliefertes Linux-System aussehen soll.
Ich möchte hiermit alle, die das auch unterstützen wollen, dazu ermuntern, die Umfrage auszufüllen. Ich habe übrigens beim Thema "support" unter "other" eingetragen, dass ich gerne hätte, dass alle Hardware unterstützt wird. Ich glaube, dass das wichtiger ist als Telefon- oder E-Mail-Support.

Umfrage: www.dell.com/linuxsurvey

Die Seite war gestern Abend nicht mehr erreichbar weil der Server unter der Last zusammengebrochen ist. Es gibt also offensichtlich Interesse an vorinstalliertem Linux. :)

Das sagt Dell dazu:

[...]
Thanks in advance for your participation. More details soon.

Update: We're overwhelmed by your responses, and we know the survey server is overloaded too. We're working on it, and the survey will remain open until March 23, so you'll have plenty of time to make your vote count.

Letzte Woche ist mir im Server meiner Eltern (Fax- und Dateiserver sowie Router und noch ein bisschen Kleinkram) die Festplatte gestorben und hat alle Daten darauf in die ewigen Festplatten-Jagdgründe genommen (Ja, ein nicht topaktuelles Backup war vorhanden).

Da ich also dann sehr schnell ein neues System gebraucht. Vorher war Gentoo installiert, aber da habe ich mich schon seit geraumer Zeit daran gestört, denn die Upgrades waren immer so heikel, da ich keinen physikalischen Zugriff darauf habe. Also wurde als Feldversuch der Server mit der Serverversion von Ubuntu-Linux eingerichtet. Installation war Ubuntu-Typisch in wenigen Minuten vorbei.

Die kranke Installationsprozedur von DJBdns war mir bekannt und hat mich folglich auch nicht so sehr schockiert. :)

Größtes Problem war, dass beim Aufstellen am späteren Einsatzort das NFS sich ganz komisch verhalten hat. Mozilla-Firefox und -Thunderbird ließen sich nicht starten weil sie angeblich schon laufen (nein, an den Lock-Files lag es nicht), KMail brachte wahllos Zugriffsfehler beim IMAP-Cache und ein sofort eingerichtetes Backup per rsync auf einen anderen Rechner führte oft zu der Meldung »stale NFS handles« und danach gab es nurnoch »permission denied« in dem Verzeichnis. Ein heraus und wieder hineinwechseln behebt das Problem kurzfristig.

Nach etwa einem Tag erfolgloser Suche und vielen Fragen an viele andere ratlose Leute, bin ich zufällig an diesen Bugreport herangestolpert.

Der dort vorgeschlagene Workaround hat bei mir funktioniert: Die Option »no_subtree_check« in alle exports-Einträge aufnehmen.
Bisher traten bei mir keine derartigen Probleme mehr auf.