Frohe Ostern: Die Debian-Version 4.0 ist seit 8. April draußen. Als stabile Version löst Etch – so der „Codename“ – nach 22 Monaten den Vorgänger Sarge (Version 3.1) ab. Da ich gerade einen bei Strato stehenden „Rootserver“ (gemeint ist ein Webserver mit Root-Rechten) neu aufsetzen musste, war das die beste Gelegenheit, ein Upgrade – unter zugegeben stark vereinfachten Bedingungen – durchlaufen zu lassen: Der Server war zu diesem Zeitpunkt nicht im Produktivbetrieb und wurde zuvor mit einem Basis-Image von Sarge reinitialisiert.

Mit dem Versionssprung um eine volle Stelle auf 4.0 (statt nur von 3.0 nach 3.1 wie beim Upgrade von Woody auf Sarge) bringt Debian für ein stinknormales LAMP-System endlich „amtliche“ Pakete für PHP5 und MySQL5 mit. Nur mal zur Erinnerung: PHP5 gibt’s seit fast drei Jahren, MySQL5 auch schon seit eineinhalb Jahren, aber beide bislang nicht offiziell in Debian stable.

Die meisten Anbieter dedizierter Webserver halten mehrere Basis-Images bereit, mit denen sich ein Server jungfräulich installieren lässt. Standard ist inzwischen, dass der Kunde die Neuinstallation aus der Ferne anstoßen kann, ohne dass der Support bemüht werden müsste und Kosten anfallen. Bei Strato installierte ich also ein nacktes Image von Debian Sarge (Etch ist dort wie bei den meisten Anbietern noch nicht im Angebot) – mit „nackt“ meine ich: ohne irgendwelche Scherze wie Serveradmin24 oder Plesk; die Einspielung wurde innerhalb einer Stunde als „abgeschlossen“ gemeldet. Auf dem System lief bereits SSH, so dass eine sichere Verbindung aus der Ferne möglich war. Sonst wird die Installation mit

ego@etchy#apt-get install openssh-server

in Gang gebracht.

Ohne viel Federlesens ging’s sofort ans Upgrade. Dazu galt es zunächst, die Installationsquellen anzupassen. Dazu öffnet man bei Debian die Datei /etc/apt/sources.list mit einem Editor seines Vertrauens. Nun alle Vorkommnisse von „Sarge“ auf „Etch“ umändern. Einträge, die auf „stable“ lauten, sind auch okay. Denn seit dem Versionswechsel fungiert Etch, das zuvor noch „testing“ war, als „stable“ und Sarge, bisher „stable“, gilt nunmehr als „oldstable“, ein Schicksal, dass „Etch“ in ein, zwei Jahren auch ereilen wird, wenn nämlich „Lenny“ stabil wird. Wer das zu verwirrend findet, verwendet konsequent in seiner Sources-Datei „Etch“.

Nachdem die Sources derart angepasst sind, kann auch schon das Debian-Installationswerkzeug apt auf die Bühne gebeten werden:

ego@etchy#apt-get update

liest die neuverfügbaren Pakete ein und ein beherztes

ego@etchy#apt-get dist-upgrade

sorgt dann für den Sprung in die nächste Debian-Generation.

Wie gesagt: Das ging alles sehr flüssig von der Hand, war aber auch kein großes Problem, da ja nur eine Basisinstallation von Sarge vorhanden war. Wer ein System mit mehr Paketen, gar mit X-Server upgraden will, hat sicher mehr Nüsse zu knacken. Einziges Problem bei meinem Strato-Server: Der Kernel blieb auf der Version 2.6.8-3 hängen; ein Update per

ego@etchy#apt-get install linux-image-2.6.18-4-486

zeitigte keine Wirkung. Das steht noch auf der Todo-Liste.

Zwischenstand: Ein Blick auf die nach dem Upgrade nach außen hin sichtbaren Dienste mit

ego@etchy#lsof -i


förderte ein gutes Ergebnis zu Tage: Mit dhcpd, ntpd, exim4 und ssh guckten wirklich nur jene Dienste ins wilde Internet hinaus, die auch wirklich gebraucht werden. Wer hier – zu diesem Installationszeitpunkt – mehr zu laufen hat, sollte schleunigst ans Abspecken gehen, wenn es keinen guten Grund für die Neugier dieser Dienste gibt: Es sind lauter potentielle Einfallstore.

Da wir beim Thema Sicherheit sind: Allgemein wird empfohlen, für den SSH-Zugriff einen Login von Root zu verbieten. Für diese und andere Einstellungen öffnet man per Texteditor die Konfigurationsdatei unter

etc/ssh/sshd_configure

Die fragliche Konfigurationszeile lautet dann

PermitRootLogon no


