Ein neuer Webserver für die Uni Wien

von Peter Marksteiner (Ausgabe 01/3, 2001)

 

Die Universität im WWW: Die ersten sechs Jahre

Seit 8. August 2001 hat die Universität Wien einen neuen Webserver: Am Abend dieses Tages wurde der Server WWW.UNIVIE.AC.AT auf eine neue, leistungsfähigere Hardware übersiedelt. Von der Öffentlichkeit blieb dies weitgehend unbemerkt - es gab nur eine kurze Unterbrechung des Betriebs, und am Aussehen der Homepage hat sich nichts geändert. Zu diesem Anlaß sei ein kurzer Rückblick auf die Anfänge des WWW an der Uni Wien gestattet.

Der erste offizielle Webserver der Universität Wien - damals "Info-Server" genannt - wurde im Comment 95/1 angekündigt und mit Beginn des Sommersemesters 1995 in Betrieb genommen. Damals war bei weitem noch nicht klar, daß sich das WorldWideWeb als weltweites Informationssystem allein durchsetzen und alle anderen praktisch vollständig verdrängen würde. (Eine Zeitlang wurden an der Uni Wien auch andere Informationssysteme - Hyper-G, Gopher - betrieben, aber bald wieder eingestellt.) Die Inhalte der ersten Uni-Homepage waren noch ziemlich dürftig. Bald jedoch präsentierten die ersten Institute ihre Webseiten, und sehr früh gab es die erste Datenbankapplikation: Ein anfangs noch ziemlich rudimentäres Online-Personal- und Vorlesungsverzeichnis, das seither laufend verbessert wurde. Das Angebot und auch die Nachfrage nahmen rasch zu - schon nach einem Jahr gab es an die 100 000 Anfragen pro Tag, sodaß bald ein leistungsfähigerer Server benötigt wurde. Dieser wurde am 19. September 1997 in Betrieb genommen und erledigte bis zuletzt zufriedenstellend seine Aufgabe, obwohl die Belastung auf mehr als das Zehnfache anstieg. Ein Engpaß war lediglich die bescheidene Einzelprozessor-Leistung, die sich vor allem bei CGI-Skripts durch längere Wartezeiten bemerkbar machte.

Heute sind die Webseiten von über 600 Instituten und Universitätseinrichtungen, Abteilungen, Forschungsprojekten, Konferenzen usw. unter http://www.univie.ac.at/ zu finden. Der Server beherbergt auch 32 Virtual Hosts, die über eine eigene Adresse zu erreichen sind - z.B. Juridicum Online (http://www.juridicum.at/) oder die Homepage der Universitätsbibliothek (http://ub.univie.ac.at/). Eine halbe Million Dateien (davon 160 000 HTML-Dokumente) stehen der Öffentlichkeit zur Verfügung, das sind 30 GB an Daten. Dazu kommt noch der digitalisierte Zettelkatalog der Universitätsbibliothek (http://ub.univie.ac.at/ol_kat.htm), dessen acht Millionen Dateien 36 GB Plattenplatz belegen. Von den hunderttausenden Besuchern des Webservers (täglich werden zwischen ein und zwei Millionen Dokumente abgeholt) werden an die zehntausend pro Tag über Suchmaschinen - allen voran Google - an die Uni Wien vermittelt: Wer Informationen zu so unterschiedlichen Themen wie "Krautsuppendiät", "Unsinn des Lebens", "dumme Gesetze" oder "Ehebruch" sucht, wird hier fündig.

Wie sieht nun die nähere Zukunft aus? Die neue Hardware - eine IBM pSeries 640, fast baugleich mit dem neuen Mailbox-Rechner (siehe Comment 01/2) - ist vermutlich leistungsfähig genug, um einen weiteren Anstieg der Last auf das Zehnfache zu bewältigen. Änderungen wird es bei der Gestaltung der Homepage und generell beim Design der Web-Präsentation der Universität Wien geben: Der Zentrale Informatikdienst wird sich davon weitgehend zurückziehen und diese Aufgaben dem Zentrum für Forschungsförderung, Drittmittel und Öffentlichkeitsarbeit überlassen. Die technische Betreuung und die Administration der Subserver wird aber selbstverständlich weiter durch den ZID erfolgen.

Die folgenden Abschnitte dieses Artikels wenden sich vor allem an die Betreiber von Instituts-Homepages und sonstigen Subservern auf WWW.UNIVIE.AC.AT und beschreiben die neuen Services und organisatorischen Änderungen, die gleichzeitig mit der Erneuerung der Hardware und der Aktualisierung der Software (Betriebssystem: AIX; Webserver: Apache; Perl; verschiedene Utilities) eingeführt wurden. Details und aktuelle Informationen sind unter http://www.univie.ac.at/ZID/www/ zu finden.

