LPI-Prüfungsvorbereitung LPIC-2

Verwaltung eines Webservers
Bewertung 2
Die Kandidaten sollten in der Lage sein, Apache für die Verwendung von virtuellen Hosts für Websites ohne fixe IP-Adressen zu konfigurieren. Dieses Lernziel beinhaltet auch die Erstellung eines SSL-Zertifikates für Apache und die Definition von SSL in den Konfigurationsdateien unter Verwendung von OpenSSL. Ebenfalls enthalten ist die Anpassung von Dateizugriff durch die Implementierung von redirect Statements in den Apache Konfigurationsdateien.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:

httpd.conf

Virtuelle Webserver verwalten
Die dritte Sektion der zentralen Konfigurationsdatei von Apache dient der Definition von virtuellen Servern. Virtuelle Server sind sozusagen Nebenserver, die vom selben Webserver verwaltet werden, aber eine andere Dokumentenwurzel benutzen. Dazu kommt, daß diese Server auch noch entweder über andere IP-Adressen oder andere DNS-Namen ansprechbar sind.
Die Definition eines virtuellen Servers ermöglicht es also dem Webserver zu entscheiden, an welchen DNS-Namen bzw. welche IP-Adresse die Anfrage ging. Diese Entscheidung führt dann zu unterschiedlichen DocumentRoots also werden unterschiedliche Seiten angezeigt.
Linux bietet zu diesem Zweck die Möglichkeit, daß eine einzige Ethernetkarte mehrere IP-Adressen bekommen kann. Dazu wird der Bezeichnung der Ethernetkarte (z.B. eth0) einfach ein Doppelpunkt und eine Nummer zugefügt (eth0:1, eth0:2, ...). Jeder dieser "virtuellen Netzwerkkarten" kann jetzt eine eigene IP-Adresse vergeben werden. Entweder mit dem entsprechenden Konfigurationsprogramm (yast, linuxconf,...) oder mit dem Befehl:
  ifconfig eth0:1 Adresse netmask Maske
Wenn diese zweite (dritte, vierte, ...) Adresse jetzt im Nameserver einen eigenen Eintrag erhält, so kann tatsächlich der Webserver darauf reagieren. Dazu müssen in der Konfigurationsdatei ein paar zusätzliche Einträge vorhanden sein:
  NameVirtualHost  IP-Adresse
Dieser Eintrag ist nur nötig, um mehrere namensbasierte Virtuelle Server aufzubauen. Die IP-Adresse ist die der "virtuellen Netzwerkkarte" wie oben beschrieben.
Jetzt können wir die einzelnen virtuellen Server definieren. Dazu werden wiederum Angaben in spitzen Klammern gemacht, entweder mit IP-Adressen (von virtuellen Karten) oder mit Hostnamen (Alias-Einträge im Nameserver, die auf die virtuelle Karte verweisen).
Jeder dieser Einträge bekommt jetzt einen eigenen DocumentRoot und kann alle bisher besprochenen Direktiven des normalen Servers enthalten. Ein Beispiel:
  NameVirtualHost 10.230.1.101

  <VirtualHost 10.230.1.101>
    ServerAdmin root@marvin.mydomain.de
    DocumentRoot /www2
    ServerName virtual1.mydomain.de
  </VirtualHost>

  <VirtualHost 10.230.1.101>

    ServerAdmin hans@marvin.mydomain.de
    DocumentRoot /www3
    ServerName virtual2.mydomain.de
    <Directory /www3/specialdir>
       AllowOverride All
    </Directory>
  </VirtualHost>
Hier haben wir also zwei virtuelle Hosts definiert, beide wurden über ein und dieselbe IP-Adresse (10.230.1.101) definiert, aber beide unterscheiden sich anhand ihres Namens. Natürlich muß der zweite Name entsprechend im Nameserver vorhanden sein und als Alias auf den ersten Rechner gesetzt sein.
Die zweite Möglichkeit virtueller Hosts ist die Adressenbasierte. Hier ist die Angabe des NameVirtualHost-Befehls nicht nötig. Dafür muß jeder virtuelle Server eine eigene IP-Adresse besitzen. Mit der oben gezeigten Methode ist das bis zu einem bestimmten Punkt möglich. Ab einer gewissen Anzahl (etwa ab 4 virtuellen Hosts) bietet es sich aber an, namensbasierte Hosts zu generieren, statt mit x virtuellen Netzwerkkarten zu arbeiten...
Innerhalb der <VirtualHost> Klammerung können alle Direktiven stehen, die auch schon für die Konfiguration des Hauptservers zur Anwendung kamen. Es sind also vollständig autarke Server, denen sogar eigene CGI-Verzeichnisse gegeben werden können. Das folgende Beispiel zeigt zwei virtuelle Hosts, die Adressenbasiert aufgebaut sind und je ein eigenes cgi-bin Verzeichnis besitzen:
  <VirtualHost 10.230.1.105>
    ServerAdmin root@marvin.mydomain.de
    DocumentRoot /www1/htdocs
    ScriptAlias /cgi-bin/ "www1/cgi-bin/"
    ServerName virtual1.mydomain.de
  </VirtualHost>

  <VirtualHost 10.230.1.106>
    ServerAdmin hans@marvin.mydomain.de
    DocumentRoot /www2/htdocs
    ScriptAlias /cgi-bin/ "www2/cgi-bin/"
    ServerName virtual2.mydomain.de
  </VirtualHost>
