ALIs

kommt noch

Virtueller WWW-Server - CGI und PHP

Dynamische Webseiten mit CGI und PHP

Vorbemerkung

Bitte beachten: Dynamische Webseiten mit CGI und PHP sind nur für Betreiber eines virtuellen Webservers am LRZ erlaubt.

Webseiten auf einem virtuellen Server können sowohl statische HTML-Seiten sein, als auch Webseiten, die aus Skripten erzeugt werden. Zur dynamischen Erzeugung von Webseiten steht Ihnen eine allgemeine CGI-Umgebung zur Verfügung, in der Skripte insbesondere in den Sprachen Perl und PHP ausführbar sind. Andere Sprachen sind möglich, aber nicht so empfehlenswert, da nicht weiter unterstützt.

Aus Sicherheitsgründen sind für Skripte einige Regelungen und Einschränkungen zu beachten, die im Folgenden ausführlich beschrieben werden.

Auf den virtuellen Webservern am LRZ können Sie Skripte in folgenden Umgebungen verwenden:

Bitte beachten Sie dazu unbedingt die folgende Beschreibung!

Das LRZ unterstützt die Programmiersprachen Perl und PHP für Webanwendungen. Java, Python und andere Sprachen werden gegenwärtig leider nicht unterstützt.

Server Side Includes (SSI) können am LRZ leider nicht genutzt werden.

Grundsätzliches, Gegebenheiten am LRZ

Zwar bieten CGI-Skripten und PHP-Seiten aus Sicht eines Web-Entwicklers zunächst sehr unterschiedliche Möglichkeiten, dynamische Inhalte zu erzeugen, aber aus technischer Sicht liegen sie so nahe beieinander, dass man beide zunächst parallel betrachten kann. In gewisser Weise sind PHP-Seiten ein Spezialfall von CGI-Skripten. Die folgenden Hinweise gelten daher - soweit nicht speziell vermerkt - für CGI-Skripten und PHP-Seiten.

Jeder, der einen virtuellen Server am LRZ betreibt, erhält automatisch die Möglichkeit, sowohl PHP-Skripte als auch CGI-Skripte einzusetzen. Ein gesonderter Antrag ist nicht notwendig.

Safe Mode und CGI-Wrapper

Die Webseiten und Skripten aller Betreiber von virtuellen Servern werden über den gleichen Webdämon aufgerufen und müssen daher für diesen zumindest lesbar sein, aber oft sind auch Schreibrechte für die Skripten notwendig. Aus Sicherheitsgründen müssen wir daher erreichen, dass die Skripten verschiedener virtueller Webserver nicht aus Versehen, geschweige denn absichtlich, Daten anderer lesen oder gar löschen können. Es gibt eine Reihe von Techniken für den Provider, dies zu gewährleisten. Am LRZ werden derzeit die folgenden beiden Methoden eingesetzt.

Die erste Methode ist bei CGI-Skripten (also unter NFS) realisiert. Dabei wird vor den Aufruf eines Skriptes ein so genannter CGI-Wrapper geschaltet, der von der Kennung des Webdämons auf die Kennung des jeweiligen Webservers umschaltet, zu dem das Skript gehört. Diese Methode wird verwendet für die beiden Skriptumgebungen CGI und PHP-CGI. Dort können allerdings nur ausführbare Dateien liegen; eine Mischung mit normalen HTML-Seiten, Stylesheets und Bildern, wie sie bei PHP-basierten Produkten in der Regel vorkommt, ist nicht möglich. Auch der Zugriffschutz kann nicht mit der gängigen "htaccess-Methode" realsiert werden und es wird nicht automatisch nach einer Datei index.php gesucht.

Die zweite Methode wird bei PHP-Skripten im Dokumentenbereich (also unter AFS) angewandt. Hier ist der so genannte Safe-Mode von PHP aktiviert. Ein PHP-Skript kann daher nur solche Dateien öffnen, die den selben Eigentümer wie das PHP-Skript haben. Zusätzlich sind einige PHP-Funktionen verboten bzw. stark eingeschränkt; das sind vornehmlich solche Funktionen, mit denen externe Kommandos aufgerufen werden können (system(), exec(), popen(), Backtic-Operator, usw). Diese Methode betrifft die Skriptumgebung PHP-MOD. HTML-Seiten, Stylesheets, Bilder und PHP-Skripte können in beliebigen Verzeichnissen im Dokumentenbereich abgelegt werden und htaccess-Dateien werden wie gewohnt berücksichtigt.

