Zurück
 

Installation von Apache Version 1.3.28 mit mod_perl 1.28 unter SuSE-Linux 8.2

Was soll denn das - das habe ich doch auf der SuSE-CD?

Warum ist so etwas überhaupt nötig, Apache (auch mit dem Zusatzmodul mod_perl) ist doch in SuSE-Distribution schon seit langem enthalten?

Nun diese Frage drängt sich einem in der Tat auf. Wie Sie anhand meiner anderen Webseiten sehen können beschäftige ich mich schon eine Weile mit CGI-Programmierung in Perl. Ich habe damit schon in den Anfangszeiten von mod_perl begonnen. Damals war in der SuSE-Distribution noch kein mit mod_perl angereicherter Apache-Server enthalten und ich mußte mir meinen Apache selber zusammenbasteln. Die hierbei gesammelten Erfahrungen und Erkenntnisse waren der eigentliche Beginn dieser Seite.

Irgendwann (die genaue Versionsnummer habe ich vergessen) begann SuSE damit einen Apache-Webserver mit optionalem mod_perl (als DSO, dynamic shared object) in ihrer Distribution mitzuliefern. Genau hier liegt aber das Problem: Die Verwendung von mod_perl als DSO-Modul wird nach wie vor von den Entwicklern als "experimental" bezeichnet und nicht unbedingt empfohlen. Auf den einschlägigen Mailinglisten lautet die erste Frage bei dubiosen Fehlern von "Newbies" deshalb fast immer: "Haben Sie mod_perl als DSO-Modul oder als Static-Modul übersetzt". Dies ist dann auch schon oft die Ursache der Probleme.

Ein weiteres Problem sind evtl. auch das gemeinsame Verwenden von miteinander unverträglichen Apache-Modulen. So kann man problemlos PHP und mod_perl gleichzeitig installieren. Aber auch hier hatte ich schon die seltsamsten Phänomene (z.B. bei Verwendung des sehr weit verbreiteten Perl-Moduls Apache::DBI) die sich immer durch das Entfernen von einem der beiden Module beheben liesen. Ein etwas versierterer Bug-Jäger als ich hat auch schon mal eine präzisere Beschreibung des Problems auf der mod_perl Mailing-Liste geliefert. Seit meinen ursprünglichen Versuchen hat sich allerdings auch bei mod_perl einiges getan und in den Installationsanleitungen wird jetzt ausdrücklich vermerkt, dass die Koexistenz mit anderen Modulen jetzt eigentlich kein Problem mehr sein dürfte.

Als Entwickler von Perl-Modulen muß man gelegentlich auch seinen Apache-Daemon neu starten oder zumindest die Conf-Datei neu einlesen. Hier habe ich die Hilfe des Apacheutilities apachectl sehr zu schätzen gelernt. Dieses Utility wird aber auch schon von SuSE seit einigen Releases mitgeliefert und kann als Alternative zu "rcapache" verwendet werden.

Wie auch immer: Irgendwann ging ich dann wieder dazu über meinen selbstübersetzten Apache-Server zu verwenden da ich damit beim Test neuer Features und Perl-Module weniger Probleme hatte. Das Gleiche gilt für eine Vielzahl von Perl-Modulen (so wird das extrem wichtige CGI.pm-Perlmodul in einer total veralteten Version mitgeliefert - auch das hat mich schon Stunden gekostet).

Menü-Zutaten

So nun starten wir aber. Lassen Sie mich erst mal die notwendigen Zutaten beschreiben. Sie benötigen natürlich

Außerdem benötigen Sie noch die passenden mod_perl-Sourcen.

