node-0 » Techtip

Ubuntu: Ruby und MySQL

Martin Eisenhardt — Wed, 09 Jan 2008 23:22:32 +0000

Möchte man das RubyGem mysql unter Ubuntu oder Kubuntu installieren, ist es zunächst notwendig, die Dev-Sourcen des MySQL-Clients zu installieren, sonst kommt es zu folgender Fehlermeldung:

$ sudo gem install mysql
Building native extensions.  This could take a while...
ERROR:  Error installing mysql:
        ERROR: Failed to build gem native extension.
 
/usr/bin/ruby1.8 extconf.rb install mysql
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file
for more details. You may need configuration options.
[...]

Die Fehlermeldung weist darauf hin, dass die Client-Sourcen von MySQL finden; bei der Erstellung der nativen Anteile der Ruby-MySQL-Bindings wird versucht, gegen die Bibliothek mit den entsprechenden Routinen zu binden (-lmysqlclient).

Die notwendige Entwickler-Bibliothek des MySQL-Clients kann folgendermaßen installiert werden:

$ sudo apt-get install libmysqlclient15-dev

Danach kann dann das mysql-Gem installiert werden:

$ sudo gem install mysql

Fertig.

RMagick unter Ubuntu/Kubuntu installieren

Martin Eisenhardt — Mon, 03 Dec 2007 12:25:11 +0000

Wer gerne automatisiert Bilder bearbeitet und Ruby mag, für den ist RMagick genau das Richtige. Allerdings ist die Installation unter Ubuntu nicht ganz ohne.

Denn wie immer, wenn der Paket-Manager (in diesem Falle also apt) die Pakete nicht im Repository finden kann, steht man ein bisschen im Regen. Natürlich lässt sich RMagick (wie bei Ruby-Paketen üblich) auch über die gem-Repositories installieren. Probiert man das dann, passiert aber folgendes:

$ sudo gem install rmagick
Building native extensions.  This could take a while...
ERROR:  While executing gem ...
  (Gem::Installer::ExtensionBuildError)
    ERROR: Failed to build gem native extension.
 
ruby gem_extconf.rb install rmagick
 
sh configure
 
Configuring RMagick 1.15.11
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C...
  (cached) -std=gnu99
checking for ruby... /usr/bin/ruby
checking for Magick-config... no
checking for GraphicsMagick-config... no
configure: error: Can't install RMagick.
  Can't find Magick-config or GraphicsMagick-config program.
RMagick configuration failed with status 1.
 
 
Gem files will remain installed in
  /var/lib/gems/1.8/gems/rmagick-1.15.11 for inspection.
Results logged to
  /var/lib/gems/1.8/gems/rmagick-1.15.11/gem_make.out

Wie so oft besteht die Lösung darin, zunächst ein paar andere Pakete zu installieren. In unserem Fall sind das zunächst einmal die build-essentials:

$ sudo apt-get install build-essential

Damit sind wir aber noch nicht fertig. Was fehlt noch? Ein Blick in Google und Co. bringt folgende Lösung:

$ sudo apt-get install libmagick9-dev ruby1.8-dev

Danach sollte ein neuerlicher Aufruf

$ sudo gem install rmagick

zum gewünschten Ergebnis führen.

Techtip: Umlaute und xfig

Martin Eisenhardt — Wed, 07 Nov 2007 12:09:23 +0000

Wer – wie ich – häufiger mal mit xfig arbeitet und mit diesem Zeichenprogramm eigentlich sehr zufrieden ist, wird dennoch immer wieder an der Tatsache verzweifeln, dass xfig es einem scheinbar absichtlich sehr schwer macht, Umlaute und andere diakritische Zeichen einzugeben.

Da ich immer wieder vergesse, wie genau das geht, dokumentiere ich das mal. Ich denke, dass auch andere Benutzer von xfig ähnliche Probleme haben.

Zunächst einmal entnehmen wir der entsprechenden Stelle der xfig-Dokumentation, dass man Latin-1-Zeichen mit dem Meta- oder Alt-Key zusammensetzen kann.

Allerdings ist es enorm wichtig, die Beschreibung dort exakt zu lesen. Um z.B. ein ä einzugeben, empfiehlt die Dokumentation:

For example to enter `a umlaut’, press and release the COMPOSE key (or META or ALT key), enter the character `a’, and then the character `”’ (double quote).

Es ist entscheidend, die Alt-Taste tatsächlich loszulassen, bevor man das a eingibt – ansonsten passiert entweder nichts oder man hat irgendeinen Shortcut ausgelöst.

Ein Traum von mir ist, dass die Maintainer von xfig irgendwann einmal auch die Eingabe von Umlauten und anderen Zeichen ohne diese Verrenkungen ermöglichen. xfig ist toll, aber die Eingabe von Sonderzeichen ist eine Zumutung.

Kubuntu Upgrade von Edgy Eft nach Feisty Fawn – Visual Guide

Martin Eisenhardt — Wed, 02 May 2007 10:21:08 +0000

Am 19. April 2007 ist die neuste Version 7.04 »Feisty Fawn« der Betriebssysteme aus der Ubuntu-Familie (also Ubuntu, Kubuntu und Xubuntu) erschienen. Dieser Blogpost soll als »Visual Guide« für das Upgrade von Kubuntu 6.10 »Edgy Eft« nach Kubuntu 7.04 »Feisty Fawn« dienen und den Upgrade-Prozess auch für den Normal-User (gibt es den auf Linux-Systemen überhaupt schon?) so einfach wie möglich machen.

Vorbedingungen

Absolute Vorbedingung für ein Upgrade nach »Feisty Fawn« ist ein laufendes System mit Kubuntu »Edgy Eft«.

Wer noch Kubuntu 6.06 »Dapper Drake« verwendet, muss zunächst auf »Edgy Eft« upgraden – ein direktes Upgrade ist leider nicht möglich. Das Upgrade von »Dapper Drake« nach »Edgy Eft« ist hier beschrieben.

Darüber hinaus ist eine funktionierende Verbindung zum Internet notwendig, um die aktualisierten Pakete aus den Repositories laden zu können.

Das Upgrade

Sind die gerade beschriebenen Vorbedingungen erfüllt, kann mit dem Upgrade von Edgy Eft nach Feisty Fawn begonnen werden.

Adept Package Manager starten

Für das Upgrade von Edgy Eft nach Feisty Fawn kann erstmals ein graphisches Upgrade-Tool genutzt werden; dies ist auch die empfohlene Vorgehensweise. Alternativ kann ein Upgrade natürlich auch weiterhin über die Kommandozeile mit apt vorgenommen werden.

Auf einem Desktop-System ist aber sicherlich das graphische Tool vorzuziehen: Daher wird zunächst der Adept Package Manager gestartet.

Dies kann wahlweise über das in Kubuntu vorkonfigurierte Katapult (Alt+Shift) oder über das K-Menü -> System -> Adept Manager geschehen.

edgy-updates freischalten

Im Adept Manager wird im Menü Adept der Punkt Manage Repositories ausgewählt.

In der Liste der Repositories müssen nun diejenigen Repositories aktiviert werden, bei denen als Distribution (dritte Spalte) edgy-updates angegeben ist. Das Aktivieren des jeweiligen Repositorys ist ganz einfach: Rechts-Klick auf die Zeile für dieses Reporitory und dann enable auswählen.

Fetch Updates

Nachdem wir Adept nun mitgeteilt haben, dass wir auch die edgy-updates haben wollen (siehe letzter Punkt), klicken wir auf Fetch Updates, um aus den einzelnen Repositories die neuesten Paketbeschreibungen zu holen.

Full Upgrade

Vor dem eigentlich Upgrade nach Feisty Fawn müssen wir zunächst noch Edgy Eft auf den aktuellsten Stand bringen. Dazu wählen wir Full Upgrade aus und klicken dann auf Apply.

Das nun folgende Update des Systems kann etwas dauern – zunächst wird nämlich Edgy Eft auf den aktuellen Stand gebracht. Ist dies geschehen, ...

Das Upgrade-Tool: Anweisungen folgen

... startet dann das neue graphische Update-Tool, das nach Rückfrage, ob man denn auf Feisty Fawn upgraden möchte, einige Veränderungen am System vornimmt.

Dann kann es mit dem eigentlichen Upgrade losgehen.

Das eigentliche Upgrade

... verlangt vom Nutzer eigentlich nur eines: Geduld, und das – je nach Bandbreite der Internetverbindung durchaus in größeren Maßen. Je nach Anzahl und Art der installierten Pakete sind es ca. 750 MB und mehr, die für das Upgrade downgeloadet werden müssen.

Nach ein paar letzten Vorbereitungen fragt der Upgrade noch einmal nach, ob man das Upgrade nun wirklich durchführen möchte. Last exit, sozusagen. Da wir mit dem Upgrade natürlich fortfahren wollen, klicken wir auf Start Upgrade, und gehen Kaffee kochen, Zeitung lesen oder tun etwas anderes zeitaufwändiges, denn: Selbst mit DSL2000 dauert es nun ca. eine Stunde, bis alle Pakete da sind.

Handarbeit

Das Upgrade läuft dann vollautomatisch durch, bis auf zwei Ausnahmen:

Zum einen fragt das Upgrade-Tool nach, bevor es vom Benutzer geänderte Konfigurationsfiles mit einer neuen Version überschreibt. Da kann es u.U. sinnvoll sein, die alte Konfigurationsdatei zu sichern und dann erst einmal die neue Version zu nehmen, um sie dann nach dem Upgrade wieder anzupassen. Einfach die alte Version zu behalten kann sich als fatal herausstellen, etwa dann, wenn die neue Version des entsprechenden Pakets das alte Format nicht mehr lesen kann oder bspw. neue Funktionen anbietet, deren Default-Einstellungen nicht dem gewünschten Verhalten entspricht.

Zum anderen informiert das Tool über diejenigen Pakete, für die der Support eingestellt wurde und zusätzlich über diejenigen Pakete, die im Zuge des Upgrades deinstalliert werden. Beides ist tatsächlich eher als Information zu sehen, großartig geändert werden kann das Verhalten des Upgrade-Tools nicht. Das wäre auch wenig sinnvoll, da unsupportete Pakete und solche, die für den Betrieb des Systems nicht mehr notwendig sind, ohnehin nur ungenutzt auf der Platte herumliegen würden und zudem eventuell mit neuen Versionen anderer Pakete konfligieren können.

Das Ende naht

Bekanntlich hat alles mal ein Ende, und so verhält sich das auch mit dem Upgrade auf Feisty Fawn.

Zu guter Letzt bleibt uns nur noch eins zu tun, nämlich das System neu zu starten.

Reboot

Nach dem Reboot sollte uns Kubuntu 7.04 »Feisty Fawn« in seiner ganzen Pracht begrüßen.

Am Bootvorgang hat sich graphisch nur wenig geändert:

Der Loginscreen ist ebenfalls recht ähnlich geblieben:

Gleiches gilt auch für den Desktop:

Fazit

Das Upgrade von Kubuntu 6.10 »Edgy Eft« auf Kubuntu 7.04 »Feisty Fawn« ist dank des graphischen Upgrade-Tools kinderleicht und DAU-sicher. Der Anwender profitiert nach dem Upgrade in erster Linie von neuen Versionen wichtiger Anwendungen – z.B. OpenOffice 2.2, Apache 2.2, Java SDK 1.6, Subversion 1.4.3, ... und viele andere mehr.

Insbesondere die Unterstützung von WLANs hat sich ebenfalls entscheidend verbessert. Wer also ohnehin die neuen Software-Versionen nutzen möchte, ist mit einem Upgrade auf Feisty Fawn gut beraten.

Zu diesem Thema in der Blogosphäre:

Planet Geek: Ubuntu Feisty Fawn Upgrade from Edgy Eft
Netscape Tech: Ubuntu »Feisty Fawn« upgrade was a breeze
Nixcraft: Howto upgrade from Ubuntu 6.10 to Ubuntu feisty fawn 7.04 Linux

Daniel Schneller: Upgrade to Feisty Fawn

Erzeugen einer Liste installierter Pakete auf einem (K)Ubuntu-System

Martin Eisenhardt — Mon, 16 Apr 2007 22:44:53 +0000

Wer sich schon einmal gefragt hat, wie er eine Liste aller auf seinem Ubuntu- bzw. Kubuntu-System installierten Pakete erhalten kann, sollte sich mal das folgende kleine Kommando angucken:

$ sudo dpkg -l | grep ^ii | awk '{print $2}' > paket-liste

Es wird eine Liste installierter Pakete in die Datei paket-liste geschrieben. Diese Liste kann man sich dann als Bettlektüre zu Gemüte führen (weniger empfehlenswert ) oder aber – und das ist das interessante – man kann diese Datei auf einen anderen Rechner übertragen und dann folgendes machen:

$ for paket in $(cat paket-liste); do
  echo $paket;
  sudo apt-get install $paket;
done

Damit wird auf dem Zielsystem exakt die gleiche Paketauswahl installiert, die auf dem Ursprungssystem installiert war. Ich habe an dieser Stelle darauf verzichtet, Pakete auf dem Zielsystem zu entfernen, die auf dem Ursprungssystem nicht installiert waren – eventuell werden die auf dem Zielsystem aus anderen Gründen benötigt.

Sollte diese Funktionalität aber benötigt werden, dürfte ein einfaches diff zwischen den Paketlisten beider Systeme zeigen, welche zusätzlichen Pakete auf dem Zielsystem installiert sind – und diese können dann entfernt werden.

GPG-Keys automatisch in apt importieren

Martin Eisenhardt — Mon, 16 Apr 2007 14:01:57 +0000

Wer mit Ubuntu/Kubuntu/Xubuntu/... arbeitet, kommt um die Benutzung des manchmal etwas widerspenstigen apt in all seinen Varianten (apt-get, apt-cache, ...) nicht herum – es sei denn, man entscheidet sich für das oftmals nicht weniger kryptische aptitude.

Ein nettes Feature von apt (und inzwischen eigentlich aller anderen package manager wie yast, portage, ...) ist, dass Pakete vor der Installation gegen einen oder mehrere kryptographische Hashes (meist MD5 und SHA1) getestet werden. Damit kann festgestellt werden, ob das Paket (möglicherweise mit finsteren Absichten) verändert wurde.

Zusätzlich baut apt auf die Signatur von Paketen durch die package maintainer: Auch diese Signatur ist natürlich kryptographisch gesichert und stellt sicher, dass das von apt downgeloadete Paket in dem Zustand vorliegt, in dem der Maintainer es released hat.

Und jetzt kommt der Knackpunkt bzw. die kleine Unbequemlichkeit: Damit eine solche Signatur überhaupt einen Wert hat, muss sie auch überprüft werden – und dazu benötigt man den public key des Signierenden, also im Falle von apt den public key des package maintainers, sonst gibt apt folgendes aus:

$ sudo apt-get update
Get:1 http://archive.canonical.com edgy-commercial Release.gpg
[191B]
Get:2 http://archive.czessi.net edgy Release.gpg [481B]
Hit http://archive.canonical.com edgy-commercial Release
Get:3 http://ubuntu.beryl-project.org edgy Release.gpg [191B]
Get:4 http://security.ubuntu.com edgy-security Release.gpg
[191B]
Get:5 http://mirror2.ubuntulinux.nl edgy-seveas Release.gpg
[307B]
[...]
W: GPG error: http://kubuntu.org edgy Release: The following
signatures couldn't be verified because the public key
is not available: NO_PUBKEY A506E6D4DD4D5088
W: GPG error: http://wine.budgetdedicated.com edgy
Release: The following signatures couldn't be verified
because the public key is not available: NO_PUBKEY
58403026387EE263
W: You may want to run apt-get update to correct these problems

Um diese lästige Meldung loszuwerden und gleichzeitig in den Genuss überprüfter Packages zu kommen, bietet sich das folgende kleine Skript an, dass die noch nicht importierten Keys (halb-)automatisch von einem Key-Server besorgt, in den lokalen GPG-Keyring und mittels apt-key auch nach apt importiert:

for KEY in "A506E6D4DD4D5088" "58403026387EE263";
do
  gpg --keyserver hkp://subkeys.pgp.net --recv-keys $KEY;
  gpg --export --armor $KEY | sudo apt-key add -;
done

Bei diesem Skript müssen am Beginn der for-Schleife die IDs der noch fehlenden Keys eingetragen werden. Nach dem Start fragt das Skript einmal nach dem User-Passwort, um das sudo in der dritten Zeile ausführen zu können; die folgenden Aufrufe sollten sich in der Standard-Konfiguration von Ubuntu, Kubuntu, Xubuntu, ... nicht noch einmal nach dem Passwort erkundigen, da ein erfolgreicher sudo-Aufruf für einige Zeit gecachet wird.

Wenn dieses Skript erfolgreich durchgelaufen ist, sollte es keine Probleme mit noch fehlenden Keys mehr geben – jedenfalls so lange nicht, bis man ein weiteres Repository zu seiner /etc/apt/sources.list hinzufügt.

Hausaufgabe für besonders Fleißige:

Wer schreibt mir ein schönes Skript für sed, awk oder grep, dass aus der Ausgabe von apt-get die IDs der noch fehlenden public keys extrahiert und diese dann automatisch in das obige Skript eingibt?

Danke schon einmal …

Techtip: Persistenz mit Hibernate

Martin Eisenhardt — Wed, 04 Apr 2007 11:48:01 +0000

Wer immer schon einmal wissen wollte, wie er seine (Java-) Applikation zwar mit Db-gestützter Persistenz ausstatten kann, sich dabei aber nicht auf ein RDBMS oder eine Handvoll davon festlegen muss, der sollte sich einmal die Kurzeinführung in Hibernate beim Net-Business-Blog ansehen.

Guter Stoff …

eMail-Subjects in UTF-8 mit Ruby kodieren

Martin Eisenhardt — Tue, 13 Mar 2007 11:32:06 +0000

Falls mal jemand außer mir in die Verlegenheit kommt, aus einem Ruby-Skript heraus eMails zu generieren, die im Header auch Umlaute/Sonderzeichen enthalten, dann wird dieser jemand wohl auch recht bald feststellen, dass das gar nicht so einfach ist.

Das erste Problem: Die entsprechenden RFC 822, 1652, 2821, etc. sind nämlich ein bisschen haarig zu lesen, außerdem gibt es so viele davon; nach meiner Zählung muss man sich bei der standard-konformen Implementierung von eMail-Funktionalität (sprich: SMTP) um mindestens 24 RFCs kümmern; wir sind ja nicht Microsoft und definieren unsere eigenen Standards …

Gut, worin liegt nun das eigentliche Problem? Kurz gefasst: eMail-Subjects sollen ausschließlich Zeichen des 7bit-ASCII enthalten. Für den englisch-sprachigen Raum mag das angehen, für Europa, Südamerika und Asien hingegen reicht das bei weitem nicht.

Also muss das Subjekt z.B. in einen UTF-8-Wrapper kodiert werden. Die Zeile

Subject: Vielen Dank für die Blumen!

sieht korrekt kodiert dann so aus:

Subject: =?utf-8?b?VmllbGVuIERhbmsgZsO8ciBkaWUgQmx1bWVuIQ==?=

Kann man gut lesen, oder?!

Wer das ganze als bequeme Ruby-Methode haben möchte, darf sich an folgendem Code bedienen:

def encodeSubject(subject)
    "=?utf-8?b?#{[subject].pack("m").delete("\n")}?="
end

Solchen Code sollte man typischerweise großflächig mit Warnhinweisen kommentieren, dass nur derjenige, der ihn auch wirklich versteht, zu Änderungen befugt ist …

Beryl 0.1.9999.1 ist »broken« – Abhilfe

Martin Eisenhardt — Sat, 03 Feb 2007 18:42:28 +0000

Vorgestern habe ich voller Elan das Update von Beryl 0.1.99.2 auf 0.1.9999.1 installiert und wurde mit einem nicht mehr funktionierenden 3D-Desktop »belohnt« .

Mir ist das sogar gleich auf zwei Rechnern passiert, da Beryl auch nach dem Update zunächst noch funktioniert. Erst nach einen Reboot kommt es zu Problemen. Da hatte ich aber auch schon den zweiten Rechner upgedated. Prima, das spricht wieder einmal für ein ingenieursmäßig organisiertes Vorgehen meinerseits …

Zur Zeit scheint es aus dem Beryl-Projekt selbst keinerlei Bug-Fixes für dieses Problem zu geben. Im IRC hört man auf dem Channel #beryl nur »same problem here«, auch den Entwicklern scheint der Faux-pas bekannt zu sein. Nur Abhilfe gibt es – auch heute, immerhin zwei Tage später – nicht. Das ist natürlich verständlich, schließlich arbeiten die Beryl-Entwickler in ihrer Freizeit an diesem wirklich innovativen 3D-Desktop. Für den Anwender ist es aber dennoch doof.

In meinem Fall – ich arbeite mit Kubuntu 6.10 »Edgy Eft« – gibt es eine recht einfache Lösung: Einfach die alte Version 0.1.99.2 wieder installieren. Da es mitunter ein bisschen schwierig ist, an die alten *.deb-Files zu kommen, habe ich mal ein Paket für Ubuntu, Kubuntu und Xubuntu zusammengestellt, dass alle benötigten Pakete enthält:

beryl-0.1.99.2.tar.bz2
In diesem Tarball ist ein Bash-Skript namens install.sh enthalten, das nach dem Download und Auspacken automatisch die alte Beryl-Version 0.1.99.2 installiert:
```
$ tar xfjv beryl-0.1.99.2.tar.bz2
$ cd beryl-0.1.99.2
$ sudo ./install.sh
```
Einen Restart später sollte der 3D-Desktop dann wieder zu sehen sein.

Auf die stabile Version 0.2 von Beryl bin ich schon einmal gespannt und hoffe, dass die dann auch problemlos unter {K,X}Ubuntu funktioniert …

Installation von VirtualBox unter Kubuntu

Martin Eisenhardt — Mon, 15 Jan 2007 12:20:40 +0000

Wer sich bei der Installation des heute unter der GPL freigegebenen Virtualisierungstools VirtualBox unter Kubuntu exakt an die Anleitung hält, bekommt ein Rechteproblem beim Start einer virtuellen Maschine. In diesem kurzen Tutorial möchte ich zeigen, wie man VirtualBox unter Kubuntu zum Laufen bekommt.

Bitte das Update am Ende des Artikels beachten!

Zunächst einmal besorgt man sich die aktuellste Version (1.3.2, Stand: 15.01.2007) der Virtualbox auf der Downloadseite bei Innotek. Diese wird auf der lokalen Platte (z.B. in /home/mein-account) gespeichert.

Die Installation wird mit

$ sudo dpkg -i VirtualBox_1.3.2_Ubuntu_Edgy_x86.deb

durchgeführt. Wichtig ist der am Schluss der Installationsroutine angezeigte Hinweis, dass sich der Nutzer von VirtualBox in der neu angelegten Gruppe vboxusers befinden muss. Wir fügen also den aktuellen Benutzer (und alle weiteren, die mit VirtualBox arbeiten sollen) dieser neuen Gruppe hinzu:

$ sudo usermod --append --groups vboxusers mneisen

Hinweis: mneisen bitte durch den eigenen Accountnamen ersetzen!

Dann prüfen wir, ob das VirtualBox-Kernelmodul bereits geladen wurde und laden es ggf. mit modprobe:

$ lsmod | grep vboxdrv
$ sudo modprobe vboxdrv

Hinweis: Die zweite Zeile ist nur notwendig, wenn die erste Zeile keinerlei Output erzeugte.

Als letzter Schritt vor dem Start von VirtualBox muss noch ein kleiner Fehler der Installationsroutine(?) ausgemerzt werden: Der Zugriff auf das gerade geladene Kernelmodul führt noch zu Problemen mit den Rechteeinstellungen.

Dies beheben wir mit einer beherzten Änderung der Rechtebits von /dev/vboxdrv:

$ sudo chmod 777 /dev/vboxdrv

Nun kann die VirtualBox von der Kommandozeile gestartet werden:

$ VirtualBox

Natürlich ist es ebenso möglich, sich einen entsprechenden Eintrag im K-Menu zu erstellen oder ein Icon auf den Desktop zu legen. Wie auch immer man VirtualBox startet, man bekommt (hoffentlich!) dieses Administrationspanel zu sehen:

Viel Spaß mit VirtualBox!

Update

Nach einer Diskussion auf #vbox (dem IRC-Channel der VirtualBox-Entwickler) hat sich herausgestellt, dass es sich bei dem beschriebenen Rechteproblem wohl am ehesten um ein Linux- bzw. (K)Ubuntu-Problem handelt. Zwar hatten auch andere User die beschriebenen Probleme, allerdings stellte sich heraus, dass Kubuntu das Hinzufügen eines Nutzers zu einer Gruppe weder in neu gestarteten Shells noch nach einem Neustart der KDE-Session beherzigt.

Erst ein kompletter Neustart hat die beschriebenen Probleme beseitigt.

Daher empfehle ich (K)Ubuntu-Nutzern nach der Installation der VirtualBox einen Neustart ihres Systems durchzuführen.

ZFS unter Ubuntu/Kubuntu 6.10 (»Edgy Eft«)

Martin Eisenhardt — Sun, 31 Dec 2006 16:55:08 +0000

Sun Microsystems hat der OpenSource Community ein neues Power-Tool geschenkt: Das Zettabyte Filesystem, kurz ZFS genannt. Dieses Filesystem räumt mit der gängigen Zuordnung »eine Partition – ein Dateisystem« gründlich auf und abstrahiert die Filesystem-Ebene komplett von der darunterliegenden Speicherinfrastruktur. Wer mehr zu den Grundlagen von ZFS lesen möchte, kann dies hier tun.

Zunächst war ZFS lediglich für Suns Betriebssystem Solaris verfügbar. Inzwischen laufen Portierungsprojekte auf verschiedene BSD-Derivate, MacOS und Linux. Gerade die Linux-Variante ist wohl für viele Anwender interessant. Diese wird von Ricardo Correira implementiert und baut auf FUSE auf, da die Integration der unter Suns CDDL freigegebenen Sourcen in den unter der GPL stehenden Linux-Kernel aus lizenzrechtlichen Gründen problematisch ist.

In diesem Blogpost möchte ich kurz beschreiben, wie man ZFS unter einem aktuellen Kubuntu 6.10 (»Edgy Eft«) kompiliert und zum Laufen bringt.

The shoulders of Giants

Auch andere haben sich natürlich schon dieses Themas angenommen, darunter Machine Check Exception und Chris Samuel.

Source Code besorgen

Es gibt grundsätzlich zwei Möglichkeiten, sich den Source-Code zu besorgen: per Download oder über das Mercurial-Repository von
Ricardo Correia. Letztere Möglichkeit ist insbesondere für Anwender/Entwickler, die immer auf dem letzten Stand sein wollen – birgt aber auch die Gefahr, dass der Code nicht gar so rock stable ist wie eine releaste Version.

Die letzte releaste Version 0.4.0_alpha1 (Stand: 31.12.2006) kann unter

https://developer.berlios.de/project/showfiles.php?group_id=6836

bezogen werden.

Das von dort heruntergeladene Source-Code-Archiv wird dann per

$ tar xfj zfs-fuse-0.4.0_alpha1.tar.bz2

entpackt.

Die Abenteurer unter uns können sich Mercurial installieren (falls nicht ohnehin schon vorhanden) und sich dann den Source Code direkt aus Ricardos Repository ziehen. Die erste der beiden Codezeilen checkt die letzte releaste Version aus der Serie 0.4 aus, die zweite besorgt die cutting edge Version (Hinweis: use at your own risk):

$ hg clone http://www.wizy.org/mercurial/zfs-fuse/0.4.x
$ hg clone http://www.wizy.org/mercurial/zfs-fuse/trunk

Dependencies installieren

Damit sich ZFS unter Ubuntu/Kubuntu kompilieren und installieren lässt, müssen wir uns zunächst eine Build-Umgebung schaffen und die Dependencies (die Sourcen von FUSE) installieren:

$ sudo apt-get install build-essential scons
$ sudo apt-get install libfuse-dev

MAKE

Wir wechseln nun in das Verzeichnis mit den Sourcen. Der genaue Pfad hängt davon ab, welche der oben vorgestellten Möglichkeiten zur Beschaffung des Source Codes gewählt wurde:

$ cd zfs-fuse-0.4.0_alpha1/src # nach Download
$ cd 0.4.x/src # Mercurial-Checkout aktuelle Serie
$ cd trunk/src # für Wagemutige

Der Build der Sourcen wird über ein im Source-Paket enthaltenes Skript für scons gesteuert. Für uns bedeutet das, dass wir es nun sehr einfach haben:

$ scons

Installation

Die Installation ist ebenfalls extrem einfach gehalten und wird auch über scons gesteuert:

$ sudo scons install

Fertig!

Arbeiten mit ZFS

Hier möchte ich nun keine komplette Übersicht über die Möglichkeiten von ZFS bieten – dazu gibt es (vielleicht) mal einen weiteren Artikel. Interessant wäre aber schon, ob das gerade übersetzte und installierte ZFS überhaupt funktioniert …

Damit wir mit ZFS unter Linux arbeiten können, müssen wir zunächst den ZFS-Daemon starten. Ein Skript dafür ist in den Sourcen im Verzeichnis src/zfs-fuse enthalten:

$ cd src/zfs-fuse; ./run.sh

Wir benötigen nun noch mindestens ein, möglichst aber mehrere Block-Devices, um die Möglichkeiten von ZFS zu demonstrieren. In meinem Fall habe ich unter EVMS einfach zwei neue Devices /dev/evms/zfs0 und /dev/evms/zfs1 auf verschiedenen Festplatten angelegt. Man kann aber auch Dateien als Pseudo-Blockdevices verwenden.

$ dd if=/dev/zero of=~/zfs0 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 22.3667 seconds, 48.0 MB/s
$ dd if=/dev/zero of=~/zfs1 bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 1.42299 seconds, 377 MB/s
$ dd if=/dev/zero of=~/zfs2 bs=1M count=1536
1536+0 records in
1536+0 records out
1610612736 bytes (1.6 GB) copied, 21.063 seconds, 76.5 MB/s

Dies legt null-gefüllte Dateien zfs{0|1|2} mit einer Größe von 1G, 0.5G und 1.5G im Heimatverzeichnis des aktuellen Benutzers an.

Der ZFS Pool kann dann mit

$ sudo zpool create test ~/zfs0

angelegt werden. Wir können nun mit ZFS-Tools ein paar Informationen über den soeben angelegten ZPool sammeln:

$ sudo zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
test                   1016M     88K   1016M     0%  ONLINE     -
$ sudo zpool status test
  pool: test
 state: ONLINE
 scrub: none requested
config:
 
        NAME                  STATE     READ WRITE CKSUM
        test                  ONLINE       0     0     0
          /home/mneisen/zfs0  ONLINE       0     0     0
 
errors: No known data errors

Super: Noch keine Fehler …

Zeit für das erste Dateisystem; Dateisysteme in ZFS sind hierarchisch, d.h., Dateisysteme können ihrerseits wiederum Dateisysteme enthalten. Properties (wie etwa Quotas, Kompression, Reservierung, ...) werden dabei von oben nach unten vererbt.

$ sudo zfs create test/users
$ sudo zfs list
NAME         USED  AVAIL  REFER  MOUNTPOINT
test         114K   984M  25.5K  /test
test/users  24.5K   984M  24.5K  /test/users

Dann wollen mit mal ein paar Dateisysteme für unsere beiden Benutzer Alice und Bob anlegen:

$ sudo zfs create test/users/alice
$ sudo zfs create test/users/bob
$ sudo zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
test               178K   984M  25.5K  /test
test/users        76.5K   984M  27.5K  /test/users
test/users/alice  24.5K   984M  24.5K  /test/users/alice
test/users/bob    24.5K   984M  24.5K  /test/users/bob

Alice und Bob sollen jeweils maximal 1G Speicher verbrauchen können.

$ sudo zfs set quota=1G test/users/alice
$ sudo zfs set quota=1G test/users/bob

Zusammen sollen Alice und Bob maximal 1.5G Platz in unserem ZPool belegen.

$ sudo zfs set quota=1536M test/users

Für Bob sollen allerdings mindestens 640M reserviert werden.

$ sudo zfs set reservation=640M test/users/bob
$ sudo zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
test               640M   344M  25.5K  /test
test/users         640M   344M  27.5K  /test/users
test/users/alice  24.5K   344M  24.5K  /test/users/alice
test/users/bob    24.5K   984M  24.5K  /test/users/bob

Oops, was ist denn jetzt passiert? Alice kann nur noch 344M belegen? Ja. Das sind die Auswirkungen der Reservierung von 640M Platz für Bob. Damit dieser garantiert 640M belegen kann, müssen andere Nutzer in ihrem Platzbedarf eingeschränkt werden. Das ist ein wirklich schönes Feature von ZFS, dass es so zwar auch in anderen Dateisystemen oder Add-On-Produkten gibt. Hier ist aber Kernbestandteil des Dateisystems und kann auch auf ganze Teilbäume im hierarchischen Baum der Dateisysteme in ZFS angewendet werden. Mit

$ sudo zfs set reservation=1.5G test/users
cannot set property for 'test/users': size is greater than available space

kann z.B. festgelegt werden, dass für die Benutzer mindestes 1.5G Platz zur Verfügung steht – wäre da nicht die ominöse Fehlermeldung, die uns darauf aufmerksam macht, dass für eine solche Reservierung nicht mehr genügend Speicherplatz in unserem Pool zur Verfügung steht. Da wir aber noch zwei weitere Devices (zfs1 und zfs2, unsere Pseudo-Blockdevices in normalen Files) zur Verfügung haben, können wir diese zu unserem ZPool hinzufügen und damit Platz schaffen:

$ sudo zpool add test ~/zfs1
$ sudo zpool add test ~/zfs2
$ sudo zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
test                   2.98G    194K   2.98G     0%  ONLINE     -

Nun können wir auch die Reservierung von 1.5G Platz für die Gesamtheit aller Dateisysteme unter test/users durchsetzen:

$ sudo zfs set reservation=1.5G test/users
$ sudo zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
test              1.50G  1.43G  25.5K  /test
test/users         640M   896M  27.5K  /test/users
test/users/alice  24.5K   896M  24.5K  /test/users/alice
test/users/bob    24.5K  1024M  24.5K  /test/users/bob

Voìla! Wie man sieht, hat Bob nun maximal 1G zur Verfügung. Da er 640M fest zugesichert bekommt und für die Dateisysteme unter test/users maximal 1.5G eingeplant sind, bleiben für Alice 896M übrig. Sie wird Ihre maximal zugewiesenen 1G also nicht nutzen können – außer wir verändern die Obergrenze auf test/users. In unserem ZPool test haben wir insgesamt rund 3G Platz – 1.5G davon sind inzwischen aber verbraucht, da wir den Nutzern soviel Speicherplatz fest zugesagt haben.

Damit Alice, die keine 1G Platz beanspruchen kann, aber dennoch viel in ihrem Verzeichnis unterbringt, schalten wir (nur für ihren Verzeichnisbaum) Kompression an:

 
$ zfs set compression=on test/users/alice

Dies komprimiert alle neu hinzukommenden Daten in Alice’ Verzeichnis, vollkommen transparent für den Anwender. Wir testen die Auswirkungen:

$ cd ~; wget http://www2.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.1.tar.bz2
$ tar xj ~/linux-2.6.19.1.tar.bz2
$ du -sh linux-2.6.19.1
269M    linux-2.6.19.1
$ sudo rsync -aS ~/linux-2.6.19.1 /test/users/alice
[...]
sent 230975825 bytes  received 468146 bytes  1624168.22 bytes/sec
total size is 229629549  speedup is 0.99
$ sudo zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
test              1.50G  1.43G  25.5K  /test
test/users         775M   761M  27.5K  /test/users
test/users/alice   135M   761M   135M  /test/users/alice
test/users/bob    24.5K  1024M  24.5K  /test/users/bob

Obwohl die Sourcen des Linux Kernel 2.6.19.1 etwa 269M umfassen, belegen sie in Alice’ komprimiertem Verzeichnis lediglich 135M. Wenn Alice also hauptsächlich mit gut komprimierbaren Daten arbeitet (Source Code, LaTeX-Dokumente, XML-Dateien, ...), dann wird sie aller Voraussicht nach sogar mehr als 1G Daten in ihrem Verzeichnis unterbringen können.

Fazit

Die ZFS-Portierung von Solaris nach Linux&FUSE ist zwar noch nicht ganz abgeschlossen, es wird auch auf die noch fehlende Optimierung und potentielle Bugs hingewiesen. In meinen Tests bin ich allerdings noch auf keinen solchen Fehler gestoßen, die Performance ist (wenn tatsächlich Disks und keine Dateien auf einem anderen Dateisystem) schon recht ordentlich. Für Systemadministratoren ist ZFS das Ende vieler Konfigurations-Alpträume und sollte Alternativen wie LVM und EVMS starke Konkurrenz machen.

Selbst professionelle, kommerzielle Lösungen können typischerweise auch nicht mehr als ZFS (z.B. Snapshots, Clones, ...). Wenn ich wetten müsste, welcher Volume Manager in 5 Jahren den Markt aufgerollt hat, würde ich auf ZFS tippen.

Für die kommende Zeit plane ich ein paar Performance-Messungen, über die ich dann hier berichten werde. Eventuell schreibe ich auch noch ein kleines Tutorial – mal sehen, wieviel Zeit ich haben werde …

Kubuntu: Upgrade von Dapper Drake auf Edgy Eft

Martin Eisenhardt — Sat, 25 Nov 2006 17:25:16 +0000

Hinweis: Einen Visual Guide für das Upgrade von Kubuntu 6.10 »Edgy Eft« nach Kubuntu 7.04 »Feisty Fawn« gibt es hier .

Nachdem ich schon verschiedentlich gelesen hatte (z.B. bei Ende der Vernunft), dass das Upgrade von (K)Ubuntu 6.06 LTS (Codename: »Dapper Drake«) auf die Version 6.10 (»Edgy Eft«) zwar nicht direkt schwierig ist, aber doch ihre Tücken aufweist, habe ich (in mir unbekannter Geduld) erst einmal ein bisschen abgewartet, bis ich auch diesen Schritt wage. Jetzt ist es soweit: Mein Rechner am Arbeitsplatz ist schon upgedated (mit nur wenigen Problemchen), jetzt gerade läuft das Upgrade meines Laptops. Mein PC im Arbeitszimmer folgt dann irgendwann.

Motivation

Warum upgraden, wenn alles gerade so schän läuft? Nun, wenn ich meine Rechner als reine Büromaschinen einsetzen würde, also nur für Openoffice, Kontact (eMail, Adressen, Kalendar), Web-Browsing und vielleicht ein bisschen Multimedia (MP3, Digikam, ...) – dann hätte ich mir das auch noch einmal überlegt. Solche »normalen« Anwender müssen sicherlich noch nicht updaten.

Wenn man allerdings auf den Maschinen entwickelt, dann hat man schon ganz gerne etwas frischere Software am Start. Insbesondere finde ich das Upgrade auf Mozilla Firefox 2.0 und endlich eine etwas modernere Variante von Subversion ganz hilfreich – obwohl Subversion 1.3.2 auch nicht wirklich »aktuell« genannt werden kann, da gibt es schon die Version 1.4.2 (Stand: 25.11.2006).

Die Empfehlung ist also ganz klar und sieht so aus, wie es bei Software-Updates immer ist: Wenn alles so läuft, wie man das möchte, wenn man keine weiteren Features oder neuere Programmversionen benötigt und für die aktuelle Serie auch noch Sicherheitsupdates herausgegeben werden (bei 6.06 LTS – »Long Term Support« – ist das noch einige Jahre so), dann sollte man auch nicht updaten. Sonst schon.

Ablauf des Updates

Auf den Seiten bei Kubuntu ist die Prozedur für das Upgrade eigentlich sehr gut erklärt. Zunächst sollte man in seinen apt-Sources alle Vorkommen von »dapper« durch »edgy« ersetzen:

$ cd /etc/apt
$ sudo sed -ibkp -e 's/dapper/edgy/g' sources.list

Danach holt man sich dann per

$ sudo apt-get update

die neuen Paket-Beschreibungen aus den Repositories und startet das Upgrade mittels

$ sudo apt-get dist-upgrade

Das kann jetzt ein bisschen dauern: In meinem Fall mussten ca. 1,4 GByte Pakete heruntergeladen werden, was auch bei DSL 2000 etwa 1,5 h in Anspruch nahm (macht nix, ich wollte eh zum Friseur ).

Während des Upgrade kann es verschiedentlich zu kleinen Problemchen kommen. Darunter ist aber nichts, was sich nicht mir einem beherzten

$ sudo dpkg --configure -a

beheben ließe. Im Extremfall muss man ein Paket temporär entfernen und kann es erst wieder nach dem Upgrade installieren. Ein solcher Fall war auf meinem Laptop courier-authlib und verwandte Pakete. Da ich die aber ohnehin nur zum Ausprobieren einiger Details installiert hatte, flogen die gleich ganz runter und werden vorerst auch nicht mehr installiert.

Hinweis: Die Sache mit courier-authlib ist im Übrigen ein »known bug«, für den es ein ziemlich übles Workaround gibt.

Der Trick ist besteht dabei tatsächlich darin, das Paket zu de-installieren (die Abhängigkeiten haben sich in »Edgy Eft« geändert). Die De-Installation ist allerdings mit ein bisschen Gewalt verbunden:

$ cd /var/run
$ sudo rm -rf courier
$ sudo dpkg --force-remove-reinstreq -P courier-authdaemon

Danach geht es dann weiter mit

$ sudo dpkg --configure -a
$ sudo apt-get dist-upgrade

Hässlich, aber wirkungsvoll …

Bei einigen Paketen fragt apt auch nach, wie sie konfiguriert werden sollen. Da ist dann jeder sich selbst bzw. jedem sein Geschmack überlassen, ob man die neuen »plain-vanilla« config-Files aus dem Upgrade übernimmt und dann nachher anhand der vorher gesicherten alten config-Files anpasst, oder ob man einfach die alten config-Files behält, mit dem Risiko, dass da dann auch nicht alles passt. Ich persönlich wähle da immer die erste Alternative.

Ein letzter Schritt ist dann noch notwendig, um das Upgrade abzuschließen:

$ sudo apt-get install kubuntu-desktop python-qt3 \
    python-kde3 ubuntu-minimal

Nach einem kurzen (hoffentlich) Reboot befindet man sich dann in einem Kubuntu 6.10 »Edgy Eft«.

(OK, der Desktop sieht jetzt irgendwie genau so aus wie vorher auch: Zum einen werden die nutzer-individuellen Einstellungen wie z.B. Wallpaper etc. übernommen, zum anderen hatte ich auch vorher schon KDE 3.5.5. Einziger Hint: Die Fenster-Deokrationen wurden auf »Lipstick« upgedated, vorher war es »Plastik«.)

Fazit

Das Upgrade ist nicht schwierig durchzuführen und dürfte auch dem Laien bei Befolgen der “Anleitung auf Kubuntu.com”: recht mühelos gelingen. Für ~~Angsthasen~~ Vorsichtige (so wie ich es einer bin) empfiehlt sich eventuell, vorher ein komplettes Backup des Rechners, zumindest aber der System-Partition anzulegen.

Nach dem Update hat man ein Kubuntu-System mit frischen Paketen, darunter KDE 3.5.5, OpenOffice 2, Mozilla Firefox 2, ...

Warum allerdings Kubuntu kein Update-Tool wie Ubuntu hat – diese Frage stelle ich mir immer wieder …

Gentoo und MySQL: A never-ending story

Martin Eisenhardt — Wed, 25 Oct 2006 16:53:19 +0000

Bereits im April gab es Probleme mit einem MySQL-Upgrade, nun gibt es einen weiteren Fall, in dem die Maintainer für MySQL bei Gentoo offensichtlich etwas zu schnell geschossen haben.

Historie oder: Was im April geschah

Nach der Aktualisierung von MySQL 4.1.14 auf die Version 4.1.14-r1 (und einer nicht angekündigten und schlecht kommunizierten Änderung des Standard-Encodings von latin1 auf utf8) funktionierten viele PHP-basierte Anwendungen entweder nicht mehr oder aber stellten Umlaute und andere Sonderzeichen falsch dar.

Dies ließ sich relativ schmerzlos durch einen kleinen Patch an den betroffenen Applikationen beheben (siehe den damaligen Blogpost). ~~Schlauere~~ Misstrauischere Zeitgenossen hatten auch noch eine andere Möglichkeit, wenn sie denn ein Backup ihrer Daten hatten: Einen DB-Dump mit dem alten MySQL in neuer Kodierung erstellen, dann MySQL stoppen, MySQL upgraden, dann ein Reload der Datenbank aus dem Dump mit neuer Kodierung.

Ich aber hatte das Pech, dass ich ein “Bindestrich-Update” (schließlich änderte sich nur die Gentoo-interne Revisionnummer) unterschätzt und für sicher gehalten habe – zumal die neue Version als stabil gekennzeichnet worden war. Wie so ein massiver Fehler den Maintainern bei Gentoo unterlaufen konnte, kann ich mir bis heute nicht erklären; so etwas darf nicht passieren, denn sehr viele Linux-Installationen werden in einem LAMP Stack eingesetzt, in dem das M eben für MySQL steht.

Kommen wir aber zum aktuellen Problem mit Gentoo und MySQL.

Das aktuelle Problem: Update von MySQL 5.0.26 auf 5.0.26-r1

Seit ca. August 2006 hatte ich die MySQL-Version 5.0.24 im Einsatz, die auch prima funktionierte: Blog betreiben, Postfix mit virtuellen Maildomains und virtuellen Mailboxes, Courier-IMAP mit Courier-Authlib und vor allem (das wird noch wichtig): Cyrus-SASL für die SMTP-Authentifizierung per SASL. Alle diese Komponenten greifen mehr oder weniger direkt auf den lokal laufenden MySQL-Server zu.

Am 13. Oktober 2006 wurde dann das Update auf MySQL 5.0.26 freigegeben, welches ich auch erfolgreich kompiliert und installiert habe. Wiederum lief alles prima – offensichtlich aber nur für diejenigen Nutzer, die keine Perl-DBI-Applikationen betreiben.

Genau da hatte die Version 5.0.26 nämlich einige Probleme und musste gepatcht werden, was dann am 21. Oktober 2006 geschah: Version 5.0.26-r1 (man beachte: es handelt sich um ein Bindestrich-Update!) fixte diese Probleme. Da ich meine Server immer gerne auf aktuellem Stand halte, habe ich auch dieses Update installiert.

Das war ein Fehler

Fast alle Applikationen liefen nach wie vor prima, allerdings hatte Cyrus-SASL keine Chance mehr, sich mit dem MySQL-Server zu verbinden. Also war auch keine SMTP-Authentifizierung mehr möglich, und in Folge dessen konnten keine eMails mehr über meinen MTA versendet werden. Der Empfang lief weiterhin prima, genauso wie der automatische Versand von eMails vom Server aus selbst. Vom Arbeitsplatz oder Laptop aus aber ging gar nichts mehr, weil diese SMTP-Sessions authentifiziert werden müssen (Stichwort: Open Relay).

Was nun?

Bislang hatte sich Cyrus-SASL über das Unix-Socket mit MySQL verbunden. Von der Kommandozeile aus ging das auch immer noch prima:

$ mysqladmin -u root -p version
mysqladmin  Ver 8.41 Distrib 5.0.26, for pc-linux-gnu on x86_64
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license
 
Server version          5.0.26-log
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/run/mysqld/mysqld.sock
Uptime:                 1 hour 7 min 9 sec
 
Threads: 10  Questions: 2705  Slow queries: 0  Opens: 30
Flush tables: 1  Open tables: 24  Queries per second avg: 0.671

Applikationen wie Wordpress oder Postfix selbst (für virtuelle Mailboxes etc.) konnten sich auch weiterhin über das Unix-Socket in /var/run/mysqld/mysqld.sock connecten, genauso wie auch über TCP/IP(Transport Control Protocol/Internet Protocol). Nur Cyrus-SASL verweigerte sowohl über das Socket als auch über TCP/IP den Dienst.

Nach vielen Hin und Her hat sich dann herausgestellt, dass folgende Konfiguration für Cyrus-SASL in /etc/sasl2/smtpd.conf immer noch die richtige ist:

pwcheck_method: auxprop
auxprop_plugin: sql
srp_mda: md5
password_format: crypt
mech_list: login plain
log_level: 0
 
sql_engine: mysql
sql_hostname: 127.0.0.1
sql_database: postfix
sql_user: postfix
sql_passwd: geheim
sql_select: SELECT password FROM accounts WHERE email='%u@%r'
sql_usessl: no

Als sql_hostname kann wahlweise auch localhost oder die nicht-lokale IP des MySQL-Servers verwendet werden.

Einziges Manko dieser Konfiguration: Sie funktionierte nicht mehr. Also scheint der Fehler bei MySQL zu liegen.

Was liegt näher als ein Downgrade auf die letzte funktionierende Version? Nichts, außer dass das entsprechende ebuild (/usr/portage/dev-db/mysql/mysql-5.0.24-r1.ebuild) am 21. Oktober aus Portage entfernt wurde. Der Spaß begann.

Spaß

Durch freundliche Hilfe im Forum bei Gentoo wurde ich darauf aufmerksam gemacht, dass ich einfach nur den ebuild für MySQL 5.0.26-r1 umkopieren müssen und damit dann schon den entsprechenden ebuild für die gewünschte Version hätte:

$ cd /usr/portage/dev-db/mysql
$ cp mysql-5.0.26-r1.ebuild mysql-5.0.24-r1.ebuild

Danach war nur noch notwendig, den digest für diesen “neuen” (alten) ebuild zu erzeugen:

$ ebuild mysql-5.0.24-r1.ebuild digest

Dieses Kommando lädt die für den ebuild benötigten Dateien und erstellt für alle Prüfsummen. Leider: Die benötigte Datei mysql-5.0.24.tar.gz ist auf einigermaßen aktuellen Mirrorn des Gentoo Mirror Networks nicht mehr vorhanden, da der zugehörige ebuild ja bereits aus Portage entfernt wurde.

Bei MySQL selbst gibt es die Datei mysql-5.0.24a-linux.tar.gz – nur ob das jetzt die gleiche ist wie die Datei, die es mal auf den Gentoo-Mirrorn gab, ist eher schwierig zu entscheiden.

Ich stand also da ohne die benötigten Source-Pakete – und ohne die geht unter Gentoo gar nichts. Ich hatte also mehr Spaß.

Mehr Spaß

Glücklicherweise konnte ich auf einem Server in Portugal, der offensichtlich schon seit ein paar Tagen nicht mehr gesynct wurde, diese Datei dann doch noch finden, zusammen mit dem kompletten Patch-Set für MySQL 5.0.24-r1.

Also nichts wie runtergeladen, Digests erstellt (s.o.) und dann ein

$ emerge -p =dev-db/mysql-5.0.24-r1

Das lief dann auch gut durch und wurde installiert, und schon nach einem

$ /etc/init.d/mysql restart

lief alles wieder wie gewohnt: reibungslos.

Da ich diese Version jetzt sicherlich so schnell nicht wieder updaten möchte, habe ich der Datei /etc/portage/package.mask noch folgende Zeile hinzugefügt:

=dev-db/mysql-5.0.26

Damit sind alle MySQL-Versionen ab 5.0.26 gesperrt.

Fazit

Das MySQL-Maintainer-Team bei Gentoo hat es wieder einmal geschafft, mir (und vermutlich vielen anderen Anwendern) echte Probleme zu bereiten. Da wird mit heißer Nadel ein Fehler gefixt, der – und das muss man natürlich auch in Betracht ziehen – viele Perl-Anwender an den Rand der Verzweiflung getrieben hat. Nur: Der Patch, der diesen Fehler behebt, ist dann eine echte Katastrophe für all diejenigen, die auf Postfix+Cyrus-SASL+MySQL als MTA setzen – und das dürften nicht gerade wenige sein.

Insgesamt erinnert mich das alles ein bisschen an die Patch-Gewohnheiten von Microsoft: Da gibt es auch häufiger mal einen Patch für einen Patch für einen Patch … Weil mit jedem Patch (von denen jeder für sich genommen sicherlich sehr wichtig ist) das Produkt an einer anderen Stelle bricht.

Ich hoffe, dass die Maintainer bei Gentoo nun aus diesem Disaster lernen und zukünftig die MySQL-Releases ein bisschen besser testen. Damit können sie sich viele Freunde unter den Perl-Usern und den MTA-Admins machen.

Service

Da es wohl schwieriger werden wird, die Dateien für die Gentoo-Variante von MySQL 5.0.24-r1 über die üblichen Kanäle zu beziehen, habe ich sie hier noch einmal zusammengestellt.

Datei	Größe	speichern in
mysql-5.0.24-r1.ebuild	1.1K	/usr/portage/dev-db/mysql
mysql-5.0.24.tar.gz	20M	/usr/portage/distfiles
mysql-patchset-5.0.24-r2.tar.bz2	1.7K	/usr/portage/distfiles

Die Angaben zum Speicherort beziehen sich auf ein standard-konform eingerichtetes Gentoo-System. Die ebuild-Datei ist nach dem nächsten

$ emerge --sync

wieder weg, da sie nicht mehr im offiziellen Portage-Tree enthalten ist. Hier könnte man mit Overlays arbeiten. Nach dem Download und Speichern der drei Dateien ist Folgendes auszuführen:

$ cd /usr/portage/dev-db/mysql
$ ebuild mysql-5.0.24-r1.ebuild digest
$ emerge -av =mysql-5.0.24-r1
$ /etc/init.d/mysql restart

XFS und (De)Fragmentierung

Martin Eisenhardt — Fri, 13 Oct 2006 14:41:10 +0000

Ich betreibe viele Partitionen mit dem von mir sehr geschätzten Dateisystem XFS von SGI, das seit längerer Zeit schon auch im Linux-Kernel als rock stable gilt.

Eine feine Fähigkeit von XFS ist es, dass man Partitionen mit einem Tool namens xfs_fsr defragmentieren kann, wie man das auch von Windows her gewohnt ist. Eigentlich ist das Mantra bei Linux-Dateisystemen ja:

Intelligente Ressourcen-Allokation verhindert zu starke Fragmentierung.

Und daher sollte man angeblich auch auf defragementierende Tools verzichten können. Gerade XFS sticht mit einer besonders intelligenten Block-Allokation gegenüber anderen Dateisystemen hervor: Es werden z.B. beim Schreiben großer Dateien gleich megabyteweise zusammenhängender Platz auf dem Block-Device reserviert und erst dann geschrieben. Das ermöglicht nachher beim Lesen dieser Daten eine extrem hohe Datentransferrate, da der Schreib-/Lese-Kopf keine Seeks über das Medium mehr machen muss.

Allerdings scheint es Workloads zu geben, die auch die intelligente Block-Allokation von XFS in die Kniee zwingt. Gestern scheine ich eine solche produziert zu haben. Ich habe auf eine portable USB-Platte mit 320 GB Kapazität gleichzeitig 12 Datenströme mit jeweils etwa 1 GB geschrieben. Beim Lesen dieser Daten heute zu Hause fiel mir auf, dass das doch recht langsam geht.

Also habe ich gerade mal

$ xfs_fsr -v

angeschmissen. xfs_fsr analysiert die inodes des Dateisystems und versucht Dateien so umzuorganisieren, dass sie mit möglichst wenigen extents auskommen. Im Idealfall hat eine Datei einen extent, der genau so viele Blocks umfasst, wie die Datei zu ihrer Speicherung benötigt.

Die Ausgabe von xfs_fsr (auf das Interessante gekürzt):

START: pass=0 ino=0 /dev/sda1 /media/usbdisk
/media/usbdisk start inode=0
ino=143
extents before:32903 after:1 DONE ino=143
ino=134
extents before:3316 after:1 DONE ino=134
ino=135
extents before:1403 after:1 DONE ino=135
ino=7241782
extents before:1135 after:1 DONE ino=7241782
ino=7241786
extents before:886 after:1 DONE ino=7241786
ino=7241787
extents before:842 after:1 DONE ino=7241787
ino=7241785
extents before:561 after:1 DONE ino=7241785
ino=7241788
extents before:241 after:1 DONE ino=7241788

Danach kommt nur noch Kleinkram.

Dass eine Datei mit 32903 Extents bei der Lesegeschwindigkeit etwas hinter den Erwartungen hinterherhinkt – das konnt man auch wirklich nicht erwarten …

Im WWW zu diesem Thema:

Defragment XFS File-system

Google bietet Ping-Service für Weblogs an

Martin Eisenhardt — Fri, 06 Oct 2006 11:29:47 +0000

Endlich bietet Google einen Service an, den andere Suchdienste für Blogs schon lange anbieten: Man kann Google nun anpingen, um neue Beiträge im eigenen Blog zu melden. Die Suchmaschine wird dann kurze Zeit später diesen neuen Blogpost indexieren und damit für die Suche zugänglich machen.

Bereits seit längerem bietet Google eine spezialisierte Suche nach Artikeln in Weblogs an. Der Ping-Service ist unter http://blogsearch.google.com/ping erreichbar, dort kann die Adresse des eigenen Blogs eingetragen werden. Die meiste Blog-Software (z.B. Wordpress) bieten auch die Möglichkeit, dies zu automatisieren; bei der Publizierung eines neuen Artikels werden dann automatisch die eingetragenen Ping-Services über den neuen Blogpost unterrichtet.

Bei Wordpress lässt sich dies unter Einstellungen » Schreiben einrichten. Dort muss in das entsprechende Eingabefeld (siehe Abbildung) der neue Ping-Dienst eingetragen werden.

Eintragen eines neuen Ping-Services in einem Wordpress-Blog.

Google bietet noch einen weiteren interessanten neuen Service an: Unter der URL http://blogsearch.google.com/changes.xml kann man sich die aktuellen bei Google einlaufenden Pings ansehen; dies lässt sich sicherlich auch für eine eigene Blog-Search-Engine nutzen, wobei die Rechtslage hinsichtlich der Nutzung dieser Daten momentan noch unklar ist, da sich die Google Blogsearch insgesamt noch im Beta-Stadium befindet.

[via Golem]

Wie man ein Blog über Inhalte bekannt macht

Martin Eisenhardt — Wed, 04 Oct 2006 18:42:36 +0000

von Neil Patel

Für jeden Blogger ist es ein Ziel, bekannt zu werden. Das kann durch Optimierungen des Blogs erreicht werden oder durch die diversen social media, die es mittlerweile gibt. Diese Methoden sind großartig und können den Bekanntheitsgrad eines Blogs steigern, allerdings liegen sie typischerweise außerhalb der eigenen Kontrolle. Das entscheidende Mittel hat man hingegen in der eigenen Hand: der Content, der Inhalt im Blog. Hier folgen nun einige Ideen, wie man den Bekanntheitsgrad eines Blogs über den Content steigern kann.

Verbreite Neuigkeiten

Neuigkeiten verbreiten sich in der Blogosphäre wie ein Lauffeuer. Handelt es sich um neue und wichtige Nachrichten, dann wird jeder darüber schreiben und auf die Fundstelle dieser News verlinken. Meistens ist es nicht einfach, Neuigkeiten zu verbreiten, während Tausende andere das Gleiche tun. Wenn dies aber gelingt, dann werden andere Blogger auf Dein Blog verlinken und es auch weiterhin regelmäßig lesen, um auf dem neuesten Stand zu bleiben.

Veröffentliche an Wochenenden

Wahrscheinlich werden die Leser Deines Blogs auch andere Blogs lesen. Schon wegen der schieren Anzahl an Blogs, die tägliche neue Artikel posten, wird es für die Leser schwierig sein, alle Artikel zu lesen. Wenn Du hingegen dann neue Artikel postest, wenn Deine Leser Zeit haben, z.B. am Wochenende, dann steigen die Chancen, dass diese Leser Dein Blog lesen. Wenn Du Dir die Blogs in Deinem Interessenbereich ansiehst, werden die meisten davon vermutlich nicht am Wochenende posten. Mir ist klar, dass einige hiermit Schwierigkeiten haben, aber überlege Dir diesen Ansatz, wenn Du die Zeit hierfür am Wochenende übrig hast.

Veröffentliche zeitlose Artikel

Versuche nicht nur Artikel zu schreiben, die eine Lebensdauer von nur einer Woche haben, sondern schreibe immer wieder über zeitlose Dinge. Diese Artikel werden zwar anfänglich nicht so stark einschlagen, aber sie könnten in einigen Monaten populär werden. Versuche also Artikel zu schreiben, die länger als einen Tag oder eine Woche “leben”.

Lehre, verkaufe nicht

Viele Leute beginnen mit einem Blog, weil sie Geld verdienen wollen. Am Geldverdienen ist nichts Falsches, und auch bloggen für Geld ist nicht verkehrt, aber vermeide jede Form der Verkaufsmasche in Deinen Blogartikeln. Wenn Du Deine Leser stattdessen informierst und gut unterrichtest, dann werden Dich die Leute möglicherweise als Autorität auf Deinem Gebiet ansehen, und das kann zu vielen günstigen Gelegenheiten für Geschäfte o.ä. führen.

Beteilige Dich an Diskussionen

eMails an andere Blogger mit der Bitte um Links können ein effektives Mittel sein, den Traffic auf Deinem Blog zu erhöhen. Ein anderer guter Weg, die eigenen Popularität zu steigern, ist die Teilnahme an Diskussionen und Unterhaltungen. Ein gutes Beispiel hierfür sind die 5 Rules of Social Media Optimization von Rohit Bhargava; durch die Beiträge tausender Leser wurde aus dieser Liste von fünf Regeln die 17 Rules of Social Media Optimization.

Ein populäres Blog zu betreiben ist eine fordernde Aufgabe, besonders angesichts der großen Anzahl neuer Blogs, die jeden Tag hinzukommen. Das Beste, was man tun kann: hochqualitativen, nützlichen Content produzieren, über Themen, an denen man selbst wirklich interessiert ist. Die Leute warten darauf von Dir zu hören, was Du ihnen erzählen möchtest. Verschwende nicht ihre Zeit!

Dieses Posting ist eine Übersetzung des Beitrags Making your blog popular through content von Neil Patel.

Neuer Mirror für Gentoo online | New Gentoo Mirror online

Martin Eisenhardt — Sat, 23 Sep 2006 11:27:37 +0000

Deutscher Text

English text follows at bottom of post.

Ab sofort steht ein neuer full mirror der Linux-Distribution Gentoo zur Verfügung, der alle zwei Stunden upgedated wird. Gespiegelt sind alle distfiles, die täglichen Snapshots des Portage-Trees sowie alle ISO-Images des Gentoo-Projekts (außer /releases/historical). Gehostet wird der Mirror auf einem AMD Athlon 64 3700+, 1 GB RAM, XFS auf RAID-0, 1 GBit NIC, Kernel 2.6.17-gentoo-r8; das Rechenzentrum steht in Nürnberg und ist mit insgesamt 9 GBit an verschiedene Backbones angebunden.

Momentan ist der Mirror weder hinsichtlich der Bandbreite noch der Anzahl gleichzeitiger Benutzer eingeschränkt.

Erreichbar ist der Mirror per HTTP und FTP:

http://gentoo.mneisen.org/

ftp://ftp.mneisen.org/gentoo/
Um den neuen Mirror zu verwenden, öffnen Sie bitte als root die Datei /etc/make.conf und suchen dort eine Zeile, die mit _GENTOO_MIRRORS_ beginnt, z.B.
GENTOO_MIRRORS="http://distfiles.gentoo.org/"

Fügen Sie nun den neuen Mirror an erster Stelle ein (dabei können Sie zwischen HTTP und FTP wählen):
GENTOO_MIRRORS="http://gentoo.mneisen.org/ http://distfiles.gentoo.org/"
bzw.
GENTOO_MIRRORS="ftp://ftp.mneisen.org/gentoo/ http://distfiles.gentoo.org/"
Auf diese Weise verwenden Sie standardmäßig den neuen Mirror und behalten den ursprünglich eingetragenen Mirror als fall back.

Für weitere Informationen oder bei Problemen kontaktieren Sie bitte Martin Eisenhardt.

English text

Beginning September 23, 2006, a new full mirror of the Gentoo Linux distribution is available to the general public. Updated on a bi-hourly schedule, it provides all distfiles, daily snapshots of the portage tree and all ISO images of the Gentoo project (sparing /releases/historical). The mirror runs on AMD Athlon 64 3700+, 1 GB RAM, XFS on RAID-0, 1 GBit NIC, kernel 2.6.17-gentoo-r8; the data center is located in Nuremberg (Germany) and connects with an aggregated bandwidth of 9 GBit to several backbones.

Momenarily, the mirror does not limit total bandwidth or concurrent number of users.

You may connect to the mirror by HTTP or FTP:
http://gentoo.mneisen.org/

ftp://ftp.mneisen.org/gentoo/
To use the new mirror, open the file /etc/make.conf with root privileges and search a line starting with _GENTOO_MIRRORS_, f.e.
GENTOO_MIRRORS="http://distfiles.gentoo.org/"

Insert the new mirror as first mirror (you may choose to use HTTP or FTP):
GENTOO_MIRRORS="http://gentoo.mneisen.org/ http://distfiles.gentoo.org/"
or
GENTOO_MIRRORS="ftp://ftp.mneisen.org/gentoo/ http://distfiles.gentoo.org/"
Save the file. Now, your system will use the new mirror as primary mirror, with your old mirror(s) as fall-back solution.

For additional information, or in the case of problems, contact Martin Eisenhardt.

Gentoo: PHP & MySQL-Updates machen Probleme

Martin Eisenhardt — Mon, 24 Apr 2006 22:40:57 +0000

Sonntags hat man ja nichts zu tun, wir haben ja alle eine 40-Stunden-Woche und “Freitag ab eins macht jeder seins” . Was macht man also? Während man die während der Woche liegengebliebene Arbeit nachholt und sich auf die nächste Arbeitswoche vorbereitet, kann man ja mal eben schnell seinen Server auf den neuesten Stand bringen.

Ich betreibe meine Rechner vorzugsweise unter Gentoo, nur zum Daddeln habe ich auf dem Laptop auch ein Windows. Das Schöne an Gentoo ist eigentlich, dass man sich darauf verlassen kann, dass alles so funktioniert, wie es soll. Es ist zwar manchmal ein bisschen Nachhilfe notwendig, aber das macht die Sache ja eher noch interessanter.

Aber was ist jetzt passiert? Ich habe gestern PHP und MySQL auf die neuesten stabilen(!) Versionen upgedated, und musste dann feststellen, dass sich sowohl Joomla! als auch phpBB2 beharrlich weigerten, Umlaute darzustellen. Stattdessen bekam man nur Multi-Byte-Sequenzen zu sehen. Die neuen Versionen ließen sich auch durch weitestgehende Anpassungen der /etc/mysql/my.cnf bzw. der /etc/apache2-php5/php.ini nicht dazu überreden, dass die Umlaute wieder korrekt angezeigt wurden.

Was war denn da kaputt? Schließlich ging es nur von MySQL 4.1.14 auf 4.1.14-r1, und auch bei PHP ging es nur um ein ähnlich kleines Update. Grund für die Probleme war es offensichtlich, dass die bereits existierenden Datenbanken in LATIN1-Kodierung vorlagen, das neue MySQL 4.1.14-r1 auf Gentoo aber UTF-8 verwendet. Stellt man das auf LATIN1 zurück, erscheinen zwar die Umlaute wieder, dann gibt es aber Probleme mit neuen Datenbanken, die man gerne in UTF-8 hätte.

Was passiert war: Zum ersten Mal seit langem haben die Betreuer des Package-Systems von Gentoo (portage) wohl etwas durchgewunken, was nicht hätte stable sein sollen. Das letzte Mal war mit das bei einem Update von apache-2.0.x-r39 auf apache-2.0.x-r40 untergekommen: bei diesem Update hatten sich die Maintainer des Portage-Trees dazu entschlossen, das Layout der Konfigurations-Dateien komplett zu ändern—bis dato wiesen die Konfigurationsdateien des httpd unter Gentoo eine gänzlich andere Struktur auf als von der Apache Foundation oder anderen Linux-Distributionen bekannt.

Was mich besonders ärgert: Wie kann man eine ernsthafte Linux-Distribution sein wollen und gleichzeitig Bindestrich-Updates (bumlux-x.y.z-r13 auf bumlux-x.y.z-r14) als stable releasen, die den Sysadmins die Konfiguration völlig zerhauen? Das darf einfach nicht passieren, schließlich gibt es ja nicht nur ein paar Privatanwender und Lehrstühle, die auf (Gentoo) Linux bauen—inzwischen gibt es auch Leute, die damit ihr Geld verdienen und die wichtige Applikationen betreiben.

Ach ja, der Work-around: Lokalisiert jeden Aufruf von mysql_connect() in Eurer Web-Applikation und schreibt direkt dahinter ein

mysql_query("SET CHARACTER SET xxx");

wobei xxx das gewünschte character set ist.

Umständlich und blöd, aber es funktioniert zumindest bei Joomla! und phpBB2.

Zum Schluss, und damit da keine Missverständnisse entstehen: Ich halte Gentoo nach wie vor für eine tolle Distribution und setze weiter darauf—ich hoffe aber, dass sich das Release Management zumindest bei den wichtigen Applikationen (LAMP, X, KDE, ...) noch weiter verbessert.

Update

Bernd Wurst schreibt in seinem Blog auch über die oben beschriebene Problematik und erklärt auch noch ein bisschen besser, warum MySQL sich so benimmt, während ich ja hier nur eine Metabetrachtung vorgenommen habe und den Workaround beschreibe. Danke an Bernd für die Erklärung!

Steffen Zieger schreibt in seinem Blog, dass es auch jetzt noch Probleme mit MySQL und PHP unter Gentoo gibt, die allerdings einfacher zu umschiffen sind. Inzwischen müssen nur noch die Zeichensätze der Datenbanken in der Konfigurationsdatei my.cnf richtig eingestellt werden – und das ist ja auch logisch.