Probleme mit dem Safe-Mode von PHP entstehen, wenn eine Datei über den Webserver neu angelegt wird. Sie gehört dann dem Webdämon und kann daher in der Folge nicht benutzt werden. Dies trifft insbesondere Content-Management-Systeme (CMS) auf PHP-Basis, die Daten für den Webserver im Dateisystem ablegen. Solche Programme, manchmal auch als Redaktionssysteme bezeichnet, können am LRZ derzeit nicht eingesetzt werden; Sie können sie allenfalls auf Ihrem eigenen Rechner einsetzen und dann die Dateien per FTP ans LRZ kopieren. Aus dem CMS-Bereich kommen eher solche Programme in Frage, die ihre Daten in einer Datenbank halten. Weiter betrifft das Safe-Mode-Problem das Hochladen von Dateien, wenn es über ein im PHP-Produkt integriertes Upload-Modul erfolgt. Hier sollten Sie solche Produkte wählen, die ein externes Hochladen über FTP zulassen. Das Safe-Mode-Problem macht sich gelegentlich auch bei der Erstinstallation eines PHP-Produkts beim Anlegen von Konfigurationsdateien bemerkbar. Da es hier in aller Regel nur um sehr wenige Dateien geht, kann man sich damit behelfen, diese Dateien einmalig von Hand umzukopieren, so daß sie dann den richtigen Eigentümer haben.

Hinweis zum Safe-Mode bei Joomla: Joomla bietet ab Version 1.5 die Möglichkeit, per FTP auf Dateien zuzugreifen. Damit treten dann keine Safe-Mode-Probleme beim Hochladen von Dateien oder beim Installieren von Joomla-Erweiterungen mehr auf. Sie müssen allerdings Ihr Paßwort in der Konfigurationsdatei speichern oder es bei jedem betroffenen Vorgang erneut eingeben. Aktivieren Sie dazu im Konfigurationsmenue unter dem Stichwort FTP-Konfiguration den "FTP-Layer für Dateizugriffe" (FTP-Host = ftp.lrz.de, FTP-Port = 21, FTP-Benutzer = LRZ-Kennung zum Webserver).

Es ist also je nach Art der geplanten PHP-Skripte zu überlegen, in welcher Umgebung die Skripte am besten laufen werden. (Sie können auch einige PHP-Skripte in der einen und die anderen in der anderen Umgebung laufen lassen.) Diese Entscheidung muss getroffen werden, bevor man die Skripte unter NFS oder AFS ablegt, und zwar aus folgendem Grund:

Wichtig für PHP-Skripte: Der Webserver sucht ein PHP-Skript immer zuerst im Dokumentenbereich (also unter AFS). Erst, wenn es dort nicht existiert, wird versucht, es im CGI-Bereich (also unter NFS) aufzurufen.

Folgendes Beispiel verdeutlicht das Verhalten: Sie wollen eine Webseite mit PHP unter folgendem URL realisieren:

http://www.mein-servername.de/sub/index.php

1. Sie entscheiden sich dafür, PHP-Skripte über das PHP-Modul von Apache auszuführen und legen die Datei index.php ab unter /afs/lrz/user/x/uv999wx/webserver/webdata/sub/index.php. Der Webserver findet die Datei unmittelbar dort, führt sie aus und liefert das Ergebnis zurück.

2. Sie entscheiden sich dafür, PHP-Skripte über den CGI-Wrapper auszuführen und legen die Datei index.php ab unter /nfs/cgi/x/uv999wx/webdata/cgi-bin/php/sub/index.php. Der Webserver sucht nun zuerst unter /afs/lrz/user/x/uv999wx/webserver/webdata/sub/ nach der Datei. Findet er sie dort (vielleicht eine ganz andere Datei mit gleichem Namen aus früheren Versuchen), so wird er diese verwenden und die index.php-Datei in NFS bleibt unbenutzt! Nur wenn die Suche im AFS-Baum erfolglos war, wird der NFS-Baum benutzt!

