CGI-Scripte

Jeder Inter.net-Nutzer hat die Möglichkeit, für seine Homepage auch CGI-Skripte zu erstellen und diese in seine HTML-Dokumente einzubinden.

Die CGI-Skripte können in einer der folgenden Programmiersprachen geschrieben sein:

Perl (Version 5.8.8, Stand 01/09)
PHP (Version 5.2.8)

Wichtige Hinweise:
Beachten Sie bitte, dass unabhängig von den eventuellen Fehlern in Ihren Skripten immer die gleiche Standard-Fehlermeldung "Internal Server Error" angezeigt wird, die leider keinen Rückschluß auf die Fehlerursache zuläßt.

In Perl-Skripten sollten Sie die daher Zeile

use CGI::Carp qw(fatalsToBrowser);

als erste Anweisung einfügen (hinter #!/usr/local/bin/perl). Bei Fehlern werden dann i.d.R. präzisere Fehlermeldungen in Ihrem Browser ausgegeben.

Wir bitten um Ihr Verständnis, daß wir keinerlei Support für externe Produkte, d.h. Ihre oder von Dritten erstellte Skripte, übernehmen können. Unabhängig vom Wortlaut der Fehlermeldung kann Ihnen daher auch unser Webmaster in diesem Fall nicht weiter helfen.

Bei diesbezüglichen Anfragen und Problemen finden Sie Unterstützung in den News-Gruppen, z.B. in snafu.technik oder über unsere Seite "User helfen Usern".

cgi.snafu.de

Inter.net bietet als Service CGI (Common Gateway Interface) auf einem eigenständigen, speziell dafür vorgesehenen Rechner (CGI-Server) an. Dieser CGI-Server heißt "cgi.snafu.de".

CGIs laufen auf dem CGI-Server und tragen die User-ID des Eigentümers. Dies erhöht die Sicherheit sowohl für Inter.net (amoklaufende CGIs stören nicht die anderen Dienste wie beispielsweise Mail) als auch für die User (von CGIs erzeugte Dateien müssen nicht mehr für alle lesbar und schreibbar sein).

Für jeden Bereich existiert eine eigenständige Maschine:

User-Webseiten -> home.snafu.de
CGIs (für User) -> cgi.snafu.de
Inter.net-Webserver -> www.snafu.de

Webseiten werden per FTP auf "home.snafu.de" übertragen und aktualisiert.

Wie installiere ich CGIs auf dem CGI-Server?

Das Wichtigste vorweg: Wer CGIs auf dem CGI-Server benutzen möchte, muss sich vorher im über unser Service-Interface (https://service.snafu.de/selfcare) dafür anmelden. Es entstehen keine zusätzlichen Kosten.

Auch wenn der CGI-Server eine eigenständige Maschine ist, werden CGIs per FTP-Login zentral auf "home.snafu.de" installiert und verwaltet. Also merken: *ein* Login für Webseiten und CGIs!

Im Home-Verzeichnis jedes Users gibt es neben "public_html" (für die normalen Webseiten) zwei weitere Verzeichnisse:

user-cgi-bin
user-cgi-doc

In "user-cgi-bin" werden CGI-Programme (Perl, PHP usw.) abgelegt. CGI-Programme dürfen nicht in Unterverzeichnissen liegen, sondern nur direkt unter "user-cgi-bin". (Konfigurationsdateien und andere nicht-ausführbare Dateien können jedoch sehr wohl in eigenen Verzeichnissen untergebracht werden.)

In "user-cgi-doc" dürfen CGI-Programme eigene Daten ablegen (dies ist unter "public_html" nämlich nicht erlaubt). Auch Webseiten mit SSI (Server Side Includes) haben hier ihren Platz.

CGIs haben als aktuelles Verzeichnis das, in dem sie liegen, also "user-cgi-bin" im Home-Verzeichnis des Users.

Für die Inhalte in "user-cgi-bin" und "user-cgi-doc" gilt eine Diskquota von zusammen 1 MB (snafu.start) bzw. 5 MB (snafu.unlimited) Speicherplatz.

Da CGIs auf "cgi.snafu.de" laufen, haben sie im Filesystem nur Zugriff auf die beiden Verzeichnisse "user-cgi-bin" und "user-cgi-doc" des Users. Ein Zugriff auf "public_html" ist nicht möglich, da dieses Verzeichnis nicht auf dem CGI-Server liegt.

Diese Trennung wurde aus Sicherheits- und Stabilitätsgründen vorgenommen. Mit dieser Konfiguration können (bewusst) fehlerhaft programmierte CGIs nun nicht mehr den Server erreichen, auf dem Sie Ihre Dateien abgelegt haben und dort Schaden anrichten.

Dadurch gibt es immer dann ein Problem, wenn zum Beispiel ein CGI bestimmte Dateien oder Verzeichnisse mit einem Passwortschutz versehen soll, diese Dateien aber im oder unterhalb von "public_html" liegen.

Lösung: Die zu schützenden Dateien in einem Verzeichnis ablegen, das unter "user-cgi-doc" eingerichtet wurde. Dort ist der Zugriff des Skripts dann wieder möglich. Entsprechendes gilt natürlich auch für die Dateien, die in anderer Weise durch CGIs lesend oder schreibend benutzt werden.

Das bedeutet auch, dass das Home-Verzeichnis der CGIs nicht identisch mit Ihrem User-Home-Verzeichnis ist. Die richtige relative Pfadangabe für das Home-Verzeichnis der CGIs würde also

"../user-cgi-bin"
oder
"../user-cgi-doc"

lauten.

Beachten Sie bitte, dass Sie mit diesem Auslagern von Dateien sparsam umgehen sollten, weil die Diskquota hier begrenzt ist (siehe oben).

Sonderfall ".htaccess": Eine Ausnahme von dieser generellen Regel bildet die Benutzung von ".htaccess". Diese Möglichkeit, Verzeichnisse mit einem Passwortschutz zu versehen, kann sowohl auf "cgi.snafu.de" als auch auf "home.snafu.de" genutzt werden.

Konkret: Der Pfadname der folgenden ".htaccess"-Datei ist für den Einsatz auf "cgi.snafu.de" angepasst:

AuthUserFile /users/sn/snafu.de/US/USERNAME/user-cgi-doc/.htpasswd
AuthGroupFile /dev/null
AuthName "Protected Area"
AuthType Basic

require valid-user USERNAME

Und diese ".htaccess" sucht ihr ".htpasswd" auf "home.snafu.de":

AuthUserFile /users/sn/snafu.de/US/USERNAME/public_html/.htpasswd
AuthGroupFile /dev/null
AuthName "Protected Area"
AuthType Basic

require valid-user USERNAME

Beachten Sie bitte, dass ".htaccess" ausnahmsweise absolute Pfadangaben benötigt.

Und hier noch ein Hinweis auf einen möglichen Stolperstein:

Wer ein CGI-Script unter "user-cgi-bin" dafür einsetzen möchte, .htaccess mit der entsprechenden Datei, in der die Passwörter enthalten sind (zum Beispiel ".htpasswd" - der Name dieser Datei ist frei wählbar), auf "home.snafu.de" zu erzeugen und evtl. sogar zu verwalten, unterliegt wieder der Einschränkung, dass CGI's nicht auf die Dateibereiche zugreifen können, die sich in oder unter public_html auf "home.snafu.de" befinden.

In einem solchen Fall muss der etwas umständliche Weg beschritten werden, .htaccess zunächst mit dem CGI-Script auf "cgi.snafu.de" zu erzeugen (also in "user-cgi-bin" oder "user-cgi-doc), um sie dann per FTP auf "home.snafu.de" in das Verzeichnis zu übertragen, das dort geschützt werden soll.

Bitte beachten Sie in einem solchen Fall, dass Sie die Pfadangaben in ".htaccess" nach der Übertragung anpassen müssen (siehe oben).

Und noch ein Hinweis:
Ein CGI arbeitet unabhängig vom Apache-Webserver. Jedes CGI ist daher selbst für Zugriffskontrollen verantwortlich, da es den Webserver - und damit auch die .htaccess-Kontrolle - umgeht und direkt auf alle Ressourcen zugreift.

Wenn also ein Unterverzeichnis in "user-cgi-doc" durch .htaccess gegen unbefugten Zugriff geschützt werden soll, dann funktioniert dieser Schutz bei allen direkten http-Zugriffen - zum Beispiel über eine solche URL, in der der konkrete Name der Datei genannt ist, auf die man zugreifen will (http://cgi.BeispielDomain.de/user-cgi-doc/Unterverzeichnis/KonkreteDatei.html). Bei einem Aufruf der in diesem Verzeichnis abgelegten Inhalte durch ein CGI hingegen funktioniert dieser Schutz nicht.

top

Wie rufe ich CGIs auf dem neuen CGI-Server auf?

CGIs müssen grundsätzlich mit absoluter URL von "cgi.snafu.de" aufgerufen werden. Dies ist notwendig, um alle üblichen Arten von CGIs unterstützen zu können.

Wie läuft das genau ab? Ein Beispiel sagt mehr als tausend Worte: Ein CGI-Skript soll das Shell-Environment ausgeben und das Datum jedes Zugriffs in einer Log-Datei mitprotokollieren.

Folgendes Skript wurde per FTP-Login auf "home.snafu.de" im Verzeichnis "user-cgi-bin" unter dem Namen "printenv.sh" installiert:

#!/bin/sh

# output HTTP header
echo "Content-Type: text/plain"
echo ""

# print environment
env

# log access
date >> ../user-cgi-doc/printenv_log.txt

Aufgerufen wird das Skript mit folgender URL:

http://cgi.snafu.de/USERNAME/user-cgi-bin/printenv.sh

Statt "USERNAME" muß man natürlich seinen Login-Namen einsetzen, den man unter "home.snafu.de" hat.

Beachten Sie bitte hier sowie immer dort, wo diese Bezeichnung verwendet wird, dass USERNAME nicht Ihre eMail-Adresse ist. Gemeint ist hier der Teil Ihres Benutzernamens vor dem "@". Und US steht für die beiden ersten Buchstaben dieses USernamens, also bei "otto" zum Beispiel "ot" (natürlich ohne die "").

Die Log-Datei mit den Zugriffen befindet sich ebenfalls auf dem CGI-Server, und zwar unter folgender URL:

http://cgi.snafu.de/USERNAME/user-cgi-doc/printenv_log.txt

Die Verwendung absoluter Pfadnamen im Dateibaum ist nicht erlaubt. Statt absoluter müssen relative Pfadnamen verwendet werden!

Wird ein CGI-Programm gestartet, ist sein aktuelles Verzeichnis das, worin es selbst liegt - also "user-cgi-bin" im Home-Verzeichnis des Users. Soll ein CGI auf eine Datei in "user-cgi-doc" zugreifen, muss deren relativer Pfad angegeben werden. Dies geschieht durch Voranstellen von "../user-cgi-doc/" (siehe Beispiel oben).

Manche CGIs werten den sogenannten "Referer" oder ähnliche Daten aus. Wer solche CGIs benutzt, muss in ihnen "cgi.snafu.de" oder "home.snafu.de" verwenden.

top

Wie benutze ich SSI (Server Side Includes) korrekt?

Die Verwendung von SSI ist sowohl auf "home.snafu.de" als auch auf "cgi.snafu.de" möglich. Die "exec"-Direktive (exec cmd, exec cgi) steht jedoch nur eingeschränkt zur Verfügung.

Auf "home.snafu.de" ist "exec cgi" erlaubt, jedoch nur für spezielle, von Inter.net vordefinierte CGIs (Mail-Formular, Gästebuch usw.) Dieser Service steht derzeit aber noch nicht zur Verfügung.

Auf "cgi.snafu.de" ist "exec cgi" für eigene CGIs erlaubt.

Da sich auf "cgi.snafu.de" im Verzeichnis "user-cgi-bin" nur ausführbare Skripts und Programme befinden dürfen, müssen auf diesem Server HTML-Seiten unter "user-cgi-doc" abgelegt werden. Entsprechend geschieht dann auch der Zugriff im Webbrowser auf solche HTML-Seiten:

http://cgi.snafu.de/USERNAME/user-cgi-doc/seite_mit_ssi.shtml

Der HTML-Code in der Datei "seite_mit_ssi.shtml" könnte etwa folgendermaßen aussehen ("USERNAME" ist durch den eigenen Login-Namen zu ersetzen):

Der Aufruf ähnelt dem in richtigen URLs, jedoch wird bei "exec cgi" einfach der führende Teil "http://cgi.snafu.de" weggelassen und nur der lokale Teil ("/USERNAME/user-cgi-bin/") angegeben.

Prinzipbedingt kann auf der Eingangsseite einer Homepage (also "http://home.snafu.de/USERNAME/index.html") kein vom Benutzer erstelltes CGI per SSI gestartet werden, weil diese Seite immer auf "home.snafu.de" landet, wo User-eigene CGIs nicht unterstützt werden. Nur die von Inter.net vorgefertigten CGIs können direkt auf der Homepage benutzt werden.

top

Wie binde ich PHP in meine Webseiten ein?

PHP wird ausschließlich als CGI unterstützt.

Dies ist notwendig, damit auch PHP-Anweisungen unter der User-ID des jeweiligen Users laufen und somit Zugriff auf die Dateien im Verzeichnis "user-cgi-doc" haben.

Da PHP-Skripts wie CGIs gestartet werden, müssen sie wie CGIs im Verzeichnis "user-cgi-bin" deponiert werden. Ein solches PHP-Skript könnte etwa folgendermaßen aussehen:

Der Aufruf geschieht wie bei herkömmlichen CGIs (siehe dort).

HTML- und PHP-Code können - wie man sieht - beliebig gemischt werden. Im Grunde entspricht PHP per CGI einer normalen HTML-Seite (mit eingebettetem PHP-Code), welcher die Zeile "#!/usr/local/bin/php3" vorangestellt wird.

Auf dem CGI-Server wurde die PHP3-Version aktualisiert (3.0.15 -> 3.0.18) sowie testweise die aktuelle PHP4-Version (4.1.1) installiert. Änderungen sollten sich für die Nutzer von PHP3 nicht ergeben. Sie benutzen weiterhin "#!/usr/local/bin/php3" in ihren Skripts. Wer PHP4 nutzen will, verwendet "#!/usr/local/bin/php4" in seinen Skripts.

Wer entgegen diesen Anweisungen keine Versionsnummer beim Aufruf benutzt ("#!/usr/local/bin/php"), bekommt nun statt PHP3 das aktuelle PHP4. Die Logik ist simpel: Wer keine spezielle Version angibt, bekommt einfach die jeweils aktuelle Version.

Da die meisten PHP3-Skripts auch mit dem PHP4-Interpreter problemlos laufen, sollte selbst beim Ignorieren der CGI-Anleitung nicht gleich Schiffbruch erlitten werden.

top

Welche Programme stehen für CGI-Skripts zur Verfügung?

Für CGI-Skripts werden die folgenden Programme offiziell unterstützt:

/usr/local/bin/perl5
/usr/local/bin/php3

Zum Testen bietet sich auch "/bin/sh" an, jedoch ist das Programmieren sicherer CGI-Skripts damit sehr mühsam.

Dateiendungen von CGIs spielen keine Rolle. Alles in "user-cgi-bin" wird pauschal als Programm ausgeführt, sofern es die unter Unix übliche Ausführberechtigung (Execute-Permission, "chmod 755 ") hat.

Zeilenenden werden unter Unix mit einem LF (Line Feed) gesetzt, nicht mit dem unter DOS/Windows üblichen CRLF (Carriage Return + Line Feed). Eine automatisch Konvertierung findet statt, wenn vor der Übertragung per FTP der ASCII-Modus aktiviert wird.

top

Sind die Fehlermeldungen meiner CGIs verfügbar?

Im Verzeichnis "user-cgi-bin" wird in der Datei "error_log" die Fehlerausgabe (standard error) von CGIs mitprotokolliert. Dies ist hilfreich, um Fehlfunktionen von CGIs eigenständig nachgehen zu können.

Die Datei wird auf die Quota des jeweiligen Users angerechnet und sollte daher regelmäßig kontrolliert und anschließend gelöscht werden.

Eine beliebte Fehlermeldung in der Datei "error_log" ist folgende:

failed to open log file
fopen: Permission denied

Dies hat seine Ursache meist in einem Tippfehler in der ersten Zeile des CGI-Skripts. Um zum Beispiel den Perl-Interpreter aufzurufen, muss dort folgendes stehen:

#!/usr/local/bin/perl5

Nicht "#/usr/local/bin/perl5" (Ausrufezeichen '!' vergessen) oder "!#/usr/local/bin/perl5" ('!' und '#' vertauscht).

top

Was tun bei "Internal Server Error"?

Eine große Anzahl von Direktiven in der Datei ".htaccess" wird nicht mehr unterstützt. Sollte die Fehlermeldung "Internal Server Error" auftauchen, liegt dies mit hoher Wahrscheinlichkeit an Problemen mit der Datei ".htaccess".

Hier hilft es oft, die Datei entweder ganz zu entfernen (meist wird sie gar nicht wirklich benötigt) oder zumindest die problematischen Zeilen zu entfernen (hier hilft nur "trial and error".

Wer Befehle der "Auth"-Gruppe benutzt, sollte darauf achten, "AuthName" gesetzt zu haben. Für die Datei ".htpasswd" ist üblicherweise ein absoluter Pfad im Filesystem anzugeben, der auf "home.snafu.de" wie folgt aussieht:

/users/sn/snafu.de/US/USERNAME/public_html/...

Dabei ist "USERNAME" durch den Login-Account (ohne angehängte Domain) zu ersetzen und "US" durch die ersten zwei Buchstaben des Login-Accounts. Aus technischen Gründen ist dieser Pfad im FTP-Client nicht verfügbar - im FTP-Client sieht man "temporäre" Pfade, die nur für die aktuelle Sitzung gültig sind und nicht gespeichert oder für andere Zwecke verwendet werden dürfen.

Ein anderer beliebter Fehler sind zu weitreichende Zugriffsrechte auf CGI-Programme und das Verzeichnis "user-cgi-bin". CGIs dürfen maximal die Rechte "755" (also lesbar und ausführbar für alle, aber nur schreibbar von einem selbst) besitzen - nicht "775" (auch schreibbar für die Gruppe) oder "777" (schreibbar für alle). Diese Rechte (755) sind notwendig, da man ja nicht möchte, dass andere User einem unbemerkt CGIs verändern.

Besonderes Augenmerk gilt dem Verzeichnis "user-cgi-bin", dessen Zugriffsrechte nicht geändert werden dürfen und daher am besten auf dem Standard verbleiben (Mode 755).

top

Warum kann mein CGI keine IP-Verbindungen herstellen?

Leider ist es inzwischen in Mode gekommen, CGIs und Shell-Accounts bei Internet-Providern zu missbrauchen, um DoS-Attacken (Denial of Service) gegen fremde Systeme auszuführen.

Aus diesem Grund können vom Rechner "cgi.snafu.de" im wesentlichen keine Internet-Verbindungen nach außen geöffnet werden.

Da CGIs normalerweise lokal auf dem CGI-Server ablaufen, ist diese Einschränkung in der Regel bedeutungslos. Allerdings sind Anwendungen wie zum Beispiel die Abfrage externer SQL-Datenbanken dadurch nicht möglich...

top

Ich habe eine eigene Domain - wie geht das mit CGI dort?

Wer eine eigene Domain hat, kann natürlich auch dort CGIs benutzen. Zusätzlich zu "www.DOMAIN.de" existiert "cgi.DOMAIN.de" im DNS, wo es die gewohnte Unterteilung in "user-cgi-bin" und "user-cgi-doc" gibt.

Folgende Schreibweisen sind jeweils gleichbedeutend:

http://home.snafu.de/USERNAME/...
http://www.DOMAIN.de/...

http://cgi.snafu.de/USERNAME/user-cgi-bin/...
http://cgi.DOMAIN.de/user-cgi-bin/...

http://cgi.snafu.de/USERNAME/user-cgi-doc/...
http://cgi.DOMAIN.de/user-cgi-doc/...

Hätte beispielsweise der User mit dem Login-Account "maxmuster" die Domain "mustermann.de", dann wären folgende Paare von URLs jeweils gleichbedeutend:

http://home.snafu.de/maxmuster/
http://www.mustermann.de/

http://cgi.snafu.de/maxmuster/user-cgi-bin/counter.pl
http://cgi.mustermann.de/user-cgi-bin/counter.pl

http://cgi.snafu.de/maxmuster/user-cgi-doc/foo.html
http://cgi.mustermann.de/user-cgi-doc/foo.html

Die Installation der Webseiten geschieht grundsätzlich unter dem Basis-Zugang bei Inter.net, in unserem Beispiel also "maxmuster". Die URLs mit der eigenen Domain (mustermann.de) werden vom Webserver intern auf den Basis-Zugang umgeleitet.

top

Hat jeder User jetzt mehrere Accounts?

Obwohl "home.snafu.de" und "cgi.snafu.de" verschiedene Server sind, wird alles über den zentralen Account auf "home.snafu.de" abgewickelt. Ein Login auf "cgi.snafu.de" ist nicht notwendig.

top

Zugriffsrechte

Ein immer wieder auftretendes Grundproblem bei CGIs waren falsch gesetzte Zugriffsrechte (Permissions). Durch cgi.snafu.de ist das erheblich vereinfacht worden. Es ist nun nicht mehr nötig in den drei Rubriken "owner", "group" und "others" diese Zugriffsrechte detailliert zu vergeben.

Die CGIs laufen unter der User-ID des Users. Wenn CGIs auf Dateien zugreifen sollen, ist es daher nicht unbedingt notwendig, die Dateien für alle lesbar bzw. schreibbar zu machen.