Achtung: Über den adduser-Dialog sollte man vorher aber unbedingt einen weiteren Nutzer-Account eingerichtet haben, sonst sperrt man sich als root aus dem eigenen Rechner aus! Root-Rechte für die weitere Installation kann man sich dann in bekannter Manier per

ego@etchy#su

verschaffen.

Für das Email-Wesen bevorzugen viele Administratoren Postfix statt des Debian-Standards Exim. Ich bin da leidenschaftslos. Angesichts von Spam-Fluten und Mail-Server-Attacken fehlt mir ohnehin der Ehrgeiz, einen eigenen Mailserver zu betreiben. Da vertraue ich lieber einem zuverlässigen Dienstleister, der Gigabyte-große Email-Postfächer bereitstellen kann und zudem ein ordentliches Domain-Management samt günstiger Domainpreise mitbringt. Aus eigener Erfahrung empfehle ich hier die Firmen Domainfactory und Host Europe (nachfolgend Provider B genannt), so dass im Zusammenspiel mit dem Hoster, der den Webserver bereitstellt (Provider A), folgendes Szenario möglich ist:

• Domains lässt man von Provider B verwalten und nutzt auch dessen Nameserver.
• In der DNS-Verwaltung ändert man den A-Record so ab, dass er auf die IP des Webservers bei Provider A zeigt.
• Den MX-Eintrag für die E-Mail lässt man so, wie er ist, um den bei Provider B vorhandenen Email-Server zu nutzen.

Wichtig ist bei dieser Konstellation, Exim auf dem eigenen Webserver so zu entschärfen, dass er keine Mails von außen annimmt, sondern nur noch interne Systemmails an den Administrator zustellt. Da ich gelegentlich auch per Skript Mails versenden will, muss Exim sie allerdings hinaus senden können. Im Konfigurationsdialog von Debian, der jederzeit wieder mit

ego@etchy#dpkg-reconfigure exim4-config

aufgerufen werden kann, habe ich deshalb die Basis-Funktionalität „Internet-Server“ gewählt und eingehende SMTP-Verbindungen auf die lokale IP 127.0.0.1 beschränkt.

Endlich kann es nun an die Installation der eigentlichen LAMP-Bestandteil gehen – A wie der Webserver Apache, M wie der Datenbankserver MySQL und P wie die Scriptsprache PHP (andere mögen hier auch Perl oder Python einsetzen). Ein simples

ego@etchy#apt-get install apache2 php5 mysql-server-5.0


installiert fast alle gewünschten Pakete auf einen Rutsch. Sehr löblich: statt für MySQL einen root-Account ohne Passwort zu erstellen, fragt der Installationsdialog nun endlich explizit nach einem Passwort. Hier die mit dem zuvor genannten apt-get-Befehl installierten Pakete:

Die folgenden zusätzlichen Pakete werden installiert:
apache2-mpm-prefork apache2-utils apache2.2-common libapache2-mod-php5
libapr1 libaprutil1 libdbd-mysql-perl libdbi-perl libexpat1
libmysqlclient15off libnet-daemon-perl libplrpc-perl libpq4 libsqlite3-0
libxml2 mime-support mysql-client-5.0 mysql-common php5-common ucf
Vorgeschlagene Pakete:
php-pear dbishell libcompress-zlib-perl tinyca
Empfohlene Pakete:
xml-core debconf-utils
Die folgenden NEUEN Pakete werden installiert:
apache2 apache2-mpm-prefork apache2-utils apache2.2-common
libapache2-mod-php5 libapr1 libaprutil1 libdbd-mysql-perl libdbi-perl
libexpat1 libmysqlclient15off libnet-daemon-perl libplrpc-perl libpq4
libsqlite3-0 libxml2 mime-support mysql-client-5.0 mysql-common
mysql-server-5.0 php5 php5-common ucf
0 aktualisiert, 23 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Wie gesagt: Das sind fast alle gewünschten Pakete. Bislang „sieht“ PHP MySQL noch nicht; das holen wir nach mit

ego@etchy#apt-get install php5-mysql

Auf demselben Weg lassen sich nach Wunsch weitere PHP-Pakete wie zum Beispiel die Grafikbibliothek php5-gd nachinstallieren.

Ob PHP richtig konfiguriert ist, lässt sich einfach überprüfen, indem man in jenem Verzeichnis, aus dem der Apache die Web-Seiten serviert – standardmäßig /var/www – eine Datei irgendeinname.php anlegt, die folgenden simplen PHP-Code zum Inhalt hat:

<? phpinfo(); ?>

Ein Aufruf von http://www.meinedomain.de/irgendeinname.php sollte nun dank des Befehls phpinfo() eine detaillierte Ausgabe der aktuellen PHP-Konfiguration ausspucken. Das hilft beim Troubleshooting: Dem zuvor fehlenden Paket php5-mysql ließ sich zum Beispiel auf die Spur kommen, weil in phpinfo() zunächst jeglicher Hinweis auf MySQL fehlte, obwohl es ordentlich installiert war.