AFS und NFS - zwei getrennte Welten

Die Trennung zwischen AFS und NFS hat folgenden Nebeneffekt: Es ist nicht ohne weiteres möglich, z.B. aus einem CGI-Skript unter NFS auf Daten unter AFS zuzugreifen. Man müsste dazu entweder den entsprechenden AFS-Bereich für alle Welt zugreifbar machen - für Lesezugriff nur bedingt empfehlenswert, bei Schreibzugriff eine Todsünde. Oder aber man müsste das AFS-Passwort unter NFS ablegen und es per Skript auslesen, bevor der AFS-Zugriff erfolgt. Aber auch die Ablage von Passwörtern auf diese Weise ist keineswegs empfehlenswert!

Sicherheitshinweise

PHP- und CGI-Skripten unter NFS werden unter der UID/GID des zugehörigen virtuellen Webservers ausgeführt und auch PHP unter AFS ist durch den Safe Mode teilweise abgesichert. Die potentielle Gefahr, die von Skripten ausgeht, wird auf diese Weise etwas entschärft. Benutzer sollten dennoch das Risiko nicht unterschätzen, zumal da es ja ihre Daten sind, auf die mit ihren Skripten zugegriffen wird. Hier ein Link, der sich mit dem Thema Sicherheit und CGI-Skripten auseinandersetzt: CGI Security

Legen Sie nie Programme wie z.B. Compiler (C, Fortran, usw.) oder Interpreter (Perl, Tcl, PHP, usw.) in den Skriptumgebungen ab! Diese könnten unter Umständen mißbraucht werden.

Temporäre Dateien "/tmp", POOL_TMP und LOCAL_TMP

Die Webserver des LRZ sind technisch nicht auf einer einzigen Maschine realisiert, sondern auf einen Server-Pool verteilt. Über eine als Switch bezeichnete Netzkomponente werden die Anfragen an die Webserver reihum von verschiedenen Maschinen des Pools beantwortet. Dadurch werden Ausfallsicherheit und Leistungsfähigkeit erhöht.

Durch die Verteilung ist es jedoch nicht mehr möglich, zur Ablage von Zwischendaten, die während der Bearbeitung eines Skriptes anfallen, von einem lokalen Verzeichnis /tmp Gebrauch zu machen, da dieses üblicherweise nur lokal an einer Maschine liegt und nicht von anderen Rechnern erreichbar ist. Dies ist insbesondere von Bedeutung für alle diejenigen Skripten, die beispielsweise mehrere HTML-Formularseiten nacheinander erzeugen und die Zwischenergebnisse oder Session-IDs jeweils temporär ablegen.

Für diese ist es notwendig, einen pool-weit definierten Bereich für die temporären Daten zu verwenden. Diesen Bereich können Sie aus Skripten im CGI-Bereich (unter NFS) über die Umgebungsvariable POOL_TMP ansprechen. Beispiele folgen weiter unter.

Für spezielle Anwendungen kann es sinnvoll sein, auf einen lokalen TMP-Bereich zu bestehen. Dies wäre beispielsweise der Fall, wenn ein Skript lediglich eine einzige Seite generiert, dazu aber eine Zwischenablage benötigt. Für diese Fälle kann die Umgebungsvariable LOCAL_TMP verwendet werden. Die Verwendung ist analog zu POOL_TMP.

Schreibrechte für den Webdämon unter AFS

Im AFS-Bereich Ihres Webservers hat der Webdämon normalerweise nur Leserechte. PHP-Skripte unter AFS (PHP-MOD) können daher nur dort schreiben, wo Sie dem Webdämon ausdrücklich ein Schreibrecht eingeräumt haben. Unter AFS werden Rechte immer für alle Dateien in einem Ordner vergeben; unterschiedliche Rechte für die einzelnen Dateien in einem Ordner sind nicht möglich.