Zugriffsstatistiken

Wer im WWW publiziert, interessiert sich naturgemäß dafür, welche seiner Dokumente wie oft und von wo aus abgerufen werden. Am Webserver der Uni Wien hatten die Betreiber von Subservern schon seit längerer Zeit die Möglichkeit, auf die entsprechenden Logfiles zuzugreifen. Auch einige Werkzeuge zur statistischen Auswertung standen zur Verfügung. Im Zuge der Server-Umstellung wurde dieses Service wesentlich verbessert: Das Kopieren der Logfiles und die Auswertung - mit drei verschiedenen Statistik-Programmen - geschehen jetzt vollautomatisch.

Bei neuvergebenen Benutzungsberechtigungen ist überhaupt nichts zu tun, um die Logfile-Auswertung zu aktivieren. Die bisherigen händischen oder halbautomatischen Verfahren können sehr einfach durch das neue System ersetzt werden; die Vorgangsweise ist unter http://www.univie.ac.at/ZID/www-logfiles/ beschrieben.

Sicherheit

Webserver sind üblicherweise für die ganze Welt offen und daher beliebte Ziele für Attacken aller Art. Auch wenn der berüchtigte "Code Red"-Wurm unserem Apache-Server nichts anhaben kann (er ist auf Internet Information Server von Microsoft spezialisiert), sollte man sich dessen bewußt sein, daß sich ein Webserver naturgemäß in einer exponierten Lage befindet und auch von einer Firewall nur teilweise geschützt werden kann, wenn sie ihn nicht in seiner Funktion behindern soll.1)

Beim Publizieren im WWW ist es daher besonders wichtig, daß gewisse Sicherheitsvorkehrungen (die immer und überall zu empfehlen sind) eingehalten werden - beispielsweise die Wahl eines sicheren Paßworts, das regelmäßige Ändern dieses Paßworts und die Verwendung von SSH und SCP/sFTP anstelle von Telnet und FTP.

Dateiattribute

In Bezug auf die Dateiattribute (file permissions) wird am Uni-Webserver nun ein neues Sicherheitskonzept angewendet. Dieses soll sicherstellen, daß der Webserver zwar ausreichende Privilegien hat, um seine Aufgabe zu erfüllen (d.h. Lesezugriff auf alle HTML-Dokumente), aber möglichst wenig sonstige Rechte, damit die Folgen eventueller Sicherheitslücken in der Server-Software so gering wie möglich gehalten werden können. Zusätzlich soll ausgeschlossen werden, daß Benutzer absichtlich oder irrtümlich auf die Daten anderer Benutzer zugreifen oder diese gar verändern können, sofern das vom Eigentümer der Daten nicht explizit gestattet wird.

Mit Standard-Unix-Permissions läßt sich dies nur schwer erreichen, deshalb wird eine AIX-spezifische Erweiterung verwendet: ACL (access control list).2) Der folgende Befehl zeigt die standardmäßig eingerichteten file permissions und ACL eines Benutzerverzeichnisses:

$ aclget /u/www/ihw
attributes:
base permissions
owner(ihw): rwx
group(ihw): ---
others: ---
extended permissions
enabled
permit r-x u:www
permit r-x u:wwwperl

Für jeden Benutzer gibt es eine eigene Gruppe (der Name der Gruppe ist gleich dem Usernamen); dies ist die einzige Gruppe, der der Benutzer angehört. Das ist eine entscheidende Verbesserung zum früheren Konzept, wo sich alle Benutzer in einer einzigen Gruppe (www) befanden.

Aufgrund der base permissions kann nur der Eigentümer (owner) des Verzeichnisses <tt>ihw</tt>, der Benutzer ihw, darauf zugreifen. Nachdem damit sichergestellt wird, daß der gesamte Inhalt dieses Verzeichnisses (alle Dateien und alle Unterverzeichnisse) mit Ausnahme des Eigentümers für niemanden erreichbar ist, sind für die darin enthaltenen Dateien keine weiteren Zugriffsbeschränkungen erforderlich. Diese können ohne Risiko world-readable sein:

$ ls -l index.html
-rw-r--r-- 1 ihw ihw 483 Aug 8 22:51 index.html

