Zentraler Webserver der FIN

Der offiziell zu verwendende Webserver-Name ist www.cs.uni-magdeburg.de. Weitere aliase sind:

ANDERE URLs bzw. Aliases, (auch wenn solche temporär oder zwecks Rückwärtskompatibilität noch existieren sollten), bitte NICHT BENUTZEN und schon gar nicht veröffentlichen. Anderenfalls muß damit gerechnet werden, daß entsprechende Verweise früher oder später ins Leere zeigen ...

EOL Server

Diese Server inkl. deren Inhalte werden nicht mehr gewartet (End Of Life). Sie werden in naher Zukunft komplett stillgelegt. Auf selbige sollte somit nicht mehr verwiesen werden!

Zugriff

Alle web homes der Nutzer sind unter Solaris via /web/$user erreichbar.

Unter /web wird die aktuell gesetzte umask bzw. Gruppe genutzt (default 022: Verzeichnisse = rwxr-xr-x , Dateien = rw-r--r--).

Bei sensitiven Dateien (z.B. die Passworte für DBs enthalten) sollten die Ausführungs- und Leserechte für other entzogen werden:

chmod o-rx file

Da der webserver (user 'webservd') die Dateien aber noch lesen können muß, erfordert dies dann die Erstellung eines entsprechenden NFS4-ACL-Eintrags, z.B.:

chmod A0+user:webservd:r:allow file

Das Ergebnis kann man sich mit ls -Val file bzw. ls -val file ansehen. Mit chmod A- file entfernt man wieder alle zusätzlichen ACL-Einträge. Weitere Infos sind via man -s 1 chmod bzw. man -s 1 ls zu finden.

Persönliche Webseiten von Mitarbeitern und Studenten

Persönliche Webseiten der Mitarbeiter und Studenten der FIN sind soweit vorhanden via http://www.cs.uni-magdeburg.de/~name/ erreichbar.

web homes werden bei Bedarf nach Anfrage mit einem Kontingent (aka quota) von 50M eingerichtet. Sollte das nicht ausreichen, kann auf Nachfrage selbiges erhöht werden, solange ausreichend Speicherplatz vorhanden ist.

web home ist ein auf dem Webserver als auch auf Solaris Clients per automounter angeflanschtes Filesystem, welches per default folgendes Layout hat:

    /web
       +--- $user                          aka web home
               +--- etc
               +--- public_html

Wo das Filesystem tatsächlich physisch liegt, ist abhängig von vorhandenen Ressourcen und Policies, kann also variieren.

Wie gewohnt wird alles unter public_html auf http://www.cs.uni-magdeburg.de/~user/ abgebildet und ist a priori für jeden web client zugreifbar.

Unter etc sollte man Sachen ablegen, die für das funktionieren der Webseiten wichtig sind, aber in keinem Fall via Web zugreifbar sein sollen. Ein Beispiel hierfür wären die AuthUserFiles in evtl. vorhandenen .htaccess Dateien.

Technische Details

Alle Webserver arbeiten i.d.R. autark. D.h. es ist nicht möglich, Verzeichnisse und/oder Dateien eines Webservers in den Namespace eines anderen auf Dateisystemebene zu verlinken oder darauf zuzugreifen! Ebenso kann der Server aus Sicherheitsgründen nicht auf die home Verzeichnisse zugreifen (kennt selbige nicht)!

Kinderkram wie PHP wird nicht unterstützt. Wer das wirklich braucht, melde sich zwecks Absprache bei dem Laborleiter seines Instituts. Alternativ kann natürlich darüber nachgedacht werden, simple Sachen per Javascript/Ajax, komplexere Sachen professionell als Web aka J2EE-Applikation zu implementieren. Für letzteres ist auf Nachfrage ein entsprechender Zugang für einen GlassFish Server (v3 oder besser) unter JDK 1.6 laufend, mit Hibernate Support und MySQL Anbindung (v5.1.x oder besser) erhältlich

Standard-Konfiguration