Schreibrecht für einzelnen Ordner:

  1. Starten Sie das Programm Secure Shell (SSH) auf Ihrem Rechner und verbinden Sie sich mit webdev1.lrz.de (Zugang nur im MWN). Sie benötigen dazu die LRZ-AFS-Kennung Ihres Webservers und das zugehörige Passwort.

  2. Geben Sie dann folgende zwei Kommandos ein (jeweils mit "Return" abschliessen):

    cd <gewünschter Ordner>
    /usr/afsws/bin/fs sa . somebody write

    Beispiel:

    cd $HOME/webserver/webdata/phpanwendung/tmp
    /usr/afsws/bin/fs sa . somebody write

    Bitte beachten Sie den Punkt zwischen "sa" und "somebody", der für den aktuellen Ordner steht; sie können an dieser Stelle auch gleich den Namen des Ordners eingeben und dann auf das Kommando "cd" verzichten. Die Kennung "somebody" ist die AFS-Kennung des Webdämons.

  3. Sie können die gesetzten Rechte kontrollieren mit:

    cd <gewünschter Ordner>
    /usr/afsws/bin/fs la .

    Bitte beachten Sie den Punkt am Ende des zweiten Kommandos, der für den aktuellen Ordner steht. Sie sollten bei "somebody" die Rechte "rlidwk" sehen, die in der Anzeige statt des Schlüsselworts "write" verwendet werden.

  4. Beenden Sie die Sitzung mit der Eingabe von "exit".

Schreibrecht für Ordner und sämtliche Unterordner:

  1. Wie oben
  2. Geben Sie dann folgende zwei Kommandos ein (jeweils mit "Return" abschliessen):

    cd <gewünschter Ordner>
    /client/bin/setacl . somebody write

    Bitte beachten Sie den Punkt zwischen "setacl" und "somebody", der für den aktuellen Ordner steht; sie können an dieser Stelle auch gleich den Namen des Ordners eingeben und dann auf das Kommando "cd" verzichten. Die Kennung "somebody" ist die AFS-Kennung des Webdämons.

  3. Wie oben
  4. Wie oben

Sie haben kein SSH-Programm auf Ihrem Rechner?

Die folgenden Abschnitte behandeln CGI-Skripte (CGI), PHP-Skripte im CGI-Bereich (unter NFS, PHP-CGI) und PHP-Skripte im Dokumentenbereich (unter AFS, PHP-MOD) getrennt. Daher sind die Überschriften jeweils mit dem passenden Begriff eingeleitet, um Unklarheiten zu vermeiden.

CGI: CGI-Skripte: Details

CGI: Ablage von Dateien im CGI-Bereich

Das CGI-Homedirectory ist am FTP-Server des LRZ (ftp.lrz.de) über den Pfad

/nfs/cgi/<DIR>/<Benutzerkennung>

erreichbar. Die Anfangs- oder Endziffer der Benutzerkennung gibt bei allen Kennungen Auskunft darüber, in welchem Directory DIR sich das Homedirectory befindet. Bei allen Kennungen wird für das Verzeichnis oberhalb der Kennung die letzte Ziffer der Kennung genommen.

Im CGI-Homedirectory finden Sie ein Subdirectory mit dem Namen webdata und in diesem wiederum ein Subdirectory cgi-bin. Das Directory webdata enthält den Verzeichnisbaum mit den notwendigen Daten, das Subdirectory cgi-bin die CGI-Skripte (cgi-bin darf ebenfalls in Subdirectories untergliedert sein). Da das CGI-Homedirectory nicht unter AFS liegt, sind hierfür die Unix Permissions relevant. Diese müssen für die jeweiligen Directories also mindestens dergestalt sein:

dr-x------

Die CGI-Skripte müssen mindestens folgende Permissions haben:

-r-x------

CGI: Voraussetzungen

