10.2. Migrieren von Apache HTTP-Server 1.3 Konfigurationsdateien

Wurde Ihr Server von Red Hat Linux 7.3 oder früher aktualisiert, auf der Apache HTTP-Server bereits installiert war, dann wird die neue Stock-Konfigurationsdatei für das Apache HTTP-Server 2.0-Paket als /etc/httpd/conf/httpd.conf.rpmnew installiert und Ihre Originalversion 1.3 httpd.conf beibehalten. Es liegt natürlich ganz bei Ihnen, ob Sie die neue Konfigurationsdatei verwenden möchten und Ihre alten Einstellungen dorthin migrieren oder die vorhandene Datei als Basis verwenden und sie entsprechend anpassen; einige Bereiche der Datei haben sich jedoch mehr als andere verändert, deshalb ist ein gemischtes Vorgehen normalerweise die beste Lösung. Die Stock-Konfigurationsdateien sowohl für Version 1.3 als auch für Version 2.0 werden in drei Abschnitte unterteilt. Ziel dieses Leitfadens ist es, den hoffentlich einfachsten Weg aufzuzeigen.

Handelt es sich bei /etc/httpd/conf/httpd.conf um eine modifizierte Version der Standard Red Hat Linux Version und Sie haben eine Kopie des Originals gespeichert, dann ist es vielleicht am einfachsten, wenn Sie den Befehl diff aufrufen, wie in folgendem Beispiel gezeigt:

diff -u httpd.conf.orig httpd.conf | less

Dieser Befehl hebt die von Ihnen durchgeführten Änderungen hervor. Besitzen Sie keine Kopie der Originaldatei, entnehmen Sie sie anhand der Befehle rpm2cpio und cpio einem RPM-Paket, wie in folgendem Beispiel gezeigt:

	  rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make

<version-number> ist hierbei mit der Versionsnummer des apache Pakets zu ersetzen.

Es ist hilfreich zu wissen, dass Apache HTTP-Server über einen Testmodus zur Prüfung Ihrer Konfigurations auf Fehler verfügt. Der Zugriff erfolgt über folgenden Befehl:

apachectl configtest

10.2.1. Konfiguration der globalen Umgebung

Der Abschnitt zur globalen Umgebung der Konfigurationsdatei enthält Anweisungen, die sich insgesamt auf die Funktionsweise von Apache HTTP-Server auswirken, wie die Anzahl konkurrierender Anfragen, die abgefertigt werden und die Speicherplätze der verschiedenen verwendeten Dateien. Bei diesem Abschnitt ist im Vergleich zu den anderen eine große Anzahl an Änderungen notwendig. Es empfiehlt sich deshalb, dass dieser Abschnitt seine Basis in der Apache HTTP-Server 2.0 Konfigurationsdatei hat und Sie Ihre alten Einstellungen dorthin migrieren.

10.2.1.1. Auswahl der zu verknüpfenden Schnittstellen und Ports

Die Anweisungen BindAddress und Port existieren nicht mehr; ihre Funktionen wurde durch eine flexiblere Listen Anweisung ersetzt.

Wenn Sie in Ihrer 1.3. Version die Konfigurationsdatei auf Port 80 gesetzt haben, sollten Sie diese auf Listen 80 umändern. Hatten Sie Port auf einen Wert gesetzt der ungleich 80 ist, dann müssen Sie auch die Port-Nummer an den Inhalt Ihrer ServerName Anweisung anhängen.

Folgendes ist ein Beispiel einer Apache HTTP-Server 1.3 Anweisung:

Port 123
ServerName www.example.com

Verwenden Sie folgende Struktur, um diese Einstellung nach Apache HTTP-Server 2.0 zu migrieren:

Listen 123
ServerName www.example.com:123 

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.1.2. Server-Pool Größeneinstellung

