Nachdem der neue Webcluster mittlerweile einsatzbereit ist, suchen wir Webmaster, die interessiert daran sind, ihren Webauftritt dort zu testen. Neue Auftritte werden wir ab September dort anlegen. Bestehende Webauftritte brauchen in den meisten Fällen ein wenig Nacharbeit, die sich aber zumeist auf das Aktualisieren des cgi-bin-Verzeichnisses beschränken wird.
Der neue Webcluster besteht momentan aus drei Webservern und einem Dialogserver, der auf den Namen
iwan.rrze.uni-erlangen.de
hört.
Folgende Software läuft auf den neuen Systemen:
- Apache 2.4.3
- Perl 5.14.1
- PHP 5.3.16
- Varnish 3.0.3
Um zu testen, ob Ihr Webauftritt auf dem neuen Custer schon lauffähig ist, können Sie folgende Schritte durchführen:
- Tragen Sie in der Hosts-Datei Ihres Client-Rechners einen der Aliasse für die IP-Adresse des neuen Clusters ein. In etwa:
131.188.16.201 www.beispiel.phil.uni-erlangen.de
Die derzeitigen Webserver haben die IP-Adresse 131.188.16.200, die zukünftigen sind unter 131.188.16.201 zu finden.
Nähere Hinweise hierzu finden Sie unter http://de.wikipedia.org/wiki/Hosts-Datei
Diese Änderung wirkt sich nur auf Ihren eigenen Rechner aus. Von anderen Rechnern aus wird weiterhin der bisherige Webcluster benutzt.
- Sollte Ihr Webauftritt den Webbaukasten verwenden, könnte es sein, dass die Menüs nicht angezeigt werden. In diesem Fall aktualisieren Sie bitte ihr cgi-bin-Verzeichnis. Der aktuelle Stand ist unter
/proj/websource/docs/muster/www.defaultwebauftritt.uni-erlangen.de
zu finden.
Das derzeitige cgi-bin-Verzeichnis heben Sie am besten auf, als cgi-bin.old beispielsweise.
Auf der Kommandozeile ist das in drei Zeilen erledigt:
- Wechseln Sie in Ihren Webroot:
cd /proj/websource/docs/FAU/fakultaet/phil/www.beispiel.phil.uni-erlangen.de
cp -R /proj/websource/docs/muster/www.defaultwebauftritt.uni-erlangen.de/cgi-bin ./cgi-bin.new
- jetzt haben wir alt und neu da und schieben den neuen an die richtige Stelle:
mv cgi-bin cgi-bin.old && mv cgi-bin.new cgi-bin
- Falls Ihr Webauftritt cronjobs verwendet, sollten diese in Zukunft auf dem neuen Dialogserver
iwan.rrze.uni-erlangen.de ausgeführt werden. Bitte testen Sie diese im Vorfeld auf dem neuen System, am einfachsten durch manuellen Aufruf.
- Wenn Sie der Ansicht sind, dass Ihr Webauftritt ohne Probleme auf dem neuen Cluster betrieben werden kann, dann schreiben Sie eine Mail an webmaster@rrze.fau.de. Wir werden dann Ihren Webauftritt auf den neuen Webcluster umziehen.
Weiterhin haben wir auch einen Web-Accelerator in Betrieb – siehe den Artikel zu Varnish in der deutschsprachigen Wikipedia.
Dieser bedient alle Webauftritte auf Port 80 – das schliesst also sämtliche Testwebauftritte sowie verschlüsselte Verbindungen aus. Desweiteren wird er nur dann aktiv, wenn man ihn explizit dazu auffordert. Ansonsten wäre die Gefahr zu groß, dass zugriffsgeschützte Seiten an unautorisierte Nutzer ausgeliefert werden.
Angenommen, Sie haben einen Ordner namens /intern, dessen Inhalte nur aus dem Uninetz erreichbar sein sollen, und Sie haben deswegen in der /intern/.htaccess folgende zwei Zeilen stehen:
Deny from All
Allow from 131.188.
Jetzt kommen nacheinander zwei Clients. Der erste hat die IP 131.188.x.x, der nächste 100.200.x.x – also irgendwo von aussen. Der erste fragt nach /intern beim Varnish an. Dieser fragt den Apache. Der Apache bekommt hierbei die Client-IP zu sehen und autorisiert den Zugriff völlig zu Recht. Allerdings hat der Varnish keine Ahnung davon, dass dieses Verzeichnis zugriffsgeschützt ist, nachdem der Apache das nicht kenntlich macht. Varnish packt jetzt also /intern in seinen Zwischenspeicher und beim nächsten, der kommt und /intern haben möchte, fragt er nicht mehr beim Apache nach, sondern sagt “hab ich da, bitteschön”. Und schon ist /intern bei 100.200.x.x gelandet, wo es nie hinsollte.
Um solche Situationen zu vermeiden, haben wir unseren Varnish so konfiguriert, dass er nur auf explizite Anforderung hin
zwischenspeichert und ansonsten einfach alle Anfragen an den Apache weiterreicht.
Um den Cache aktivieren, muss der Webauftritt einen Header mitliefern – der Header X-Enable-Cache muss den Wert yes haben, ansonsten reicht der Varnish die Antwort nur weiter und speichert nichts.
Diesen Header kann man in den .htaccess-Dateien des Webauftritts setzen.
-
Explizit einschalten lässt sich der Varnish hiermit – die
IfModule-Blöcke sorgen dafür, dass der bisherige Cluster damit auch zurechtkommt, nachdem das headers-Modul nur auf den neuen Servern aktiv ist:
<IfModule headers_module>
Header set X-Enable-Cache yes
</IfModule>
In einer .htaccess-Datei wirkt das rekursiv. Wenn Sie diese Zeilen in die Datei websource/.htaccess einfügen, geben Sie damit den gesamten Webauftritt für den Varnish frei!
-
Explizit deaktivieren können Sie den Varnish mit den folgenden Zeilen. Diese Konstellation wäre zum Beispiel sinnvoll in einem zu schützenden Unterverzeichnis eines explizit freigegebenen Verzeichnisses.
<IfModule headers_module>
Header unset X-Enable-Cache
</IfModule>
-
Für den Anfang empfiehlt es sich, zunächst mit einem Unterordner zu testen, der garantiert unkritisch ist. So können Sie beispielsweise in der
websource/test/.htaccess die richtige Konfiguration ermitteln.
-
Mittels
<Files> oder <FilesMatch> können Sie den Cache auch für bestimmte Dateien aktivieren oder deaktivieren:
“Nichts cachen ausser PNGs” beispielsweise sieht so aus:
<IfModule headers_module>
Header unset X-Enable-Cache
<FilesMatch "\.png$">
Header set X-Enable-Cache yes
</FilesMatch>
</IfModule>