Mittels Common Gateway Interface (CGI) können Sie beliebige Programme über den Webserver aufrufen. Am LRZ wird derzeit nur positionsabhängiges CGI angeboten: Alle Dateien im CGI-Bereich (auch .htaccess, Bilder, usw) werden als CGI-Skripte interpretiert. Umgekehrt bedeutet dies auch, daß die Namen von CGI-Skripten beliebig sind (jedoch Sonderbehandlung von PHP-Skripten mit Namen auf .php, siehe PHP-CGI). Die Voraussetzungen für die Ausführung von CGI-Skripten sind:

  • Ablage im CGI-Bereich unter: /nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/
  • Dateiname beliebig (Sonderbehandlung bei Endung .php)
  • Datei ausführbar: x-Bit gesetzt
  • Datei ausführbar: Pfad zum Interpreter in erster Zeile
  • Eigentümer Datei = Kennung Webserver
  • Gruppe Datei = Gruppe Webserver

Oft werden CGI-Skripte in Perl geschrieben. In Perl-Skripten sollte die erste Zeile mit dem Pfad zum Perl-Interpreter wie folgt lauten:

       #!/usr/bin/perl

Dies ist der Standardpfad von Perl. Statt /usr/bin/perl kann auch /usr/local/bin/perl verwendet werden.

CGI: Dateipfad und URL

Um aus einer HTML Seite heraus ein CGI-Skript aufrufen zu können, wird der URL benötigt. Dieser muss bestimmten Konventionen gerecht werden. Hier der Zusammenhang von Dateipfad und URL für ein beliebiges Skript:

Dateipfad /nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/<Subdirectory>/<script>
URL http[s]://<www.mein-servername.de>/sys/cgi/<Subdirectory>/<script>

Die Bezeichnungen der variablen Pfadbestandteile sind selbsterklärend.

CGI: Debugging beliebiger CGI-Skripte

Im Debug-Modus können möglicherweise sensitive oder sicherheitsrelevante Daten ausgegeben werden, die nicht für jedermanns Auge bestimmt sind. Daher wurde der Zugriff mit einem Passwortschutz versehen. Kennung und Passwort sind die gleichen, die auch für den Zugriff auf die Logs verwendet werden. Sie wurden Ihnen bei der Einrichtung des Servers mitgeteilt.

Der Debug-URL kann über eine verschlüsselte Verbindung (HTTPS) oder über eine unverschlüsselte Verbindung (HTTP) aufgerufen werden; es empfiehlt sich jedoch die verschlüsselte Variante, um das übermittelte Paßwort zu schützen.

Beispiel für Debug-URL:

Dateipfad /nfs/cgi/6/t123456/webdata/cgi-bin/kurse/anmeldung.pl
URL http://www.mein-servername.de/sys/cgi/kurse/anmeldung.pl
Debug-URL https://www.mein-servername.de/sys/cgi/debug-t123456/kurse/anmeldung.pl

CGI: Verwendung von POOL_TMP

Beispiel:

#!/usr/bin/perl
$TMP = $ENV{'POOL_TMP'};
open (TMPDAT, "$TMP");
print "Dies ist ein vergänglicher Text\n";
close(TMPDAT);

CGI: Beispiel für CGI-Skript

Unter der Kennung 'uv999wx' ist ein virtueller Server 'www.mein_institut.uni-muenchen.de' eingerichtet. Der Benutzer mit der Kennung 'uv999wx' hat in seinem Directory cgi-bin ein Subdirectory perl, das ein CGI script mit dem Namen email.pl enthält. Der Pfad zu email.pl sieht dann so aus:

/nfs/cgi/x/uv999wx/webdata/cgi-bin/perl/email.pl

Der erforderliche URL zum Skript heißt dann:

http://www.mein_institut.uni-muenchen.de/sys/cgi/perl/email.pl

Zum Debugging des Skripts kann folgender URL verwendet werden:

http://www.mein_institut.uni-muenchen.de/sys/cgi/debug-uv999wx/perl/email.pl

Als einfaches Test-Skript kann folgendes CGI-Skript verwendet werden:

#!/usr/bin/perl
print "Content-type: text/html\n\n";
while (($key, $val) = each %ENV) {
        print "$key = $val<BR>\n";
}

PHP-CGI: PHP-Skripte im CGI-Bereich: Details

