Webserver Apache: Admin-Skripte mit CGI selbst erstellen

Wer dynamische Seiten oder ganze Anwendungen auf seinen Apache-Webserver bringen möchte, kann dazu die Schnittstelle CGI nutzen. Sie hat den Vorteil, dass sie auf nahezu jedem Webserver zur Verfügung steht, auch unter Windows mit Microsoft IIS.

Außerdem kann man sie mit jeder Sprache auf einfache Art und Weise nutzen. Möglich sind beispielsweise einfache .BAT-Dateien unter Windows oder Shell-Skripte unter Unix. So können auch Einsteiger, die kaum Programmierkenntnisse besitzen, eigene Webanwendungen erstellen.

Klarer Nachteil von CGI ist die Performance. CGI-Anwendungen erzeugen bei jedem Webrequest einen eigenen externen Prozess, was entsprechend Zeit kostet. Für Websites mit vielen Usern ist CGI daher wenig geeignet.

Wegen seiner Flexibilität, Plattformunabhängigkeit und Einfachheit ist CGI aber nach wie vor beliebt. Besonders geeignet ist es, um einem Webadministrator schnell und unkompliziert Status-Informationen über seinen Webserver und sein Betriebssystem zu geben. Geschwindigkeit spielt dabei meist keine Rolle, weil diese administrativen Requests nur einen Bruchteil ausmachen und hinsichtlich der Performance kaum ins Gewicht fallen.

Um eine Apache-Website CGI-fähig zu machen, kann man beispielsweise die nachfolgende Config-Datei verwenden. Einsteiger, die noch keine Erfahrung mit Apache haben, können zum besseren Verständnis auf den ZDNet-Artikel "Hosting auf dem Root-Server: So konfiguriert man Apache" zurückgreifen.

In dieser Konfigurationsdatei befinden sich die statischen HTML-Seiten im Verzeichnis /var/www. Die CGI-Programme für die Website sind im Verzeichnis /var/cgi-bin/www.

Der Befehl ScriptAlias leitet das virtuelle Verzeichnis /cgi-bin zu /var/cgi-bin/www um. Um also das CGI-Skript /var/cgi-bin/www/test auszuführen, muss ein Client in seinem Browser die URL http://Apache1.ZDNetLabs.Darktech.org/cgi-bin/test verwenden.

Mit der Option +ExecCGI wird die Ausführung von CGI-Skripten erlaubt, -Indexes verhindert, dass die Skripte aufgelistet werden können. Mit -MultiViews verlangt man, dass die Skriptnamen exakt eingegeben werden müssen.

+FollowSymLinks erspart die Prüfung, ob eine Datei ein symbolischer Link ist, was die Performance erhöht. Der Admin muss daher selbst darauf achten, dass kein Link aus dem HTML-Verzeichnis in das Skript-Verzeichnis zeigt, sonst können User den Sourcecode des Skripts herunterladen.

Nach der Änderung der Konfigurationsdatei muss der Apache-Server neu gestartet werden. Das macht man am besten mit

apache2ctl configtest
apache2ctl graceful

Danach kann man CGI-Dateien in das Verzeichnis /var/cgi-bin/www legen.

So einfach funktionieren CGI-Skripte

CGI-Anwendungen kommunizieren mit dem Webserver über Standard-Input und Standard-Output sowie Umgebungsvariablen. Dadurch erklärt sich ihre Einfachheit. Ein simples Skript muss lediglich den Header und die eigentliche Datei an Standard-Output ausgeben. Zwischen Header und Datei kommt eine Leerzeile. Im Header muss mindestens der Content-Type stehen.

In einem ersten Beispiel soll ein Bash-Skript erstellt werden, das den Inhalt der Log-Verzeichnisse (/var/log und Unterverzeichnisse) an den Client-Browser übergibt. Dazu wird die Datei /var/cgi-bin/www/test mit folgendem Inhalt erstellt:

