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 ...
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!
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 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 AuthUserFile
s in evtl.
vorhandenen .htaccess
Dateien.
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
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/).
... 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 ...