PHP-CGI: Voraussetzungen

PHP-Skripte im CGI-Bereich werden gesondert behandelt, falls ihr Dateiname wie üblich auf .php endet. Sie müssen dann im Verzeichnis cgi-bin/php/ abgelegt werden.

Die Voraussetzungen für die Ausführung solcher PHP-Skripte im CGI-Bereich sind:

  • Ablage im CGI-Bereich unter: /nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/php/
  • Dateiname endet auf .php
  • Eigentümer Datei = Kennung Webserver
  • Gruppe Datei = Gruppe Webserver

Es ist also - anders als bei sonstigen CGI-Skripten - unerheblich, ob das Skript ausführbar ist oder nicht und ob in der ersten Zeile der Pfad zum Interpreter steht oder nicht. Alle Varianten sind möglich. Es wird immer das vom LRZ konfigurierte PHP-Programm verwendet.

Beachten Sie aber bitte, daß die meisten PHP-basierten Produkte Skripte und andere Dateien, wie z.B. Stylesheets und Bilder, unter einem Einstiegspunkt sammeln. Dies ist im CGI-Bereich nicht möglich, so daß sie solche Produkte hier oft nicht oder allenfalls mit geeigneten Anpassungen einsetzen können.

Falls der Dateiname des PHP-Skripts nicht auf .php endet, so wird es wie unter CGI-Skripte: Details behandelt.

PHP-CGI: Dateipfad und URL

Bei PHP-Skripten im CGI-Bereich ist der Zusammenhang von Dateipfad und URL anders als bei sonstigen CGI-Skripten, falls ihr Dateiname wie üblich auf .php endet. Das soll Ihnen die Gestaltung kompletter Webauftritte mit PHP-Skripten ohne den störenden Einschub /sys/cgi im URL erleichtern.

Dateipfad /nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/php/<Subdirectory>/<script>.php
URL http[s]://<www.mein-servername.de>/<Subdirectory>/<script>.php

Beispiel:

Dateipfad /nfs/cgi/x/uv999wx/webdata/cgi-bin/php/intro.php
URL http://www.mein-servername.de/intro.php

Bitte beachten: Bei einem URL der Gestalt http://www.mein_institut.uni-muenchen.de/volldynamisch.php wird die Datei volldynamisch.php wie eine normale HTML-Datei zuerst im Dokumentenbereich (unter AFS), also unter /afs/lrz/user/x/uv999wx/webserver/webdata/volldynamisch.php gesucht; nur, wenn sie dort nicht existiert, wird im Verzeichnis /nfs/cgi/x/uv999wx/webdata/cgi-bin/php weitergesucht! (siehe PHP-MOD)

PHP-CGI: Debugging von PHP-Skripten

Im Debug-Modus können möglicherweise sensitive oder sicherheitsrelevante Daten ausgegeben werden, die nicht für jedermanns Auge bestimmt sind. Daher wurde der Zugriff mit einem Passwortschutz versehen. Kennung und Passwort sind die gleichen, die auch für den Zugriff auf die Logs verwendet werden. Sie wurden Ihnen bei der Einrichtung des Servers mitgeteilt.

Der Debug-URL kann über eine verschlüsselte Verbindung (HTTPS) oder über eine unverschlüsselte Verbindung (HTTP) aufgerufen werden; es empfiehlt sich jedoch die verschlüsselte Variante, um das übermittelte Paßwort zu schützen.

Beispiel für Debug-URL:

Dateipfad /nfs/cgi/6/t123456/webdata/cgi-bin/php/kurse/anmeldung.php
URL https://www.mein-servername.de/kurse/anmeldung.php
Debug-URL https://www.mein-servername.de/debug-t123456/kurse/anmeldung.php

PHP-CGI: Verwendung von POOL_TMP

Beispiel:

<?php
 $TMP = $_SERVER['POOL_TMP'];
 printf("POOL_TMP: %s",$TMP);
 $fp = fopen ("$TMP/tmp.txt", "a");
 fwrite ($fp, "Dies ist ein vergänglicher Text\n");
 fclose($fp);
?>

PHP-CGI: Beispiel für PHP-Skript