Allerdings muß auch der Webserver die Dateien lesen können. In unserem Fall läuft der Webserver als Benutzer www. Mittels extended permissions erhält er Zugriff auf das Benutzerverzeichnis, und da innerhalb dieses Verzeichnisses alles world-readable ist, kann er alle Dateien lesen. Der Secure Server https://www.univie.ac.at/ läuft mit den Berechtigungen des Benutzers wwwperl; daher müssen auch für diesen extended permissions eingerichtet werden.

Ein Spezialfall sind CGI-Skripts (mehr dazu siehe weiter unten): Am Webserver der Uni Wien sorgt der sogenannte Suexec-Wrapper dafür, daß CGI-Skripts mit den Rechten und Privilegien des jeweiligen Eigentümers laufen. Daher braucht der Benutzer www keine Zugriffsrechte auf ein CGI-Skript (sehr wohl aber auf das Verzeichnis, in dem es sich befindet):

$ ls -l test.cgi
-rwx------ 1 ihw ihw 1279 Oct 4 2000 test.cgi

Bei manchen "Altbeständen" ist dieses Konzept noch nicht zur Gänze verwirklicht - z.B. sind Dateien mitunter noch der Gruppe www zugeordnet. Wenn die Dateiattribute und ACL eines Verzeichnisses von den oben beschriebenen abweichen, können unter https://www.univie.ac.at/bin/html-perm/ die empfohlenen Zugriffsberechtigungen gesetzt werden.

mod_speling

Das Apache-Modul mod_speling - der Rechtschreibfehler ist Absicht! - bessert kleine Ungenauigkeiten beim Aufruf eines URLs automatisch aus. Es bewirkt z.B., daß ein Klient, der das nicht existierende Dokument www.univie.ac.at/zid/ anfordert, die Antwort erhält, dieses sei unter www.univie.ac.at/ZID/ zu finden.

Mit diesem sehr nützlichen (und daher auch am Uni-Webserver verfügbaren) Modul ist aber leider ein Sicherheitsproblem verbunden: Es kann leicht vorkommen, daß dadurch unbeabsichtigt Daten übers Web sichtbar werden. Ein Beispiel: Der Benutzer ihw bearbeitet ein CGI-Skript namens test.cgi und speichert eine ältere Version unter dem Namen test.bak ab. Nun will jemand dieses Skript aufrufen und vergißt dabei die Endung .cgi - er schreibt also www.univie.ac.at/ihw/test. Wenn innerhalb eines Verzeichnisses mehrere Dokumente mit ähnlichem Namen existieren, bietet mod_speling eine Auswahl an; wählt man hier test.bak, wird nicht das CGI-Skript ausgeführt, sondern der Quellcode angezeigt bzw. abgespeichert. Besonders problematisch ist das, wenn das Skript dazu dient, eine Datenbankverbindung zu öffnen: Bei diesem Vorgang läßt es sich nur schwer vermeiden, das Paßwort im Klartext anzugeben.

Um zu vermeiden, daß Daten unabsichtlich veröffentlicht werden, ist die folgende Vorgangsweise zu empfehlen:

  • Vergeben Sie restriktive Zugriffsberechtigungen für alle Dateien, die nicht für die Öffentlichkeit bestimmt sind. Wenn nur der Eigentümer (owner) die Datei test.bak lesen darf, kann sie auch der Webserver (der Benutzer www) nicht lesen.

  • Bei CGI-Skripts sollten häufig verwendete und sensitive Programmteile in Module verpackt werden. Beispielsweise kann die oben erwähnte Datenbankverbindung im Modul Connect.pm geöffnet werden. Das Klartext-Paßwort steht dann nur in einer einzigen Datei (die natürlich besonders gut geschützt werden muß), auch wenn das Modul von Dutzenden verschiedenen Skripts verwendet wird.

  • Mit der Direktive FilesMatch in der Datei .htaccess kann der Zugriff auf bestimmte Dateitypen gänzlich unterbunden werden - z.B.

    <FilesMatch *.pm>
    deny from all
    </FilesMatch>
  • Damit mod_speling funktioniert, benötigt der Webserver Lesezugriff (read permissions) auf das Verzeichnis, in dem sich die Dateien befinden (sonst genügen execute permissions). Man kann aber beispielsweise mit dem Befehl chmod go-r safedir den Lesezugriff auf das Verzeichnis safedir unterbinden - die "Rechtschreibprüfung" ist dann für dieses Verzeichnis überhaupt ausgeschaltet.

Mehr als nur HTML:
Programmieren am Webserver

