Web-Server sind für viele Bestandteile des Systems erforderlich, die primär eigentlich eine andere Aufgabe haben:
- Mailserver: für die Webmail-Oberflächen
- Wikis: benötigen naturgemäß einen Web-Server
- Content Managenemt Systeme: werden über die Web-Schnittstelle genutzt
Versionsverwaltung: subversion arbeitet mit der Web-DAV-Schnittstelle
Bug tracking: trac wird über ein Web-Interface benutzt
- Nutzerverwaltung/Administration: wird über das Web-Schnittstelle verwendet
Damit alle Dienste über die Standard-Ports angesprochen werden können, verwenden wir den Lastverteilungsserver Pound. Er leitet jede Anfrage an den zuständigen Webserver weiter und fungiert gleichzeitig als SSL-Umsetzer.
Wir analysieren regelmäßig die Statistik der Zugriffe auf unsere Webserver (nicht-öffentlich).
Unser Nutzer-Webserver erlaubt allen Nutzern den Betrieb öffentlicher (oder zugangsbeschränkter) Webseiten. Hier ist die Abgrenzung der Zugriffsrechte recht komplex und erfordert einige manuelle Anpassungen.
Inhaltsverzeichnis
Was ist das hier
Diese Anleitung beschreibt die Einrichtung von Apache1, Apache2 und Pound.
Daten fuer die Faxe-Administration
Installation der Apache-Server |
|
UML |
|
Apache1 |
bastelecke, interim, wikis |
Apache-ssl |
bastelecke, interim |
Apache2 |
bastelecke, mail, svn, www |
Apache2 - Module |
|
mod_deflate |
|
bastelecke |
x |
x |
|
svn |
x |
www |
|
Bitte folgendes beachten:
unsere eigenen Konfigurations-Dateien in /etc/apache2/conf.d sind Links nach /data/etc
Allgemeine Einstellungen
Verteilung der Anfragen
Der einzige spezielle Bestandteil unseres Webservers ist der WebProxy. Er verteilt alle Anfragen, die auf Port 80 (http) und Port 443 (https) eingehen, auf die zuständigen UML-Webserver. Die Zuteilung erfolgt aufgrund von Vergleichen mit URL-Mustern.
Als WebProxy kamen für uns ein apache-Webserver mit dem backhand-Modul oder der Lastverteilungsserver Pound in Frage.
Die Nutzung eines apache-Server als Proxy stellte sich jedoch als recht komplex heraus - zumindest schafften wir es nicht, ihn so transparent zu konfigurieren, wie wir wollten
Pound dagegen ist sehr speziell und schlank - genau richtig für unsere Zwecke.
Zusätzlich zur Verteilung der Anfragen dient er auch als gemeinsamer SSL-Umsetzer - er leitet alle Verbindungen unverschlüsselt weiter. Dies ist ungefährlich, da die Kommunikation vollständig innerhalb des Rechners abläuft.
Detaillierte Informationen zur Einrichtung findest du auf der WebProxy-Seite.
Standard-Einstellungen
Proxy
Damit die Webserver gut mit dem WebProxy auskommen, brauchen sie folgende Einstellungen (apache):
UseCanonicalName on ServerName UMLNAME.sao
Es ist absolut notwendig, dass diese beiden Statements vr allen Alias- usw. Direktiven gesetzt werden - andernfalls wird mensch verrückt bei der Suche nach dem Fehler. Somit ist es in einer Multi-Dateien-Konfiguration (üblicherweise /etc/apache?/conf.d/) erforderlich, die Datei mit diesen Statements vor allen anderen zu laden (beispielsweise durch Verlinkung oder Verschiebung nach /etc/apache?/sites-enabled (debian)).
SSL
Manche Web-Dienste verweigern Teilfunktionalitäten, wenn sie glauben, dass SSL nicht aktiv ist (z.B. verweigern die Webmail-Oberflächen die Eingabe einer gpg-Passphrase). Dies lässt sich oft mit folgender Direktive beheben:
SetEnv HTTPS on
Apache 2
Komprimierung mit mod_deflate
Das Modul mod_deflate ermoeglicht das komprimierte Senden von Seiten an den Browser (Unterstuetzung des Browser vorausgesetzt). Dadurch steigt zwar die CPU-Belastung, doch es werden geringere Datenmengen uebertragen - wohltuend fuer jede Bandbreite.
Weitere Informationen auf der Apache Seite oder bei Debian-Administration.org.
Installation des Modules
Als root im entsprechenden UML folgendes ausfuehren:
a2enmod deflate
Die erfolgreiche Installation wird mit folgender Meldung belohnt:
Module deflate installed; run /etc/init.d/apache2 force-reload to enable.
Einrichtung
Unter /etc/apache2/conf.d wird die Datei deflate.conf angelegt. Hier unsere Beispielkonfiguration:
# den deflate-Filter aktivieren <IfModule mod_deflate.c> SetOutputFilter DEFLATE # Browserweiche damit aeltere Browser nicht rumzicken BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary # wichtig fuer Proxy-Server <IfModule mod_headers.c> Header append Vary User-Agent </IfModule> # Definition des Log-Outputs DeflateFilterNote Input instream DeflateFilterNote Output outstream DeflateFilterNote Ratio ratio # die Logmeldungen werden nach /var/log/apache2/deflate.log geschrieben <IfModule mod_log_config.c> LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate CustomLog /var/log/apache2/deflate.log deflate </IfModule> </IfModule>
Nun muss Apache2 neugestartet werden:
/etc/init.d/apache2 restart
Fertig! Ob das Modul korrekt funktioniert, kannst du mit der Log-Datei kontrollieren.
Logfile Analyse
Für die Auswertung der access.log bieten sich die zwei Tools awstats und visitors an. Für beide existieren Debianpakete.
visitors -A -m 30 access.log -o html > report.html
perl /usr/lib/cgi-bin/awstats.pl -config=sao -month=04 -year=2005 -update -output > report.html
Für letzteres muss es eine config Datei /etc/awstats/awstats.sao.conf geben. awstats.sao.conf
Probleme
Apache2 und PHP
Mensch munkelt, dass PHP Probleme mit den apache2-Modellen außer prefork haben kann.
Nutzer-Webserver
Prozessbeschränkung
Alle user, die sich auf dem Server einloggen dürfen maximal 50 Prozesse gleichzeitig aufführen. Dies soll die Gefahr von Fork-Bombs minimieren.
Wie dies geschieht, kann hier nachgelesen werden.
Nähere Details zu unseren Anpassungen des Nutzer-Webservers findest du hier.