Umstieg auf Linux

“It works!” steht da in großen Lettern, wenn ich die Webseite des Ubuntu Servers aufrufe. Für ein Software-Projekt möchte ich mit Kerberos experimentieren. Da ich eine PHP-Seite entwerfen soll, bei der sich Kerberos-Clients anmelden können sollen, brauche ich ein Kerberos-Plugin für PHP.

Das lässt sich beim Apache Webserver mit dem Befehl sudo apt-get install libapache-mod-auth-kerb erledigen. Dabei wird notfalls krb5-config und libapache2-mod-auth-kerb mitinstalliert. Ein beherztes sudo /etc/init.d/apache2 restart aktiviert die neu installierten Module. Der Webserver sagt weiterhin “It works!”, aber die Frage ist, was er mit “it” meint. Sicherlich funktioniert Apache noch, aber wer weiß, ob Kerberos jetzt funktioniert?

Zunächst hat mein Server ein Problem mit der IP-Adresse. Er kann keinen Servernamen finden und verwendet den Loopback-Adapter 127.0.1.1 als Default. Den Servernamen kann man mittels sudo nano /etc/apache2/httpd.conf angeben. Danach verschwinden die Warnungen. Man verwendet vielleicht den am besten gleichen Namen wie in /etc/hostname angegeben.

Die angezeigte Seite, die “It works!” ausgibt, ist lediglich eine statische HTML-Seite. Das beweist noch nicht einmal, ob PHP überhaupt funktioniert. Eine einfache Datei /var/www/phpinfo.php mit dem Inhalt <? phpinfo(); ?> gibt eine Informationsseite aus. Irgendwo gibt es einen Abschnitt namens “Loaded Modules”, der die installierten Module auflistet. Dort taucht nach der Installation ein mod_auth_kerb auf, was auf eine erfolgreiche Installation des Kerberos Moduls hindeutet. Jetzt fragt sich natürlich, wie man Kerberos vernünftig benutzt.

Die Bibliothek PEAR scheint der richtige Ansatz zu sein. PEAR bringt eine Klasse Auth mit, mit welcher sich Kerberos Authentifizierungen durchführen lassen. PEAR ist bei Ubuntu 8.10 Server nicht standardmäßig dabei, lässt sich aber über ein einfaches sudo apt-get install php-pear nachrüsten.

Mein kleines PHP-Kerberos-Testscript funktioniert leider nicht. Die Funktion require_once(“Auth.php”); beschwert sich, dass Auth.php nicht aufzufinden ist. Eine Durchsuchung der Festplatte zeigt: die Datei Auth.php existiert lediglich im Verzeichnis /usr/share/php/PEAR/Command. Dieses Verzeichnis ist aber nicht Bestandteil des Include-Pfades von PHP. Eine kurze Recherche sagt mir, dass man die Bestandteile von PEAR einzeln installieren muss. In diesem Fall also sudo pear install Auth. Jetzt erscheint eine neue Fehlermeldung: “Cannot use Kerberos V authentication, KADM5 extension not loaded!”

Leider funktioniert sudo apt-get install php-kadm5 nicht. Ein sudo apt-get install krb5-admin-server bringt jedoch neue Erkenntnisse: vermutlich habe ich jetzt einen Kerberos Server installiert, der mir früher oder später nützlich sein wird, wenn ich mich tatsächlich irgendwo anmelden möchte.

Für heute muss ich meine Untersuchungen abbrechen. Ich bin schon deutlich schlauer und meinem Kerberos-AFS Projekt einen Schritt näher. Am Ende soll übrigens eine Überprüfung von AFS-Freigaben entstehen. Der User kann per Weboberfläche Berechtigungen festlegen, deren Einhaltung per Cron-Job überprüft wird.

Heute hat sich die Situation ergeben, dass ich eine etwas ältere Hardware zur Verfügung habe. Es handelt sich um einen Pentium III mit 666 MHz, 128 MB RAM und 20 GB Festplatte. Da mir 128 MB RAM selbst für einen Ubuntu Server etwas enig vorkamen, habe ich auf 384 MB aufgestockt.

Meine ursprüngliche Idee war, Ubuntu 8.10 Server direkt zu installieren. Da mir aber eine Ubuntu 7.10 Server CD gerade zwischen die Finger gekommen ist, entschloss ich mich spontan zu einem dreistufigen Upgrade. Die Tour sollte mich von Version 7.10 zu 8.04 und schließlich zu 8.10 bringen.

An Diensten habe ich die LAMP-Konfiguration, Mailserver und Postgre-SQL Server ausgewählt. Die Sprache sollte Deutsch sein – oder zumindest das Tastaturlayout, damit ich mich bei der Belegung der Sonderzeichen nicht erst lange eingewöhnen muss. Die Sprachunterstützung für Deutsch ließ bei Ubuntu 7.10 Server wie auch schon bei der Desktop-Variante zu wünschen übrig. Die meisten Meldungen sind Englisch, manchmal auch ein nettes Gemisch aus Englisch und Deutsch.