Dateien wie HTML-Dokumente, Grafiken, Sound-Files usw. vom Server zum Klienten zu schicken, ist eine relativ triviale Aufgabe. Heute gehört zum WorldWideWeb jedoch viel mehr als das: Webseiten werden auf Anfrage des Klienten dynamisch generiert; Redakteure verwenden Content-Management-Systeme, um Webseiten aktuell und konsistent zu halten, und oft dient der Webserver nur als Front-End für komplexe Applikationen, die auf Datenbank-Servern laufen.

Für Aufgaben dieser Art kommen viele verschiedene Techniken zum Einsatz. Manche davon (z.B. CGI, Java) sind weitgehend portabel und können auf den unterschiedlichsten Plattformen verwendet werden; andere wie z.B. mod_perl sind auf Unix- bzw. Linux-Systeme und den Webserver Apache beschränkt. Im folgenden werden (ohne Anspruch auf Vollständigkeit) einige der wichtigsten Programmierwerkzeuge kurz vorgestellt - hauptsächlich solche, die für Apache geeignet sind. Apache wird einerseits auf allen zentralen Webservern der Uni Wien eingesetzt, andererseits ist es weltweit die mit Abstand beliebteste Webserver-Software: Laut einer Studie von Netcraft gilt für mehr als die Hälfte aller Webserver der Welt "powered by Apache"; weit abgeschlagen kommt auf Platz zwei der IIS von Microsoft; alle anderen wie z.B. Netscape Enterprise Server, Zeus oder Zope folgen unter "ferner liefen".

Die Methoden für das dynamische Generieren von Webseiten fallen im wesentlichen in zwei Klassen: Bei der einen (z.B. CGI) wird das gesamte HTML-Dokument - oder auch eine andere Datei, etwa ein GIF-Bild - von einem Programm erzeugt. Bei der zweiten (z.B. SSI, PHP, Embperl, ASP) wird Programm-Code in Form von speziellen Tags in das HTML-Dokument eingebettet. Der Webserver führt diesen Code aus - oder läßt ihn von einem externen Programm ausführen - und liefert dann das HTML-Dokument, erweitert um den Output des Programms, an den Klienten. Es existieren auch verschiedene hybride Formen. Der Vollständigkeit halber sei noch erwähnt, daß PHP und Embperl auch als externe Programme über die CGI-Schnittstelle laufen können; das ist jedoch unüblich und wesentlich weniger effizient.

CGI

Das Common Gateway Interface ist nach wie vor die von uns bevorzugte und empfohlene Methode, Webseiten dynamisch zu generieren. Auf den Webservern der Uni Wien gibt es dafür die weitestgehende Unterstützung - vor allem für in Perl geschriebene Skripts ist eine große Zahl von Modulen verfügbar, die die Programmierung erleichtern. CGI-Skripts können aber auch in anderen Sprachen geschrieben werden, z.B. C, C++, python und verschiedenen Shells. Da das Thema CGI bereits im Comment 99/1 ausführlich behandelt wurde, wird im folgenden lediglich auf die Vor- und Nachteile gegenüber den anderen hier beschriebenen Werkzeugen eingegangen.

Diese sind vor allem eine Konsequenz der Tatsache, daß jedesmal, wenn ein Klient ein mittels CGI-Skript generiertes Dokument anfordert, ein eigener Prozeß gestartet wird:

  • Die Rechte und Privilegien dieses Prozesses müssen nicht mit denen des Webservers übereinstimmen. In einem Multiuser-Betrieb ist es von essentieller Bedeutung für die Sicherheit, daß die Benutzer einander nicht in die Quere kommen können: Wir vertrauen zwar darauf, daß sich unsere Benutzer nicht mutwillig gegenseitig die Daten zerstören. Wir können uns allerdings nicht darauf verlassen, daß alle so hervorragende CGI-Programmierer sind, daß ihre Skripts frei von Sicherheitslücken sind (Hinweise und Literaturzitate zur sicheren CGI-Programmierung finden Sie im Kapitel Sicherheit des oben erwähnten Artikels). Auf den Webservern der Uni Wien sorgt der Suexec-Wrapper dafür, daß alle CGI-Skripts mit den Rechten ihrer Eigentümer laufen; wenn ein Hacker ein fehlerhaftes CGI-Skript dazu ausnützt, Daten zu löschen oder HTML-Dokumente zu verändern, hat den Schaden nur der, der für das Skript verantwortlich ist.

  • Der Prozeß, der ein CGI-Skript ausführt, wird nach Beantwortung der Klientenanfrage beendet. Daher kann man sich gewisse Programmierfehler und Schlampereien erlauben: Vergißt man beispielsweise, eine geöffnete Datei oder eine Datenbankverbindung wieder zu schließen, so geschieht das "von selbst" beim Beenden des Prozesses. Bei Techniken wie PHP oder mod_perl (siehe unten), wo ein einziger Prozeß lange läuft und sehr viele Anfragen beantwortet, können solche Fehler jedoch fatal sein. Darüber hinaus sind diese Methoden recht anfällig für memory leaks (ständig zunehmenden Speicherbedarf), die bei CGI-Skripts ausgeschlossen sind.

  • Der größte Nachteil von CGI ist die mangelnde Effizienz: Schon das Generieren (forking) eines neuen Prozesses ist mit einem beträchtlichen Ressourcen-Bedarf verbunden. Dann muß das Skript geladen und meist noch übersetzt (kompiliert) werden. Wird ein Skript zehntausendmal pro Tag aufgerufen, so werden diese Schritte eben zehntausendmal ausgeführt. Techniken wie mod_perl wurden hauptsächlich erfunden, um diesen überflüssigen Aufwand (overhead) zu vermeiden.