Erstellen eines SSL-Zertifikates
In der Regel wird bei der Installation von Apache-ssl bereits ein Zertifikat erstellt, es gibt jedoch die Möglichkeit, dieses Zertifikat selbst manuell zu erstellen. Entweder wird über die Quellen von Apache-SSL das Makefile benutzt, dann reicht es, zu schreiben
  make certificate
Soll jedoch ein kompletter Schlüsselsatz manuell erstellt werden, ohne den Server-Quellcode zu besitzen, dann wird das Programm openssl benötigt. Die einzelnen notwendigen Schritte sind:
  openssl req -new > new.cert.csr
Dadurch wird ein Schlüsselpaar erzeugt, in unserem Beispiel haben wir jetzt die beiden Dateien
  new.cert.csr  
  privkey.pem
angelegt. Die erste enthält das Request-Zertifikat, die zweite den Private-Key. Während des Anlegens musste ein Passwort für den Schlüssel angegeben werden. Dieses Passwort kann jetzt entfernt werden, da in der Regel keine Abfrage beim Aufbau einer https-Verbindung gewünscht ist.
  openssl rsa -in privkey.pem -out new.cert.key
Wie angegeben haben wir jetzt den Schlüssel new.cert.key erzeugt.
Abschließend müssen wir noch das Request-Zertifikat in ein Signiertes Zertifikat umwandeln:
  openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days 365
Dadurch haben wir jetzt die Datei new.cert.cert angelegt, die ein signiertes Zertifikat enthält.
Diese Dateien werden jetzt unter anderen Namen in ein Verzeichnis kopiert, auf das der Webserver Zugriff hat, in der Regel etwas wie /etc/apache/ssl. Die Namen werden dahingehend verändert, dass sie alle die Endung .pem bekommen.
  cp new.cert.cert /etc/apache/ssl/ServerCert.pem
  cp new.cert.key  /etc/apache/ssl/ServerKey.pem
Jetzt müssen wir diese Zertifikate nur noch in der Konfigurationsdatei aktivieren:
SSL aktivieren
In der Datei httpd.conf benötigen wir jetzt die folgenden Direktiven:
  SSLCertificateFile /etc/apache/ssl/ServerCert.pem
  SSLCertificateKeyFile /etc/apache/ssl/ServerKey.pem
Der Apache-SSL-Server lauscht auf den TCP-Port 443
Später kann über die Direktiven SSLVerifyClient, SSLVerifyDepth, SSLRequire, SSLOptions und SSLRequireSSL auch noch genau festgelegt werden, welche Clients sich wie mit dem Server verbinden dürfen. In der Regel ist das aber nicht immer erwünscht, meistens geht es ja nur darum, sicherzustellen, dass ein Server tatsächlich der ist, der er ausgibt zu sein und dass die Übermittlung sensibler Daten verschlüsselt stattfindet.
Links zum Thema SSL

Das SSL-Apache Handbuch (deutsch)
Apache-SSL Homepage (englisch)

Redirect-Statements
Die Redirect-Direktive in httpd.conf dient dazu, eine alte URL in eine neue umzuleiten. Alle Nachfragen, die mit dem Pfad der alten URL beginnen, werden auf die angegebene neue URL umgeleitet.
Die Syntax des Redirect-Befehls ist
  Redirect [Status] URL-Pfad URL
Der Befehl
  Redirect /test http://www.anderer.rechner.de/test
würde also alle Anfragen an das Verzeichnis /test auf das entsprechende Verzeichnis des Rechners www.anderer.rechner.de umleiten. Würde ein User also die Datei /test/foobar.html anfordern, so würde er stattdessen auf die URL http://www.anderer.rechner.de/test/foobar.html umgeleitet.
Das optionale Status-Argument kann folgende Werte annehmen:

permanent
Der Server gibt in der Antwort den Code 301 zurück, der auf eine permanente Umleitung hinweist.
temp
Der Server gibt in der Antwort den Code 302 zurück, der auf eine temporäre Umleitung hinweist. Wird der Status weggelassen, so ist das die Voreinstellung.
seeother
Der Server gibt in der Antwort den Code 303 zurück, der auf eine darauf hinweist, dass die URL gewechselt hat.
gone
Der Server gibt in der Antwort den Code 410 zurück, der darauf hinweist, dass die URL gelöscht wurde. In diesem Fall wird nicht umgeleitet und die Angabe der neuen URL sollte weggelassen werden.

[ Zurück zur Startseite LPI 201 ] [ Zurück zur LPI-Seite ] [ Zurück zur Hauptseite von Linux-Praxis ] [ Guestbook ] [ Kontakt ]
Diese und die darunterliegenden Seiten wurden erstellt von F. Kalhammer
© 2001 by F.Kalhammer -
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License..