Bei der Installation habe ich die 20 GB Festplatte automatisch aufteilen lassen, das noch vom Vorbesitzer vorhandene Windows 98 gehört damit der Vergangenheit an (was für ein Glück). Die weitere Installation ging nicht unbedingt immer zügig vonstatten, was aber vermutlich an der doch schon etwas älteren Hardware liegen könnte.

Ob die installierten Dienste unter Ubuntu 7.10 alle funktionierten ist mir nicht bekannt. Da ich den Ubuntu Server eigentlich nicht benötige, habe ich mich gleich zum Update entschlossen. Ohne grafische Oberfläche stand ich erst mal auf dem Schlauch. Mit einem einfachen sudo do-release-upgrade ging es dann aber vorwärts: knapp 170 MB Pakete wurden aus dem Internet heruntergeladen und installiert.

Dann wurde ich auf die schwachen Schlüssel hingewiesen, die man mit ssh-keygen -l -f HOST_KEY_FILE neu erzeugen soll. Dankenswerterweise gibt Ubuntu auch die Namen der HOST_KEY_FILEs mit an. Dies sind /etc/ssh/ssh_host_rsa_key und /etc/ssh/ssh_host_dsa_key. Ob ich da allerdings tatsächlich nach dem Upgrade etwas manuell tun muss, blieb unklar. Während des Upgrades schienen die beiden Schlüssel erzeugt worden zu sein.

Eine neue Version der Datei /etc/dovecot/dovecot.conf stellte mich vor ein kleine Herausforderung. Da ich keine Konfigurationsdatei manuell angepasst hatte, entschloss ich mich zum Ersetzen der Datei durch die Variante des Paket-Betreuers. Wozu die Datei gut ist, weiß ich noch nicht. Sicherlich hätte ich meine eigene Version beibehalten, wenn ich darin Eintragungen vorgenommen hätte.

Nach diesem Upgrade-Schritt war ich natürlich gespannt, auf welche Version der Ubuntu-Server sich aktualisiert haben könnte. Beim Login hat Ubuntu es schon verraten: Ubuntu 8.04 war der Stand. Ansonsten hätte mir ein uname -a die Kernel-Version und ein less /etc/issue die Ubuntu Versionsnummer ausgegeben.

Die nächste Stufe lässt sich nicht einfach durch Wiederholung des Befehls sudo do-release-upgrade erreichen. Die lapidare Ausgabe ist “No new release found”. Das liegt vermutlich daran, dass Version 8.04 die Long Term Support (LTS) Version von Ubuntu Server ist. Ein sudo nano /etc/update-manager/release-upgrades öffnet die Datei, in der die möglichen Updates spezifiziert werden. Ändert man hier den Eintrag Prompt=lts in Prompt=normal ab, findet der Upgrade Manager auch das Upgrade.

Zwei Minuten lang hat Ubuntu die Änderungen berechnet und dann um ca. 20:30 startete der wiederum ca. 190 MB große Download, der ungefähr 16 Minuten dauern soll. Der Download hätte vielleicht etwas zügiger vonstatten gehen können, wenn Downloads parallel ausgeführt worden wären – zumindest war das der subjektive Eindruck.

Zwischendurch hat mich wieder der Bildschirmschoner erschreckt – wie auch beim Update von 7.10 auf 8.04. Der Bildschirm wird dann einfach schwarz, was mir immer den Eindruck vermittelt, dass der PC abgestürzt ist oder sich ausgeschaltet hat. Als alten DOS-Hasen macht mich das kirre…

Eine neue Hürde tat sich auf, als die Dienste, die PAM verwenden, neu gestartet werden mussten. Einige Dienste muss man wohl manuell neu starten, andere konnte man eintippen bzw. waren vorgegeben. Ich habe es natürlich bei der Voreinstellung belassen und frage mich, ob es wohl noch weitere Dienste gegeben hätte, die ich neustarten sollte. So wurden Samba, Dovecot, Apt und Cron neu gestartet und die Installation fortgeführt.

Nach dem Upgrade war ein Neustart fällig, was mich doch ein bisschen an die Windows-Welt erinnerte. Ubuntu 8.10 Server ist jetzt installiert, nur was tue ich jetzt damit? Zunächst werde ich mal prüfen müssen, ob die Dienste alle laufen. Mit dem LAMP-Paket könnte ich immerhin Webseiten und Dateien hosten, die ich über DynDNS nach außen reiche. Dazu muss ich aber zunächst ein Loch in meine DSL-Firewall bohren…