|
|
|||||||||||||||||||||||||||||||||||||||||||||
10.2. Migrieren von Apache HTTP Server 1.3 KonfigurationsdateienDer 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 UmgebungskonfigurationDer 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-BindingDie 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��eneinstellungWenn 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:
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.
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:
10.2.1.4. Sonstige globale Umgebungs�nderungenFolgende Anweisungen wurden aus der Apache HTTP Server 2.0 Konfiguration entfernt:
10.2.2. Hauptserver-KonfigurationDer 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 MappingDie 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. LoggingFolgende Log-Anweisungen wurden entfernt:
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 VerzeichnisseDie 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. InhaltsverhandlungDie 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. FehlerdokumenteUm 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 HostDer Inhalt aller <VirtualHost> Sektionen sollte auf die gleiche Weise wie der Hauptserver-Abschnitt migriert werden, wie in Abschnitt 10.2.2 beschrieben.
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.0In 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-ModulIn 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_sslDie 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_proxyZugriffskontrollbefehle 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:
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_includeDas 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_dbApache 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.
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_perlDie 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_pythonDie 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. PHPDie 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.
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_ldapRed 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.
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.
|
|||||||||||||||||||||||||||||||||||||||||||||