Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einführung
2 Mathematische und technische Grundlagen
3 Hardware
4 Netzwerkgrundlagen
5 Betriebssystemgrundlagen
6 Windows
7 Linux
8 Mac OS X
9 Grundlagen der Programmierung
10 Konzepte der Programmierung
11 Software-Engineering
12 Datenbanken
13 Server für Webanwendungen
14 Weitere Internet-Serverdienste
15 XML
16 Weitere Datei- und Datenformate
17 Webseitenerstellung mit (X)HTML und CSS
18 Webserveranwendungen
19 JavaScript und Ajax
20 Computer- und Netzwerksicherheit
A Glossar
B Zweisprachige Wortliste
C Kommentiertes Literatur- und Linkverzeichnis
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
IT-Handbuch für Fachinformatiker von Sascha Kersken
Der Ausbildungsbegleiter
Buch: IT-Handbuch für Fachinformatiker

IT-Handbuch für Fachinformatiker
Rheinwerk Computing
1216 S., 6., aktualisierte und erweiterte Auflage, geb.
34,90 Euro, ISBN 978-3-8362-2234-1
Pfeil 13 Server für Webanwendungen
Pfeil 13.1 HTTP im Überblick
Pfeil 13.1.1 Ablauf der HTTP-Kommunikation
Pfeil 13.1.2 HTTP-Statuscodes
Pfeil 13.1.3 HTTP-Header
Pfeil 13.2 Der Webserver Apache
Pfeil 13.2.1 Apache im Überblick
Pfeil 13.2.2 Apache-Module
Pfeil 13.2.3 Apache installieren
Pfeil 13.2.4 Apache-Konfiguration
Pfeil 13.3 PHP installieren und einrichten
Pfeil 13.3.1 Installation
Pfeil 13.3.2 Die PHP-Konfigurationsdatei »php.ini«
Pfeil 13.4 Zusammenfassung

Rheinwerk Computing - Zum Seitenanfang

13.2 Der Webserver ApacheZur nächsten Überschrift

Der Apache HTTP Server (kurz Apache) ist die mit Abstand verbreitetste Webserversoftware mit einem Marktanteil von 60 bis 70 %. Er entstand ab 1995, zunächst als Weiterentwicklung des NCSA-Webservers durch Detailverbesserungen (Patches), sodass der Name oft mit »a patchy web server« erklärt wird. Um seine Entwickler bildete sich die Apache Software Foundation, die neben dem Webserver auch zahlreiche andere bekannte Open-Source-Programme beheimatet, beispielsweise den Spam-Filter SpamAssassin, die Java-Servlet-Engine Tomcat (nebenbei ebenfalls ein Webserver) oder den XSLT-Prozessor Xalan (siehe Kapitel 15, »XML«).

Apache ist stabil, sicher und läuft auf den verschiedensten Plattformen. Ein Großteil seiner Funktionalität wird durch Module bereitgestellt. So kann er leicht durch Drittanbieter oder gar eigene Programmierung erweitert werden; außerdem können Sie nicht benötigte Teile deaktivieren, sodass sie nicht unnötig Ressourcen verschwenden.


Rheinwerk Computing - Zum Seitenanfang

13.2.1 Apache im ÜberblickZur nächsten ÜberschriftZur vorigen Überschrift

Es gibt zurzeit zwei verschiedene aktive Apache-Entwicklungszweige. Neue Features werden zwar nur noch für den aktuell stabilen Zweig 2.4.x implementiert, aber es gibt bei Bedarf noch Bugfixes für den 2.2-Zweig. Die früheren Versionen 1.3 und 2.0 wurden inzwischen mit je einem finalen Bugfix-Release eingestellt. Tabelle 13.4 zeigt die drei letzten Versionen im Überblick.

Tabelle 13.4 Die verschiedenen Apache-Versionszweige

Versionszweig aktuelles Release Eigenschaften

2.0.x

2.0.65

Neuentwicklung, inkompatibel mit den alten 1.x-Versionen

Netzwerk- und andere Systemfunktionen werden jeweils plattformoptimiert durch die Abstraktionsschicht Apache Portable Runtime (APR) bereitgestellt.

Module dynamisch ladbar

verschiedene Laufzeitverhalten durch Multi-Processing-Module (MPM)

Versionszweig wurde mit 2.0.65 eingestellt.

2.2.x

2.2.25

Detailverbesserungen gegenüber Version 2.0.x, z. B.:

Neuordnung der Authentifizierungsmodule

eingebaute Datenbankschnittstelle

Viele Betriebssystemdistributionen werden noch mit 2.2.x ausgeliefert.

2.4.x

2.4.4

Auch MPM sind nun dynamisch ladbar.

Neuordnung der Autorisierungsmodule
(Zugriffskontrolle)

aktueller Entwicklungszweig

Im Folgenden wird vorwiegend die aktuelle, stabile Version 2.4 besprochen, mit ein paar Hinweisen auf den vorigen Entwicklungszweig 2.2. Die in der Tabelle bereits kurz angedeuteten Eigenschaften von Apache 2 sind:

  • Abstraktionsbibliothek APR
    Bis zur Version 1.3.x verwendete Apache die auf Unix-Systemen üblichen POSIX-Systemaufrufe zur Verwaltung von Netzwerkverbindungen, Speicher, Dateizugriffen und so weiter. Auf Nicht-Unix-Systemen kam deshalb eine POSIX-Emulationsschicht zum Einsatz, die Apache auf diesen Plattformen allerdings langsamer und weniger stabil machte. Deshalb wurden solche systemnahen Funktionen für die neue Version 2 in die Abstraktionsbibliothek Apache Portable Runtime (APR) ausgelagert, die sie für jedes System nach dessen besten Möglichkeiten bereitstellt. Inzwischen wird die APR daher auch als Grundlage anderer Software eingesetzt.
  • Unterschiedliche Laufzeitmodelle durch MPM
    Ein Netzwerkserver muss in der Lage sein, mehrere Clientanfragen gleichzeitig zu beantworten. Dafür gibt es je nach System unterschiedliche Prozess- oder Thread-Verfahren (siehe Abschnitt 10.4, »Einführung in die Netzwerkprogrammierung«). Apache 1.x verwendete ausschließlich ein Preforking-Modell, das heißt, er erzeugte einige Child-Prozesse auf Vorrat. Apache 2 ermöglicht dagegen die Auswahl verschiedener sogenannter Multi-Processing-Module (MPM), die auf Prozessen, Threads oder einer Mischung aus beiden basieren, sodass für jedes System die vorteilhafteste Auswahl getroffen werden kann.

    In der neuen Version 2.4 sind die MPM sogar dynamisch zur Laufzeit ladbar, genau wie alle anderen Module.

  • Dynamische Module
    Die bereits in der Einleitung erwähnten Apache-Module mussten früher statisch einkompiliert werden. Apache musste also für jeden Wechsel der Modulauswahl ganz neu kompiliert werden. In Apache 2 besteht dagegen die Möglichkeit, Module als Dynamic Shared Objects (DSO) zu kompilieren und über die Konfigurationsdatei ein- oder auszuschalten. Somit braucht der Server nur neu gestartet zu werden, wenn Sie neue Module hinzufügen oder vorhandene entfernen möchten.
  • Eingebaute SSL-Unterstützung
    Sicherheitsbedürftige Webanwendungen wie E-Commerce oder gar Homebanking benötigen gesicherte Verbindungen, die die Identität des Servers und die Integrität der Daten garantieren sowie die Kommunikation verschlüsseln. Die Lösung für diese Anforderung ist HTTP über SSL, kurz HTTPS. Bis Apache 1.3 gab es dafür diverse Erweiterungen, teilweise von Drittanbietern. Apache 2 ist dagegen ab Werk mit dem Modul mod_ssl ausgestattet, das die SSL-Funktionalität nahtlos integriert.

