NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Rerenzhandbuch- Migrieren von Apache HTTP Server 1.3 Konfigurationsdateien
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:
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:
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.
Wichtig
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.
Wichtig
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 https://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:
Die veraltete Anweisung FancyIndexing wurde entfernt. Die gleiche Funktionalit�t ist �ber FancyIndexingOption 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:
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:
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:
Der Inhalt aller <VirtualHost> Sektionen sollte auf die gleiche Weise wie der Hauptserver-Abschnitt migriert werden, wie in Abschnitt 10.2.2 beschrieben.
Wichtig
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:
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_perlgefiltert.
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:
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:
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:
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:
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:
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:
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.
Aktion
dbmmanage Befehl (Apache 1.3)
Entsprechender htdbm Befehl (Apache 2.0)
Benutzer zu Datenbank hinzuf�gen (angegebenes Passwort verwenden)
dbmmanage authdb add username password
htdbm -b -TDB authdb username password
Benutzer zu Datenbank hinzuf�gen (fragt nach Passwort)
dbmmanage authdb adduser username
htdbm -TDB authdb username
Benutzer aus Datenbank entfernen
dbmmanage authdb delete username
htdbm -x -TDB authdb username
Benutzer in Datenbank auflisten
dbmmanage authdb view
htdbm -l -TDB authdb
Passwort pr�fen
dbmmanage authdb check username
htdbm -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:
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:
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.
Bitte 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.iniregister_globals auf On setzen.
Weitere Informationen zu diesem Thema finden Sie im folgenden URL. Darin enthalten sind Einzelheiten zu den �nderungen im globalen Scope:
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.
Wichtig
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 https://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 https://authzldap.othello.ch/ f�r weitere Informationen zur Konfiguration des "Third Party" Moduls mod_authz_ldap.