Zunächst wird mit einem einfachen Echo-Befehl der Header ausgegeben. Dann folgt eine Leerzeile und danach kommt der eigentliche HTML-Text. Bis auf die Zeile "ls -laFR /var/log" handelt es sich um Echo-Befehle, die HTML-Code an Standard-Output übergeben.

Das Ergebnis ist zwar absolut korrekt, aber von der Formatierung her nicht zufriedenstellend. Das zeigt das nachfolgende Bild.

HTML behandelt mehrere Leerzeichen hintereinander als nur eines und wandelt darüber hinaus Zeilenumbrüche und andere Whitespace-Zeichen in Leerzeichen um. Ferner benutzen die gängigen Browser per Default eine Proportionalschrift.

Alle drei Probleme lassen sich dadurch lösen, dass man die Ausgabe von „ls -laFR /var/log“ zwischen <pre> und </pre> setzt. Danach sieht das Skript wie folgt aus:

Die Ausgabe im Browser wird nun besser dargestellt:

Doch der erste Eindruck täuscht. Kämen im Text die Zeichen <, > oder & vor, würde das dazu führen, dass der Browser sie als HTML-Tags interpretiert. Man muss daher < durch &​lt;, > durch &​gt; und & durch &​amp; ersetzen.

Das geht relativ einfach mit einer Funktion htmlout im Skript, der man praktischerweise gleich die Tags <pre> und </pre> hinzufügt. Mit der Zeile "htmlout <Unix-Befehl>" kann man so die Ausgabe jedes Unix-Kommandos für den Browser formatieren. Das Beispielskript sieht dann so aus:

Man beachte, dass vor der Zeile "ls -laFR /var/log" jetzt das Wort "htmlout" steht. Das bewirkt, dass die Ausgabe durch die vorher definierte Funktion htmlout formatiert wird.

Nutzung von Servervariablen

CGI definiert einige Umgebungsvariablen, die man in Skripten nutzen kann. Eine vollständige Liste aller Variablen ist in RFC 3875 aufgeführt. Gegeben sei beispielsweise folgendes Skript:

Es führt zu folgender Browser-Ausgabe:

Dynamische Parameter

Parameter, die per GET übergeben werden, finden sich in der Umgebungsvariable QUERY_STRING. Parameter, die mit POST submittet werden, können über Standard-Input gelesen werden.

Einfache Sprachen, etwa Windows-Batch-Skripte oder Unix-Bash-Skripte, sind für die Auswertung komplexer Webformulare oft ungeeignet, da die Parameter in der Regel URL-kodiert sind. Den Sprachen mangelt es an leicht zu benutzenden Parsern für URL-Encoding.

Wenn man es mit der Komplexität jedoch nicht übertreibt, lassen sich aber durchaus praktikable Lösungen entwickeln. Angenommen, man betreibt auf einem Server zwanzig verschiedene Named Virtual Hosts mit eigenen Domainnamen und sucht als Admin eine schnelle Möglichkeit, zu prüfen, ob die DNS-Server funktionieren – vor allem, ob der primäre DNS auch seine Secondaries mit Updates versorgt.

Sinnvoll ist ein dazu Skript, das den Domainnamen als Parameter akzeptiert und mittels dig die notwendigen Überprüfungen macht. Falls GET-Parameter mit Leerzeichen getrennt sind, werden sie auch als Kommandozeilenparameter an das Skript übergeben und nicht nur in die Variable QUERY_STRING geschrieben. Das kann man sich zunutze machen, indem man folgendes Skript verwendet:

Ruft man nun die URL http://apache1.zdnetlabs.darktech.org/cgi-bin/test?dns+ZDNet.de auf, wird die DNS-Konfiguration von ZDNet.de einem einfachen Check unterzogen. Im Browser erscheint Folgendes:

So erkennt man beispielsweise im Nameserver-Abgleich, das die Serial auf allen Servern 2011101720 beträgt. Der Update der sekundären DNS-Server funktioniert also. Im DNS-Trace lässt sich unter anderem ablesen, ob die Glue-Records richtig gesetzt sind.