Ein typischer Fehler ist auch, dass statt der Ausgabe von phpinfo() der Quellcode der Datei angezeigt wird: Ein untrügliches Zeichen dafür, dass zwar der Apache-Webserver läuft, dieser aber nicht den PHP-Interpreter anwirft. Typischerweise wäre dann zu prüfen, ob das PHP-Modul wirklich eingebunden ist. Die Einbindung eines jeglichen Apache-Moduls erfolgt unter Apache 2/Debian Etch, indem man einen Symlink in /etc/apache2/mods-enabled ablegt, der auf das Modul in /etc/apache2/mods-available zeigt. Ganz einfach erledigt dies auch das Skript a2enmod. Im Falle von PHP tut es der Befehl:

ego@etchy#a2enmod php5

What’s new? Wer zuvor eine orthodoxe Sarge-Installation mit den offiziellen PHP4-Paketen betrieb, muss darauf gefasst sein, dass durch das Upgrade auf PHP5 der Programmcode anzupassen ist. Auf ein solches Risiko lässt sich niemand ein, ohne seine Skripte zuvor in einer Testumgebung auf Herz und Nieren geprüft zu haben. Wer zuvor schon PHP5-Pakete von Backports oder Dexter verwendet oder wer gar sein PHP5 selbst „gebacken“ hat, bekommt solche Probleme nicht mehr und braucht zudem dank Etch auch keine Installations-Verrenkungen mit inoffiziellen Paketen mehr zu unternehmen.Neu ist, dass Debian Etch standardmäßig UTF8 verwendet. Das ist gut, sorgt aber für Probleme, wenn man vorher mit Latin-Zeichensätzen gearbeitet hat. Debian stellt deshalb ein Konvertierungswerkzeug bereit, das bisher nach User-Berichten allerdings nicht ganz problemlos arbeitet. Wenn es nur darum geht, dass Umlaute auf Webseiten falsch dargestellt werden, dann hilft auch eine Modifikation an der Hauptkonfigurationsdatei des Webservers /etc/apache2/apache.conf: Die Zeile

#AddDefaultCharset ISO-8859-1

muss auskommentiert werde – mit anderen Worten: die Raute muss weg.

Etwas tricky ist das MySQL-Upgrade, sofern bisher die bei Sarge serienmäßigen MySQL-4.1-Pakete installiert waren. Damit verfügt man noch über Datenbanken, die die alte Passwort-Verschlüsselung verwenden. Seit der krummen Versionsnummer 4.1.13 benutzt MySQL aber eine verbesserte Verschlüsselung. Passwort-Felder haben nun eine Länge von 41 statt bisher 16 Zeichen und beginnen immer mit einem * (Sternchen). Das kann beim Einspielen alter Datenbanken auf die mit Etch installierte neue Serverversion und dann beim Zugriff alter MySQL-Clients (wie in PHP4) auf den neuen MySQL-Server Probleme bereiten.

Hier sprudelt ein echter Problemquell, wenn PHP-Skripte über die alte mysql-Bibliothek (die neue unter PHP5 heißt mysqli) die MySQL-Funktion PASSWORD() benutzen, um beispielsweise Nutzern einen Login zu einem geschützten Bereich zu ermöglichen: Auf einmal ist dann der Zugang nicht mehr möglich, obgleich man doch das „richtige“ Passwort eingegeben hat!

In einem solchen Fall könnte man seine Scripte anpassen, indem überall PASSWORD() mit OLD-PASSWORD() ersetzt wird: MySQL nutzt in diesem Fall ein Hashing im alten Stil, also mit 16 Bytes langen Passwörtern. Schnelle und generelle Abhilfe schafft eine Ergänzung der MySQL-Konfigurationsdatei /etc/mysql/my.cnf: Im Abschnitt [mysqld] hängt man eine Zeile mit dem Eintrag old_passwords an. Auf einem anderen Server, auf dem ich Ubuntu völlig neu aufsetzte, nutzte dieser Eintrag alleine noch nichts, weil sich das Installationsskript vorwitzig eingemischt hatte: Unter /etc/mysql/conf.d/ lag eine Datei namens old_passwords.cnf, die meine Direktive überschrieb:

# created by debconf
[mysqld]
old_passwords = false

Ein true statt false brachte auch diesen Server wieder dazu, alte Passwörter zu verwenden. Trotzdem: Ein solcher Rückgriff sollte nicht mehr als eine vorübergehende Abhilfe sein, denn schlecht verschlüsselte Passwörter bedeuten weniger Sicherheit.