Auf dem neuen Webserver der Uni Wien halten sich die Performance-Probleme von CGI-Skripts allerdings in Grenzen: Ein kleines Skript, das ein größeres Modul (CGI.pm) lädt und sonst nicht viel tut, benötigt weniger als 0,2 Sekunden. Eine solche Verzögerung wird vom Klienten kaum wahrgenommen. Selbst das Öffnen einer Oracle-Datenbankverbindung dauert maximal 0,5 Sekunden, meistens jedoch deutlich kürzer. Der konstante Overhead, der sich durch mod_perl, FastCGI und dergleichen einsparen läßt, liegt daher im Bereich von wenigen Zehntelsekunden. Die Verwendung solcher Techniken ist also vor allem dann sinnvoll, wenn ein Skript tausende Male pro Tag aufgerufen wird und somit den Server merklich belastet.

Wenn ein CGI-Skript mehrere Sekunden benötigt, sodaß es vom Benutzer als langsam empfunden wird, ist der Grund eher beim Skript selbst und nicht beim Overhead der CGI-Schnittstelle zu suchen: Entweder ist es ineffizient programmiert und kann durch Optimierung beschleunigt werden, oder es führt tatsächlich so komplexe Operationen aus, daß es einfach nicht schneller geht. In beiden Fällen kann das CGI::Cache-Modul hilfreich sein, welches die Ergebnisse früherer Aufrufe des Skripts zwischenspeichert.

Server-Side Includes (SSI)

Server-Side Includes sind eine Erweiterung des Apache-Servers. Obwohl SSI nur über einen rudimentären "Wortschatz" verfügen und sich nicht mit ausgefeilten Programmiersprachen wie PHP messen können, sind sie erstaunlich leistungsfähig und ermöglichen es, mit einfachen Mitteln beachtliche Effekte zu erzielen. Beispielsweise erlauben es If-Then-Else-Konstrukte, verschiedenen Klienten verschiedene Versionen desselben Dokuments zu zeigen, abhängig vom Browser oder der IP-Adresse des Klienten. Allen Webdesignern sei die aufmerksame Lektüre der SSI-Dokumentation empfohlen - dort wird man jede Menge Anregungen finden.

Besonders nützlich sind Server-Side Includes, um einer Anzahl von HTML-Dokumenten eine einheitliche grafische Gestaltung zu verleihen. Wenn der HTML-Code, der allen Dokumenten gemeinsam sein soll (z.B. <BODY>-Tag mit Hintergrundfarbe, Logo, Navigationsleiste) in eine eigene Datei body.html geschrieben wird und alle anderen Dokumente die Zeile

enthalten, so braucht bei Änderungen des Designs nur eine einzige Datei modifiziert zu werden; das einheitliche Erscheinungsbild bleibt in jedem Fall erhalten.

Server-Side Includes werden auf allen zentralen Webservern der Uni Wien unterstützt. Es gibt nur eine kleine Einschränkung: Das Kommando exec cmd ist aus Sicherheitsgründen nicht erlaubt, weil es damit möglich wäre, beliebige Befehle mit den Privilegien des Benutzers www auszuführen. Man kann aber CGI-Skripts mit exec cgi oder include virtual in HTML-Dokumente einbetten.

PHP

