10.2. Migrieren von Apache HTTP Server 1.3 Konfigurationsdateien

Der nächste Abschnitt zeigt im Detail, wie eine Apache HTTP Server 1.3 Konfigurationsdatei migriert wird, um von Apache HTTP Server 2.0 genutzt werden zu können.

Wenn Ihr Server von Red Hat Enterprise Linux 2.1 auf Red Hat Enterprise Linux 4 aktualisiert wurde, dann wird die neue Stock-Konfigurationsdatei für das Apache HTTP Server 2.0-Paket als /etc/httpd/conf/httpd.conf.rpmnew installiert und die Originalversion 1.3 httpd.conf bleibt unverändert. 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.

Handelt es sich bei /etc/httpd/conf/httpd.conf um eine modifizierte Version der neuinstallierten Standard Red Hat-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 (als root angemeldet):

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

In the above command, replace <version-number> with the version number for the apache package.

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. Globale Umgebungskonfiguration

Der globale Umgebungsabschnitt der Konfigurationsdatei enthält Anweisungen, die sich insgesamt auf die Funktionsweise von Apache HTTP Server auswirken, wie z.B. die Anzahl konkurrierender Anfragen, die abgefertigt werden können sowie die Speicherplätze der verschiedenen Dateien. Bei diesem Abschnitt ist eine große Anzahl an Änderungen notwendig und sollten daher auf der Basis der Apache HTTP Server 2.0 Konfigurationsdatei stattfinden, wobei die Migration Ihrer alten Einstellungen dorthin erfolgt.

10.2.1.1. Interface- und Port-Binding

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 nicht 80 war 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 zu 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

Wenn Apache HTTP Server Anforderungen annimmt, werden Child-Prozesse oder Threads erzeugt, die diese übernehmen. Diese Gruppe von Child-Prozessen oder Threads wird Server-Pool genannt. Die Verantwortung der Handhabung des Annehmens und Versendens von Child-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. Drei MPM-Module werden mit der Version 2.0 ausgeliefert: prefork, worker und perchild. Lediglich prefork und worker MPMs sind zur Zeit verfügbar, das perchild MPM könnte allerdings zu einem späteren Zeitpunkt verfügbar werden.

Das standardmäßige Verhalten des Apache HTTP Server 1.3 wurde in das prefork MPM verlagert. 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

Das worker MPM implementiert einen Multi-Process, Multi-Threaded Server, der eine größere Skalierbarkeit bietet. Wenn dieses MPM verwendet wird, werden Anfragen durch Threads gehandhabt, was Systemreserven spart und es einer größeren Anzahl von Anfragen erlaubt effizient beantwortet zu werden. Obwohl einige der von der worker MPM akzeptierten Anweisungen die selben sind wie die von der prefork MPM akzeptierten, sollten die Werte nicht direkt von einer Apache HTTP Server 1.3 Installation übertragen werden. Es ist am Besten, die Standardwerte als Richtlinie zu nehmen, und dann zu Experimentieren, um die geeignetsten Werte zu bestimmen.

WichtigWichtig
 

Um das worker MPM zu verwenden, erzeugen Sie die Datei /etc/sysconfig/httpd unf fügen folgende Anweisungen zu der Datei hinzu:

HTTPD=/usr/sbin/httpd.worker

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 2.0-Konfiguration anzupassen (im Gegensatz zur Migration Ihrer Änderungen in die 2.0-Konfiguration), diesen Abschnitt aus der Apache HTTP Server 2.0 Stock-Konfigurationsdatei zu kopieren.

Diejenigen, die den Abschnitt immer noch nicht aus der Stock - Apache HTTP Server 2.0-Konfiguration kopieren möchten, sollten Folgendes beachten:

  • Die Anweisungen AddModule und ClearModuleList existieren nicht mehr. Diese Anweisungen wurden verwendet, um sicherzustellen, dass Module in der richtigen Reihenfolge aktiviert werden konnten. Apache 2.0 API erlaubt es den Modulen, ihre Reihenfolge anzugeben, womit diese beiden Anweisungen überflüssig werden.

  • Die Reihenfolge der LoadModule Zeilen ist in den meisten Fällen nicht mehr länger 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 globale Umgebungsänderungen

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 <VirtualHost> Definitionen, die Sie eventuell definieren möchten.

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 Apache HTTP Server 2.0 Stock-Konfiguration migrieren.

10.2.2.1. UserDir Mapping

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 folgender Dokumentation der Apache Software Foundation Website:

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 Option VersionSort für die IndexOptions-Anweisung führt dazu, dass Dateien mit Versionsnummern auf natürlichere 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 feste Meldung mit der ErrorDocument Anweisung zu verwenden, sollte die Meldung von einem Paar doppelter Anführungszeichen umschlossen sein, anstatt dass nur doppelte Anführungszeichen der Meldung vorangestellt werden, wie in Apache 1.3. verlangt.

Folgendes ist ein Beispiel einer Apache HTTP Server 1.3 Anweisung:

ErrorDocument 404 "The document was not found

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 Apache HTTP Secure Server Konfiguration im Red Hat Enterprise Linux Handbuch zur System-Administration und in der Online-Dokumentation unter folgender URL:

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. CGI-Skripts sind zum Beispiel in der Lage, serverkonvertierte 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 Perl-Skript ganz vom Perl-Modul (mod_perl) gehandhabt werden. In Apache HTTP Server 2.0 wird die Anfrage zunächst vom Kernmodul gehandhabt — das statische Dateien bedient — und wird dann von mod_perl 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.

Untenstehend 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 suexec-Modul

In Apache HTTP Server 2.0 benutzt das mod_suexec Modul eher die SuexecUserGroup Anweisung, als die User und Group Anweisungen, zur Konfigurierung virtueller Hosts. Die User und Group Anweisungen können im Allgemeinen noch immer verwendet werden, jedoch nicht mehr im Zusammenhang mit der Konfiguration virtueller Hosts.

Folgendes ist ein Beispiel einer Apache HTTP Server 1.3 Anweisung:

<VirtualHost vhost.example.com:80>
    User someone
    Group somegroup
</VirtualHost>

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

<VirtualHost vhost.example.com:80>
    SuexecUserGroup someone somegroup
</VirtualHost>

10.2.4.2. 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, muss sich die Angabe Include conf.d/*.conf wie in Abschnitt 10.2.1.3 beschrieben in Ihrer Datei httpd.conf befinden.

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 zu Apache HTTP Server 2.0 zu migrieren:

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

Es ist auch wichtig zu beachten, dass beide, die SSLLog und SSLLogLevel Anweisung, entfernt wurden. Das Modul mod_ssl unterliegt nun den ErrorLog und LogLevel Anweisungen. Sehen Sie Abschnitt 10.5.35 und Abschnitt 10.5.36 für weitere Information zu diesen Anweisungen.

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

10.2.4.3. 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_mem_cache

Diese verwenden normalerweise die gleichen oder ähnliche Anweisungen wie die älteren Versionen des mod_proxy Moduls. Es wird allerdings angeraten, jede Anweisung zu prüfen, bevor etwaige Cache-Einstellungen migriert werden.

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

10.2.4.4. Das Modul mod_include

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

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 zu 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.5. 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 zu migrieren, müssen die Konfigurationsdateien angepasst werden, indem man AuthDBUserFile und AuthDBGroupFile durch deren mod_auth_dbm Äquivalente ersetzt: 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 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 Manipulation 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 zu verwendenden 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 (Apache 1.3)Entsprechender htdbm Befehl (Apache 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.6. 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
    PerlResponseHandler ModPerl::Registry
    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.7. Das Modul mod_python

Die Konfiguration für mod_python; wurde von /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.8. 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.

AnmerkungBitte beachten
 

Jegliche PHP Konfigurationsanweisungen, die in Apache HTTP Server 1.3 verwendet werden, sind nunmehr bei der Migration zu Apache HTTP Server 2.0 auf Red Hat Enterprise Linux 4 völlig kompatibel.

In PHP 4.2.0 und späteren Versionen hat sich der Satz an standardmäßig vordefinierten Variablen geändert, welche im globalen Anwendungsbereich verfügbar waren.Individuelle Input- und Servervariablen werden nicht mehr standardmäßig direkt im globalen Bereich untergebracht. 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:

10.2.4.9. Das Modul mod_authz_ldap

Red Hat Enterprise Linux wird mit dem Modul mod_authz_ldap für Apache HTTP Server ausgeliefert. Dieses Modul verwendet die Kurzform des "Distinguished Name" als Subjekt und den Aussteller des Client-SSL-Zertifikats, um den "Distinguished Name" des Benutzers innerhalb eines LDAP-Verzeichnisses zu bestimmen. Es kann auch Benutzer anhand den Attributen der Einträge im LDAP-Verzeichnis autorisieren, wobei Zugriff auf ein Asset auf Benutzerrechte und Gruppenrechten des Asset basiert und Zugriff für Benutzer mit abgelaufenen Passwörtern abgelehnt wird. Das Modul mod_ssl wird für die Verwendung des Modul mod_authz_ldap benötigt.

WichtigWichtig
 

Das Modul mod_authz_ldap authetifiziert einen Benutzer zu einem LDAP-Verzecihnis nicht mit einem verschlüsselten Passwort-Hash. Diese Funktionalität ist im exprimentellen Modul mod_auth_ldap enthalten. Siehe die Online-Dokumentation des Modul mod_auth_ldap unter http://httpd.apache.org/docs-2.0/mod/mod_auth_ldap.html für Informationen zum Status dieses Moduls.

Die Datei /etc/httpd/conf.d/authz_ldap.conf konfiguriert das Modul mod_authz_ldap.

Siehe /usr/share/doc/mod_authz_ldap-<version>/index.html (ersetzen Sie <version> mit der Versionsnummer des Pakets) oder http://authzldap.othello.ch/ für weitere Informationen zur Konfiguration des "Third Party" Moduls mod_authz_ldap.