Rheinwerk Computing - Zum Seitenanfang

13.2.2 Apache-ModuleZur nächsten ÜberschriftZur vorigen Überschrift

Zum Lieferumfang von Apache gehören gut 70 verschiedene Module. Daneben gibt es unzählige Erweiterungen von unabhängigen Anbietern, sowohl als Open Source als auch kommerziell. Die meisten dieser Zusatzmodule werden auf der Site http://modules.apache.org/ erwähnt und verlinkt.

Tabelle 13.5 enthält eine Übersicht über die wichtigsten mitgelieferten Module. Die Spalte »aktiv« informiert darüber, ob das jeweilige Modul in einer Standardinstallation von Apache automatisch mitinstalliert und aktiviert wird oder nicht.

Tabelle 13.5 Die wichtigsten Module in Apache 2.4

Modul aktiv Beschreibung

mod_authz_host

ja

Zugriffsschutz anhand von Client-Hostnamen und/oder -IP-Adressen

mod_alias

ja

Einbinden externer Verzeichnisse in den URL-Namensraum der Website; interne und externe Weiterleitungen

mod_auth_basic

ja

Grundmodul zur Authentifizierung, das die Anmeldedaten vom Client (klartextbasiert) entgegennimmt und anschließend mithilfe verschiedener Provider-Module auf ihre Gültigkeit überprüft

mod_auth_digest

nein

wie mod_auth_basic, allerdings MD5-verschlüsselt

mod_authn_dbd

nein

Authentifizierungs-Provider-Modul, das eine SQL-Abfrage an eine externe Datenbank sendet, um die Anmeldedaten zu überprüfen

mod_authn_dbm

nein

Authentifizierungs-Provider; verwendet datenbankähnliche DBM-Dateien.

mod_authn_file

ja

Authentifizierungs-Provider; verwendet einfache Textdateien.

mod_authnz_ldap

nein

Authentifizierungs-Provider; befragt ein externes LDAP-Verzeichnis.

mod_authz_dbm

nein

Vergleicht Gruppenzugehörigkeiten mithilfe von DBM-Dateien.

mod_authz_groupfile

ja

Vergleicht Gruppenzugehörigkeiten mithilfe einfacher Textdateien.

mod_autoindex

ja

automatisch generierte Verzeichnisindizes für Verzeichnisse ohne Startseite

mod_cgi

ja

Unterstützung für CGI-Skripte, das heißt externe Programme oder interpretierte Skripte als Webanwendungen

mod_dbd

nein

Integrierte Datenbankschnittstelle; wird u. a. für mod_authn_dbd benötigt.

mod_dir

ja

Definition des Startseitennamens sowie Verarbeitung von Anfragen, die ein Verzeichnis statt einer Datei anfordern

mod_env

ja

Setzen und Ändern von Server-Umgebungsvariablen

mod_headers

nein

Manipulation der Anfrage- und Antwort-Header

mod_imagemap

ja

Unterstützung serverseitiger Image Maps, d. h. Bilder mit verschiedenen anklickbaren Bereichen

mod_include

ja

Server Side Includes, eine der ältesten Technologien zum Einbinden dynamischer Daten in Webseiten

mod_ldap

nein

LDAP-Verbindung und erweiterte Optionen
(z. B. Caching) für LDAP-basierte Module wie mod_authnz_ldap

mod_log_config

ja

Formatierung von Server-Log-Dateien mithilfe zahlreicher Platzhalter

mod_mime

ja

Setzt Entity-Header wie Content-Type inklusive Zeichensatz anhand der Dateiendung(en) einer Ressource.

mod_mime_magic

nein

Ermittelt den MIME-Type aufgrund des Dateiinhalts, wie das Unix-Kommando file.

mod_negotiation

ja

Content-Negotiation, d. h. Lieferung verschiedener Varianten einer Ressource anhand der Accept*-Anfrage-Header

mod_rewrite

nein

beliebige URL-Manipulationen auf der Basis regulärer Ausdrücke

mod_setenvif

ja

Setzen und Ändern von Server-Umgebungsvariablen je nach den Werten bestimmter Anfrage-Header

mod_ssl

nein

gesicherte HTTPS-Verbindungen

mod_userdir

ja

Ermöglicht persönliche Websites für die Benutzerkonten des Servers unter http://servername/~username.


Rheinwerk Computing - Zum Seitenanfang

13.2.3 Apache installierenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie eine Unix-Variante verwenden, können Sie zunächst überprüfen, ob Apache zum Lieferumfang Ihrer Distribution gehört – dies wird meist der Fall sein. Falls Sie aber mehr Kontrolle über den Installationsumfang ausüben möchten oder die aktuellste Version brauchen, sollten Sie Apache mithilfe des offiziellen Sourcecode-Pakets selbst kompilieren. Für Windows liefert die Apache Software Foundation dagegen einen offiziellen Binär-Installer.

Installation auf Unix-Systemen

Laden Sie zunächst das neueste Release von Apache 2.4 (Anfang Juli 2013: 2.4.4) von http://httpd.apache.org/ herunter. Falls zu dem Zeitpunkt, zu dem Sie dieses Buch lesen, bereits ein neueres Release verfügbar ist, wird Ihnen dieses automatisch angeboten. Die Download-Site wählt automatisch einen nahe gelegenen Mirror, sodass Sie nach dem Download die Integrität des Pakets überprüfen sollten. Dazu müssen Sie die MD5-Prüfsumme der heruntergeladenen Datei ermitteln und mit dem Wert auf der Apache-Website vergleichen. Geben Sie dazu beispielsweise dieses Kommando ein:

$ md5sum httpd-2.4.4.tar.gz

Unter Mac OS X heißt das Kommando md5 statt md5sum.

Als Nächstes können Sie das Paket auspacken. Geben Sie für die .tar.gz-Variante Folgendes ein:

$ tar xzvf httpd-2.4.4.tar.gz

Haben Sie dagegen ein .tar.bz2-Archiv heruntergeladen, lautet die Eingabe:

$ tar xjvf httpd-2.4.4.tar.bz2

Nun müssen Sie in das neu erstellte Verzeichnis wechseln:

$ cd httpd-2.4.4

Der erste Schritt besteht darin, das Skript configure auszuführen, das die Makefiles an Ihr System und mithilfe von Kommandozeilenparametern an Ihre Wünsche anpasst. Eine vollständige Liste aller verfügbaren Optionen erhalten Sie durch Eingabe von:

$ ./configure --help |less

Hier einige der wichtigsten Optionen im Überblick:

  • --prefix=/Verzeichnispfad
    übergeordnetes Verzeichnis, in das Apache installiert wird (Standard /usr/local/apache2)
  • --enable-layout=Layoutname
    Auswahl eines benannten Verzeichnislayouts aus der Datei layout.config; kann als Ersatz für oder zusätzlich zu --prefix angegeben werden.
  • --with-mpm=MPM-Modul
    Auswahl des passenden MPM – die wichtigsten sind prefork (rein prozessbasiert, Standard) und worker (gemischtes Prozess-/Thread-Modell). worker arbeitet auf Plattformen mit guter Thread-Unterstützung etwas speicherschonender, sollte aber nicht mit Drittanbietermodulen wie PHP eingesetzt werden.
  • --enable-so
    Aktiviert die grundsätzliche Unterstützung für Module als Dynamic Shared Objects; inzwischen ist diese Option Standard.
  • --enable-modules="modul1 modul2 ..."
    Kompiliert die angegebenen Module (ohne das Präfix mod_) statisch ein.
  • --enable-mods-shared="modul1 modul2 ..."
    Kompiliert die angegebenen Module als Shared Objects.
  • --enable-modules=most
    Kompiliert fast alle Module (außer die experimentellen sowie diejenigen, die Schwierigkeiten bereiten würden) statisch ein.
  • enable-mods-shared=most
    Kompiliert fast alle Module als Shared Objects.
  • --disable-modules="modul1 modul2 ..."
    Lässt die angegebenen Module explizit weg.