Die aktuelle Konfiguration eines Webservers bzw. dessen Status kann vom Sunpool-Intranet von allen registrierten Rechnern via http://servername/server-info bzw. http://servername/server-status abgefragt werden. Analog können die vom Server gesetzten Environment-Variablen via http://servername/cgi-bin/printenv inspiziert werden.

Per default ist die automatische Generierung von Verzeichnislisten (siehe mod_autoindex) beim Fehlen entsprechender Index-Dateien aktiviert. Als Index-Dateien sind per default folgende Dateien definiert: index.html, index.shtml und index.html.var (man beachte: antiquierte home.html oder index.htm zählen NICHT dazu). MultiViews können ebenfalls genutzt werden.

Desweiteren sind Server Side Includes (SSI) aktiviert (*.shtml), jedoch ohne EXEC-Funktion.

Das Folgen symbolischer Links ist i.d.R. deaktiviert, kann aber bei Bedarf via Nachfrage vom entsprechenden Webmaster aktiviert werden (wird dann aber max. auf SymLinksIfOwnerMatch gelockert).

Die URL-Pfade /icons/.* und /error/.* sind reservierte Standard-Pfade. Sie sind immer ein Alias auf die in der Apache-Distribution enthaltenen Standard-Icons zur Erstellung einer autoindex Seite (siehe /opt/apache2/icons/) bzw. Apache-Fehlermeldungen (siehe /opt/apache2/error/).

Best Practice

... ist immer ein relativ kontroverses Thema, nichts desto trotz möchten wir nicht unsere gesammelten Erfahrungen diesbzgl. verheimlichen ;-)

Verweise auf andere Seiten sollten möglichst verzeichnis-orientiert angelegt werden, also http://extern.site/docs/ statt http://extern.site/docs/index_de.html.

Hintergrund ist, daß ein HTML-Autor auch mal seinen Webseiten ändert, neue Technologien aufgreift und beispielsweise den DirectoryIndex umstellt, so daß die Einstiegsseite plötzlich nicht mehr index_*.html sondern home.php heißt. Wird verzeichnis-orientiert verlinkt, kümmert sich i.d.R. der Webserver selbst darum, was als Einstiegseite benutzt werden soll - er schickt dem Client ein Redirect auf die richtige Seite.

Ebenso besteht keine Notwendigkeit, dem Nutzer/Client irgendeine Sprache aufzuzwingen! In jedem modernen Webclient kann man heutzutage seine Preferenzen bzgl. bevorzugter Sprachen einstellen und somit den Webclient und Webserver aushandeln lassen, in welcher Sprache die referenzierte Seite dargestellt werden soll. Nur weil man beispielsweise selber der französichen Sprache nicht mächtig ist (und nur Seiten in Englisch anbietet), ist noch lange kein Grund, den Nutzer auf externe englisch-sprachige Seiten zu zwingen, obwohl die externe Site durchaus anders sprachige Seiten anbietet ...

Verweise auf lokale Seiten (d.h. Seiten auf dem gleichen Webserver) sollten immer nur als URL-Pfad und nicht komplett aka schema://hostname[:port]/url-path angelegt werden. Also statt http://servername/pfad/ nur /pfad/ benutzen.

Hintergrund ist eine bessere Verifizier- und Testbarkeit: Angenommen man entschließt sich, eine Website oder nur einzelne Seiten davon zu überarbeiten oder neue Funktionalitäten hinzuzufügen/zu eruieren. Clevere Leute haben für diesen Fall i.d.R. einen zweiten Webserver, der anfangs bis auf Name und IP-Adresse eine exakte Kopie des Originals ist. Verwendet man nun nur URL-Pfade für Referenzen auf lokale Seiten, läßt sich die Funktionalität des Servers mit geeigneten Tools (z.B. Link-Checker) relativ einfach testen. Nach erfolgreichen Test kann das Original durch einfaches Sychronisieren der entsprechenden Konfigurationsdateien und Verzeichnisse sehr schnell und für externe Nutzer i.d.R. unbemerkt aktualisiert werden. Benutzt man dagegen vollständige schema://hostname[:port]/url-path Verweise, hat man entweder Probleme beim Testen auf der Kopie oder beim Sychronisieren auf den Original-Server, da alle Links erneut angepaßt werden müseen ...