Apache

Einführung

Der Apache-Webserver ist ein zentrales Element des Caipirinha-Servers, weil auf ihm aufbauend noch zahlreiche weitere Dienste realisiert sind, und zwar:

Caipigallery auf [1]
Caipiwiki auf [2]
GroupOffice auf [3]
Caipithek auf [4]
MRTG für die verschiedenen Grafiken auf [5], [6], [7], [8]
USV-Status auf [9]

Pakete

Zum Betrieb des Apache-Webservers müssen die folgenden Pakete auf dem Caipirinha-Server installiert werden. Außerdem muss PHP installiert und konfiguriert worden sein. Als Einstieg in die Konfiguration des Apache-Webservers ist ferner das Buch [10] sehr empfehlenswert.

apache2
apache2-doc
apache2-mod_perl
apache2-mod_php5
apache2-prefork
apache2-utils
susehelp
susehelp_de
susehelp_en

Basis-Setup

Um Apache auf die eigenen Anforderungen anzupassen, erstellen wir zunächst eine Konfigurationsdatei, die dann zusätzlich zu den bereits existierenden Konfigurationsdateien beim Start des Apache-Servers abgearbeitet wird:

/etc/apache2/httpd.conf.local:

#
# Additional Configuration for the Apache Web server on CAIPIRINHA
#
# Gabriel Rüeck, 24.10.2010

AddDefaultCharset    UTF-8
DirectoryIndex       index.shtml

# Additional Handler Declarations
AddHandler           imap-file map

SSLCipherSuite       HIGH

# Verzeichnisse freigeben außerhalb des DocumentRoot
Alias /kde-icons     /opt/kde3/share/icons/crystalsvg/48x48/mimetypes
Alias /gnome-icons   /usr/share/icons/gnome/32x32
Alias /dav           /home/public/Dropbox

# Umleitungen auf die neu angemietete Domain rueeck.name
Redirect permanent   /coppermine  http://rueeck.name/coppermine
#Redirect            /mediawiki   http://rueeck.name/mediawiki
Redirect permanent   /lx-erp      https://rueeck.name/lx-erp
Redirect permanent   /phpPgAdmin  https://rueeck.name/phpPgAdmin
Redirect permanent   /groupoffice https://rueeck.name/groupoffice

# KDE ICONS (needed for update_rss.sh)
<Location /kde-icons>
  Allow from         all
</Location>

# GNOME ICONS (needed for caipithek.php)
<Location /gnome-icons>
  Allow from         all
</Location>

# MULTIMEDIA-VERZEICHNIS
<Directory /srv/www/htdocs/MM>
  SSLRequireSSL
  AuthName           "Secure Access on CAIPIRINHA"
  AuthType           Digest
  AuthUserFile       /srv/www/htdocs/MM/.htpasswd
  Require            valid-user
  Options            Indexes FollowSymLinks
  IndexOptions       +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8
</Directory>

# DIGITAL DROPBOX
<Directory /srv/www/htdocs/Dropbox>
  AuthName           "Digital Dropbox on caipirinha"
  AuthType           Digest
  AuthUserFile       /home/public/Dropbox/.htpasswd
  Require            valid-user
</Directory>

# WEBALIZER
<Directory /srv/www/htdocs/webalizer>
  AuthName           "Secure Access on CAIPIRINHA"
  AuthType           Digest
  AuthUserFile       /srv/www/htdocs/MM/.htpasswd
  Require            valid-user
</Directory>

# LX-OFFICE
<Directory /srv/www/htdocs/lx-office-erp>
  SSLRequireSSL
</Directory>

<Directory /srv/www/htdocs/lx-erp>
  SSLRequireSSL
  Options ExecCGI Includes FollowSymlinks
</Directory>

<Directory /srv/www/htdocs/lx-erp/users>
  Deny from          all
</Directory>

<Directory /srv/www/htdocs/phpPgAdmin>
  SSLRequireSSL
</Directory>

# WEBDAV WEBFOLDERS
# Speicherort für Lock-Datenbank
DAVLockDB            /var/lock/dav/lock
DavDepthInfinity     off

<Location /dav>
  Allow from         all
  Dav                on
  ForceType          text/plain
  AuthType           Digest
  AuthName           "Secure Access on CAIPIRINHA"
  AuthUserFile       /srv/www/htdocs/MM/.htpasswd
  <LimitExcept OPTIONS>
    Require            valid-user
  </LimitExcept>
  Options            Indexes
  IndexOptions       +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8
  SSLRequireSSL
</Location>

Gehen wir diese Konfiguration einmal Schritt für Schritt durch:

