Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

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:

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 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:

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

 
 
  Published under the terms of the GNU General Public License Design by Interspire