46.5. Apache-Module

Die Apache-Software ist modulartig aufgebaut. Sämtliche Funktionen mit Ausnahme der wichtigsten Aufgaben werden in Modulen zur Verfügung gestellt. Dies geht sogar so weit, dass selbst HTTP durch ein Modul verarbeitet wird (http_core).

Apache-Module können bei der Entwicklung in die Apache-Binaries kompiliert oder während der Laufzeit dynamisch geladen werden. Wie die Module während der Laufzeit manuell bzw. mit YaST geladen werden, erfahren Sie im Abschnitt 46.3.2.2.1, „LoadModule Modul_ID /Pfad/des/Moduls bzw. im Abschnitt Module.

Apache wird in SUSE Linux mit den folgenden, im apache2-RPM sofort verfügbaren Modulen ausgeliefert (das Präfix „mod_“ wurde in folgender Aufstellung weggelassen): access, actions, alias, asis, auth, auth_anon, auth_dbm, auth_digest, auth_ldap, autoindex, cache, case_filter, case_filter_in, cern_meta, cgi, charset_lite, dav, dav_fs, deflate, dir, disk_cache, dumpio, echo, env, expires, ext_filter, file_cache, headers, imap, include, info, ldap, log_config, log_forensic, logio, mem_cache, mime, mime_magic, negotiation, proxy, proxy_connect, proxy_ftp, proxy_http, rewrite, setenvif, speling, ssl, status, suexec, unique_id, userdir, usertrack und vhost_alias. Darüber hinaus stellt SUSE Linux folgende Apache-Module als RPM-Pakete bereit, die gesondert installiert werden müssen: apache2-mod_auth_mysql, apache2-mod_fastcgi, apache2-mod_macro, apache2-mod_murka, apache2-mod_perl, apache2-mod_php4, apache2-mod_php5, apache2-mod_python und apache2-mod_ruby.

Auf einige dieser Module wird in diesem Abschnitt näher eingegangen. Eine Beschreibung der übrigen, in der Basisausstattung enthaltenen Module, finden Sie auf der Apache-Website unter http://httpd.apache.org/docs-2.0/mod/. Module von Drittanbietern werden unter http://modules.apache.org/ beschrieben.

Apache-Module lassen sich in drei Kategorien einteilen: Basismodule, Erweiterungsmodule und externe Module.

46.5.1. Basismodule

Basismodule sind standardmäßig in Apache enthalten. Sie stehen in jedem Fall zur Verfügung, es sei denn, sie wurden bei der Entwicklung ausdrücklich weggelassen. In Apache von SUSE Linux sind nur die grundlegenden Basismodule kompiliert. Alle anderen Basismodule stehen jedoch als shared objects zur Verfügung: wenn sie nicht in der /usr/sbin/httpd2-Binary enthalten sind, können sie während der Laufzeit über APACHE_MODULES in /etc/sysconfig/apache2 hinzugefügt werden.

46.5.1.1. Serverseitige Includes (Einschlüsse) mit mod_include

mod_include ist ein Mittel zur Dateiverarbeitung, bevor Daten an den Client gesendet werden. In der Regel wird mod_include zum Einschließen von Dateien in ein Dokument verwendet, die vor Erreichen des Clients als HTML geparst werden. Aus diesem Grund werden diese Einschlüsse auch als serverseitige Includes (SSIs) bezeichnet.

Bei SSIs werden spezielle Befehle auf dem Server ausgeführt, die von formatierten SGML-Kommentaren initiiert werden. Diese SGML-Befehle haben die folgende Syntax:

 <!--#Element Attribut=Wert --> 

Eine Liste der Element- und Attribut-Werte finden Sie in der Dokumentation von mod_include unter http://httpd.apache.org/docs-2.0/mod/mod_include.html.

Wenn Sie mod_include in SUSE Linux verwenden möchten, fügen Sie include zu APACHE_MODULES in /etc/sysconfig/apache2 hinzu oder verwenden Sie YaST, wie in Module beschrieben.