Unter der Kennung 'uv999wx' ist ein virtueller Server 'www.mein_institut.uni-muenchen.de' eingerichtet. Der Benutzer mit der Kennung 'uv999wx' hat in seinem PHP-Directory /nfs/cgi/x/uv999wx/webdata/cgi-bin/php ein Subdirectory umfrage mit einem PHP-Skript namens test.php. Der Pfad zum Skript sieht also folgendemaßen aus:

/nfs/cgi/x/uv999wx/webdata/cgi-bin/php/umfrage/test.php

Der normale URL heißt dann:

http://www.mein_institut.uni-muenchen.de/umfrage/test.php

Zum Debugging des Skripts kann folgender URL verwendet werden:

http://www.mein_institut.uni-muenchen.de/debug-uv999wx/umfrage/test.php

oder (empfohlen)

https://www.mein_institut.uni-muenchen.de/debug-uv999wx/umfrage/test.php

Als einfaches Test-Skript kann folgendes PHP-Skript verwendet werden:

<?php
echo 'Hallo, Welt';
?>

CGI und PHP-CGI: Zugriffskontrollen im Bereich /nfs einrichten

Diese Beschreibung gilt ausschließlich dann, wenn man PHP- oder CGI-Skripten mit einer passwortbasierten Zugriffskontrolle schützen möchte. Unabhängig davon ist es natürlich möglich und oft auch sinnvoll, mit Hilfe der Skripten eine eigene Zugriffskontrolle zu programmieren. Entsprechende Techniken findet man in den einschlägigen Dokumentationen zur PHP- und CGI-Programmierung.

Vorbereitung des virtuellen Servers

Der Zugriffsschutz wird im NFS-Bereich nicht, wie unter AFS, verzeichnisweise durch eine .htaccess-Datei erreicht, sondern aus technischen Gründen über eine spezielle Datei-Endung .sec, die man an den Namen des zu schützenden Skriptes anhängt.

Will man beispielsweise in seinem NFS-CGI-Verzeichnis das Skript

/nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/<Skriptname>

schützen, so geht man folgendermaßen vor.

  1. Man legt die Passwort-Datei für den Zugriffsschutz an. Dazu geht man in das NFS-Verzeichnis

    /nfs/cgi/<DIR>/<Benutzerkennung>

  2. Dort legt man - falls noch nicht vorhanden - ein Verzeichnis webconfig an mit dem Kommando:

    mkdir webconfig

  3. Dem Verzeichnis webconfig gibt man (hier gelten Unix-Permissions!) folgende Permissions:

    drwxr-xr-x

    z.B. mit

    chmod 755 webconfig

  4. Man wechselt in das Verzeichnis webconfig mit cd webconfig

  5. Dort legt man - falls noch nicht vorhanden - eine Datei namens htpasswd an (genau dieser Name!) mit folgenden Permissions:

    -r--r--r--

    z.B. mit

    chmod 444 htpasswd

    Diese Datei enthält die Kennungen und Gruppen, die auf die geschützten CGI- und PHP-Skripten Zugriff haben sollen. Das Format ist das Gleiche wie unter "Eigene WWW-Seiten für LRZ-Benutzer unter AFS", Kapitel "Zugriffskontrollen einrichten" beschrieben.

  6. Man hängt an den eigentlichen (ansonsten beliebigen) Skriptnamen die Endung .sec an:

    /nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/<Skriptname>.sec

    Dies gilt auch für PHP-Skripten: Nach der Endung .php wird eine weitere Endung .sec ergänzt:

    /nfs/cgi/<DIR>/<Benutzerkennung>/webdata/cgi-bin/php/<PHP-Skriptname>.php.sec

  7. Der URL zum Skript lautet dann:

    http://www.mein-servername.de/sys/cgi/<Subdirectory>/<Skriptname>.sec

    bzw. für PHP-Skripten

    http://www.mein-servername.de/<Subdirectory>/<Skriptname>.php.sec

    Das funktioniert auch im Debug-Modus, ganz analog zu ungeschützten Skripten:

    https://www.mein-servername.de/sys/cgi/debug-<Benutzerkennung>/<Subdirectory>/<Skriptname>.sec

    https://www.mein-servername.de/debug-<Benutzerkennung>/<Subdirectory>/<Skriptname>.php.sec

  8. Beachten Sie, dass man zur Verwendung des Debug-Modus Kennung und Passwort des virtuellen Servers angeben muss. Hier können Sie keine eigenen Berechtigungen eintragen. Die soeben beschriebenen Zugriffsschutzmechanismen sind unabhängig vom Debug-Modus. Bei Verwendung des Debug-Modus sind sie ausgeschaltet, es würde wenig Sinn machen, eine weitere Passwortabfrage zu verlangen, nachdem man sich ohnehin in der Debug-Modus-Abfrage als Administrator des Servers ausgewiesen hat.

  9. Beachten Sie immer, dass alles, was sie unter dem Pfad /nfs/cgi/<DIR>/<Benutzerkennung>/ anlegen, keinen Einfluß hat auf statische Seiten unter AFS /afs/lrz/user/<DIR>/<Benutzerkennung>/webserver. Auch die Passwort-Dateien sind verschieden!