Die Zeiten, da PHP noch eine simple Perl-Applikation war, deren Name sich von "Personal Homepage" ableitete, sind vorbei: Heute ist PHP (aktuelle Version: PHP4) eine eigene Programmiersprache; der Programm-Code wird wie erwähnt in HTML-Dokumente eingebettet. PHP verfügt über eine umfangreiche Bibliothek an Funktionen, die ein sehr effizientes Programmieren von dynamischen Web-Applikationen ermöglicht. Besonders bei Linux-Benutzern erfreut sich PHP großer Beliebtheit, da zahlreiche Linux-Distributionen mit einem vorkonfigurierten Apache mit PHP und MySQL ausgeliefert werden. Ähnlich wie mod_perl (siehe unten) ist PHP für einen Multiuser-Betrieb aber nur bedingt geeignet und wird deshalb auf WWW.UNIVIE.AC.AT nicht angeboten. Für Web-Projekte, die PHP verwenden wollen oder müssen, steht ein eigener Server (gerda.univie.ac.at) zur Verfügung. Mehr über diesen Server sowie über PHP, MySQL und PostgreSQL ist im Artikel General Repository for Database Applications (GERDA) zu finden.

mod_perl

Diese Technik ist das Resultat einer glücklichen Verbindung des Webservers Apache und der Programmiersprache Perl: Bei mod_perl wird in den Apache-Server ein kompletter Perl-Interpreter eingebaut. Damit steht einerseits eine Perl-Schnittstelle zum Apache-API (application programmer interface) zur Verfügung, mit der die Funktionalität des Webservers um beliebige in Perl geschriebene Module erweitert werden kann (zu diesem Thema sei das bei O'Reilly erschienene Buch Writing Apache Modules with Perl and C von Lincoln Stein und Doug MacEachern wärmstens empfohlen). Auch alle Webserver der Uni Wien haben zusätzliche Module, die teils in C und teils in Perl geschrieben sind - beispielsweise geschieht die Authentifizierung mit Unet- und Mailbox-Paßwörtern mit Hilfe eines Perl-Moduls. Andererseits kann mod_perl auch verwendet werden, um mittels eines Perl-Handlers dynamisch HTML-Dokumente zu generieren. Dazu benutzt man entweder direkt das Perl-API des Apache oder emuliert mit Hilfe des Apache::Registry-Moduls die CGI-Schnittstelle. So können in Perl geschriebene CGI-Skripts (immer unter der Voraussetzung, daß sie sauber programmiert sind!) unverändert unter mod_perl laufen.

Der größte Vorteil von mod_perl gegenüber CGI ist die bessere Performance; die Nachteile sind höhere Fehleranfälligkeit, weitaus höherer Speicherbedarf, größere Schwierigkeiten bei der Fehlersuche (debugging) und eingeschränkte Multiuser-Fähigkeit. In der mod_perl-Dokumentation liest man zum Thema Multiuser-Fähigkeit folgendes: "ISPs probably cannot let users run scripts under mod_perl on the main server. There are many reasons for this." Nun ist die Uni Wien zwar kein ISP (internet service provider), aber die Voraussetzungen sind ähnlich. Daher steht mod_perl auch auf dem "main server" www.univie.ac.at nicht zur Verfügung.

Für Betreiber von Subservern besteht jedoch die Möglichkeit, auf einem hohen Port (> 1024) einen eigenen Webserver laufen zu lassen, der über mod_perl oder andere Features verfügt, die vom Uni-Webserver nicht unterstützt werden (z.B. Embperl oder FastCGI, siehe unten): Wer einen Webserver mit speziellen Eigenschaften braucht und die nötigen Kenntnisse hat, einen solchen zu bauen und zu konfigurieren, kann das gerne tun. Wir stellen dafür eine empfohlene Konfiguration zur Verfügung; im wesentlichen ist sie aber frei wählbar. Ein solcher Webserver kann dann z.B. unter www.univie.ac.at angesprochen werden. Man sollte allerdings vermeiden, URLs mit Portangabe zu publizieren,3) sondern besser einen "sprechenden" Namen verwenden: Der Hauptserver ist auch ein transparenter Proxy und kann so konfiguriert werden, daß beispielsweise alle Anfragen an www.univie.ac.at/mod_perl_project/ zu www.univie.ac.at weitergeleitet werden.

Embperl & FastCGI

Embperl ist ein Zusatz zu mod_perl, der es ermöglicht, HTML-Dokumente um Perl-Code zu erweitern. Das Konzept ist dem von PHP sehr ähnlich; allerdings hat Embperl nie die Popularität von PHP erreicht, sodaß dafür wesentlich weniger Software zur Verfügung steht.

