Gentoo und MySQL: A never-ending story
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
Ähnliche Artikel in diesem Blog:
Tags: emerge, Gentoo, Linux, MySQL, Open Source, OSS, Perl, Python, SQL
Am 26. Oktober 2006 um 22:00 Uhr
Hi, hab den Blogpost hier auf den Forums gesehen und will mal kommentieren…
Also, zuerst hat das Problem mit den Sockets nichts mit dem -r1 upgrade zu tun um das ABI Breakage zu fixen.
Wir haben 5.0.26 released, was auch all unsere Tests (MySQL-Testsuite, tests mit PHP etc.) durchging, als MySQL AB das freigegeben hat… Da dann aber ein ABI Breakage drin war, haben wir dann 5.0.26-r1 freigegeben mit dem korrekten fix dafür, und was wars bezüglich den “bindestrich Versionen” (wer hat da gesagt es können sich keine grossen Sachen ändern? Und auch ist MySQL 5.0.X noch als unstable markiert…).
Zeitgleich werkelten wir an den mysql Eclasses um MySQL 5.1 support zu fixen, und gaben diese neuen Eclasses Samstag Abend frei (auch da, all unsere Tests waren erfolgreich), doch da schlich sich ein minimaler Bug ein: die Socket-Path Angabe wurde mit ‘’ quotiert, was theoretisch keine Probleme verursachen sollte, doch einige Programme nahmen das dann zu ernst und benutzten direkt ’/var/.../mysql.sock’ (MIT den quotes) als Socket-Path, was natürlich nicht geht… Sobald wir am Montag Morgen darüber informiert worden, wurde der Bug gefixt. Da das Problem in den Eclasses war, betraf es alle dev-db/mysql Versionen die in der Zeitspanne emerged wurden (natürlich vorausgesetzt man hatte in der Zeitspanne auch emerge—sync gemacht)... Korrekter fix: einfach re-emergen.
Wir sind uns darüber im Klaren das solche Sachen nicht passieren sollten, doch leider kann man nicht alles vorhersehen, und wenn uns Probleme bekannt werden, versuchen wir die schnellstmöglich zu beheben. Auch das UTF-8/Latin1 Problem war n’bissel komplizierter als was hier geschrieben wurde, eine Serie an Updates in MySQL und PHP, die einzeln korrekt funktionierten, doch zusammen etwas weniger, war Schuld, und dann entschieden wir uns halt mit der UTF-8 Idee weiterzumachen, weil es unumstritten das bessere Charset der beiden ist, und haben dann den my.cnf fix für PHP bereitgestellt.
Grüsse, Luca Longinotti, Gentoo PHP & MySQL Maintainer.
Am 27. Oktober 2006 um 09:43 Uhr
Hallo Luca,
danke für Deinen Kommentar und die Aufklärung, was da wirklich schief gelaufen ist. Ich möchte da mal auf ein paar Punkte eingehen:
MySQL 5 ist in Gentoo unstable
Das stimmt, ist aber sehr bedauerlich, da MySQL 5 viele neue Features mitgebracht hat, die zumindest ich gerne nutze. Das MySQL-Projekt hat die 5.0-Serie bereits seit langem als für den produktiven Einsatz bestimmt gekennzeichnet, und die meisten anderen Linux-Distributionen unterstützten inzwischen standardmäßig MySQL 5. Das soll jetzt auf keinen Fall ein Gentoo-Bashing sein, aber da hinkt diese von mir sehr geschätzte Distribution ein wenig hinterher. Ich kann mir gut vorstellen, dass es dafür Gründe gibt – vielleicht kannst Du da ja ein bisschen Licht ins Dunkel bringen (Links welcome!).
Erklärung für das Problem mit MySQL 5.0.26-r1
Das Problem mit den Quotes in der eclass habe ich dann dank des entsprechenden Threads in den Gentoo-Foren auch bei bugs.gentoo.org gefunden – leider für meine Zwecke ein bisschen spät, aber daran bin ich selbst schuld.
Inzwischen ist MySQL 5.0.26-r1 im Einsatz und läuft prima.
UTF-8 vs. Latin1
Ich stimme Dir vollkommen zu, dass UTF-8 die richtige Wahl für ein Charset ist – egal ob in der DB oder systemweit. Damals war halt ärgerlich, dass durch das Update gerade in Blogs, CMS und Foren ziemlich viel Unschönes passierte und ich schnell einen Fix brauchte, den ich dann eben wie in dem verlinkten Blogpost beschrieben vorgenommen habe. Ich gebe zu, dass es kein schöner Fix ist, aber er hat wenigstens funktioniert
Inzwischen ist das natürlich kein Thema mehr, alle DBs sind auf UTF-8 portiert und laufen klasse.
Oberthema: Patch-Qualität bzw. Release-Qualität
Es ist immer ein heikles Thema, wenn man über die Qualität der Arbeit anderer spricht. Besonders in diesem Fall, weil ich sowohl von Gentoo insgesamt, aber auch von der MySQL-Unterstützung ziemlich begeistert bin.
Dennoch wage ich hier mal eine These aufzustellen:
Es gibt beim Thema Software-Tests (im Speziellen bei Unit Tests, aber das ist hier sicherlich übertragbar) eine Grundweisheit:
Das stellt einen Software-Entwickler oder Maintainer natürlich vor Probleme: Egal, wie sehr er sich anstrengt, er kann nie garantieren, dass die Software fehlerfrei ist.
Meiner Meinung nach wäre es aber sinnvoll, die wichtigsten/häufigsten Einsatzszenarien durchzutesten. Im Falle von MySQL bedeutet dies etwa Wordpress, phpBB & Konsorten, diverse Language Bindings (Perl, Python, C, C++, Ruby), amarok u.ä. und eben den Bereich MTA. Und da dürfte die Konfiguration Postfix+MySQL+Cyrus-SASL+Courier doch ziemlich häufig anzutreffen sein, also einen typischen Use Case darstellen.
Eine kleine Statistik
Noch ein paar Worte zur Wichtigkeit der Qualitätssicherung bei MySQL: Dieses Blog hier ist noch nicht sehr alt, es gibt nicht allzu viele Artikel. Dennoch: Der am meisten gelesene Artikel ist mit Abstand der Artikel über die UTF-8 vs. Latin1-Geschichte mit PHP unter Gentoo. Auch jetzt kommen jeden Tag Dutzende von Besuchern über Suchmaschinen auf diesen Artikel, übliche Suchanfrage ist “Gentoo Mysql php latin1 utf8” oder etwas sehr ähnliches.
Kleines Fazit
Nach wie vor bin ich von der Qualität, Konfigurierbarkeit, Paketverfügbarkeit und Zuverlässigkeit von Gentoo und MySQL unter Gentoo sehr überzeugt – deshalb setze ich nach wie vor auf dieses Gespann.
Im Einzelfall würde ich mir – nach Deinen Schilderungen – etwas umfangreichere und vielleicht realitätsnähere(?) Tests wünschen. Vielleicht gibt es die Möglichkeit, ein paar typische Einsatzszenarien (z.B. Mailserver mit Postfix+MySQL, Blog-Server mit Wordpress und phpBB, ...) als Image für QEMU zu erstellen und auch mit diesen Images zu testen.
Ich wäre durchaus bereit, da mitzuhelfen – ich bastele gerne mit QEMU.
Am 27. Oktober 2006 um 13:22 Uhr
Hallo Martin!
Ja, dass MySQL 5.0 noch unstable ist, ist bedauerlich, doch das wird sich endlich bald ändern: https://bugs.gentoo.org/show_bug.cgi?id=144999#c17
Gründe waren vorallem noch Bugs die man beheben musste und viel Testing das man noch machen musste, beides sollte jetzt ok sein. Also so in 8-10 Tagen sollte MySQL 5.0.26-r1 anfangen stable markiert zu werden.
Zum Testing: ja, wir werden das ausweitern, atm wurden vorallem die MySQL eigenen Tests und PHP/PHP Apps als Test-cases benutzt, MTA/Language-Bindings, wenigstens meinerseits, noch nie, muss gestehen daran nie gross gedacht zu haben… Demnächst werde ich nen neuen Server mit Linux-Vserver aufsetzen, und da werden wir wohl sicher ein paar Images für MySQL-Testing einrichten, was die Arbeit da vereinfachen sollte.
Mfg, Luca Longinotti.
Am 13. November 2006 um 16:38 Uhr
Danke für die Ausführungen. MySQL 5.0.26 ist ja jetzt stable, meine SASL/MySQL-Authentifizierung hat es heute aber dennoch zerhauen. Ich hab jetzt erstmal wieder ein downgrade auf 4.1 gemacht…
Am 20. November 2006 um 19:39 Uhr
Tja, da lief es ewig, ohne Probleme und dann will ich eben nur eine “Kleinigkeit” machen, da habe ich die selben Probs. Bin gerade dabei, mysql neu zu comilen, soll ja helfen. Hoffentlich!
Am 20. November 2006 um 20:12 Uhr
puh, kann wieder mailen…
Am 13. Februar 2007 um 12:43 Uhr
auf meinen gentoo-servern habe ich auch immer die bange frage, ob ein update jetzt was kaputt macht, oder nicht. um schnell wieder auf die alte version zurueckzuwechseln, mache ich daher vorher von allen mir wichtigen packeten (=diensten), die geupdatet werden sollen ein ‘quickpkg’.
das ist ein tar aller installierten files des packetes und kann im falle eines falles schnell zurueckinstalliert werden.