Und los geht's ...

  1. Wie bereits weiter oben beschrieben ist der Original-Apache-Server sowie die Original-httpd.conf von SuSE ziemlich speziell angepaßt. Nach Abarbeitung dieser Anleitung sollten Sie einen total neuen Apache-Server haben. Die Installationsroutine (sie wird weiter unten über mittels make install gestartet) überschreibt aber keine vorhandenen Dateien. Deshalb müssen Sie als erstes die Original-SuSE-Dateien "entfernen". Damit Sie im Notfall aber dort nachschauen können schieben wir die Dateien nur in andere Verzeichnisse. Folgendes mache ich in diesem Fall immer:

    mkdir /etc/httpd/suse.orig

    mv /etc/httpd/* /etc/httpd/suse.orig

    mv /usr/local/httpd /usr/local/httpd.suse.orig

  2. Legen Sie sich nun auf Ihrer Festplatte (z.B. in Ihrem Homeverzeichnis) ein Unterverzeichnis ein. Sie können dafür beispielsweise den Namen software verwenden.

  3. In dieses Verzeichnis kopieren Sie nun die beiden im vorigen Kapitel besorgten *.tar.gz-Dateien und packen Sie getrennt aus (tar zxf <Dateiname>). Sie haben dann innerhalb von software/ zwei nebeneinanderliegende Unterverzeichnisse apache_1.3.28/ und mod_perl-1.28/.

  4. Wechseln sie nun in das mod_perl-Verzeichnis mod_perl-1.28/.

  5. Verwenden sie das folgende Kommando um die mod_perl Seite zu installieren und den Apache-Source-Baum vorzubereiten (Achtung: Direkt nach dem Start des folgenden Befehls versucht der perl-Makefile-Mechanismus herauszubekommen ob Sie alle notwendigen Module installiert haben auf die mod_perl vertraut. Ignorieren Sie keinesfalls entsprechende required-Meldungen. Es kann sonst sein, dass Sie zwar den ganzen Rest dieser Beschreibung machen können und trotzdem läuft später ihr Apache-Server nicht stabil!!!): 
    perl Makefile.PL \
     APACHE_SRC=../apache_1.3.28/src \
     DO_HTTPD=1 \
     USE_APACI=1 \
     PREP_HTTPD=1 \
     EVERYTHING=1

     

  6. Dannach müssen Sie den mod_perl-Teil übersetzen und installieren. Beim Installieren wird einerseits ein der Source-Baum des Apache um mod_perl erweiteret. Außerdem werden die zugehörigen Perl-Module in die bereits installierten Perl-Bibliotheken aufgenommen. Letztere kann nur root modifizieren.

    make

    und dann als root

    make install

  7. Wechseln Sie danach in das parallel liegende Apache-Source-Verzeichnis. Da wir bei den Pfaden einigermassen zu SuSE kompatibel bleiben wollen, verwenden wir das für SuSE vorkonfigurierte Layout aus der Datei "config.layout". Das dort enthaltene Pfadlayout stammt aber noch aus SuSE-Version-6.x-Zeiten. Zumindest die "datadir"-Zeile im SuSE-Layout sollte dafür angepasst werden. Suchen Sie also den SuSE-Abschnitt in der Datei und ändern Sie die "datadir"-Zeile folgendermassen ab:

    datadir: /srv/www
  8. Nun können wir starten. Geben Sie das folgende Kommando ein: 
    ./configure \
"--with-layout=SuSE" \
"--server-uid=wwwrun" \
    "--server-gid=nogroup" \
"--enable-module=so" \
"--enable-module=unique_id"  "--enable-shared=unique_id" \
"--enable-module=rewrite"    "--enable-shared=rewrite" \
"--enable-module=info"       "--enable-shared=info" \
"--enable-module=headers"    "--enable-shared=headers" \
"--enable-module=expires"    "--enable-shared=expires" \
"--enable-module=mime_magic" "--enable-shared=mime_magic" \
"--enable-module=proxy" "--enable-shared=proxy" \
"--activate-module=src/modules/perl/libperl.a"

    Nun noch das obligatorische

    make

    und wieder als root (haben Sie vorher die weiter obenen Sicherheitskopien von /etc/httpd und /usr/local/httpd gemacht? Die Dateien müssen auf jeden Fall "weggedreht" sein da die Installationsroutine diese nicht überschreibt!)

    make install

  9. Nun können Sie Ihren Apache-Server das erste Mal starten. Dazu verwenden Sie entweder das SuSE-Startupskript "/etc/rc.d/apache start" oder das neue Binary "apachectl":

    apachectl start

Prima ..., und wie geht's jetzt weiter

Sie müssen nun Ihren "nagelneuen" Apache-Server nur noch für die Verwendung von mod_perl konfigurieren. mod_perl ist ziemlich mächtig. Es ist nicht nur ein in den Apache integrierter Perl-Interpreter. Vielmehr "grätscht" mod_perl in die diversen Callback-Hooks des Apache-Webservers 'rein und erlaubt damit den direkten Zugriff in jede Stufe eines http-Request. Sie können eigene Apache-Module in Perl schreiben usw.! Für den Anfang ist das aber etwas zu heftig und die meisten Leute haben mod_perl nur im Einsatz um die Ausführungsgeschwindigkeit ihrer in Perl geschriebenen CGI-Skripte zu beschleunigen - durch den in den Apache integrierten Perl-Interpreter entfällt nämlich die Startup-Zeit für den Interpreter.

"Normale" CGI-Skripte sind genau genommen unter mod_perl gar nicht lauffähig. Deshalb liefert mod_perl ein spezielles Emulationsmodul namens Apache::Registry mit. Es "simuliert" für ein "normales" CGI-Skript die übliche CGI-Umgebung. Um dieses Modul für Ihre Perl-Skripte zu aktivieren müssen Sie den Apache-Server so konfigurieren, dass er alle Perl-Dateien

mittels des Handlers (Server-Moduls) Apache::Registry abarbeitet. Dieses Modul "simuliert" den Perl-Skripten wie bereits gesagt eine normale CGI-Umgebung vor (obwohl das nicht mehr der Fall ist). Sie müssen dadurch Ihre Perl-Skripte gar nicht mehr - bzw. nur geringfügig ändern. Näheres zu dieser Konfiguration erfahren Sie mittels des Befehls: 

perldoc Apache::Registry

Wenn Sie beispielsweise alle *.pl-Dateien als mod_perl-CGI-Skripte aktivieren wollen dann verwenden Sie z.B. die folgenden Konfigurationsanweisungen:

PerlModule Apache::Registry
<Files *.pl>
  AddHandler perl-script .pl
  PerlHandler Apache::Registry
  PerlSendHeader On
</Files>

Die "geringfügigen" Änderungen alter CGI-Skripte betreffen die Deklaration von Variablen. mod_perl übersetzt nämlich Ihre Perl-CGI-Skripte nur einmal und hält den erzeugten Zwischencode in einem internen Programmcode-Cache. Das gleiche gilt für Ihre Variablen. Deren Lebensdauer erlischt auf einmal nicht mehr mit dem Ende des Skripts sondern erst wenn der Apache-Server gestopt wird. Das hat ziemlich unerwünschte Nebeneffekte zur Folge!!!! Deshalb plazieren Sie zuerst einmal in jedem Ihrer Skripte ein

use strict;

um sich selbst zu zwingen Variablen zu deklarieren. Dannach deklarieren Sie alle Variablen fein säuberlich lexikalisch (ja ich weis ich hab' gut grinsen) mittels my.

Beispiel:

my ($nname, $vname);
my $remoteip;

Alles weitere füllt Bücher :-) und ich höre hier deshalb erst mal auf ...

Zurück

Zähler Lokal bzw. Remote-Zugriffe seit dem 24. November 2000 (auf diese Seite bzw. ihre Vorgänger mit anderen Versionen)