FastCGI ist eine Methode, CGI-Skripts zu beschleunigen, ohne die Schnittstelle wesentlich zu ändern: Dabei wird nicht für jeden Aufruf eines Skripts ein neuer Prozeß gestartet, sondern der Webserver kommuniziert mit einem lange laufenden Prozeß, der die Skripts verarbeitet.

Embperl und FastCGI werden vom Uni-Webserver nicht unterstützt, können bei Bedarf aber auf einem eigenen Webserver betrieben werden (siehe Abschnitt mod_perl).

Active Server Pages (ASP)

Im Unterschied zu den bisher vorgestellten Techniken, die entweder server-unabhängig oder speziell auf Apache zugeschnitten sind, hat ASP seine Heimat in der Windows-Welt, speziell beim Internet Information Server (IIS) von Microsoft. Von den Grundprinzipien und der Leistungsfähigkeit ist ASP durchaus mit PHP zu vergleichen: Programm-Code wird mittels spezieller Tags in HTML-Dokumente eingebettet und vom Server ausgeführt. Anders als PHP ist ASP aber nicht auf eine spezielle Programmiersprache beschränkt; am häufigsten werden VBScript (VB steht für Visual Basic), JavaScript und Perl - in diesem Zusammenhang meistens PerlScript genannt - verwendet.