Weitere sinnvolle Befehle, mit denen man schnell überprüfen kann, ob mit dem Server etwas nicht stimmt, sind etwa ps -lefww f, um eine Prozessliste anzuzeigen. So sieht man, ob alle Daemonen noch laufen oder etwa ein Virus einen Prozess erzeugt hat, der schleunigst entfernt werden muss.

Mit df -h lässt sich die Belegung der Festplatte prüfen und free zeigt an, ob genügend Hauptspeicher vorhanden ist. Über netstat -lnutpvwee kann man ermitteln, auf welche TCP- und UDP-Ports der Server reagiert. Auch auf diese Weise kann man verdächtige Software entdecken, die etwa Befehle über einen TCP-Port entgegennimmt.

CGI-Skripte gegen unbefugte Nutzung sichern

Wer sich mittels CGI-Skripten sensitive Informationen über seinen Server holt, will diese Abfragen in der Regel nicht für jeden zulassen. Man sollte sie daher mit einem Passwort schützen. Am einfachsten erreicht man das, indem man der Apache-Konfiguration seines Skriptverzeichnis folgende Zeilen hinzufügt:

authType basic
authName "Geheimbereich fuer Admins"
AuthUserFile /etc/apache2/user1.txt
require valid-user

Die Apache-Config-Datei könnte beispielsweise wie folgt aussehen:

Für AuthUserFile kann man jeden beliebigen Dateinamen wählen. Den ersten Nutzer richtet man mit dem Befehl htpasswd -c /etc/apache2/user1.txt <username> ein, etwa htpasswd -c /etc/apache2/user1.txt admin. Anschließend fragt das Programm nach dem Passwort für den User admin. Will man weitere Nutzer einrichten, ruft man htpasswd ohne den Parameter -c auf. -c bewirkt, dass die Passwort-Datei neu initialisiert wird. Das heißt, alle bisherigen Nutzer werden gelöscht.

Es existieren zahlreiche weitere Authentifizierungsmöglichkeiten in Apache, etwa über ein PAM-Modul oder die Anbindung an eine MySQL-Datenbank. An dieser Stelle soll aber nur die einfache Möglichkeit über eine Passwort-Textdatei erläutert werden.

Der Authentifizierungsmechanismus Basic führt natürlich dazu, dass Kennwörter in Klartext übertragen werden. Man kann stattdessen Digest verwenden, was in der Apache-Dokumentation näher erläutert wird. Digest ist sicherer, wird aber von älteren Browsern nicht oder nicht korrekt unterstützt.

Die praktikableste Möglichkeit ist, auf Basic in Kombination mit SSL-Verschlüsselung zu setzen. Dann wird nicht nur das Passwort, sondern die gesamte Kommunikation verschlüsselt. Wie man SSL-Sites mit Apache aufsetzt, zeigt der ZDNet-Artikel "Apache: Verschlüsselung und Webanwendungen einrichten".

Fazit

CGI ist sicherlich nicht das Interface der Wahl, wenn es um hochperformante, auf Durchsatz getrimmte Webanwendungen geht. Aber es hat den Vorteil, dass es für nahezu alle Webserverplattformen zur Verfügung steht und auch mit einfachen Skriptsprachen genutzt werden kann. Dazu gehören sogar Windows-Batch-Files (*.BAT).

CGI ist jedoch besonders gut geeignet, um administrative Aufgaben zu erledigen, etwa die Überwachung von Leistungsparametern und Vitalzeichen eines Servers. Um zu überprüfen, ob ihr Server noch einwandfrei funktioniert, können sich Administratoren leicht eine Statuspage bauen.

Dies ist sicherlich auch möglich, indem man sich per SSH einloggt und Befehl und Skripte von Hand aufruft. Wer sich jedoch ein Webinterface erstellt, kann auf einfache Art und Weise von überall zugreifen, etwa aus dem Internetcafé, aber auch per Smartphone und Tablet. Nicht immer steht ein SSH-Client zur Verfügung.