Author Archives: Patrick

MySQL-Upgrade wie es sein sollte

Nicht, dass ich im Allgemeinen zu extremer Prokrastination neige, aber im Falle des netten kleinen ToDos „Update der MySQL-Server auf 5.5“ bin ich eindeutig schuldig. Das schob ich nämlich bereits seit Ende 2012 leise vor mir her, da ich den Aufwand für außerordentlich hoch hielt. Zur Ausgangssituation: Aus historischen Gründen hatten wir eine recht heterogene Landschaft im Bereich MySQL-DB-Server, bestehend aus:

* 1 Master-Slave-Cluster, Version 5.1, basierend auf original MySQL-RPMs

* 2 Master-Slave-Clustern, Version 5.1, basierend auf IUS-RPMs

* 1 Master-Slave-Cluster, Version 5.5, basierend auf original MySQL-RPMs

* 1 Master-Master-Cluster, Version 5.1, basierend auf original MySQL-RPMs

Wohlgemerkt: Alle auf RHEL5! Die nun alle auf eine homogene Basis zu stellen (nämlich Version 5.5, basierend auf IUS-RPMs) und dabei sowohl die Daten als auch die Replikation leben zu lassen, schien nur durch komplette Dump-Restores mit zwischenzeitlicher Neuinstallation der Pakete zu funktionieren. Da wir hier über eine Datenmenge von insgesamt etwa einem Terabyte sprechen, rechnete ich mit einer ziemlich großen Downtime.