Da wir keinen IIS betreiben, wird auch ASP vom Zentralen Informatikdienst nicht angeboten. Zwar könnte man mit Hilfe des Apache::ASP-Moduls auch einen ASP-fähigen Apache betreiben; angesichts der oben beschriebenen Alternativen wäre das aber nur mäßig sinnvoll - vor allem, weil dann nur die Perl-Variante zur Verfügung stünde, die meisten ASP-Applikationen jedoch in VBScript geschrieben sind. Weitere Informationen zu ASP sind auf den Webseiten von Microsoft und an vielen anderen Orten im Web zu finden (z.B. http://www.activeserverpages.com/).

Java & Server-Side JavaScript

Java ist eine objektorientierte Programmiersprache, die von Sun Microsystems entwickelt wurde und seit Jahren intensiv gefördert und beworben wird. Vor allem in der kommerziellen Datenverarbeitung, wo man gegenüber Open Source-Produkten wie Perl und PHP oft recht mißtrauisch ist, hat Java viele Freunde gefunden. Ein großer Vorteil von Java ist die weitgehende Portabilität: Java kann auf allen möglichen Hardware- und Software-Plattformen - also auch mit verschiedenen Webservern - eingesetzt werden. In einer Client/Server-Umgebung kann Java sowohl am Klienten (als Applet) als auch am Server (als Servlet) laufen. Für Applets ist keine besondere Server-Unterstützung erforderlich; Servlets sind - nach der Meinung von Sun Microsystems - eine schnellere und leichter zu programmierende Alternative zu CGI-Skripts. Java-Code kann auch in Form von Java Server Pages (JSP) in HTML-Dokumente eingebettet werden; das Konzept ist dem von ASP sehr ähnlich. Allgemeines zu Java ist unter http://java.sun.com/ zu finden; Informationen über Java-fähige Apache-Server gibt es unter http://java.apache.org/.

Der Vollständigkeit halber sei noch Server-Side JavaScript erwähnt. JavaScript ist eine Erfindung von Netscape und hat abgesehen vom Namen sehr wenig mit Java gemeinsam, obwohl die beiden oft miteinander verwechselt werden. Die häufigste Anwendung von JavaScript ist die Erzeugung von dynamischen Effekten in Webbrowsern; es gibt aber auch eine Server-Version von JavaScript, die allerdings keine besondere Verbreitung gefunden hat.

Java-Servlets, JSP und Server-Side JavaScript werden von den zentralen Webservern der Uni Wien nicht unterstützt.

SQL-Datenbanken

SQL-Datenbanken sind zwar kein Werkzeug zum Generieren von dynamischen HTML-Dokumenten, aber bei vielen dynamischen Webapplikationen ein unerläßliches Hilfsmittel. Teuren kommerziellen SQL-Datenbanken wie Oracle, db2, Informix oder Microsoft SQLServer stehen Open Source-Produkte wie MySQL und PostgreSQL gegenüber. Jede dieser Datenbanken versteht einen eigenen "Dialekt" von SQL und verfügt über ein eigenes API.

Auf den Webservern der Universität Wien kommen hauptsächlich die Kombinationen Perl/Oracle (auf WWW.UNIVIE.AC.AT) und PHP/MySQL bzw. PHP/PostgreSQL (auf GERDA.UNIVIE.AC.AT) zum Einsatz. Was sind nun die jeweiligen Vor- und Nachteile?

  • In Bezug auf Datensicherheit und Datenintegrität, die in der kommerzellen Datenverarbeitung essentiell sind, ist Oracle haushoch überlegen. Die Unterstützung von Transaktionen durch MySQL ist hingegen recht mangelhaft.

  • Die höhere Datensicherheit bedeutet einen höheren Aufwand, sodaß Oracle-Applikationen mitunter langsamer sind als äquivalente MySQL-Applikationen (die Performance von Datenbanken ist allerdings ein sehr komplexes Thema und hängt von vielen Faktoren ab). Für Anwendungen wie z.B. Gästebücher, wo die Datenintegrität nicht so wichtig ist, ist MySQL durchaus geeignet.

  • Perl verwendet für alle Datenbanken eine einheitliche Schnittstelle, das DBI-Interface. Dieses setzt auf Treiber-Modulen für die einzelnen Datenbanken auf, was für den Benutzer jedoch transparent ist. Daher sind Perl/DBI-Skripts relativ portabel, solange nicht zu viele datenbankspezifische SQL-Erweiterungen verwendet werden.

  • Im Gegensatz dazu verwendet PHP für jede Datenbank ein eigenes Interface - z.B. setzt die Oracle-Schnittstelle von PHP direkt am OCI (Oracle call interface) auf. Dies erhöht die Flexibilität auf Kosten der Einfachheit und Portabilität.

  • Oracle ist sehr teuer. Zwar steht es an der Uni Wien im Rahmen einer Campuslizenz zur Verfügung, aber kaum jemand kann und will es sich leisten, zu Hause Oracle zu installieren.

  • Nachdem PHP und MySQL auf vielen Linux-Systemen zur Standardausstattung gehören, findet man im Internet für zahlreiche Aufgaben fertige Lösungen. DBI/Oracle-Applikationen gibt es hingegen sehr wenige. Allerdings lassen sich etliche DBI-Applikationen, die auf anderen Datenbanken beruhen, mit relativ geringem Aufwand auf Oracle portieren.

Die Qual der Wahl

Angesichts dieses überreichen Angebots an Techniken und Programmiersprachen stellt sich natürlich die Frage: Welche soll ich verwenden? Meistens gibt es keine "beste" Lösung für ein bestimmtes Problem - vielmehr ist es legitim und sinnvoll, auf persönliche Vorlieben und Kenntnisse Rücksicht zu nehmen. Das Erlernen einer Programmiersprache bedeutet einen beträchtlichen Aufwand an Zeit und Arbeit. Diese Investition soll natürlich eine möglichst hohe Rendite bringen. PHP ist z.B. gerade dabei, Perl den Rang als wichtigste Sprache für Webapplikationen abzulaufen - wer nur für das Web programmieren will, ist daher vielleicht mit PHP besser beraten. Andererseits wird PHP fast ausschließlich für Webapplikationen verwendet, während Perl eine universell einsetzbare Sprache mit unzähligen Anwendungen ist, die nicht das geringste mit dem WWW zu tun haben.

Noch viel weniger läßt sich die Frage beantworten, was leichter zu erlernen sei: Die eifrig geführten Debatten zu diesem Thema gleichen eher Glaubenskriegen als sachlichen Diskussionen. Egal welche Technik verwendet wird - dynamische Webapplikationen sind einigermaßen komplex und erfordern in jedem Fall einen gewissen Lernaufwand. Ohne Grundkenntnisse der Funktionsweise des WorldWideWeb, von Client/Server-Programmierung, Sicherheitsfragen und dergleichen geht es einfach nicht. Wenn jemand behauptet, die Applikation X lasse sich ganz leicht und ohne jegliche Vorkenntnisse installieren und betreiben, lügt er. Unzulässige Vereinfachungen neigen dazu, sich später zu rächen; andererseits besteht aber kein Grund, die Dinge komplizierter zu machen, als sie sind - gemäß dem bewährten Grundsatz: Make everything as simple as possible - but not simpler.

 

1) Ein solcher teilweise geschützter Netzwerkbereich wird demilitarized zone genannt.

2) Für ein Verständnis des Folgenden sind Grundkenntnisse der Unix-Dateiattribute nötig (siehe z.B. http://www.unet.univie.ac.at/aix/aixuser/usrosdev/file_own_user_grps.htm und http://www.unet.univie.ac.at/aix/aixuser/usrosdev/access_control_list.htm).

3) Von vielen Firewalls und Proxy-Servern werden Verbindungen zu "non standard"-Ports nicht durchgelassen.