Das folgende Kommando bereitet Apache zur Installation ins Standardverzeichnis /usr/local/apache2 sowie zur Kompilierung fast aller Module als DSOs vor:

    Danach müssen Sie die beiden folgenden Kommandos eingeben, um die eigentliche Kompilierung sowie die Installation in das Zielverzeichnis durchzuführen:

    $ make
    # make install

    Mindestens den letzten Schritt müssen Sie als User root ausführen, da ein normaler User nicht in Verzeichnisse wie /usr/local schreiben darf.

    Nach der Installation können Sie Apache starten und anderweitig steuern. Dazu dient das Skript apachectl im Unterverzeichnis bin. Es besitzt unter anderem folgende Aufrufoptionen:

    • apachectl start
      Apache starten
    • apachectl stop
      Apache beenden
    • apachectl graceful-stop
      Apache beenden, aber erst nach Bearbeitung aller laufenden Clientanfragen (seit Version 2.2 verfügbar)
    • apachectl restart
      Apache neu starten – wichtig nach Konfigurationsänderungen
    • apachectl graceful
      Apache nach Fertigstellung der aktuellen Anfragen neu starten; manche Änderungen benötigen allerdings einen »richtigen« Neustart.

    Im Übrigen eignet sich apachectl auch als Startskript, das den automatischen Start von Apache beim Booten ermöglicht. Einzelheiten dazu finden Sie in Kapitel 7, »Linux«. Auf den meisten Linux-Systemen genügt es, einen Symlink auf apachectl in /etc/init.d abzulegen und diesen anschließend per chkconfig -a zu aktivieren. Beispiel:

    # ln -s /usr/local/apache2/bin/apachectl \
    /etc/init.d/apache2
    # chkconfig -a apache2

    Installation unter Windows

    Ein offizielles Windows-Binary-Release von Apache 2.4 gibt es noch nicht. Sie können es entweder selbst kompilieren (Anleitung in der offiziellen Apache-Dokumentation) oder von Drittanbieter-Websites wie http://www.apachelounge.com erhalten.

    Laden Sie den Apache-Installer (zurzeit httpd-2.2.25-win32-x86-openssl-0.9.8y.msi) von http://httpd.apache.org/ herunter.[Anm.: Es gibt auch eine SSL-freie Variante namens apache_2.2.25-win32-x86-no_ssl.msi – bis vor einigen Jahren gab es gar keine Windows-Version, die das Modul mod_ssl und die passende OpenSSL-Version mitlieferte.] Doppelklicken Sie danach auf das Icon des Installers.

    Befolgen Sie danach in jedem Fall die Installationsanweisungen. Der Dialog besteht aus den folgenden Seiten, auf denen Sie jeweils Next anklicken müssen, um fortzufahren:

    1. kurze Information, dass Apache 2 installiert wird
    2. Anzeige der Apache-Lizenz – eine typische Open-Source-Lizenz, die sowohl die freie Verwendung als auch die beliebige Veränderung des Webservers gestattet. Wählen Sie die Option I accept the terms in the license agreement.
    3. Informationstext über Apache 2 und Hinweise zu weiteren Informationsquellen
    4. Voreinstellungen einiger Konfigurationsdaten: Geben Sie unter Network Domain Ihren Domainnamen ein, etwa »test.local« für einen nicht öffentlichen Testserver. Als Server Name müssen Sie den DNS-Namen des Servers selbst angeben, zum Beispiel »www.test.local«. Die Administrators E-Mail Address ermöglicht Benutzern den Versand einer Mitteilung über Serverfehler, da sie auf automatisch generierten Fehlermeldungsseiten angezeigt wird; üblich ist die Adresse webmaster@<Domain>. Auch für einen lokalen Test sollten Sie Apache als vollwertigen Produktionsserver (For All Users, on Port 80, as a Service) installieren.[Anm.: Falls auf Ihrem System bereits Microsoft Internet Information Services oder ein anderer Webserver installiert ist, der Port 80 belegt, müssen Sie den Port nach der Installation über die Konfigurationsdatei wechseln (siehe den nächsten Abschnitt).]
    5. Wenn Sie Typical wählen, werden nur gängige Komponenten installiert. Custom ermöglicht dagegen die freie Auswahl, was zu bevorzugen ist.
    6. Wenn Sie Custom ausgewählt haben, wird nun eine Baumansicht mit den möglichen Komponenten der Installation angezeigt. In der Regel können Sie einfach die Wurzel anklicken und die Option This Feature, and all subfeatures, will be installed on local hard drive einstellen; dies erfordert knapp 50 MByte Festplattenspeicher. Am unteren Rand wird das Verzeichnis gewählt; der Vorgabewert ist Apache Software Foundation im Verzeichnis Program Files oder Programme.
    7. Wenn Sie doch noch etwas ändern möchten, können Sie nun auf Back klicken; andernfalls beginnt ein Klick auf Install mit der eigentlichen Installation.

    Wenn Sie Apache als Dienst installiert haben (siehe Punkt 4), startet er automatisch. Zur Verwaltung des Dienstes können Sie den mitinstallierten Apache Service Monitor verwenden, der im Systray als kleines Federsymbol angezeigt wird. Mit der rechten Maustaste können Sie dieses Programm öffnen und Apache 2 steuern.


    Rheinwerk Computing - Zum Seitenanfang

    13.2.4 Apache-KonfigurationZur nächsten ÜberschriftZur vorigen Überschrift

    Einstellungen für den Apache-Webserver werden in diversen Konfigurationsdateien vorgenommen. Bei Apache 2.0 befanden sich alle Einstellungen in der zentralen Datei httpd.conf, die standardmäßig unter /usr/local/apache2/conf (Unix) oder C:\Program Files\Apache Software Foundation\Apache2.2\conf (Windows) liegt.

    Seit Apache 2.2 wurden einige Einstellungen dagegen in separate Dateien im Unterverzeichnis extra ausgelagert. Um sie zu aktivieren, müssen Sie das Kommentarzeichen (#) vor der jeweiligen Include-Direktive in der Konfigurationsdatei httpd.conf entfernen. Im Einzelnen handelt es sich um folgende Dateien:

    • httpd-mpm.conf – Einstellungen für das jeweilige MPM, deren Änderung je nach Serverlast die Performance verbessern kann
    • httpd-multilang-errordoc.conf – Fehlermeldungsseiten in unterschiedlichen Sprachen
    • httpd-autoindex.conf – Einstellungen für automatisch generierte Verzeichnisseiten
    • httpd-languages.conf – Zuordnung zusätzlicher Dateiendungen zu Inhaltssprachen für Content-Negotiation
    • httpd-userdir.conf – benutzerspezifische Webverzeichnisse (http://servername/~username)
    • httpd-info.conf – Veröffentlichung von Serverinformationen unter einer speziellen URL
    • httpd-vhosts.conf – Konfiguration virtueller Hosts, das heißt verschiedener Websites für unterschiedliche Hostnamen oder IP-Adressen
    • httpd-manual.conf – Veröffentlichung der Apache-Dokumentation unter dem URL-Pfad /manual
    • httpd-dav.conf – Einstellungen für WebDAV (Web-based Distributed Authoring and Versioning), ein HTTP-basiertes Repository
    • httpd-default.conf – optionale Standardeinstellungen für den Server
    • httpd-ssl.conf – SSL-Konfiguration

    Der mit Ihrer Distribution gelieferte Apache verwendet oft eine andere Dateiaufteilung. Mitunter hilft es dann auch nichts, diese Dateien direkt zu editieren, da ihr Inhalt durch distributionseigene Tools oder Konfigurationsdateien bestimmt wird.

    Jede Apache-Konfigurationseinstellung (Direktive) hat das folgende Format:

    Direktive Wert [Wert ...]

    Außerdem existieren Container-Direktiven wie etwa <Directory> ... </Directory>, die die Wirkung der enthaltenen Apache-Direktiven auf bestimmte Verzeichnisse, Dateien oder andere Spezialwerte beschränken.

    Wichtige Konfigurationsdirektiven

    Es folgt eine Beschreibung der wichtigsten Apache-Direktiven. Für jede von ihnen wird das Modul mitgeteilt, das sie bereitstellt; core ist dabei kein Modul, sondern der immer verfügbare Funktionskern des Servers. Zudem erfahren Sie durch eine oder mehrere der nachfolgenden Abkürzungen diejenigen Kontexte, in denen eine Direktive stehen darf:

    • S – Serverkontext
      Diese Direktive gilt serverweit.
    • V – virtueller Host
      Die Direktive kann in einem <VirtualHost>-Container stehen und gilt dann nur für den betreffenden virtuellen Host.
    • D – Verzeichnis-Kontext
      Die Direktive gilt für einen Verzeichnisbereich und darf sich in einem <Directory>-, <Location>- oder <Files>-Container befinden.
    • H – .htaccess-Dateien
      Die Direktive darf in einer .htaccess-Datei stehen, über die Sie Konfigurationsdaten in die einzelnen Verzeichnisse der Website selbst auslagern können. .htaccess-Dateien werden nur benötigt, falls Sie bei einem Hoster Webspace angemietet haben oder umgekehrt virtuelle Hosts für andere User zur Verfügung stellen. Auf Ihrem eigenen Server sollten Sie dagegen alle Direktiven in die Datei httpd.conf beziehungsweise die mit ihr verknüpften Konfigurationsdateien schreiben.

    Ausführlichere Informationen zu diesen Direktiven sowie zu allen anderen finden Sie in der Apache-Originaldokumentation (http://httpd.apache.org/docs/2.4) sowie in meinem Buch »Apache 2.4« (4. Auflage, Bonn 2012, Galileo Press). Zu diesem Buch gibt es auch eine Website mit einer umfangreichen Direktivenliste (http://buecher.lingoworld.de/apache2/dirs.php).

    Die Werte mancher Direktiven sind Pfadangaben. Auch unter Windows müssen Sie in diesem Fall den Unix-Slash (/) als Pfadtrennzeichen verwenden. Falls Pfadangaben oder andere Werte Leerzeichen enthalten, müssen Sie sie in Anführungszeichen setzen.

    • Alias URL-Pfad Verzeichnispfad

      Kontext: SV; Modul: mod_alias

      Ein Verzeichnispfad, der sich außerhalb der DocumentRoot (siehe im Folgenden) befindet, wird an der angegebenen Stelle in den URL-Pfad eingebunden. Beispiel:

      Alias /info /var/webdata/info

      Die Eingabe von »http://servername/info/...« liefert daraufhin die entsprechenden Inhalte aus dem Verzeichnis /var/webdata/info.

    • Allow from all | IP-Adresse | Hostname

      Kontext: DH; Modul: mod_authtz_host

      Die traditionelle Art, Hosts anzugeben, denen der Zugriff auf eine bestimmte Ressource erlaubt wird. Als Wert hinter Allow from können Hostnamen, ganze IP-Adressen oder Teile von ihnen eingetragen werden; alternativ auch das Schlüsselwort all für jeden Host.

      Das folgende Beispiel erlaubt allen Hosts den Zugriff auf URLs unter http://servername/public:

      <Location /public>
      Order allow,deny
      Allow from all
      </Location>

      In Apache 2.4 wird diese Syntax zwar noch unterstützt, gilt aber als veraltet. Hier wird sie von dem Modul mod_access_compat bereitgestellt, während mod_authz_host keine eigenen Direktiven mehr definiert, sondern Require ip für IP-Adressen beziehungsweise Require host für Hostnamen verwendet.

      Die zuvor dargestellte Konfiguration wird für Apache 2.4 wie folgt angegeben:

      <Location /public>
      Require all granted
      </Location>
    • AllowOverride None|All|Direktiventyp [Direktiventyp ...]

      Kontext: D; Modul: core

      Legt fest, welche Direktiven im aktuellen Kontext und in seinen Unterverzeichnissen durch .htaccess-Dateien überschrieben werden dürfen. Diese Direktive ist nur in <Directory>-Abschnitten erlaubt, nicht in <Location> oder <Files>. Eine Voreinstellung für alle Verzeichnisse kann in einem Container für das Wurzelverzeichnis, also

      <Directory />
      ...
      </Directory>

      vorgenommen werden.

      Die möglichen Werte sind:

      • None: Apache wertet im angegebenen Kontext keine .htaccess-Dateien aus; empfiehlt sich als Vorgabewert für /.
      • FileInfo: Direktiven für Dateitypen und -inhalte
      • Indexes: Direktiven für automatisch generierte Verzeichnisindizes
      • Limit: Direktiven zur Zugriffskontrolle, insbesondere Order, Allow und Deny
      • AuthConfig: Direktiven zur Authentifizierung
      • Options: Direktiven für Verzeichnisoptionen, zum Beispiel Options
      • All: alle bisher genannten sowie einige zusätzliche Direktiven
    • AuthBasicProvider provider

      Kontext: DH; Modul: mod_auth_basic

      Gibt das Provider-Modul (mod_authn_*) an, das die Vergleichsdaten für die klartextbasierte Authentifizierung liefern soll. Hier ein Beispiel, das einfache Textdateien (Modul mod_authn_file) auswählt:

      AuthBasicProvider file
    • AuthDigestProvider provider

      Kontext: DH; Modul: mod_auth_digest

      Wie AuthBasicProvider, allerdings für die verschlüsselte Digest-Authentifizierung

    • AuthName Bereichsname

      Kontext: DH; Modul: core

      Bestimmt den Namen eines Authentifizierungsbereichs, den sogenannten Realm. Nach einmaliger erfolgreicher Anmeldung senden Browser die Anmeldedaten für denselben Realm innerhalb einer Sitzung automatisch. Außerdem zeigen Browser den Realm im Anmeldefenster an. Beispiel:

      AuthName "Privater Bereich"
    • AuthType Basic | Digest

      Kontext: DH; Modul: core

      Legt fest, auf welche Weise ein Browser die Anmeldedaten an den Server senden soll: Basic steht für Klartext, Digest dagegen für MD5-Verschlüsselung. Letzteres ist natürlich sicherer, funktioniert aber nicht mit allen Provider-Modulen und bereitet sehr alten Browsern Schwierigkeiten.

    • AuthUserFile Dateipfad

      Kontext: DH; Modul: mod_authn_file

      Gibt eine Textdatei an, in der sich Benutzerdaten zur Überprüfung bei der Anmeldung befinden. Für die Erzeugung solcher Dateien ist das im bin-Verzeichnis von Apache befindliche Kommandozeilentool htpasswd zuständig. Beispiel:

      # htpasswd [-c] .htuser username

      Nach dieser Eingabe wird zweimal nach dem neuen Passwort für den angegebenen Usernamen gefragt; daraufhin wird es verschlüsselt in der Datei .htuser im aktuellen Verzeichnis gespeichert. Die Option -c (»create«) muss zum Anlegen einer neuen Datei verwendet werden.

      In der Direktive wird der Dateipfad relativ zur ServerRoot (siehe im Folgenden) interpretiert, es sei denn, Sie geben einen absoluten Pfad an. Hier ein Beispiel, das die Datei .htuser aus dem Verzeichnis credentials im Apache-Installationsverzeichnis auswählt:

      AuthUserFile credentials/.htuser

      Aus Sicherheitsgründen sollte die angegebene Datei sich auf keinen Fall innerhalb des Website-Verzeichnisses selbst befinden. Falls Sie gemieteten Webspace verwenden und daher keine andere Möglichkeit haben, müssen Sie den Zugriff auf die entsprechende Datei ganz verbieten. Dies funktioniert in Apache 2.4 für den Dateinamen .htuser zum Beispiel so:

      <Files .htuser>
      Require all denied
      </Files>

      In den Versionen bis 2.2 wird dagegen folgende Variante verwendet:

      <Files .htuser>
      Order deny,allow
      Deny from all
      </Files>
    • Deny from all|IP-Adresse|Hostname

      Kontext: DH; Modul: mod_authtz_host

      Traditionelle Art und Weise, den angegebenen Rechnern den Zugriff auf Ressourcen in dem Kontext zu verweigern, in dem die Direktive steht. Das folgende Beispiel untersagt zunächst allen Hosts den Zugriff auf den URL-Pfad /geheim und erlaubt anschließend den Zugriff vom lokalen Rechner aus:

      <Location /geheim>
      Order deny,allow
      Deny from all
      Allow from 127.0.0.1
      </Location>

      Für die Änderungen in Apache 2.4 beachten Sie bitte die Anmerkungen zur Direktive Allow. Das 2.4-Äquivalent zur eben dargestellten Konfiguration lautet:

      <Location /geheim>
      Require ip 127.0.0.1
      </Location>
    • <Directory Verzeichnis> ... </Directory>

      Kontext: SV; Modul: core

      Umschließt Einstellungen für ein bestimmtes Verzeichnis der Website. Das folgende Beispiel verbietet .htaccess-Dateien auf dem gesamten Server (kann für einzelne Verzeichnisse aber wieder überschrieben werden):

      <Directory />
      AllowOverride None
      </Directory>
    • DirectoryIndex Dateiname [Dateiname ...]

      Kontext: SVDH; Modul: mod_dir

      Gibt Namen für Startseiten an, das heißt für Dateien, nach denen Apache in der angegebenen Reihenfolge suchen soll, wenn nur ein Verzeichnis ohne konkreten Dateinamen angefordert wurde. Der Vorgabewert ist index.html; das folgende Beispiel erlaubt zusätzlich index.htm und index.php:

      DirectoryIndex index.html index.htm index.php
    • DocumentRoot Verzeichnis

      Kontext: SV; Modul: core

      Das Wurzelverzeichnis der Website, dem der URL-Pfad / zugeordnet ist. Die Voreinstellung ist /htdocs im Apache-Verzeichnis.
      Unix-Standard:

      DocumentRoot /usr/local/apache2/htdocs

      Windows-Standard:

      DocumentRoot "C:/Programme/Apache Software Foundation/Apache2.2/htdocs"
    • <IfModule Modul> ... </IfModule>

      Kontext: SVDH; Modul: core

      Direktiven in diesem Container werden nur dann ausgeführt, wenn das betreffende Modul verfügbar ist. Der Modulname wird so angegeben wie das erste Argument von LoadModule (siehe im Folgenden); für mod_mime wird beispielsweise mime_module geschrieben. Das folgende Beispiel, das so in der Original-Konfigurationsdatei steht, stellt nur dann die Startseite index.html ein, wenn mod_dir aktiv ist:

      <IfModule dir_module>
      DirectoryIndex index.html
      </IfModule>
    • Listen [IP-Adresse:]Port

      Kontext: S; Modul: MPM-Module

      Bestimmt den TCP-Port, an dem Apache auf eingehende Clientverbindungen lauscht. Wenn eine IP-Adresse angegeben wird, gilt die Einstellung nur für die betreffende Netzwerkschnittstelle, ansonsten für alle. Standard:

      Listen 80

      Falls Apache an mehreren Ports lauschen soll, müssen mehrere Listen-Direktiven angegeben werden, zum Beispiel 443 für SSL-verschlüsselte Verbindungen.

    • LoadModule Modulname Dateipfad

      Kontext: S; Modul: mod_so

      Module, die als Dynamic Shared Objects (DSOs) kompiliert wurden (unter Windows ist dies grundsätzlich der Fall), werden mithilfe dieser Direktive geladen und aktiviert. Der erste Parameter, der Modulname, entspricht dem Grundnamen mit angehängtem _module (zum Beispiel rewrite_module für mod_rewrite); der Dateipfad verweist meist auf eine .so-Datei im Verzeichnis modules relativ zur ServerRoot (siehe im weiteren Verlauf). Das folgende Beispiel lädt mod_autoindex:

      LoadModule autoindex_module modules/mod_autoindex.so
    • <Location URL-Pfad> ... </Location>

      Kontext: SV; Modul: core

      Umschließt die Konfiguration für einen bestimmten URL-Pfad. Hier ein Beispiel, das für alle Dateien in Verzeichnissen unter der URL http://servername/info die Startseite start.html einstellt:

      <Location /info>
      DirectoryIndex start.html
      </Location>
    • NameVirtualHost IP-Adresse[:Port]

      Kontext: S; Modul: core

      Konfiguriert eine IP-Adresse und/oder einen TCP-Port für den Einsatz namensbasierter virtueller Hosts, das heißt, dass bei Zugriffen auf diese Adresse oder diesen Port je nach Host-Header der Anfrage unterschiedliche Sites geliefert werden. Wenn alle Netzwerkschnittstellen angesprochen werden sollen, können Sie statt einer konkreten Adresse * benutzen. Um virtuelle Hosts einzurichten, müssen Sie anschließend mehrere <VirtualHost>-Container definieren, in denen die Direktive ServerName die unterschiedlichen möglichen Hostnamen angibt.

      Wichtig: Für die betreffende Adresse beziehungsweise den Port gibt es danach keinen »Hauptserver« mehr. Auch die bisherige Hauptserver-Konfiguration muss in einen <VirtualHost>-Container verschoben werden.

      In Apache 2.4 wurde diese Direktive ersatzlos gestrichen; der Server erkennt die Konfiguration anhand der <VirtualHost>-Container selbst.

      Hier zwei Beispiele:

      NameVirtualHost 196.23.17.42
      NameVirtualHost *:8080
    • Options None|All|[+|-]Optionstyp [[+|-]Optionstyp ...]

      Kontext: SVDH; Modul: core

      Diese Direktive stellt Optionen für ein Verzeichnis ein. None deaktiviert alle Optionen, während All alle außer MultiViews einschaltet. Die verfügbaren Optionen sind:

      • Indexes: Wenn ein Verzeichnis angefordert wurde, wird die Startseite (DirectoryIndex) beziehungsweise der automatisch generierte Index geliefert.
      • FollowSymLinks: Falls die angeforderte URL ein symbolischer Link ist, wird deren Ziel geliefert.
      • SymLinksIfOwnerMatch: Verfolgt ebenfalls symbolische Links, aber nur, wenn der Eigentümer des Symlinks demjenigen der Zieldatei entspricht.
      • ExecCGI: CGI-Skripte werden ausgeführt.
      • Includes: Server Side Includes (SSI) werden ausgeführt.
      • IncludesNOEXEC: Aktiviert ebenfalls SSI, allerdings mit Ausnahme von #exec (Programmausführung) und #exec cgi (CGI-Ausführung).
      • MultiViews: Content-Negotiation wird automatisch anhand bestimmter Dateiendungen durchgeführt.

      In untergeordneten Kontexten stehen die speziellen Schreibweisen +Option und -Option zur Verfügung, um Optionen zu den Einstellungen des übergeordneten Kontextes hinzuzufügen beziehungsweise daraus zu entfernen.

    • Order allow,deny | deny,allow

      Kontext: DH; Modul: mod_authtz_host

      Legt die Reihenfolge fest, in der Allow- und Deny-Direktiven ausgewertet werden. Der vordere Wert gilt dabei als Voreinstellung (meist mit dem Wert All), der hintere als Ausnahme von dieser Regel.

      Wichtig: In allow,deny beziehungsweise deny,allow darf kein Leerzeichen hinter dem Komma stehen.

      Hier ein Komplettbeispiel, das nur Rechnern aus dem Netzwerk 192.168.1.0/24 den Zugriff auf den URL-Pfad /intranet gestattet:

      <Location /intranet>
      Order deny,allow
      Deny from all
      Allow from 192.168.1
      </Location>

      In Apache 2.4 gilt Order zusammen mit Allow und Deny als veraltet; in der Beschreibung der Direktive Allow steht mehr dazu. Die entsprechende Konfiguration lautet hier folgendermaßen:

      <Location /intranet>
      Require ip 192.168.1
      </Location>
    • Redirect [Status] URL-Pfad URL

      Kontext: SVDH; Modul: mod_alias

      Anfragen für den angegebenen URL-Pfad werden an die (externe) URL weitergeleitet. Das folgende Beispiel leitet alle Anfragen für http://servername/extern an entsprechende Ressourcen unter http://externerserver weiter:

      Redirect /extern http://externerserver
    • Require user Username | group Groupname | valid-user

      Kontext: DH; Modul: core

      Gibt im Rahmen von Authentifizierungsdirektiven an, welche Benutzer (user) oder Gruppen (group) sich anmelden dürfen. valid-user steht für alle Benutzer aus der aktuellen Datenquelle, zum Beispiel dem AuthUserFile (siehe zuvor).

      In Apache 2.4 wird Require auch verwendet, um Clients anhand ihrer IP-Adressen (Require ip) beziehungsweise Hostnamen (Require host) den Zugriff zu erlauben beziehungsweise zu verweigern. Außerdem stehen verschachtelbare Require-Container zur Verfügung, um zu bestimmen, wie mehrere Require-Direktiven zusammenwirken sollen:

      • <RequireAll>...</RequireAll> ist eine logische Und-Verknüpfung, legt also fest, dass alle enthaltenen Require-Direktiven erfüllt sein müssen.
      • <RequireAny>...</RequireAny> ist dagegen logisches Oder, das heißt, mindestens eine der enthaltenen Require-Direktiven muss erfüllt sein.
      • <RequireNone>...</RequireNone> gilt nur als bestanden, wenn keine der enthaltenen Require-Direktiven zutrifft.
    • Satisfy Any | All

      Kontext: DH; Modul: core

      Falls Authentifizierung und Zugriffskontrolle über Order/Allow/Deny für dasselbe Verzeichnis eingesetzt werden, gibt diese Direktive an, ob beide Kriterien erfüllt sein müssen (All) oder ob eines von ihnen genügt (Any). Der Vorgabewert ist All.

      In Apache 2.4 entfällt Satisfy, weil die Require-Container eine viel genauere Festlegung erlauben.

    • ScriptAlias URL-Pfad Verzeichnispfad

      Kontext: SV; Modul: mod_alias

      Entspricht der Funktionsweise von Alias (siehe zuvor), betrachtet aber zusätzlich die Dateien im angegebenen Verzeichnis als CGI-Skripte. In der Standardkonfiguration gibt es ein Verzeichnis cgi-bin unter der ServerRoot (nicht etwa der DocumentRoot!), das als solches CGI-Verzeichnis dient. Der betreffende Eintrag sieht unter Unix so aus:

      ScriptAlias /cgi-bin /usr/local/apache2/cgi-bin

      Die Windows-Variante lautet:

      ScriptAlias /cgi-bin \
      "C:/Programme/Apache Software Foundation/Apache2.2/cgi-bin"
    • ServerAdmin E-Mail-Adresse

      Kontext: SV; Modul: core

      Die E-Mail-Adresse des Serveradministrators, an die Benutzer Fehlermeldungen schicken können. Beispiel:

      ServerAdmin webmaster@test.local
    • ServerName Domainname

      Kontext: SV; Modul: core

      Gibt den Domainnamen des Servers oder des virtuellen Hosts an. Beachten Sie, dass der Server in der Öffentlichkeit nur dann tatsächlich unter diesem Namen verfügbar ist, wenn entsprechende Nameserver-Einträge existieren. Die nötigen Einzelheiten zur Nameserver-Konfiguration werden im nächsten Kapitel erläutert. Beispiel:

      ServerName www.test.local
    • ServerRoot Verzeichnispfad

      Kontext: S; Modul: core

      Dies ist das Stammverzeichnis, in dem Apache installiert wurde. Verzeichnisangaben in vielen Direktiven werden relativ zu diesem Wert interpretiert. Unter Unix wird standardmäßig der folgende Wert verwendet:

      ServerRoot /usr/local/apache2

      Hier zum Vergleich die übliche Windows-Voreinstellung:

      ServerRoot \
      "C:/Programme/Apache Software Foundation/Apache2.2"

    • ServerSignature On|Off|E

      Kontext: SVDH; Modul: core

      Bestimmt die Fußzeile mit Informationen über den Server, den Hostnamen und eventuell die E-Mail-Adresse des Administrators. Die drei möglichen Werte sind: Off – keine Fußzeile; On – Fußzeile ohne E-Mail-Adresse (Beispiel: Apache/2.4.4 (Unix) Server at www.test.local Port 80); EMail – wie On, aber als Link auf die ServerAdmin-E-Mail-Adresse.

    • ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full

      Kontext: S; Modul: core

      Bestimmt, wie ausführlich die Serversoftware im Server-Header und auf automatisch generierten Seiten genannt wird. Angenommen, es handelt sich um Apache 2.4.4 auf einem Unix-System, dann lautet ProductOnly: Apache, Major: Apache/2, Minor: Apache/2.4, Minimal: Apache/2.4.4 und OS: Apache/2.4.4 (Unix). Full hängt noch die Selbstbeschreibungen diverser Module an, zum Beispiel Apache/2.4.4 (Unix) Dav/2 PHP/5.5.0.

    • <VirtualHost Host[:Port]> ... </VirtualHost>

      Kontext: S; Modul: core

      Umschließt die Konfiguration eines virtuellen Hosts, der durch eine IP-Adresse, einen Hostnamen und/oder einen TCP-Port angegeben wird. Die zugehörigen Listen- und eventuellen NameVirtualHost-Direktiven müssen allerdings im Serverkontext stehen. Näheres über das komplexe Thema Virtual Hosts erfahren Sie in der Beschreibung dieser Direktive auf der Website zu meinem Buch »Apache 2«: http://buecher.lingoworld.de/apache2/showdir.php?id=757.

    Konfigurationsbeispiele

    Nachdem soeben diverse Apache-Direktiven vorgestellt wurden, sollten Sie sich einige von ihnen im größeren Konfigurationszusammenhang anschauen.

    Als Erstes sollten restriktive Voreinstellungen für das Wurzelverzeichnis – und damit für jedes beliebige Verzeichnis – vorgenommen werden:

      Für Apache 2.2 sieht der entsprechende Container so aus:

      <Directory />
      # Alle Optionen ausschalten
      Options None
      # .htaccess ausschalten (f. Sicherheit & Performance)
      AllowOverride None
      # ALLE Zugriffe verbieten
      Order deny,allow
      Deny from all
      </Directory>

      Die DocumentRoot benötigt dagegen großzügigere Einstellungen, beispielsweise diese:

      <Directory /usr/local/apache2/htdocs>
      # Einige Optionen aktivieren
      Options Indexes FollowSymLinks
      # Alle Zugriffe gestatten
      Require all granted
      </Directory>

      Hier die Variante für Apache bis einschließlich Version 2.2:

      <Directory /usr/local/apache2/htdocs>
      # Einige Optionen aktivieren
      Options Indexes FollowSymLinks
      # Alle Zugriffe gestatten
      Order allow,deny
      Allow from all
      </Directory>

      Wenn Sie Aliasse verwenden, müssen Sie für die betreffenden Verzeichnisse übrigens auch derartige Angaben machen.

      Hier ein etwas umfangreicheres Beispiel, das zwei namensbasierte virtuelle Hosts für den Port 8080 bereitstellt:

      # An Port 8080 lauschen
      Listen 8080

      # Namensbasierte virtuelle Hosts für Port 8080 aktivieren
      NameVirtualHost *:8080
      # (in Apache 2.4 entfällt NameVirtualHost ersatzlos)

      # Erster VHost, server1.test.local:8080
      <VirtualHost *:8080>
      # ServerName, mit dem der Host-Header
      # einer Anfrage verglichen wird
      ServerName server1.test.local
      # Spezifische Webmaster-E-Mail-Adresse
      ServerAdmin webmaster@server1.test.local
      # Wurzelverzeichnis der Website
      DocumentRoot /var/www/vhosts/server1
      # Zugriffe auf dieses Verzeichnis erlauben
      <Directory /var/www/vhosts/server1>
      Options All
      Require all granted
      # Variante für Apache 2.2 (# entfernen):
      # Order allow,deny
      # Allow from all
      </Directory>
      # Fehler-Logdatei
      ErrorLog logs/server1.test.local-error_log
      # Zugriffs-Logdatei

      CustomLog logs/server1.test.local-access_log common
      </VirtualHost>

      # Zweiter VHost, server2.test.local:8080
      <VirtualHost *:8080>
      ServerName server2.test.local
      ServerAdmin webmaster@server1.test.local
      DocumentRoot /var/www/vhosts/server1
      <Directory /var/www/vhosts/server1>
      Options All
      Require all granted
      # Variante für Apache 2.2 (# entfernen):
      # Order allow,deny
      # Allow from all
      </Directory>
      ErrorLog logs/server1.test.local-error_log
      CustomLog logs/server1.test.local-access_log common
      </VirtualHost>

      Je nachdem, ob ein Besucher eine Adresse unter http://server1.test.local:8080 oder unter http://server2.test.local:8080 eingibt, wird die gewünschte Ressource aus der jeweiligen DocumentRoot geliefert.

      Um eine solche Konfiguration auf Ihrem lokalen Rechner zu testen, müssen Sie die entsprechenden Hostnamen in Ihrer /etc/hosts-Datei der lokalen IP-Adresse 127.0.0.1 zuweisen. Die entsprechende Zeile sieht dann beispielsweise wie folgt aus:

      127.0.0.1 localhost server1.test.local server2.test.local

      Als Nächstes sehen Sie hier ein vollständiges Beispiel für ein geschütztes Verzeichnis, dessen Inhalte Benutzer nur nach Anmeldung mit Benutzername und Passwort aufrufen dürfen. Die gewünschten Benutzerdaten müssen sich dabei in der htpasswd-Datei .htuser im Apache-conf-Verzeichnis befinden:

      <Location /privat>
      # Klartextbasierte Übertragung der Anmeldedaten
      AuthType Basic
      # Anmeldedaten in einfacher htpasswd-Textdatei
      AuthBasicProvide file
      # Realm
      AuthName "Privater Bereich"
      # Pfad der htpasswd-Datei
      AuthUserFile conf/.htuser
      # Alle User aus der Datei haben Zutritt
      Require valid-user
      </Location>

      Dies akzeptiert alle Benutzer-Passwort-Kombinationen aus der Datei .htuser. Wenn ein User einen URL-Pfad aus diesem Verzeichnis anfordert, erhält sein Browser den Status 401 Unauthorized als Antwort und zeigt einen Anmeldedialog an. Wenn die Anmeldung innerhalb einer Sitzung einmal korrekt erfolgt ist, sendet der Browser bei weiteren Zugriffen auf denselben Bereich die Anmeldedaten automatisch.

      Hier zu guter Letzt noch eine Standardkonfiguration für einen virtuellen Host unter dem SSL-Standardport 443. Anfragen, die an https://servername gesendet werden, erzeugen dadurch gesicherte Verbindungen und werden mit Dateien aus der DocumentRoot /var/www/secure beantwortet:

      # An Port 443 (SSL-Standard) lauschen
      Listen 443

      # Die wichtigsten allgemeinen SSL-Voreinstellungen
      # Standardverhalten bei der SSL-Serialisierung
      # (geordnete Verarbeitungsreihenfolge)
      SSLMutex default
      # Den eingebauten Startwertalgorithmus für
      # den Zufallsgenerator verwenden
      SSLRandomSeed startup builtin
      # Kein Cache für SSL-Sitzungsdaten
      SSLSessionCache none

      # Virtueller Host für Port 443
      <VirtualHost *:443>
      # SSL-Funkitonalität einschalten
      SSLEngine On
      # Pfad zum Server-Zertifikat
      SSLCertificateFile conf/ssl/test.cert
      # Pfad zum Public Key des Server-Zertifikats
      SSLCertificateKeyFile conf/ssl/test.key
      # Pfad der gesicherten Website
      DocumentRoot /var/www/secure
      </VirtualHost>

      Das Zertifikat können Sie mithilfe von openssl erzeugen, müssen es für den Praxiseinsatz aber von einer anerkannten Zertifizierungsstelle durch eine digitale Signatur beglaubigen lassen, damit Browser es ohne Fehlermeldung akzeptieren. Eine solche Signatur kostet Geld; in der Regel ist es aber günstiger, sich dafür an Ihren Hoster zu wenden als direkt an eine Zertifizierungsstelle. Näheres zur Zertifikatserstellung und SSL-Konfiguration erfahren Sie auf der Webseite http://buecher.lingoworld.de/apache2/mod_ssl.html.

      Andere Webserver im Überblick

      Neben dem ausführlich vorgestellten Marktführer Apache gibt es zahlreiche weitere Webserver. Drei bekannte Modelle sind:

      • Microsoft Internet Information Services (IIS)
        Der Microsoft-Webserver gehört zum Lieferumfang aller Windows-Server seit Windows NT 4.0 Server. In Windows Server 2003 war Version 6 enthalten, Windows Server 2008 enthält die Version 7 und Windows Server 2012 die neue Version 8. Für Windows XP Professional und neuer existiert IIS als optionaler Download.

      Der Leistungsumfang von IIS reicht an denjenigen von Apache heran; hinzu kommen eingebaute FTP-Server- und Mailserver-Funktionen. Die Konfiguration erfolgt nicht über eine textbasierte Konfigurationsdatei, sondern ausschließlich über die grafische Benutzeroberfläche.

      IIS ist außerdem ein Web Application Server für ASP.NET, Microsofts eigene Technologie für Webanwendungen. Gemäß der .NET-Spezifikation können diese Anwendungen in allen Sprachen der Common Language Runtime geschrieben werden, zum Beispiel in VB.NET, C# oder C++.

      • Lighttpd
        Dieser Webserver ist ein Open-Source-Produkt. Wie der Name vermuten lässt, handelt es sich um eine leichtgewichtige Alternative zu einem umfangreichen HTTP-Server wie Apache. Der »Lighty« wurde vor allem im Hinblick auf geringen Ressourcenverbrauch geschrieben. Dafür bietet er natürlich weniger Features als Apache, ist aber ebenfalls durch Module erweiterbar. Ein recht ähnliches Produkt, das auch gern als Webcache-Vorschaltproxy verwendet wird, ist nginx.
      • Apache Tomcat
        Tomcat stammt ebenfalls von der Apache Software Foundation. Es handelt sich in erster Linie um einen Application Server für Java Servlets und Java Server Pages (JSP), der aber auch statische HTML-Seiten ausliefern kann. Dies erledigt er natürlich nicht ganz so performant und flexibel wie der Apache HTTP Server, aber für eine größtenteils Java-basierte Webapplikation mit nur wenigen statischen Seiten genügt er auch in dieser Rolle. Wenn nötig lässt er sich aber auch als Backend-Server mit einem Apache verknüpfen.


      Ihre Meinung

      Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

      << zurück




      Copyright © Rheinwerk Verlag GmbH 2013
      Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
      Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


      Nutzungsbestimmungen | Datenschutz | Impressum

      Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

      Cookie-Einstellungen ändern


        Zum Rheinwerk-Shop
      Neuauflage: IT-Handbuch für Fachinformatiker






      Neuauflage: IT-Handbuch für Fachinformatiker
      Jetzt Buch bestellen


       Ihre Meinung?
      Wie hat Ihnen das Openbook gefallen?
      Ihre Meinung

       Buchempfehlungen
      Zum Rheinwerk-Shop: Java ist auch eine Insel






       Java ist auch
       eine Insel


      Zum Rheinwerk-Shop: Linux Handbuch






       Linux Handbuch


      Zum Rheinwerk-Shop: Computer Netzwerke






       Computer Netzwerke


      Zum Rheinwerk-Shop: Schrödinger lernt HTML5, CSS3 und JavaScript






       Schrödinger lernt
       HTML5, CSS3
       und JavaScript


      Zum Rheinwerk-Shop: Windows 8.1 Pro






       Windows 8.1 Pro


       Lieferung
      Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
      InfoInfo