Ein wenig Recherche nach der optimalen Vorgehensweise brachte jedoch zutage, dass die Jungs und Mädels der IUS Community (http://iuscommunity.org), deren Repositories wir ja auch oft und gerne benutzen, tatsächlich auch an solche wirren Zustände gedacht haben. Genauer gesagt gibt es das hübsche Plugin „replace“ für die Paketverwaltung yum. Es lässt sich – natürlich nach Integration des IUS-Repos – per „yum install yum-plugin-replace“ installieren und eröffnet die Möglichkeit, yum mit der Option „replace-with“ aufzurufen.

So führt das folgende Kommando bspw. dazu, dass ein bisheriger 5.1-Server auf IUS-Basis nahtlos durch einen 5.5-Server ersetzt wird:

yum replace mysql51-libs --replace-with mysql55-libs

Der Wechsel ist aber – und das ist das eigentliche Erstaunliche – auch aus den MySQL-RPMs heraus möglich:

yum replace MySQL-server-community --replace-with mysql55-server

yum bzw. das Plugin löst selbst alle nötigen Abhängigkeiten auf. Ggf. beschwert es sich, dass die Herkunft einiger beteiligter Pakete nicht ermittelt werden konnte, dies kann man aber problemlos ignorieren.

Letztendlich war es mir so möglich, das gefürchtete Upgrade für alle Server in einer Stunde durchzuführen, ohne dass ich bislang ein Problem feststellen konnte. Einige Hinweise gilt es aber noch zu beachten:

  • Laut MySQL sollte immer der Slave zuerst aktualisiert werden.
  • Nach dem Upgrade von Slave und Master muss auf dem Master das Kommando „mysql_upgrade“ ausgeführt werden, um fehlende MySQL-Tabellen zu ergänzen. Zudem werden bei der Gelegenheit alle Tabellen geprüft und ggf. repariert.
  • Beim Wechsel von MySQL 5.5 aus MySQL-RPMs auf MySQL 5.5 aus IUS-RPMs musste ich zuvor manuell das Paket „MySQL-shared-compat“ entfernen. Das konnte das Plugin aus irgendwelchen Gründen nicht lösen.
  • Bei Statement-basierter Replikation wirft MySQL 5.5 im Gegensatz zu 5.1 Warnungen, wenn Anweisungen bspw. nicht-deterministische Ergebnisse liefern. Diese Warnungen waren nicht zu unterdrücken (jedenfalls habe ich den Schalter nicht gefunden), obwohl wir uns der Tatsache bewusst waren und die entsprechende Datenbank ohnehin von der Replikation ausgenommen hatten. Ein somit ohnehin fälliger Wechsel zum „Mixed“-Format war also unvermeidlich (Schalter „binlog-format = MIXED“)
  • In MySQL 5.5 fallen einige Konfigurationsoptionen weg bzw. sollten durch ihre Nachfolger ersetzt werden. Die Ersetzung kann bereits vor dem Upgrade in der my.cnf durchgeführt werden. Aufgefallen sind bei mir:
    • skip-locking
    • log-err (ersetzt durch log-error)
    • key_buffer (ersetzt durch key_buffer_size)
    • thread_cache (ersetzt durch thread_cache_size)

Mediawiki und LDAP – „Wollen Sie sich wirklich sperren?“

Ein lange gehegter Wunsch war die Anbindung der zentralen Mediawiki-Installation an die LDAP-Authentifizierung. Dank der Mediawiki-Erweiterung „LDAPAuthentication“ war dies prinzipiell auch überhaupt kein Problem. Dann aber kamen seltsame Fehlermeldungen, dass Benutzer plötzlich gesperrt seien, die definitiv noch Zugang zum Wiki haben sollten. Hier muss man nun wissen, dass nicht alle Wiki-User im LDAP verzeichnet sind, sodass zusätzlich auch lokale Accounts parallel existieren müssen. Also gibt es auch unabhängig vom LDAP die Möglichkeit, Benutzer direkt in Mediawiki zu sperren.

Ein Test meinerseits ergab die schöne Fehlermeldung „Sie sind dabei sich selbst zu sperren. Wollen Sie das wirklich?“ Okay, irgendwie geraten also die User bei der Sperrung durcheinander. Aber warum? Die Lösung fand ich in den Tiefen des PHP-Codes von Mediawiki, indem ich alle beteiligten Funktionen nacheinander durchtestete. In der Datei „functions/User.php“ heißt es in der Funktion „newFromName“:

$name = $wgAuth->getCanonicalName( $t->getText() );

Der LDAP-Server wird also nach dem kanonischen Namen des Users gefragt. In der Regel einfach nur unnötig, führt es genau hier sogar zu einem sehr unerfreulichen Ergebnis: Existiert der User nämlich nicht (mehr) im LDAP, werden ungültige Werte zurückgegeben. Dies führt dann dazu, dass plötzlich ein ganz anderer User – in diesem Fall z.B. ich selbst – als „Target“ dient.

Eine Änderung der o.g. Zeile brachte dementsprechend das gewünschte Verhalten:

$name = $t->getText();

Liveblog zum 2. Halbfinale des ESC 2013

Vorab: Der Blick auf die Wettervorhersage für Samstag geht mir jeden Tag mehr auf den Zeiger! Das kann doch nicht wahr sein…

Ein jammernder roter Ballon und ein armer dünner Kerl, der in einer Umlaufbahn darum kreist. Danke Mazedonien, sehr unterhaltsam.

Oh toll, ne lesbische finnische Hupfdohlenbarbie. So, und gleich dann bitte wieder jemand der singen kann, ja? Insgesamt ist das 2. Halbfinale bislang unterirdisch!

Wollte eigentlich über den isländischen Legolas lachen, aber verdammt, der kann singen! Au ja, Griechenland mit einem Sufflied! “Alcohol is for free” – im Green Room hatten die wohl auch reichlich, hm!?

Zu Hilfe! Ist hier ein Stilberater anwesend? Er wird dringend beim israelischen Auftritt benötigt! Armenien – Der Stiefbruder von Pocahontas incl. Pornobalken! Lied geht so.

Ungarn schickt den jungen Reinhard Mey, der irgendwas über Bettwäsche singt. Albanien gefiel. Aber außer dem Sänger sollten die mal alle ne Mimikschulung machen und sich das grenzdebile Grinsen rausklöppeln.

Na also, Georgien! DAS ist ein Grand-Prix-Lied im positiven Sinne! Nun die Schweiz. Der Opi is ja cool. Sieht allerdings etwas überfordert aus. Solides Lied, nette Sängerin, von mir aus kann die Schweiz weiter. Kann mal einer dem Rumänen die Klöten zurückgeben??? Ach Du scheiße! 

Weiter kommen sollten: Island und Georgien wegen Qualität. Finnland, Schweiz und Ungarn wegen Originalität. Albanien wegen der Abwechslung.Und natürlich Rumänien, damit ich nochmal Tränen lachen kann!

Insgesamt ein zufriedenstellendes Ergebnis. Dänemark, Russland und Island sind am Samstag meine Favoriten.

Liveblog zum 1. Halbfinale des ESC 2013

Österreich seeehr langweilig. Estland optisch und künstlerisch wertvoll.

Slowenien hätte ja gut sein können – aber warum haben die nicht jemanden geschickt, der singen kann oder zumindest das Lied kennt!?

Ist das der Gierather Männergesangsverein? Nein, es ist Kroatien! Jetzt wird Dänemark gerade offenbar mein Topfavorit – geiles Lied!

Oha, ich werde doch nicht zum ersten Mal einen russischen Beitrag mögen!? Bisher nur nette Mädels auf der Bühne. Und Kroatien. Ukraine übrigens das Gegenteil von Slowenien: Tolle Sängerin, Lied eher mäßig.

Och Holland, meint Ihr das ernst? Da würd ich als Vogel auch vom Dach fallen! 

YEAH, ein Harlem Shake beim ESC!!! Ach nee, Montenegro isses…

Litauen mit Fahrstuhlmusik und miserablem Englisch – unterirdisch! Weißrussland – auauauaua! Moldawien ein wenig zu bombastisch in der Show für den dünnen Song.

Danke an Peter Urban für den Kommentar zu Irland! 😀 Jetzt bin ich auf den Low Budget Beitrag aus Zypern gespannt. 

Zypern hat wohl vor allem an der Stimme und am Kleidstoff gespart, hm? 

Ist es Sailor Moon? Ist es Prinzessin Lillifee? Nein, es ist Serbien! Prophezeihe hiermit einen Sieg für Dänemark beim ESC 2013 – zumindest nach dem 1. HF. Zudem müssen Russland und Estland weiter.

Peter Urban ist einfach der Meister! Zu Serbien: “Als wäre der Starlight-Express durch eine Konditorei gedonnert.” Schmeiß mich weg…

Was die “Halftime”-Show betrifft sollten sich die Damen und Herren des ESC mal dringend Tipps bei den Superbowl-Organisatoren holen. 

Da sind aber böse Dinger durchgerutscht! Litauen, Weißrussland, Irland, Holland, … Naja, hauptsache Dänemark und Estland dabei!

Prüfung von Sicherheitszertifikaten

Die Prüfung der von Servern verwendeten Zertifikate hinsichtlich ihrer Gültigkeit  und Vertrauenswürdigkeit ist heutzutage ein elementarer Bestandteil der persönlichen Sicherheit im Internet. Viel zu oft werden solche Hinweise zwar einfach weggeklickt, spätestens bei Shops, die die Angabe der Konto- oder Kreditkartendaten erfordern, und erst recht beim Online-Banking sollten aber wirklich alle Internetnutzer misstrauisch werden, sobald der Browser eine entsprechende Warnung anzeigt.

Aus diesem Grund ist auch die Uni Köln seit Jahren einer Certificate Authority angeschlossen, die in allen gängigen Browsern und Mailclients als vertrauenswürdig bekannt ist, namentlich der Root-CA der Deutschen Telekom. Denn auch an der Uni müssen z.T. sehr vertrauliche Daten über das Netz geschickt werden, z.B. Prüfungsergebnisse, Accountdaten oder auch E-Mails.

Umso wichtiger ist es, dass die entsprechende Prüfung der gemeldeten Sicherheitszertifikate möglichst automatisiert und zuverlässig erfolgt. Hierfür gibt es ein eigenes Netzprotokoll, das „Online Certificate Status Protocol“ (OCSP). Es prüft automatisch die Gültigkeit des vom aufgerufenen Server gesendeten Zertifikates. Dies ist leider nicht bei allen Browsern und Mailclients korrekt voreingestellt. Zum Teil wird nur auf den Servernamen geprüft, zum Teil aber auch gar nicht. Wir möchten daher hier für die wichtigsten Programme kurz beschreiben, wo die korrekten Einstellungen vorzunehmen sind.

Mozilla Firefox / Mozilla Thunderbird
Bei den beiden Mozilla-Programmen finden sich die Einstellung in einem übersichtlichen Menü unter „Einstellungen“ → „Zertifikate“ → „Validierung“.

Google Chrome
In Chrome muss unter „Einstellungen“ → „Erweiterte Einstellungen anzeigen“ → „HTTPS/SSL“ ein Häkchen bei „Serverzertifikate auf Sperrung prüfen“ gesetzt werden.

Internet Explorer / Windows Mail / Outlook
Alle drei sind fest mit dem Windows-Zertikatspeicher verbunden, den man im Internet Explorer unter „Extras“ → „Internetoptionen“ → „Inhalte“ → „Zertifikate“ erreicht (die Menüfolge mag in den verschiedenen Versionen etwas anders sein). OCSP wird von Windows erst seit Vista – und damit auch in Windows 7 und 8 – unterstützt, für XP fehlt die Funktion leider. Die Aktivierung erfolgt in „Extras“ → „Internetoptionen“ → „Erweitert“ und umfasst die Einstellungen „Auf gesperrte Zertifikate überprüfen“ und „Auf gesperrte Zertifikate von Herausgebern überprüfen“.

Apple Safari
Safari nutzt den zentralen Schlüsselbund von MacOSX. Diesen erreicht man in der Regel über das Anwendungsmenü im Bereich „Utilities“ oder „Werkzeuge“. Innerhalb des Schlüsselbunds kann man im Menü „Einstellungen“, Karteireiter „Zertifikate“ die passenden Einstellungen wählen. In aller Regel ist dies bei OCSP und CRL jeweils „Bester Versuch“, die Priorität sollte auf OCSP liegen.

Opera
In Opera (ab Version 9) muss man den Umweg über die Seite „about:config“ im Browser gehen. In den „Security Prefs“ kann man den Eintrag bei „OCSP Validate Certificates“ ändern. Da dieser aber standardmäßig aktiviert ist, muss man in der Regel nichts ändern.