Da denkt man an nichts böses und will nur mal eben eine aktualisierte Software auf dem Server einspielen. Eigentlich keine größere Sache sollte man meinen, sind doch die aktuellen Linux-Distributionen allesamt mit einem Paket-Management-System ausgestattet, das es erlaubt Software recht einfach zu installieren und zu warten. Wenn alles glattläuft, wie gesagt, wenn …

Angefangen hat alles mit einer Fehlermeldung, dass in einem Webinterface die Bilder nicht angezeigt werden. Im Hintegrund werkelt ein PHP-Skript, das die Bilder bei Bedarf auf die passende Größe runter sakliert – das senkt den Bandbreitenbedarf und die Übetragungszeiten für eine Website. Zudem hat man dann als Autor noch ein wenig mehr Einfluss auf die Qualität – die Skalierungsmechanismen der verschiedenen Browser sind nicht alle wirklich gut.

Ursprünglich habe ich mal auf die integrierte GD-Bibliothek von PHP gesetzt allerdings musste ich recht bald schon feststellen: Die ist für einfache Dinge ganz brauchbar (und in den meisten Fällen auch einfach schon vorhanden), aber die Performance ist nicht unbedingt berauschend. Gerade aber für die Erstellung von Bildergalieren on-the-fly ist die Performance (oder die Ungeduld des Benutzers) wichtig. Fündig geworden bin ich bei der Imagick-Erweiterung für PHP. Diese basiert auf der ImageMagick-Bibliothek. Diese hat den Vorteil direkt in C geschrieben zu sein und die Performance macht echt Freude. Zudem sind die Möglichkeiten doch mittlerweile sehr ausgefeilt.

Wie nahezu jede Software hat sich auch Imagick weiterentwickelt und damit gab es einige Veränderungen an den Schnittstellen und Funktionen – daher funktioniert die Bilder-Skalierung nicht mehr wie gewünscht: Auf dem Testserver hatte ich eine aktuellere Version installiert und auch auf dieser Basis programmiert – mit der älteren wollte das nicht so recht harmonieren, es fehlten einfach ein paar Funktionen bzw. diese wurden verändert und teilweise umbenannt.

Nun gut, dann aktualisiert man doch einfach auch mal das produktive System. Da mein Hosting-Anbieter zum Installationszeitpunkt nur die Wahl zwischen Plesk (alles vorgefertigt und Clicki-Bunti) oder CentOS 5 minimal geboten hatte, habe ich mich notgedrungen für CentOS als RedHat-Devirat entschieden, denn auf einigen Komponenten möchte ich doch gerne etwas mehr Einfluss nehmen als es Plesk von Hause aus zulässt (Stichwort Mailserver, Virenscanner und Authentifizierungsmethoden). CentOS ist ein Unternehmenslinux und das merkt man – hier wird viel Wert auf stabile und sichere Software gelegt, weniger darauf die aktuellsten Funktionen bereit zu halten. Als Folge habe ich damals schon einige Software von Hand kompiliert und installiert – eine Zeit lang hatte ich ja auch mit Linux from Scratch gearbeitet – also kein wirkliches Neuland für mich. Allerdings klappt es nicht immer auf Anhieb, die Software selbst zu installieren und nur bestimmte Teile direkt wie geliefert zu verwenden. Aber es hat ja am Ende alles funktioniert. Nur mit den Updates muss man dann halt vorsichtig sein.

Das letzte Update ist denn auch irgendwo mal stecken geblieben. Als Folge davon gab es noch nicht vollendete Transaktionen des Paket-Managers (yum) – mit

yum-complete-transaction

lässt sich soetwas auch beheben. Nur ärgerlich wenn das auch nicht klappt, weil dem virtuellen Server mal wieder der Arbeitsspeicher ausgeht – also erst mal einige Server-Prozesse stoppen, und dann das Update machen … Immerhin läuft es dann auch durch. Auch wenn noch ein paar Klippen wie beschädigte Repository-Datenbanken zu beheben sind.

Wie sich herausstellt: Leider ist mit den verwendeten Quellen / Repositories keine aktuellere Version von Imagick zu bekommen. Aber es gibt ja alternative Quellen wie das Remi-Repository – dort finden sich viele Pakete aktuellerer Software als in den offiziellen Quellen von CentOS. Das führt ggf. zu doppelten und widersprüchlichen Paketen und Abhängigkeiten die sich im Kreis drehen. Mit ein wenig Nacharbeit kann man diese Abhängigkeiten aber auflösen, indem man explizit vorgibt, welche Version aus welcher Quelle man denn nun haben möchte. Damit lässt sich schon mal die aktuelle Fassung von ImageMagick installieren (das Paket dazu im Remi-Repository heißt ImageMagick2).

Wie ich bereits geschrieben hatte, habe ich einiges an Software selbst kompiliert – unter anderem PHP, da es das von Haus aus bei CentOS nicht mit den Erweiterungen und Einstellungen und vor allem in einer aktuellen Fassung gab. Das macht mir natürlich jetzt etwas Probleme, denn die Imagick-Erweiterung lässt sich nicht so ohne weiteres per Paket-manager installieren. PHP hat dafür mittlerweile etwas vergleichbares wie einen Paket-Manager – nur auf Quellcode-Basis mit automatischer Kompilierung. Vergleichbar ist das mit dem CPAN-Archiv von Perl – auch dort werden viele Module für Perl bereit gehalten und lassen sich damit auch problemlos installieren und auf dem aktuellen Stand halten. Bei PHP heißt das Tool dazu PECL (PHP Extension Community Library), zudem gibt es noch PEAR (PHP Extension and Application Repository) – beide arbeiten recht gut zusammen und machen das Leben mit PHP um einiges leichter.

PECL ist das richtige Stichwort – es bietet unter anderem auch die Option die Imagick-Erweiterung zu installieren. Leider ist die Freude erst mal nur kurz – das verwendete PHP-Modul wird weiterhin gegen die veraltete Version (6.2.x) von Imagick gelinkt. Klar die hatte ich ja nicht deinstalliert, denn das Package ImageMagick2 darf parallel zu ImageMagick installiert sein. Also das alte endlich mal loswerden und per Paket-Manager deinstallieren. Aber oh Wunder – PECL kann auf einmal das Modul nicht mehr bauen….
Lösung: Es fehlten die notwendigen Header-Dateien zum Paket ImageMagick2 – das Paket dazu heißt praktischerweise ImageMagick2-devel (für development-version) – das bringt die Header mit, im normalen Betrieb werden die nicht benötigt, nur wenn man eben selbst Software unter Verwendung der Library schreiben oder kompilieren möchte.
Damit klappt dann auch endlich die Kompilation des aktuellen Modules. Nochmal den Webserver neu starten und dann funktioniert auch endlich die ursprünglich gewünschte Anzeige der Bilder. 🙂
Mittlerweile ist es mal wieder kurz vor 0:00h geworden, aber die Mühe und der Bastelaufwand waren ja vom Erfolg gekrönt.

Nur noch kurz testen ob auch sonst alles auf dem Server noch richtig läuft – beim Update wurden ja doch auch einige andere Pakete gleich mit aktualisiert. Und – oh Schreck! – der Mailserver mag nicht … genauer gesagt, das Filter-Daemon amavisd kommt nicht mehr richtig in Gang. Amavisd ist die zentrale Schnittstelle zwischen Mailserver und diversen Viren und Spam-Scannern. Ohne die Software, kein e-mail-Vekehr.
Der Neustart von Amavisd bringt die Ursache recht schnell an den Tag: Da sind einige Perl-Module beim Update zu Bruch gegangen, wahrscheinlich, weil sie in verschiedenen Versionen installiert wurden – einmal per CPAN und einmal per Paket-Manager der Distribution (leider sind sich diese beiden Werkzeuge in den seltensten Fällen wirklich grün). Das manuelle Entfernen der Module aus der Installation bringt auch das wieder ins Lot.

Nun stellt sich nur noch der Virenscanner Clam-AV etwas bockig – das Scanner-Daemon will und will nicht starten – Ursache ist diesmal aber nicht die Software sondern leider mal wieder die Beschränkungen der Virtualisierung – zum Starten braucht Clamd recht viel Arbeitsspeicher: ca. 100 Megabyte – bei nur 768 MB virtuellem RAM kann es aufgrund der anderen Prozesse wie MySQL, Apache, Postfix usw. da recht bald recht eng im Speicher werden. Da MySQL sich doch auch recht gut im Speicher breit macht (klar Cache braucht nunmal Platz) ziehe ich dort die Daumenschrauben ein wenig fester an, dann reicht es auch noch für den Start von Clamd – aber gut ist diese Lösung auf Dauer nicht, ich werde wohl oder übel einen anderen Server brauchen, ob es wieder ein virtualisierter wird, weiß ich noch nicht so genau. Auf alle Fälle machen derartige Nachschichten nicht wirklich Spaß