[Tip]Tipp

Mit der XBitHack-Direktive (http://httpd.apache.org/docs-2.0/mod/mod_include.html#xbithack) instruieren Sie Apache, Dateien für SSI-Direktiven mit gesetztem Execute-Bit zu parsen.

Statt die Erweiterung einer Datei ändern zu müssen, um sie als Container für SSI-Elemente zu kennzeichnen (.shtml im obigen Beispiel), können Sie eine normale .html-Datei verwenden und chmod +x EigeneDatei.html ausführen.

46.5.1.2. Common Gateway Interface: mod_cgi

mod_cgi befähigt Apache, Inhalte bereitzustellen, die in externen Common Gateway Interface (CGI)-Programmen oder -Skripts erstellt wurden. mod_cgi agiert somit als Instanz zwischen der Programmiersprache auf dem physischen Gerät und dem Apache-Webserver. Theoretisch können CGI-Skripts in jeder beliebigen Programmiersprache geschrieben sein. Üblich sind aber Sprachen wie Perl oder C. mod_cgi ist die gängigste Methode, dynamischen Inhalt in eine Website einzuschließen.

Die CGI-Programmierung unterscheidet sich von der herkömmlichen Programmierung insoweit, als CGI-Programme und -Skripts den MIME-Typ Content-type: text/html hervorbringen müssen, um eine HTML-Ausgabe zu produzieren.

Beispiel 46.11. Ein einfaches CGI-Skript in Perl

 #!/Pfad/zu/perl
print "Content-type: text/html\n\n";
print "Hello, World."; 

Der Unterschied zwischen Modulen, die an eine spezielle Programmiersprache gebunden sind (z. B. mod_php5), und mod_cgi liegt in der Möglichkeit, mod_cgi mit mod_suexec zu kombinieren (siehe Abschnitt 46.5.2.1, „Ausführen von CGIs unter einem anderen Benutzer mit mod_suexec). Durch diese Kombinationsfähigkeit können CGI-Skripts mit einer bestimmten Benutzer-ID ausgeführt werden. Skripts, die nur mod_cgi oder mod_php5 verwenden, werden in der Regel mit der Benutzer-ID des Apache-Benutzers ausgeführt (Standardeinstellung in SUSE Linux: wwwrun). Module, die für eine bestimmte Programmiersprache (wie mod_php5 oder mod_ruby) entwickelt wurden, betten in Apache einen persistenten Interpreter ein, der die Skripts unter der Benutzer-ID von Apache ausführt.

CGIs mit mod_suexec vereinfachen daher die Verwaltung, da die CGI-Prozesse statt dem Webserver individuellen Benutzern zugeordnet werden können. Außerdem erhöht diese Kombination die Sicherheit des Dateisystems: Das Skript übernimmt nur die Dateisystemrechte des jeweiligen Benutzers. Dagegen werden dem Skript im Falle von Modulen die Dateiberechtigungen des Webserver-Benutzers zugeschrieben, was wiederum zu einer unerwünschten Datensichtbarkeit im Dateisystem führen kann.

CGIs werden nach der Ausführung einer Client-Anforderung an den Webserver beendet. CGIs sind also nicht persistent und geben die belegten Ressourcen nach ihrer Beendigung frei. Gerade im Falle einer fehlerhaften Programmierung ist dies von Vorteil. Bei Modulen können sich die Auswirkungen von Programmierungsfehlern anhäufen, da der Interpreter persistent vorliegt. Dies kann dazu führen, dass Ressourcen, beispielsweise Datenbankverbindungen, nicht mehr freigegeben werden, wodurch letztlich ein Neustart von Apache erforderlich wird.

Wenn Sie mod_cgi in SUSE Linux verwenden möchten, fügen Sie cgi zu APACHE_MODULES in /etc/sysconfig/apache2 hinzu oder verwenden Sie YaST, wie in Module beschrieben. Das Standardverzeichnis für CGIs ist in SUSE Linux /srv/www/cgi-bin/.

Falls Sie Ihre Apache-Konfigurationsdatei manuell bearbeiten möchten, verwenden Sie das folgende Beispiel als Anhaltspunkt für die Konfiguration von mod_cgi.

Beispiel 46.12. Manuelle Aktivierung von mod_cgi

# Global Environment
LoadModule cgi_module /Pfad/zu/mod_cgi.so

# Main Server and/or Virtual Host and/or
# Directory and/or .htaccess context
AddHandler cgi-script .cgi .pl

# Main Server and/or Virtual Host context
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

# Alternatively, explicitly allow CGI scripts in a directory
# Main Server and/or Virtual Host context
<Directory /srv/www/some/dir> 
	Options +ExecCGI
<Directory> 

46.5.2. Erweiterungsmodule

Im Allgemeinen sind Erweiterungsmodule im Apache-Softwarepaket enthalten, jedoch nicht statisch im Server kompiliert. In SUSE Linux stehen diese Module als shared Objects zur Verfügung, die während der Laufzeit in Apache geladen werden können.

46.5.2.1. Ausführen von CGIs unter einem anderen Benutzer mit mod_suexec

In Verbindung mit mod_cgi (siehe Abschnitt 46.5.1.2, „Common Gateway Interface: mod_cgi) ermöglicht mod_suexec die Ausführung von CGI-Skripts für einen bestimmten Benutzer und eine bestimmte Gruppe. Zu diesem Zweck wird das Programm suEXEC aus /usr/sbin/suexec2 ausgeführt. Es handelt sich hier um einen Wrapper, der von Apache bei jeder Ausführung eines CGI-Skripts oder CGI-Programms aufgerufen wird. Sowohl dem Wrapper als auch dem Programm wird die konfigurierte Benutzer- und Gruppen-ID zugewiesen. Dadurch wird das Programm für den konfigurierten Benutzer oder die Gruppe ausgeführt.

Diese Vorgehensweise reduziert zwar das mit benutzergenerierten CGI-Skripts einhergehende Sicherheitsrisiko, bringt aber einige Einschränkungen mit sich:

Einschränkungen von suEXEC

  • suEXEC docroot (absoluter Pfad von suEXEC): Alle Skriptausführungen sind auf dieses Basisverzeichnis beschränkt. Die Ausführung von Skripts außerhalb des docroot ist mit suEXEC nicht möglich und würde zu einem Fehler führen. Das docroot-Verzeichnis wird bei der Kompilierung von suEXEC festgelegt und kann während der Laufzeit nicht geändert werden. Die Standardeinstellung in SUSE Linux ist /srv/www.

  • uidmin: Gibt die Mindest-ID an, die ein Benutzer für die Ausführung von Skripts mit suEXEC besitzen muss. Dadurch wird verhindert, dass Skripts von Systembenutzern wie root ausgeführt werden. Erteilen Sie Benutzern, die Skripts mit mod_suexec ausführen sollen, keine niedrigeren IDs als uidmin. Der uidmin-Standardwert in SUSE Linux ist 96.

  • gidmin: Diese Einstellung entspricht dem Konzept der uidmin, gilt aber für Gruppen-IDs. Der gidmin-Standardwert in SUSE Linux ist 96.

  • Verzeichnis- und Dateiberechtigungen: Das jeweilige Skript muss dem Benutzer und der Gruppe angehören, die für suEXEC festgelegt sind. Außerdem darf die Datei von keinem anderen Benutzer außer dem Eigentümer bearbeitet werden können. Auch das Verzeichnis, in dem sich das Skript befindet, darf nur durch den Eigentümer bearbeitbar sein.

  • suEXEC safepath (sicherer Pfad von suEXEC): Alle Programme, die in einem Skript verwendet werden (z. B. Perl), müssen sich in einem Verzeichnis befinden, das für suEXEC als sicher gekennzeichnet ist. Das safepath-Verzeichnis wird bei der Kompilierung von suEXEC festgelegt und kann während der Laufzeit nicht geändert werden. Die Standardeinstellung in SUSE Linux ist /usr/local/bin:/usr/bin:/bin.

Sollte es in Verbindung mit mod_suexec zu Fehlern kommen, konsultieren Sie das suEXEC-Protokoll in /var/log/apache2/suexec.log.

Wenn Sie mod_suexec in SUSE Linux verwenden möchten, fügen Sie suexec zu APACHE_MODULES in /etc/sysconfig/apache2 hinzu oder verwenden Sie YaST, wie in Module beschrieben. Berücksichtigen Sie außerdem, dass zur Ausführung von suEXEC das Basismodul mod_cgi erforderlich ist.

mod_suexec ist besonders in einer virtuellen Hostumgebung (siehe Abschnitt 46.4, „Virtuelle Hosts“) sinnvoll. Den Benutzer und die Gruppe, unter denen CGI-Skripts ausgeführt werden, geben Sie in der Datei, die die virtuellen Hostdeklarationen enthält (in SUSE Linux standardmäßig die Datei /etc/apache2/vhosts.d/*), mit folgender Syntax an:

Beispiel 46.13. mod_suexec-Konfiguration

<VirtualHost 192.168.0>
# ...
ScriptAlias /cgi-bin/ /srv/www/vhosts/www.beispiel.com/cgi-bin/
SuexecUserGroup tux benutzer
# ...
</VirtualHost> 

In diesem Beispiel weisen Sie mit der Syntax SuexecUserGroup Benutzername Gruppe alle Skripts in /srv/www/vhosts/www.beispiel.com/cgi-bin/ der Benutzer-ID „tux“ und der Gruppen-ID „benutzer“ zu.

46.5.2.2. Secure Sockets Layer und Apache: mod_ssl

mod_ssl bietet mittels der Protokolle Secure Sockets Layer (SSL) und Transport Layer Security (TLS) eine sichere Verschlüsselung für die HTTP-Kommunikation zwischen einem Client und dem Webserver. Zu diesem Zweck sendet der Server vor der Beantwortung von Anforderungen an eine URL ein SSL-Zertifikat mit Informationen, die die Identität des Servers nachweisen. Dies garantiert, dass der Server der eindeutig gekennzeichnete und richtige Endpunkt der Kommunikation ist. Außerdem wird durch das Zertifikat eine verschlüsselte Verbindung zwischen dem Client und dem Server hergestellt, die sicherstellt, dass Informationen ohne das Risiko der Freigabe sensitiver Klartextinhalte übertragen werden. Die Verwendung von mod_ssl in Apache erkennen Sie in URLs am Präfix https:// (statt http://).

Auf dem Webserver ist Port 443 der Standard-Port für SSL- und TLS-Anforderungen. Zwischen einem „normalen“ Apache-Webserver, der Port 80 überwacht, und einem SSL/TLS-aktivierten Apache-Server, der Port 443 überwacht, kommt es zu keinen Konflikten. In der Tat kann die gleiche Apache-Instanz sowohl HTTP als auch HTTPS ausführen. In der Regel ist ein virtueller Host (siehe Abschnitt 46.4, „Virtuelle Hosts“) eigens dafür abgestellt, die Anforderungen für Port 80 und Port 443 an separate virtuelle Server zu verteilen.

[Important]Namensbasierte virtuelle Hosts und SSL

Auf einem Server mit nur einer IP-Adresse können nicht mehrere SSL-aktivierte virtuelle Hosts laufen. Benutzer, die versuchen, eine Verbindung mit einer solchen Konfiguration herzustellen, erhalten bei jedem Besuch der URL eine Warnung mit dem Hinweis, dass das Zertifikat nicht mit dem Namen des Servers übereinstimmt. Für die Kommunikation auf Grundlage eines gültigen SSL-Zertifikats ist eine separate IP-Adresse bzw. ein separater Port für jede SSL-aktivierte Domäne erforderlich.

Trotz der Warnung erhalten Sie die gleiche Verschlüsselungsstufe wie auf jeder gültigen SSL-Site. Die Kommunikation zwischen dem Webserver und dem Client ist also trotz Warnung sicher. Ein wichtiges Konzept, das durch ein gültiges SSL-Zertifikat garantiert wird, nämlich der Identitätsnachweis des Servers, geht allerdings verloren.

Wenn Sie mod_ssl in SUSE Linux aktivieren möchten, fügen Sie ssl zu APACHE_MODULES in /etc/sysconfig/apache2 hinzu oder verwenden Sie YaST, wie in Module beschrieben. Außerdem müssen Sie auf dem Webserver die Überwachung des HTTPS-Standardportes 443 konfigurieren. Diese Einstellung können Sie manuell in /etc/apache2/listen.conf oder in YaST mit dem Menüeintrag Lauschen auf vornehmen (siehe Auswahl des Netzwerkgeräts).

Mit cd /usr/share/doc/packages/apache2; ./certificate.sh als root können Sie ein SSL-Testzertifikat erstellen. Befolgen Sie hierzu die Anweisungen auf dem Bildschirm. Die zugehörigen Zertifikatdateien werden in den Verzeichnissen /etc/apache2/ssl* abgelegt.

Ein „echtes“ Zertifikat mit globaler Gültigkeit erhalten Sie von Zertifikatausstellern wie Thawte (http://www.thawte.com/) oder Verisign (www.verisign.com).

Falls Sie Ihre Apache-Konfigurationsdatei manuell bearbeiten möchten, verwenden Sie das folgende Beispiel als Anhaltspunkt für die Konfiguration von mod_ssl.

Beispiel 46.14. Manuelle Konfiguration von mod_ssl

# Global Environment
# listen on the standard SSL port
Listen 443
# load module only if rcapache2 start-ssl was issued
<IfDefine SSL>
LoadModule ssl_module /Pfad/zu/mod_ssl.so
</IfDefine>

# Main Server context
# include global (server-wide) SSL configuration
# that is not specific to any virtual host
# only if ssl_module was loaded
<IfModule mod_ssl.c>
Include /etc/apache2/ssl-global.conf
</IfModule> 
[Tip]Tipp

Vergessen Sie nicht, die Firewall für SSL-aktivierte Apache-Server an Port 443 zu öffnen. Dazu können Sie YaST verwenden: Navigieren Sie zu Sicherheit und Benutzer+Firewall+Erlaubte Dienste und fügen Sie der Liste Erlaubte Dienste den Eintrag HTTPS-Server hinzu.

46.5.3. Externe Module

Externe Module sind offiziell nicht in der Apache-Distribution enthalten. SUSE Linux bietet jedoch einige externe Module an, die ohne großen Aufwand sofort verwendet werden können. Dieses Kapitel geht kurz auf einige dieser Module und deren Funktionen ein.

46.5.3.1. Verwenden von Perl zur Verwaltung von Apache: mod_perl

mod_perl bettet einen persistenten Perl-Interpreter in Apache ein. Perl umgeht den von mod_cgi verursachten Overhead, der bei jeder CGI-Anforderung eine externe ausführbare Datei aufruft. Zudem ermöglicht mod_perl die Steuerung zahlreicher Aspekte der Apache-Funktionalität mithilfe der Programmiersprache Perl.

Wenn Sie mod_perl in SUSE Linux verwenden möchten, installieren Sie das apache2-mod_perl-RPM und aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2. Nach der Installation und Aktivierung wird in /etc/apache2/conf.d/ eine eigene Konfigurationsdatei (mod_perl.conf) für dieses Modul erstellt. Außerdem wird das mod_perl-Startskript (mod_perl-startup.pl) installiert. Weitere Informationen zur Verwendung dieses Moduls finden Sie in der Dokumentation auf der Website zu mod_perl unter http://perl.apache.org/.

46.5.3.2. Unterstützung für PHP: mod_php4, mod_php5

PHP ist eine weit verbreitete Programmiersprache, die ursprünglich für das Web entwickelt wurde und in zwei Versionen vorliegt: PHP4 und PHP5. PHP4 repräsentiert das klassische Konzept und die ursprünglichen Vorgehensweisen von PHP, während PHP5 neue, objektorientierte Programmiermöglichkeiten mit zahlreichen erweiterten Funktionen bereitstellt. Beide Versionen stehen in SUSE Linux zur Verfügung. Sie betten den PHP-Interpreter als persistentes Modul in Apache ein.

Wenn Sie mod_php4 oder mod_php5 in SUSE Linux verwenden möchten, installieren Sie das betreffende RPM (apache2-mod_php4 oder apache2-mod_php5) und aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2.

Nach der Installation und Aktivierung wird in /etc/apache2/conf.d/ eine eigene Konfigurationsdatei für das jeweilige Modul (php4.conf oder php5.conf) erstellt. Die PHP-Website (http://www.php.net) ist ein hervorragendes Nachschlagewerk, wenn Sie Informationen zur Verwendung von Apache mit PHP suchen.

46.5.3.3. Python und Apache: mod_python

mod_python bettet den Python-Interpreter in Apache ein. Python ist eine objektorientierte Programmiersprache mit einer klaren und einfachen Syntax. Eine ungewöhnliche, aber sehr praktische Programmierungsweise besteht darin, dass sich die Programmstruktur nach den Einrückungen im Quellcode richtet, nicht wie üblich nach Begrenzern wie begin und end.

Wenn Sie mod_python in SUSE Linux verwenden möchten, installieren Sie das apache2-mod_python-RPM und aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2. Weitere Informationen zur Verwendung dieses Moduls finden Sie in der Dokumentation auf der Website zu mod_python unter http://www.modpython.org/.

46.5.3.4. Ruby-Interpreter in Apache: mod_ruby

mod_ruby bettet den Ruby-Interpreter in den Apache-Webserver ein. Dadurch können Ruby CGI-Skripts in Originalversion ausgeführt werden. Ruby ist eine relativ neue, objektorientierte High-Level-Programmiersprache, die in bestimmten Aspekten an Perl und Python erinnert. Wie Python verfügt Ruby über eine klare, transparente Syntax. Andererseits hat Ruby einige Abkürzungen übernommen (wie $.r für die Nummer der letzten aus der Eingabedatei gelesenen Zeile), die einige Programmierer sehr zu schätzen wissen, andere jedoch eher ablehnen. Das grundlegende Konzept von Ruby ist vergleichbar mit dem von Smalltalk.

Wenn Sie mod_ruby in SUSE Linux verwenden möchten, installieren Sie das apache2-mod_ruby-RPM und aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2. Weitere Informationen zur Verwendung dieses Moduls finden Sie in der Dokumentation auf der Website zu mod_ruby unter http://www.modruby.net/en/index.rbx.

46.5.3.5. Zugriff auf das native Dateisystem: mod_dav

mod_dav stellt in Apache WebDAV-Funktionalität (Web-Based Distributed Authoring and Versioning) bereit. WebDAV ist eine Erweiterung des HTTP-Protokolls, mit dem Benutzer Dateien auf entfernten Servern gemeinsam bearbeiten und verwalten können. Die Funktionalität von WebDAV ist vergleichbar mit der von FTP, allerdings mit dem Unterschied, dass HTTP als zugrunde liegendes Protokoll für den Serverzugriff verwendet wird. Im Prinzip wandelt mod_dav einen einfachen Apache-Webserver in ein erweitertes entferntes Dateisystem um.

Wenn auch nicht erforderlich, empfiehlt es sich, den Zugriff auf die via WebDAV zur Verfügung gestellten Verzeichnisse einzuschränken. Als minimale Vorkehrung sollten Sie die WebDAV-Ressource durch eine grundlegende HTTP-Authentifizierung und Limit-Klauseln in Location-Direktiven schützen.

Für den Zugriff auf WebDAV-Ressourcen ist auf dem Client eine WebDAV-fähige Software erforderlich. SUSE Linux verfügt bereits über WebDAV-Fähigkeiten: Für die Verbindung mit einem Apache WebDAV-Dateisystem kann Konqueror mit dem Präfix webdav:// oder webdavs:// (Letzteres für WebDAV via SSL) verwendet werden.

mod_dav setzt das Modul mod_dav_fs voraus, das den eigentlichen Dateisystemzugriff für WebDAV bereitstellt. Wenn Sie mod_dav in SUSE Linux verwenden möchten, aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2. Aktivieren Sie auf die gleiche Weise auch mod_dav_fs. Weitere Informationen zur Verwendung dieses Moduls finden Sie in der Dokumentation auf der Website zu mod_dav unter http://httpd.apache.org/docs-2.0/mod/mod_dav.html.

46.5.3.6. Anbieten von Benutzer-Homepages: mod_userdir

mod_userdir in SUSE Linux bietet standardmäßig den Inhalt des ~/public_html-Ordners eines jeden Benutzers als öffentliche Webseiten an. Die URL, mit der auf diese Seiten zugegriffen wird, lautet http://www.beispiel.com/~Benutzername/.

[Tip]Tipp

Aus Sicherheitsgründen unterbindet mod_userdir in SUSE Linux den Zugriff auf den Inhalt des Homeverzeichnisses des Root-Benutzers. Mit folgender Syntax können Sie außerdem die Bereitstellung öffentlicher Homepages auf bestimmte Benutzer einschränken:

# Main server context
UserDir disabled
UserDir enabled tux wilber 

Wenn Sie mod_userdir in SUSE Linux verwenden möchten, aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2. Weitere Informationen zur Verwendung dieses Moduls finden Sie in der Dokumentation auf der Website zu mod_userdir unter http://httpd.apache.org/docs-2.0/mod/mod_userdir.html.

46.5.3.7. Ändern des URL-Layouts: mod_rewrite

mod_rewrite wird gerne mit einem „Schweizer Präzisionsmesser für die URL-Manipulation“ verglichen. Es schreibt angeforderte URLs in Windeseile nach einem bestimmten Regelsatz um. Aus umständlichen URLs wie http://www.beispiel.com/display.php?cat=2&article=1&lang=de ergibt sich so sehr schnell eine wesentlich einfachere Adresse wie http://www.beispiel.com/2/1/de.

Der URL Rewriting Guide fasst die Vorteile und Nachteile dieses leistungsstarken, aber komplexen Moduls mit wenigen Worten zusammen:

Mit mod_rewrite schießen Sie sich beim ersten Versuch entweder in den Fuß und verwenden es nie wieder oder Sie schätzen seine Leistungsstärke für den Rest Ihres Lebens.

RewriteRule-Sätze können für jeden Konfigurationskontext festgelegt werden: für den Hauptserver, für virtuelle Hosts, für Verzeichnisse und für .htaccess-Dateien. Wenn Sie mod_rewrite zum ersten Mal verwenden, empfiehlt sich als Lektüre der „URL Rewriting Guide“ unter http://httpd.apache.org/docs-2.0/misc/rewriteguide.html.

Wenn Sie mod_rewrite in SUSE Linux verwenden möchten, aktivieren Sie das Modul mit YaST (siehe Module) oder manuell in /etc/sysconfig/apache2.