Mit AddDefaultCharset wird UTF-8 als Standard-Zeichensatz des Webservers eingestellt. Dadurch können auch Texte in nicht-lateinischen Buchstaben problemlos dargestellt werden. Heutzutage macht wegen der zunehmenden Internationalisierung eigentlich auch keine andere Einstellung mehr Sinn.
Mit DirectoryIndex legt man fest, dass Webseiten mit Namen index.shtml ebenfalls als Index-Seiten (also so wie index.html) betrachtet werden. Manche Entwicklungswerkzeuge für Webseiten nehmen die Endung shtml für Webseiten, welche Server Side Includes (SSI) enthalten.
In der Zeile mit der Direktive AddHandler wird nun ein Handler für Image Maps benannt.
Die folgende Direktive SSLCipherSuite fordert den Einsatz von Triple-DES-Verschlüsselung beim Aufruf verschlüsselter Webseiten (https) und verbietet den Einsatz schwächerer Verschlüsselungsalgorithmen.
Nun werden Alias-Pfade für einige Verzeichnisse außerhalb des DocumentRoot festgelegt. Damit erreicht man quasi eine “Umleitung” des Zugriffs. So wird beispielsweise beim Aufruf der Seite http://caipirinha.homelinux.org/dav nicht etwa in das Verzeichnis /srv/www/htdocs/dav verzweigt, wie dies normalerweise der Fall wäre, sondern der Webserver sieht stattdessen in /home/public/Dropbox nach. Mit dieser Methode kann man beliebige Verzeichnisse einbinden, ohne dass sich alles unterhalb des DocumentRoot (/srv/www/htdocs) befinden muss.
Nun folgen einige Umleitungen für Webseiten, die vormals auf dem Caipirinha-Server gehostet wurden und die jetzt auf die Maschine rueeck.name verschoben worden sind. Damit Zugriffe auf diese vormals auf dem Caipirinha-Server existierenden Seiten nicht ins Leere gehen, werden sie automatisch umgeleitet.
Die folgenden beiden Location-Direktiven haben als einzigen Zweck das Zulassen des Zugriffs für alle Clients auf die Web-Verzeichnisse:
- http://caipirinha.homelinux.org/kde-icons
- http://caipirinha.homelinux.org/gnome-icons
Die folgende Directory-Direktive bezieht sich auf das Verzeichnis /srv/www/htdocs/MM (erreichbar über https://10.130.25.50/MM). Dieses Verzeichnis ist erfordert zwingend eine verschlüsselte Verbindung (https) und eine erfolgreiche Authentifizierung (Direktiven SSLRequireSSL, AuthName, AuthType, AuthUserFile, Require) mit einem gültigen Paar aus Benutzernamen und Passwort aus der Datei /srv/www/htdocs/MM/.htpasswd. Außerdem ist bei diesem Verzeichnis das Auflisten des Verzeichnis-Inhalts (Indexes) zulässig. Bei der Auflistung werden bestimmte Sortierkriterien eingehalten, die zusätzlich (deswegen das “+”-Zeichen) zu den Default-Optionen aktiviert werden (+IgnoreCase +FoldersFirst +VersionSort). Außerdem wird das Listing mit dem Zeichensatz UTF-8 durchgeführt (+Charset=UTF-8).
Dann folgt eine Directory-Direktive für die Dropbox, bei der ebenfalls eine Authentifizierung, aber keine Verschlüsselung notwendig ist.
Eine vergleichbare Konfiguration hat die nächste Directory-Direktive, welche den Zugriff auf die Webserver-Statistiken in /srv/www/htdocs/webablizer regelt (siehe Webalizer).
Dann folgen drei Abschnitte, welche den Zugriff auf die Dateien für das Paket lx-office regeln. Dabei ist zu beachten, dass für das Verzeichnis /srv/www/htdocs/lx-erp spezifische Optionen festgelegt werden, und zwar nicht zusätzlich zu den Default-Optionen, sondern anstatt der Default-Optionen. Deshalb fehlt hier das “+”-Zeichen, welches bei der Festlegung der Optionen in einem der vorherigen Blöcke benutzt worden war. Für den Zugriff auf lx-office sowie auf phpPgAdmin ist zwingend Verschlüsselung notwendig, weil bei der Benutzung dieser Pakete Passworte übertragen werden müssen.
Zuletzt kommen die Einstellungen für das WebDAV-Verzeichnis in /home/public/Dropbox (erreichbar über https://caipirinha.homelinux.org/dav). Eine Einführung in WebDAV findet sich auf [11], [12], [13] und [14]; die detaillierte Spec gibt es auf [15]. Bei der Konfiguration von WebDAV sind mehrere Punkte zu beachten:
- Zunächst muss eine lock-Datenbank eingerichtet werden, welche im Betrieb dann mehrere Dateien (in diesem Fall lock.dir und lock.pag) erzeugt. Dazu muss das Verzeichnis /var/lock/dav erzeugt werden und dem Apache-Benutzer wwwrun:www gehören; das macht man mit den beiden Befehlen unten.
- Mit der Direktive DavDepthInfinity werden PROPFIND-Abfragen mit unendlicher Tiefe ausgeschaltet. Dies wäre bei meinem kleinen Anwenderkreis allerdings nicht unbedingt notwendig gewesen.
- Für den Zugriff auf https://caipirinha.homelinux.org/dav ist eine verschlüsselte Verbindung und eine Authentifizierung des Typs Digest notwendig. Digest muss deswegen gewählt werden, weil Windows Vista und Windows 7-Clients eine Authentifizierung mit Basic nicht mehr durchführen. Beim Authentifizierungstyp Basic wird das Passwort nicht verschlüsselt, sondern im Base64-Verfahren übertragen und lässt sich daher beim Mitschneiden der Verbindung problemlos abschöpfen. Zwar ist dies bei einer gesicherten (https)-Verbindung kein großes Problem, aber moderne Windows-Clients fordern das eben, und die Grundidee ist ja auch richtig.
- Die Authentifizierung wird allerdings nicht für die Methode OPTIONS gefordert, mit welcher ein Client eine Liste der unterstützten HTTP-Methoden anfordern kann. Der Grund für diese Einstellung ist, dass ich in den Log-Dateien des Servers viele Fehler gefunden habe, welche daraus resultieren, dass Windows Vista- und Windows 7-Clients immer zunächst ohne Authentifizierung auf den WebDAV-Server zugreifen wollen. Eine große Anzahl der Anfragen geht dabei von den Methoden OPTIONS und PROPFIND aus. PROPFIND hatte ich testweise ebenfalls von der Authentifizierung ausgenommen (mit der LimitExcept-Direktive), aber dann konnte jeder Client auch ohne Authentifizierung den Verzeichnisinhalt von /home/public/Dropbox auflisten lassen. Ein Zugriff auf die Dateien war zwar nicht möglich, aber dennoch schien mir dies aus Gründen der Sicherheit problematisch zu sein.

mkdir /var/lock/dav
chown wwwrun:www /var/lock/dav

Die Einstellungen für den WebDAV-Betrieb können sicherlich verbessert werden, und für entsprechende Vorschläge bin ich daher dankbar.

In dieser Konfigurationsdatei sind die Dateien /srv/www/htdocs/MM/.htpasswd und /home/public/Dropbox/.htpasswd referenziert, welche gültige Paare aus einem Benutzernamen und dem dazugehörigen verschlüsselten Passwort enthalten. Eine solche Datei wird mit dem Befehl htdigest2 erzeugt, dessen Benutzung in man htdigest2 beschrieben ist. Möchte man beispielsweise noch einen Benutzer alfred hinzufügen, so würde man eingeben:

htdigest2 /srv/www/htdocs/MM/.htpasswd "Secure Access on CAIPIRINHA" alfred

und bei der darauf folgenden Abfrage ein Passwort eingeben. Der Wert für realm (siehe man htdigest2) sollte gleich dem Ausdruck (hier: “Secure Access on CAIPIRINHA”) sein, welcher im entsprechenden Abschnitt der Konfigurationsdatei /etc/apache2/httpd.conf.local bei der Direktive AuthName eingetragen ist.

Nun muss noch eine weitere Konfigurationsdatei angepasst werden. In der Datei /etc/apache2/mod_mime-defaults.conf werden folgende Änderungen (Entfernen des davor stehenden “#”) vorgenommen:

Der MIME-Typ für *.tgz-Dateien wird gesetzt.
Der Filter für Server Side Includes (SSI) wird aktiviert.

/etc/apache2/mod_mime-defaults.conf:

...
#
# AddType allows you to add to or override the MIME configuration
# file mime.types for specific file types.
#
AddType application/x-tar .tgz
...
#
# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
...

Mit YaST2 müssen jetzt mit dem Editor für /etc/sysconfig noch einige Variablen richtig gesetzt werden:

Applications→SuSEhelp→DOC_HOST wird auf caipirinha.homelinux.org gesetzt.
Applications→SuSEhelp→DOC_ALLOW bleibt leer.
Applications→SuSEhelp→DOC_AUTOINDEX wird auf yes gesetzt.
Network→WWW→Apache→SuSEhelp→DOC_SERVER wird auf yes gesetzt.
Network→WWW→Apache2→APACHE_CONF_INCLUDE_FILES wird auf /etc/apache2/httpd.conf.local gesetzt, damit unsere Konfigurationsdatei von oben überhaupt verarbeitet wird.
Network→WWW→Apache2→APACHE_CONF_INCLUDE_DIRS bleibt leer.
Network→WWW→Apache2→APACHE_MODULES muss mindestens die Module actions alias auth_basic auth_digest authn_file authz_host authz_default authz_user autoindex cgi charset_lite dav dav_fs dav_lock deflate dir env expires imagemap include log_config mime mime_magic negotiation setenvif suexec ssl userdir php5 beinhalten.
Network→WWW→Apache2→APACHE_SERVER_FLAGS wird auf -D SSL gesetzt, um SSL zu aktivieren.
Network→WWW→Apache2→APACHE_HTTPD_CONF bleibt leer.
Network→WWW→Apache2→APACHE_MPM bleibt leer.
Network→WWW→Apache2→APACHE_SERVERADMIN wird auf root@caipirinha.homelinux.org eingestellt.
Network→WWW→Apache2→APACHE_SERVERNAME wird auf caipirinha.homelinux.org eingestellt.
Network→WWW→Apache2→APACHE_START_TIMEOUT wird auf 20 gestellt.
Network→WWW→Apache2→APACHE_SERVERSIGNATURE wird auf on gesetzt.
Network→WWW→Apache2→APACHE_LOGLEVEL wird auf warn gesetzt.
Network→WWW→Apache2→APACHE_ACCESS_LOG wird auf /var/log/apache2/access_log combined gesetzt.
Network→WWW→Apache2→APACHE_USE_CANONICAL_NAMES wird auf off gesetzt.
Network→WWW→Apache2→APACHE_SERVERTOKENS wird auf OS gesetzt.
Network→WWW→Apache2→APACHE_EXTENDED_STATUS wird auf off gesetzt.

Die hier genannten Einstellungen finden sich dann auch in den System-Dateien:

/etc/sysconfig/susehelp
/etc/sysconfig/apache2

SSL-Setup

Für den erfolgreichen SSL-Betrieb sind noch weitere Konfigurationen erforderlich. Zunächst muss die Datei /etc/apache2/vhosts.d/vhost-ssl.template in /etc/apache2/vhosts.d/vhost.conf umbenannt werden. Alternativ kann man natürlich eine Kopie mit diesem Namen erstellen. An dieser Datei braucht nichts weiter geändert zu werden. Diese Datei erstellt zusammen mit der oben beschriebenen Option “-D SSL” einen virtuellen Server, der auf Port 443 “hört” und darüber die verschlüsselte Kommunikation abwickelt.

Nun muss noch ein Zertifikat für den SSL-Betrieb des Servers erstellt werden. Es ist ratsam, zunächst eine Einführung zu diesem Thema zu lesen, beispielsweise [16] oder [17]. Dazu existieren im Wesentlichen drei Herangehensweisen:

Einfaches Server-Zertifikat

Die Vorgehensweise ist in [18] hinreichend beschrieben. Es genügt eine openssl-Sequenz mit einigen Angaben zum Server, und das Schlüsselpaar wird erstellt. Dann muss man nur noch die Rechte des öffentlichen Zertifikats anpassen und die Schlüssel in die entsprechenden Verzeichnisse verschieben, nämlich:

server.crt nach /etc/apache2/ssl.crt/
server.key nach /etc/apache2/ssl.key/

caipirinha:~/tmp # openssl req -new -x509 -nodes -out server.crt -keyout server.key
Generating a 1024 bit RSA private key
........++++++
.......................++++++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Berlin
Locality Name (eg, city) []:Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Gabriel Rüeck
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:caipirinha.homelinux.org
Email Address []:administrator@caipirinha.homelinux.org
caipirinha:~/tmp # chmod a+r server.crt
caipirinha:~/tmp # mv server.crt /etc/apache2/ssl.crt/
caipirinha:~/tmp # mv server.key /etc/apache2/ssl.key/

Selbstsigniertes Server-Zertifikat

Die Vorgehensweise ist in [https//caipirinha.homelinux.org/manual/ssl/ssl_faq.html#ownca] hinreichend beschrieben. Mit diesem Verfahren sagt man den Benutzern seines Servers eigentlich: “Ich habe dieses Zertifikat erzeugt, und ich beglaubige auch, dass ich es selbst erzeugt habe und dass alles so stimmt.” Dies ist natürlich eine gewagte Behauptung, und weil das im Prinzip jeder so machen kann, gibt es üblicherweise beim Aufruf der SSL-verschlüsselten Seite eine Fehlermeldung, so wie im Bild Problem mit dem Sicherheitszertifikat. Mit dieser Fehlermeldung weist der Browser darauf hin, dass keine der bekannten und vertrauenswürdigen Beglaubigungsstellen dieses Zertifikat überprüft hat und dass hier etwas “faul” ist. Man kann dann zwar auf den Link “Laden dieser Webseite fortsetzen (nicht empfohlen)” klicken, und man kommt dann schließlich zur Webseite wie im Bild Zertifikatsfehler. Allerdings bleibt das URL-Fenster im Browser rot hinterlegt, und wenn man auf Zertifikatsfehler klickt, bekommt man auch den Grund dafür angezeigt.

Nichtsdestotrotz ist ein selbstsigniertes Zertifikat für private Server eine nützliche Sache, denn ein solches Zertifikat kann man kostenlos erstellen. Gibt es nur wenige Benutzer des eigenen Servers, dann kann man diesen Benutzern vielleicht sogar beibringen, das selbstsignierte Zertifikat dauerhaft im Browser zu installieren. Dazu führt man ausgehend vom Bild Zertifikatsfehler nacheinander folgende Schritte aus:

Auf “Zertifikate anzeigen” klicken.
Auf “Zertifikat installieren” klicken.
“Alle Zertifikate in folgendem Speicher speichern” auswählen und als Speicherort “Vertrauenswürdige Stammzertifizierungsstellen” auswählen, so wie im Bild Zertifikatsimport-Assistent gezeigt.
Den Fingerabdruck des Zertifikats überprüfen (Bild Fingerabdruck des Zertifikats).
Das Einfügen des Zertifikats durch mehrmaliges Bestätigen von “Ja” oder “OK” abschließen.

Woher weiß man, ob der angezeigte Fingerabdruck wirklich der richtige ist? Es könnte sich ja um einen Man-in-the-middle-Angriff handeln? Um hier sicher zu gehen, muss der Administrator des Servers den wahren Fingerabdruck auf sonstigen geschützten Wegen an seine Benutzer übermitteln oder eben das Risiko eingehen, dass seine Benutzer das Zertifikat installieren, ohne dass sie gründlich prüfen. Man sieht also schon, dass ein selbstsigniertes Zertifikat keine Lösung für einen Server mit kommerziellen Anwendungen ist.

In meinem Fall betreibe ich selbst drei Server, welche auch SSL-Verbindungen unterstützen. Ich habe allerdings nur ein Root-Zertifikat im Rahmen der OpenVPN-Konfiguration erzeugt, mit dem ich dann die jeweiligen Server-Zertifikate signiert habe. Dazu habe ich aber komplett die Skripte aus dem OpenVPN-Paket benutzt.

Fremdsigniertes Server-Zertifikat

Ein fremdsigniertes Zertifikat ist erforderlich, wenn man seinen Server im SSL-Betrieb einer größeren Allgemeinheit zugänglich machen will und seine Benutzer nicht mit Meldungen über Zertifikatsfehler abschrecken will. Dazu erzeugt man nach der in [19] beschriebenen Vorgehensweise einen sogenannten Certificate Signing Request (CSR), den man dann einer vertrauenswürdigen Zertifizierungsstelle zur Signierung zusendet. Die Signaturstelle verlangt meistens noch mehr Information, um prüfen zu können, ob der Antragsteller auch wirklich existiert und tatsächlich einen Server unter dem Namen unterhält, unter dem er den CSR erstellt hat. Dies ist aufwändig und kostet daher auch Geld. Die Preise sind aber unterschiedlich; ein Vergleich lohnt sich daher vor Abschluss eines entsprechenden Vertrags. Mit einem fremdsignierten Server-Zertifikat gibt es dann idealerweise keine Probleme mehr beim Aufrufen der SSL-geschützten Seite durch den Benutzer.

Virtueller Server

Man kann auf einer Maschine auch mehrere, voneinander unabhängige Webangebote hosten, und das mit einem Apache-Server. Das nennt sich “virtuelles Hosting”. Webhoster nutzen beispielsweise dieses Prinzip, um vielen Kunden eine eigene Domain anzubieten, wobei meist ganz viele Domains auf eine IP-Adresse abgebildet werden. Diese Webseiten liegen dann oft auch auf einer leistungsfähigen Maschine. Das schont Ressourcen und spart Geld, denn für eine private Webseite braucht man nicht unbedingt einen eigenen Root- Server. Man unterscheidet dabei zwischen IP-basiertem virtuellem Hosting und namensbasiertem virtuellem Hosting [20]. Das folgende Beispiel beschreibt das namensbasierte virtuelle Hosting [21], welches auf dem Caipiroska-Server verwirklicht wurde. Dort gibt es folgende Domains:

Zu beachten ist, dass alle drei Domains auf derselben Maschine liegen und die gleiche IP-Adresse haben. Beim Aufruf einer drei Domains übermittelt der Client-Browser in seiner Anfrage an den Webserver den Namen der Domain, die er aufrufen will (RFC2616, für SSL außerdem RFC4366). Der Server greift dann in die “richtige Kiste” und liefert das gewünschte Webangebot aus. Beim Caipiroska-Server sind die Domains allerdings nicht völlig voneinander getrennt, sondern es existiert vielmehr eine Matrix-Struktur, so wie hier dargestellt:

http://caipiroska.homelinux.org https://caipiroska.homelinux.org	http://hle.homelinux.org https://hle.homelinux.org	http://ba-berlin.homelinux.org https://ba-berlin.homelinux.org	Unterseite
Webangebot der Domain caipiroska.homelinux.org Daten stammen aus /srv/www/htdocs/caipiroska	Webangebot der Domain hle.homelinux.org Daten stammen aus /srv/www/htdocs/hle	Webangebot der Domain ba-berlin.homelinux.org Daten stammen aus /srv/www/htdocs/ba-berlin	/
Persönliche Seite des Benutzers Gabriel Daten stammen aus /home/gabriel/public_html	Persönliche Seite des Benutzers Gabriel Daten stammen aus /home/gabriel/public_html	Persönliche Seite des Benutzers Gabriel Daten stammen aus /home/gabriel/public_html	/~gabriel
ERP-System (LX-Office) installiert in /srv/www/htdocs/lx-office-erp	ERP-System (LX-Office) installiert in /srv/www/htdocs/lx-office-erp	ERP-System (LX-Office) installiert in /srv/www/htdocs/lx-office-erp	/lx-erp
CPU-Last des Caipiroska-Servers Daten stammen aus /srv/www/htdocs/mrtg	CPU-Last des Caipiroska-Servers Daten stammen aus /srv/www/htdocs/mrtg	CPU-Last des Caipiroska-Servers Daten stammen aus /srv/www/htdocs/mrtg	/mrtg/cpu.html
USV-Status meiner Server Daten werden über ein CGI-Skript erzeugt	USV-Status meiner Server Daten werden über ein CGI-Skript erzeugt	USV-Status meiner Server Daten werden über ein CGI-Skript erzeugt	/cgi-bin/multimon.cgi
Statistiken der Domain caipiroska.homelinux.org Daten stammen aus /srv/www/htdocs/caipiroska/webalizer	Statistiken der Domain hle.homelinux.org Daten stammen aus /srv/www/htdocs/hle/webalizer	Statistiken der Domain ba-berlin.homelinux.org Daten stammen aus /srv/www/htdocs/ba-berlin/webalizer	/webalizer

Eine solche Mischung aus getrenntem Inhalt und gemeinsamem Inhalt würde man natürlich nicht zulassen, wenn man einen professionellen Webhosting-Dienst hochziehen wollte. Insofern sind die hier abgedruckten Konfigurationsdateien eher zur Anregung eigener Ideen denn als Musterbeispiel namensbasierter Virtualisierung zu verstehen:

/etc/apache2/httpd.conf.local:

#
# Konfiguration für den CAIPIROSKA-Server
#
# Gabriel Rüeck, 20.10.2010

AddDefaultCharset    UTF-8
DirectoryIndex       index.shtml

# Additional Handler Declarations
AddHandler           imap-file map

SSLCipherSuite       HIGH

# LINKS, DIE FÜR ALLE VHOSTS GELTEN SOLLEN
Alias /lx-erp        /srv/www/htdocs/lx-office-erp
Alias /kde-icons     /opt/kde3/share/icons/crystalsvg/48x48/mimetypes
Alias /gnome-icons   /usr/share/icons/gnome/32x32
Alias /mrtg/         /srv/www/htdocs/mrtg/

# VERZEICHNIS-REGELN
<Directory /srv/www/htdocs/hle>
  Order deny,allow
  Deny from all
  Allow from 213.61.59.192/27
  Allow from 213.61.250.32/29
  Allow from 213.61.250.38/31
</Directory>

<Directory /home/shared>
  Order deny,allow
  Deny from all
  Allow from 213.61.59.192/27
  Allow from 213.61.250.32/29
  Allow from 213.61.250.38/31
  Options FollowSymLinks
</Directory>

<Directory /srv/www/htdocs/hle/bugzilla>
  AddHandler cgi-script .cgi
  Options +Indexes +ExecCGI
  DirectoryIndex index.cgi
  AllowOverride Limit
</Directory>

# WEBALIZER
<Location /webalizer>
  AuthName           "Secure Access on CAIPIRINHA"
  AuthType           Digest
  AuthUserFile       /srv/www/htdocs/caipiroska/MM/.htpasswd
  Require            valid-user
</Location>

# KDE ICONS (needed for update_rss.sh)
<Location /kde-icons>
  Allow from         all
</Location>

# GNOME ICONS (needed for caipithek.php)
<Location /gnome-icons>
  Allow from         all
</Location>

# LX-OFFICE
<Directory /srv/www/htdocs/lx-office-erp>
  SSLRequireSSL
</Directory>

<Directory /srv/www/htdocs/lx-erp>
  SSLRequireSSL
  Options ExecCGI Includes FollowSymlinks
</Directory>

<Directory /srv/www/htdocs/lx-erp/users>
  Deny from          all
</Directory>

<Directory /srv/www/htdocs/phpPgAdmin>
  SSLRequireSSL
</Directory>

Viele Direktiven dieser Konfiguration wurden bereits im Abschnitt Basis-Setup beschrieben, und deshalb sollen nur noch neue Konfigurationen erläutert werden:

Das Verzeichnis /srv/www/htdocs/hle soll nur aus bestimmten IP-Adreßbereichen zugänglich sein. Deswegen wurde der Zugriff in der entsprechenden Directory-Direktive zunächst für alle gesperrt und dann selektiv für einige Netzwerke zugelassen.
Für das Verzeichnis /home/shared gilt ebenfalls das eben Gesagte.
Für das Verzeichnis /srv/www/htdocs/hle/bugzilla werden weitere Einstellungen vorgenommen, welche so in der Installationsanleitung für Bugzilla beschrieben sind. Da dieses Verzeichnis ein Unterverzeichnis zu /srv/www/htdocs/hle ist, gelten natürlich zusätzlich die oben beschriebenen IP-Zugangsbeschränkungen.

Auch das Verzeichnis /etc/apache2/vhosts.d/vhosts.conf sieht nun anders aus. Der Einfachheit halber habe ich in dieser Datei keine bedingten Schleifen untergebracht, wie es sie in /etc/apache2/vhosts.d/vhost-ssl.template gibt. Stattdessen werden direkt namensbasierte virtuelle Hosts für unverschlüsselte und für verschlüsselte Verbindungen definiert. Das sieht dann so aus:

#
# Konfiguration virtueller Hosts auf CAIPIROSKA
#
# Gabriel Rüeck, 20.10.2010

NameVirtualHost *:80
NameVirtualHost *:443

# Non-SSL-Konfiguration
<VirtualHost *:80>
  ServerName            caipiroska.homelinux.org
  ServerAlias           caipiroska
  ServerAdmin           gabriel@rueeck.de
  DocumentRoot          /srv/www/htdocs/caipiroska
  ErrorLog              /var/log/apache2/caipiroska_error_log
  CustomLog             /var/log/apache2/caipiroska_access_log combined

  # Umleitungen auf die neu angemietete Domain rueeck.name
  Redirect permanent    /coppermine  http://rueeck.name/coppermine
  Redirect permanent    /mediawiki   http://rueeck.name/mediawiki
  Redirect permanent    /lx-erp      https://rueeck.name/lx-erp
  Redirect permanent    /phpPgAdmin  https://rueeck.name/phpPgAdmin
  Redirect permanent    /groupoffice https://rueeck.name/groupoffice
</VirtualHost>

<VirtualHost *:80>
  ServerName            hle.homelinux.org
  ServerAdmin           gabriel@rueeck.de
  DocumentRoot          /srv/www/htdocs/hle
  ErrorLog              /var/log/apache2/hle_error_log
  CustomLog             /var/log/apache2/hle_access_log combined

  # Spezifische Alias-Definitionen
  Alias /DIS            /home/shared
  Alias /MIS            /home/shared/programs
  Alias /HAL            /home/shared/mediawiki
  Alias /coppermine     /home/shared/coppermine
  Alias /pictures       /home/shared/pictures

  <Location /pictures>
    Options             Indexes
    IndexOptions        +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8
  </Location>
</VirtualHost>

<VirtualHost *:80>
  ServerName            ba-berlin.homelinux.org
  ServerAdmin           gabriel@rueeck.de
  DocumentRoot          /srv/www/htdocs/ba-berlin
  ErrorLog              /var/log/apache2/ba-berlin_error_log
  CustomLog             /var/log/apache2/ba-berlin_access_log combined
</VirtualHost>

# SSL-Konfiguration
<VirtualHost *:443>
  SSLEngine             on
  SSLCertificateFile    /etc/apache2/ssl.crt/server.crt
  SSLCertificateKeyFile /etc/apache2/ssl.key/server.key
  SSLOptions            StrictRequire
  ServerName            caipiroska.homelinux.org
  ServerAlias           caipiroska
  ServerAdmin           gabriel@rueeck.de
  DocumentRoot          /srv/www/htdocs/caipiroska
  ErrorLog              /var/log/apache2/caipiroska_error_log
  CustomLog             /var/log/apache2/caipiroska_access_log combined

  # Umleitungen auf die neu angemietete Domain rueeck.name
  Redirect permanent    /coppermine  http://rueeck.name/coppermine
  Redirect permanent    /mediawiki   http://rueeck.name/mediawiki
  Redirect permanent    /lx-erp      https://rueeck.name/lx-erp
  Redirect permanent    /phpPgAdmin  https://rueeck.name/phpPgAdmin
  Redirect permanent    /groupoffice https://rueeck.name/groupoffice

  <Directory /srv/www/htdocs/caipiroska/MM>
    AuthName            "Secure Access on CAIPIRINHA"
    AuthType            Digest
    AuthUserFile        /srv/www/htdocs/caipiroska/MM/.htpasswd
    Require             valid-user
    Options             Indexes FollowSymLinks
    IndexOptions        +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8
  </Directory>
</VirtualHost>                                  

<VirtualHost *:443>
  SSLEngine             on
  SSLCertificateFile    /etc/apache2/ssl.crt/hle_auf_caipiroska.crt
  SSLCertificateKeyFile /etc/apache2/ssl.key/hle_auf_caipiroska.key
  SSLOptions            StrictRequire
  ServerName            hle.homelinux.org
  ServerAdmin           gabriel@rueeck.de
  DocumentRoot          /srv/www/htdocs/hle
  ErrorLog              /var/log/apache2/hle_error_log
  CustomLog             /var/log/apache2/hle_access_log combined

  # Spezifische Alias-Definitionen
  Alias /DIS            /home/shared
  Alias /MIS            /home/shared/programs
  Alias /HAL            /home/shared/mediawiki
  Alias /coppermine     /home/shared/coppermine
  Alias /pictures       /home/shared/pictures

  <Location /pictures>
    Options             Indexes
    IndexOptions        +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8
  </Location>
</VirtualHost>                                  

<VirtualHost *:443>
  SSLEngine             on
  SSLCertificateFile    /etc/apache2/ssl.crt/ba-berlin.crt
  SSLCertificateKeyFile /etc/apache2/ssl.key/ba-berlin.key
  SSLOptions            StrictRequire
  ServerName            ba-berlin.homelinux.org
  ServerAdmin           gabriel@rueeck.de
  DocumentRoot          /srv/www/htdocs/ba-berlin
  ErrorLog              /var/log/apache2/ba-berlin_error_log
  CustomLog             /var/log/apache2/ba-berlin_access_log combined
</VirtualHost>

Hier muss noch Einiges erklärt werden:

Zunächst einmal muss man beachten, dass es insgesamt drei DocumentRoots gibt, welche den einzelnen Domains zugeordnet sind. Die Domains werden mit dem Schlüsselwort ServerName zugeordnet.
Jede Domain hat ihre eigenen Log-Dateien. Das ist erforderlich, weil ja mit dem Paket Webalizer auch Statistiken für jede Domain getrennt erfasst werden sollen.
Für jede Domain existiert sowohl ein Server für unverschlüsselte Verbindungen auf Port 80 als auch ein Server für verschlüsselte Verbindungen auf Port 443.
Jeder Server für verschlüsselte Verbindungen hat sein eigenes Server-Zertifikat (*.crt) und seine eigene Schlüsseldatei (*.key), die mit den Direktiven SSLCertificateFile und SSLCertificateKeyFile zugeordnet werden.
Speziell für die Domain caipiroska.homelinux.org gilt:
- Einige Unterseiten werden umgeleitet auf entsprechende Seiten auf der Maschine http://rueeck.name. Dies wird durch die Direktive Redirect erreicht. Die Option Permanent signalisiert dem aufrufenden Client mit dem Statuscode 301, dass der Inhalt der Webseite “endgültig” zur neuen Adresse umgezogen ist.
- Über eine gesicherte Verbindung kann man das Verzeichnis /srv/www/htdocs/caipiroska/MM erreichen, welches noch eine Authentifizierung erfordert.
Speziell für die Domain hle.homelinux.org gilt:
- Mit der Alias-Direktive werden einige Verzeichnisse außerhalb des DocumentRoot definiert.
- Der Inhalt des Verzeichnisses /home/shared/pictures kann aufgelistet werden. Dabei werden bestimmte Sortierkriterien eingehalten, die zusätzlich (deswegen das “+”-Zeichen) zu den Default-Optionen aktiviert werden (+IgnoreCase +FoldersFirst +VersionSort). Außerdem wird das Listing mit dem Zeichensatz UTF-8 durchgeführt (+Charset=UTF-8).

Die Server-Zertifikate sind mit den Skripten des OpenVPN-Paketes erzeugt worden. Mit YaST2 müssen jetzt mit dem Editor für /etc/sysconfig noch einige Variablen beim Caipiroska-Server richtig gesetzt werden:

Applications→SuSEhelp→DOC_HOST wird auf caipiroska.homelinux.org gesetzt.
Applications→SuSEhelp→DOC_ALLOW bleibt leer.
Applications→SuSEhelp→DOC_AUTOINDEX wird auf yes gesetzt.
Network→WWW→Apache→SuSEhelp→DOC_SERVER wird auf yes gesetzt.
Network→WWW→Apache2→APACHE_CONF_INCLUDE_FILES wird auf /etc/apache2/httpd.conf.local gesetzt, damit unsere Konfigurationsdatei von oben überhaupt verarbeitet wird.
Network→WWW→Apache2→APACHE_CONF_INCLUDE_DIRS bleibt leer.
Network→WWW→Apache2→APACHE_MODULES muss mindestens die Module actions alias auth_basic auth_digest authn_file authz_host authz_default authz_user autoindex cgi charset_lite dav dav_fs dav_lock deflate dir env expires imagemap include log_config mime mime_magic negotiation setenvif suexec ssl userdir php5 beinhalten.
Network→WWW→Apache2→APACHE_SERVER_FLAGS wird auf -D SSL gesetzt, um SSL zu aktivieren.
Network→WWW→Apache2→APACHE_HTTPD_CONF bleibt leer.
Network→WWW→Apache2→APACHE_MPM bleibt leer.
Network→WWW→Apache2→APACHE_SERVERADMIN wird auf root@caipiroska.homelinux.org eingestellt.
Network→WWW→Apache2→APACHE_SERVERNAME wird auf caipiroska.homelinux.org eingestellt.
Network→WWW→Apache2→APACHE_START_TIMEOUT wird auf 20 gestellt.
Network→WWW→Apache2→APACHE_SERVERSIGNATURE wird auf on gesetzt.
Network→WWW→Apache2→APACHE_LOGLEVEL wird auf warn gesetzt.
Network→WWW→Apache2→APACHE_ACCESS_LOG wird auf /var/log/apache2/access_log combined gesetzt.
Network→WWW→Apache2→APACHE_USE_CANONICAL_NAMES wird auf off gesetzt.
Network→WWW→Apache2→APACHE_SERVERTOKENS wird auf OS gesetzt.
Network→WWW→Apache2→APACHE_EXTENDED_STATUS wird auf off gesetzt.

Die hier genannten Einstellungen finden sich dann auch in den System-Dateien:

/etc/sysconfig/susehelp
/etc/sysconfig/apache2

Danach kann der Apache-Webserver mit /etc/init.d/apache start in Betrieb genommen werden, und alles sollte funktionieren.

Webalizer

Mit dem Paket webalizer ist es möglich, umfassende Server-Statistiken anhand der Analyse der Log-Dateien des Apache-Webservers zu erstellen. Die notwendigen Einstellungen werden in der Konfigurationsdatei /etc/webalizer.conf vorgenommen, in der sich schon sinnvolle Voreinstellungen befinden. Im Wesentlichen müssen hier folgende Einstellungen, deren Optionen ausführlich in /etc/webalizer.conf beschrieben sind, angepasst werden:

/etc/webalizer.conf:

...
LogFile        /var/log/apache2/access_log
OutputDir      /srv/www/htdocs/webalizer
Incremental    yes
HostName       caipirinha.homelinux.org
UseHTTPS       yes
Quiet          yes
GMTTime        yes
CountryGraph no
...

Die im Bild Webserver-Statistik aufgelisteten Monate können noch weiter aufgeschlüsselt werden. So kann man sich anschauen, welche Datei am Häufigsten herunter geladen wurde, wie oft ein bestimmter Fehler, beispielsweise 404, aufgetreten ist, aus welchen Top Level Domains die Zugriffe kamen, etc.

Um die Statistiken aktuell zu halten, muss webalizer allerdings auch regelmäßig aufgerufen werden. Am Besten ist es daher, einen entsprechenden Eintrag in der crontab von root zu machen, etwa so:

...
# Crontab für root
#
LANG   = de_DE.UTF-8
LC_ALL = de_DE.UTF-8
MAILTO = root@rueeck.name
SHELL  = /bin/bash
#
05  00  *    *  *    umask 0022; webalizer -c /etc/webalizer.conf
...

Das hier vor den webalizer-Aufruf gestellte umask-Kommando macht die durch den Benutzer root erstellten Statistiken für alle (und damit auch für den Apache-Benutzer wwwrun) lesbar. Dies wurde erforderlich, weil auf dem Caipirinha– und auf dem Caipiroska-Server die Benutzerrechte aus Sicherheitsgründen einheitlich restriktiv auf 0077 gesetzt wurden. Damit werden dann täglich die Statistiken erneuert.

Bei einem virtuellen Server sind darüber hinaus weitere Dinge zu beachten [22]. So muss für jede virtuelle Domain jeweils eine separate webalizer-Instanz aufgerufen werden.

Posted on: 2010-09-14Gabriel Rüeck