Zusammenfassung

Zur Realisierung eines passwortbasierten Zugriffskontrolle unter NFS braucht man also nur zwei Dinge:

  1. Man hängt die Endung .sec an die zu schützende Datei an.
  2. Man trägt die zugriffsberechtigten Personen in die Passwort-Datei /nfs/cgi/<DIR>/<Benutzerkennung>/webconfig/htpasswd mit Kennung und Passwort ein.

Dieser Schutz ist aus Anwendersicht einfacher zu implementieren als der im Bereich AFS beschriebene Schutzmechanismus mittels .htaccess-Dateien. Er bietet dafür aber auch weniger Konfigurationsmöglichkeiten: Es gibt nur genau eine Passwortdatei, daher dürfen entweder alle in dieser Datei eingetragenen Personen zugreifen oder keiner.

PHP-MOD: PHP-Skripte im Dokumentenbereich: Details

PHP-MOD: Voraussetzungen

PHP-Skripte können im Dokumentenbereich (also unter AFS) abgelegt werden, in dem auch die HTML-Seiten, Bilder etc. liegen. Sie werden vom Webdämon an der Endung .php erkannt. Der Webdämon sucht in den AFS-Verzeichnissen automatisch nach Dateien index.htm(l) (was er als statische HTML-Seite sofort ausliefert) oder index.php (was als PHP-Skript interpretiert wird). Die Voraussetzungen für die Ausführung von PHP-Skripten im Dokumentenbereich sind also:

  • Ablage im Dokumentenbereich (/afs/lrz-muenchen.de/user/<DIR>/<Benutzerkennung>/webserver/webdata/)
  • Dateiname endet auf .php
  • AFS-Leserecht für Webdämon ("somebody")

Wichtige Einschränkung der PHP-Skripte unter AFS ist der bereits beschriebene Safe Mode. PHP-Skripte, die lediglich Webseiten ausliefern, sind dadurch nicht weiter eingeschränkt.

PHP-MOD: Dateipfad und URL

Bei PHP-Skripten im Dokumentenbereich ist der Zusammenhang von Dateipfad und URL genau so wie bei statischen HTML-Seiten, Stylesheets, Bildern, usw.:

Dateipfad /afs/lrz-muenchen.de/user/<DIR>/<Benutzerkennung>/webserver/webdata/<Subdirectory>/<script>.php
URL http[s]://<www.mein-servername.de>/<Subdirectory>/<script>.php

Beispiel:

Dateipfad /afs/lrz-muenchen.de/user/x/uv999wx/webserver/webdata/intro.php
URL http://www.mein-servername.de/intro.php

PHP-MOD: Beispiel für PHP-Skript

Der PHP-Code kann innerhalb der Datei an beliebiger Stelle eingefügt werden:

<html>
  <head>
    <title>Meine PHP-Homepage</title>
  </head>

  <body bgcolor="ffffff">
<?php
echo 'Hallo, Welt';
?>
....
  </body>

</html>