SELFHTML aktuell Artikel Serverkonfiguration Die Apache-Konfigurationsdatei
Die Apache-Konfigurationsdatei:
Serverseitige Techniken (Partnerprogramme)
| SELFHTML aktuell Artikel Serverkonfiguration Die Apache-Konfigurationsdatei | |
|
Die Apache-Konfigurationsdatei:
|
| |
| |
Der Apache ist nach eigener Definition ein "HTTP-Webserver". Das heißt, er benutzt und versteht ausschließlich das HTTP-Protokoll und erfüllt Aufgaben, die die Übermittlung von Webseiten bzw. Webinhalten zum Ziel haben. Er nutzt dazu verschiedene Mechanismen und ist aufgrund seines modularen Aufbaus zu einer Vielzahl an Informationsübertragungen fähig. Aber er verläßt den Rahmen des HTTP-Protokolls nicht. Und das bedeutet, er kann Daten und Dateien zwar vermitteln, aber er kann sie nicht selbst bearbeiten - mit Ausnahme der wenigen Informationen, die er bei entsprechender Konfiguration über sich selbst zur Verfügung stellen kann.
Nun gibt es aber zahlreiche Anforderungen, die genau das voraussetzen, was der Apache selbst nicht leisten kann, nämlich die Verarbeitung bzw. Veränderung von übergebenen Daten. Dazu gibt es ein Konzept, mit dem der Apache ganz einfach Anforderungen an "Datenverarbeitung" an irgendein anderes Programm weiterleitet und dieses Programm gewissermaßen bittet, die Arbeit zu erledigen und die erhaltenen Daten an ihn zurückzugeben, damit er sie wiederum an den anfragenden Client weiterreichen kann. Das ist ein durchaus effektives Konzept, bei dem der anfragende Client in den meisten Fällen gar nichts davon erfährt, daß die Daten, die er aufgrund seiner Anfrage erhält, von Apache gar nicht aus irgendeinem Serververzeichnis ausgelesen, sondern erst von einem "Partner" zusammengestellt wurden.
Es gibt mehrere solcher "Partner". Hier soll aber nur auf drei davon näher eingegangen werden, wobei die Anmerkungen zu SSI im Grunde genommen keinen "Partner" betreffen, sondern eine Möglichkeit (ein Feature), die der Apache selbst nutzen kann. Im 
SELFHTML-Forum wird bisweilen der Terminus "serverseitige Techniken" gebraucht, wenn über die Arbeitsweise dieser Partner diskutiert werden muß. Das ist zutreffend, da die angeforderte Arbeit der Datenverarbeitung eben nur auf dem Rechner erfolgen kann, auf dem der Apache installiert ist - also auf dem Server. Nur diese Techniken führen dazu, daß Ergebnisse der Datenverarbeitung auch gespeichert und nach Bedarf später erneut abgerufen werden können. Der Gegensatz, nämlich "clientseitige Techniken" besteht darin, daß Daten auch im anfragenden Client verändert, also bearbeitet werden können, wozu am häufigsten Javascript genutzt wird. Nur führt das Ergebnis dieser Datenverarbeitung (in der Regel) nicht zu einem Ergebnis, das die neu strukturierten Daten irgendwo dauerhaft abspeichert. Bei "clientseitigen Techniken" bleiben sie flüchtig.
Das Thema ist außerordentlich vielschichtig und enthält auch eine Reihe von "Zwischenstufen" sowie eine Menge sicherheitsrelevanter Probleme. Aber es gehört nicht zum Konzept dieses Artikels, hier ausführlichere Darlegungen anzubieten bzw. zur Diskussion zu stellen.
Bei einer wie auch immer verlaufenen "Standardinstallation" verfügt der Apache noch nicht über die Möglichkeit, seine potentiellen Partner anzusprechen. Das muß erst durch Einfügen bzw. Aktivieren der entsprechenden Anweisungen in der Konfigurationsdatei festgelegt werden und kann sowohl im Abschnitt "main server configuration" erfolgen, womit es für den gesamten Server Gültigkeit erhält, wie auch in jedem einzelnen <VirtualHost>-Container. Dann gilt es lediglich für diesen virtuellen Host.
Soll die Ausführung von Server Side Includes ermöglicht werden, so muß in der Modulliste das entsprechende DSO-Modul mod_include geladen werden:
... LoadModule include_module modules/mod_include.so ...
Es gibt für SSI keine plattformspezifischen Unterschiede, und der Name sagt bereits, was dieses Konzept leisten soll. Es geht nicht darum, vorhandene Daten tatsächlich zu verändern. In Webdokumente sollen aber vom Server selbst weitere Webdokumente, deren Inhalte oder auch Ergebnisse von Scriptaufrufen unverändert eingebettet werden können, was unter Umständen zur Übermittlung sehr großer Datenmengen "auf einen Rutsch" führen kann. Die Grundform, in der das geschieht, besteht in einer Anweisung, die in ihrer Form einem Kommentar in HTML-Dokumenten entspricht und daher nicht in einem Browser angezeigt wird:
<--SSI-Befehl -->
Anweisungen, ob und wie darauf reagiert werden kann, sind in der httpd.conf bereits vorformuliert, jedoch müssen sie aktiviert werden. Es sind nur einige wenige Zeilen. Zunächst muß in den "Options" für das Verzeichnis, dessen Dokumente SSI anfordern dürfen, angegeben werden:
... Options +Includes ...
Das genügt jedoch noch nicht. Um SSI befolgen zu können, müssen die Module mod_mime und mod_include in der Modulliste aktiviert sein. Für Apache 1.3.31 werden dann die Angaben
AddType text/html .shtml .shtm AddHandler server-parsed .shtml .shtm
benötigt. Apache 2.0.50 ignoriert eine AddHandler-Anweisung für SSI jedoch und nutzt stattdessen eine andere Anweisung:
AddOutputFilter INCLUDES .shtml .shtm
Manchmal möchte man nun auch noch den scheinbaren Zwang, daß Dateien, die SSI-Anweisungen enthalten, grundsätzlich *.shtml oder *.shtm heißen müssen, umgehen bzw. auflockern. Wenn beispielsweise auch "normale" Dateien, also *.htm und *.html SSI ausführen lassen sollen, müssen die angegebenen Zeilen in der Form
AddOutputFilter INCLUDES .shtml .shtm .html .htm
notiert werden. Das gilt sinngemäß auch für die Anweisung AddType (und AddHandler in Apache 1.3.31). Eine besonders gute Idee muß das allerdings nicht sein, da der Apache damit veranlaßt wird, wirklich sämtliche *.htm-Dokumente auf das Vorhandensein von Includes zu durchsuchen, und das kann zu erheblicher Beeinträchtigung der Performance führen. Von dieser Möglichkeit sollte also wirklich nur dann Gebrauch gemacht werden, wenn gute Gründe dafür vorliegen und man sehr genau weiß, was damit vom Server verlangt wird. AddOutputFilter kann aber auch in .htaccess-Dateien eingesetzt werden und gilt dann ausschließlich für dieses eine Verzeichnis, das von .htaccess konfiguriert wird. In einem solchen Fall kann es sinnvoll sein, auch *.html-Dokumente auf das Vorhandensein von SSI parsen zu lassen. Treten irgendwelche Komplikationen auf, wenn ein Webdokument versucht, SSI anzusprechen, sollten die Apache-Protokolle genügend Aufschluß darüber geben, was und warum es nicht funktioniert hat.
Eine tabellarische Übersicht einiger SSI kann unter http://de.selfhtml.org/cgiperl/intro/ssi.htm#uebersicht nachgelesen werden. Selbstverständlich gibt es auch in der 
Online-Dokumentation ausführliche Erläuterungen.
Auf einer Linux-Maschine gehört PERL zu den Systembestandteilen, die immer vorhanden sind - manche Aufgaben der Systeminstallation lassen sich ohne PERL gar nicht bewältigen (bei Windows-Systemen ist das nicht der Fall). PERL ist einer der ältesten und mächtigsten "Partner" des Apache und hat insbesondere dadurch eine enorme Bedeutung, daß es (neben vielen anderen Aufgaben) die CGI-Schnittstelle nutzen kann. Es muß also in der Regel keine gesonderte Software-Installation vorgenommen werden, allerdings gibt es eine umfangreiche Liste von PERL-Modulen, die im Regelfall nicht installiert, aber bisweilen gewünscht werden.
Anders als bei SSI muß der Apache bei in PERL geschriebenen CGI-Scripts deren Anweisungen an den PERL-Interpreter übergeben und das Ergebnis der Arbeit des PERL-Interpreters wieder entgegennehmen und an den anfragenden Client weiterreichen können. Die dafür nötigen Anweisungen sind bereits in der httpd.conf vorformuliert, müssen aber aktiviert werden. Dazu muß dem Apache lediglich mitgeteilt werden, in welchen Verzeichnissen das Ablegen von CGI-Scripts zulässig ist. Es ist eine Konvention, solche Verzeichnisse cgi-bin zu nennen - wenn der Server angewiesen wird, auch andere Verzeichnisnamen, beispielsweise "cgi-perl" oder "cgi-lokal", zu beachten, ist das durchaus korrekt. Um solche cgi-bin-Verzeichnisse zu bestimmen, wird ein ScriptAlias verwendet:
ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/" <Directory "/srv/www/cgi-bin"> AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all </Directory>
Jeder virtuelle Host kann sein eigenes cgi-bin-Verzeichnis erhalten, womit die Einstellungen des Hauptservers überschrieben werden. Für das 
weiter vorn angegebene Beispiel eines virtuellen Host http://www.server1.test könnte der <VirtualHost>-Container dann beispielsweise so aussehen:
NameVirtualHost 192.168.0.2
<VirtualHost 192.168.0.2>
ServerName www.server1.test
DocumentRoot "/var/www/server1"
ScriptAlias /cgi-bin/ "/var/www/server1/cgi-bin/"
<Directory "/var/www/server1/cgi-bin/">
AllowOverride None
Options +ExecCGI -Includes
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Es gibt ein Modul mod_perl, das nicht zu einer Standardinstallation gehört, aber leicht dazuinstalliert werden kann. Dieses Modul bietet für PERL-Programmierer einige sehr interessante Möglichkeiten PERL-Code unmittelbar in HTML-Dokumente einzubetten. Für seinen Einsatz sind einige weitere ScriptAliase meist bereits vorformuliert. beispielsweise in dieser Form:
ScriptAlias /cgi-perl/ "/var/www/cgi-bin/" <Location /cgi-perl> SetHandler perl-script PerlResponseHandler ModPerl::PerlRun PerlOptions +ParseHeaders Options +ExecCGI </Location>
Zu beachten ist, daß dieser ScriptAlias für dasselbe cgi-bin-Verzeichnis eingesetzt werden kann, auf das auch "cgi-bin" zeigt. Um Konflikte zu vermeiden, werden dafür dann nicht Optionen für einen <Directory>-Container festgelegt, sondern stattdessen für einen <Location>-Container.
In den von der Apache Foundation bereitgestellten Sourcen ist schließlich noch eine Anweisung
AddHandler cgi-script .cgi
vorformuliert. Sie wird nicht immer zwingend benötigt, und ist auch nicht immer in einer "default"-Konfigurationsdatei vorhanden. Aber manchmal kann sie nützlich sein, da Apache damit angewiesen wird, unabhängig vom MIME-Typ alle Dateien mit dem Namen *.cgi grundsätzlich als CGI-Programme zu behandeln. Und manchmal hat man auch Gründe, andere Dateinamen zu verwenden, beispielsweise *.pl. oder es sollen CGI-Programme eingesetzt werden, die gar nichts mit PERL zu tun haben, sondern vielleicht in C geschrieben wurden. Dann ist dieser Handler wichtig.
Auf einer Windows-Maschine ist PERL nicht von Anfang an vorhanden, sondern muß gesondert installiert werden. Die gebrächlichste Quelle dazu ist ActiveState, es gibt aber auch andere Downloadmöglichkeiten. Bei ActiveState kann man eines der bekannten MSI-Pakete erhalten, das dann nur noch installiert werden muß:
Aktuell ist (im Juli 2004) PERL 5.8.4. Die Installation mit Hilfe des MSI-Paketes läßt sich auf allen Windows-Systemen problemlos durchführen. Bei Win9x sollte überprüft werden, ob die perl.exe über den Pfad in der autoexec.bat erreicht werden kann, da man Scripts manchmal auch auf der Konsole (Eingabeaufforderung) prüfen möchte. Wenn in PERL geschriebene CGI-Scripts eingesetzt werden sollen, gibt es in der Apache-Konfigurationsdatei noch eine nur unter Windows gültige Befehlszeile ScriptInterpreterSource mit dem Wert registry. Diese Anweisung wird für Apache 1.3.31 von http_core bereitgestellt, für Apache 2.0.50 von dem Multiprozessing-Modul mod_win32. Sie bewirkt, daß der Apache die "shebang" in PERL-Scripts ignoriert und stattdessen den in der Windows-registry enthaltenen Systempfad nutzt, um den PERL-Interpreter anzusprechen.
Für die Apache-Konfigurationsdatei gilt unter Windows, daß hier immer ein Handler vergeben werden muß, beispielsweise in dieser Form:
AddHandler cgi-script .cgi .pl .exe .bat
Sonst gelten die anderen, oben bereits für Linux getroffenen Anmerkungen ebenso auch für Windows. Ausführliche Darstellungen zur Arbeit mit PERL gehören seit langem zum Inhalt von SELFHTML; sie sind im entsprechenden Kapitel zu finden. Außerdem gibt es zahlreiche mehr oder weniger umfangreiche Tutorials und Anleitungen sowie gut besuchte Newsgroups. Eine von mehreren Portalseiten mit weiterführenden Links ist 
http://Links.perl-community.de.
Anders als PERL gehört PHP nicht zu den Systembestandteilen, die immer auf einer Linux-Maschine vorhanden sind. Es wird auf den Installationsmedien (CDs) immer zu finden sein - oder aber man besorgt es sich vom FTP-Server der gewählten Distribution. Die Originalquellen können als *.tar.gz-Archive von http://www.php.net/downloads.php bezogen werden. Unter Umständen möchte oder muß man sich PHP selbst kompilieren, was auf vergleichbare Art wie vorn bereits für den Apache beschrieben abläuft. Auch für PHP gibt es ein configure-Script. Einige Hinweise zur Installation kann man im PHP-Handbuch nachlesen, das an dieser Stelle leider noch nicht übersetzt ist. Und bei aller Skepsis gegenüber Statistiken kann ein Blick auf http://www.php.net/usage.php doch ganz aufschlußreich sein.
Aktuell ist zur Entstehungszeit dieses Artikels Version 5.0.0 (13.Juli 2004 freigegeben, Version 5.0.1 ist ein später veröffentlichtes Bugfix). Es gibt zwei Wege, auf denen PHP mit dem Apache zusammenarbeiten kann: entweder über die CGI-Schnittstelle oder unmittelbar als Modul. Die "Modulvariante" ist etwas schneller, da PHP im Speicher geladen bleibt, und auf einer Linux-Maschine sicherlich zu bevorzugen. Unter dem Namen mod_phpx (das x steht für die Version, also 4 oder 5) stellen die Distributoren ihre Installationspakete in bereits aufgearbeiteter vorkompilierter Form zur Verfügung, wenn man sich nicht die Mühe machen möchte, PHP selbst zu kompilieren.
Für die Arbeitsweise von PHP selbst ist die php.ini wichtig, die immer zu einer PHP-Installaion gehört. Sie ist jedoch nicht für die Zusammenarbeit mit dem Webserver zuständig. Dafür, daß PHP-Scripts mit Hilfe des Apache ausgeführt werden können, benötigt die Konfigurationsdatei des Servers einige wenige Zeilen. Zuallererst muß das Modul selbst geladen werden. Die Modulliste wird also um den Eintrag
LoadModule php5_module modules/libphp5.so
erweitert. Das genügt jedoch nicht, die Apachekonfiguration benötigt noch eine Anweisung, die mod_mime bereitstellt:
AddType application/x-httpd-php .php
Wenn man nicht sicher ist, ob das Modul ansprechbar bzw. überhaupt installiert ist, kann die Anweisung AddType auch in einen <IfModule>-Container eingeschlossen werden. Ist ein Modul mit diesem Namen vorhanden und ansprechbar, funktioniert dann alles, gibt es kein solches Modul, braucht der Apache auch nicht wegen mißglückter Konfiguration zu protestieren:
<IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php .php5 AddType application/x-httpd-php-source .phps </IfModule>
Es gibt eine - selten erwähnte - Alternative. Da in der Regel ja mod_mime aktiviert (für Scripteinsatz zwingend erforderlich) und in der httpd.conf eine Zeile TypesConfig conf/mime.types oder ähnlich enthalten ist, kann man in die Datei mime.types, die meist im selben Verzeichnis wie die Konfigurationsdatei liegt, den gewünschten MIME-Typ eintragen. Das bedeutet, in die Liste der dort bereits verzeichneten Typen noch die Zeile
application/x-httpd-php php
aufzunehmen. Achtung! Hier wird vor der Extension "php" kein Punkt angegeben. Im Grunde genommen bedeutet diese Vervollständigung der Liste in mime.types sogar eine elegantere Lösung als eine zusätzliche AddType-Anweisung in der Apache-Konfigurationsdatei.
Auch hier muß zunächst natürlich die Software besorgt werden. Wie für den Apache selbst und für PERL gibt es auch für PHP ein MSI-Installationspaket. Damit wird die Integration der "CGI-Variante" ins System automatisiert, was häufig vollkommen ausreicht. Will man auf einer Windows-Maschine PHP in der "Modulvariante" nutzen, so wird das etwas umfangreichere Sourcenpaket, das in der Regel als ZIP-Archiv erhältlich ist, benötigt.
PHP ist, ganz im Gegensatz zu fast allen Windows-Programmen, nicht auf irgendwelche registry-Schlüssel angewiesen und trägt dort auch nicht irgendwelche Zeilen dynamisch ein. Alles, was PHP selbst benötigt, wird über die php.ini gesteuert, die im %windir% abgelegt werden sollte, in der Regel also wahrscheinlich C:\Windows oder C:\WINNT. Ein kurzer Text mit einigen - leider nicht immer ganz zutreffenden und aktuellen - Installationshinweisen wird mit PHP mitgeliefert, unabhängig davon, ob man das Installerpaket verwendet oder das ZIP-Archiv benutzen möchte.
Zur Einrichtung der "Modulvariante" wird so verfahren, daß das ZIP-Archiv in ein bestimmtes Verzeichnis, beispielsweise D:\PHP entpackt wird. Es wird zwar empfohlen, die darin enthaltene Bibliothek php5ts.dll in das system32-Verzeichnis zu kopieren, jedoch ist das nicht zwingend erforderlich, da diese Bibliothek von Apache an mehreren Stellen gesucht wird, sobald er startet. Sie könnte also beispielsweise auch nach D:\Apache\bin kopiert oder verschoben werden. Darüberhinaus wird natürlich das Modul benötigt, das unter dem Namen php5apache2.dll zur Verfügung steht. Dieses Modul muß in das Modulverzeichnis des Apache kopiert oder verschoben werden, also nach D:\Apache\modules. In der Modulliste der Konfigurationsdatei kommt dann der Eintrag
LoadModule php5_module modules/php5apache2.dll
hinzu, sowie an anderer Stelle der httpd.conf
AddType application/x-httpd-php .php
Das genügt, damit Apache dieses PHP-Modul ansprechen kann. Auch hier könnte natürlich anstelle von AddType die Liste der MIME-Typen in mime.types vervollständigt werden, wodurch AddType überflüssig würde. Sollen weitere PHP-Features genutzt werden (auch PHP ist modular aufgebaut), muß die php.ini bearbeitet werden.
Zur Einrichtung der "CGI-Variante" genügt es, den MSI-Installer auszuführen. Es werden dabei einige Einstellungen abgefragt, leider gibt es eine Fehlermeldung, wenn man angibt, daß PHP mit dem Apache zusammenarbeiten soll. Also müssen die Einstellungen in der httpd.conf von Hand vorgenommen werden. Zwar gehört auch eine php5ts.dll zum Lieferumfang des Installers, sie muß aber nicht verschoben oder kopiert werden. In der Modulliste der Konfigurationsdatei ist dann zwar keine LoadModule-Anweisung für das PHP-Modul nötig, jedoch wird eine solche Anweisung für das Apache-Modul mod_cgi vorausgesetzt. Außerdem sind weitere Anweisungen in der httpd.conf erforderlich:
ScriptAlias /php/ "D:/PHP/" Action application/x-httpd-php "/php/php.exe" AddType application/x-httpd-php .php
AddType könnte weggelassen und stattdessen die Liste der MIME-Typen in mime.types vervollständigt werden. Ein ScriptAlias sowie Action sind aber für diese "CGI-Variante" zwingend erforderlich. Dann steht dem Arbeiten mit PHP-Scripts nichts mehr im Wege.
SELFHTML aktuell Artikel Serverkonfiguration Die Apache-Konfigurationsdatei
© 2007 
Impressum, für diese Seite: 
christoph.schnauss@berlin.de