Die Verantwortung der Handhabung von Annahmen und Versenden von Kind-Prozessen wurde in Apache HTTP-Server 2.0 in einer Modulgruppe mit dem Namen Multi-Processing Modules (MPMs) zusammengefasst. Im Gegensatz zu anderen Modulen kann nur ein Modul der MPM-Gruppe von Apache HTTP-Server geladen werden, da ein MPM-Modul für grundlegende Anfragebearbeitung und Anfrageverteilung zuständig ist. Drei MPM-Module werden mit der Version 2.0 ausgeliefert: prefork, worker und perchild.

Das Originalverhalten von Apache HTTP-Server 1.3 wurde auf das prefork MPM übertragen. Derzeit ist nur das prefork MPM auf Red Hat Linux verfügbar, obwohl weitere MPSs für die Zukunft vorgesehen sind.

Das prefork MPM akzeptiert die gleichen Anweisungen wie Apache HTTP-Server 1.3. Folgende Anweisungen können direkt migriert werden:

  • StartServers

  • MinSpareServers

  • MaxSpareServers

  • MaxClients

  • MaxRequestsPerChild

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.1.3. Support für Dynamic Shared Objects (DSO)

Viele Änderungen sind hier notwendig und es empfiehlt sich für jeden, der versucht, eine Apache HTTP-Server 1.3-Konfiguration an eine Apache HTTP-Server 2.0-Konfiguration anzupassen (im Gegensatz zur Migration Ihrer Änderungen in die 2.0-Konfiguration), diesen Abschnitt aus der Stock-Red Hat Linux-Apache HTTP-Server 2.0-Konfigurationsdatei zu kopieren.

Diejenigen, die diesen Abschnitt nicht kopieren wollen, sollten Folgendes beachten:

  • Die AddModule und ClearModuleList-Anweisungen gibt es nicht länger. Diese Anweisungen wurden verwendet, um sicherzustellen, dass Module in der richtigen Reihenfolge aktiviert wurden. Die Apache HTTP-Server 2.0 API erlaubt Modulen die Reihenfolge zu bestimmen, was diese beiden Anweisungen überflüssig macht.

  • Die Reihenfolge der LoadModule Zeilen ist nicht mehr von Bedeutung.

  • Viele Module wurden hinzugefügt, entfernt, umbenannt, aufgeteilt oder zusammengefasst.

  • LoadModule Zeilen für Module, die in ihren eigenen RPMs (mod_ssl, php, mod_perl und ähnliche) verpackt sind, sind nicht mehr notwendig, da sie sich in der entsprechenden Datei im /etc/httpd/conf.d/ Verzeichnis befinden.

  • Die verschiedenen HAVE_XXX Definitionen werden nicht mehr festgelegt.

WichtigWichtig
 

Sollten Sie versuchen, Ihre Originaldatei zu ändern, beachten Sie bitte, dass es äußerst wichtig ist, dass Ihre httpd.conf folgende Anweisung enthält:

Include conf.d/*.conf

Das Weglassen dieser Anweisung hat zur Folge, dass alle Module scheitern, die in ihren eigenen RPMs (wie mod_perl, php und mod_ssl) verpackt sind.

10.2.1.4. Sonstige Änderungen der globalen Umgebung

Folgende Anweisungen wurden aus der Apache HTTP-Server 2.0 Konfiguration entfernt:

  • ServerType — Der Apache HTTP-Server kann nur als ServerType standalone gestartet werden, womit diese Anweisung keine Bedeutung mehr hat.

  • AccessConfig und ResourceConfig — Diese Anweisungen wurden herausgenommen, da sie die gleiche Funktion wie die Include Anweisung haben. Haben Sie AccessConfig und ResourceConfig Anweisungen gesetzt, dann müssen sie diese durch Include Anweisungen ersetzen.

    Um sicherzustellen, dass die Dateien in der Reihenfolge gelesen werden, die von den älteren Anweisungen vorgesehen war, sollten Sie Include Anweisungen an das Ende von httpd.conf setzen. Dabei sollte die Anweisung, die ResourceConfig entspricht, vor der Anweisung liegen, die AccessConfig entspricht. Haben Sie mit Standardwerten gearbeitet, müssen Sie diese ausdrücklich als conf/srm.conf und conf/access.conf mit aufnehmen.

10.2.2. Hauptserver-Konfiguration

Der Abschnitt zur Hauptserver-Konfiguration der Konfigurationsdatei richtet den Hauptserver ein, der auf alle Anfragen antwortet, die nicht über eine <VirtualHost> Definition gehandhabt werden. Die Werte hier liefern auch Standardwerte für alle definierten <VirtualHost> Container.

In den Anweisungen dieses Abschnitts gibt es kaum Unterschiede zwischen Apache HTTP-Server 1.3 und Version 2.0. Wenn Ihre Hauptserver-Konfiguration sehr stark benutzerdefiniert ist, ist es vielleicht einfacher für Sie, wenn Sie Ihre bereits existierende Konfiguration an Apache HTTP-Server 2.0 anpassen. Benutzer mit weniger benutzerdefinierten Hauptserver-Abschnitten sollten ihre Änderungen in die Stock-Apache HTTP-Server 2.0 Konfiguration migrieren.

10.2.2.1. UserDir-Abbildung

Die Anweisung UserDir wird verwendet, um URLs wie http://example.com/~bob/ in ein Unterverzeichnis innerhalb des Home-Verzeichnisses des Benutzers bob wie /home/bob/public_html abzubilden. Als Nebenwirkung erlaubt es diese Eigenschaft einem potentiellen Unbefugten festzustellen, ob ein bestimmter Benutzername im System vorhanden ist. Aus diesem Grund ist diese Anweisung in der Standardkonfiguration von Apache HTTP-Server 2.0 deaktiviert.

Aktivieren Sie die UserDir Abbildung durch Umändern der sich in httpd.conf befindlichen Anweisung von:

UserDir disable

in folgende:

UserDir public_html

Weitere Informationen zu diesem Thema finden Sie in der Dokumentation auf der Apache Software Foundation Website, unter http://httpd.apache.org/docs-2.0/mod/mod_userdir.html#userdir.

10.2.2.2. Logging

Folgende Log-Anweisungen wurden entfernt:

  • AgentLog

  • RefererLog

  • RefererIgnore

Agent- und Referrer-Logs sind über CustomLog und LogFormat Anweisungen immer noch verfügbar.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.2.3. Index-Erstellung für Verzeichnisse

Die veraltete Anweisung FancyIndexing wurde entfernt. Die gleiche Funktionalität ist über FancyIndexing Option in der Anweisung IndexOptions verfügbar.

Die neue Option VersionSort für die IndexOptions Anweisung führt dazu, dass Dateien mit Versionsnummern auf natürliche Weise sortiert werden, so dass httpd-2.0.6.tar in einer Verzeichnis-Indexseite vor httpd-2.0.36.tar erscheinen würde.

Die Standardwerte für die Anweisungen ReadmeName und HeaderName haben sich geändert, und zwar von README und HEADER in README.html und HEADER.html.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.2.4. Inhaltsverhandlung

Die Anweisung CacheNegotiatedDocs kann jetzt die Argumente on oder off haben. Existierende Fälle von CacheNegotiatedDocs sollten durch CacheNegotiatedDocs on ersetzt werden.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.2.5. Fehlerdokumente

Um eine hart-kodierte Meldung mit der ErrorDocument Anweisung zu verwenden, sollte die Meldung von einem Paar doppelter Anführungszeichen ["] umschlossen sein, anstatt dass nur ein doppeltes Anführungszeichen der Meldung vorangestellt werden, wie in Apache HTTP-Server 1.3. verlangt.

Verwenden Sie folgende Struktur um eine ErrorDocument Einstellung nach Apache HTTP-Server 2.0 zu migrieren:

ErrorDocument 404 "The document was not found"

Beachten Sie, dass in der o.g. Beispiel-Anweisung ErrorDocument doppelte Anführungszeichen angehängt wurden.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.3. Konfiguration des virtuellen Host

Der Inhalt aller <VirtualHost> Sektionen sollte auf die gleiche Weise wie der Hauptserver-Abschnitt migriert werden, wie in Abschnitt 10.2.2 beschrieben.

WichtigWichtig
 

Bitte beachten Sie, dass die SSL/TLS Konfiguration des virtuellen Host aus der Hauptserver-Konfigurationsdatei genommen und in /etc/httpd/conf.d/ssl.conf verschoben wurde.

Weitere Informationen zu diesem Thema finden Sie im Kapitel Konfiguration von Apache HTTP Secure Server im Red Hat Linux Handbuch benutzerdefinierter Konfiguration und in der Online-Dokumentation unter:

10.2.4. Module und Apache HTTP-Server 2.0

In Apache HTTP-Server 2.0 wurde das Modulsystem so geändert, dass Module auf neue und interessante Weise miteinander verknüpft und kombiniert werden können. Common Gateway Interface (CGI) Skripte sind zum Beispiel in der Lage, Server-parsed HTML-Dokumente zu erzeugen, die dann von mod_include verarbeitet werden können. Dies eröffnet eine enorme Anzahl von Möglichkeiten in Bezug darauf, wie Module zum Erreichen eines bestimmten Ziels kombiniert werden können.

Das funktioniert so, dass jede Anfrage direkt von einem handler Modul bedient wird, gefolgt von null oder mehr filter Modulen.

In Apache HTTP-Server 1.3 zum Beispiel würde ein PHP-Skript ganz von einem PHP-Modul gehandhabt werden. In Apache HTTP-Server 2.0 wird die Anfrage zunächst vom Kernmodul — das statische Dateien bedient — gehandhabt, und wird dann vom PHP-Modul gefiltert.

Die genaue Verwendung und alle anderen diesbezüglichen neuen Eigenschaften von Apache HTTP-Server 2.0 würden den Rahmen dieses Dokumentes sprengen; die Änderung hat jedoch Auswirkungen, wenn Sie PATH_INFO verwendet haben. Darin enthalten sind Pfad-Informationen, die dem echten Dateinamen angehängt werden, in einem Dokument, das von einem jetzt als Filter implementierten Modul gehandhabt wird. Das Kernmodul, das die Anfrage anfangs gehandhabt hat, versteht PATH_INFO standardmäßig nicht und wird 404 Not Found Fehler ausgeben bei Anfragen, die derartige Informationen enthalten. Sie können die Anweisung AcceptPathInfo verwenden, um das Kernmodul dazu zu zwingen, Anfragen mit PATH_INFO zu akzeptieren.

Folgend ist ein Beispiel dieser Anweisung:

AcceptPathInfo on

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.4.1. Das Modul mod_ssl

Die Konfiguration für mod_ssl wurde von httpd.conf in die Datei /etc/httpd/conf.d/ssl.conf verschoben. Damit diese Datei geladen wird und dass folglich mod_ssl funktioniert, müssen Sie die Anweisung Include conf.d/*.conf wie in Abschnitt 10.2.1.3 beschrieben in Ihrer Datei httpd.conf haben.

ServerName Anweisungen in virtuellen Hosts von SSL müssen die Port-Nummer ausdrücklich angeben.

Folgendes ist ein Beispiel einer Apache HTTP-Server 1.3 Anweisung:

<VirtualHost _default_:443>
    # General setup for the virtual host
    ServerName ssl.example.name
    ...
</VirtualHost>

Verwenden Sie folgende Struktur, um diese Einstellung nach Apache HTTP-Server 2.0 zu migrieren:

<VirtualHost _default_:443>
    # General setup for the virtual host
    ServerName ssl.host.name:443
    ...
</VirtualHost>

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.4.2. Das Modul mod_proxy

Zugriffskontrollbefehle für den Proxy befinden sich jetzt in einem <Proxy> Block anstatt in einem <Directory proxy:>.

Die Cache-Funktionalität der alten Datei mod_proxy wurde in folgende drei Module aufgeteilt:

  • mod_cache

  • mod_disk_cache

  • mod_file_cache

Diese verwenden normalerweise die gleichen oder ähnliche Anweisungen wie die älteren Versionen des mod_proxy Moduls.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.4.3. Das Modul mod_include

Das Modul mod_include ist jetzt als Filter implementiert und wird deshalb anders aktiviert. Weitere Informationen zu Filtern finden Sie in Abschnitt 10.2.4.

Folgendes ist ein Beispiel einer Apache HTTP-Server 1.3 Anweisung:

AddType text/html .shtml
AddHandler server-parsed .shtml

Verwenden Sie folgende Struktur, um diese Einstellung nach Apache HTTP-Server 2.0 zu migrieren:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Beachten Sie bitte, dass die Anweisung Options +Includes wie bisher für den <Directory> Container oder in einer .htaccess-Datei verlangt wird.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.4.4. Die Module mod_auth_dbm und mod_auth_db

Apache HTTP-Server 1.3 unterstützte zwei Authentifizierungsmodule, mod_auth_db und mod_auth_dbm, die jeweils Berkely-Datenbanken und DBM-Datenbanken verwendeten. Diese Module wurden in Apache HTTP-Server 2.0, in ein einziges Modul mit dem Namen mod_auth_dbm zusammengefasst, das auf mehrere verschiedene Datenbankformate zugreifen kann. Um von mod_auth_db aus Version 1.3 zu migrieren, müssen die Konfigurationsdateien angepasst werden, indem AuthDBUserFile und AuthDBGroupFile durch die entsprechenden aus mod_auth_dbm ersetzt werden: AuthDBMUserFile und AuthDBMGroupFile. Sie müssen außerdem die Anweisung AuthDBMType DB hinzufügen um den Typ der Datenbankdatei anzugeben, der verwendet wird.

Folgendes ist ein Beispiel für eine mod_auth_db Konfiguration in Apache HTTP-Server 1.3:

<Location /private/>
  AuthType Basic
  AuthName "My Private Files"
  AuthDBUserFile /var/www/authdb
  require valid-user
</Location>

Verwenden Sie folgende Struktur um diese Einstellung zu Apache HTTP-Server 2.0 zu migrieren:

<Location /private/>
  AuthType Basic
  AuthName "My Private Files"
  AuthDBMUserFile /var/www/authdb
  AuthDBMType DB
  require valid-user
</Location>

Bitte beachten Sie, dass die Anweisung AuthDBMUserFile auch in .htaccess Dateien verwendet werden kann.

Das dbmmanage Perl-Skript, das zur Bearbeitung von Benutzernamen- und Passwort-Datenbanken verwendet wurde, wurde in Apache HTTP-Server 2.0. durch htdbm ersetzt. Das Programm htdbm bietet gleichwertige Funktionalität und kann wie mod_auth_dbm mit einer Reihe von Datenbank-Formaten umgehen; die Option -T kann in der Befehlszeile zur Bestimmung des Formats verwendet werden.

Tabelle 10-1 zeigt, wie man von einer Datenbank im DBM-Format anhand von dbmmanage in das htdbm Format migrieren kann.

Aktiondbmmanage Befehl (1.3)Entsprechender htdbm Befehl (2.0)
Benutzer zu Datenbank hinzufügen (angegebenes Passwort verwenden)dbmmanage authdb add username passwordhtdbm -b -TDB authdb username password
Benutzer zu Datenbank hinzufügen (fragt nach Passwort)dbmmanage authdb adduser usernamehtdbm -TDB authdb username
Benutzer aus Datenbank entfernendbmmanage authdb delete usernamehtdbm -x -TDB authdb username
Benutzer in Datenbank auflistendbmmanage authdb viewhtdbm -l -TDB authdb
Passwort prüfendbmmanage authdb check usernamehtdbm -v -TDB authdb username

Tabelle 10-1. Migrieren von dbmmanage nach htdbm

Die Optionen -m und -s funktionieren sowohl mit dbmmanage als auch mit htdbm und aktivieren damit jeweils die Verwendung von MD5-oder SHA1-Algorithmen zum Haschieren der Passwörter.

Wird mit htdbm eine neue Datenbank erzeugt, muss dies anhand der Option -c erfolgen.

Weitere Informationen zu diesem Thema finden Sie in folgender Dokumentation der Apache Software Foundation Website:

10.2.4.5. Das Modul mod_perl

Die Konfiguration für mod_perl wurde von httpd.conf in die Datei /etc/httpd/conf.d/perl.conf verschoben. Damit diese Datei geladen wird und dass folglich mod_perl funktioniert, müssen Sie die Anweisung Include conf.d/*.conf wie in Abschnitt 10.2.1.3 beschrieben in Ihrer Datei httpd.conf haben.

Alle Apache:: Einträge in httpd.conf müssen durch ModPerl:: ersetzt werden. Außerdem hat sich die Art und Weise geändert, mit der Handler eingetragen werden.

Dies ist ein Beispiel für eine Apache HTTP-Server 1.3 mod_perl Konfiguration:

<Directory /var/www/perl>
    SetHandler perl-script
    PerlHandler Apache::Registry
    Options +ExecCGI
</Directory>

Dies entspricht mod_perl in Apache HTTP-Server 2.0:

<Directory /var/www/perl>
    SetHandler perl-script
    PerlModule ModPerl::Registry
    PerlHandler ModPerl::Registry::handler
    Options +ExecCGI
</Directory>

Die meisten Module für mod_perl 1.x dürften ohne Änderungen mit mod_perl 2.x funktionieren. XS-Module erfordern eine Neukompilierung und bedürfen eventuell geringerer Makefile-Änderungen.

10.2.4.6. Das Modul mod_python

Die Konfiguration für mod_python wurde von httpd.conf nach /etc/httpd/conf.d/python.conf verschoben. Damit diese Datei geladen wird und folglich dass mod_python funktioniert, müssen Sie die Anweisung Include conf.d/*.conf wie in Abschnitt 10.2.1.3 beschrieben in Ihrer Datei httpd.conf haben.

10.2.4.7. PHP

Die Konfiguration für PHP wurde von httpd.conf in die Datei /etc/httpd/conf.d/php.conf verschoben. Damit diese Datei geladen wird, müssen Sie die Anweisung Include conf.d/*.conf wie in Abschnitt 10.2.1.3 beschrieben in Ihrer Datei httpd.conf haben.

PHP ist jetzt als Filter implementiert und deshalb anders aktiviert werden. Weitere Informationen zu Filtern finden Sie unter Abschnitt 10.2.4.

In Apache HTTP-Server 1.3 wurde PHP anhand folgender Anweisungen implementiert:

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Verwenden Sie dagegen in Apache HTTP-Server 2.0 folgende Anweisungen:

<Files *.php>
    SetOutputFilter PHP
    SetInputFilter PHP
</Files>

In PHP 4.2.0 und späteren Versionen haben sich die standardmäßigen vordefinierten Variablen, die im globalen Scope verfügbar waren, geändert. Individuelle Input- und Servervariablen werden nicht mehr standardmäßig direkt in das globale Scope gesetzt. Diese Änderung kann dazu führen, dass Skripts nicht mehr funktionieren. Sie können zum alten Verhalten zurückkehren, indem Sie in der Datei /etc/php.ini register_globals auf On setzen.

Weitere Informationen zu diesem Thema finden Sie im folgenden URL. Darin enthalten sind Einzelheiten zu den Änderungen im globalen Scope: