Obwohl es bereits ein Debian 6 “Squeeze” gibt, sind noch viele Debian 3 und vor allem Debian 4 (etch) im Produktiveinsatz. Insbesondere Etch ist noch weit verbreitet, weil es wegen seiner Stabilität und Härtung gegen Hackerangriffe bei Admins sehr beliebt war. Von Hause aus boten unzählige Hoster/Rechenzentren Mietserver mit Repositories für Debian 4 an.
Eine nur schwer zu schätzende Menge dieser Server ist bis heute im Produktiveinsatz, obwohl Debian die Unterstützung/Support/Updates für Etch inzwischen eingestellt hat. Solche Server haben häufig eine gewachsene Historie, auf die es Rücksicht zu nehmen gilt. Oft bieten die Server spezielle Dienste und Services oder beherbergen einfache Joomla oder WordPress-Installationen von Kunden, die nicht ohne weiteres ein Update des komletten Linux-Unterbaus vertragen. Manchmal mag es auch einfach darum gehen, dass man einen mühselig kompilierten und konfigurierten Postfix-E-Mail-Server, der brav und klaglos seine Dienst tut, einfach nicht aufgeben möchte.
Das Problem
Auf einem Debian 4.0 “Etch” Linux-Server im “LAMP” (Linux, Apache, mySQL, php) werkelt das standardmäßig mit Etch aufgelieferte php 5.2.0. In der Regel sollte es sich um einen Rechner ähnlich dieser Konfiguration handeln:
- Debian 4.0 Etch 32 Bit (Zum Beispiel lange Jahre von Hetzner angeboten)
- Apache 2.2.3
- mySQL 5
- php 5.2.0-8+etch16 (oder sehr ähnlich)
Nun verlangt eine WordPress- oder Joomla-Installation ein Update von php auf mindestens Version 5.2.4., aber ein beherztes
apt-get update php
liefert aber bei normalerweise erreichbaren Debian “etch” Repositories maximal Version 5.2.0. An eine höhere php-Version kommt man nicht heran. Über eine WordPress-Version von 3.1.4 hinaus kann man nichts installieren. Viele Ajax-Funktionalitäten bleiben dem Admin verschlossen und es verbleibt immer das ungewisse Gefühl ein Webserver mit scheunentorweit geöffneten Sicherheitslücken zu betreiben.
Die Lösung(en)
Erstes mittel der Wahl sollte eigentlich sein, ein zweites System aufzusetezen, Ubuntu oder Debian Squeeze zu installieren, alle Dienste und Services nachzubauen, und mit dem WordPress auf dieses neue System zu migrieren. Leider bedeutet dies einen Heidenaufwand.
Eine Alternative wäre, sich den Sourcecode von php 5.x.x runterzuladen, sich um eine schiere Unmenge an Anhängigkeiten zu kümmern und sich sein ganz persönliches auf sein System zugeschnittenes php zu kompilieren. Vorweg: Das ist eine Unmenge von Arbeit, die sich in der Regel kaum lohnen und auch nur Experten vorbehalten sein sollte. Auch für ein laufendes Produktivsystem nicht das Mittel der ersten Wahl.
Doch es gibt eine – zwar nicht nicht risikofrie, aber gangbare – Methode: Das Einspielen von bereits vorkompilieren php-Komponenten aus vertrauenswürdigen Drittquellen. Um eben diese Methode soll es im weiteren gehen.
Schritt für Schritt
Ich übernehme keine Verantwortung für die Folgen der nachfolgend aufgeführten Beschreibung. Bei mir hat’s super funktioniert, wenn Ihr Euer System damit zerschießt und einen Schaden habt, ist das Euer Pech und liegt nicht in meiner Verantwortung.
Zuerst kopiert man sich mal aus den Archiven von dotdeb https://archives.dotdeb.org/dists/etch/php5/ die gewünschte php-Version. Download-Them-All (Plugin für den Feuerfuchs) hilft dabei. Man braucht anschließend den Inhalt der Ordner binary-i386/ und source/ der gewünschten php-Version. Für ein System wie oben beschrieben und eigentlich nur der Notwendigkeit auf 5.2.4 zu updaten, habe ich mich dennoch für einen Umstieg auf 5.2.12 entschieden. Meinem Verständnis nach ist das Risiko genau dasselbe, dann kann man auch einen Sprung auf die höchste mögliche Version wagen. Für das Debian 4.0 und den oben beschrieben Softwarekomponenten auf einem 32-Bit-System php-Version 5.2.12/
Das weitere Vorgehen ist im Prinzip folgendes. Aus den gerade heruntergeladenen Paketen, erstellt man sich sein eigenes Repository, das man temporär online erreichbar macht. Danach weist man mit Apt auf eben dieses selbst erstelle Repository und installiert anschließend das bereitliegende php 5.2.12. Das Vorgehen ist weitestgehend trivial, erfordert aber trotzdem Aufmerksamkeit. Außerdem braucht man:
- Textkonsole/root-Zugang – putty ist bereits okay
- Installiertes Debian Paketmanagement – Paket: “dpkg-dev”
- apt-get oder aptitude (ich gehe von apt-get aus)
- etwas Webspace
- ein kühles Getränk (optional)
- ruhige Nerven (obligatorisch)
Per Textkonsole legt man im Webspace die Verzeichnisse für das eigene Repository an, das anschließend eigentlich nur das php-Paket enthalten wird.
cd /var/www (oder wo immer bei Euch die HTML-Daten liegen)
mkdir mein-repository
cd mein-repository
mkdir binary
mkdir source
Natürlich darf man die Verzeichnisse auch mit dem midnight-commander (mc) anlegen.
Jetzt kopiert man alle zuvor heruntergeladenen .deb Dateien in den Ordner “binary” und die restlichen in “source”.
Auch dabei kann man sich wieder gut des mc bedienen.
Das Repository ist fast fertig. Wir müssen nur noch Dateien mit der Struktur anlegen. Dabei hilft uns die Debian-Paketverwaltung.
cd mein-repository
dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz
Kleiner Hinweis für Tippfaule und alle die sichergehen wollen, sich nicht zu vertippern und mit putty arbeiten: Kopiert Euch die Zeilen hier einzeln in die Zwischenablage. Mit einem Rechtsklick fügt ihr sie in Putty in die Textkonsole ein. Return führt die Befehle aus. Sie erzeugen ein zusätzliche gezippte Index-Dateien in den Ordnern “binary” und “source”.
Es darf keine Fehlerausgaben hierbei geben.
Jetzt wechselt man zu /etc/apt (oder wo immer Eure sources.list liegt) und bearbeitet dort die Datei sources.list. ich habe zuerst alle anderen Quellen mit “#” auskommentiert und anschließend die folgenden zwei Zeilen eingetragen:
deb https://myhost.com/~cc/mein-repository binary/
deb-src https://myhost.com/~cc/mein-repository source/
Damit sind die Vorbereitungen abgeschlossen.
Finale
Bis hierher wurde am laufenden System eigentlich noch nichts geändert. Meine Mama würde an dieser Stelle sagen: “Jetzt kommt der spannende Augenblick, in dem der Elefant das Wasser lässt…”
Wir lassen apt unser Repository lesen:
apt-get update
Wer will, kann mal nach “php” im Repository suchen – muss aber nicht sein.
apt-cache search php
Aber die Ausgabe fördert zutage, dass es gilt, nun das Paket php5 mit all seinen Anhängigkeiten zu installieren.
apt-get install php5
Die Sicherheitsabfrage, ob man php5 installieren will, bejaht man mit “y”. Ebenfalls mit “y” bestätigt man sein Einverständnis zur unsicheren Quelle. Während nun die Installation abläuft wird man höchstwahrscheinlich danach gefragt, ob man bestehende php.ini- und apache-mod-ini-Files behalten oder durch die im Pkate enthaltenen ersetzen will. Natürlich gab es in der Vergangenheit gewiß schon mal Änderungen an des besagten Files, aber wer sich nicht sicher ist, was er tut und dem auch die Möglichkeiten zum Vergleich fehlen, sollte hier die vom Paketherausgeber vorgebenen ini-Files nutzen. Notfalls muss man eben die alten ini-files zuerst mithilfe einer zweiten Konsole kopieren und später händisch notwendige Änderungen vornehmen. Bei mir war das übrigens augenscheinlich nicht nötig.
Das sollte es gewesen sein!
Aufräumen
Bei mir ließ sich anschließend problemlos WordPress in der aktuellen Version installieren. Eine Ausgabe der phpinfo() zeigt nun als Versionsnummer: PHP Version 5.2.12-0.dotdeb.0 Es ist vollbracht. Ich habe den Apachen nochmal neu gestartet und den Ordner “mein-repository” aus dem Webordner entfernt.