Apache Webserver 2 (2. aktualisierte Auflage) - *ISBN 3

Apache Webserver 2 (2. aktualisierte Auflage) - *ISBN 3
Apache Webserver 2
Open Source Software wird gegenüber kommerziellen Lösungen immer wichtiger.
Addison-Wesley trägt dieser Entwicklung Rechnung mit den Büchern der Open Source
Library. Administratoren, Entwickler und User erhalten hier professionelles Know-how,
um freie Software effizient einzusetzen. Behandelt werden sowohl Themen wie Betriebssysteme, Netzwerke und Sicherheit als auch Programmierung.
Eine Auswahl aus unserem Programm:
Auf Basis der Java-Technologie lassen sich mit dem StrutsFramework einfach und schnell komplexe, dynamische
Websites entwickeln. Dieses Buch gibt einen grundlegenden Einstieg in die Welt der Web-Applikations-Entwicklung. Zahlreiche anschauliche und gut nachvollziehbare
Beispiele erläutern die Features des Frameworks und
führen schnell zum Erfolg.
Kevin Bedell, James Turner
Struts
ISBN 3-8273-2113-1
480 Seiten, 1 CD
Euro 44,95 (D), Sfr 74,50
Ralf Spenneberg beschreibt nach den Grundlagen der
Thematik (Kryptographie, Protokolle, Key-Management,
Netzwerkstrukturen) die Praxis von Konfiguration und
Betrieb eines VPN mit FreeS/wan (für Kernel 2.4) und
Kernel IPsec (für Kernel 2.6). Anschließend behandelt der
Autor Fragen der fortgeschrittenen VPN-Konfiguration
wie den Einsatz in heterogenen Netzen, Bandbreiten-Kontrolle, NAT-Traversal, Kooperation mit anderen (nicht IP-)
Protokollen und die dynamische Adressvergabe mit
DHCP über das VPN.
Ralf Spenneberg
VPN mit Linux
ISBN 3-8273-2114-X
450 Seiten, 1 CD
Euro 49,95 (D), sFr 79,95
Sebastian Wolfgarten
Apache Webserver 2
Installation, Konfiguration, Programmierung
2., aktualisierte Auflage
eBook
Die nicht autorisierte Weitergabe dieses eBooks
an Dritte ist eine Verletzung des Urheberrechts!
An imprint of Pearson Education
München • Boston • San Francisco • Harlow, England
Don Mills, Ontario • Sydney • Mexico City
Madrid • Amsterdam
Die Deutsche Bibliothek – CIP-Einheitsaufnahme
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen
Nationalbibliografie; detaillierte bibliografische Daten sind im Internet
über http://dnb.ddb.de abrufbar.
Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz
veröffentlicht.
Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.
Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen.
Trotzdem können Fehler nicht vollständig ausgeschlossen werden.
Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine
juristische Verantwortung noch irgendeine Haftung übernehmen.
Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.
Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in
elektronischen Medien.
Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.
Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig
auch eingetragene Warenzeichen oder sollten als solche betrachtet werden.
Umwelthinweis:
Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.
10 9 8 7 6 5 4 3 2 1
06 05 04
ISBN 3-8273-2118-2
© 2004 by Addison-Wesley Verlag,
ein Imprint der Pearson Education Deutschland GmbH
Martin-Kollar-Straße 10–12, D-81829 München/Germany
Alle Rechte vorbehalten
Einbandgestaltung: Marco Lindenbeck, [email protected]
Fachlektorat: Ralf Eichinger, München
Lektorat: Sylvia Hasselbach, [email protected]
Korrektorat: Elke Koerschgens, Niederkassel; Sandra Gottmann, Bonn
Herstellung: Monika Weiher, [email protected]
Satz: reemers publishing services gmbh, Krefeld, www.reemers.de
Druck: Bercker Graphischer Betrieb, Kevelaer
Printed in Germany
Inhaltsverzeichnis
1
Vorwort
17
Apache-Grundlagen
19
1.1 Apache
19
1.2 Vergleich Apache 1.3.x vs. 2.x
20
1.2.1
Verschiedene Laufzeitmodelle
1.2.2
Apache Portable Runtime
21
1.2.3
Multi Processing Modules
21
1.2.4
Neues Build-System
22
1.2.5
Multi-Protokoll-Unterstützung
22
1.2.6
Neues Apache API
22
1.2.7
IPv6
22
1.2.8
Ein- und Ausgabefilter
22
1.2.9
Mehrsprachige Fehlermeldungen
23
1.2.10 Vereinfachte Konfiguration
23
1.2.11 Native Windows NT Unicode-Unterstützung
23
1.2.12 Bibliothek für reguläre Ausdrücke aktualisiert
24
1.3 Migration Apache 1.x auf 2.x
1.3.1
Änderungen an der Installation
24
24
1.3.2
Änderungen an der Laufzeitkonfiguration
24
1.3.3
Weitere Änderungen
25
1.3.4
Module von Drittanbietern
25
1.3.5
Fazit
26
1.4 Funktionsweise des Apache
2
20
26
1.4.1
Apache 1.3.x
26
1.4.2
Apache 2.x
28
Installation
35
2.1 Bezug der Software
35
2.2 Inhalte der Quellen
36
2.3 Grundinstallation unter Unix/Linux
37
2.4 Installation mit fertigen Paketen
45
2.4.1
Installation per RPM
45
2.4.2
Installation mit Debian .deb Paketen
46
2.4.3
Installation mit vorkompilierten Paketen
47
6
Inhaltsverzeichnis
2.5 Installation des Apache 2 unter Gentoo Linux
2.5.1
Aktualisierung des Systems
48
2.5.2
Installation des Apache 2
49
2.6 Installation des Apache 2 unter SuSE
2.6.1
51
Installation
51
2.7 Installation unter (Free-) BSD
53
2.7.1
Aktualisierung der Ports-Sammlung unter FreeBSD mit CVSup
54
2.7.2
Installation von Software mit der FreeBSD Ports-Sammlung
55
2.7.3
Deinstallation von einer Software mit der Ports-Sammlung
57
2.7.4
Installation des Apache 2 mit der Ports-Sammlung
58
2.8 Installation unter Sun Solaris
60
2.8.1
Installation von wget und gunzip
60
2.8.2
Installation des Compilers gcc
60
2.8.3
Autoconf
62
2.8.4
Libtool
62
2.8.5
Manuelle Kompilierung und Installation des Apache 2
unter Sun Solaris
63
2.9 Installation unter Microsoft Windows
2.9.1
Installation des Apache 2 unter Windows
64
64
2.9.2
Kompilierung des Apache 2 unter Microsoft Windows
68
2.9.3
SSL unter Windows
73
2.10 Apache für absolute Anfänger (XAMPP)
3
48
78
2.10.1 Installation unter Linux (LAMPP)
78
2.10.2 Installation unter Windows (WAMPP)
80
Erweiterte Installation
3.1 Anpassung der Installationspfade
3.1.1
Erstellung eines eigenen Installationslayouts
3.2 Benutzerdefinierte Installation unter Unix/Linux
3.3 Modulübersicht
83
83
92
93
110
3.3.1
Standardmodule
110
3.3.2
Module von Drittanbietern
113
3.3.3
Empfohlene Module
118
3.4 ./configure bis zum Abwinken
3.4.1
Fallbeispiele
122
122
Inhaltsverzeichnis
7
3.5 Installation diverser Zusatzsoftware unter Unix/Linux
3.5.1
Installation von GNU Bison (optional, u.a. für PHP benötigt)
125
3.5.2
Installation von GNU Flex (optional, u.a. für PHP benötigt)
125
3.5.3
Installation von GNU GDBM
(optional, u.a. für PostgreSQL benötigt)
126
3.5.4
Installation von LibNCurses (optional, u.a. für
Kernelkonfiguration und LibReadline benötigt)
126
3.5.5
Installation von FreeType (optional, u.a. für PHP benötigt)
127
3.5.6
Installation von zlib (optional, u.a. für PHP und
GD-Lib benötigt)
128
3.5.7
Installation von JPEGSrc (optional, u.a. für PHP benötigt)
129
3.5.8
Installation von LibPNG (optional, u.a. für PHP und
GD-Lib benötigt)
130
Installation von GD-Lib (optional, u.a. für PHP benötigt)
131
3.5.9
3.5.10 Installation der LibTiff (optional, u.a. für PHP und
PDFLib benötigt)
132
3.5.11 Installation der PDFLib (optional, u.a. für PHP benötigt)
133
3.5.12 Installation von GhostScript (optional)
134
3.6 Apache 2 in einer Chroot-Umgebung
Grundinstallation des Apache 2
136
3.6.2
Einrichtung der Chroot-Umgebung
137
3.6.3
Konfiguration des Apache und Test der Chroot-Umgebung
142
3.6.4
Abschlussarbeiten
143
144
3.7.1
Installation
145
3.7.2
Konfiguration
147
3.7.3
Praxisbeispiel
149
3.8 Updates
5
135
3.6.1
3.7 Metux MPM
4
125
Betrieb
152
155
4.1 Starten/Stoppen des Apache unter Unix/Linux
155
4.2 Starten/Stoppen des Apache unter Microsoft Windows
160
Konfiguration
165
5.1 Einleitung
165
5.1.1
Begriffsdefinition
165
5.1.2
Konfigurationsdateien
166
5.1.3
Syntax der Konfigurationsanweisungen
167
5.1.4
Kommentare
168
8
Inhaltsverzeichnis
5.1.5
Mehrzeilige Anweisungen
169
5.1.6
Aufteilung auf mehrere Konfigurationsdateien
169
5.1.7
Kontexte
170
5.2 Basiskonfiguration
171
5.2.1
Serveridentifikation
173
5.2.2
Erweiterte Basiskonfiguration
180
5.2.3
Datei- und Verzeichnisstandorte
204
5.2.4
Benutzer- und Gruppenverwaltung
217
5.2.5
Ressourcenbegrenzung und Prozessmanagement
226
5.2.6
Dateien und Verzeichnisse
245
5.2.7
Aliase und Umleitungen
254
5.2.8
Handler
280
5.2.9
Verzeichnisindizes und Listings
284
5.2.10 Umgebungsvariablen
296
5.2.11 Server-Side Includes
305
5.2.12 suEXEC
309
5.3 Fortgeschrittene Konfiguration
311
5.3.1
Virtuelle Server
311
5.3.2
URL-Manipulation mit mod_rewrite
329
5.4 Sonstige Module
370
5.4.1
Der Apache als Proxy-Server (mod_proxy)
370
5.4.2
Auf den Client zugeschnittene Verarbeitung
(mod_negotiation)
385
Einfügen von definierten Inhalten in Antwortseiten
(mod_injection)
393
5.4.4
Der Umgang mit verschiedenen Dateitypen (mod_mime)
398
5.4.5
Caching von Inhalten (mod_cache)
412
5.4.6
Kontrolle über und Änderung von HTTP-Headern
(mod_headers)
428
5.4.7
Steuerung der Aktualität von Inhalten (mod_expires)
432
5.4.8
Serverseitige Unterstützung von Image-Maps
435
5.4.9
Aufzeichnung des Userverhaltens mit Cookies
(mod_usertrack)
438
5.4.3
5.4.10 Änderung des Zeichensatzes von Antwortseiten
(mod_charset_lite)
442
5.4.11 Emulation der CERN HTTPD-Metdatei-Semantik
(mod_cern_meta)
445
5.4.12 Multiprotokoll-Unterstützung: Das echo-Beispiel-Modul
(mod_echo)
447
5.4.13 Auslieferung einer Zufallsdatei mit mod_variety
449
Inhaltsverzeichnis
6
9
Logging
453
6.1 Logdateien
6.1.1
ErrorLog
455
6.1.2
LogLevel
458
6.1.3
CustomLog
460
6.1.4
LogFormat
462
6.1.5
TransferLog
464
6.1.6
CookieLog
466
6.2 Formatierung der Logdatei-Einträge
6.2.1
Sinnvolle Logdatei-Formate
467
472
6.3 Mehrere Logdateien
472
6.4 Konditionelle Protokollierung
473
6.5 Logdatei-Rotation
476
6.5.1
rotatelogs
477
6.5.2
cronolog
478
6.5.3
Logdatei-Umleitung (Piped Logs)
480
6.6 Logdateien der virtuellen Server
481
6.7 Weitere Logdateien
482
6.7.1
RewriteLog
482
6.7.2
RewriteLogLevel
483
6.7.3
ScriptLog
483
6.7.4
ScriptLogLength
484
6.7.5
ScriptLogBuffer
484
6.8 Logdatei-Auswertung
7
453
485
6.8.1
Webalizer
485
6.8.2
Kostenpflichtige Alternative: WebTrends für Windows
490
6.8.3
Alternativen
492
6.8.4
Echtzeitanzeige von Logdateien mit mod_view
493
Serverseitige Programmierung
7.1 Common Gateway Interface (CGI)
497
497
7.1.1
Sicherheit von CGI-Skripten
499
7.1.2
mod_cgid
500
7.2 Perl
7.2.1
501
Installation unter Unix
501
7.2.2
Installation unter Windows
502
7.2.3
mod_perl
504
10
Inhaltsverzeichnis
7.3 Servlets
507
7.3.1
Installation eines Java Development Kits (optional)
507
7.3.2
Java (Tomcat) unter Unix/Linux
508
7.3.3
Java (Tomcat) unter Microsoft Windows
511
7.4 PHP
515
7.4.1
CGI-Variante unter Unix/Linux
7.4.2
DSO-Variante unter Unix/Linux
523
7.4.3
Installation unter Microsoft Windows
527
7.4.4
Konfiguration (php.ini)
536
7.5 Nutzung von C++ mit mod_cplusplus
515
541
7.5.1
Installation
541
7.5.2
Konfiguration
542
7.6 ASP.NET mit mod_mono
547
7.6.1
Vorbereitung
547
7.6.2
Installation von mono
548
7.6.3
Installation von mod_mono
549
7.6.4
Installation von xsp
551
7.6.5
Konfiguration
553
7.6.6
Probleme
555
7.7 mod_ruby
555
7.7.1
Installation von ruby
556
7.7.2
Installation von eruby
556
7.7.3
Installation von mod_ruby
557
7.7.4
Konfiguration
557
7.8 Apache spricht Python mit mod_python
559
7.8.1
Installation von Python
559
7.8.2
Installation von mod_python
560
7.8.3
Konfiguration und Test von mod_python
561
7.9 Ein- und Ausgabefilter
562
7.9.1
Kompressionsfilter (mod_deflate)
569
7.9.2
Entwicklung von eigenen Filtern
572
7.10 Erweiterung der Funktionalität mit mod_isapi
583
7.10.1 Unterstützte Serverfunktionen
587
7.10.2 Entwicklung einer ISAPI-Anwendung mit Borland Delphi 6
588
7.11 Programmierung von eigenen Modulen:
Das Beispiel-Modul (mod_example)
592
Inhaltsverzeichnis
8
11
Datenbanken und LDAP
8.1 MySQL
595
8.1.1
Installation unter Unix
595
8.1.2
Installation unter Microsoft Windows
599
8.2 PostgreSQL
8.2.1
Installation von PostgreSQL (optional)
8.3 Authentifizierung gegen LDAP-Verzeichnisdienste
600
600
605
8.3.1
Vorbereitung
605
8.3.2
Installation von OpenLDAP
605
8.3.3
Konfiguration
606
8.3.4
Start von OpenLDAP und Erzeugung der eigenen Population 610
8.3.5
Installation des Apache 2 mit LDAP-Unterstützung
612
8.3.6
Beispielkonfiguration des Apache
613
8.3.7
Apache, LDAP und SSL
613
8.4 Optimierung von Zugriffen auf LDAP-Server (mod_ldap)
9
595
Sicherheit
619
9.1 Sicherheitstechnische Optimierung der Standardkonfiguration des Apache
9.1.1
614
Optimierung
9.2 Verwendung von sudo
619
619
624
9.2.1
Installation
625
9.2.2
Konfiguration und Verwendung von sudo
625
9.3 Kommunikationsverschlüsselung
627
9.3.1
Installation von OpenSSL (optional, u.a. für Apache und
PostgreSQL benötigt)
627
9.3.2
Verschlüsselung mit dem SSL/TLS Interface mod_ssl
628
9.3.3
Zertifizierung
630
9.3.4
Konfiguration von mod_ssl
637
9.4 Client- und Benutzerauthentifizierung
665
9.4.1
Verwendung von htpasswd
679
9.4.2
mod_auth_anon
682
9.4.3
mod_auth_dbm
686
9.4.4
mod_auth_digest
688
9.4.5
Authentifizierung mit mod_auth_shadow
693
9.4.6
Authentifizierung mit mod_auth_mysql
694
9.4.7
Authentifizierung mit mod_auth_pam
707
12
Inhaltsverzeichnis
9.4.8
Authentifizierung über LDAP (mod_auth_ldap)
712
9.4.9
Authentifizierung mit Hilfe einer externen Quelle
(mod_auth_external)
724
9.5 Abwehr interner Angriffe
9.5.1
Chroot()-Umgebung für lokale Benutzer
9.6 Abwehr externer Angriffe
9.6.1
735
735
745
Abwehr von bösartigen Anfragen mit mod_fortress
745
9.6.2
Intrusion Detection System (mod_security)
751
9.6.3
Konzeption und Realisierung einer Firewall unter Linux
780
9.6.4
Schutz vor Denial of Service-Attacken durch mod_dosevasive
810
10 Analyse während der Laufzeit
819
10.1 Der Apache erstattet Meldung (mod_status und mod_info)
819
10.2 Analyse eingehender Aufgaben
821
10.2.1 Echtzeitauswertung der aktuellen Zugriffe mit apachetop
821
10.2.2 Debugging mit mod_loopback
823
10.2.3 Vollständige Sicherung des ein- und ausgehenden
Datenverkehrs mit mod_log_data
827
10.2.4 Verzögerung einer Anfrage mit mod_sleep
831
10.3 Analyse ausgehender Daten
10.3.1 Dynamische Syntaxüberprüfung von HTML-Dateien
mit mod_tidy
Anhang
833
833
837
A.1 Reguläre Ausdrücke
837
A.1.1
Allgemeine Grundlagen
837
A.1.2
Metazeichen
838
A.1.3
Beispiele für reguläre Ausdrücke
840
A.2 HTTP-Statuscodes
845
A.2.1
1xx
846
A.2.2
2xx
846
A.2.3
3xx
847
A.2.4
4xx
849
A.2.5
5xx
850
A.3 Umgebungsvariablen
851
A.3.1
Standardumgebungsvariablen
852
A.3.2
Headervariablen
854
A.3.3
Spezielle Variablen
856
Inhaltsverzeichnis
13
A.4 Datumsformatierung mit strftime()
A.4.1
Benutzung der Funktion strftime() in C
A.5 Ein- und Ausgabekanäle
858
859
860
A.5.1
stdin-Eingabekanal
861
A.5.2
stdout-Ausgabekanal
861
A.5.3
stderr-Fehlerausgabekanal
861
A.6 Browserkennungen
861
A.7 Daten auf den Server überspielen
862
A.7.1
Secure Copy (SCP) unter Windows
863
A.8 Installation und Konfiguration eines Nameservers
unter Unix/Linux
865
A.8.1
Installation
866
A.8.2
Konfiguration
866
A.8.3
Erster Start des Nameservers und Test der Zonendateien
871
A.8.4
Erweiterte Konfiguration
874
A.8.5
Das optionale Sahnehäubchen
879
A.9 Webseite zum Buch
881
A.10 Unterstützung und Hilfe
881
A.11 Literaturangaben
884
A.12 Lizenzbestimmungen für den Apache-Webserver
884
Stichwortverzeichnis
889
Dieses Buch ist meiner Familie, meinen Freunden und der
Open Source-Gemeinde gewidmet.
Vorwort
Mehr als zwei Jahre, nachdem ich mit den Arbeiten für dieses Buch begonnen habe
und mehr als ein Jahr, nachdem die sehr erfolgreiche Erstauflage veröffentlicht
wurde, erscheint nun die aktualisierte und stark erweiterte zweite Ausgabe meines
Erstlingswerkes.
Zu Recht werden sich jetzt viele (potentielle) Leser fragen, was die Vorteile der Neuauflage sind und ob es sich wirklich lohnt, in dieses dicke Buch, das ein Stückchen
Software zum Inhalt hat, zu investieren? Wenn man dem 34. Präsident der USA,
Dwight David Eisenhower (1890 – 1969), Glauben schenken darf, dann ist alles, was
nicht auf einer einzigen Manuskriptseite zusammengefasst werden kann, weder durchdacht
noch entscheidungsreif. Insofern finden Sie, geneigter Leser, in diesem Buch knapp 1000
Seiten unnützes und nicht durchdachtes Zeug, welches im Vergleich zur ersten Auflage um weitere 150 Seiten sowie um mehr als 25 neue Kapitel ergänzt worden ist.
Aus meiner Sicht als Autor fällt mir passend dazu ein Spruch des amerikanischen
Schriftstellers Mark Twain (1835 – 1910) ein, der einmal gesagt hat, dass es idiotisch sei,
sieben oder acht Monate an einem Roman zu schreiben, wenn man in jedem Buchladen für
zwei Dollar einen kaufen könne. Warum sollten Sie dieses Buch also kaufen?
Sie finden in der rund 900 Seiten umfassenden zweiten Auflage meines Erstlingswerkes einen detaillierten und praxisnahen Einblick in die Struktur, den Aufbau, die
Installation, die Konfiguration sowie die Erweiterung des Apache 2, der Ihnen hoffentlich den offiziellen Nachfolger der erfolgreichsten Open Source-Software
schmackhaft macht. Ich habe mich daher sehr bemüht, die wenigen Fehlerchen der
Erstauflage, die im Wesentlichen aus Rechtschreibfääählern bestanden zu beseitigen
und weitere interessante Themengebiete (z.B. ASP.NET, LDAP, Ruby, Python, Sicherheit) in der Neuauflage ausführlich zu berücksichtigen und somit einem noch größeren Leserkreis, vom Anfänger bis zum Apache-Guru, gerecht zu werden. Die 25 neu
enthaltenen Kapitel zeugen von diesem Versuch, sollen aber keineswegs Ausdruck
des Wortes: »Gewisse Bücher scheinen geschrieben zu sein, nicht damit man daraus lerne,
sondern damit man wisse, dass der Verfasser etwas gewusst hat.« sein, wie der große deutsche Dichter Johann Wolfgang von Goethe (1749 – 1832) es einmal ausgedrückt hat.
Es geht also in diesem Buch nicht darum, wie viel ich weiß (oder auch nicht), sondern
wie viel Sie von diesem Buch und meinen langjährigen Erfahrungen mit dem Apache
lernen können. Ich versuche, mich deshalb auf einen minimalen Umfang an Theorie
zu beschränken und durch engen Praxisbezug den Lerneffekt für Sie zu maximieren.
Das Buch soll, und dies gilt für die erste und die zweite Auflage gleichermaßen, ein
lockeres und leicht verständliches Werk sein, welches Sie mit einer jugendlichen
Unbeschwertheit in die große, weite Welt des Apache 2 einführt.
Bedenken Sie deshalb und das gilt insbesondere dann, wenn Sie gerade in einer Buchhandlung stehen und einem armen Studenten wie mir unter die Arme greifen wollen,
dass laut Benjamin Franklin (1706 – 1790) eine Investition in Wissen immer noch die besten Zinsen bringt. Na, überzeugt? Klappen Sie das Buch zu, rennen Sie zur Kasse und
kaufen Sie es ;-)
Sebastian Wolfgarten
Stuttgart/Kaarst/Dublin/Frankfurt, im Januar 2004
18
Vorwort
Zielsetzung
Aufgrund der enorm vielen positiven (und sehr wenigen negativen) Resonanzen auf
mein Erstlingswerk habe ich mich mehr als ein halbes Jahr intensiv bemüht, neue und
interessante Inhalte für dieses Buch zu finden und die Inhalte der ersten Auflage zu
aktualisieren. Wie Sie der sehr eigenwilligen Einleitung entnehmen können, handelt
es sich hierbei jedoch nicht um ein gewöhnliches (staubtrockenes) Fachbuch, sondern
um eine (hoffentlich) gelungene, lockere und verständliche Mischung aus Theorie
und Praxis, wobei die Praxis und insbesondere die täglich auftauchenden Probleme
und Herausforderungen im Betrieb eines Webservers stark überwiegen. Ich beschäftige mich seit mehreren Jahren mit dem Apache und hoffe, dass Ihnen die erweiterte
zweite Auflage meines Erstlingswerkes gefällt und hilft. Insbesondere die stark veränderte inhaltliche Struktur soll für mehr Übersichtlichkeit sorgen und berücksichtigt
damit einen Kritikpunkt, der durch einige Leser an mich herangetragen worden ist.
Bei der Auswahl der mehr als 25 neuen Kapitel habe ich versucht, ein möglichst breites und vielseitiges Spektrum an Themen zusammen zu stellen, wobei aufgrund meines beruflichen Hintergrunds der Bereich (Webserver-) Sicherheit überwiegt. Nichtsdestotrotz habe ich, ebenso wie in der ersten Auflage probiert, einen möglichst
großen Leserkreis vom Anfänger bis zum Experten anzusprechen. Eventuell gibt es
dabei Passagen, die einen Anfänger verwirren bzw. einen Experten langweilen, aber
ich habe immer einen Mittelweg gesucht (und hoffentlich auch gefunden), um Ihnen
den Ein- oder Umstieg auf den Apache 2 zu ermöglichen. Dabei habe ich übrigens
passend zur Neuauflage unter http://www.apache2-buch.de eine eigene Internetseite
eingerichtet, auf der Sie weitere Informationen zum Apache 2 sowie zu diesem Buch
(Errata, Beispiele, Foren etc.) erhalten. In diesem Sinne wünsche ich Ihnen, lieber
Leser, viel Spaß beim Lesen der zweiten Auflage meines Erstlingswerkes. Ich stehe
Ihnen selbstverständlich jederzeit gerne für Rückfragen und Hilfen per E-Mail
([email protected]) zur Verfügung. Auch über Lob und konstruktive Kritik
würde ich mich sehr freuen.
Danksagung
Die Neuauflage meines Buches wäre ohne die direkte oder indirekte Hilfe vieler Menschen wohl nie erschienen. Deshalb möchte ich mich zuerst bei allen Menschen bedanken, die bei der Entstehung dieses Buches in irgendeiner Form mitgeholfen haben.
Dabei muss ich mich sicherlich zuerst bei meinen Eltern und meinem Bruder Jens
bedanken, die mich im letzten halben Jahr in außergewöhnlichem Maße unterstützt
haben und ohne die dieses Buch niemals fertig geworden wäre.
Abermals gehört ein großer Dank der Lektorin Sylvia Hasselbach, die sich wieder in
besonderer Weise für dieses Buch eingesetzt hat. Zusätzlich möchte ich mich für ihre
enorme Geduld und ihren massiven Einsatz bedanken, der auch nach der x-ten Verschiebung des Abgabetermins nicht geschrumpft ist. Dem Fachlektor Ralf Eichinger
gebührt ebenfalls ein großes Dankeschön, denn erst durch seine penible Überarbeitung und Kontrolle meines Werkes ist es zu dem geworden, was es ist.
Schließlich möchte ich mich bei der Firma SuSE und dort besonders bei Herrn Peter
Poeml sowie bei der Firma RedHat bedanken, die mir freundlicherweise jeweils eine
Kopie ihrer Linux-Distribution zur Verfügung gestellt haben.
1 Apache-Grundlagen
1.1
Apache
Der Apache ist ein freier und kostenloser HTTP (Web-)Server, der inzwischen mit
einem Marktanteil von gut 67% (http://www.netcraft.com/survey/, Stand: November
2003) weltweiter Marktführer auf diesem Gebiet ist und als das Vorzeigeprojekt der
Open Source-Gemeinde gilt. Entstanden ist der Apache Anfang 1995, nachdem der
Entwickler des seinerzeit populärsten HTTP-Servers NCSA-HTTPD, Rob Mc Cool
(der hieß wirklich so) beschlossen hatte, andere Wege zu gehen und die Entwicklung
seines bereits weitverbreiteten HTTP-Servers einzustellen. Eine kleine Gruppe von
Anwendern begann damit, die Software mittels kleiner Erweiterungen und Fehlerbereinigungen (so genannter Patches) zu erweitern, und formte so nach und nach einen
gepatchten Server, woraus im Laufe der Zeit der Name Apache (a patchy server) entstand. Im April 1995 erfolgte die Veröffentlichung der ersten Version (0.6.2), die die
Version 1.3 des HTTPd von Rob Mc Cool als Basis benutzte. Am 1. Dezember 1995
erfolgte die Veröffentlichung der Version 1.0 des Apache, die neben einer Reihe von
neuen Funktionen (u.a. geändertes Laufzeitverhalten) und Verbesserungen von
Grund auf neu geschrieben worden war. In einem Zeitraum von weniger als einem
Jahr überholte der Apache den seinerzeit am häufigsten eingesetzten Webserver
HTTPd von Rob Mc Cool und ist seitdem unangefochten die am häufigsten eingesetzte Software für Webserver. Das Erfolgsrezept des Apache liegt insbesondere in
der außerordentlich guten Dokumentation und in einem modularen Konzept, welches die problemlose Erweiterung des Servers mittels externer Module ermöglicht.
Diverse Versionen erscheinen in unregelmäßigen Abständen (momentan aktuell
1.3.29 bzw. 2.0.48) und die Verbreitung des Apache erreichte im Januar 2004 ihren
vorläufigen Höhepunkt mit einem Verbreitungsgrad von 67,43%.
Die ersten Grundsteine für den Apache 2 wurden im Sommer 1996 gelegt, als die Idee
entstand, den Apache um Filter sowie Multithreading-Fähigkeiten zu erweitern. Ein
halbes Jahr später entstanden außerdem Pläne für eine plattformunabhängige und
vom Betriebssystem losgelöste Bibliothek (heutzutage Apache Portable Runtime), die
die elementare Grundlage des Apache 2 liefern sollte. Im Jahr 1999 begannen die ersten Entwicklungen für den Apache 2, die im Januar 2000 dazu führten, dass sich die
Entwickler nur noch auf den Apache 2 konzentrierten und die funktionale Weiterentwicklung der alten Version 1.3 stoppten. Nach nunmehr dreijähriger Entwicklungszeit erschien im April 2002 die langersehnte Version 2.0.35 des Apache, die genug
Neuerungen und Erweiterungen mit sich brachte, um ein ganzes Buch zu füllen (wie
Sie sehen können). Momentan (Februar 2004) gilt die Version 2.0.48 als die beste und
stabilste Version des Apache. Für die Leser, die bereits Erfahrungen mit der alten Version 1.3.x des Apache haben, folgt nun ein Vergleich zwischen beiden Versionen.
20
1.2
1 Apache-Grundlagen
Vergleich Apache 1.3.x vs. 2.x
Im April 2002 erreichte die erste Version des Apache 2.0.x einen stabilen Status und
wird seitdem erfolgreich unter http://www.apache.org eingesetzt. Seit diesem Zeitpunkt
stehen diverse Versionen zum allgemeinen Einsatz bereit. Leider ist jedoch seitens
der Anwender dem Apache 2 bisher zu Unrecht sehr wenig Interesse entgegengebracht worden, http://www.netcraft.com nennt im Juli 2002 nur knapp 50.000 Server,
auf denen Apache 2 weltweit eingesetzt wird (Apache 1.3.x: 10 Millionen!). Die
renommierten Experten von netcraft.com vermuteten seinerzeit eine fehlende Unterstützung für viele Third-Party Modules, was sicherlich einige Anwender von einer
Migration abgehalten hat. Eventuell greift hier auch die alte SystemadministratorMaxime Never change a running system, aber die Neuerungen, die der Apache 2 bietet,
sind derart tiefgehend, dass sie erst bei genauerem Hinsehen deutlich werden. Sicherlich muss man (noch) zugeben, dass sich der Apache 2 (zumindest teilweise) in einem
experimentellen Status befindet und nur bedingt auf Produktivsystemen zum Einsatz
kommen sollte, aber die dreijährige Entwicklungszeit des Apache 2 hat Früchte getragen, die in der Zukunft sicherlich von einer Vielzahl von Administratoren geerntet
werden. Um Sie etwas auf den Geschmack dieser süßen Früchte zu bringen, möchte
ich Ihnen im Folgenden kurz die Neuerungen des Apache 2 vorstellen.
1.2.1
Verschiedene Laufzeitmodelle
Ein großer Kritikpunkt des Apache 1.3.x ist das statische Laufzeitmodell und die
damit, insbesondere unter Nicht-Unix-Plattformen wie Microsoft Windows, hervorgerufenen Performanceeinbußen gegenüber diversen Konkurrenzprodukten. Die
dem Apache 1.3.x zugrunde liegende Architektur beruht auf der Tatsache, dass es
unter Linux/Unix durch den Befehl fork möglich ist, identische Kopien von bestehenden Prozessen zu erzeugen. Der Apache macht sich dieses Prinzip zu eigen und arbeitet im Gegensatz zu einigen anderen Webservern als so genannter Preforking-Server,
d.h., sofort nach dem Start legt der gestartete Hauptprozess eine in der Konfigurationsdatei festgelegte Anzahl an identischen Kopien (auch Kindprozess genannt) seiner selbst an, die auf eingehende Anfragen warten. Der Server kontrolliert die Anzahl
der Serverprozesse dynamisch während der Laufzeit und kann diese je nach Auslastung und Anzahl der gleichzeitigen Zugriffe flexibel erhöhen oder auch verringern.
Weitere und ausführlichere Informationen sowie ein grafisches Schema des zugrunde
liegenden Modells finden Sie in den Erläuterungen zum Laufzeitverhalten des Apache 1.3.x.
Die fast drei Jahre dauernde Entwicklung der Version 2 des Apache hatte u.a. die
Zielsetzung, Portierungen auf andere Plattformen zu erleichtern und damit eine noch
weitere Verbreitung des Apache zu ermöglichen. Deshalb ist die saubere Trennung
von plattformspezifischem Code eines der obersten Ziele der Entwickler gewesen, da
der Umfang sowie die weitgehende Verbreitung des Apache eine Portierung auf
viele, höchst unterschiedliche Plattformen erforderte. Gleichzeitig sollten Entwickler
eine standardisierte Schnittstelle zur Verfügung gestellt bekommen, die ihnen die
betriebssystemunabhängige Entwicklung von Erweiterungen für den Apache ermöglicht. Ein Entwickler sollte nicht unbedingt wissen müssen, welche speziellen Gege-
1.2 Vergleich Apache 1.3.x vs. 2.x
21
benheiten auf einer bestimmten Betriebssystemplattform herrschen und ihm eventuell Probleme bereiten könnten. Er sollte in der Lage sein, unabhängig von dem
zugrunde liegenden Betriebssystem allein durch seine bereits vorhandenen Programmierkenntnisse eine Erweiterung für den Apache zu schreiben, die auf eine gemeinsame Bibliothek und Schnittstelle aufsetzt und auf allen Betriebssystemen gleichermaßen und ohne Änderungen funktioniert. Das Ergebnis dieser Überlegungen und
Anstrengungen der Entwickler des Apache heißt:
1.2.2
Apache Portable Runtime
Die Entwickler des Apache 2 haben alle betriebssystem-abhängigen Funktionen in
eine gemeinsame und betriebssystemunabhängige Bibliothek namens Apache Portable
Runtime (APR) ausgelagert. Durch die Einführung dieser so genannten Apache Portable Runtime (APR), die als Schnittstelle zwischen dem jeweiligen Betriebssystem und
dem Kern des Apache 2 fungiert, können die Entwickler auf eine plattformunabhängige Bibliothek zurückgreifen, die ihnen einen standardisierten und betriebssystemunabhängigen Zugriff auf grundlegende Funktionen eines Betriebssystems (u.a.
Datei- und Netzwerkfunktionen, Zeit, Speicherverwaltung, Thread- und Prozessverwaltung etc.) zur Verfügung stellt, ohne dass diese sich mit den speziellen Gegebenund Besonderheiten einer einzelnen Plattform auseinander setzen müssen. Weitere
Informationen sowie eine grafisches Schema finden Sie in den Erläuterungen zum
Apache 2.x. Einen Überblick über den Stand der Entwicklung der Apache Portable
Runtime erhalten Sie unter http://apr.apache.org/.
1.2.3
Multi Processing Modules
Eine weitere, sehr wichtige Neuerung im Apache 2.x ist die Einführung von so
genannten Multi Processing Modules (MPM), einer speziellen Sorte von Modulen, in
die der Teil des Quellcodes ausgelagert worden ist, der für das Laufzeitverhalten verantwortlich ist. Dabei kann der Apache sich spezielle Fähigkeiten des jeweils
zugrunde liegenden Betriebssystems zunutze machen und entweder als prozessbasierender oder thread-basierender Server agieren. Auch die Kombination aus beiden Laufzeitverhalten ist in einem so genannten Hybrid-Modus möglich. Die Funktion eines MPM ist die für das jeweils genutzte Betriebssystem optimale Abbildung
von eingehenden Clientanfragen auf einfache Ausführungseinheiten (Prozesse oder
Threads), die diese Anfragen verarbeiten. Diese Modularisierung eines Teils des Apache bringt somit einen deutlich klarer strukturierten Quellcode und ermöglicht die
Entwicklung und Verwendung von plattformspezifischen Optimierungen und
Erweiterungen, die eine exklusive Nutzung eines MPM auf ein bestimmtes, optimiertes Betriebssystem erzwingen können. Insbesondere auf Nicht-Unix-Betriebssystemen ist somit ein großer Geschwindigkeits- und Performancegewinn möglich, da auf
diesen Plattformen nicht mehr versucht wird, das Verhalten des Apache unter Unix
nachzuahmen, sondern die Möglichkeiten des jeweiligen Betriebssystems optimal zu
nutzen. Gerade unter Microsoft Windows ist mit dem MPM_winnt ein Multi Processing Module verfügbar, welches als stabil und in punkto Stabilität und Geschwindigkeit als echte Alternative zum direkten Konkurrenten, dem Microsoft Internet Infor-
22
1 Apache-Grundlagen
mation Server, bezeichnet werden kann. Es benutzt native Windows-API-Funktionen
und die Verwendung der fehlerbehafteten und schlecht funktionierenden POSIXEmulation-Layer wird endgültig vermieden. Dadurch erhöht sich ebenfalls die allgemeine (Netzwerk-) Geschwindigkeit des Apache unter Windows. Unter Unix/Linux
existieren mehrere MPMs, die alle eine andere Strategie verfolgen, um die eingehenden Clientanfragen zu verarbeiten. Der Administrator hat nun die Qual der Wahl und
muss das für seinen Anwendungsbereich passende MPM aussuchen und fest in den
Apache kompilieren. Auf die Vor- und Nachteile der einzelnen Multi Processing
Modules (MPM) werde ich im Laufe dieses Buches noch näher eingehen.
1.2.4
Neues Build-System
Das Installationssystem des Apache wurde komplett neu entwickelt und basiert nun,
wie viele andere Programme auch, auf libtool und autoconf. Dadurch wird die Installation des Apache vereinfacht und der Installation anderer Open Source-Programme
angepasst.
1.2.5
Multi-Protokoll-Unterstützung
Sicherlich ein sehr interessantes Feature des Apache 2 ist, dass dieser die notwendigen Grundfunktionalitäten durch die Apache Portable Runtime bereitstellt, um neben
dem HTTP- auch weitere Protokolle zu verarbeiten. Der Apache stellt praktisch ein
Framework (Rahmensystem) für einen Server zur Verfügung und es existieren mit
mod_echo, mod_pop3 und mod_ftp bereits erste Referenzimplementationen.
1.2.6
Neues Apache API
Die komplette Programmierschnittstelle (Application Programming Interface) des
Apache hat sich sehr stark verändert und bietet nun durch die Apache Portable Runtime ein standardisiertes Framework für den Zugriff auf systemunabhängige Funktionen. Leider funktionieren dadurch die für die Version 1.3.x des Apache vorhandenen Module nicht ohne Änderungen unter dem Apache 2!
1.2.7
IPv6
Sofern das dem Server zugrunde liegende Betriebssystem IPv6 unterstützt, unterstützt der Apache 2 den neuen Standard IPv6 vollständig. Weiterhin bleibt selbstverständlich die IPv4-Unterstützung erhalten.
1.2.8
Ein- und Ausgabefilter
Sicherlich ein Killer-Feature ist die Einführung von Filtern, die Daten lesen und verändern können, bevor diese an den Server oder Client gesendet werden. Das Buch
beschreibt die Implementation solcher Filter ausführlich und zeigt in mehreren praktischen Beispielen, wie mächtig Filter sein können. Dazu gehört z.B. ein dynamischer
PDF-Konvertierungsfilter, der die Daten ins weitverbreitete PDF-Format konvertiert,
1.2 Vergleich Apache 1.3.x vs. 2.x
23
bevor diese vom Server an den Client gesendet werden. Das Schema verdeutlicht den
Sinn und Zweck von Filtern im Apache 2:
Eingabefilter können eingehende
Anfragen filtern, noch bevor diese durch
andere Module des Apache verarbeitet
werden können.
Eingabefilter
Internet
Client
Nach der Verarbeitung
durch den Eingabefilter wird
die Anfrage an den Kern
des Apache sowie die
nachgelagerten Module
weitergegeben.
Apache 2
Prinzipiell können Filter die ein- und
ausgehenden Daten beliebig (z. B.
durch Ausführung eines externen
Programmes) verändern oder
manipulieren.
Ausgabefilter
Auch die Antworten des Apache auf
vorherige Anfragen von Clients können,
bevor diese endgültig an den jeweiligen
Client gesendet werden, durch so
genannte Ausgabefilter gefiltert werden.
Abbildung 1.1 Ein- und Ausgabefilter im Apache 2
1.2.9
Mehrsprachige Fehlermeldungen
Die durch den Server im Falle eines server- oder clientseitig aufgetretenen Fehlers
dargestellten Fehlermeldungen sind nun endlich in mehrsprachigen Varianten (u.a.
Englisch, Deutsch, Französisch, Spanisch, Italienisch, Dänisch, Polnisch etc.) verfügbar. Je nach Spracheinstellung des Browsers erhält ein Client direkt die für seine Einstellungen optimierte Variante einer Fehlermeldung.
1.2.10 Vereinfachte Konfiguration
Die Konfiguration des Apache hat sich vereinfacht, da viele funktional ähnliche
Anweisungen, die oft vertauscht oder verwechselt wurden, sauber voneinander
getrennt worden sind. Insgesamt hat die Anzahl der Konfigurationsanweisungen von
knapp 210 auf etwa 300 Stück jedoch deutlich zugenommen!
1.2.11 Native Windows NT Unicode-Unterstützung
Unter Windows NT-basierten Versionen des Windows-Betriebssystems verwendet
der Apache 2.0 jetzt utf-8 für alle Dateinamen-Kodierungen. Diese werden direkt auf
das zugrunde liegende Unicode-Dateisystem abgebildet, wodurch MehrsprachUnterstützung für alle Windows NT-basierten Varianten (Windows 2000, NT, XP)
möglich wird. Unter Windows 95, 98 oder ME ist diese nicht verfügbar, so dass hier
die lokale Codepage des jeweiligen Rechners für den Zugriff auf das Dateisystem verwendet wird.
24
1 Apache-Grundlagen
1.2.12 Bibliothek für reguläre Ausdrücke aktualisiert
Der Apache 2 beinhaltet die so genannte Perl Compatible Regular Expressions-Bibliothek von http://www.pcre.org/ und verwendet daher bei der Auswertung von regulären Ausdrücken die leistungsfähigere Syntax von Perl 5.
1.3
Migration Apache 1.x auf 2.x
Die Migration vom Apache 1.3.x auf den Apache 2.x ist eine Aufgabe, die nicht zwischen Tagesschau und Wetterkarte bewältigt werden kann. Zahlreiche Änderungen
am Design sowie an der Installation und Konfiguration des Servers erfordern eine
intensive Auseinandersetzung mit der neuen Version. Konkret haben sich u.a. folgende Änderungen ergeben:
1.3.1
Änderungen an der Installation
Die Vorbereitung der Installation des Apache basiert inzwischen, wie bei vielen Open
Source-Programmen auch, auf Autoconf und Libtool. Dabei entspricht die Verwendung dieses Systems teilweise dem in der Version 1.3 verwendeten APACI-System,
sie ist aber eben nicht identisch. Die wichtigste Neuerung ist die Verfügbarkeit von
mehreren Laufzeitmodellen, unter denen der Administrator ein Modell auswählen
und fest in den Server einkompilieren muss.
1.3.2
Änderungen an der Laufzeitkonfiguration
Viele Konfigurationsanweisungen wurden aus dem Kernmodul mod_core herausgenommen und sind in der Version 2 des Apache in den verschiedenen Laufzeitmodulen (engl. multi processing modules, MPMs) enthalten. Das Laufzeitverhalten des Apache 1.3.x wird durch ein MPM namens Prefork fast identisch abgebildet.
Das Proxymodul wurde überarbeitet und beherrscht jetzt komplett den HTTP/1.1Standard. Die entsprechenden Anweisungen wurden umbenannt und sind nicht
mehr innerhalb eines <Directory proxy:>-Abschnitts in der Konfigurationsdatei des
Apache enthalten, sondern in einem eigenen <Proxy>-Abschnitt.
Eine weitere Neuerung des Apache 2 ist die Behandlung von PATH_INFO (hinter
dem tatsächlichen Dateinamen angefügte Pfadangaben), da diese für einige Module
geändert worden ist. So akzeptieren Module, die früher als Handler implementiert
waren, inzwischen jedoch als (Ausgabe-)-Filter implementiert sind, möglicherweise
keine Requests mit PATH_INFO mehr. Filter wie INCLUDES sind direkt im CoreHandler implementiert und weisen deshalb Requests mit PATH_INFO ab. Sie können
die AcceptPathInfo-Direktive verwenden, um den Core-Handler zu zwingen,
Requests mit PATH_INFO zu akzeptieren, und dadurch die Fähigkeit wiederherstellen, PATH_INFO in Server Side Includes zu benutzen.
1.3 Migration Apache 1.x auf 2.x
25
Die CacheNegotiatedDocs-Anweisung besitzt jetzt als Parameter nur noch an (on) oder
aus (off). Ebenso muss eine in der ErrorDocument-Anweisung erstellte Nachricht zu
Beginn und zum Abschluss von Anführungszeichen eingeschlossen werden. Endgültig sind außerdem die Anweisungen AccessConfig, ResourceConfig, BindAddress, ServerType und Port entfallen. Äquivalente Funktionalitäten werden u.a. durch die Listenund Include-Anweisung bereitgestellt. Im Apache 1.3 wurde die Port-Direktive außerdem dazu verwendet, die Portnummer für selbst referenzierende URLs festzulegen.
Die neue ServerName-Syntax wurde dahingehend verändert, dass diese sowohl den
Hostnamen als auch die Portnummer für selbstreferenzierende URLs akzeptiert.
Die Module mod_log_agent und mod_log_referer, welche die Direktiven AgentLog, RefererLog und RefererIgnore bereitgestellt haben, wurden entfernt. Durch Verwendung
der Direktive CustomLog aus mod_log_config sind die Agent- und Refererlogs auch weiterhin verfügbar.
Die Direktiven AddModule und ClearModuleList sind entfallen. Diese Direktiven wurden benutzt, um sicherzustellen, dass die Module in der richtigen Reihenfolge aktiviert werden können. Die neue Apache 2.0 API erlaubt es Modulen, ihre Reihenfolge
explizit anzugeben, und macht diese Direktiven damit überflüssig.
Die Direktive FancyIndexing wurde entfernt und ist in ähnlicher Form mit der Option
FancyIndexing der Direktive IndexOptions verfügbar.
1.3.3
Weitere Änderungen
Die httpd-Kommandozeilenoption -S, die dazu verwendet wurde, die VirtualHostKonfiguration auszugeben, wurde durch -t -D DUMP_VHOSTS ersetzt. Allgemein
hat sich die Syntax einiger Anweisungen verändert bzw. ist aufgrund zahlreicher
Anregungen und Vorschläge der Benutzer des Apache angepasst worden.
Das Modul mod_auth_digest, das im Apache 1.3 experimentellen Status hatte, ist nun
ein Standardmodul. Ebenso wurde das Modul mod_mmap_static durch das Modul
mod_file_cache ersetzt.
Die Distribution wurde komplett reorganisiert und enthält kein unabhängiges srcVerzeichnis mehr. Stattdessen wurden die Quellcodes logisch unterhalb des Hauptverzeichnisses der Distribution angeordnet. Die Installationen des kompilierten Servers sollten in ein separates Verzeichnis erfolgen.
1.3.4
Module von Drittanbietern
Aufgrund der tiefgreifenden Änderungen an der Programmierschnittstelle des Apache funktionieren für den Apache 1.3.x entwickelte Module nicht ohne Modifikationen mit der Version 2.x des Apache. Die Kernmodule des Apache sind soweit für die
Version 2 verfügbar und auch für einige Drittanbietermodule gibt es bereits dedizierte Versionen für die neue Version des Apache. Leider sind einige Module von
Drittanbietern momentan (Februar 2004) teilweise noch nicht für den Apache 2 verfügbar bzw. befinden sich zurzeit noch in der Entwicklung.
26
1.3.5
1 Apache-Grundlagen
Fazit
Kurz und schmerzlos: Vergewissern Sie sich, dass die von Ihnen verwendeten
Module auch für den Apache 2 verfügbar sind, erstellen Sie ein Backup Ihrer vorhandenen Daten installieren Sie den Apache in der Version 2 komplett neu! Benutzen Sie
dazu kein Produktivsystem, sondern einen Entwicklungsserver oder verwenden Sie
für den Apache 2 einen separaten Bereich auf dem Server mit eigener Portnummer
(z.B. 8080). Vergewissern Sie sich außerdem, dass das von Ihnen verwendete Laufzeitverhalten (MPM) für Ihr Betriebssystem als stabil gekennzeichnet ist (siehe
http://httpd.apache.org/docs-2.0/mod/) und lesen Sie dieses Buch :-)
1.4
Funktionsweise des Apache
1.4.1
Apache 1.3.x
Die dem Apache 1.3.x zugrunde liegende Architektur beruht auf der Tatsache, dass es
unter Linux/Unix durch den Befehl fork möglich ist, identische Kopien von bestehenden Prozessen zu erzeugen. Die Manpage von fork lehrt uns dazu nach Eingabe von
man 2 fork Folgendes:
BEZEICHNUNG
fork, vfork - erzeugt einen Kindprozess
SYNTAX
#include <unistd.h>
pid_t fork(void);
pid_t vfork(void);
DESCRIPTION
fork erzeugt einen Kindprozess, der sich vom Vaterprozess nur durch die PID und
PPID unterscheidet und darin, dass die Verwendung von Ressourcen auf 0 gesetzt
ist. File locks und noch ausstehende Signale werden nicht vererbt.
Unter Linux ist fork unter Benutzung von copy-on-write Seiten implementiert, so
dass der einzige Nachteil von fork die Zeit und der Speicher ist, der benötigt wird,
um den die Page-Tables des Vaterprozesses zu kopieren und einen Task-Record für den
Kindprozess anzulegen.
Der Apache macht sich dieses Prinzip zu eigen und arbeitet im Gegensatz zu einigen
anderen Webservern als so genannter Preforking-Server, d.h. sofort nach dem Start
legt der gestartete Hauptprozess (Vaterprozess) eine in der Konfigurationsdatei festgelegte Anzahl an identischen Kopien (auch Kindprozess genannt) seiner selbst an, die
auf eingehende Anfragen warten. Dabei gibt die Konfigurationsanweisung StartServers die Anzahl der zu startenden Kindprozesse an, wobei der Standardwert bei fünf
liegt. Der Server kontrolliert die Anzahl der Serverprozesse dynamisch während der
Laufzeit und kann diese je nach Auslastung und Anzahl der gleichzeitigen Zugriffe flexibel erhöhen oder auch verringern. Es stehen dafür die Konfigurationsoptionen
MinSpareServers und MaxSpareServers bereit, die die Anzahl der leer laufenden Prozesse kontrollieren. Damit wird versucht, immer eine gewisse Anzahl von Prozessen,
definiert durch die Option MinSpareServers, in Reserve zu haben, um auch auf eine
1.4 Funktionsweise des Apache
27
plötzlich eintretende, sehr hohe Anzahl von gleichzeitigen Clientanfragen reagieren zu
können, ohne dass der Server unter dieser unerwarteten Last zusammenbricht.
Interessanterweise verarbeitet der Server selber nie direkt die Anfragen der Clients,
sondern gibt diese nur an die Kindprozesse ab, die die weitere Be- und Verarbeitung
der Anfragen übernehmen. Der Hauptserverprozess ist durch diese Konstruktion
geschützt, da er niemals direkten Kontakt mit einem Client hat. Dadurch kann der
Hauptprozess, der unter der Kennung des root-Benutzers läuft, ungestört wichtige
Funktionen wie das Einlesen und Auswerten der Konfigurationsdateien oder das
Schreiben von Logdateien übernehmen. Zusätzlich verwaltet der Hauptprozess die
Anzahl der Kindprozesse, die unter der Kennung eines unprivilegierten Systembenutzers (z.B. nobody) laufen. Falls einer dieser Kindprozesse unerwartet beendet
wird oder es zu einem ernsthaften Fehlverhalten kommt, startet der Hauptserverprozess den Kindprozess automatisch neu. Außerdem kann ein Kindprozess nach einer
gewissen Zeit automatisch beendet und neugestartet werden, wenn dieser eine konfigurierbare Anzahl von Anfragen bewältigt hat. Dadurch wird verhindert, dass im
Laufe der Zeit etwa durch ein Fehlverhalten eines Kindprozesses, das beispielsweise
durch einen Programmierfehler in einem externen Modul verursacht worden ist, ein
nicht freigegebener Speicherbereich entsteht und womöglich weiter anwächst, der die
Stabilität und die Funktion des gesamten Servers beeinträchtigen kann.
Der Vorteil dieser Funktionsweise liegt darin, dass das Fehlverhalten eines einzelnen
Kindprozesses die Stabilität des gesamten Servers nicht beeinträchtigen kann. Der
Nachteil dabei ist allerdings eine verminderte Geschwindigkeit bei der Beantwortung
von eingehenden Clientanfragen, da für jeden Kindprozess auch Prozessorzeit durch
das Betriebssystem zur Verfügung gestellt werden muss, und die kaum mögliche
Kommunikation sowie Daten- und Informationsteilung der einzelnen Kindprozesse
untereinander.
Die nachfolgende Grafik (Abb. 1.2) verdeutlicht die Funktionsweise nochmals.
Im krassen Gegensatz zu Linux/Unix ist es unter Windows hingegen nicht möglich,
laufende Prozesse zu kopieren. Mit der Portierung auf die Windows-Plattform ergab
sich nun bei Erscheinen der Version 1.3.x das Problem, dass die oben beschriebene
Preforking-Methode überhaupt nicht mehr möglich war. Infolgedessen war es nötig,
das gesamte Laufzeitverhalten für die Windows-Plattform grundlegend zu ändern.
Deshalb erzeugte man zwei Prozesse, einen zur reinen Beantwortung der Clientanfragen sowie einen zur Überwachung des anderen Prozesses. Falls nötig, konnte dieser
überwachende Prozess den anderen neu starten (z.B. infolge eines Absturzes). Innerhalb des Prozesses, der die Anfragen der Clients beantwortete, liefen mehrere
Threads, die je nach Beanspruchung des Servers neu erzeugt oder auch wieder entfernt werden konnten. Die Entwickler versuchten so, das unter Unix/Linux erfolgreich verwendete Preforking-Prinzip unter Windows abzubilden, was nur teilweise
gelang. Die verschiedenen Laufzeitverhalten (Prozesse unter Linux/Unix, Threads
unter Windows) erforderten zusätzlich große Änderungen im Quelltext des Apache
und es war nötig, innerhalb des Quellcodes des Apache betriebssystem- und laufzeitspezifische Unterscheidungen (im Quellcode gekennzeichnet durch C typische
ifdef-Anweisungen) zwischen den beiden Versionen für die unterschiedlichen Plattformen vorzunehmen. Die Pflege des Quellcodes wurde für die Entwickler zusehends schwieriger, da der gesamte Quellcode unübersichtlicher wurde.
28
1 Apache-Grundlagen
Hauptprozess des Apache
Kindprozess 1
Kindprozess 2
Client 1
Kindprozess 3
Kindprozess N
Client N
Client 2
Abbildung 1.2 Struktur des Laufzeitverhaltens des Apache 1.3.x
1.4.2
Apache 2.x
Die fast drei Jahre dauernde Entwicklung der Version 2 des Apache hatte u.a. die
Zielsetzung, Portierungen auf andere Plattformen zu erleichtern und damit eine noch
weitere Verbreitung des Apache zu ermöglichen. Deshalb ist die saubere Trennung
von plattformspezifischem Code eines der obersten Ziele der Entwickler gewesen, da
der Umfang sowie die weitgehende Verbreitung des Apache eine Portierung auf
viele, höchst unterschiedliche Plattformen erforderte. Gleichzeitig sollten Entwickler
eine standardisierte Schnittstelle zur Verfügung gestellt bekommen, die ihnen die
betriebssystemunabhängige Entwicklung von Erweiterungen für den Apache ermöglicht. Ein Entwickler sollte nicht unbedingt wissen müssen, welche speziellen Gegebenheiten auf einer bestimmten Betriebssystemplattform herrschen und ihm eventuell Probleme bereiten könnten. Er sollte in der Lage sein, unabhängig von dem
zugrunde liegenden Betriebssystem allein durch seine bereits vorhandenen Programmierkenntnisse eine Erweiterung für den Apache zu schreiben, die auf eine gemeinsame Bibliothek und Schnittstelle aufsetzt und auf allen Betriebssystemen gleichermaßen und ohne Änderungen funktioniert. Das Ergebnis dieser Überlegungen und
Anstrengungen der Entwickler des Apache heißt:
Apache Portable Runtime
Da der Apache inzwischen für eine Vielzahl von Plattformen (z.B. Unix/Linux und
Windows) verfügbar ist und sogar auf Plattformen wie BeOS, Mac OS X oder Sony
Playstation 2 gewohnt stabil läuft, sind tiefgreifende und plattformspezifische Anpassungen notwendig gewesen, die den Quellcode des Apache zusätzlich aufblähten. Das
1.4 Funktionsweise des Apache
29
Problem dabei ist, dass die meisten Betriebssysteme ähnliche oder sogar dieselben
Funktionen für Netzwerkoperationen, Speicherverwaltung, Interprozesskommunikation usw. bereitstellen, diese aber meist höchst unterschiedlich implementieren. Dies
hat zur Folge, dass augenscheinlich zwar dieselben Funktionsmerkmale verfügbar
sind, sich aber von der programmiertechnischen Seite her Konzepte und Lösungen
zwischen den einzelnen Betriebssystemen nicht ohne Änderungen übertragen lassen.
Sogar innerhalb von gleichartigen Betriebssystemen (z.B. verschiedene Unix-Derivate)
bzw. Betriebssystemen mit gleichem Ursprung unterscheiden sich die vorhandenen
Programmierfunktionen und -schnittstellen teilweise erheblich, was zu Inkompatibilitäten zwischen den unterschiedlichen Herstellern und Versionen führt. Frühere Versionen des Apache mussten mit diesem Zustand zurechtkommen und die unterschiedlichen Gegebenheiten der Betriebssysteme durch spezielle und an eine Plattform
gebundene Lösungen umgehen. Es entstand plattformspezifischer Quellcode, der den
ohnehin recht umfangreichen Quellcode des Apache unnötig aufblähte und die Pflege
des Quellcodes zusehends erschwerte. Diese Problematik wurde von den Entwicklern
des Apache 2 aufgegriffen und gelöst, in dem sie alle betriebssystemabhängigen Funktionen in eine gemeinsame und betriebssystemunabhängige Bibliothek namens Apache
Portable Runtime (APR) ausgelagert haben. Durch die Einführung der Apache Portable
Runtime (APR), einer Schnittstelle zwischen dem jeweiligen Betriebssystem und dem
Kern des Apache 2, existiert für Entwickler nun eine plattformunabhängige Bibliothek,
die ihnen einen standardisierten und betriebssystemunabhängigen Zugriff auf grundlegende Funktionen eines Betriebssystems (u.a. Datei- und Netzwerkfunktionen, Zeit,
Speicherverwaltung, Thread- und Prozessverwaltung etc.) zur Verfügung stellt, ohne
dass diese sich mit den speziellen Gegeben- und Besonderheiten einer einzelnen Plattform auseinander setzen müssen. Der Quellcode des Apache und der Module wird
wesentlich klarer strukturiert. Plattformspezifische Änderungen können in der Apache Portable Runtime vorgenommen werden und beeinflussen oder stören nicht mehr
die Funktionalität auf anderen Plattformen. Zusätzlich benutzt der Apache in der
neuen Version die so genannten POSIX-Schnittstellen (POSIX – Portable Operating
System Interface for UniX) nicht mehr, da aufgrund schlecht oder fehlerhaft implementierter POSIX-Bibliotheken, die Software auf Nicht-Unix-Betriebssystemen nicht
sonderlich performant war. Ferner greift er nicht mehr direkt auf das zugrunde liegende Betriebssystem zu, sondern benutzt vielmehr die durch die API (Application
Programming Interface, eine Art Programmierschnittstelle) des APR (Apache Portable
Runtime) zur Verfügung stehenden, standardisierten und plattformunabhängigen
Funktionen wie folgende Darstellung verdeutlicht:
Die Version 1.0 des APR stellt dabei alle Funktionen bereit, die zum Betrieb des Apache 2.0 benötigt werden und ist intern in zwei Kernbibliotheken, die Apache Portable
Runtime (APR) sowie die Apache Portable Runtime-Utils (APR-Utils) aufgeteilt. Darüber hinaus ist geplant, die Apache Portable Runtime unabhängig vom Apache weiterzuentwickeln und als freie Bibliothek für plattformunabhängige Softwareentwicklung zu veröffentlichen. Einen Überblick über den Stand der Entwicklung der Apache
Portable Runtime erhalten Sie, ebenso wie weitere Unterstützung und diverse Programmierbeispiele, unter http://apr.apache.org/.
30
1 Apache-Grundlagen
Entwickler
Standardisierter Zugriff auf die
durch die APR zur Verfügung
gestellten Funktionen
Apache Portable Runtime
(APR)
Verwendung von APR erzeugt
automatisch Betriebssystemunabhängige Erweiterungen
Interaktion zwischen
Betriebssystem und APR
Zugriff auf das dem Server zugrunde
liegende Betriebssystem (z. B. Microsoft
Windows, Linux, Mac OS X, FreeBSD
etc.) sowie dessen Hardware erfolgt nur
durch die APR und nie direkt durch den
Entwickler.
Abbildung 1.3 Zusammenspiel zwischen APR und Betriebssystem
aus Sicht eines Entwicklers
Multi Processing Modules
Eine weitere, sehr wichtige Neuerung im Apache 2.x ist die Einführung von so
genannten Multi Processing Modules (MPM), einer speziellen Sorte von Modulen, in
die der Teil des Quellcodes ausgelagert worden ist, der für das Laufzeitverhalten verantwortlich ist. Dabei kann der Apache sich spezielle Fähigkeiten des jeweils zugrundeliegenden Betriebssystems zu nutze machen und entweder als prozess-basierender
oder thread-basierender Server agieren. Auch die Kombination aus beiden Laufzeitverhalten ist in einem so genannten Hybrid-Modus möglich.
Die Funktion eines MPM ist die für das jeweils genutzte Betriebssystem optimale
Abbildung von eingehenden Clientanfragen auf einfache Ausführungseinheiten (Prozesse oder Threads), die diese Anfragen verarbeiten. Diese Modularisierung eines
Teils des Apache bringt somit einen deutlich klarer strukturierten Quellcode und
ermöglicht, die Entwicklung und Verwendung von plattformspezifischen Optimierungen und Erweiterungen, die eine exklusive Nutzung eines MPM auf ein bestimmtes, optimiertes Betriebssystem erzwingen können. Insbesondere auf Nicht-UnixBetriebssystemen ist somit ein großer Geschwindigkeits- und Performancegewinn
möglich, da auf diesen Plattformen nicht mehr versucht wird, das Verhalten des Apache unter Unix nachzuahmen, sondern die Möglichkeiten des jeweiligen Betriebssystems optimal zu nutzen. Gerade unter Microsoft Windows ist mit dem MPM_winnt
ein Multi Processing Module verfügbar, welches als stabil und in punkto Stabilität
und Geschwindigkeit als echte Alternative zum direkten Konkurrenten, dem Microsoft Internet Information Server, bezeichnet werden kann.
Unter Unix/Linux existieren mehrere MPMs, die alle eine andere Strategie verfolgen,
um die eingehenden Clientanfragen zu verarbeiten. Der Administrator hat nun die Qual
1.4 Funktionsweise des Apache
31
der Wahl und muss das für seinen Anwendungsbereich passende MPM aussuchen und
fest in den Apache kompilieren. Folgende MPMs stehen dabei zur Auswahl:
Prefork
Das mpm_prefork implementiert das Laufzeitverhalten des Apache 1.3.x unter
Unix/Linux. Der Apache arbeitet dabei als so genannter Preforking-Server, d.h.,
sofort nach dem Start legt der gestartete Hauptprozess eine in der Konfigurationsdatei festgelegte Anzahl an identischen Kopien (auch Kindprozess genannt) seiner
selbst an, die einen einzigen Thread haben und auf eingehende Anfragen warten. Der
Server kontrolliert die Anzahl der Serverprozesse dynamisch während der Laufzeit
und kann diese je nach Auslastung und Anzahl der gleichzeitigen Zugriffe flexibel
erhöhen oder auch verringern. Weitere Informationen und ein grafisches Schema des
zugrunde liegenden Modells finden Sie in den Erläuterungen zum Laufzeitverhalten
des Apache 1.3.x. Bis zur Fertigstellung der anderen Laufzeitmodelle (z.B. Perchild)
stellt dieses Laufzeitverhalten immer noch den De-facto-Standard dar.
Perchild
Das mpm_perchild ähnelt in seinem Aufbau dem mpm_worker ähnlich. Auch hier
erzeugt ein Hauptprozess eine durch die NumServers-Anweisung festgelegte Anzahl an
Kindprozessen, die wiederum eine flexible Anzahl an Threads zur Beantwortung der
Clientanfragen starten. Um Fluktuationen bei der Anzahl der gleichzeitigen Anfragen
auszugleichen, wird die Anzahl der Threads je Kindprozess erhöht oder erniedrigt. Die
Besonderheit des mpm_perchild besteht außerdem darin, dass die Möglichkeit besteht,
einzelne Kindprozesse unter verschiedenen User- und Gruppenkennungen laufen zu
lassen, um somit beispielsweise virtuelle Server mit eigener Benutzer- und Gruppenkennung laufen zu lassen (vgl. AssignUserID-, ChildPerUserID-Anweisung). Ein vereinfachtes Schema macht das Prinzip deutlich:
Der Hauptprozess des Apache erzeugt
eine feste Anzahl an Kindprozessen, die
jeweils eine flexible Anzahl an Threads
starten.
Kindprozess 1
Hauptprozess des Apache
Kindprozesse können
erstmalig auch unter
eigenständigen
Benutzerkennungen laufen.
Kindprozess 2
Thread 4
Thread 1
Thread 2
Client 1
Thread 3
Kindprozess 3
Thread 5
Thread N
Client 3
Client 2
Client N
Abbildung 1.4 Schema des mpm_perchild
32
1 Apache-Grundlagen
WinNT
Das mpm_winnt lehnt sich an die alte Struktur des Apache 1.3.x unter Windows an
und erzeugt einen Haupt- und Überwachungsprozess, der einen Kindprozess startet,
der wiederum eine Vielzahl von Threads erzeugt, die die Anfragen der Client bearbeiten. Aufgrund der durchgehenden Verwendung von Windows-eigenen (Netzwerk-)-Funktionen konnte die Geschwindigkeit, Stabilität und Performance unter
Windows drastisch gesteigert werden. Folgendes Schema verdeutlicht das Prinzip
kurz:
Hauptprozess des Apache
Der Hauptprozess des Apache
überwacht den einzelnen Kindprozess.
Kindprozess
Thread 1
Thread 3
Kindprozess erzeugt Threads zur
Beantwortung von Clientanfragen.
Thread 4
Thread 2
Client 1
Client 3
Client 2
Abbildung 1.5 Funktionsweise des durch mpm_winnt implementierten Laufzeitverhaltens
Worker
Das mpm_worker stellt ein hybrides Laufzeitverhalten bereit, welches sowohl auf Prozessen, als auch auf Threads basiert. Ein Hauptprozess erzeugt eine Vielzahl von
Kindprozessen, die wiederum eine durch die ThreadsPerChild-Anweisung definierte
und feste Anzahl an Threads zur Beantwortung der Clientanfragen starten. Dadurch
können mehr Anfragen gleichzeitig bearbeitet werden, als dies bei einem reinen prozessbasierten Laufzeitverhalten der Fall wäre, ohne dabei auf die Stabilität eines prozessbasierten Servers zu verzichten. Der Server versucht zusätzlich dauerhaft eine
gewisse Anzahl an Threads frei zu haben, um im Falle einer plötzlichen Flut von
Anfragen diese dennoch bewältigen zu können. Schwankungen in der Serverlast werden durch das Starten weiterer Kindprozesse mit entsprechenden Threads oder das
Beenden einzelner Kindprozesse ausgeglichen. Das Laufzeitverhalten gilt allgemein
als stabil. Auch dazu eine kleine Grafik:
1.4 Funktionsweise des Apache
Der Hauptprozess des Apache erzeugt
eine Anzahl an Kindprozessen, die
jeweils eine feste Anzahl an Threads
starten.
Kindprozess 1
33
Hauptprozess des Apache
Kindprozess 2
Thread 3
Thread 1
Kindprozess 3
Thread 4
Thread 2
Thread 5
Client 1
Client 2
Client 3
Thread 6
Client 4
Client 5
Abbildung 1.6 Hybrides Laufzeitmodell von mpm_worker
Netware
Das mpm_netware ist speziell für die Netware-Plattform optimiert und arbeitet mit
einem thread-basierten Laufzeitmodell. Dabei existiert ein Haupt-Thread, der dafür
verantwortlich ist, die vielen Arbeits-Threads zu starten, damit diese alle Clientanfragen bearbeiten können. Dabei werden immer einige Threads in Reserve gehalten,
damit diese im Falle von plötzlich auftretenden Anfragen direkt alle Clients bearbeiten können, ohne dass erst neue Arbeits-Threads durch den Haupt-Thread erzeugt
werden müssen. Die Anweisungen StartThreads, MinSpareThreads, MaxSpareThreads
und MaxThreads regulieren die maximale Anzahl an Arbeits-Threads, die zur Beantwortung von Clientanfragen erzeugt werden sollen. Sollten Sie mehr Clientanfragen
als 256 Stück/Sekunde haben, ist es ratsam, den Wert der MaxThreads-Anweisung zu
erhöhen bzw. zu erniedrigen, wenn Sie weniger Anfragen haben. Das Laufzeitmodell
von mpm_netware gilt bereits als stabil. Dazu folgende Illustration:
34
1 Apache-Grundlagen
Der Hauptprozess des Apache erzeugt
selbst Threads zur Beantwortung von
Clientanfragen.
Hauptprozess des Apache
Thread 1
Thread 4
Thread 2
Thread 3
Client 1
Client 4
Client 2
Client 3
Abbildung 1.7 Laufzeitverhalten des mpm_netware
Leader und Threadpool
Die beiden als experimentell gekennzeichneten Laufzeitverhalten von mpm_leader
und mpm_threadpool stellen eine Variation des mpm_worker dar. Sie beruhen u.a.
darauf, dass die Arbeitschritte zwischen den einzelnen Threads der Kindprozesse
synchronisiert werden können. Momentan sind diese beiden Module jedoch einfach
noch nicht einsetzbar.
Die Wahl des richtigen Laufzeitmodells (MPM)
Die Wahl des richtigen Laufzeitverhaltens hängt von einer Vielzahl von Faktoren
(u.a. Funktionalität, Verfügbarkeit, Stabilität, Geschwindigkeit) ab und es kann derzeit keine generelle Empfehlung ausgesprochen werden. Sicherlich sollten Sie
momentan (Februar 2004) das mpm_prefork verwenden (sofern auf Ihrer Plattform
möglich), da dieses das derzeit ausgereifteste Laufzeitverhalten darstellt, zumal dieses Prinzip bereits im Apache 1.3.x mehrere Jahre in Millionen von Installationen
erfolgreich gewirkt hat. Sobald jedoch die Entwicklung der anderen Laufzeitmodelle
(z.B. worker und perchild) abgeschlossen ist und eventuell sogar erste Benchmarks verfügbar sind, kann die Wahl eines anderen Laufzeitverhaltens durchaus Sinn machen.
Die Wahl eines thread-basierten Laufzeitverhaltens wird unter Unix/Linux höchstwahrscheinlich zu einer Performancesteigerung führen, wobei es eventuell bei der
Verwendung von Drittanbietermodulen Probleme geben kann, wenn diese Bibliotheken benutzen, die in einer thread-basierten Umgebung nicht funktionieren. Da
momentan einfach Vergleichs- und Erfahrungswerte fehlen, rate ich Ihnen auf einem
Produktivsystem weiterhin zum mpm_prefork. Wenn Sie jedoch Interesse an den Möglichkeiten und Chancen der anderen Laufzeitmodelle haben, so kann ich Ihnen nur
empfehlen, diese in Testinstallationen auf Herz und Nieren zu prüfen.
2 Installation
2.1
Bezug der Software
Die offizielle Homepage des Apache Webservers lautet http://httpd.apache.org und
beheimatet neben zahlreichen Dokumentationen und Nachrichten auch die aktuellste
Version des Apache. Selbstverständlich gibt es weltweit so genannte Mirrors, d.h.
Spiegelserver, die dieselben Informationen anbieten, die jedoch aufgrund der geringeren geographischen Entfernung die Downloadgeschwindigkeit der Software
erheblich beschleunigen (sollen). Eine Liste der aktuellen Spiegelserver findet man
unter http://www.apache.org/mirrors/, geordnet nach den Anfangsbuchstaben des
Country Codes (http://www.iana.org/cctld/cctld-whois.htm) des jeweiligen Landes. Sie
finden diese Liste ebenfalls auf der dem Buch beiliegenden CD-ROM im Verzeichnis
Mirrors. Einen deutschen Spiegelserver stellt die Universität Erlangen unter
http://ftp.uni-erlangen.de/pub/mirrors/apache zur Verfügung.
Der Apache ist verfügbar für zahlreiche Plattformen wie z.B. Unix/Linux sowie
Microsoft Windows und existiert prinzipiell in zwei Formen: als vorkompiliertes
Binärpaket (sog. binary) und als Quellcode in der Hochsprache C. Letzteres bedarf
einer Kompilierung durch einen entsprechenden Compiler und bietet für erfahrene
Anwender somit die Möglichkeit, den Webserver individuell an ihre Gegebenheiten
anzupassen. Eine vorkompilierte Version ermöglicht dies nur in sehr beschränktem
Maße. Während ich die Neuauflage dieses Buches schreibe, ist die aktuelle Version
des Apache 2.0.48 erst vor kurzer Zeit erschienen.
Ich möchte mich an dieser Stelle zunächst auf die Unix/Linux-Betriebssysteme
beschränken, da die Installation des Apache unter Microsoft Windows in einem separaten Teil behandelt wird. Laden Sie sich deshalb die Datei httpd-2.0.x.tar.gz (bzw. .zip
oder tar.Z) von der Website http://www.apache.org (oder einem Mirror) herunter,
wobei das Zeichen »x« für die jeweils aktuelle Versionsnummer des Apache steht
(z.B. 2.0.43 oder 2.0.48). Dazu können Sie in der Kommandozeile beispielsweise das
Tool wget (http://www.wget.org) benutzen, welches bereits den meisten Distributionen
beiliegt. Durch Eingabe des Befehls
# wget http://www.apache.org/dist/httpd/httpd-2.0.48.tar.gz
laden Sie die momentan aktuelle Version 2.0.48 (knapp 4,2 MB) herunter. Extrahieren
Sie das Archiv mit dem Befehl
# tar xvzf httpd-2.0.48.tar.gz
Ein neues Verzeichnis namens httpd-2.0.48 wird erzeugt, welches die entpackten
Daten des Archivs enthält. Wechseln Sie in dieses Verzeichnis und schauen Sie sich
den Inhalt dieses Verzeichnisses einmal genauer an.
36
2 Installation
2.2
Inhalte der Quellen
Nachdem Sie nun die Software entpackt haben, existiert ein neues Verzeichnis
namens httpd-2.0.48 in Ihrem aktuellen Arbeitsverzeichnis. Wechseln Sie durch Eingabe von cd httpd-2.0.48 dorthin und Sie finden die folgende Verzeichnisstruktur vor:
build
Im Verzeichnis build befinden sich einige Skripte zur Installation des Apache.
docs
Dieser Ordner enthält die kompletten Dokumentationen des Apache sowie Beispiele für Konfigurationsdateien und Skripte.
include
Dort befindet sich ein Teil der sog. Headerdateien, die für die Kompilierung des
Quellcodes nötig sind. Sie enthalten Definitionen der Autoren des Programms und
beeinflussen das grundlegende Verhalten des Apache.
modules
In diesem Verzeichnis befinden sich grundlegende sowie optionale Module für den
Häuptling. Sie sind sortiert nach Themengebieten (z.B. Authentifikation, Generatoren, Logprogramme, Sicherheit etc.), welche in der Datei README im modules-Verzeichnis beschrieben sind. In den einzelnen Unterverzeichnissen befinden sich die
Quellcodes der einzelnen Module, teilweise inklusive kleiner Beschreibungen.
os
Dort befinden sich Makefiles und Headerdateien für diverse Betriebssysteme, die
zur Übersetzung des Apache notwendig sind.
server
Hier liegen ebenfalls diverse Quellcodedateien, die zur Kompilierung des Apache
notwendig sind und dessen grundlegende Eigenschaften definieren.
srclib
Drei zusätzliche Programme bzw. Bibliotheken für den Apache, darunter eine
Bibliothek für Perl-kompatible reguläre Ausdrücke und die sog. Apache Portable
Runtime (APR).
support
In diesem Ordner befinden sich zusätzliche Hilfsprogramme für den Apache wie
das Benchmarkingtool ab und u.a. Programme zur Generierung von Passwörtern,
ebenso die generelle Manpage des Indianers. Beschrieben sind die Dateien dieses
Unterverzeichnisses in einer weiteren Datei namens README, die in diesem Verzeichnis liegt.
test
Diverser Testcode der Entwickler, könnte bei neueren Versionen entfernt worden
sein.
2.3 Grundinstallation unter Unix/Linux
37
Nun haben Sie eine grobe Übersicht über die in der Apache-Distribution enthaltenen
Dateien und Verzeichnisse. Wenn Sie ein sehr interessierter und eventuell sogar fachlich versierter Anwender sind, können Sie einen Blick in die Quellcodes des Apache
werfen. Diese sind in ANSI C geschrieben und teilweise sogar kommentiert, so dass
man bei Bedarf eigene Anpassungen vornehmen kann. Ein kleines Beispiel für eine
Änderung des Quellcodes werde ich im Verlaufe des Buches vorstellen.
Hinweis
2.3
Grundinstallation unter Unix/Linux
Um unerfahrenen Lesern den Einstieg in die Materie etwas zu erleichtern, enthält diese Neuauflage erstmals auch ein separates Installationskapitel für Neueinsteiger und Anfänger. Falls Ihnen also die nachfolgend dokumentierten
Installationsschritte zu kompliziert sind oder Sie einen einfachen Einstieg in die
bunte Welt des Apache wünschen, möchte ich Sie an dieser Stelle auf das entsprechende Kapitel in diesem Buch verweisen.
Sie haben im vorherigen Abschnitt einen guten Überblick über den Inhalt und modularen Aufbau der aktuellen Apache-Distribution bekommen und ich möchte deshalb
die eigentliche Installation unter Linux/Unix, dargestellt am Beispiel der Version 2.0.48
des Apache, beginnen. Prinzipiell bieten sich Ihnen zwei Möglichkeiten, den Apache zu
installieren: Entweder Sie verwenden durch Entwickler vorkompilierte, d.h. ohne großen Einsatz sofort lauffähige Varianten des Apache (teilweise binaries bzw. precompiledVersionen genannt), oder Sie besorgen sich den Quellcode der Software und kompilieren diesen per Hand. Wenn Sie ein nicht sonderlich erfahrener Benutzer sind, empfehle
ich Ihnen die Verwendung von vorkompilierten und damit sofort einsatzfähigen Varianten des Apache, die Sie ebenfalls unter den genannten Adressen herunterladen können (vgl. Hinweis zu Beginn dieses Kapitels). Eine Installationsanleitung für diese, binaries genannten Versionen, finden Sie u.a. im Laufe dieses Kapitels. Erfahreneren
Benutzern möchte ich jedoch die zweite Variante, d.h. die manuelle Kompilierung des
Quellcodes des Apache empfehlen, da im Gegensatz zu den vorkompilierten und fertigen, d.h. nicht mehr veränderbaren Varianten des Apache, nur so die Möglichkeit
besteht, auf den Umfang und den Inhalt des Apache Einfluss zu nehmen. Die manuelle
Übersetzung des Quellcodes ist zwar mühsam und birgt viele Gefahren und Stolpersteine, aber die Chance, sich eine individuell und auf die jeweiligen Bedürfnisse exakt
zugeschnittene Version des Apache zu erstellen, sollte Ansporn genug sein, es mit der
manuellen Kompilierung und Installation zu versuchen!
Wie bereits erwähnt, müssen wir zunächst von http://httpd.apache.org die aktuellste
Version (momentan 2.0.48) herunterladen und mit
# tar xvzf httpd-2.0.48.tar.gz
entpacken. Es wird ein neues Verzeichnis namens httpd-2.0.48 erzeugt, in das die
Daten entpackt werden.
Im Gegensatz zur Version 1.3.x benutzt die Version 2.x des Apache die Programme
libtool und autoconf zur Installation, da es mit den Skripten der alten Version teilweise
Probleme gab. Autoconf und Libtool verrichten bereits in zahlreichen anderen Open
38
2 Installation
Source-Projekten (PHP, kdevelop etc.) gute Arbeit und versprechen deshalb eine reibungslosere Installation als in den vorangegangenen Versionen des Indianers.
Zur Kompilierung und Installation des Apache benötigen wir folgende Programme:
Autoconf
Libtool
ANSI-C Compiler (z.B. gcc) und diverse, fast unabdingbare Programme (u.a. make)
Perl-compatible regular expression Bibliothek (pcre)
Perl (optional)
Sofern diese Programme noch nicht oder in veralteten Versionen auf Ihrem System
installiert sind, müssen Sie diese neu installieren. Gerade nicht sonderlich erfahrene
Benutzer sollten die oben genannten Programme mit Hilfe der Softwareverwaltung
(z.B. YaST2, apt-get, dpkg, emerge etc.) Ihrer Distribution installieren.
Hinweis für SuSE 8.x/9.x-Benutzer: Standardmäßig werden die zur Kompilierung
des Apache nötigen Programme nicht mitinstalliert. Benutzen Sie auch hier die Softwareverwaltung Yast2, um die genannten Pakete (make, gcc, autoconf, bison, flex und
libtool etc.) nach zu installieren. Alternativ können Sie die Softwarepakete auch per
Hand installieren, wie die nachfolgenden Erläuterungen veranschaulichen:
Beginnen wir die einfache Installation der Software Autoconf, indem wir diese in der
aktuellsten Version mit dem Programm wget von einem FTP-Server ziehen (ca.
1,2 MB):
# wget ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.gz
Diese entpacken wir durch die Eingabe von
# tar xvzf autoconf-2.59.tar.gz
Wechseln Sie in das entpackte Verzeichnis autoconf-2.59. Danach konfigurieren wir
die Software durch Eingabe von
# ./configure
und beginnen die Kompilierung durch Ausführung des Befehls
# make
Die Installation des Programms schließt (als Superuser »root«)
# make install
ab und installiert es nach /usr/local/bin/autoconf. Damit Autoconf von anderen Programmen, die es zur Installation nutzen, gefunden werden kann, muss der Pfad
/usr/local/bin in die Umgebungsvariable PATH des Systems aufgenommen werden,
falls dies noch nicht der Fall sein sollte. Die Eingabe des Befehls set | grep PATH bzw.
echo $PATH sollte Auskunft darüber geben, welche Verzeichnisse sich bereits im sys-
2.3 Grundinstallation unter Unix/Linux
39
temweiten Pfad befinden. Taucht das Verzeichnis /usr/local/bin nicht in diesem Pfad
auf, so kann es in der Bash-Shell in die nach dem Login ausgeführte Datei .profile des
(Root)-Benutzers oder durch folgenden Aufruf in der Shell, hinzugefügt werden:
# export PATH=/usr/local/bin:$PATH.
Um den Pfad systemweit zu setzen, fügen Sie diesen in der Datei /etc/profile zu den
bereits vorhandenen Systempfaden hinzu.
Libtool (ca. 2,8 MB) finden wir ebenso auf http://www.gnu.org und laden es mit
# wget ftp://ftp.gnu.org/gnu/libtool/libtool-1.5.tar.gz
herunter. Das Archiv entpacken wir abermals mit tar xvzf libtool-1.5.tar.gz. Wechseln
Sie in das entpackte Verzeichnis libtool-1.5, und erneut erfolgt die Konfiguration der
Software durch:
# ./configure
Wir beginnen die Kompilierung der Software durch die Eingabe des Befehls
# make
Die Installation von Libtool schließt
# make install
endgültig ab und das kompilierte Programm wird nach /usr/local/bin kopiert. Auch
für dieses Programm gelten bezüglich des Pfades dieselben Hinweise wie für Autoconf (siehe oben).
Ein ANSI-C Compiler sowie grundlegende Programme wie make etc. findet man
eigentlich auf jedem Linux/Unix-System, sie sollten Teil jeder Distribution und
Installation sein.
Die PCRE-Bibliothek, geschrieben von Philip Hazel, laden wir uns ebenfalls mit dem
Programm wget durch Eingabe des Befehls
# wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-4.5.tar.gz
herunter (480 KB) und entpacken diese mit tar xvzf pcre-4.5.tar.gz. PCRE bedeutet Perlcompatible regular expressions und bezeichnet eine Bibliothek zum Verarbeiten von so
genannten regulären Ausdrücken. Eine Einführung in die Verwendung von regulären
Ausdrücken erfolgt im Laufe dieses Buches. Wechseln Sie in das entpackte Verzeichnis pcre-4.5, starten Sie die Konfiguration der Software wieder mit
# ./configure
und
# make && make install
kompilieren und installieren die Bibliothek direkt. Zum endgültigen Abschluss der
Installation kopieren wir noch die Quelldateien der Bibliothek in unser Includeverzeichnis /usr/include mit dem Befehl
40
2 Installation
# cp /usr/local/include/pcre* /usr/include/
Dadurch werden diese Dateien von neuen Softwarepaketen, die wir installieren,
gefunden und benutzt. Alternativ können Sie hier auch symbolische Verweise (sog.
Symlinks) verwenden.
Nun sind alle benötigten Programme installiert und wir können uns endlich der
eigentlichen Installation unseres Häuptlings widmen.
Wechseln Sie nun in das nach dem Entpacken neu erstellte Verzeichnis httpd-2.0.48
durch Eingabe von cd httpd-2.0.48. Rufen Sie dort den Befehl
# ./buildconf
auf, der Abhängigkeiten (u.a. auf apr und apr-util) überprüft und einige Skripte
erzeugt, die zur Kompilierung notwendig sind. Die angezeigten Warnungen wie
WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.
können getrost ignoriert werden, es ist jedoch wichtig, dass die Programme Autoconf
und Libtool gefunden und erkannt werden:
Hinweis
buildconf: autoconf version 2.53 (ok)
buildconf: libtool version 1.4.2 (ok)
Die Versionsangaben können auf dem von Ihnen verwendeten System durchaus variieren.
Die Anzahl der Installationsparameter des Apache 2 ist sehr lang und Sie erhalten
eine (leider nicht ganz vollständige) Übersicht der möglichen Optionen durch die
Eingabe von
# ./configure --help
Falls Sie diese in einer angenehmen Form lesen möchte, können Sie auch den Befehl
# ./configure --help | less
nutzen, der Ihnen eine seitenweise Übersicht über die einzelnen Optionen gibt, indem
er die Ausgaben des Befehls configure durch eine so genannte Pipe in das Programm
less umleitet, welches schließlich die seitenweise Anzeige übernimmt. Dabei können
Sie sich durch Betätigen der Leertaste jeweils die nächste Seite anzeigen lassen, oder
mit der (Bild_½)- und (Bild_¼) Taste nach oben bzw. unten scrollen. Das Betätigen
der Taste (Q) beendet die Auflistung der Optionen durch das Programm less.
2.3 Grundinstallation unter Unix/Linux
41
Ein minimaler Aufruf des configure-Skriptes sieht wie folgt aus:
# ./configure --prefix=/usr/local/apache2
Dieser minimale Aufruf sorgt dafür, dass der Apache nach /usr/local/apache2 installiert
wird. Die Ausgaben dieses Skriptes sehen (stark gekürzt) wie folgt aus:
checking
checking
checking
checking
checking
for chosen layout... Apache
for working mkdir -p... yes
build system type... i686-pc-linux-gnu
host system type... i686-pc-linux-gnu
target system type... i686-pc-linux-gnu
Configuring Apache Portable Runtime library ...
configuring package in srclib/apr now
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Configuring APR library
Platform: i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output... a.out
[...]
Construct makefiles and header files...
creating config_vars.mk
configure: creating ./config.status
creating modules/aaa/Makefile
creating modules/cache/Makefile
creating modules/echo/Makefile
creating modules/experimental/Makefile
creating modules/filters/Makefile
creating modules/loggers/Makefile
creating modules/metadata/Makefile
creating modules/proxy/Makefile
creating modules/ssl/Makefile
creating modules/test/Makefile
creating os/unix/Makefile
creating server/mpm/Makefile
creating server/mpm/prefork/Makefile
creating modules/http/Makefile
creating modules/dav/main/Makefile
creating modules/generators/Makefile
creating modules/dav/fs/Makefile
creating modules/mappers/Makefile
creating Makefile
42
2 Installation
creating modules/Makefile
creating srclib/Makefile
creating os/beos/Makefile
creating os/os2/Makefile
creating os/Makefile
creating os/unix/Makefile
creating server/Makefile
creating support/Makefile
creating srclib/pcre/Makefile
creating test/Makefile
config.status: creating docs/conf/httpd-std.conf
config.status: creating include/ap_config_layout.h
config.status: creating support/apxs
config.status: creating support/apachectl
config.status: creating support/dbmmanage
config.status: creating support/envvars-std
config.status: creating support/log_server_status
config.status: creating support/logresolve.pl
config.status: creating support/phf_abuse_log.cgi
config.status: creating support/split-logfile
config.status: creating build/rules.mk
config.status: creating include/ap_config_auto.h
config.status: executing default commands
Die vielen Ausgaben des configure-Skriptes lassen sich schlecht am Bildschirm verfolgen und eventuell auftretende Fehler bzw. Warnungen sind kaum zu erfassen. Deshalb macht es unter Umständen Sinn, die Ausgaben in eine eigene Datei umzuleiten
und diese Datei später genau auf solche Unregelmäßigkeiten zu überprüfen. Um die
Ausgaben in eine Datei umzuleiten, benutzen Sie einfach den folgenden Befehl:
# ./configure --prefix=/usr/local/apache2 > /home/sebastian/apache_configure.
ausgabe
Der hier genutzte Eingabe-/Ausgabeoperator > sorgt dafür, dass die Ausgabe des auf
der linken Seite dieses Zeichen stehenden configure-Skriptes in die auf der rechten
Seite angegebenen Datei apache_configure.ausgabe im Verzeichnis /home/sebastian
umgeleitet werden.
Die Kompilierung des Quellcodes des Apache kann nun endlich gestartet werden
durch die Eingabe von
# make
Die Kompilierung beginnt und es erscheinen etwa folgende Ausgaben (stark gekürzt):
Making all in srclib
make[1]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib'
Making all in apr
make[2]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr'
Making all in strings
make[3]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/strings'
2.3 Grundinstallation unter Unix/Linux
43
make[4]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/strings'
/bin/sh /home/sebastian/apache2/httpd-2.0.48/srclib/apr/libtool --silent -mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE I../include -I../include/arch/unix -c apr_cpystrn.
c && touch apr_cpystrn.lo
/bin/sh /home/sebastian/apache2/httpd-2.0.48/srclib/apr/libtool --silent -mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE I../include -I../include/arch/unix -c apr_snprintf
.c && touch apr_snprintf.lo
[…]
/bin/sh /home/sebastian/apache2/httpd-2.0.48/srclib/apr/libtool --silent --mode=link
gcc -g -O2 -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE D_SVID_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -I. -I/home/sebastian/apache2/httpd2.0.48/os/unix -I/home/sebastian/apache2/httpd-2.0.48/server/mpm/prefork I/home/sebastian/apache2/httpd-2.0.48/modules/http -I/home/sebastian/apache2/httpd2.0.48/modules/proxy -I/home/sebastian/apache2/httpd-2.0.48/include I/home/sebastian/apache2/httpd-2.0.48/srclib/apr/include I/home/sebastian/apache2/httpd-2.0.48/srclib/apr-util/include I/home/sebastian/apache2/httpd-2.0.48/modules/dav/main -I/usr/local/include -exportdynamic
-o httpd modules.lo modules/aaa/mod_access.la modules/aaa/mod_auth.la
modules/filters/mod_include.la modules/loggers/mod_log_config.la
modules/metadata/mod_env.la modules/metadata/mod_setenvif.la modules/http/mod_http.la
modules/http/mod_mime.la modules/generators/mod_status.la
modules/generators/mod_autoindex.la modules/generators/mod_asis.la
modules/generators/mod_cgi.la modules/mappers/mod_negotiation.la
modules/mappers/mod_dir.la modules/mappers/mod_imap.la modules/mappers/mod_actions.la
modules/mappers/mod_userdir.la modules/mappers/mod_alias.la modules/mappers/mod_so.la
server/mpm/prefork/libprefork.la server/libmain.la os/unix/libos.la
/home/sebastian/apache2/httpd-2.0.48/srclib/pcre/libpcre.la
/home/sebastian/apache2/httpd-2.0.48/srclib/apr-util/libaprutil.la
/home/sebastian/apache2/httpd-2.0.48/srclib/apr/libapr.la -lm -lcrypt -lnsl -ldl -ldb
/usr/local/lib/libexpat.la
make[1]: Leaving directory `/home/sebastian/apache2/httpd-2.0.48'
Natürlich kann auch hier die Ausgabe in eine Datei umgeleitet werden, um eventuell
auftretende Warnungen bzw. Fehlermeldungen besser analysieren zu können. Um
die Ausgabe in eine Datei namens apache_make.ausgabe ins Verzeichnis /home/sebastian
umzuleiten, geben Sie Folgendes ein:
# make > /home/sebastian/apache_make.ausgabe
Sobald die Kompilierung abgeschlossen ist, kann die Software in das durch Angabe
der Option --prefix an das configure-Skript gewählte Verzeichnis (--prefix=Verzeichnis, z.B. /usr/local/apache2) installiert werden. Geben Sie dazu folgenden Befehl ein
# make install
44
2 Installation
Dieser Befehl installiert den Apache in ein vorher definiertes Verzeichnis und erzeugt
dabei folgende Ausgaben (gekürzt):
Making install in srclib
make[1]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib'
Making install in apr
make[2]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr'
Making all in strings
make[3]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/strings'
make[4]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/strings'
make[4]: Nothing to be done for `local-all'.
make[4]: Leaving directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/strings'
make[3]: Leaving directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/strings'
Making all in passwd
make[3]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/passwd'
make[4]: Entering directory `/home/sebastian/apache2/httpd-2.0.48/srclib/apr/passwd'
make[1]: Entering directory `/home/sebastian/apache2/httpd-2.0.48'
Installing configuration files
:mkdir /usr/local/apache2/htdocs
mkdir /usr/local/apache2/manual
mkdir /usr/local/apache2/error
mkdir /usr/local/apache2/icons
mkdir /usr/local/apache2/logs
mkdir /usr/local/apache2/cgi-bin
mkdir /usr/local/apache2/man
make[1]: Entering directory `/home/sebastian/apache2/httpd-2.0.48'
Installing configuration files
Installing HTML documents
Installing error documents
Installing icons
Installing CGIs
Installing header files
Installing man pages
Installing build system files
make[1]: Leaving directory `/home/sebastian/apache2/httpd-2.0.48'
Die eigentliche Installation des Apache unter Linux/Unix aus dem Quellcode ist nun
abgeschlossen. Wenn Sie den Indianer erneut kompilieren wollen, da Sie beispielsweise einen anderen configure-Aufruf oder durch gleichzeitiges Betätigen der Tasten
Steuerung ((Strg) bzw. (Ctrl)) und (C) den Kompilierungs- bzw. Installationsvorgang
angehalten haben, müssen Sie vor dem erneuten Start des Kompilierungs- und Installationsvorgangs den Befehl make clean eingeben, der zahlreiche, bereits kompilierte
Dateien löscht und den ursprünglichen Zustand wieder herstellt. Weitere Informationen über die Verwendung der zahlreich zur Verfügung stehenden Konfigurationsoptionen erhalten Sie im Kapitel über die benutzerdefinierte Installation des Apache.
2.4 Installation mit fertigen Paketen
2.4
45
Installation mit fertigen Paketen
Es existieren für Linux mehrere Paketmanager wie der Red Hat Package Manager
(RPM), der üblicherweise unter SuSE und Red Hat zum Einsatz kommt, sowie das
Debian Package Management System (dpkg), welches auf dem Debian-System zum Einsatz kommt. Diese Programme stellen, teilweise auf recht unterschiedliche Weise, folgende Funktionen bereit:
Einheitliche Oberfläche zur Installation, Deinstallation und Aktualisierung von
Software
Indexierung der installierten Softwarepakete
Abgleichung mit externen Servern zur Aktualisierung der internen Softwaredatenbank
Direkte Installation von Software aus dem Internet
Auflösung von eventuell vorhandenen Abhängigkeiten durch automatische Zusatzinstallation von extra benötigter Software
Vorkonfiguration von neu installierter Software
Somit stellen diese Programme gerade nicht sonderlich erfahrenen Benutzern eine
sehr einfache Möglichkeit der Softwareverwaltung unter Linux zur Verfügung. Es
existieren dabei für beide Systeme vorgefertigte und vorkompilierte Pakete, die den
Apache installieren.
2.4.1
Installation per RPM
Teilweise bieten die Distributoren (SuSE, Red Hat) schon fertige Pakete mit dem Apache 2.0.x an. Ansonsten finden Sie unter http://www.rpmfind.net eine unabhängige
Suchmaschine für .rpm-Pakete, in der Sie durch eine Suche nach Apache 2 sicherlich
fündig werden. Auf der dem Buch beiliegenden CD-ROM ist ebenfalls ein fertiges
RPM-Paket enthalten. Laden Sie sich beispielsweise für SuSE 9.0 das Paket von
ftp://ftp.suse.com/pub/people/poeml/apache2/9.0-i386/apache2-2.0.48-31.i586.rpm herunter
(knapp 749kb) und installieren Sie dieses durch Eingabe von
Hinweis
# rpm –i apache2-2.0.48-31.i586.rpm
Die Installation mittels RPM-Paket erfordert das Vorhandensein diverser
Zusatzsoftware (u.a. Berkeley DB, OpenSSL etc.). Beachten Sie deshalb auch die
entsprechenden Kapitel in diesem Buch zur manuellen Installation benötigter
Zusatzsoftware unter Unix/Linux oder benutzen Sie die Softwareverwaltung
Ihrer Distribution (z.B. YaST 2) zur Installation von Drittanbietersoftware.
Dies installiert den Apache nach /usr/local/apache2. Sie können RPM auch direkt einen
Verweis auf einen FTP-Server geben, von dem er das Paket ziehen soll. Der Aufruf
würde demnach wie folgt aussehen:
# rpm –i ftp://ftp.suse.com/pub/people/poeml/apache2/9.0-i386/apache2-2.0.4831.i586.rpm
46
2 Installation
Entfernen können Sie den Apache durch Eingabe von
# rpm –e apache-2.0.48
Eine Übersicht über die in diesem Paket enthaltenen Dateien, erhalten Sie durch Eingabe von
# rpm –qa apache-2.0.48
Weitere Informationen zur Verwendung von RPM finden Sie im RPM Howto unter
http://www.rpm.org/RPM-HOWTO/ (auf der CD-ROM enthalten) sowie durch Eingabe
des Befehls man rpm. Eine gute deutschsprachige Anleitung zur Benutzung des Red
Hat Package Managers finden Sie u.a. unter http://www.kernelnotes.de/dlhp/DE-RPMHOWTO.html.
2.4.2
Installation mit Debian .deb Paketen
Offiziell ist der Apache 2.x noch nicht in der von mir verwendeten Debian Woody 3.0
enthalten, aber einige Entwickler bieten schon jetzt fertige .deb-Pakete auf ihren Internetseiten an. Unter http://www.apt-get.org finden Sie deshalb eine praktische Suchmaschine für .deb-Pakete, mit dessen Hilfe Sie sicherlich die neuesten Versionen des
Apache 2 finden. Entweder Sie laden sich die benötigen Pakete manuell von dieser
Adresse herunter und installieren diese durch den Befehl dpkg –i dateiname.deb oder
Sie benutzen das Programm apt zur Installation, welches ein Frontend zu dpkg darstellt. Öffnen Sie dazu die Datei sources.list, die gewöhnlich im Verzeichnis /etc/apt/
liegt und fügen Sie die folgenden Zeilen hinzu:
deb http://debian.netfarm.it/debian/ woody sherpya
Hinweis
deb-src http://debian.netfarm.it/debian/ woody sherpya
Unter http://www.backports.org finden Sie ebenfalls viele Softwarepakete für
Debian.
Auf dem von mir genutzten System sieht die gesamte Datei /etc/apt/sources.list demnach wie folgt aus:
deb http://debian.netfarm.it/debian/ woody sherpya
deb-src http://debian.netfarm.it/debian/ woody sherpya
deb
deb-src
deb
deb-src
deb
deb-src
deb
deb-src
http://ftp.de.debian.org/debian woody main
http://ftp.de.debian.org/debian woody main
http://ftp.de.debian.org/debian-non-US woody/non-US main
http://ftp.de.debian.org/debian-non-US woody/non-US main
http://ftp.de.debian.org/debian/ woody-proposed-updates main
http://ftp.de.debian.org/debian/ woody-proposed-updates main
http://ftp.de.debian.org/debian-non-US/ woody-proposed-updates/non-US main
http://ftp.de.debian.org/debian-non-US/ woody-proposed-updates/non-US main
2.4 Installation mit fertigen Paketen
47
deb
http://security.debian.org/ woody/updates main
deb-src http://security.debian.org/ woody/updates main
Nun muss die Datei sources.list neu eingelesen werden, damit die Softwareverwaltung weiß, dass es eine Veränderung in dieser Datei gegeben hat und eventuell neuere Softwareversionen verfügbar sind. Rufen Sie dazu den folgenden Befehl auf
# apt-get update
Sofern Sie mit dem Internet verbunden sind, wird die Liste der verfügbaren Server
neu eingelesen und erfolgreich aktualisiert:
Get:1 http://debian.netfarm.it ./ Packages [1483B]
Ign http://debian.netfarm.it ./ Release
Fetched 1483B in 0s (3258B/s)
Reading Package Lists... Done
Building Dependency Tree... Done
Die auf diesem Server verfügbaren Pakete können überprüft werden durch
# apt-cache search apache2
Bei meinen Tests befanden sich mehrere Softwarepakete auf diesem Server, wie die
Ausgabe von apt-cache search apache2 zeigt (gekürzt)
apache2-common 2.0.47-1 (i386)
apache2-dev 2.0.47-1 (all)
apache2-doc 2.0.47-1 (all)
Die benötigten Bibliotheken werden installiert durch den Befehl
# apt-get –f install
Der eigentliche Apache Server wird installiert durch
Hinweis
# apt-get install apache2-common-2.0.47-1
Die Version 2.0.47 des Apache ist inzwischen veraltet und auf dem genannten
Server sollte bald eine aktualisierte Version verfügbar sein.
Nach Ausführung dieses Befehls ist der Apache Webserver 2.0.x in einer aktuellen
Version installiert. Weitere Informationen zur Verwendung von dpkg und apt finden
Sie in den entsprechenden Manpages (man dpkg und man apt) und u.a. auf http://www.
openoffice.de/linux/buch/apt.html und unter http://dugfaq.sylence.net/dug-faq/node5.html.
2.4.3
Installation mit vorkompilierten Paketen
Unter http://www.apache.org/dist/httpd/binaries/linux/ gibt es die neueste, vorkompilierte Version des Apache für zahlreiche Plattformen (Intel, PowerPC, Sparc etc.) als
.tar.gz-Archiv. Laden Sie sich die für Ihre Plattform passende Datei herunter (meist
httpd-2.0.x-i686-pc-linux-rh72.tar.gz) und entpacken Sie diese durch folgenden Befehl
48
2 Installation
# tar xvzf httpd-2.0.48-i686-pc-linux-rh72.tar.gz
Nachdem Sie die Software entpackt haben, ist die Installation denkbar einfach: Kopieren Sie aus dem neu erzeugten Verzeichnis den Unterordner bindist in ein beliebiges
Verzeichnis. Um den Unterordner beispielsweise nach /usr/local/apache2 zu kopieren,
geben Sie folgenden Befehl ein:
# cp -R httpd-2.0.48/bindist /usr/local/apache2
Die Installation ist damit bereits abgeschlossen, dies ist wohl die einfachste Art, den
Apache unter Unix/Linux zu installieren. Eine interessante Alternative zu dieser
Methode wird im Installationskapitel des Apache für Anfänger vorgestellt.
2.5
Installation des Apache 2
unter Gentoo Linux
Die Gentoo-Distribution (http://www.gentoo.org) ist eine relativ junge Linux-Distribution, die sich einer stetig wachsenden Beliebtheit erfreut und auch auf meinem Desktop bereits Einzug gehalten hat. Neben einer guten Dokumentation besticht diese,
vornehmlich für Fortgeschrittene und professionelle Anwender gedachte Distribution, vor allen Dingen durch eine BSD-artige Portssammlung (vgl. Kapitel über die
Installation des Apache unter FreeBSD), die u.a. eine kinderleichte Installation von
Softwareprogrammen und eine einfache Aktualisierung des Systems ermöglicht.
2.5.1
Aktualisierung des Systems
Um ständig Zugriff auf die neuesten Programmversionen und Softwareprodukte zu
haben, muss die Portssammlung von Zeit zu Zeit aktualisiert werden. Dazu muss bei
bestehender Internetverbindung folgender Befehl eingegeben werden (als root):
# emerge sync
Es erscheint in etwa folgende Ausgabe, die den erfolgreichen Start des Aktualisierungsprozesses belegt:
root66 sebastian # emerge sync
>>> starting rsync with rsync://rsync.gentoo.org/gentoo-portage...
>>> checking server timestamp ...
Nachdem dieser Vorgang abgeschlossen ist, kann das eigene System mit Hilfe des
Befehls emerge bequem auf den neuesten Stand gebracht werden. Dazu sollten Sie sich
zunächst einmal eine Liste der Programme anzeigen lassen, die das System aktualisieren würde:
# emerge -UpDv world
2.5 Installation des Apache 2 unter Gentoo Linux
49
Auf meinem privaten System sind dies momentan (Januar 2004) folgende Programme:
>>> --upgradeonly implies --update... adding --update to options.
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild N
] dev-lang/python-2.3.3 +ncurses +gdbm +ssl +readline +tcltk +berkdb bootstrap -ipv6 -build -ucs2 -doc
[ebuild
U ] dev-java/java-config-1.2.5 [1.2.4]
[ebuild
U ] sys-apps/man-pages-1.65 [1.64]
[ebuild
U ] media-libs/lcms-1.12 [1.11] -tiff +jpeg +zlib
+python
[ebuild
U ] media-libs/libvorbis-1.0.1-r1 [1.0.1]
[ebuild
U ] net-firewall/fwbuilder-1.1.1 [1.0.11] -static +nls
[ebuild
U ] net-misc/rsync-2.6.0 [2.5.7]
[ebuild
U ] sys-apps/slocate-2.7-r5 [2.7-r2]
[ebuild N
] media-sound/madplay-0.15.0b-r1 -debug +nls
[ebuild
U ] media-sound/mad-0.15.0b [0.14.2b-r2]
Um die Aktualisierung der genannten Programme schließlich durchzuführen, müssen Sie aus dem oben genannten Kommando nur den Parameter -p entfernen:
# emerge -UDv world
Je nach Umfang der zu aktualisierenden Softwareprogramme und der Geschwindigkeit der eigenen Internetverbindung, kann der Vorgang unter Umständen eine
geraume Zeit in Anspruch nehmen. Sobald dieser abgeschlossen ist, sind auf Ihrem
System die neuesten Programmversionen installiert und die Aktualisierung des eigenen Systems ist damit abgeschlossen. Weitere Informationen zu Gentoo und der
wirklich ausgereiften Softwareverwaltung finden Sie im Internet u.a. unter
http://www.gentoo.org/doc/de/index.xml.
2.5.2
Installation des Apache 2
Nachdem Sie die Portssammlung und das eigene System auf den neuesten Stand
gebracht haben, können Sie mit der Installation des Apache 2 unter Gentoo beginnen.
Durchsuchen Sie dazu zunächst die Portssammlung, um einen Überblick über die zur
Verfügung stehenden Programme zu erhalten:
# emerge -s apache
Dieser Befehl durchsucht die Portssammlung nach der Zeichenkette apache und bringt
unter anderem folgenden Eintrag zum Vorschein:
* net-www/apache
Latest version available: 2.0.48-r1
Latest version installed: 2.0.48-r1
50
2 Installation
Size of downloaded files: 6,111 kB
Homepage:
http://www.apache.org/
Description: Apache Web Server, Version 2.0.x
Um den Apache in der vorliegenden Version 2.0.48 zu installieren, muss bei bestehender Internetverbindung einfach folgender Befehl eingegeben werden:
# emerge apache
Daraufhin beginnt die Kompilierung und Installation der Software:
Calculating dependencies ...done!
>>> emerge (1 of 1) net-www/apache-2.0.48-r1 to /
>>> md5 src_uri ;-) httpd-2.0.48.tar.gz
>>> Unpacking source...
>>> Unpacking httpd-2.0.48.tar.gz to /var/tmp/portage/apache-2.0.48-r1/work
Nach der erfolgreichen Installation der Software können Sie sich durch den Befehl
qpkg eine Liste der neu installierten Dateien und Verzeichnisse anzeigen lassen:
Hinweis
# qpkg -l apache
Die Applikation qpkg ist Bestandteil des Programms gentoolkit, welches gegebenenfalls zunächst durch Eingabe des Befehls emerge gentoolkit installiert werden
muss.
Die relativ lange Ausgabe zeigt insgesamt 1595 (qpkg -l apache | wc -l) neue Dateien
und Verzeichnisse, die durch die Installation des Apache auf dem lokalen System neu
vorhanden sind (Auswahl):
net-www/apache-2.0.48-r1 *
CONTENTS:
/usr
/usr/include
/usr/include/apache2
/usr/include/apache2/apr_allocator.h
/usr/include/apache2/apr_atomic.h
/usr/include/apache2/apr_compat.h
/usr/include/apache2/apr_dso.h
/usr/include/apache2/apr_env.h
/usr/include/apache2/apr_errno.h
/usr/include/apache2/apr_file_info.h
[…]
/var/www/localhost/icons/world1.png
/var/www/localhost/icons/world2.gif
/var/www/localhost/icons/world2.png
/var/www/localhost/cgi-bin
/var/www/localhost/cgi-bin/printenv
/var/www/localhost/cgi-bin/test-cgi
2.6 Installation des Apache 2 unter SuSE
51
Dabei sind u.a. die folgenden Verzeichnisse von besonderer Bedeutung:
/usr/include/apache2
In diesem Verzeichnis sind alle Headerdateien des Apache 2 installiert.
/usr/lib
Die durch den Apache 2 bereitgestellten Bibliotheken (z.B. libapr) sind in diesem
Verzeichnis gespeichert.
/usr/lib/apache2
Alle Zusatzmodule des Apache (z.B. mod_rewrite) sind als so genannte Shared
Objects (.so-Dateien) im Verzeichnis /usr/lib/apache2 gespeichert.
/usr/sbin
Dieses Verzeichnis beinhaltet einen Großteil der ausführbaren Programme (z.B.
htpasswd, suexec) des Apache 2.
/usr/share/doc/apache-2.0.48-r1
Enthält die komplette Dokumentation des Apache 2 im HTML-Format.
/etc/apache2
Sämtliche Konfigurationsdateien des Apache liegen in diesem Verzeichnis vor.
/var/www/localhost
Das Dokumentenverzeichnis (vgl. DocumentRoot-Anweisung) sowie die Fehlerseiten des Apache sind unterhalb dieses Verzeichnisses gespeichert.
Um den Apache schließlich zu starten, müssen Sie folgenden Befehl eingeben:
# /etc/init.d/apache2 start
Starten Sie daraufhin ihren Browser und rufen Sie die Adresse http://localhost auf, um
die korrekte Funktionsweise des Apache 2 zu überprüfen. Sofern das Programm wie
gewünscht funktioniert, können Sie durch folgenden Befehl dafür sorgen, dass der
Apache beim Systemstart automatisch ausgeführt wird:
# rc-update add apache2 default
Die Installation des Apache 2 unter Gentoo Linux ist damit abgeschlossen.
Installation des Apache 2 unter SuSE
2.6.1
Installation
Hinweis
2.6
Die nachfolgenden Ausführungen beziehen sich auf SuSE Linux 9.0 Professional, wobei das entsprechende Beispielsystem über eine Standardinstallation
(ohne Apache) verfügte.
52
2 Installation
Da SuSE 9.0 leider keine Möglichkeit bietet, den Apache 2 in der aktuellsten Version
automatisch über das Internet zu installieren, muss die Software zunächst manuell
von einem FTP-Server heruntergeladen werden. Führen Sie dazu bei bestehender
Internetverbindung folgenden Befehl aus:
Hinweis
# wget –r ftp://ftp.suse.com/pub/projects/apache/apache2/9.0-i386/
Sollten Sie eine ältere Version der SuSE-Distribution (z.B. 8.0) benutzen, finden
Sie unter ftp://ftp.suse.com/pub/projects/apache/apache2/ entsprechende Pakete für
ihre Version. Bitte passen Sie in diesem Fall die hier aufgeführten Befehle und
Verzeichnisnamen an ihre Version an.
Sobald dieser Vorgang abgeschlossen ist, finden Sie im aktuellen Verzeichnis ein neues
Verzeichnis namens ftp.suse.com, welches die vom Server übertragenen Dateien
beinhaltet. Wechseln Sie in das tiefste Unterverzeichnis dieses Verzeichnisses (cd
ftp.suse.com/pub/projects/apache/apache2/9.0-i386/) und installieren Sie die Bibliothek libapr
(Apache Portable Runtime), die später zur Ausführung des Apache 2 benötigt wird:
Hinweis
# rpm -i libapr0-2.0.48-31.i586.rpm
Eventuell auftauchende Warnungen können getrost ignoriert werden.
Dieser Befehl installiert mit Hilfe des Programms rpm die Datei libapr0-2.0.4831.i586.rpm aus dem aktuellen Verzeichnis. Nachdem die Bibliothek installiert ist,
können Sie mit der eigentlichen Installation des Apache beginnen (eine Zeile):
Hinweis
# rpm -i apache2-prefork-2.0.48-31.i586.rpm apache2-2.0.48-31.i586.rpm
Sofern Sie nicht das durch das mpm_prefork (vgl. Einleitung des allgemeinen
Installationskapitels) bereitgestellte Laufzeitverhalten benutzen möchten, können Sie diesen Befehl entsprechend anpassen und somit eine der anderen Varianten (Dateiname: apache2-leader-2.0.48-31.i586.rpm, apache2-metuxmpm-2.0.4831.i586.rpm oder apache2-worker-2.0.48-31.i586.rpm) verwenden, die durch SuSE
auf dem genannten FTP-Server bereitgestellt werden.
Wenn die Installation abgeschlossen ist, müssen Sie Software mit dem SuSE-eigenen
Programm SuSEConfig für das eigene System konfigurieren:
# SuSEconfig --module apache2
Schließlich sollten Sie noch die Hilfe-, Entwicklungs- und Beispieldateien des Apache
2 installieren (eine Zeile):
# rpm -i apache2-devel-2.0.48-31.i586.rpm apache2-doc-2.0.48-31.i586.rpm apache2example-pages-2.0.48-31.i586.rpm
2.7 Installation unter (Free-) BSD
53
Damit ist die reine Installation des Apache 2.0.48 unter SuSE Linux abgeschlossen.
Für die weitere Administration des Servers sind u.a. folgende Verzeichnisse wichtig:
/srv/www
Dieses Verzeichnis beinhaltet das gesamte Dokumentenverzeichnis (vgl. DocumentRoot-Anweisung) des Apache 2.
/etc/apache2
Sämtliche Konfigurationsdateien des Apache 2 sind in diesem Verzeichnis gespeichert. Dabei teilt SuSE, im Gegensatz zu vielen anderen Herstellern, die Konfigurationsdatei httpd.conf des Apache aus Gründen der Übersichtlichkeit in mehrere
kleine Konfigurationsdateien (z.B. uid.conf für Benutzer- und Gruppenkonfiguration) auf. Bitte beachten Sie, dass primär die Datei /etc/sysconfig/apache2 zur manuellen Konfiguration des Apache 2 verwendet werden sollte. Unter Umständen
kann nach einer Veränderung dieser Datei die Ausführung des Befehl
SuSEconfig --module apache2 notwendig sein.
Um den Server schließlich zu starten, müssen Sie folgenden Befehl eingeben:
# rcapache2 start
Wenn Sie daraufhin die korrekte Funktionsweise des Indianers testen möchten, müssen Sie ihren Browser starten und die Adresse http://localhost aufrufen.
Hinweis
Weitere Informationen zur Verwendung des Apache 2 unter SuSE finden Sie im Internet u.a. unter http://portal.suse.com/sdb/en/2003/01/apache2-faq.html (Englisch) und in
der lokalen Datei /usr/share/doc/packages/apache2/README.SuSE (ebenfalls Englisch).
Insbesondere bei der Installation von Drittanbietermodulen gibt es unter SuSE
Linux einige Besonderheiten zu beachten. Lesen Sie daher bitte auch unbedingt
die Datei /usr/share/doc/packages/apache2/README.QUICKSTART (Englisch)
und achten Sie u.a. darauf, dass Sie bei der manuellen Installation eines Drittanbietermoduls (z.B. mod_injection) nicht den Parameter -a verwenden, der
das neu erstellte Modul automatisch in der Konfigurationsdatei httpd.conf aktivieren würde, da dieser die Konfigurationsdatei zerstören könnte.
2.7
Installation unter (Free-) BSD
Unter Linux existieren mehrere konkurrierende Systeme bzw. Programme zur Verwaltung und Installation von Software (so genannte Paketverwaltung), die sich von
Distribution zu Distribution sehr unterscheiden. Außer Debian bietet keine Distribution eine Paketverwaltung, die man als intelligent und wirklich ausgereift bezeichnen
kann. Die BSD-Systeme wie Free-, Open- und NetBSD verfügen seit geraumer Zeit
über eine so genannte Ports-Collection (auch Ports-Sammlung genannt), eine strukturierte und sortierte Sammlung von Informationsdateien (auch Ports genannt), die die
Installation und Deinstallation von Softwarepaketen mit einem einfachen, aber
nahezu genialen System über das Internet ermöglicht. Die Informationsdateien enthalten Beschreibungen der Softwarepakete, die Sie installieren können, sowie die
54
2 Installation
Adresse des meist über das Internet (via FTP oder HTTP) zu beziehenden Quellcodes
einer Software. Erfordert der Einsatz auf einer bestimmten Zielplattform die Einspielung eines Patches oder einer andersartigen Modifikation des Quellcodes, wird diese
Modifikation ebenfalls durch die Ports-Sammlung vorgenommen. Ebenso wird eine
zusätzlich durch die zu installierende Software benötigte Bibliothek oder Erweiterung automatisch aus dem Internet heruntergeladen und installiert, so dass die
Abhängigkeiten der Softwarepakete untereinander immer und ohne manuellen Eingriff des Benutzers erfüllt werden. Zusätzlich definiert eine Informationsdatei, welche Dateien wohin kopiert werden, und in einer systemweiten Datenbank werden
Prüfsummen gespeichert, die eine absolut saubere Deinstallation und Update der
vorhandenen Softwarepakete ermöglichen. Dieses System wurde inzwischen von der
Gentoo-Linuxdistribution (http://www.gentoo.org) übernommen und ist allen auf dem
Markt erhältlichen Softwareverwaltungssystemen weit überlegen, einzig das Debian
Package Management System kann vielleicht mithalten.
2.7.1
Aktualisierung der Ports-Sammlung
unter FreeBSD mit CVSup
Die mir vorliegende Version 4.9 von FreeBSD enthält eine veraltete Version des Apache 2 (2.0.47) und es ist daher zunächst nötig, die Ports-Sammlung auf den neuesten
Stand zu bringen. Hinweis: Um den Zugriff auf die neusten Softwareversionen zu
erhalten, sollten Sie Ihre Ports-Sammlung in regelmäßigen Abständen über das Internet aktualisieren.
Installieren Sie die Ports-Sammlung, sofern Sie diese noch nicht auf Ihrem System
installiert haben, und wechseln Sie durch Eingabe des folgenden Befehls in das Verzeichnis /usr/ports/net/cvsup:
# cd /usr/ports/net/cvsup
Starten Sie die Installation der zum Update der Ports-Sammlung benötigten Software
cvsup bei bestehender Internetverbindung durch das Kommando:
# make install
Je nach Geschwindigkeit des Computers und der Internetverbindung sowie dem
Umfang der ursprünglich installierten Komponenten des FreeBSD-Systems kann die
Installation von cvsup eine geraume Zeit in Anspruch nehmen.
Ist die Installation von cvsup endlich abgeschlossen, müssen Sie die Beispielkonfigurationsdatei ports-supfile, die sich im Verzeichnis /usr/share/examples/cvsup befindet, in
das Heimatverzeichnis des root-Benutzers kopieren:
# cp /usr/share/examples/cvsup/ports-supfile /root
Zur Aktualisierung Ihrer Ports-Sammlung benötigen Sie noch einen Server, der
zwecks guter und schneller Erreichbarkeit über eine geografisch für Sie günstige Position verfügen sollte. Eine Liste der möglichen Server finden Sie im Internet unter
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-
2.7 Installation unter (Free-) BSD
55
MIRRORS, für Deutschland ist u.a. der Server cvsup.de.FreeBSD.org geeignet. Sollte
dieser Server (wie in meinem Fall) überlastet sein, müssen Sie einen alternativen Server wie cvsup5.de.FreeBSD.org benutzen, der freundlicherweise durch den, für die
Benutzer des Apache durch die Entwicklung des genialen Moduls mod_rewrite
bekannten Softwareautor, Ralf S. Engelschall (http://www.engelschall.com) bereitgestellt wird.
Öffnen Sie deshalb die Datei /root/ports-supfile mit Ihrem Lieblingseditor (z.B. vi, pico,
joe, mcedit etc.) und ändern Sie in der Zeile 51 den folgenden Ausdruck:
*default host=CHANGE_THIS.FreeBSD.org
Geben Sie hier den von Ihnen favorisierten Server an, den Sie zur Aktualisierung der
Ports-Sammlung benutzen möchten. Für den Server cvsup5.de.FreeBSD.org sieht diese
Zeile demnach wie folgt aus:
*default host=cvsup5.de.FreeBSD.org
Alternativ können Sie auch diesen zugegebenermaßen etwas umständlichen Befehl
benutzen, um den Wert in der Datei /root/ports-supfile zu ändern:
# sed 's/*default host=CHANGE_THIS.FreeBSD.org/*default host=cvsup5.de.FreeBSD.
org/g' /root/ports-supfile > /root/ports-supfile2 && mv /root/ports-supfile2
/root/ports-supfile
Speichern Sie die Datei /root/ports-supfile und starten Sie die Aktualisierung Ihrer
Ports-Sammlung über das Internet:
# /usr/local/bin/cvsup –g –L 2 /root/ports-supfile
Benutzen Sie dieses Kommando regelmäßig, um die Ports-Sammlung zu aktualisieren! Tipp: Bei mir ist während der Aktualisierung meiner Ports-Sammlung der Strom
ausgefallen, ich hatte wohl mit den fünf angeschlossenen Rechnern zu viele Geräte
gleichzeitig in Betrieb. Als ich dann den Apache installieren wollte, verweigerte dieser die Installation, da die vorherige Installation bei 98% abgebrochen ist und eine
ungültige Version vorhanden war. Ein schneller Weg diesen Fehler zu korrigieren, ist
das Verzeichnis /usr/ports/distfiles, in dem die heruntergeladenen Softwarepakete temporär gespeichert werden, zu leeren und die Installation des Apache erneut zu starten:
# rm -R /usr/ports/distfiles/*
# cd /usr/ports/www/apache2 && make install
Nach diesem kleinen Trick konnte ich den Apache wieder ohne Probleme installieren.
2.7.2
Installation von Software mit
der FreeBSD Ports-Sammlung
Sofern Sie die Ports-Sammlung installiert haben, finden Sie im Verzeichnis /usr/ports
eine strukturierte Sammlung von Informationsdateien, die Sie zur Installation der
bereitgestellten Softwarepakete (inzwischen 6000-7000 Stück!) verwenden können.
56
2 Installation
Wenn Sie eine bestimmte Software (z.B. openssh) suchen, können Sie die PortsSammlung u.a. mit folgendem Befehl durchsuchen:
# find /usr/ports -name Suchbegriff -print
Das korrekte Verzeichnis für OpenSSH finden Sie durch folgenden Befehl:
# find /usr/ports -name openssh -print
Sofern Sie sich der genauen Bezeichnung einer Software nicht sicher sind, können Sie
die gesuchte Zeichenkette um eine so genannte Wildcard, d.h. einen Platzhalter
erweitern, so dass alle Softwarepakete, die zu dieser Beschreibung passen, gefunden
und ausgegeben werden:
# find /usr/ports -name "*ssh" -print
Bei der Verwendung eines Platzhalters ist die Angabe von Anführungszeichen im
Gegensatz zu den unter Linux erhältlichen Implementationen des find-Befehls unbedingt notwendig! Dieser Platzhalter im Aufruf des find-Kommandos sorgt dafür, dass
das Verzeichnis /usr/ports nach allen Vorkommnissen des Wortes ssh abgesucht wird,
wobei durch den Charakter »*« auch alle Verzeichnisse ausgegeben werden, deren
Bezeichnung auf ssh endet und alle, deren Bezeichnung mit einem beliebigen Wort
von beliebiger Länge (z.B. OpenSSH) vor der Zeichenkette ssh beginnt.
Eine weitere Möglichkeit, eine bestimmte Software zu suchen, ist die eingebaute
Suchfunktion der Ports-Sammlung zu benutzen. Wechseln Sie in das Verzeichnis
/usr/ports und geben Sie dort den Befehl
# make search name=Suchbegriff
ein. Wenn Sie also beispielsweise nach OpenSSH suchen, können Sie auch folgenden
Befehl benutzen, um den Standort dieser Software herauszufinden und weitere Informationen über diese zu erhalten:
# make search name=openssh
Dieser Befehl durchsucht die Ports-Sammlung und liefert für OpenSSH u.a. folgenden Eintrag:
Port:
Path:
Info:
Maint:
Index:
B-deps:
R-deps:
openssh-3.6.1_5
/usr/ports/security/openssh
OpenBSD's secure shell client and server (remote login program)
[email protected]
security
Die erste Zeile enthält den Namen und die Version der vorhandenen OpenSSH-Variante, die zweite Zeile enthält den korrekten Pfad innerhalb der Ports-Kollektion und
die dritte Zeile gibt eine kurze Beschreibung der Funktion der Software aus. Die bei-
2.7 Installation unter (Free-) BSD
57
den letzten Zeilen weisen auf die durch das Programm zusätzlich benötigten Erweiterungen und Bibliotheken hin.
Sofern Sie die Software, die Sie installieren möchten, gefunden haben, müssen Sie in
das entsprechende Verzeichnis wechseln und von dort die Installation beginnen. Die
vorhin ausgeführte Suche nach OpenSSH brachte das Verzeichnis /usr/ports/
security/openssh zum Vorschein. Wechseln Sie in dieses Verzeichnis durch
# cd /usr/ports/security/openssh
und starten Sie die komplette Installation inklusive aller zusätzlich benötigten Bibliotheken, Erweiterungen und Programmen durch Eingabe eines einzigen (magischen)
Befehls:
# make install
Sofern eine Internetverbindung besteht, startet der Download des zu installierenden
Softwarepaketes und aller zusätzlich benötigten Bibliotheken und Erweiterungen.
Dazu enthält eine Informationsdatei (ein so genannter Port) der Ports-Sammlung
immer eine Liste an Servern, auf denen die entsprechende Software verfügbar ist, so
dass die Software auch dann erfolgreich installiert werden kann, wenn die entsprechende Datei auf einem Server nicht mehr vorhanden oder ein Server überhaupt nicht
erreichbar ist.
Die Installation der Software ist nun abgeschlossen. Wie Sie den Umfang und den
genauen Speicherort der neu aufgespielten Dateien und Verzeichnisse erhalten, erläutere ich in der Installationsanleitung des Apache 2 mit Hilfe der Ports-Sammlung.
2.7.3
Deinstallation von einer Software
mit der Ports-Sammlung
Die Deinstallation einer Software mit Hilfe der Ports-Sammlung ist sehr einfach,
wechseln Sie in das entsprechende Verzeichnis der zu deinstallierenden Software und
führen Sie den Befehl make deinstall aus. Ich habe mir beispielsweise den Editor joe
installiert, der in der Ports-Sammlung unter /usr/ports/editors/joe zu finden ist. Zur
Deinstallation dieses Editors wechsele ich in dieses Verzeichnis und führe die saubere
Deinstallation aus:
# cd /usr/ports/editors/joe
# make deinstall
Die Deinstallation der Software geht rasant schnell und wird Ihnen kurz bestätigt:
===>
Deinstalling joe-2.8_5
Sofern Sie die Software wieder installieren möchten, können Sie dies durch die Eingabe von make install in dem entsprechenden Verzeichnis erreichen. Die Installation
wird in diesem Fall deutlich schneller erfolgen, da die Kompilierung des aus dem
Internet heruntergeladenen Quellcodes der Software nicht mehr nötig ist und größtenteils übergangen wird.
58
2.7.4
2 Installation
Installation des Apache 2 mit der Ports-Sammlung
Die Installation des Apache 2 unter FreeBSD mit der Ports-Sammlung läuft im Prinzip
genauso ab, wie die bereits erklärte Installation jeder anderen Software mit Hilfe dieser Sammlung. Suchen Sie das korrekte Verzeichnis für den Apache 2 durch Eingabe
eines der folgenden Befehle:
# find /usr/ports -name "apache2" -print
oder
# cd /usr/ports && make search name=apache-2
Daraufhin erscheint etwa folgende Ausgabe:
Port:
Path:
Info:
Maint:
Index:
B-deps:
R-deps:
apache-2.0.48_1
/usr/ports/www/apache2
Version 2 of the extremely popular Apache http server
[email protected]
www ipv6
expat-1.95.6_1 libtool-1.3.5_1
expat-1.95.6_1
Die Befehle liefern korrekterweise das Verzeichnis /usr/ports/www/apache2, in dem der
Apache in der Version 2.0.48 zu finden ist. Wechseln Sie in dieses Verzeichnis und
starten Sie die Installation des Apache 2 inklusive aller zusätzlich benötigten Bibliotheken:
# make install
Sobald die Installation abgeschlossen ist, können Sie sich ein Bild über den Umfang
und den Standort der durch die Ports-Sammlung installierten Variante des Apache
machen. Suchen Sie dazu in der Datenbank der lokal installierten Software nach dem
Apache:
# pkg_info | grep apache
Die Suche liefert Ihnen den genauen Namen, die Version und eine Beschreibung des
Apache zurück:
apache-2.0.48_1
Version 2 of the extremely popular Apache http server
Sie erhalten den Umfang und den Standort der neu installierten Dateien, indem Sie
den vollständigen Namen der Software an den Befehl pkg_info übergeben, wie folgendes Beispiel zeigt:
# pkg_info –L apache-2.0.48_1
2.7 Installation unter (Free-) BSD
59
Die Ausgabe ist sehr lang, benutzen Sie den Befehl more, um seitenweise durch die
Liste der installierten Dateien und Verzeichnisse mit Hilfe der (Bild_½)- und
(Bild_¼)-Taste blättern zu können:
# pkg_info –L apache-2.0.48_1 | more
Die Darstellung der Liste der installierten Dateien können Sie durch Betätigen der
Taste (Q) beenden. Der Apache wurde, wie Sie der Bildschirmausgabe entnehmen
können, in folgende Verzeichnisse installiert:
/usr/local/man
Die Manpages des Apache, die die Benutzung der mitgelieferten Programme erklären, befinden sich in diesem Verzeichnis. Sie können diese Hilfeseiten durch
Eingabe des Befehls man Befehlname aufrufen. Um beispielsweise die Hilfeseiten
zum Befehl htpasswd zu erhalten, rufen Sie den Befehl man htpasswd auf.
/usr/local/bin
Speicherort der Dateien apr-config und apu-config, die einen standardisierten Zugriff auf die Kommandozeilenoptionen der Konfigurationsparameter der Apache
Portable Runtime bereitstellen.
/usr/local/etc/apache2
In diesem Verzeichnis werden die Konfigurationsdateien wie httpd.conf des Apache gespeichert.
/usr/local/etc/rc.d
Enthält ein Startskript namens apache2.sh zum automatischen Start des Apache
beim Systemstart.
/usr/local/include/apache2
Die Include- und Header-Dateien des Apache sind in diesem Verzeichnis gespeichert.
/usr/local/lib/apache2
Die durch den Apache bereitgestellten Bibliotheken sind in diesem Verzeichnis gespeichert und stehen dort dem System zur Verfügung.
/usr/local/libexec/apache2
Die als Dynamic Shared Objects (DSO) kompilierten Module des Apache sind in diesem Verzeichnis gespeichert. Dies sind die Module dav_fs, proxy, access, deflate,
proxy_connect, actions, dir, proxy_ftp, alias, env, proxy_http, asis, expires, rewrite,
auth, ext_filter, setenvif, auth_anon, headers, speling, auth_dbm, imap, ssl,
auth_digest, include, status, autoindex, info, unique_id, cern_meta, log_config,
userdir, cgi, mime, usertrack, cgid, mime_magic, vhost_alias, dav und negotiation.
/usr/local/sbin
Die ausführbaren Programme und Skripte des Apache wie apachectl sind in diesem
Verzeichnis gespeichert.
60
2 Installation
/usr/local/share/apache2
Einige zur Installation des Apache benötigte Skripte lagern in diesem Verzeichnis.
/usr/local/share/doc/apache2
Das komplette Handbuch des Apache liegt im HTML-Format in diesem Verzeichnis vor.
/usr/local/www
Das Datenverzeichnis des Apache, in dem u.a. die im Internet zu veröffentlichenden Informationen gespeichert sind. Dazu gehören außerdem die im Falle eines
Fehlers durch den Server angezeigten Fehlermeldungen sowie zahlreiche Icons.
Die eigentliche Installation des Apache 2 unter FreeBSD ist damit abgeschlossen.
2.8
Installation unter Sun Solaris
Natürlich stehen Ihnen unter Sun Solaris, ebenso wie unter allen Unix/Linux-Varianten, alle bereits beschriebenen Installationswege (./configure etc.) zur Verfügung. Die
Installation des Apache 2 unter Sun Solaris lässt sich jedoch stark vereinfachen, indem
man sich der Solaris-eigenen Paketverwaltung bedient. Als Basis für die hier vorgestellten Installationsschritte dient eine Grundinstallation (Core) von Sun Solaris 8
(Intel), die insgesamt knapp 750 MB umfasst. Benötigt werden drei CD-ROMs von
Sun Solaris 8 sowie einige Dateien aus dem Internet. Sollten Sie die Programme (z.B.
gcc) bereits installiert haben, können Sie diese Beschreibung getrost überspringen.
2.8.1
Installation von wget und gunzip
Sofern Sie das Programm wget noch nicht installiert haben, müssen Sie die CD-ROM
Software Companion einlegen und in das Verzeichnis /cdrom/s8_software_companion/
components/i386/Packages wechseln. Installieren Sie die Software durch folgenden
Befehl:
# pkgadd -d . SFWwget
Die Dekomprimierungssoftware gunzip finden Sie auf der CD Software 2 im Verzeichnis /cdrom/sol_8_701_ia_2/Solaris_8/Product. Auch hier erfolgt die Installation einfach
unter Verwendung der Paketverwaltung von Sun Solaris:
# pkgadd -d . SUNWgzip
Die weitere Installation der benötigten Programme und Erweiterungen sollte nun reibungslos funktionieren.
2.8.2
Installation des Compilers gcc
Auf der Internetseite http://www.sunfreeware.com finden Sie eine große Anzahl an freien
Programmen für Sun Solaris. Laden Sie sich den Compiler gcc entweder von der Inter-
2.8 Installation unter Sun Solaris
61
netseite herunter oder legen Sie die CD-ROM Software 1 von Sun Solaris 8 ein und
mounten Sie diese. Auf der CD befinden sich zwei Softwarepakete, die Sie vor der
Installation des gcc installieren müssen. Wechseln Sie dazu in deren Basisverzeichnis:
# cd /cdrom/sol_8_701_ia/s2/Solaris_8/Product
Kopieren Sie die beiden Programme in ein temporäres Verzeichnis (z.B. /tmp):
# cp -R SUNWscpu SUNWtoo /tmp
Verfahren Sie ebenso mit der CD-ROM Software 2 von Sun Solaris 8 und wechseln Sie
in folgendes Verzeichnis auf der zweiten CD:
# cd /cdrom/sol_8_701_ia_2/Solaris_8/Product
Aus diesem Verzeichnis müssen Sie die folgenden Verzeichnisse auf die Festplatte
Ihres Systems kopieren:
# cp -R SUNWhea SUNWsrh SUNWbtool SUNWlibm SUNWsprot SUNWarc /tmp
Sobald der Kopiervorgang abgeschlossen ist, müssen Sie in das temporäre Verzeichnis (z.B. /tmp) wechseln und können dort die Installation der kopierten Pakete mit
Hilfe der Softwareverwaltung von Sun Solaris durch folgenden Befehl einleiten:
# cd /tmp
# pkgadd -d .
Bevor die eigentliche Installation des gcc erfolgen kann, müssen Sie von der CD Software Companion das Common GNU Package installieren, welches Sie nach Einlegung
der CD-ROM im Verzeichnis /cdrom/s8_software_companion/components/i386/Packages
finden. Die Installation erledigt nachstehendes Kommando prompt:
# pkgadd -d . SFWgcmn
Endlich können wir uns der Installation des Compilers gcc widmen, die unspektakulär aus dem genannten Verzeichnis /cdrom/s8_software_companion/components/i386/Packages der Software Companion-CD erfolgt:
# pkgadd -d . SFWgcc
Dieser Befehl installiert die Version 2.95.3 des Compilers. Sofern Sie eine neuere Version des gcc installieren möchten, müssen Sie diese von http://www.sunfreeware.com
bzw. http://www.gnu.org herunterladen und manuell installieren.
Schließlich benötigen wir noch das Programm gmake, welches sich auf der Software
Companion-CD in gleichen Verzeichnis befindet, wie der Compiler gcc. Die Installation ist auch hier simpel:
# pkgadd -d . SFWgmake
Damit die neu installierten Programme und Bibliotheken vom System gefunden und
erkannt werden können, müssen Sie in der Datei /etc/default/su die Pfadangabe der
62
2 Installation
Variablen SUPATH anpassen. Öffnen Sie dazu die genannte Datei und ersetzen Sie
den bereits vorhandenen Wert der Variablen SUPATH durch folgende Angabe:
SUPATH=/opt/sfw/bin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/u
sr/ccs/bin:/bin:/usr/ucb
Speichern Sie die Datei, loggen Sie sich aus dem System aus und direkt wieder ein,
damit die Änderungen aktiv werden. Zur Überprüfung der geänderten Pfadangabe
können Sie folgenden Befehl eingeben, der den neu definierten Pfad vollständig
zurückliefern sollte:
# echo $SUPATH
Die Installation des Compilers gcc sowie diverser externer Bibliotheken und Programme ist damit abgeschlossen.
2.8.3
Autoconf
Laden Sie sich die Version 2.53 der Software Autoconf von der Internetseite ftp://
ftp.sunfreeware.com/pub/freeware/intel/8/autoconf-2.53-sol8-intel-local.gz herunter (Alternativadresse: ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.sunfreeware.com /intel/
8/autoconf-2.53-sol8-intel-local.gz) und entpacken Sie die vorkompilierte Variante:
# gunzip autoconf-2.53-sol8-intel-local.gz
Sobald die Software entpackt ist, kann die Installation auf die gewohnt komfortable
Weise erfolgen:
# pkgadd -d autoconf-2.53-sol8-intel-local
Die Installation von Autoconf unter Verwendung der Softwareverwaltung von Sun
Solaris ist damit abgeschlossen.
2.8.4
Libtool
Die Software Libtool finden Sie im Internet unter ftp://ftp.sunfreeware.com/pub/
freeware/intel/8/libtool-1.4-sol8-intel-local.gz. Sollte dieser Server nicht erreichbar sein,
finden Sie unter ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.sunfreeware.com/
intel/8/libtool-1.4-sol8-intel-local.gz eine alternative Downloadmöglichkeit. Hinweis:
Diese alternative Möglichkeit gilt übrigens auch für Autoconf sowie alle auf der Internetseite http://www.sunfreeware.com erhältlichen Softwarepakete!
Laden Sie sich die Version 1.4 herunter und entpacken Sie diese vorkompilierte Variante:
# gunzip libtool-1.4-sol8-intel-local.gz
2.8 Installation unter Sun Solaris
63
Sobald die Software entpackt ist, kann die Installation auf die gewohnt komfortable
Weise erfolgen:
# pkgadd -d libtool-1.4-sol8-intel-local
Die Installation von Libtool ist damit abgeschlossen.
2.8.5
Manuelle Kompilierung und Installation des
Apache 2 unter Sun Solaris
Die Kompilierung und Installation des Apache 2 unter Sun Solaris ist nach Installation der vorgestellten Softwarepakete mit der bereits erläuterten Vorgehensweise
unter Unix/Linux identisch. Hinweis: Auch für Sun Solaris existieren fertige und vorkompilierte Pakete, die Sie sich von http://nagoya.apache.org/dist/httpd/binaries/solaris/
heruntleraden können, wenn Sie den Apache nicht manuell installieren möchten.
Laden Sie sich zunächst von http://httpd.apache.org die aktuellste Version des Apache
herunter:
# wget http://www.apache.org/dist/httpd/httpd-2.0.43.tar.gz
Nachdem dieser knapp 4 MB große Download beendet ist, können Sie die Software,
im Gegensatz zu vielen anderen Unix/Linux-Varianten, nicht direkt mit dem Programm tar entpacken, sondern müssen einen Umweg über gunzip gehen:
# gunzip -d httpd-2.0.48.tar.gz
Erst jetzt können Sie die Software wie gewohnt mit tar entpacken:
# tar xvf httpd-2.0.48.tar
Wechseln Sie in das neu entpackte Verzeichnis httpd-2.0.48 und rufen Sie das configure-Skript unter Verwendung der von Ihnen gewünschten Optionen auf. Eine Übersicht der verfügbaren Optionen finden Sie in den Erläuterungen zur manuellen Installation des Apache 2 unter Unix/Linux. Ein minimaler Aufruf dieses Skriptes könnte
beispielsweise folgendermaßen aussehen:
# ./configure --prefix=/usr/local/apache2
Wenn dieser Vorgang abgeschlossen ist, können Sie die Kompilierung der Software
starten:
# make
Die Installation in das Verzeichnis /usr/local/apache2 erledigt (wie gewohnt) folgender
Befehl:
# make install
Hinweis
64
2 Installation
Damit Sie den Apache 2 unter Sun Solaris überhaupt starten können, müssen
Sie die Benutzer- und Gruppenkennung, unter der der Server läuft, vor dem
ersten Start ändern. Öffnen Sie dazu die zentrale Konfigurationsdatei httpd.conf
des Apache, die sich im Verzeichnis /usr/local/apache2/conf befindet, und ändern
Sie die Werte für den Benutzer und die Gruppe wie folgt (etwa Zeile 265-266):
User nobody
Group nogroup
Speichern Sie die Datei und starten Sie den Apache 2 unter Sun Solaris:
# /usr/local/apache2/bin/httpd
Rufen Sie die Adresse http://localhost auf und Sie sehen die Startseite des Apache.
Eventuelle Fehlermeldungen finden Sie in der Datei /usr/local/apache2/logs/error_log.
Die Installation unter Sun Solaris ist damit abgeschlossen.
2.9
Installation unter Microsoft Windows
Bevor ich die Installation unter Microsoft Windows darstelle, möchte ich noch auf
Besonderheiten der einzelnen Windows-Versionen eingehen und den Benutzern der
verschiedenen Versionen Hilfestellung geben.
Windows 95:
Falls Sie den Apache mit Windows 95 betreiben wollen, müssen Sie ein Update (Version 2) der Netzwerkbibliothek winsock.dll installieren, welches Sie, falls sich die
Struktur der Microsoft Website nicht mal wieder komplett geändert hat, unter folgender URL finden: http://www.microsoft.com/windows/downloads/bin/W95ws2setup.exe.
Windows 9x/NT:
Unter Windows 9x und NT müssen Sie außerdem den Microsoft Installer (MSI) installieren, da dieser in den beiden Versionen noch nicht enthalten ist. Sie finden (hoffentlich!) alle benötigten Programme auf der Seite http://www.microsoft.com, den direkte Link für den MS Installer für Windows 95 und 98 finden Sie unter
http://www.activestate.com/download/contrib/Microsoft/9x/InstMsi.exe. Für Windows NT
lautet dieser Link http://www.activestate.com/download/contrib/Microsoft/NT/InstMsi.exe.
In den neueren Versionen von Microsoft Windows, d.h. ab ME und 2000, ist der
Microsoft Installer bereits im großen Lieferumfang des Betriebssystems enthalten.
Windows XP:
Um den Apache 2 unter Microsoft Windows XP installieren zu können, muss das
Service Pack 1 installiert sein, welches Sie kostenlos von http://www.microsoft.com/
windowsxp/pro/downloads/servicepacks/sp1/default.asp herunterladen können.
2.9.1
Installation des Apache 2 unter Windows
Die Version 2.0.48 des Apache gibt’s vorkompiliert für Windows direkt unter
http://www.apache.org/dist/httpd/binaries/win32/apache_2.0.48-win32-x86-no_ssl.msi.
2.9 Installation unter Microsoft Windows
65
Laden Sie sich diese Datei herunter und führen Sie das Installationsprogramm durch
Doppelklick auf diese Datei aus.
Hinweis
Abbildung 2.1 Begrüßungsbildschirm der Apache 2-Installation unter Windows
Wie Sie den Bildern entnehmen können, beziehen diese sich auf eine ältere Version des Apache 2. Nichtsdestotrotz erfolgt die Installation der Version 2.0.48
des Apache weiterhin wie beschrieben. Bitte beachten Sie außerdem, dass der
Deutsche Günther Knauf unter http://www.gknw.com/development/apache/ ebenfalls ständig aktualisierte Pakete für den Apache 2 sowie zahlreiche Zusatzmodule für Microsoft Windows kostenlos zur Verfügung stellt. Eine weitere
Anlaufstelle ist die Internetseite http://hunter.campbus.com, die ebenfalls kostenlose Binärpakete des Apache 2 (inklusive Zusatzmodule) für Microsoft Windows anbietet.
Klicken Sie auf Next, um zum nächsten Abschnitt der Installation zu gelangen. Lesen
und akzeptieren Sie die Lizenzbestimmungen, die Grundlage für die Benutzung des
Apache 2.x sind und klicken Sie auf Next.
Lesen Sie die Informationen der Autoren des Apache und klicken Sie abermals auf
Next. Nun erfolgt die Anpassung der Netzwerkkonfiguration des Apache. Falls Sie
den Apache-Server auf einem echten, d.h. einem aktiv im Internet stehenden Webserver betreiben, müssen Sie dort die von Ihrem Provider bzw. Netzwerkadministrator erhaltenen Daten wie Domainname, Netzwerkname etc. eintragen. Handelt es
sich bei dem Server jedoch um einen privaten Server, so sollten Sie keine im Internet
bereits vorhandene Adresse benutzen. Tragen Sie dazu beispielsweise folgende
Daten ein:
66
2 Installation
Abbildung 2.2 Akzeptierung der Lizenzbestimmungen des Apache 2
Abbildung 2.3 Eingabe diverser Informationen bei
der Apache 2-Installation unter Microsoft Windows
2.9 Installation unter Microsoft Windows
67
Diese Einstellungen können Sie nach der Installation jederzeit in der zentralen Konfigurationsdatei httpd.conf ändern. Ich habe den Apache als Dienst installiert, d.h. der
Server startet bei allen Systemstarts für alle lokalen Benutzer auf Port 80, da ich den
Server für Softwareentwicklung nutzen möchte. Durch Betätigen der Schaltfläche
Next können Sie einen Installationstyp auswählen, erfahrene Benutzer können den
Umfang und den Inhalt der Installation individuell anpassen durch Wahl des Typs
Custom, nicht so erfahrene Benutzer wählen besser Typical. Nachdem Sie abermals auf
Next geklickt haben, können Sie noch ein Installationsverzeichnis (z.B. D:\Apache)
auswählen und die Installation durch Betätigen der Schaltfläche Next und Install starten. Freudig gibt der Häuptling die Vollendung der Installation bekannt:
Abbildung 2.4 Endbildschirm der Apache 2-Installation unter Windows
Ein kleines Icon in der Taskleiste mit einer Feder und einem grünen Pfeil deutet auf den
gestarteten Apache-Server hin. Ein Aufruf im Browser der Adresse http://127.0.0.1 bzw.
http://localhost zeigt die Startseite des Apache:
Die eigentliche Installation unter Windows ist nun abgeschlossen.
68
2 Installation
Abbildung 2.5 Willkommensbildschirm des Apache 2
2.9.2
Kompilierung des Apache 2 unter Microsoft
Windows
Wer über die entsprechenden Programme (Visual Studio 6 und Cygwin) verfügt,
kann auch unter Microsoft Windows den Apache selber kompilieren.
Besorgen Sie sich von http://www.cygwin.org die aktuellste Version der Portierung der
wichtigsten Unix/Linux-Programme für Windows und installieren Sie diese Software vollständig. Starten Sie Visual C++ und wählen Sie unter Extras die Optionen.
Wählen Sie dort den Reiter Verzeichnisse und fügen Sie zum Suchpfad der ausführbaren Dateien den Pfad zum Unterverzeichnis Bin Ihrer Cygwin-Installation (z.B.
D:\Cygwin\Bin) hinzu. Dieser Bereich schaut demnach etwa wie folgt aus:
Abbildung 2.6 Pfad für ausführbare Dateien unter VC++
2.9 Installation unter Microsoft Windows
69
Danach beenden Sie Visual C++ komplett. Laden Sie sich nun von http://httpd.
apache.org die aktuelle Version des Apache im Quellcode (9,32 MB) herunter und entpacken Sie diese Datei (z.B. httpd-2.0.48-win32-src.zip) in ein temporäres Verzeichnis
(z.B. D:\httpd-2.0.48). Falls Sie das Modul mod_deflate nutzen möchten, benötigen
Sie außerdem ZLib, eine freie und kostenlose Bibliothek zur Kompression von Daten.
Diese erhalten Sie unter http://www.gzip.org/zlib/ bzw. direkt vom deutschen Mirror
unter ftp://ftp.info-zip.org/pub/infozip/zlib/zlib.zip. Entpacken Sie diese Datei und kopieren Sie das entpackte Verzeichnis in das Unterverzeichnis srclib Ihres entpackten Apache-Quellcodes (z.B. D:\httpd-2.0.48\srclib\zlib).
Sofern Sie auch die Unterstützung von SSL durch mod_ssl benötigen, müssen Sie sich
von http://www.openssl.org die entsprechenden Bibliotheken herunterladen und installieren. Falls Sie keine Unterstützung von SSL wünschen, können Sie diesen Teil überspringen! Laden Sie ansonsten also die aktuellste Version, die Sie unter
http://ww.openssl.org/source/openssl-0.9.7c.tar.gz finden, herunter, entpacken und kopieren Sie diese in ein beliebiges Zielverzeichnis (z.B. D:\OpenSSL). Anmerkung: Bitte achten Sie im Laufe der Installationen unter Windows bei allen Pfadangaben darauf, dass
sich unterhalb des von Ihnen angegebenen Pfades auch die entsprechenden Dateien
befinden und nicht noch ein zusätzliches Verzeichnis, in dem die gesuchten Dateien
enthalten sind. Gerade beim Entpacken von Dateiarchiven mit der Endung .tar.gz, habe
ich dieses Verhalten des Öfteren bemerkt. So wird beim Entpacken des Archivs openssl0.9.7c.tar.gz ein Verzeichnis erstellt, in dem die Datei openssl-0.9.7c.tar liegt. Erst nachdem man diese Datei wiederum entpackt hat, erhält man die im ursprünglichen Archiv
enthaltenen Dateien. Dies ist ein Verhalten, welches ich u.a. am populären Datenkompressionsprogramm Rar bzw. der entsprechenden Windows-Variante entdeckt habe.
Falls das von Ihnen verwendete Datenkompressionsprogramm (z.B. WinZip o.Ä.)
ebenfalls dieses Verhalten aufweist, müssen Sie gegebenenfalls die Pfadangaben auf die
entsprechenden Unterverzeichnisse verweisen lassen, oder die Dateien aus den teilweise mehrfach verzweigten Unterverzeichnissen in ein Hauptverzeichnis kopieren.
Zur Übersetzung von OpenSSL benötigen wir, neben Visual C++, auch Perl. Falls Sie
Perl noch nicht installiert haben, installieren Sie es laut der Anleitung, die dieses Buch
in einem späteren Kapitel beschreibt.
Nachdem Perl installiert ist, müssen wir eine Umgebungsvariable setzen, damit wir
in der MS-DOS-Eingabeaufforderung Perlskripte ausführen können. Benutzer von
älteren Windows-Versionen müssen einen Eintrag in der Datei autoexec.bat vornehmen, die im Hauptverzeichnis Ihres Laufwerkes C: existiert. Öffnen Sie diese Datei
und fügen Sie folgenden Eintrag hinzu, bzw. erweitern Sie die Variable PATH um den
folgenden Eintrag:
set PATH=C:\Windows;C:\Windows\Command;D:\Perl
Passen Sie diese Verzeichnisangabe ggfs. an Ihre lokalen Einstellungen an und starten
Sie Ihr System komplett neu. Falls Sie den korrekten Pfad zur Datei perl.exe nicht kennen, suchen Sie diese Datei mit dem unter Windows vorgegebenen Suchprogramm
und geben den gefundenen Pfad vollständig in der Datei autoexec.bat an.
Benutzer von moderneren Windows-Versionen (NT, 2000, ME, XP etc.) können die
Umgebungsvariable durch eine Änderung in der Systemsteuerung vornehmen. Für
70
2 Installation
Windows 2000 klicken Sie dazu mit der rechten Maustaste auf den Arbeitsplatz, dort
auf Eigenschaften und auf Erweitert. Durch Betätigen des Knopfes Umgebungsvariablen
gelangen Sie in die Übersicht der aktuell gesetzten Variablen und können durch einen
Klick auf Bearbeiten bestehende Systemvariablen verändern. Bitte verändern Sie den
Wert für die Variable PATH im Bereich der Systemvariablen und nicht in den für den
gerade angemeldeten Benutzer (Umgebungsvariablen genannt). Fügen Sie zur Variable PATH den Wert D:\Perl\bin (bzw. Ihr Perl-Verzeichnis) hinzu. Alternativ können Sie auch in der Eingabeaufforderung die Definition einer neuen Umgebungsvariable vornehmen. Dazu benutzen Sie in der MS-DOS-Eingabeaufforderung folgenden
Befehl (für Windows 2000, lokales Windowsverzeichnis ist C:\WinNT):
set PATH=D:\Perl\bin;C:\WinNT\system32;C:\WinNT
Die Eingabe von set bzw. echo %PATH% in der Eingabeaufforderung zeigt alle definierten Umgebungsvariablen an und gibt Ihnen die Gelegenheit die korrekte Definition der Variable PATH zu überprüfen. Ebenso sollte nun die Eingabe von perl --help
in der MS-DOS-Eingabeaufforderung die Hilfe von Perl anzeigen. Falls dies nicht der
Fall ist und eine Meldung erscheint, dass der Befehl entweder falsch geschrieben sei
oder nicht gefunden werden konnte, dann ist die Variablendefinition von PATH
falsch und bedarf einer Korrektur.
Starten Sie nun die MS-DOS-Eingabeaufforderung und wechseln Sie in das Verzeichnis, in das Sie das OpenSSL-Archiv entpackt haben (z.B. D:\OpenSSL). Starten Sie den
Installationsprozess von OpenSSL durch die Eingabe von
perl Configure VC-WIN32 --prefix=D:/SSL_fertig
Das hier angegebene Verzeichnis D:\SSL_fertig müssen Sie eventuell an das von
Ihnen gewählte Verzeichnis der OpenSSL-Installation anpassen (Achtung: Der Forwardslash »/« im Beispiel ist kein Tippfehler!). Danach geben Sie folgenden Befehl
ein, um die Assemblerroutinen zu starten:
ms\do_masm
Gefolgt von einem Microsoft-spezifischen Skript, welches Sie durch den Befehl
ms\do_ms
ausführen. Nun können Sie durch den Befehl
nmake /f ms\ntdll.mak
die Kompilierung der OpenSSL-Bibliotheken unter Windows starten. Voraussetzung
dafür ist allerdings, dass der Befehl nmake sich im Systempfad befindet, was nach
einer Installation von Visual C++ bzw. Visual Studio eigentlich automatisch
geschieht. Sobald die Kompilierung abgeschlossen ist, müssen Sie die erzeugten Programme per Hand installieren. Falls Sie sich noch nicht im temporären Installationsverzeichnis von OpenSSL befinden (z.B. D:\OpenSSL), wechseln Sie in dieses Verzeichnis und geben Sie in der MS-DOS-Eingabeaufforderung die nachfolgenden
Befehle ein, wobei Sie eventuell das hier beispielhaft gewählte Installationsverzeich-
2.9 Installation unter Microsoft Windows
71
nis D:\SSL_fertig an Ihre eigenen Einstellungen und Verzeichnisstrukturen anpassen
müssen:
mkdir D:\SSL_fertig
mkdir D:\SSL_fertig\bin
mkdir D:\SSL_fertig\lib
mkdir D:\SSL_fertig\include
mkdir D:\SSL_fertig\include\openssl
copy inc32\OpenSSL\* D:\SSL_fertig\include\openssl
copy /b out32dll\ssleay32.lib D:\SSL_fertig\lib
copy /b out32dll\libeay32.lib D:\SSL_fertig\lib
copy /b out32dll\ssleay32.dll D:\SSL_fertig\bin
copy /b out32dll\libeay32.dll D:\SSL_fertig\bin
copy /b out32dll\openssl.exe D:\SSL_fertig\bin
Fügen Sie das Unterverzeichnis bin des von Ihnen gewählten Verzeichnisses der
OpenSSL-Installation (z.B. D:\SSL_fertig\bin) dem Systempfad hinzu, so wie Sie es
eben mit dem Pfad zum Programm Perl gemacht haben. Schließlich kopieren Sie nun
das gesamte OpenSSL-Verzeichnis (z.B. D:\OpenSSL) in das Unterverzeichnis srclib
des entpackten Apache-Quellcodes (z.B. D:\httpd-2.0.48\srclib\openssl). Die Kompilierung und Installation der OpenSSL-Bibliothek ist damit abgeschlossen.
Nachdem die Installation von OpenSSL abgeschlossen ist, starten Sie nun erneut
Visual C++ und öffnen Sie die Datei Apache.dsw, die sich in dem entpackten, temporären Verzeichnis des Apache-Quellcodes (z.B. D:\httpd-2.0.48) befindet. Wählen Sie
den Menüpunkt Erstellen und dort Aktive Konfiguration festlegen. Es öffnet sich das
Fenster Projektkonfiguration, in dem Sie als Projekt bitte InstallBin – Win32 Release auswählen. InstallBin sorgt dafür, dass alle zugehörigen Projekte übersetzt werden und
ruft danach die Datei Makefile.win auf, die die kompilierten Programme (.exe-Dateien,
wie apache.exe) und Bibliotheken (.dll-Dateien, wie libapr.dll) in ein vorher definiertes
Verzeichnis installiert. Um die Kompilierung zu starten, wählen Sie den Menüpunkt
Erstellen und dort Alles neu erstellen. Die eventuell auftretenden Warnmeldungen
eines 16-Bit-MS-DOS-Teilsystems (was auch immer das sein mag) können getrost
ignoriert werden. Eventuell schlummert unter der Haube meines Windows 2000Rechners noch ein Windows 3.x, aber das vermag ich nicht genau zu sagen, hier
müsste man mal die Zeugen im inzwischen beendeten Microsoft-Prozess befragen.
Sobald die Kompilierung abgeschlossen ist, befindet sich im Hauptverzeichnis des
Laufwerkes, auf dem auch der entpackte Apache-Quellcode schlummert, ein neues
Verzeichnis namens Apache2 (z.B. C:\Apache2), in das der komplette Apache installiert worden ist.
Um das Installationsverzeichnis zu ändern, müssen Sie übrigens in Visual C++ den
Menüpunkt Projekt auswählen und dort den Unterpunkt Einstellungen. Auf der linken
Seite des neu erscheinenden Fensters Projekteinstellungen wählen Sie nur InstallBin aus
und auf der rechten Seite klicken Sie auf den Reiter Allgemein. Unter dem ersten Punkt
Befehlszeile zum Erstellen finden Sie den Befehl, der dem Compiler übergeben wird, um
den Apache zu kompilieren. In dieser Zeile steht:
NMAKE /f makefile.win INSTDIR="\Apache2" SHORT=R LONG=Release_install
72
2 Installation
Sie können nun das bei INSTDIR angegebene Verzeichnis beliebig ändern, um die
Installation beispielsweise nach C:\Programme\Apache2 vorzunehmen, müsste demnach dort Folgendes stehen:
NMAKE /f makefile.win INSTDIR="C:\Programme\Apache2" SHORT=R
LONG=Release_install
Wenn Sie diese Zeile geändert haben, müssen Sie den Apache komplett neu kompilieren, damit die Änderungen wirksam werden. Weitere Optionen, die Sie der Befehlszeile zum Erstellen übergeben können, sind:
Port (Standardwert = 80)
Servername (Standardwert = localhost)
Ein abschließendes Beispiel: Die Befehlszeile zum Erstellen des Apache würde für die
Installation nach C:\Server\Apache2 auf Port 80 für die fiktive Domain http://www.beispiel.de wie folgt aussehen:
NMAKE /f makefile.win INSTDIR="C:\Server\Apache2"
PORT=80 SERVERNAME="www.beispiel.de" SHORT=R
LONG=Release_install
Wenn Sie nun die Kompilierung des Apache testen möchten, starten Sie die MS-DOSEingabeaufforderung, wechseln Sie in das Unterverzeichnis bin Ihrer kompilierten
Apache-Installation (z.B. D:\Apache2\bin) und starten Sie die Datei Apache.exe. Rufen
Sie danach mit Ihrem Browser die Seite http://localhost auf, um die Testseite des Apache zu sehen:
Abbildung 2.7 Willkommensbildschirm des Apache nach manueller Kompilierung
Die Kompilierung und Installation des Apache ist nun abgeschlossen. Im Kapitel Verhalten unter Windows erhalten Sie weitere Informationen über die Verhaltensweise des
Apache unter Microsoft Windows. Außerdem erklärt das Kapitel SSL unter Windows
die Funktionsweise und Konfiguration von mod_ssl unter Windows.
Sollte wider Erwarten beim Start der Apache.exe eine Fehlermeldung erscheinen,
beruht diese meist auf Fehlern in der zentralen Konfigurationsdatei httpd.conf des
Apache. Insbesondere bei der Verwendung von mod_ssl ist mir aufgefallen, dass die
2.9 Installation unter Microsoft Windows
73
Konfigurationsdatei httpd.conf gravierende Fehler enthält, die einen Start des Häuptlings verhindern. Zur Behebung dieser Fehler öffnen Sie die Konfigurationsdatei
httpd.conf, die sich im Unterverzeichnis conf Ihrer selbst kompilierten Apache-Installation befindet, mit einem beliebigen Editor (z.B. notepad, Ultraedit etc.). Suchen Sie in
dieser Datei nach dem Wort ServerRoot und setzen Sie diese Variable auf das Hauptverzeichnis Ihrer Apache-Installation, wobei der unter Dos/Windows zur Kennzeichnung von Verzeichnissen übliche Backslash (»\«) immer durch einen Forwardslash
(»/«) ersetzt werden muss. Bei mir steht dieser Eintrag in der Zeile 57 der Konfigurationsdatei und sieht wie folgt aus:
ServerRoot "D:/Apache2"
Ändern Sie also diesen Eintrag entsprechend. Weiterhin müssen Sie, falls nicht bereits
während der Kompilierung geschehen, einen Port angeben, auf dem der Apache
horcht. Normalerweise ist das der Port 80 und Sie können diesen etwa in Zeile 120
definieren:
Listen 80
Zusätzlich müssen Sie den Namen des Servers (ServerName) definieren, unter dem
der Server später erreichbar ist. Falls Sie über ein bereits konfiguriertes DNS-System
verfügen, müssen Sie als Servernamen Ihren kompletten Namen im DNS-System eingeben (z.B. rechnername.domain.tld). Wenn Sie sich nicht sicher sind, wie Ihr Name
im DNS-System lautet, fragen Sie entweder Ihren Administrator bzw. Ihren Provider
oder tragen Sie (etwa in Zeile 212) einfach den Namen localhost ein:
ServerName localhost
Außerdem müssen Sie, etwa in Zeile 228, das so genannte DocumentRoot-Verzeichnis
setzen. In diesem Verzeichnis lagern alle Inhalte (Bilder, HTML-Dateien etc.), die Sie
im Internet veröffentlichen möchten. Normalerweise nennt sich dieses Verzeichnis
htdocs und liegt unterhalb Ihrer Apache-Installation. Ich habe diese Variable wie folgt
gesetzt, da ich meine Installation des Apache nach D:\Apache2 vorgenommen habe:
DocumentRoot "D:/Apache2/htdocs"
Speichern Sie alle von Ihnen durchgeführten Änderungen in der Datei httpd.conf und
starten Sie die Datei apache.exe erneut. Nun sollten keine weiteren Fehlermeldungen
auftreten und bei einem Aufruf von http://localhost endlich die bekannte Startseite des
Apache erscheinen. Weitere Erläuterungen zum Betrieb eines durch SSL gesicherten
Webservers erhalten Sie im Kapitel über die Konfiguration von SSL.
2.9.3
SSL unter Windows
Normalerweise können Sie die SSL-Erweiterungen für den Apache unter
http://www.modssl.org/contrib/ herunterladen, doch im Moment (Dezember 2003) gibt
es noch keine SSL-Module für den Apache 2.x. Dies mag sich geändert haben, wenn
Sie dieses Buch in den Händen halten, ich musste jedoch den Apache inklusive SSLUnterstützung per Hand kompilieren.
74
2 Installation
Nachdem der Apache erfolgreich kompiliert worden ist, müssen Sie ein Zertifikat
erstellen, welches Ihre Identität gegenüber dem Client preisgibt und Sie als anbietenden Dienst zertifiziert. Zunächst brauchen Sie dazu eine Konfigurationsdatei für
OpenSSL, die leider in der mir vorliegenden Version nicht enthalten ist. Deshalb finden Sie auf der dem Buch beiliegenden CD-ROM im Unterverzeichnis Misc\Win32
ein Verzeichnis namens OpenSSL_cnf, das eine Datei namens Openssl.cnf enthält.
Kopieren Sie diese bitte in das Verzeichnis mit den kompilierten SSL-Bibliotheken
(z.B. D:\SSL_fertig). Starten Sie nun die MS-DOS-Eingabeaufforderung und wechseln
Sie dazu in das Verzeichnis der kompilierten SSL-Bibliotheken (z.B. D:\SSL_fertig).
Achtung: Bei der von mir verwendeten Windows 2000-Version war es nötig, den Verzeichniswechsel durch die Eingabe von cd ssl_fe~1 vorzunehmen, da die Eingabeaufforderung mit einer Verzeichnislänge von mehr als acht Zeichen scheinbar nicht
umgehen kann, obwohl die Eingabe des Befehls dir alle Verzeichnisnamen, inklusive
der mit mehr als acht Buchstaben, ausgibt. Insofern muss man den Verzeichnisnamen
auf sechs Buchstaben kürzen und ein Tildezeichen (»~«) sowie die Zahl eins (»1«)
anhängen. Falls mehrere gleichnamige Verzeichnisse vorhanden sind, muss die Zahl
jeweils um eine Ganzzahl erhöht werden.
Wir wollen uns nun ein Testzertifikat erstellen, um Ihnen zu demonstrieren, wie man
sich ein eigenes Zertifikat erzeugt und wie man ein solches installiert. Starten Sie die
MS-DOS-Eingabeaufforderung und wechseln Sie in das Unterverzeichnis bin des Verzeichnisses mit den erfolgreich kompilierten SSL-Bibliotheken (z.B. D:\SSL_
fertig\bin). Bevor wir mit der Erzeugung eines eigenen Zertifikates beginnen können,
müssen wir zunächst einen privaten Schlüssel für den eigenen Server erstellen:
# openssl genrsa -out server.key -des3 1024
Loading 'screen' into random state - done
warning, not much extra random data, consider using the -rand option
Generating RSA private key, 1024 bit long modulus
................................................................................
..++++++
.............................................++++++
e is 65537 (0x10001)
Enter PEM pass phrase: test
Verifying password - Enter PEM pass phrase: test
Vor der Erzeugung des privaten Schlüssels des Servers müssen Sie einen Passwortsatz
für diesen definieren (kursiv). Anschließend geben Sie den nachfolgenden Befehl ein, um
eine Zertifizierungsanfrage (Certificate Signing Request, csr) zu erzeugen (von mir getätigte Eingaben während der Erzeugung der Zertifizierungsanfrage sind markiert!):
# openssl req –config openssl.cnf –new > test-zertifikat.csr
Sie müssen nun zunächst ein Passwort vergeben, mit dem dieses Zertifikat geschützt
wird. Wählen Sie dieses Passwort mit großer Vorsicht und Bedacht, denn es schützt
Ihr Zertifikat vor ungewollten Veränderungen durch Dritte. Dabei sollte es aus mindestens acht Zeichen bestehen und neben Buchstaben unterschiedlicher Groß- und
Kleinschreibung eventuell auch Zahlen und Sonderzeichen enthalten.
Tipp
2.9 Installation unter Microsoft Windows
75
Benutzen Sie nicht nur ein einfaches Passwort, sondern einen Passwortsatz, der
inhaltlich sinnlos ist und aus Groß- und Kleinbuchstaben, Zahlen sowie Sonderzeichen besteht.
Geben Sie es jetzt das von Ihnen gewählte Kennwort ein (wird bei der Eingabe nicht
angezeigt) und bestätigen Sie dieses durch eine erneute Eingabe:
Enter PEM pass phrase: test
Verifying password - Enter PEM pass phrase: test
Nun müssen Sie zahlreiche Informationen eingeben, die später im Zertifikat angezeigt werden und Ihre Identität gegenüber dem Client preisgeben (Eingaben sind
kursiv):
Country Name (2 letter code) []: DE
State or Province Name (full name) []: Nordrhein-Westfalen
Locality Name (eg, city) []: Duesseldorf
Organization Name (eg, company) []: Fantasie AG
Organizational Unit Name (eg, section) []: Marketing
Common Name (eg, your websites domain name) []: localhost
Email Address []: [email protected]fantasie-ag.de
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: test
Bitte beachten Sie: Die unter Common Name getätigte Eingabe muss absolut mit Ihrer
vollen Internetadresse (z.B. www.beispiel.de) übereinstimmen, da es ansonsten später
auf dem Client zu einer Warnmeldung kommt. Falls Sie sich unsicher sind über Ihre
vollständige Internetadresse bzw. diese Ihnen noch nicht bekannt ist, wählen Sie einfach localhost.
Jetzt entfernen wir die Passphrase vom privaten Schlüssel, damit wir den Passwortsatz nicht bei jedem Start des Servers eingeben müssen:
# openssl rsa -in server.key -out test-zertifikat.key
read RSA key
Enter PEM pass phrase: test
writing RSA key
Schließlich erstellen wir das ganze Zertifikat gemäß den eben von uns getätigten Eingaben für einen Zeitraum von einem Jahr (365 Tage) und unterschreiben es selbst:
# openssl x509 –in test-zertifikat.csr -out test-zertifikat.cert –req -signkey
test-zertifikat.key –days 365
Loading 'screen' into random state - done
Signature ok
subject=/C=DE/ST=Nordrhein-Westfalen/L=Duesseldorf/O=Fantasie
AG/OU=Marketing/CN=localhost/[email protected]
Getting Private key
76
2 Installation
Das Zertifikat ist nun erstellt und wir müssen das von uns erstellte und unterschriebene Zertifikat dem Apache zur Verfügung stellen. Erzeugen Sie dafür im Unterverzeichnis conf des Apache ein Verzeichnis namens SSL und kopieren Sie die Dateien
test-zertifikat.key und test-zertifikat.cert in dieses neu erstellte Verzeichnis.
Nun müssen Sie Änderungen an der Datei httpd.conf vornehmen, damit das SSLModul geladen wird und ein virtueller Host für Ihre SSL-gesicherte Seite zur Verfügung steht. Öffnen Sie dazu die Datei httpd.conf im Unterverzeichnis conf des Apache
und fügen Sie die nachfolgende Zeile hinzu, die das SSL-Modul lädt (sofern noch
nicht vorhanden):
LoadModule ssl_module modules/mod_ssl.so
Außerdem müssen Sie einen weiteren Port definieren, auf dem der Apache auf eingehende Clientanfragen wartet. Laut Definition ist der Port 443 (TCP und UDP) für SSL
vorgesehen. Fügen Sie deshalb zusätzlich zur bereits vorhandenen Listen-Anweisung
die folgende Option hinzu:
Listen 443
Ferner benötigen Sie noch diese SSL-Optionen, die Sie ebenfalls in die Datei httpd.conf
einfügen:
SSLMutex sem
SSLRandomSeed startup builtin
Schließlich müssen Sie noch einen virtuellen Host für Ihre SSL-Seite definieren. Fügen
Sie dazu beispielsweise die folgenden Einträge in die Konfigurationsdatei httpd.conf
ein, wobei Sie die Verzeichnisse eventuell noch an Ihre lokalen Gegebenheiten anpassen müssen:
<VirtualHost 127.0.0.1:443>
ServerName localhost
DocumentRoot D:/Apache2/htdocs
SSLEngine On
SSLCertificateFile conf/ssl/test-zertifikat.cert
SSLCertificateKeyFile conf/ssl/test-zertifikat.key
</VirtualHost>
Listing 2.1 Auszug einer Beispielkonfiguration von SSL unter Windows
Bitte beachten Sie, dass die Backslashes (»\«) in den Verzeichnisangaben abermals
durch Forwardslashes (»/«) ersetzt werden müssen. Die Option SSLEngine On aktiviert die SSL-Implementierung und die beiden Optionen SSLCertificateFile und SSLCertificateKeyFile geben den vollständigen Pfad des jeweils gültigen SSL-Zertifikates
sowie dessen Schlüssel an.
Starten Sie nun die Apache.exe und schauen Sie sich die Seite https://localhost an. Es
erscheint in etwa das folgende Bild:
Sie werden durch Ihren Browser auf ein Zertifikat hingewiesen, welches von einer
nicht als vertrauenswürdig eingestuften Quelle unterschrieben, d.h. ausgestellt wor-
2.9 Installation unter Microsoft Windows
77
Abbildung 2.8 Sicherheitshinweis zu einem selbsterzeugten Zertifikat
den ist. Der Browser stuft das Zertifikat deshalb als nicht vertrauenswürdig ein, da
wir es selbst unterschrieben haben und praktisch uns selber bescheinigt haben, dass
wir eine vertrauenswürdige und sichere Quelle sind. Durch Betätigen der Schaltfläche Zertifikat anzeigen können wir die in diesem Zertifikat enthaltenen Informationen
zur Identität des Urhebers einsehen:
Abbildung 2.9 Detailinformationen zu einem Zertifikat
Die von uns eingangs getätigten Eingaben erscheinen im Zertifikat und schnell wird
klar, warum unser Zertifikat als nicht vertrauenswürdig eingestuft wird: So wie ich mir
eben die Eingaben ausgedacht und die Fantasie AG gegründet habe, könnte ich mich
auch als jede andere Institution und Firma ausgeben und eventuell durch geschickt
abgekupferte Webseiten ahnungslose Surfer um deren Kreditkartennummern etc.
erleichtern. Der Client wird diese Sicherheitsmeldung so lange bekommen, bis Sie Ihr
78
2 Installation
Zertifikat durch eine Institution signieren haben lassen, die Ihrem Browser bekannt ist
und als sicher, d.h. vertrauenswürdig eingestuft wird. Bekannte Zertifizierungsstellen
sind u.a. Verisign (http://www.verisign.com) und Thawte (http://www.thawte.com), wobei
ein von denen signiertes Serverzertifikat etwa 200 USD pro Jahr kostet.
Dies war eine sehr abgespeckte Einführung in die Verwendung von SSL unter Windows. Weitere Grundlagen, Erklärungen und Informationen zu SSL und dessen Verwendung finden Sie im Kapitel über mod_ssl.
2.10
Apache für absolute Anfänger (XAMPP)
Dieses Kapitel richtet sich ausschließlich an Anfänger, die mit dem Apache sowie den
zusätzlich verfügbaren Programmen und Erweiterungen (z.B. PHP, MySQL etc.) bisher noch keine oder kaum Erfahrung haben. Ich kann mir gut vorstellen, dass einige
der in diesem Buch besprochenen Themen für Anfänger zu kompliziert sind und
möchte daher an dieser Stelle einfach und verständlich auf die Installation des Apache sowie zahlreicher Erweiterungen anhand vorgefertigter Pakete unter Windows
und Linux eingehen. Unter http://www.apachefriends.org bieten Kai ’Oswald’ Seidler
und Kay Vogelsang fertige Pakete (so genannte XAMPP) für Windows und Linux an,
mit deren Hilfe in sehr kurzer Zeit eine voll funktionsfähige Entwicklungsumgebung,
bestehend unter anderem aus Apache, MySQL, Perl und PHP, installiert werden
kann, ohne dass dafür besondere Voraussetzungen erfüllt sein müssen. Dabei werden
alle Softwareprogramme in ein gemeinsames Verzeichnis installiert, so dass später,
falls gewünscht, auch eine reibungslose Deinstallation von XAMPP möglich ist.
Hinweis
Die Installation dieser beiden Softwarepakete, früher aufgrund der Namen der einzelnen Komponenten häufig LAMPP (Linux, Apache, MySQL, Perl und PHP) und
WAMPP (Windows, Apache, MySQL, Perl und PHP) genannt, möchte ich nachfolgend
kurz vorstellen. Sofern Sie weitere Informationen zu XAMPP und den Apachefriends
suchen, können Sie unter http://www.apachefriends.org/faq.html nachschauen.
Die aufgeführten Softwarepakete sind ebenfalls auf der dem Buch beiliegenden
CD-ROM enthalten, so dass das manuelle Herunterladen von XAMPP nicht
unbedingt notwendig ist.
2.10.1 Installation unter Linux (LAMPP)
Zunächst müssen Sie sich die knapp 22 MB große Version 1.3 von XAMPP für Linux
herunterladen. Geben Sie dazu bei bestehender Internetverbindung folgenden Befehl
ein (eine Zeile):
Hinweis
# wget http://heanet.dl.sourceforge.net/sourceforge/xampp/xampp-linux-1.3.tar.gz
Sollte der Download nicht starten, müssen Sie gegebenenfalls das Programm
wget installieren. Konsultieren Sie dazu bitte das Handbuch Ihrer Distribution.
2.10 Apache für absolute Anfänger (XAMPP)
79
Sobald der Download abgeschlossen ist, können Sie die Software wie folgt in das Verzeichnis /opt entpacken (als root):
# tar xvfz xampp-linux-1.3.tar.gz -C /opt
Erfreulicherweise ist damit die Installation bereits abgeschlossen, da die Programme
in vorkompilierter Form dem Softwarepaket XAMPP beiliegen. Dementsprechend ist
auch der Start des Apache sowie die Aktivierung der zahlreichen Erweiterungen
(MySQL, ProFTP etc.) ein Kinderspiel:
# /opt/lampp/lampp start
Daraufhin erscheint folgende Ausgabe,
Starting XAMPP for Linux 1.3...
LAMPP: Starting Apache with SSL...
LAMPP: Starting MySQL...
LAMPP: Starting ProFTPD...
XAMPP for Linux started.
die den erfolgreichen Start der Software dokumentiert. Sie können nun mit einem
Browser Ihrer Wahl die Willkommensseite von XAMPP unter http://localhost erreichen:
Abbildung 2.10 Willkommensbildschirm von XAMPP 1.3 für Linux
80
2 Installation
Dort stehen Ihnen umfangreiche Informationen (z.B. Zugriffsstatistiken, Beispielskripte oder Statusmeldungen) zur Verfügung, die Sie nach Belieben abrufen können.
Viel einfacher kann die Installation einer vollständigen Entwicklungsumgebung nun
wirklich nicht mehr sein ;-)
Die Software können Sie übrigens durch folgende Eingabe stoppen:
# /opt/lampp/lampp stop
Weitere Informationen zur Verwendung der Software finden Sie unter http://www.
apachefriends.org/lampp.html und http://www.apachefriends.org/faq-lampp.html. Bitte beachten Sie insbesondere die dort aufgeführten Sicherheitshinweise sowie die Vielzahl der
ebenfalls in diesem Softwarepaket enthaltenen Programme (z.B. ProFTP, OpenLDAPClient, OpenSSL etc.).
Wenn Sie eigene Software unter Linux kompilieren möchten, die die durch XAMPP
installierten Erweiterungen verwendet, müssen Sie zusätzlich das Entwicklungspaket
von XAMPP 1.3 (optional) installieren. Laden Sie sich deshalb von http://heanet.dl.
sourceforge.net/sourceforge/xampp/xampp-linux-devel-1.3.tar.gz die aktuelle Version (ca.
19 MB) herunter, entpacken und installieren Sie diese (als root) durch Eingabe von
# tar xvfz xampp-linux-devel-1.3.tar.gz -C /opt
Damit ist die Installation des Entwicklungspaketes von XAMPP ebenfalls abgeschlossen.
2.10.2 Installation unter Windows (WAMPP)
Die Installation der Software XAMPP ist unter Windows ähnlich einfach, wie unter
Linux. Laden Sie sich zunächst von http://aleron.dl.sourceforge.net/sourceforge/xampp/
xampp-win32-1.0.exe die aktuelle Version 1.0 herunter (ca. 23 MB) und führen Sie das
Programm aus (z.B. durch Doppelklick mit der linken Maustaste auf diese Datei):
Abbildung 2.11 Extrahieren von XAMPP 1.0 unter Windows
Wählen Sie zunächst ein Verzeichnis, in das die temporären Dateien von XAMPP entpackt werden sollen und bestätigen Sie dieses durch Betätigen der Schaltfläche
Extract. Nachdem dieser Vorgang abgeschlossen ist, finden Sie in dem von Ihnen
gewählten Verzeichnis ein neues Verzeichnis namens xampp, welches alle Programme
und Dateien von XAMPP enthält. Wechseln Sie in dieses Verzeichnis und führen Sie
die Datei setup_xampp.bat aus, um die eigentliche Installation der Software zu starten:
2.10 Apache für absolute Anfänger (XAMPP)
81
Abbildung 2.12 Startbildschirm der Installation von XAMPP 1.0 unter Windows
Sofern Sie Unterstützung für mod_perl wünschen, müssen Sie in dem erscheinenden
Eingabefenster den Wert 1 eingeben, ansonsten den Wert 2 (im Zweifelsfall 2 wählen)
und durch Betätigen der Taste (Enter) die Auswahl bestätigen. Daraufhin wird die
Installation von XAMPP durchgeführt. Sobald die Installation beendet ist, können Sie
das Eingabefenster durch Betätigen einer beliebigen Taste verlassen und durch Ausführen der Dateien apache_start.bat und mysql_start.bat den Apache sowie MySQL
starten. Mit Ihrem Browser können Sie daraufhin unter http://localhost die Willkommensseite von XAMPP 1.0 für Windows mit zahlreichen Beispielen und Informationen abrufen:
Die reine Installation des Apache (inklusive mod_ssl und gegebenenfalls mod_perl)
sowie MySQL, Perl und OpenSSL ist damit bereits abgeschlossen. Weitere Informationen zur Installation von XAMPP 1.0 unter Windows finden Sie im Internet unter
http://www.apachefriends.org/winxampp/xampp-win32-10.txt. Sie können XAMPP für
Windows übrigens einfach beenden, indem Sie die durch den Start des Apache und
MySQL geöffneten Eingabefenster schließen. Außerdem finden Sie unter
http://www.apachefriends.org/wampp.html und http://www.apachefriends.org/faq-wampp.html
eine Menge weiterer Informationen (z.B. Sicherheitseinstellungen, Installationsverzeichnisse, Anpassungen, FAQ etc.) zu dieser tollen Software.
82
2 Installation
Abbildung 2.13 Willkommensbildschirm von XAMPP 1.0 für Windows
3 Erweiterte Installation
3.1
Anpassung der Installationspfade
Bevor ich nun auf die unterschiedlichen Anpassungsoptionen des Apache eingehe,
möchte ich mich zunächst der Möglichkeit der individuellen Definition der Installationspfade widmen.
Der Apache stellt mehrere Installationslayouts zur Verfügung, d.h. eine Liste mit
möglichen, vordefinierten Installationsverzeichnissen, jeweils optimiert für unterschiedliche Betriebssysteme und entsprechende Varianten. Diese Installationsschemata definieren also Zielinstallationsverzeichnisse und entsprechende Unterverzeichnisse, wie sie standardmäßig auf einer Vielzahl der unterstützten
Betriebssysteme Verwendung finden. Die Layouts werden definiert in der Datei config.layout, die sich im Hauptverzeichnis des entpackten Quellcodes des Apache befindet. Für den mir vorliegenden Apache 2.0.48 sieht diese Datei wie folgt aus:
#
# config.layout -- Pre-defined Installation Path
# Layouts
#
# Hints:
# - layouts can be loaded with configure's
# --with-layout=ID option
# - when no --with-layout option is given, the default
#
layout is `Apache'
# - a trailing plus character (`+') on paths is
#
replaced with a `/<target>' suffix where <target>
#
is currently hardcoded to 'apache2'.
#
(This may become a configurable parameter at some point.)
#
# Classical Apache path layout.
<Layout Apache>
prefix:
/usr/local/apache2
exec_prefix:
${prefix}
bindir:
${exec_prefix}/bin
sbindir:
${exec_prefix}/bin
libdir:
${exec_prefix}/lib
libexecdir:
${exec_prefix}/modules
mandir:
${prefix}/man
sysconfdir:
${prefix}/conf
datadir:
${prefix}
installbuilddir:
${datadir}/build
errordir:
${datadir}/error
iconsdir:
${datadir}/icons
htdocsdir:
${datadir}/htdocs
manualdir:
${datadir}/manual
84
cgidir:
includedir:
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
3 Erweiterte Installation
${datadir}/cgi-bin
${prefix}/include
${prefix}
${localstatedir}/logs
${localstatedir}/logs
${localstatedir}/proxy
# GNU standards conforming path layout.
# See FSF's GNU project `make-stds' document for details.
<Layout GNU>
prefix:
/usr/local
exec_prefix:
${prefix}
bindir:
${exec_prefix}/bin
sbindir:
${exec_prefix}/sbin
libdir:
${exec_prefix}/lib
libexecdir:
${exec_prefix}/libexec
mandir:
${prefix}/man
sysconfdir:
${prefix}/etc+
datadir:
${prefix}/share+
installbuilddir:
${datadir}/build
errordir:
${datadir}/error
iconsdir:
${datadir}/icons
htdocsdir:
${datadir}/htdocs
manualdir:
${datadir}/manual
cgidir:
${datadir}/cgi-bin
includedir:
${prefix}/include+
localstatedir:
${prefix}/var+
runtimedir:
${localstatedir}/run
logfiledir:
${localstatedir}/log
proxycachedir:
${localstatedir}/proxy
</Layout>
# Apache binary distribution path layout
<Layout BinaryDistribution>
prefix:
/usr/local/apache
exec_prefix:
bindir:
bin
sbindir:
bin
libdir:
lib
libexecdir:
libexec
mandir:
man
sysconfdir:
conf
datadir:
installbuilddir:
build
errordir:
error
iconsdir:
icons
htdocsdir:
htdocs
manualdir:
manual
3.1 Anpassung der Installationspfade
cgidir:
includedir:
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
cgi-bin
include
logs
logs
proxy
# Mac OS X Server (Rhapsody)
<Layout Mac OS X Server>
prefix:
/Local/Library/WebServer
exec_prefix:
/usr
bindir:
${exec_prefix}/bin
sbindir:
${exec_prefix}/sbin
libdir:
${exec_prefix}/lib
libexecdir:
/System/Library/Apache/Modules
mandir:
${exec_prefix}/share/man
sysconfdir:
${prefix}/Configuration
datadir:
${prefix}
installbuilddir:
/System/Library/Apache/Build
errordir:
/System/Library/Apache/Error
iconsdir:
/System/Library/Apache/Icons
manualdir:
/System/Library/Apache/Manual
htdocsdir:
${datadir}/Documents
cgidir:
${datadir}/CGI-Executables
includedir:
/System/Library/Frameworks/Apache.framework/Versions/2.0/Headers
localstatedir:
/var
runtimedir:
${prefix}/Logs
logfiledir:
${prefix}/Logs
proxycachedir:
${prefix}/ProxyCache
</Layout>
# Red Hat Linux 7.x
<Layout RedHat>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
layout
/usr
${prefix}
${prefix}/bin
${prefix}/sbin
${prefix}/lib
${prefix}/lib/apache
${prefix}/man
/etc/httpd/conf
/var/www
${datadir}/build
${datadir}/error
${datadir}/icons
${datadir}/html
${datadir}/manual
${datadir}/cgi-bin
85
86
includedir:
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
3 Erweiterte Installation
${prefix}/include/apache
/var
${localstatedir}/run
${localstatedir}/log/httpd
${localstatedir}/cache/httpd
# According to the /opt filesystem conventions
<Layout opt>
prefix:
/opt/apache
exec_prefix:
${prefix}
bindir:
${exec_prefix}/bin
sbindir:
${exec_prefix}/sbin
libdir:
${exec_prefix}/lib
libexecdir:
${exec_prefix}/libexec
mandir:
${prefix}/man
sysconfdir:
/etc${prefix}
datadir:
${prefix}/share
installbuilddir:
${datadir}/build
errordir:
${datadir}/error
iconsdir:
${datadir}/icons
htdocsdir:
${datadir}/htdocs
manualdir:
${datadir}/manual
cgidir:
${datadir}/cgi-bin
includedir:
${prefix}/include
localstatedir:
/var${prefix}
runtimedir:
${localstatedir}/run
logfiledir:
${localstatedir}/logs
proxycachedir:
${localstatedir}/proxy
</Layout>
# BeOS layout...
<Layout beos>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
/boot/home/apache
${prefix}
${exec_prefix}/bin
${exec_prefix}/bin
${exec_prefix}/lib
${exec_prefix}/libexec
${prefix}/man
${prefix}/conf
${prefix}
${datadir}/build
${datadir}/error
${datadir}/icons
${datadir}/htdocs
${datadir}/manual
${datadir}/cgi-bin
${prefix}/include
3.1 Anpassung der Installationspfade
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
# SuSE 6.x layout
<Layout SuSE>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
# BSD/OS layout
<Layout BSDI>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
localstatedir:
${prefix}
${localstatedir}/logs
${localstatedir}/logs
${localstatedir}/proxy
/usr
${prefix}
${prefix}/bin
${prefix}/sbin
${prefix}/lib
${prefix}/lib/apache
${prefix}/man
/etc/httpd
/usr/local/httpd
${datadir}/build
${datadir}/error
${datadir}/icons
${datadir}/htdocs
${datadir}/manual
${datadir}/cgi-bin
${prefix}/include/apache
/var
${localstatedir}/run
${localstatedir}/log/httpd
${localstatedir}/cache/httpd
/var/www
/usr/contrib
${exec_prefix}/bin
${exec_prefix}/bin
${exec_prefix}/lib
${exec_prefix}/libexec/apache
${exec_prefix}/man
${prefix}/conf
${prefix}
${datadir}/build
${datadir}/error
${datadir}/icons
${datadir}/htdocs
${datadir}/manual
${datadir}/cgi-bin
${exec_prefix}/include/apache
/var
87
88
runtimedir:
logfiledir:
proxycachedir:
</Layout>
3 Erweiterte Installation
${localstatedir}/run
${localstatedir}/log/httpd
${localstatedir}/proxy
# Solaris 8 Layout
<Layout Solaris>
prefix:
/usr/apache
exec_prefix:
${prefix}
bindir:
${exec_prefix}/bin
sbindir:
${exec_prefix}/bin
libdir:
${exec_prefix}/lib
libexecdir:
${exec_prefix}/libexec
mandir:
${exec_prefix}/man
sysconfdir:
/etc/apache
datadir:
/var/apache
installbuilddir:
${datadir}/build
errordir:
${datadir}/error
iconsdir:
${datadir}/icons
htdocsdir:
${datadir}/htdocs
manualdir:
${datadir}/manual
cgidir:
${datadir}/cgi-bin
includedir:
${exec_prefix}/include
localstatedir:
${prefix}
runtimedir:
/var/run
logfiledir:
${datadir}/logs
proxycachedir:
${datadir}/proxy
</Layout>
# OpenBSD Layout
<Layout OpenBSD>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
localstatedir:
runtimedir:
/var/www
/usr
${exec_prefix}/bin
${exec_prefix}/sbin
${exec_prefix}/lib
${exec_prefix}/lib/apache/modules
${exec_prefix}/share/man
${prefix}/conf
${prefix}
${prefix}/build
${prefix}/error
${prefix}/icons
${prefix}/htdocs
${datadir}/manual
${prefix}/cgi-bin
${exec_prefix}/lib/apache/include
${prefix}
${prefix}/logs
3.1 Anpassung der Installationspfade
logfiledir:
proxycachedir:
</Layout>
# Debian layout
<Layout Debian>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
# Debian layout
<Layout Debian>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
localstatedir:
${prefix}/logs
${prefix}/proxy
${prefix}/usr
${exec_prefix}/bin
${exec_prefix}/sbin
${exec_prefix}/lib
${exec_prefix}/lib/apache2/modules
${exec_prefix}/bin
${exec_prefix}/sbin
${exec_prefix}/lib
${exec_prefix}/lib/apache/modules
${exec_prefix}/share/man
${prefix}/conf
${prefix}
${prefix}/build
${prefix}/error
${prefix}/icons
${prefix}/htdocs
${datadir}/manual
${prefix}/cgi-bin
${exec_prefix}/lib/apache/include
${prefix}
${prefix}/logs
${prefix}/logs
${prefix}/proxy
${prefix}/usr
${exec_prefix}/bin
${exec_prefix}/sbin
${exec_prefix}/lib
${exec_prefix}/lib/apache2/modules
${exec_prefix}/share/man
${prefix}/etc/apache2
${exec_prefix}/share/apache2
${datadir}/icons
${prefix}/usr/share/apache2/default-site/htdocs
${htdocsdir}/manual
${prefix}/usr/lib/cgi-bin
${exec_prefix}/include/apache2
${prefix}/var/run
89
90
runtimedir:
logfiledir:
proxycachedir:
infodir:
installbuilddir:
errordir:
</Layout>
3 Erweiterte Installation
${prefix}/var/run
${prefix}/var/log/apache2
${prefix}/var/cache/apache2/proxy
${exec_prefix}/share/info
${prefix}/etc/apache2/build
${datadir}/error
Die vordefinierten Layouts und die entsprechenden Installationsverzeichnisse benutzen Werte, die unter den gelisteten Betriebssystemen typisch sind. Dem einen oder
anderen Leser werden die Zielverzeichnisse wahrscheinlich bekannt vorkommen.
Einige Layouts (z.B. SuSE) verstreuen die unterschiedlichen Bestandteile des Apache
in verschiedene Bereiche des Dateisystems, andere Layouts installieren alle Bestandteile in ein Verzeichnis. Beide Methoden haben sicherlich ihre Vor- und Nachteile, ich
habe jahrelang mit dem SuSE-typischen Layout gearbeitet, inzwischen habe ich mich
jedoch sehr an das klassische Layout unter /usr/local/apache bzw. /usr/local/apache2
gewöhnt. Schauen wir uns zur Veranschaulichung beispielsweise das klassische Layout Apache einmal genauer an:
# Classical Apache path layout.
<Layout Apache>
prefix:
/usr/local/apache2
exec_prefix:
${prefix}
bindir:
${exec_prefix}/bin
sbindir:
${exec_prefix}/bin
libdir:
${exec_prefix}/lib
libexecdir:
${exec_prefix}/modules
mandir:
${prefix}/man
sysconfdir:
${prefix}/conf
datadir:
${prefix}
installbuilddir:
${datadir}/build
errordir:
${datadir}/error
iconsdir:
${datadir}/icons
htdocsdir:
${datadir}/htdocs
manualdir:
${datadir}/manual
cgidir:
${datadir}/cgi-bin
includedir:
${prefix}/include
localstatedir:
${prefix}
runtimedir:
${localstatedir}/logs
logfiledir:
${localstatedir}/logs
proxycachedir:
${localstatedir}/proxy
</Layout>
Dieses Layout beginnt mit der Definition der Variable prefix, die auf das lokale Verzeichnis /usr/local/apache2 verweist. Diese Variable gibt das Hauptinstallationsverzeichnis, in das der Apache mit allen Komponenten installiert werden soll, an.
Die folgende Variable exec_prefix verweist ebenfalls auf dieses Verzeichnis und gibt
den Speicherort für architekturabhängige Dateien an. In der Praxis ist dieses Ver-
3.1 Anpassung der Installationspfade
91
zeichnis oft, wie hier im Beispiel zu sehen, mit dem in der Deklaration der Variable
prefix gewählten Verzeichnis identisch.
Das bei bindir definierte Verzeichnis enthält zwei Shellskripte für den Zugriff auf die
Apache Portable Runtime (apr) und die Apache Portable Runtime Utils (apr-utils). Dieses
Verzeichnis ist im Beispiel identisch mit dem Verzeichnis der Variable sbindir, was
meiner Meinung nach durchaus sinnvoll ist. Diverse Zusatzprogramme für den Apache (z.B. htpasswd, apxs etc.) sowie das eigentliche Programm (httpd) lagern im sbinVerzeichnis, hier befindet sich dieses Verzeichnis unter ${exec_prefix}/bin (entspricht
/usr/local/apache2/bin).
Benötigte Bibliotheken (apr, aprutil etc.) werden im Unterverzeichnis lib des bei prefix
angegebenen Verzeichnisses gespeichert (/usr/local/apache2/lib). Die Module werden,
sofern diese als Dynamic Shared Objects (DSO) vorliegen, im durch die Variable libexecdir definierten Unterverzeichnis (z.B. modules) gespeichert.
Im Verzeichnis mandir werden die Manpages des Apache gespeichert, hier als Unterverzeichnis des durch die Variable prefix definierten Verzeichnisses.
Sysconfdir bezeichnet das Verzeichnis, welches alle Konfigurationsdateien des Apache (z.B. httpd.conf) enthält. Hier wird ein Unterverzeichnis namens conf unterhalb
des Hauptverzeichnisses gewählt, viele Distributionen verwenden auch /etc zur Speicherung dieser Dateien.
Das Verzeichnis datadir ist normalerweise den Verzeichnissen installbuilddir, errordir,
iconsdir, htdocsdir, manualdir und cgidir übergeordnet und entspricht, wie hier im Beispiel, meist dem bei prefix angegebenen Verzeichnis (z.B. /usr/local/apache2).
Installbuilddir enthält mehrere Skripte zur Installation diverser Programmteile (u.a.
der DSO-Module) des Apache. Im Beispiel wird dieses Verzeichnis einfach build
genannt.
Ruft ein Client z.B. eine nicht (mehr) existierende Datei auf, so erhält er eine entsprechende Fehlermeldung. Diese und andere Fehlermeldungen sind mehrsprachig im
Verzeichnis error (Variable errordir) gespeichert und können, falls gewünscht, individuell angepasst werden. Abermals ist das Verzeichnis error im Layout ein direktes
Unterverzeichnis des bei prefix angegebenen Verzeichnisses.
Die Variable iconsdir definiert ein Verzeichnis namens icons, in dem diverse kleine
Bildchen (so genannte Icons) gespeichert werden sollen. Diese werden u.a. bei Verzeichnislistings angezeigt und zeigen teilweise die Art einer Datei an (z.B. Icon
movie.gif für diverse Filmformate).
Das bei htdocsdir angegebene Verzeichnis enthält die Inhalte (Bilder, HTML-Dateien
etc.) die ins Internet gestellt und veröffentlicht werden sollen (hier: /usr/
local/apache2/htdocs).
Die kompletten Handbücher (eng. manuals) des Apache 2.x werden in ein Unterverzeichnis namens manual installiert (Verzeichnis manualdir), welches dem bei datadir
angegebenen Verzeichnis unterstellt ist.
Die Common Gateway Interface (CGI)-Skripte werden im Verzeichnis cgi-bin gespeichert (Variable cgidir) und dort mit besonderen Rechten versehen. Ebenfalls ein
Unterverzeichnis von datadir.
92
3 Erweiterte Installation
In der Programmiersprache C geschriebene Headerdateien des Apache werden im
Verzeichnis include gespeichert (Variable includedir), welches auch ein Unterverzeichnis des zentralen Speicherortes prefix (z.B. /usr/local/apache2) darstellt.
Das bei localstatedir angegebene Verzeichnis ist den Verzeichnissen runtimedir, logfiledir und proxycachedir übergeordnet und entspricht meist dem Hauptverzeichnis
(prefix, hier: /usr/local/apache2) des Apache.
Im Unterverzeichnis logs des bei localestatedir (=prefix) angegebenen Verzeichnisses
werden neben den normalen Logfiles, bestimmt durch die Variable logfiledir, auch
laufzeitspezifische Dateien (u.a. Lockfile) gespeichert, wie die Variable runtimedir
definiert.
Die temporären Dateien, der so genannte Cache, des Proxymodules werden im Verzeichnis von proxycachedir gespeichert. Entspricht hier einem eigenen Verzeichnis
namens proxy unterhalb des Basisinstallationsverzeichnisses des Apache.
3.1.1
Erstellung eines eigenen Installationslayouts
Falls Sie mit den vorgegebenen Layouts nicht zufrieden sind, können Sie sich sehr
leicht ein eigenes Installationslayout erstellen. Editieren Sie die Datei config.layout und
fügen Sie einen neuen Bereich ein, beispielsweise durch Kopieren eines bereits vorhandenen Layouts. Ich habe das Standardlayout des Apache kopiert, entsprechende
Änderungen vorgenommen und dieses Layout MeinIndianer genannt:
# MeinIndianer
<Layout MeinIndianer>
prefix:
exec_prefix:
bindir:
sbindir:
libdir:
libexecdir:
mandir:
sysconfdir:
datadir:
installbuilddir:
errordir:
iconsdir:
htdocsdir:
manualdir:
cgidir:
includedir:
localstatedir:
runtimedir:
logfiledir:
proxycachedir:
</Layout>
/usr/local/apache2
${prefix}
${exec_prefix}/bin
${exec_prefix}/bin
${exec_prefix}/lib
${exec_prefix}/modules
${prefix}/man
/etc/apache2
${prefix}
${datadir}/build
/var/www/error
/var/www/icons
/var/www
${datadir}/manual
${htdocsdir}/cgi-bin
${prefix}/include
${prefix}
${localstatedir}/logs
${localstatedir}/logs
${localstatedir}/proxy
3.2 Benutzerdefinierte Installation unter Unix/Linux
93
Geändert habe ich die Variable sysconfdir, da ich Konfigurationsdateien gerne unter
dem Verzeichnis /etc speichere. Zudem habe ich mit htdocs den Speicherort für die zu
veröffentlichenden Inhalte (html-Dateien, Bilder etc.) nach /var/www geändert und die
Variablen errordir, iconsdir und cgidir direkt diesem Verzeichniswechsel angepasst.
Durch ein eigenes Layout können Sie die späteren Zielverzeichnisse der ApacheInstallation beliebig bestimmen. Bedenken Sie jedoch bei der Wahl der entsprechenden Verzeichnisse, dass Sie an einigen Dateien des Apache eventuell Änderungen
vornehmen und deshalb diese Dateien zu einem späteren Zeitpunkt wieder finden
müssen! Ich finde es sehr hilfreich, wenn die Installation unterhalb eines Verzeichnisses vorgenommen wird, da man so sicherlich schnell alle benötigten Dateien und Verzeichnisse findet. Insbesondere wenn der Apache im Zuge eines Updates oder einer
Neuinstallation gelöscht werden soll, ist eine auf mehrere Verzeichnisse verteilte
Installation oftmals problematisch.
Bitte achten Sie auch darauf, dass der Name eines manuell erstellten Layouts keine
Leerzeichen enthalten darf! Sie können das von Ihnen erstellte Layout durch die
Option
--enable-layout=Name an das configure-Skript übergeben und damit aktivieren. Die
Installation mit meinem selbst erstellten Layout erfolgt beispielsweise durch den
Befehl
Hinweis
# ./configure --enable-layout=MeinIndianer
Diesem Befehl können Sie selbstverständlich noch weitere Optionen anfügen.
Die normale Installation des Apache 2 nimmt seinen Lauf und kann durch die Befehle
make und make install abgeschlossen werden. Das eigene Layout wurde ohne Probleme erkannt und akzeptiert:
checking
checking
checking
checking
checking
3.2
for chosen layout... MeinIndianer
for working mkdir -p... yes
build system type... i686-pc-linux-gnu
host system type... i686-pc-linux-gnu
target system type... i686-pc-linux-gnu
Benutzerdefinierte Installation unter
Unix/Linux
Die bereits beschriebene minimale Installation ist natürlich für erfahrene Benutzer
nicht ausreichend, da diese oft sehr angepasste und individuelle Installationen und
Konfigurationen wünschen, die z.B. durch die zielgerichtete Aktivierung von
bestimmten Modulen und die Verwendung gewisser Laufzeitverhalten erreicht werden. Der Apache bietet deshalb eine schier unglaubliche Anzahl an Installationsoptionen, die sich in zahlreichen Variationen zusammenstellen lassen. Nachdem Sie
94
3 Erweiterte Installation
die Software dekomprimiert und in das neu entpackte Verzeichnis httpd-2.0.48
gewechselt haben, können Sie die Übersicht der zur Verfügung stehenden Optionen
durch Eingabe des folgenden Befehls aufrufen:
# ./configure --help
Die Anzahl der Konfigurationsoptionen ist wirklich enorm hoch. Falls Sie diese in
einer angenehmen Form lesen möchten, können Sie auch den Befehl
# ./configure --help | less
nutzen, der Ihnen eine seitenweise Übersicht über die einzelnen Optionen gibt, indem
er die Ausgaben des Befehls configure durch eine so genannte Pipe in das Programm
less umleitet, welches schließlich die seitenweise Anzeige übernimmt. Dabei können
Sie sich durch Betätigen der Leertaste jeweils die nächste Seite anzeigen lassen, oder
mit der (Bild_½)- und (Bild_¼)-Taste nach oben bzw. unten scrollen. Das Betätigen
der Taste (Q) beendet die Auflistung der Optionen durch das Programm less.
Bevor Sie sich der Übersetzung einer individuell auf Ihre Wünsche und Bedürfnisse
zugeschnittenen Version des Apache widmen können, möchte ich Ihnen zunächst
eine Übersicht über die möglichen Konfigurationsoptionen sowie deren Bedeutung
geben:
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
-h, --help
Zeigt eine Übersicht der möglichen Konfigurationsoptionen nebst kleinen Erläuterungen.
--help=short
Zeigt eine kurze (engl. short) Übersicht der
Optionen, wobei diese sich nur auf die ApacheModule beziehen. Die Ausgabe entspricht ebenfalls der Option
--help=recursive.
-V
Versionsinformationen werden angezeigt und
das Programm wird wieder beendet.
-q, --quiet, --silent
Manche Benutzer empfinden die Tests, die configure während des Ablaufes durchführt, als
störend und möchten diese nicht sehen. Durch
Angabe dieses Parameters werden sie nicht mit
angezeigt, allerdings geben diese Ausgaben bei
Problemen oft sehr hilfreiche Hinweise auf mögliche Fehlerursachen.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«)
3.2 Benutzerdefinierte Installation unter Unix/Linux
95
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--cache-file=Datei
Falls man die Ausgaben der durch configure ausgeführten Tests speichern möchte, um diese beispielsweise anderen Programmen oder Benutzern zur Verfügung zu stellen, kann man durch
diese Option eine Datei festlegen, in der die
Ausgaben gespeichert werden sollen.
-C, --config-cache
Diese Option speichert die Ausgabe der Tests
von configure in der Datei config.cache (Standardverhalten).
-n, --no-create
Dadurch werden verschiedene Dateien wie
Makefile etc. nicht erzeugt bzw. nicht gelesen
(z.B. config.status), falls diese schon vorhanden
sind.
--srcdir=Verzeichnis
Macht eine Angabe über den Speicherort der
Quellen des Apache.
--prefix=Präfix
Definition eines Verzeichnisses, in das der
Apache installiert werden soll (Standard:
/usr/local/apache2). Siehe auch die Beschreibung
der Datei config.layout.
--exec-prefix=Präfix
Architekturabhängige Dateien (z.B. httpd etc.)
können in ein spezielles Verzeichnis kopiert
werden, sofern dies gewünscht ist. Eigentlich ist
dies jedoch nicht notwendig, sie werden unterhalb des mit --prefix angegebenen Verzeichnisses
kopiert.
--bindir=Verzeichnis
Verzeichnis für zwei Shellskripte, die Kommandozeilenzugriff auf die Apache Portable Runtime
(apr) und die Apache Portable Runtime Utils
(apr-utils) ermöglichen. Standard:
/usr/local/apache2/bin
--sbindir=Verzeichnis
In diesem Verzeichnis liegen alle ausführbaren
Dateien des Apache (z.B. htpasswd, apxs etc.)
inklusive des eigentlichen Programms (httpd).
Dieses Verzeichnis sollte mit dem bei --bin-dir
angegebenen Verzeichnis identisch sein, da
sonst einige Skripte (z.B. Startskript apachectl)
nicht mehr ohne Benutzereingriff funktionieren.
--libexecdir=Verzeichnis
Verzeichnis für DSO-Module und Bibliotheken.
Standard: /usr/local/apache2/libexec
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
96
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--datadir=Verzeichnis
Ein Verzeichnis für allgemeine Dateien des Apache, dem untergeordnet sind die Verzeichnisse
errordir, iconsdir, htdocsdir, manualdir und cgidir.
Entspricht in der Praxis oft dem bei --prefix
angegebenen Verzeichnis
(Standard: /usr/local/apache2/share).
--sysconfdir=Verzeichnis
Enthält alle Konfigurationsdateien des Apache
(z.B. httpd.conf) sowie einige Beispiele
(Standard: /usr/local/apache2/etc).
--sharedstatedir=Verzeichnis
Veränderbare Daten, die nicht an eine
bestimmte Architektur gebunden sind. In vielen
Konfigurationen unbenutzt (Standard:
/usr/local/apache2/com).
--localstatedir=Verzeichnis
Dieses Verzeichnis ist den Verzeichnissen runtimedir, logfiledir und proxycachedir übergeordnet
und entspricht meist dem Hauptverzeichnis
(--prefix) des Apache (Standard:
/usr/local/apache2/var).
--libdir=Verzeichnis
In diesem Verzeichnis werden die Bibliotheken
der Apache Portable Runtime (apr) und der Apache
Portable Runtime Utils (apr-utils) gespeichert
(Standard: /usr/local/apache2/lib).
--includedir=Verzeichnis
Die Includedateien des Apache, allesamt in C
geschriebene Headerdateien, werden in diesem
Verzeichnis gespeichert
(Standard: /usr/local/apache2/include).
--oldincludedir=Verzeichnis
Falls man einen anderen ANSI C-Compiler
verwendet, als den gcc, so können die Includedateien auch in diesem Verzeichnis (meist
/usr/include) gespeichert werden.
--infodir=Verzeichnis
Die komplette Dokumentation des Apache im
HTML-Format (Standard: /usr/local/apache2/info).
--mandir=Verzeichnis
Die Manualpages (Online-Handbücher)
des Apache
(Standard: /usr/local/apache2/man).
--build=BUILD, --host=HOST,
--target=TARGET
Auf manchen Systemen ist es unter Umständen
nötig, Parameter der Rechnerarchitektur dem
configure-Skript zu übergeben, falls dieses die
entsprechenden Parameter nicht selbst anhand
einiger lokaler Programme (z.B. uname, arch etc.)
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
97
Bedeutung
findet. Sollte in den wenigsten Fällen manuell
gesetzt werden müssen. Auf meinen Systemen
lautete dieser Wert z.B. i686-pc-linux-gnu bzw.
i386-pc-solaris2.8.
--disable-FEATURE
Ein bestimmtes Feature abschalten, entspricht
der Anweisung
--enable-FEATURE=no.
--enable-FEATURE=yes
Ein bestimmtes Feature einschalten, Gegenstück
zu --disable-FEATURE.
--enable-layout=LAYOUT
In der Datei config.layout werden verschiedene
Installationslayouts vorgestellt und können
durch diese Anweisung benutzt werden. Weitere Hinweise zum Aufbau dieser Datei sowie
zur Erstellung eigener Layouts finden Sie im
vorhergehenden Kapitel.
--enable-maintainer-mode
Schaltet den Entwicklermodus ein und gibt
erweiterte Warnmeldungen aus.
--enable-modules=Modulliste
Aktiviert die mit Moduleliste angegebenen
Module im Apache. Mehrere Module müssen
mit Kommata voneinander getrennt und durch
Anführungszeichen eingeschlossen werden.
--enable-mods-shared=Liste
Die hier angegebenen Module werden als Dynamic Shared Objects zur Verwendung mit mod_so
übersetzt. Die Anweisung --enable-modsshared=max sorgt dafür, dass alle Module außer
mod_so und das Kernmodul mod_core als Dynamic Shared Objects übersetzt werden.
--disable-access
Deaktiviert (disable) bzw. aktiviert (enable) die
von Hostnamen und IP-Adressen abhängige
Zugriffskontrolle des Moduls mod_access.
--enable-access
--disable-auth
Schaltet die Benutzerauthentifizierung durch
das Modul mod_auth an bzw. ab.
--enable-auth
--enable-auth-anon
--disable-auth-anon
Falls anonyme Zugriffe auf den Webserver
gestattet werden sollen, müssen Sie dieses
Modul aktivieren (--enable-auth-anon). Ich rate
von der Verwendung dieses Moduls, welches
vergleichbar ist mit dem unsicheren Anonymous FTP, strikt ab (--disable-auth-anon).
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
98
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-auth-dbm
Unter Umständen ist die Authentifizierung der
Benutzer via datenbankähnlicher DBM-Dateien
gewünscht und kann durch --enable-auth-dbm
aktiviert werden. Diese Dateien können durch
das Programm dbmmanage verwaltet werden.
--disable-auth-dbm
--enable-auth-digest
--disable-auth-digest
--enable-file-cache
--disable-file-cache
--enable-echo
--enable-charset-lite
--disable-charset-lite
--disable-cache
Früher wurde das Modul mod_mmap_static verwendet, um beim Start des Apache bestimmte
statische Dateien in den Speicher zu laden und
somit die Zugriffsgeschwindigkeit auf diese
Informationen zu erhöhen. Das Modul wurde
aus dem Apache 2 entfernt und durch
mod_file_cache ersetzt. Falls Sie statische Informationen haben, auf die Sie schnell zugreifen müssen, aktivieren Sie dieses Modul, ansonsten nicht.
Der Apache 2.0 bietet im Gegensatz zu den Vorgängerversionen die nötige Infrastruktur, um
neben dem HTTP- Protokoll auch weitere Protokolle (z.B. FTP und POP3) zu unterstützen und
zu verarbeiten! mod_echo wurde als Beispiel
geschrieben und sollte auf einem Produktionssystem nicht installiert werden, da es lediglich
zur Veranschaulichung dient. Es kann die Daten
einer Clientanfrage gemäß des Echo-Protokolls
direkt wieder an diesen zurückliefern. Ein konkretes Beispiel dazu wird im Laufe dieses
Buches gegeben.
--disable-echo
--enable-cache
Das Modul mod_auth_digest löst die veraltete
Basisauthentifikation (basic authentification) ab
und implementiert die neue MD5-Digest Authentication, die fester Bestandteil der HTTP/1.1
Spezifikation ist. Auch hier aktiviert
--enable-auth-digest das Modul,
--disable-auth-digest schaltet es ab.
Erlaubt Konvertierung von Inhalten in
bestimmte Zeichensätze, die vorher definiert
werden müssen. Gilt noch als experimentell,
--disable-charset-lite und --enable-charset-lite
schalten dieses Modul aus bzw. an.
Falls Sie den Apache auch als Proxyserver
betreiben, müssen Sie dieses Modul aktivieren
(--enable-cache), da es die Cachingfunktionen enthält, die früher direkt in mod_proxy integriert
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
99
Bedeutung
waren. Ansonsten können Sie dieses Modul
deaktivieren (--disable-cache).
--enable-disk-cache
--disable-disk-cache
--enable-mem-cache
--disable-mem-cache
--enable-example
--disable-example
--enable-ext-filter
--disable-ext-filter
--enable-case-filter
--disable-case-filter
--enable-case-filter-in
--disable-case-filter-in
--enable-deflate
--disable-deflate
Das Modul ist experimentell und implementiert
einen mit RFC 2616 kompatiblen Inhaltsspeicher
(http content cache) und bedarf zusätzlich mindestens einem Speichermanagementmodul wie
mod_mem_cache. Gilt bisher als bedingt stabil.
Mod_mem_cache implementiert ein RAM basierendes Speichermanagementmodul und ist das
Gegenstück zu mod_disk_cache. Gilt ebenfalls
noch als experimentell.
Diese Option installiert ein Beispielmodul
(mod_example) für den Zugriff auf die Apacheinterne API (Application Programming Interface) auf dem Server. Dieses Modul ist für
(Modul-) Entwickler gedacht und hat auf einem
Produktivsystem nichts verloren.
Im Gegensatz zu früheren Versionen kann der
Apache ab Version 2.x Daten auch vor der Ausgabe an die Clients an ein externes Programm
liefern, dort verarbeiten lassen und endgültig
ausgeben. Als Ausgabefilter können beispielsweise Sortierungsprogramme oder Ähnliches
verwendet werden, wobei es allgemein jedes
Programm sein kann, welches Daten von der
Standardeingabe einliest, verarbeitet und in die
Standardausgabe schreibt. --enable-ext-filter
aktiviert diese Funktionalität, --disable-ext-filter
deaktiviert sie.
Ein Beispiel für einen Filter, der Daten in Großbuchstaben umwandelt. Aktivierung mit --enablecase-filter, Deaktivierung mit --disable-case-filter.
Ein Beispiel für einen Eingabefilter, der Eingaben in Großbuchstaben umwandelt. Aktivierung
mit --enable-case-filter-in, Deaktivierung mit
--disable-case-filter-in.
Mod_deflate ist ein Ausgabefilter, der Ausgaben
komprimiert, bevor diese an den Client gesendet
werden. Mit
--enable-deflate wird diese Erweiterung aktiviert,
mit --disable-deflate wird sie deaktiviert.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
100
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
Hinweis: Wenn Sie diesen Ausgabefilter verwenden möchten, müssen Sie ebenfalls das
Modul mod_ext_filter aktivieren, da Sie sonst
überhaupt keine externen Filter wie
mod_deflate verwenden können!
--enable-include
--disable-include
--enable-log-config
--disable-log-config
--enable-env
Mit diesem Modul können Dokumente auf dem
Server ausgeführt werden, bevor diese an den
Client gesendet werden. Diese Dokumente werden Server Side Includes (SSI) genannt, inzwischen gibt es für serverseitige Programmierung
weitaus bessere Alternativen. Wird mit
--enable-include aktiviert, --disable-include
deaktiviert den Filter.
Das Modul log_common wurde durch dieses
Modul ersetzt. Es stellt u.a. Zugriffsstatistiken
über die Art und Häufigkeit der aufgerufenen
Webseiten zur Verfügung und zeichnet ebenso
eventuell aufgetretene Fehler auf. Dieses Modul
sollte unbedingt durch --enable-log-config
aktiviert werden!
Umgebungsvariablen aus der Shell können an
den Apache bzw. an ein auf dem Server laufendes Skript übergeben werden. Ebenso können
beliebige Variablen in der Serverkonfiguration
gesetzt werden. Der Einsatz dieses Moduls ist
dringend empfohlen, die Aktivierung erfolgt mit
--enable-env. Falls Sie das Modul nicht benötigen,
können Sie es mit --disable-env abschalten.
--disable-env
--enable-mime-magic
--disable-mime-magic
--enable-cern-meta
--disable-cern-meta
Eine automatische Erkennung des korrekten
MIME-Typen für eine Datei wird durch dieses
Modul bereitgestellt. Sollten Sie auf jeden Fall
aktivieren mit
--enable-mime-magic.
Es gibt eventuell Benutzer, die vom CERN
HTTPD auf den Apache umgestiegen sind und
ihre alten CERN-Meta-Files weiter benutzen
möchten. Durch die Aktivierung dieses Moduls
mit --enable-cern-meta können diese alten
Dateien, die zusätzliche Header an die Clients
senden, auch im Apache benutzt werden. Sollten
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
101
Bedeutung
Sie den CERN HTTPD nicht benutzt haben,
schalten Sie dieses Modul durch
--disable-cern-meta ab.
--enable-expires
--disable-expires
--enable-headers
--disable-headers
Mit mod_expires kann die Dauer der Gültigkeit
einer Information, praktisch deren Lebensdauer,
definiert werden. Ein sehr sinnvolles Modul,
wenn man Informationen veröffentlicht, die nur
einen bestimmten Zeitraum Gültigkeit haben
sollen (z.B. Nachrichten, Aktienkurse etc.).
Es wird durch die Option
--enable-expires eingeschaltet.
Unter Umständen ist es nötig, die HTTP-Header
beliebig zu verändern und Daten zu modifizieren, hinzuzufügen, zu ersetzen oder gar zu
löschen. Falls gewünscht, wird diese Option mit
--enable-headers eingeschaltet, --disable-headers
schaltet sie ab.
--with-gdbm=Pfad
Einige Funktionen des Apache (z.B. RewriteMap
von mod_rewrite) benutzen datenbankähnliche
DBM-Dateien, die im Vergleich zu reinen Textdateien einen erheblichen Geschwindigkeitsvorteil darstellen. Mit dieser Option setzen Sie den
Pfad zur lokalen GDBM-Installation, die für die
Benutzung solcher DBM-Dateien vorhanden
sein muss. Falls kein Pfad angegeben wird, sucht
der Apache in den Suchpfaden des Systems nach
der lokalen Installation. Alternativ kann auch
einer der zwei anderen DBM-Datenbanktypen
(z.B. NDBM) installiert sein.
--with-ndbm=Pfad
Mit dieser Option setzen Sie den Pfad zur lokalen NDBM-Installation, die für die Benutzung
von DBM-Dateien vorhanden sein muss. Falls
kein Pfad angegeben wird, sucht der Apache in
den Suchpfaden des Systems nach der lokalen
Installation. Alternativ kann auch einer der zwei
anderen DBM-Datenbanktypen installiert sein.
--with-berkeley-db=Pfad
Die Option setzt den Pfad zur lokalen Installation der Berkeley DB, die für die Benutzung von
DBM-Dateien vorhanden sein muss. Falls kein
Pfad angegeben wird, sucht der Apache in den
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
102
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
Suchpfaden des Systems nach der lokalen Installation. Alternativ kann auch einer der zwei
anderen DBM-Datenbanktypen installiert sein.
--enable-usertrack
--disable-usertrack
--enable-unique-id
--disable-unique-id
--enable-setenvif
--disable-setenvif
--enable-proxy
Früher als mod_cookies bekannt, versucht dieses
Modul anhand so genannter Cookies die Aktionen des Benutzers zu verfolgen und aufzuzeichnen. Eigentlich nutzlos, denn viele Benutzer lehnen Cookies aufgrund ihres schlechten Rufes ab,
kann mit --disable-usertrack deaktiviert werden.
Mit Hilfe dieses Moduls kann für jede Clientanfrage eine einzigartige (engl. unique) Zahl, eine
so genannte ID, erzeugt werden. Funktioniert
zurzeit nur unter Unix/Linux, nicht unter Windows. Wird mit --enable-unique-id ein bzw. mit
--disable-unique-id ausgeschaltet.
Anhand der bei einer Clientanfrage zur Verfügung stehenden Informationen (u.a. Browserversion, IP-Adresse etc.) lassen sich mit diesem
Modul Umgebungsvariablen setzen. Sollte auf
jeden Fall mit --enable-setenvif aktiviert werden.
Aktiviert bzw. deaktiviert die Proxyfunktionalitäten des Apache. Sofern man keinen Proxyserver betreiben möchte oder eine andere Software
einsetzt (z.B. Squid), sollte man diese Funktion
mit --disable-proxy deaktivieren. Die Aktivierung
dieses Moduls integriert automatisch die
Module proxy_connect, proxy_ftp und proxy_http
in den Server. Unter Umständen benötigen Sie
dieses Modul auch in Verbindung mit
mod_rewrite.
--disable-proxy
--enable-proxy-connect
--disable-proxy-connect
--enable-proxy-ftp
--disable-proxy-ftp
Dieses Modul implementiert die ConnectMethode für das Apache-Proxymodul. Kann
gefahrlos deaktiviert werden mit --disable-proxyconnect, wenn man den Apache nicht als Proxyserver betreibt.
FTP-Routinen für das Apache-Proxymodul.
Können deaktiviert werden
(--disable-proxy-ftp), wenn man den Apache nicht
als Proxyserver betreibt.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
103
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-proxy-http
HTTP- und HTTPS-Routinen für das ApacheProxymodul. Können ebenfalls deaktiviert werden (--disable-proxy-http), wenn man den Apache
nicht als Proxyserver betreibt.
--disable-proxy-http
--enable-ssl
Integriert die SSL-Unterstützung von OpenSSL
in den Apache (--enable-ssl) bzw. schaltet diese
aus (--disable-ssl). Wenn sensible Daten transferiert werden müssen (z.B. Bankdaten, Passwörter, Kreditkartendaten etc.), sollte diese
Erweiterung zwingend aktiviert werden.
--disable-ssl
--enable-optional-hook-export
Testmodul für Apache-interne Funktionen
--disable-optional-hook-export
--enable-optional-hook-import
Testmodul für Apache-interne Funktionen
--disable-optional-hook-import
--enable-optional-fn-import
Testmodul für Apache-interne Funktionen
--disable-optional-fn-import
--enable-optional-fn-export
Testmodul für Apache-interne Funktionen
--disable-optional-fn-export
--enable-bucketeer
--disable-bucketeer
--enable-static-support
--disable-static-support
--enable-static-htpasswd
--disable-static-htpasswd
--enable-static-htdigest
--disable-static-htdigest
Das Modul mod_bucketeer ist ein Test für einen
Ausgabefilter. Es liest eine Textdatei mit speziellen Sonderzeichen (u.a. ^P, ^F und ^Ennn) ein,
um bei Vorhandensein eines solchen Sonderzeichens die Möglichkeit der Ausführung einer
Apache-internen Funktion (sog. Bucket) zu
geben.
Erzeugt statisch gelinkte Versionen der Supportprogramme (--enable-static-support). Bei statisch
gelinkten Versionen sind die benötigten Bibliotheken in den fertigen Binaries enthalten, bei
dynamisch gelinkten Programmen sind diese
nicht im fertigen Programm enthalten, sondern
können als Bibliothek von mehreren Programmen benutzt werden und sparen somit Festplatten- und Arbeitsspeicher.
Generiert eine statisch gelinkte Version von
htpasswd.
Errichtet eine statisch gelinkte Version von
htdigest.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
104
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-static-rotatelogs
Generiert eine statisch gelinkte Version von
rotatelogs.
--disable-static-rotatelogs
--enable-static-logresolve
--disable-static-logresolve
--enable-static-htdbm
Erzeugt eine statisch gelinkte Version von
logresolve.
--disable-static-htdbm
Generiert eine statisch gelinkte Version von
htdbm.
--enable-static-ab
Linkt ab (Apache-Benchmark) statisch.
--disable-static-ab
--enable-static-checkgid
--disable-static-checkgid
--enable-http
--disable-http
--enable-mime
--disable-mime
--enable-dav
--disable-dav
Generiert eine statisch gelinkte Version von
checkgid.
--enable-http aktiviert die HTTP-ProtokollUnterstützung für den Apache,
--disable-http deaktiviert diese Unterstützung
(nicht sinnvoll!).
Mod_mime setzt anhand der Dateiendung einer
Datei den entsprechenden MIME-Typen. MIME
heißt Multipurpose Internet Mail Extension und
sorgt dafür, dass durch vorherige Kennzeichnung des Datentyps ein Client mit empfangenen
Daten überhaupt umgehen kann. Dabei wird ein
MIME-Typ (z.B. text/html) übergeben und der
Client weiß nun, welche Art von Daten er erhält.
Dieses wichtige Modul wird mit --enable-mime
aktiviert, deaktiviert wird es mit --disable-mime.
Aktiviert bzw. deaktiviert die Unterstützung für
WebDav (web-based distributed authoring and versioning), einem Standard, der von namhaften Firmen wie Microsoft, Netscape, Novell, IBM und
Xerox ins Leben gerufen worden ist und der
inzwischen von der unabhängigen IETF WebDav Working Group weiterentwickelt und
überwacht wird
(http://www.webdav.org). Es handelt sich dabei
um eine Erweiterung des HTTP-Protokolls (RFC
2518), die es ermöglicht, Dateien und Verzeichnisse direkt über HTTP auf einem Server zu
bearbeiten.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
105
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-status
Integriert das Modul mod_status in den Apache
bzw. lässt es weg. Mod_status gibt Statusinformationen über die Auslastung und die Aktivität
des Servers aus.
--disable-status
--enable-autoindex
--disable-autoindex
--enable-asis
Fügt mod_asis dem Apache hinzu
(--enable-asis) bzw. entfernt (--disable-asis) dieses
Modul. Es dient zur Sendung von selbstdefinierten HTTP-Headern an den Client.
--disable-asis
--enable-info
Mod_info gibt einen umfassenden Überblick über
die aktuelle Serverkonfiguration, wobei nicht
die laufende Konfiguration angezeigt wird, sondern die Konfiguration, die beim Start des Apache zur Verfügung stand. Ändert man die Konfiguration, so wird diese erst aktiv, wenn der
Server neu gestartet worden ist bzw. die Konfigurationsdateien neu eingelesen worden sind.
Erst nach Einlesen der Konfigurationsdateien
werden diese Änderungen in der Ausgabe von
mod_info sichtbar. --enable-info schaltet dieses
Modul ein, --disable-info schaltet es ab.
--disable-info
--enable-suEXEC
--disable-suEXEC
--enable-cgid
--disable-cgid
Mit dieser Option kann das Modul
mod_autoindex, welches automatisch Verzeichnisindizes erzeugt (vergleichbar mit dem
Befehl ls unter Unix/Linux und dir unter
Dos/Windows), ein(--enable-autoindex) bzw. abgeschaltet
(--disable-autoindex) werden.
Ermöglicht es CGI-Skripten unter der Benutzerkennung eines beliebigen anderen Benutzers
oder Gruppe zu laufen. Wird aktiviert mit
--enable-suEXEC,
--disable-suEXEC lässt das Modul weg.
Unter Unix/Linux ist es mit mod_cgid möglich,
CGI-Skripte mit einem externen CGI-Daemon
auszuführen. Es verhält sich exakt wie mod_cgi,
bietet eine zusätzliche Konfigurationsoption
(ScriptSock) und wird automatisch gewählt,
wenn während des Kompilierungs- und Konfigurationsprozesses ein thread-basierendes
Multi Processing Module (MPM) wie
mpm_leader o.Ä. gewählt wird.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
106
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-cgi
Dieses Basismodul ermöglicht die Ausführung
von CGI-Skripten. Es wird aktiviert mit --enablecgi, falls Sie inzwischen alternative Programmiersprachen zur Entwicklung von dynamischen Webseiten benutzen (z.B. PHP, Java),
können Sie es mit --disable-cgi abschalten.
--disable-cgi
--enable-dav-fs
Mod_dav_fs ist eine Schnittstelle für mod_dav, die
es mod_dav erlaubt, Inhalte des Dateisystems zu
verwalten. Es wird eingeschaltet mit
--enable-dav-fs, abgeschaltet mit --disable-dav-fs
und sollte immer zusammen mit mod_dav
Verwendung finden.
--disable-dav-fs
--enable-negotiation
--disable-negotiation
--enable-vhost-alias
--disable-vhost-alias
--enable-dir
--disable-dir
Mit diesem nützlichen Modul lassen sich lokale
Gegebenheiten auf der Clientseite (z.B. Spracheinstellungen) auswerten und zur Veröffentlichung von benutzeroptimierten Inhalten (z.B.
Startseite in Deutsch) verwenden. Es wird
aktiviert mit
--enable-negotation, falls Sie es deaktivieren
möchten, können Sie dies mit --disable-negotiation
tun. Benutzer- und sprachoptimierte Inhalte
lassen sich auch mit dynamischen Skripten
(z.B. in Perl oder PHP) entwickeln.
Dynamisch konfigurierbares Massenhosting
anhand von vorgefertigten Strukturen des lokalen Dateisystems wird durch dieses Modul
bereitgestellt. Damit entfällt die massenweise
Definition von VirtualHosts in der Konfigurationsdatei httpd.conf des Apaches und neue virtuelle Hosts lassen sich ohne Neustart des
Apache aktivieren. Dieses Modul ist wohl nur
für Massenhoster praktisch und wird mit
--enable-vhost-alias aktiviert,
--disable-vhost-alias schaltet es ab.
Mod_dir stellt die Option DirectoryIndex zur
Verfügung, mit der die Startdatei eines Webangebotes definiert wird. Außerdem leitet es
unvollständige Clientanfragen an die richtige
Adresse weiter. Dieses wichtige Modul wird mit
--enable-dir aktiviert, --disable-dir schaltet es ab.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
107
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-imap
Dieses veraltete Modul stellt serverseitige
Imagemaps bereit. Es wird mit
--disable-imap deaktiviert, --enable-imap aktiviert
es. Dieses Modul findet praktisch keine
Verwendung mehr.
--disable-imap
--enable-actions
--disable-actions
--enable-speling
--disable-speling
--enable-userdir
--disable-userdir
--enable-alias
Mod_actions kann CGI-Skripten bestimmte
MIME-Typen zuordnen und bei Zugriff auf
Dateien dieses Typs diese automatisch ausführen. Mit --enable-actions wird dieses Modul
aktiviert, --disable-actions deaktiviert es.
Mod_speling versucht, durch menschliche Benutzer gemachte Fehler wie falsch eingegebene
Internetadressen, nicht beachtete Groß- und
Kleinschreibung etc. zu korrigieren und dennoch die richtige, ursprünglich gewünschte Seite
zu finden. Das Modul wird mit --enable-speling
eingeschaltet, --disable-speling schaltet es aus.
Mit dem Modul mod_userdir können Benutzer
unter einer vorher festgelegten Adresse (z.B.
www.domain.de/~benutzername) persönliche und
individuelle Inhalte im Internet präsentieren.
Benutzt werden kann dieses Modul mit
--enable-userdir, --disable-userdir schaltet die
Verwendung ab.
Zur Umleitung von internen Pfaden auf andere
Verzeichnisse (sog. Aliase) oder komplette
Weiterleitungen an eine externe Webseite
(sog. Redirect) kann mod_alias benutzt werden.
Es wird mit --enable-alias verwendet,
--disable-alias schaltet es ab.
--disable-alias
--enable-rewrite
--disable-rewrite
Unter Verwendung eines vorher definierten und
auf regulären Ausdrücken basierenden Regelsatzes, können mit mod_rewrite eingehende
Anfragen auf andere Ziele umgeleitet werden.
Es wurde von dem Deutschen Ralf S. Engelschall (http://www.engelschall.com) entwickelt
und wird mit
--enable-rewrite eingeschaltet,
--disable-rewrite schaltet die Benutzung von
mod_rewrite ab.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
108
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--enable-so
Diese extrem wichtige Option bestimmt die Verwendung von Dynamic Shared Objects und wird
mit --enable-so eingeschaltet. Dynamic Shared
Objects erlauben es dem Apache, nachträglich
Module zu installieren und zu verwenden, ohne
den Apache selbst neu zu kompilieren. Dadurch
ist etwa eine Aktualisierung einer Zusatzsoftware wie PHP ohne Modifizierung und Neukompilierung des Apache möglich. Wichtig: Die
als Dynamic Shared Objects zu übersetzenden
Module müssen mit der Zusatzoption
--enable-mods-shared=Modulliste angegeben werden, wobei auch die Verwendung von --enablemods-shared=min bzw. --enable-mods-shared=max
möglich ist! Falls Sie dennoch auf dieses Modul
verzichten möchten, so können Sie dies durch
die Option
--disable-so machen.
--disable-so
--with-PACKAGE=yes
Durch Angabe von --with-package=yes wird die
Benutzung von bestimmten Packages (gemeint
sind hier Modulnamen) explizit angegeben.
Beispielsweise aktiviert die Option
--with-example=yes die Nutzung von mod_example.
--without-PACKAGE
Genauso wie Module explizit aktiviert werden
können, können sie auch explizit deaktiviert
werden. Die Option
--without-example deaktiviert die Verwendung
von mod_example und entspricht ebenfalls der
Option
--with-example=no.
--with-port=Portnummer
Gibt die Portnummer an, unter der der Apache
später erreichbar sein soll. Der Standardport ist
Port 80, die Angabe eines anderen Ports bedarf
bei der Aufrufung einer Internetseite durch
einen Client auch die Angabe des neuen Ports
(z.B. http://www.domain.tld:8000).
--with-z=Verzeichnis
Diese Option erlaubt die Verwendung einer
bestimmten zlib-Datenkompressionsbibliothek.
Das Installationsverzeichnis (z.B. /usr/local) der
alternativen zlib-Bibliothek muss dabei beim
Aufruf übergeben werden mit
--with-z=/usr/local.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.2 Benutzerdefinierte Installation unter Unix/Linux
109
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--with-ssl=Verzeichnis
Durch Angabe eines Verzeichnisses kann mit
der Option ein SSL/TLS-Toolkit verwendet werden. Wurde ein solches Toolkit beispielsweise
nach /usr/local/ssl installiert, so kann dieses
durch die Option --with-ssl=/usr/local/ssl benutzt
werden.
--with-mpm=MPM
Durch die Option --with-mpm=MPM wird der
Apache angewiesen, ein bestimmtes Multi-processing Modul (MPM), d.h. ein bestimmtes Laufzeitverhalten, zu benutzen. Unter Unix/Linux
stehen zurzeit bereits die Module prefork,
perchild, worker, leader und threadpool zur
Verfügung. Unter Windows existiert bisher nur
das MPM winnt, für OS/2 existiert mpmt_os2
und Netware hat das MPM netware.
--with-module=Modultyp:Datei
Mit dieser Option können Module und deren
Moduldateien explizit aktiviert werden, wenn
diese vorhanden sind.
--with-program-name=Name
Hier kann ein alternativer Name für die eigentliche Programmdatei des Apache (z.B. apache2
anstatt httpd) gewählt werden. Die Konfigurationsdatei des Servers wird ebenfalls diesem
Namen angepasst.
--with-suEXEC-bin=Pfad
Definiert den Speicherort von SuEXEC nach der
Installation.
--with-suEXEC-caller=Benutzer
Bestimmt den Benutzer, der später das SuEXECProgramm aufrufen darf, d.h. der Benutzer
unter dessen Kennung der Apache läuft.
--with-suEXEC-userdir=Verzeichnis
Gibt das Verzeichnis an, in dem sich die Webseiten der Benutzer befinden.
--with-suEXEC-docroot=Verzeichnis
Entspricht der Einstellung der Anweisung
DocumentRoot (vgl. DocumentRoot-Anweisung).
--with-suEXEC-uidmin=Benutzerid
Bestimmt die kleinste Benutzerkennung (numerisch), der es erlaubt ist, das Programm SuEXEC
zu benutzen. Aus Sicherheitsgründen sollte
diese Benutzerkennung immer größer sein, als
die Kennung mit der der Apache läuft.
--with-suEXEC-gidmin=Gruppenid
Bestimmt die kleinste Gruppenkennung (numerisch), der es erlaubt ist, das Programm SuEXEC
zu benutzen.
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
110
3 Erweiterte Installation
Option
(Abkürzungen und Synonyme
sind durch Komma getrennt)
Bedeutung
--with-suEXEC-logfile=Datei
Gibt den Speicherort einer Logdatei für SuEXEC
an.
--with-suEXEC-safepath=Verzeichnis
Dieser Parameter bestimmt einen Systempfad
für die durch SuEXEC aufgerufenen CGISkripte.
--with-suEXEC-umask=Umask
Definiert die umask für den SuEXEC-Prozess
Tabelle 3.1 Konfigurationsoptionen und deren Bedeutung
(abgeleitet von »./configure --help«) (Forts.)
3.3
Modulübersicht
Bevor wir mit der Übersetzung und Installation des Apache beginnen, möchte ich in
diesem Kapitel eine kleine Einführung in die modulare Struktur des Apache geben
und die Funktionen der unterschiedlichen Module erklären. Ich halte dies durchaus
für sinnvoll, denn bei der Kompilierung und Installation sind gewisse Grundlagen
und Kenntnisse einfach nötig. Außerdem bekommt man hierdurch einen guten Einblick in die grundlegende Funktionsweise unseres Häuptlings.
Grundsätzlich besteht der Apache zunächst aus einem unabdingbaren Kernmodul
(Quellcode: core.c), welches kompiliert etwa 1,26 MB groß ist und die grundlegendsten
Funktionen definiert. Dieses Modul stellt bestimmte Konfigurationsoptionen (so
genannte Direktive) bereit, die immer zur Verfügung stehen. Dazu kommen eine Reihe
von Standardmodulen, die Teil der offiziellen Apache-Distribution sind und auch
durch die Apache Software Foundation gepflegt werden. Den dritten und letzten Part
stellen die Module der Drittanbieter, die teilweise unter http://modules.apache.org gelistet werden.
3.3.1
Standardmodule
Folgende Module gelten als Standardmodule:
Modulname
Funktion
mod_access
Mit diesem Modul kann der Zugriff auf Inhalte des Webservers
auf Basis von Hostnamen und IP-Adressen kontrolliert werden.
Dies ist beispielsweise sinnvoll, wenn man sensible Daten (Logfileauswertungen o.Ä.) schützen und nur ganz bestimmten
Hosts den Zugriff gewähren will.
Tabelle 3.2 Standardmodule des Apache
3.3 Modulübersicht
111
Modulname
Funktion
mod_actions
Hiermit lassen sich CGI-Skripte bestimmten MIME-Typen
zuordnen und bei Zugriff auf Dateien mit diesem Typ automatisch ausführen.
mod_alias
Mit mod_alias lassen sich URL-Pfade intern auf ein anderes Verzeichnis (Alias) oder komplett an eine andere URL umleiten
(Redirect).
mod_asis
Dieses Modul stellt den Handler send-as-is bereit, der Dokumente
so ausliefern kann »wie sie sind«, d.h. ohne Hinzufügung der
normalen HTTP-Header. Damit lassen sich beliebige Inhalte und
benutzerdefinierte HTTP-Header an den Client senden und
somit beispielsweise Umleitungen (so genannte Redirects)
realisieren.
mod_auth
Mod_auth stellt die drei Directiven AuthGroupFile, AuthUserFile
und AuthAuthoritative zur Verfügung, die zur Konfiguration von
passwortgeschützten Verzeichnissen und Inhalten benötigt werden. Das Modul arbeitet auf Basis von Textdateien und ist die
einfachste Art eines Authentifizierungmoduls.
mod_autoindex
Existiert in einem Verzeichnis keine Indexdatei, erzeugt dieses
Modul einen Verzeichnisindex, der teilweise an die eigenen
Wünsche angepasst werden kann.
mod_cgi
Damit der Apache CGI-Skripte (CGI – Common Gateway Interface) überhaupt ausführen kann, wird dieses Modul benötigt.
mod_cgid
Dieses Modul ist mit mod_cgi fast identisch, allerdings benutzt
es einen externen Daemon zur Ausführung von CGI-Skripten
und wird automatisch benutzt, wenn bei der Kompilierung des
Apache ein multi-threaded MPM gewählt worden ist. Auf die
verschiedenen Laufzeitmodelle werde ich später noch eingehen.
mod_dir
Das Module mod_dir stellt nur eine Konfigurationsoption
namens DirectoryIndex zur Verfügung und diese legt fest, welche
Datei dem Client gesendet wird, wenn dieser ein Verzeichnis
aufruft. Dies ist üblicherweise eine Datei wie index.html oder
index.php. Ruft ein Client beispielsweise die URL http://www.
beispiel.de/infos/ auf, wird automatisch versucht die als DirectoryIndex angegebene Datei zu finden und falls vorhanden an den
Client zu senden. Außerdem vervollständigt dieses Modul
Clientanfragen, wenn diese auf Verzeichnisse zugreifen, aber
den abschließenden Slash (»/«) vergessen haben, und leitet sie
auf die korrekte URL um.
mod_env
Dieses Modul sorgt dafür, dass Umgebungsvariablen aus der
Shell an den Apache bzw. an ein auf dem Server laufendes Skript
übergeben werden können. Ebenso können beliebige Variablen
in der Serverkonfiguration gesetzt und ausgelesen werden.
Tabelle 3.2 Standardmodule des Apache (Forts.)
112
3 Erweiterte Installation
Modulname
Funktion
mod_imap
mod_imap erweitert den Indianer um die Möglichkeit der Nutzung von serverseitigen Image-Maps (so genannte Clickable
Images). Unterstützt ein Clientbrowser keine Bilder (z.B. Textbrowser wie lynx), dann wird automatisch ein Textmenü
erzeugt. Dieses Modul ist meiner Meinung nach überflüssig,
da Imagemaps mit diversen Technologien heutzutage auf dem
Client realisiert werden. Dies wird direkt in das HTML-Dokument eingebettet und teilweise sogar mit Flash oder ähnlich
gelagerten Designmöglichkeiten umgesetzt.
mod_include
Durch dieses Module werden die sog. Server-Side Includes aktiviert, d.h. Dokumente können auf einschließende Verweise auf
externe Datenquellen (z.B. Shellskripte, CGI-Skripte o.Ä.) untersucht werden. Falls solche externen Verweise vorhanden sind,
werden diese ausgeführt und das Ergebnis wird an der Stelle des
Verweises eingefügt. Nachdem alle SSI-Verweise ersetzt worden
sind, wird das Dokument an den Client gesendet.
mod_log_config
Das Modul log_config hat das Modul log_common ersetzt, welches in früheren Versionen des Apache Verwendung fand. Es
erzeugt u.a. Zugriffsstatistiken über die Art und Häufigkeit der
aufgerufenen Webseiten. Diese Statistiken lassen sich mit diversen Programme (z.B. Webalizer, Webtrends etc.) auswerten und
grafisch darstellen. Bei Bedarf lässt sich das Aussehen und der
Inhalt der Logfiles an die eigenen Wünsche anpassen.
mod_mime
Basierend auf der Endung einer Datei (z.B. .html) werden so
genannte MIME-Header (Multipurpose Internet Mail Extensions) erzeugt, die an den Client gesendet werden. Ohne dieses
Kennzeichen könnten die Clients mit den abgerufenen Daten
nichts anfangen. Deshalb gehört dieses Modul zu den absolut
notwendigen und sollte auf jeden Fall statisch oder als Dynamic
Shared Object in den Apache integriert werden.
mod_negotiation
Anhand der HTTP-Header, die ein Client sendet, lassen sich mit
diesem Modul transparent, d.h. für den Client nicht direkt
ersichtlich, Inhalte bereitstellen, die an persönliche Gegebenheiten des Nutzers angepasst sind. Ein Beispiel dafür ist die bei der
Installation des Apache standardmäßig vorhandene Startseite,
die je nach Spracheinstellung des Clients eine entsprechende
Variante (etwa in Deutsch) darstellt.
mod_setenvif
Mit diesem Modul lassen sich anhand der bei einer Clientanfrage
zur Verfügung stehenden Informationen (z.B. IP-Adresse, Browserversion etc.) Umgebungsvariablen setzen. Es wird auch u.a.
dazu verwendet, Funktionalitäten des Apache unter bestimmten
Umständen auszuschalten bzw. zu umgehen.
Tabelle 3.2 Standardmodule des Apache (Forts.)
3.3 Modulübersicht
113
Modulname
Funktion
mod_so
Das mod_so integriert die Möglichkeit des dynamischen Ladens
und Aktivierens von externen Modulen für den Apache, ohne
dass dieser neu kompiliert werden muss. Diese externen Objekte
nennt man Dynamic Shared Objects (DSO). Auf deren Besonderheiten werde ich im Laufe dieses Buches noch genauer eingehen.
mod_status
Wie der Name schon unschwer erkennen lässt, erzeugt dieses
Modul einen Statusbericht der unter einer vorher definierten
Adresse erreichbar ist und u.a. Auskunft gibt über die aktuelle
CPU-Auslastung, die Anzahl der in Bearbeitung befindlichen
Anfragen usw. Ein Beispiel für den Einsatz von mod_status finden Sie unter http://xml.apache.org/server-status?refresh=10.
mod_userdir
Lokale User können mit diesem Modul Ihre privaten Verzeichnisse unter einer gewissen Adresse (http://www.domain.tld/~username/) freigeben und ins Internet stellen.
Tabelle 3.2 Standardmodule des Apache (Forts.)
3.3.2
Module von Drittanbietern
Bekannte Module von Drittanbietern sind außerdem:
Modulname
Funktion
mod_auth_anon
mod_auth_anon ist in etwa vergleichbar mit Anonymous FTP,
d.h. ein Benutzer kann unter Angabe des Benutzernamens anonymous und seiner E-Mail-Adresse authentifiziert werden und
bestimmte (geschützte) Bereiche des Webservers erreichen. Die
Zugriffe können in einem separaten Logfile gespeichert werden.
mod_auth_dbm
Authentifizierung via datenbankähnlicher DBM-Dateien, die mit
dem Programm dbmmanage erstellt und aktualisiert werden
können.
mod_auth_digest
Dieses Modul implementiert die MD5-Digest Authentication, die
fester Bestandteil der HTTP/1.1-Spezifikation ist. Der Vorteil
gegenüber der veralteten Basic Authentication ist, dass die Passwörter der Nutzer nicht mehr im Klartext übertragen werden. Es
gilt noch als experimentell, löst aber das Modul
mod_auth_digest und mod_digest ab. Alle Browser sollten diesen Standard inzwischen unterstützen.
mod_auth_ldap
Ab dem Apache 2.0.41 besteht die Möglichkeit, den Verzeichnisdienst LDAP zur einfachen Authentifikation eines Benutzers zu
verwenden.
Tabelle 3.3 Bekannte Module von Drittanbietern
114
3 Erweiterte Installation
Modulname
Funktion
mod_cache
Ab Apache 1.3.x wurden die Cachingfunktionen aus dem Modul
mod_proxy herausgenommen und in ein separates Modul
(mod_cache) integriert.
mod_cern_meta
Falls Sie vom CERN HTTPD auf den Apache umgestiegen sind,
können Sie dieses Modul dazu benutzen, Ihre CERN-Meta-Files
weiter zu verwenden. Meta-Files sind Dateien, die ähnlich dem
Modul mod_asis zusätzliche HTTP-Header enthalten, die an den
Client gesendet werden können. Mod_header ist auf jeden Fall
diesem Modul vorzuziehen und wenn Sie (wie ich) niemals einen
anderen Webserver außer dem Apache benutzt haben, brauchen
Sie diese Funktionalität nicht.
mod_charset_lite
Hiermit kann der Administrator Zeichensätze definieren, in die
die Inhalte übersetzt werden sollen, bevor diese an den Client
gesendet werden. Es befindet sich derzeit noch in der Entwicklung und gilt als experimentell.
mod_dav
Distributed authoring and versioning ist die Abkürzung dieses
Moduls, zu Deutsch etwa verteile und versionskontrollierte Verwaltung und Entwicklung. DAV gilt inzwischen allgemein als Standard und wird von den meisten Authoringprogrammen wie
Dreamweaver, Frontpage etc. unterstützt. Es bietet praktisch die
Möglichkeit auf Verzeichnisse eines entfernten Webservers zuzugreifen, als sei dieser eine lokale Ressource. Ohne die Benutzung
entsprechender Sicherheitsmechanismen kann man den Einsatz
dieses Moduls nicht verantworten. Die Homepage dieses Moduls
lautet http://www.webdav.org/mod_dav/.
mod_deflate
Mit dem Modul mod_deflate können Sie Informationen komprimieren, bevor diese an einen Client gesendet werden. Dabei ist
das Modul als Ausgabefilter konzipiert und sorgt je nach Typ der
komprimierten Daten zum Teil für große Komprimierungsraten
(>30-50%). Für den Apache 1.3.x existieren unter dem Namen
mod_gzip bzw. mod_gz ähnliche Module.
mod_echo
Dieses Modul veranschaulicht die im Apache 2.x enthaltene
Multiprotokollunterstützung und implementiert einen einfachen
Echo-Server.
mod_example
Dieses Modul dient ausschließlich Demonstrationszwecken und
gibt interessierten Entwicklern Einblick in die Funktionsweise
der Apache API (Application Programming Interface, Programmierschnittstelle). Es dient lediglich der Anschauung und sollte
nicht im Produktionsbetrieb eingesetzt werden.
mod_expires
Durch dieses Modul kann man einem Dokument den HTTPHeader Expires hinzufügen, der die Lebensdauer eines Dokumentes definiert. Dies ist besonders dann sinnvoll, wenn man
Dokumente hat, deren Inhalte sich häufig ändern und von denen
Tabelle 3.3 Bekannte Module von Drittanbietern (Forts.)
3.3 Modulübersicht
Modulname
115
Funktion
immer die jeweils aktuellste Version an den Client gesendet werden soll. So kann man Proxyserver und lokale Zwischenspeicher
auf dem jeweiligen Client umgehen.
mod_ext_filter
Durch das Modul mod_ext_filter können externe Programme,
die Daten von der Standardeingabe lesen, diese verarbeiten und
in die Standardausgabe schreiben, als Filter benutzt werden,
bevor Daten an den Client geschickt werden. Somit lassen sich
Daten beispielsweise sortieren oder anderweitig ver- oder bearbeiten, bevor diese an den Client geschickt werden.
mod_file_cache
Im Apache 1.3.x gab es das Modul mod_mmap_static, welches
inzwischen durch dieses Modul ersetzt worden ist. Beim Start
des Apache können dadurch Dateien direkt im Speicher abgelegt
werden. Diesen Vorgang nennt man Memory Mapping und er
erhöht die Zugriffszeit auf diese Dateien erheblich, da die Daten
direkt aus dem Speicher kommen. Zusätzlich kann das Modul
Dateien beim Start des Servers öffnen und deren geöffneten
Dateihandler speichern. Allerdings werden Veränderungen an
diesen Dateien nicht sofort bemerkt und erst nach einem Neustart des Servers angezeigt. Außerdem kann die Technik nicht
auf CGI-Skripte u.Ä. angewendet werden, da das nur mit »normalen« Dateien funktioniert, die durch das Kernmodul des Apache bereitgestellt werden können. Mod_file_cache gilt bisher als
experimentell und ist mit Vorsicht zu gebrauchen.
mod_headers
Mod_headers kann HTTP-Header beliebig modifizieren, hinzufügen, ersetzen oder auch löschen.
mod_info
Dieses Modul erzeugt eine umfassende Übersicht über die Konfiguration des Servers, die unter einer frei wählbaren URL
erreichbar sein kann.
mod_isapi
Die Möglichkeit der Entwicklung und Nutzung von Internet Server Application Programming Interface (ISAPI) war bisher nur unter
Windows mit dem Internet Information Server (IIS) möglich.
Durch mod_isapi kann man auch mit dem Apache in den Genuss
dieser Erweiterung kommen, allerdings nur unter Microsoft
Windows.
mod_jserv
Mod_jserv ist eine vollständige Java Servlet Engine, die inzwischen jedoch nicht mehr eigenständig weiterentwickelt wird und
mit dem Jakarta-Projekt (http://jakarta.apache.org) verschmolzen
ist. Nun wird Tomcat zur Ausführung von Java Server Pages und
Java Servlets benutzt.
mod_ldap
Um die Geschwindigkeit von Webseiten zu verbessern, die auf
Verbindungen zu LDAP-Verzeichnisdiensten (LDAP=Lightweight Directory Access Protocol) beruhen, wurde dieses Modul
entwickelt. Es sorgt ab dem Apache 2.0.41 für eine gesteigerte
Tabelle 3.3 Bekannte Module von Drittanbietern (Forts.)
116
3 Erweiterte Installation
Modulname
Funktion
Performance u.a. durch Zwischenspeicherung von Ergebnissen
und Bereitstellung von so genanntem Connection Pooling. Diese
Connection Pools sind persistenten Datenbankverbindungen
ähnlich und erlauben den Aufruf mehrerer Abfragen über eine
offene Verbindung zum LDAP-Server.
mod_mime_magic
Basierend auf dem Unix-Befehl file untersucht dieses Modul
Dateien nicht anhand ihrer Endungen, sondern anhand ihrer
Inhalte und versucht so, den richtigen MIME-Typen zu finden
und diesen an den Client zu senden. Es ist besonders hilfreich,
wenn Dateien nicht immer auch eine bestimmte oder bekannte
Endung haben.
mod_perl
Mit mod_perl ist es möglich, die sehr mächtige Programmiersprache Perl zur Entwicklung eigener Apache-Module und
Skripte zu benutzen. Bis zur Entwicklung von mod_perl war die
Entwicklung neuer Module für den Apache nur in C möglich.
Dabei wird der Perl-Interpreter speicherresident geladen. Eine
sehr nützliche Funktion ist außerdem das so genannte CodeCaching, welches Skripte kompiliert, ausführt und danach im
Cache speichert, bis der Server beendet wird.
mod_php
Ursprünglich von Rasmus Lerdorf entwickelte und unter dem
Namen Personal Homepage Tools bekannt gewordene Erweiterung,
die in C geschrieben ist. Inzwischen wird diese Erweiterung als
PHP: Hypertext Preprocessor bezeichnet und hat in den letzten Jahren eine sehr weite Verbreitung gefunden. PHP wird, ebenso wie
Perl, serverseitig ausgeführt und ist laut einer Umfrage von
http://www.securityspace.com mit einem Nutzungsgrad von etwa
53% die beliebteste Apache-Erweiterung. Zum überragenden
Erfolg von PHP haben sicherlich die Schnittstellen zu diversen
Datenbanken (z.B. Oracle, MySQL, Interbase, Sybase etc.), die
dynamische Erzeugung von Grafiken, die Netzwerkfunktionen
und eine gute (inzwischen sogar mehrsprachige) Dokumentation
beigetragen. Die Homepage dieser Erweiterung lautet
http://www.php.net, ein deutscher Mirror ist unter der Adresse
http://www.php3.de erreichbar. Im Moment ist die Version 4.3.4
aktuell, die Version 5 steht jedoch kurz vor der Veröffentlichung.
mod_proxy
Dieses Modul erweitert den Apache um Proxyfunktionalitäten.
Unterstützt wird die HTTP/0.9-, HTTP/1.0- und HTTP/1.1-Spezifikation sowie FTP und SSL. Ich persönlich bevorzuge als Proxyserver die Software Squid (http://www.squid-cache.org), aber in
Verbindung mit mod_rewrite kann dieses Modul unter Umständen durchaus Sinn machen.
mod_rewrite
Das Modul ist 1996 durch Ralf S. Engelschall entwickelt worden
und bietet die Möglichkeit, ähnlich wie mod_alias, interne Aliase
und externe Redirects zu realisieren, wobei diese im Gegensatz
Tabelle 3.3 Bekannte Module von Drittanbietern (Forts.)
3.3 Modulübersicht
Modulname
117
Funktion
zu mod_alias auch auf Basis von regulären Ausdrücken (POSIX
regular expressions) und externen Programmen möglich sind.
mod_speling
Mod_speling korrigiert Tippfehler der Benutzer und versucht dennoch die gewünschte Datei an den Client zu senden. Der Name
mod_speling ist von den Autoren bewusst falsch geschrieben worden und deutet wohl auf die Funktion dieses Moduls hin.
mod_ssl
Basierend auf Apache-SSL entwickelte im April 1998 der Deutsche Ralf S. Engelschall mit mod_ssl sozusagen die Schnittstelle
zwischen Apache und OpenSSL, einer frei verfügbaren SSLBibliothek zur sicheren Verschlüsselung von Daten. Da der Apache den Exportbestimmungen der USA unterliegt, ist die SSLUnterstützung nicht direkt in den Apache eingebunden, sie muss
durch dieses Zusatzmodul aktiviert werden.
mod_suEXEC
Normalerweise werden CGI- (Common Gateway Interface) und
SSI-Skripte (Server Side Includes) unter dem Benutzer ausgeführt, unter dem auch der Apache läuft. Mit mod_suEXEC
(su = switch user) können diese ab Apache 1.2 durch einen beliebigen anderen Benutzer oder eine andere Gruppe ausgeführt
werden.
mod_unique_id
Wie der Name schon angibt, erzeugt dieses Modul eine Umgebungsvariable mit einer einzigartigen (englisch: unique) Zahl
(auch ID genannt), die für jede Clientanfrage neu und einzigartig
erzeugt wird.
mod_usertrack
Ehemals mod_cookies genannt, bietet dieses Modul die Möglichkeit, mit Hilfe so genannter Cookies die Aktionen eines Benutzers zu verfolgen und aufzuzeichnen. Cookies sind kleine Textdateien, die auf dem Client gespeichert werden und durch den
Server, der diese gesetzt hat, wieder ausgelesen werden können.
Das Verfolgen und Aufzeichnen der Benutzeraktionen (auch
Usertracking genannt) basiert auf einem einfachen Grundprinzip,
ist aber in der Regel aufgrund der Tatsache, dass nicht jeder
Browser Cookies unterstützt und diese auch durch den Benutzer
abgelehnt werden können, praktisch nicht gezielt realisierbar.
mod_vhost_alias
Ein sehr hilfreiches Modul für die Bereitstellung von virtuellem
Hosting. Es bezieht die Informationen für eine neue Domain
nicht aus einem <VirtualHost>-Eintrag in der httpd.conf, sondern
direkt aus dem Dateisystem und somit findet eigentlich ein
Aliasing von Verzeichnisnamen auf fertige Domainnamen statt.
Dadurch können ohne Neustart des Apache neue Domains angelegt werden. Auf die verschiedenen Möglichkeiten des virtuellen
Hosting wird in späteren Kapiteln noch ausführlich eingegangen.
Tabelle 3.3 Bekannte Module von Drittanbietern (Forts.)
118
3 Erweiterte Installation
Teilweise werden Module von Drittanbietern unter http://modules.apache.org aufgelistet. Eine Suche ohne die Eingabe eines Suchbegriffs zeigt dort eine Übersicht aller
registrierten Module der Drittanbieter. Falls man auf der Suche nach einem speziellen
Module ist, hilft oft auch eine Suchanfrage bei http://www.google.de.
Bei der Vielzahl von Modulen die Übersicht zu behalten und nur die für die jeweiligen Bedürfnisse nötigen Module zu finden, ist sicherlich eine aufwendige Arbeit.
Deshalb habe ich in der nachfolgenden Tabelle geeignete Modulkombinationen aufgelistet und diese verschiedenen Szenarien zugeordnet.
3.3.3
Empfohlene Module
Diese Module bilden die Grundlage für die nachfolgenden Fallbeispiele und sind so
essenziell, dass sie immer in den Apache integriert werden sollten.
Name des Moduls
Grund für den Einsatz
mod_access
Sensible Inhalte einer Website sollen nur von bestimmten Hosts
erreichbar sein und können durch dieses Modul geschützt werden.
mod_auth
Der Zugang zu bestimmten Verzeichnissen kann durch eine
Authentifikation am Server mit Hilfe eines gültigen Benutzernamens und Passwortes gewährt werden.
mod_dir
Der Name der Startdatei wird durch die Konfigurationsoption
DirectoryIndex bestimmt, den dieses Modul zur Verfügung
stellt. Außerdem hängt dieses Modul automatisch einen Slash
(»/«) an die vom Benutzer angegebene URL an, wenn dieser
fehlt und der Benutzer eigentlich ein Verzeichnis aufrufen
wollte.
mod_log_config
Um eine Statistik der aufgerufenen Webseiten zu bekommen,
ist dieses Modul unbedingt notwendig.
mod_mime
Damit die Clients überhaupt wissen, welche Art von Inhalten
eine Website zur Verfügung stellt, definiert dieses Modul so
genannte MIME-Typen.
Tabelle 3.4 Grundkonfiguration der Module
Fallbeispiel 1
Minimale Konfiguration eines Webservers, der ausschließlich statische Informationen
in Form von HTML-Dateien zur Verfügung stellt. Jeder Mitarbeiter soll ein individuelles Verzeichnis für seine Daten bekommen, die er im Web veröffentlichen will.
Eventuell sollen die statischen Inhalte später durch dynamisch generierte Webseiten
ersetzt werden.
3.3 Modulübersicht
119
Name des Moduls
Grund für den Einsatz
mod_autoindex
Benutzer, denen die Möglichkeit gegeben wird, unter einer
bestimmten Adresse persönliche Inhalte im Web zu veröffentlichen, vergessen eventuell eine Startdatei wie index.html o.Ä. zu
definieren. Das Modul erzeugt automatisch einen Index eines
Verzeichnisses und zeigt diesen an.
mod_setenvif
Eventuell müssen Funktionalitäten des Apache aufgrund lokaler
Gegebenheiten der Clients (z.B. stark veraltete Browserversion)
abgeschaltet werden.
mod_so
Falls später die statischen Webseiten durch dynamisch erzeugte
ersetzt werden sollen, so werden zusätzliche Module (z.B. PHP)
benötigt, die eigentlich eine Neuinstallation des Apache erzwingen. Mit diesem Modul ist die nachträgliche Installation von
Modulen ohne Neukompilierung des Apache möglich. Man
spricht hier von so genannten Dynamic Shared Objects (DSO).
mod_userdir
Jeder lokale Benutzer soll unter einer festgelegten Adresse (z.B.
http://www.domain.tld/~benutzername) individuelle Informationen
veröffentlichen können.
Tabelle 3.5 Modulkonfiguration eines sehr einfachen Webservers,
basierend auf der oben genannten Grundkonfiguration
Fallbeispiel 2
Konfiguration eines kompletten Webservers, der nur eine Website beheimatet. Die
Inhalte werden sowohl statisch, als auch dynamisch generiert. Eingesetzt wird der
Server als Intranet bzw. Internetserver.
Name des Moduls
Grund für den Einsatz
mod_actions
CGI-Skripte können einem bestimmten MIME-Typen zugewiesen und bei Zugriff auf Dateien diesen Typs automatisch ausgeführt werden.
mod_alias
Umleitung von internen Pfaden auf ein anderes Verzeichnis (sog.
Alias) oder komplette Weiterleitung an eine externe Webseite
(sog. Redirect).
mod_asis
Eventuell ist es nötig, eigene Header an den Client zu senden,
ohne dass die normalen HTTP-Header hinzugefügt werden.
Auch Redirects können damit realisiert werden.
mod_cache
Zur Zwischenspeicherung von häufig angeforderten Daten ist
dieses Modul sicherlich nützlich.
Tabelle 3.6 Modulkonfiguration eines Intranet/Internet Servers,
basierend auf der oben genannten Grundkonfiguration
sowie der Konfiguration aus dem ersten Szenario
120
3 Erweiterte Installation
Name des Moduls
Grund für den Einsatz
mod_cgi
Auf vielen Webservern kommen so genannte Common Gateway
Interface (CGI)-Skripte zum Einsatz, die in verschiedenen Programmiersprachen geschrieben werden können. Damit der Apache diese überhaupt ausführen kann, wird dieses Modul benötigt.
mod_env
Teilweise wird der Zugriff auf Umgebungsvariablen aus der
Shell im Apache benötigt. Dieses Modul stellt die Verbindung
zwischen Shell und Apache her und erlaubt die Definition eigener Variablen in der Serverkonfiguration.
mod_expires
Für Inhalte der Website kann es eventuell nötig sein, die Dauer
der Gültigkeit anhand eines zusätzlichen HTTP-Headers zu
beschränken.
mod_headers
Unter Umständen kann es notwendig sein, die HTTP-Header
beliebig zu modifizieren, hinzuzufügen, zu ersetzen oder auch
zu löschen.
mod_include
Falls Server Side Includes (SSI) benutzt werden, ist dieses Modul auf
jeden Fall nötig. SSI-Skripte sind meiner Meinung nach eigentlich
veraltet und daher ist die Benutzung dieses Moduls optional.
mod_mime_magic
Dieses Modul versucht anhand des Inhaltes einer Datei den
Dateitypen zu erkennen und ihr einen entsprechenden MIMETypen zuzuweisen.
mod_negotiation
Der Apache kann anhand von Daten, die der Client an den Server gesendet hat, Informationen in einem durch den Client
gewünschten und akzeptierten Format übermitteln. Der Client
sendet dabei Informationen über die von ihm gewünschten
Datenformate, Spracheinstellungen, Zeichensätze und Codierung und der Apache liefert die Variante einer Information an
den Client, die am besten auf die Wünsche des Client passt. Es
findet praktisch eine Verhandlung über das Aussehen und das
Format der zu liefernden Daten statt. Dieser Vorgang wird Content Negotiation (etwa: Inhaltsverhandlung) genannt und wird
durch das Modul mod_negotiation bereitgestellt.
mod_perl
Mod_perl ist sozusagen das Urgestein aller Module und erfreut
sich immer noch großer Beliebtheit. Es darf auf einem Webserver
nicht fehlen und dient dazu, in Perl geschriebene Programme
ausführen zu können.
mod_php
Dynamisch erzeugte Inhalte lassen sich hervorragend mit diesem
Modul realisieren und es gibt wohl kaum einen Webserver, der
es inzwischen nicht bereitstellt.
Tabelle 3.6 Modulkonfiguration eines Intranet/Internet Servers,
basierend auf der oben genannten Grundkonfiguration
sowie der Konfiguration aus dem ersten Szenario (Forts.)
3.3 Modulübersicht
121
Name des Moduls
Grund für den Einsatz
mod_rewrite
Die Realisierung von internen und externen Weiterleitungen und
Redirects anhand regulärer Ausdrücke ist sicherlich ein Feature,
welches sehr oft Verwendung findet.
mod_speling
Oft geben Benutzer eine URL falsch oder unvollständig ein und
vergessen beispielsweise einen Buchstaben. Mod_speling korrigiert solche Tippfehler und führt den Client dennoch zum
gewünschten Ziel.
mod_ssl
Eventuell wird ein Shopsystem angeboten und es müssen sensible Daten (z.B. Kreditkartennummern etc.) transferiert werden.
Mit mod_ssl lässt sich eine relativ sichere Übertragung dieser
Daten mit dem SSL-Standard realisieren.
mod_suEXEC
Die Verwendung dieses Moduls ist optional, es ermöglicht die
Ausführung von CGI- und SSI- Skripten unter der Kennung
eines beliebigen lokalen Benutzers. Falls solche Funktionalitäten
nicht benötigt werden, kann man dieses Modul ruhig weglassen.
Tabelle 3.6 Modulkonfiguration eines Intranet/Internet Servers,
basierend auf der oben genannten Grundkonfiguration
sowie der Konfiguration aus dem ersten Szenario (Forts.)
Fallbeispiel 3
Konfiguration eines kompletten Webservers, der einen großen Anteil von virtuellen
Servern (so genannte VirtualHosts) beheimatet. Dies kann beispielsweise in einer ISPUmgebung (Internet Service Provider) der Fall sein.
Name des Moduls
Grund für den Einsatz
mod_vhost_alias
Aufbauend auf Strukturen des lokalen Dateisystems kann dieses
Modul neue virtuelle Server bereitstellen, ohne dafür neue Einträge in der Konfigurationsdatei des Apache vorzunehmen.
Tabelle 3.7 Zusätzliche Modulkonfiguration eines Internetservers mit einer Großzahl von
virtuellen Servern, die auf der Standardkonfiguration eines Webservers
(vgl. Tabelle ) aufbaut
122
3.4
3 Erweiterte Installation
./configure bis zum Abwinken
Das configure-Skript des Apache bietet wirklich schier unendliche Kombinationsmöglichkeiten der einzelnen Konfigurationsoptionen. Generell können, wie bereits in der
Auflistung und Erläuterung der einzelnen Optionen dargestellt, einzelne Module
und bestimmte Parameter durch Nutzung der entsprechenden Option aktiviert bzw.
deaktiviert werden. Die Verwendung der jeweiligen Optionen muss wirklich sehr
individuell an die jeweiligen Gegebenheiten angepasst werden. Ich möchte nun sozusagen als kleine Entscheidungshilfe einige Fallbeispiele präsentieren, die Ihnen helfen
sollen, bei der Installation des Apache die von Ihnen wirklich benötigten Optionen zu
wählen.
3.4.1
Fallbeispiele
Fallbeispiel 1:
Der Apache soll unter Verwendung des Layouts Apache nach /usr/local/apache2 installiert werden. Es soll dasselbe Laufzeitverhalten verwendet werden, wie im Apache
1.3.x (prefork), und der Server soll die Standardmodule des Apache (mod_auth,
mod_access, mod_log_config, mod_env, mod_setenvif, mod_mime, mod_autoindex, mod_asis,
mod_cgi, mod_dir, mod_userdir, mod_actions, mod_alias und mod_so) ohne mod_imap,
mod_include, mod_negotiation und mod_status verwenden. Deshalb ergibt sich folgender configure-Aufruf:
# ./configure --enable-layout=Apache --with-mpm=prefork
--disable-status --disable-imap --disable-include
--disable-negotiation
Zuerst wird bei diesem Befehl ein Layout (Apache, siehe config.layout) sowie ein Laufzeitverhalten gewählt (Prefork, identisch mit dem Laufzeitverhalten des Apache 1.3.x)
und die vier nicht gewünschten Module werden nacheinander deaktiviert durch den
Aufruf --disable-modulname. Die Übersetzung dieser Konfiguration erfolgt nun durch
den Befehl
# make
und
# make install
installiert die Software in das Installationsverzeichnis des Layouts Apache (/usr/
local/apache2).
Fallbeispiel 2:
Der Apache soll unter Verwendung des Layouts Apache wieder nach
/usr/local/apache2 installiert werden, wobei die Konfigurationsdateien jedoch unter
/etc/httpd/ gespeichert werden sollen. Der Server soll auf Port 8080 horchen, das aus
dem Apache 1.3.x bekannte Laufzeitverhalten (Prefork) benutzen und eine große
3.4 ./configure bis zum Abwinken
123
Anzahl an Modulen (Standard- und Zusatzmodule) als DSO (Dynamic Shared Objects)
übersetzen. Der entsprechende configure-Aufruf sieht wie folgt aus:
# ./configure --enable-layout=Apache --with-mpm=prefork
–-sysconfdir=/etc/httpd/ --with-port=8080
–-enable-mods-shared=most
Sie können diesen Aufruf in einer Zeile eingeben oder Backslashs benutzen, da diese
Zeilenumbrüche symbolisieren und den Aufruf insgesamt lesbarer gestalten. Der
Befehl ähnelt dem aus Fallbeispiel 1, ist jedoch um die Option --sysconfdir=/etc/httpd/
erweitert worden, die die Konfigurationsdateien des Apache (u.a. httpd.conf) in das
Verzeichnis /etc/httpd/ installiert. Durch die Option --with-port=8080 wird der Apache
auf dem TCP-Port 8080 horchen und somit von der Standardeinstellung (TCP, Port
80) abweichen. Die letzte Einstellung --enable-mods-shared=most gibt an, dass eine
große Anzahl an Standard- und Zusatzmodulen als so genannte Dynamic Shared
Objects (DSO) übersetzt werden sollen. Dazu zählen die Module:
mod_access
mod_expires
mod_actions
mod_headers
mod_alias
mod_imap
mod_asis
mod_include
mod_auth
mod_info
mod_auth_anon
mod_log_config
mod_auth_dbm
mod_mime
mod_auth_digest
mod_negotiation
mod_autoindex
mod_rewrite
mod_cgi
mod_setenvif
mod_dav
mod_speling
mod_dav_fs
mod_status
mod_dir
mod_userdir
mod_env
mod_vhost_alias
Die Kompilierung und Installation erfolgt, wie bei jedem dieser Fallbeispiele und
einer Vielzahl von Unix/Linux-Programmen, mit dem Befehl make und make install.
Fallbeispiel 3:
Der Apache soll unter Verwendung eines selbst erstellen Layouts namens MeinIndianer installiert werden, wobei die größtmögliche Anzahl an Modulen als Dynamic
Shared Objects (DSO) übersetzt werden sollen. Die Module mod_include und
mod_imap, die eigentlich zu den Standardmodulen des Apache gehören, sollen
jedoch komplett deaktiviert werden. Es ergibt sich daraus folgender configure-Befehl:
124
3 Erweiterte Installation
# ./configure –-enable-layout=MeinIndianer -–disable-imap
–-disable-include –-enable-mods-shared=max
Der Sinn dieses Befehls sollte klar sein, denn es wird ein Layout namens MeinIndianer
benutzt, um die maximale Anzahl an Modulen (außer mod_imap und mod_include)
als Dynamic Shared Objects zu übersetzen. Die Befehle make und make install schließen
die Installation ab.
Fallbeispiel 4:
Unter Verwendung des Multi Processing Module (MPM) Perchild soll der Apache
nach /var/web installiert werden und die Module mod_rewrite, mod_deflate sowie
mod_alias sollen als Dynamic Shared Objects übersetzt werden. Der Apache soll
außerdem zu Entwicklungszwecken mod_example anbieten. Es entsteht daraus folgender configure-Befehl:
# ./configure –-prefix=/var/web –-with-mpm=perchild
–-enable-example –-enable-mods-shared="rewrite deflate alias"
Die Installation des Häuptlings aller Webserver erfolgt nach /var/web und verwendet
das Laufzeitverhalten perchild. Er bietet die Standardmodule sowie mod_example an
und hat die Module mod_rewrite, mod_deflate und mod_alias als Dynamic Shared
Objects übersetzt. Die Kompilierung und Installation wird schließlich durch make und
make install durchgeführt.
Fallbeispiel 5:
In einer sehr sicherheitskritischen Umgebung soll ein möglichst minimalistischer
Apache installiert werden, der nur über die zum Betrieb unbedingt notwendigen
Module verfügt. Es entsteht beispielsweise folgender configure-Aufruf:
# ./configure --prefix=/usr/local/apache2 --disable-include
--disable-env --disable-status --disable-asis --disable-autoindex
--disable-imap --disable-actions --disable-userdir --enable-auth-dbm --enable-authdigest --enable-deflate
Dieser Aufruf würde den Apache in das Verzeichnis /usr/local/apache2 installieren und
nur die Module mod_access, mod_auth, mod_auth_dbm, mod_auth_digest,
mod_deflate, mod_log_config, mod_setenvif, mod_mime, mod_cgi, mod_negotiation,
mod_dir, mod_alias sowie mod_so fest in den Server integrieren. Dies ist sicherlich
noch nicht die sicherste Modulkonfiguration des Apache, aber eine gute Grundlage.
Selbstverständlich wird auch in diesem Beispiel die Kompilierung durch den Befehl
make und die Installation durch den Befehl make install ausgeführt.
Sie haben nun einige Beispiele für den Aufruf des configure-Befehls bekommen und
können sich nun anhand der o.g. Tabelle den Apache gemäß Ihren Wünschen und
Bedürfnissen zusammenbauen und installieren. Nachfolgend möchte ich nun die
Installation diverser Zusatzbibliotheken für den Apache und diverse Erweiterungen
(u.a. Perl, PHP etc.) unter Unix/Linux erläutern und weitere configure-Beispiele präsentieren.
3.5 Installation diverser Zusatzsoftware unter Unix/Linux
3.5
125
Installation diverser Zusatzsoftware unter
Unix/Linux
Die Basisinstallation des Apache ist recht einfach und verlangt eigentlich keine besonderen Voraussetzungen. Alle von mir verwendeten Systeme (u.a. SuSE Linux, Debian
Linux, FreeBSD, Sun Solaris, Microsoft Windows), auf denen ich den Apache installiert habe, nutzen durch das jeweilige Betriebssystem vordefinierte Standardinstallationen (ohne Besonderheiten). Die insbesondere in der fortgeschrittenen Installation
verwendeten Erweiterungen beruhen oft auf speziellen Softwarepaketen, die nicht
immer Teil der Standardinstallation eines Betriebssystems sind. Dieser Abschnitt
erläutert deshalb die Installation von einigen Softwarepaketen und Bibliotheken, die
Sie installieren müssen, wenn diese nicht von Ihrer Distribution mitgeliefert werden
oder Sie diese nicht installiert haben. Hinweis: Falls Sie mit der manuellen Installation
von Software unter Unix/Linux nicht sonderlich vertraut sind, sollten Sie dieses
Kapitel überspringen und die entsprechenden Softwarepakete mit der Paketverwaltung Ihrer Distribution (z.B. Yast) installieren!
3.5.1
Installation von GNU Bison
(optional, u.a. für PHP benötigt)
Laden Sie sich die aktuelle Version 1.875 von der Homepage der Bibliothek
http://www.gnu.org/directory/bison.html herunter und entpacken Sie diese durch tar xvzf
bison-1.875.tar.gz (ca. 1 MB).
Wechseln Sie in das Verzeichnis bison-1.875 und rufen Sie das Konfigurationsskript
auf, um die Installation vorzubereiten:
# ./configure
Starten Sie die Kompilierung der Software und installieren Sie diese:
# make && make install
Die Installation ist damit abgeschlossen. Erzeugen Sie nun die Liste der dem System
bekannten Bibliotheken neu:
# ldconfig
3.5.2
Installation von GNU Flex (optional, u.a. für PHP
benötigt)
Laden Sie sich die aktuelle Version 2.5.4a von der Homepage der Bibliothek
http://www.gnu.org/software/flex/flex.html (oder von ftp://ftp.gnu.org/non-gnu/flex/)
herunter und entpacken Sie diese durch tar xvzf flex-2.5.4a.tar.gz (373 KB).
126
3 Erweiterte Installation
Rufen Sie das Konfigurationsskript innerhalb von flex-2.5.4 auf, um die Installation
vorzubereiten:
# ./configure
Starten Sie die Kompilierung der Software und installieren Sie diese:
# make && make install
Die Installation von Flex nach /usr/local/bin ist damit abgeschlossen, erzeugen Sie nun
die Liste der dem System bekannten Bibliotheken neu:
# ldconfig
3.5.3
Installation von GNU GDBM
(optional, u.a. für PostgreSQL benötigt)
Laden Sie sich die aktuelle Version 1.8.3 von ftp://ftp.gnu.org/gnu/gdbm/ herunter und
entpacken Sie diese durch tar xvzf gdbm-1.8.3.tar.gz. (223 KB)
Wechseln Sie in das Verzeichnis gdbm-1.8.3. Rufen Sie das Konfigurationsskript auf,
um die Installation vorzubereiten:
# ./configure
Starten Sie die Kompilierung der Software und installieren Sie diese:
# make && make install
Die Installation ist damit abgeschlossen. Erzeugen Sie nun die Liste der dem System
bekannten Bibliotheken neu:
# ldconfig
3.5.4
Installation von LibNCurses (optional, u.a. für
Kernelkonfiguration und LibReadline benötigt)
Normalerweise wird die ncurses (new curses) Bibliothek bei vielen Distributionen standardmäßig mitinstalliert. Wenn Sie diese jedoch nicht installiert haben, müssen Sie
sich diese von der Internetseite http://www.gnu.org/software/ncurses/ncurses.html
herunterladen und entpacken mit dem Befehl tar xvzf ncurses-5.3.tar.gz (2 MB).
Starten Sie innerhalb des Verzeichnisses ncurses-5.3 durch den Aufruf des mitgelieferten configure-Skriptes die Konfiguration der Software:
# ./configure
Sobald der Vorgang abgeschlossen ist, können Sie die Kompilierung der ncursesBiliothek starten:
# make
3.5 Installation diverser Zusatzsoftware unter Unix/Linux
127
Installieren Sie die Software, erzeugen Sie die Liste der bekannten Bibliotheken neu
und schließen Sie damit die Installation der Bibliothek ab:
# make install && ldconfig
3.5.5
Installation von FreeType
(optional, u.a. für PHP benötigt)
Die Homepage der FreeType-Bibliothek lautet http://www.freetype.org, laden Sie sich
von dort die aktuelle Version (zur Zeit 2.1.5) herunter und entpacken Sie diese durch
Eingabe von tar xvzf freetype-2.1.5.tar.gz (1,1 MB).
Wechseln Sie in das neu erzeugte Verzeichnis freetype-2.1.5 (cd freetype-2.1.5) und
rufen Sie die Übersicht der zur Verfügung stehenden Konfigurationsoptionen auf:
# ./configure --help
Nach Durchsicht der Optionen habe ich mich für folgenden Aufruf entschieden:
Hinweis
# ./configure --prefix=/usr/local/freetype-2.1.5
Sofern Sie kein spezielles Installationsverzeichnis (z.B. /usr/local/freetype-2.1.5)
wünschen, können Sie auch nur den Befehl ./configure benutzen.
Die Konfigurierung der Software beginnt, diverse Abhängigkeiten (u.a. libtool etc.)
werden geprüft und sobald das Skript beendet ist, kann die Kompilierung von FreeType 2.1.5 beginnen:
# make
Wenn die Kompilierung ohne Fehlermeldung abgeschlossen ist, können Sie die Software nach /usr/local/freetype-2.1.5 installieren:
# make install
Die Installation sollte ohne Probleme klappen. Damit das System die erzeugten Bibliotheken finden kann, sollten Sie diese entweder in das Verzeichnis /lib kopieren oder
die Systempfade für Bibliotheken entsprechend erweitern. Wenn Sie die Bibliotheken
nach /lib kopieren möchten, hilft Ihnen der folgende Befehl:
# cp /usr/local/freetype-2.1.5/lib/* /lib
Alternativ können Sie die Suchpfade für Systembibliotheken, die in der Datei
/etc/ld.so.conf definiert werden, um das Unterverzeichnis lib Ihrer FreeType-Installation erweitern. Nutzen Sie dazu folgenden Einzeiler:
# echo /usr/local/freetype-2.1.5/lib >> /etc/ld.so.conf
128
3 Erweiterte Installation
Der Befehl leitet die Ausgabe des Kommandos echo in die Datei /etc/ld.so.conf um und
fügt dadurch dieser Datei einen Verweis auf das Verzeichnis /usr/local/freetype-2.1.5/lib
hinzu. Schließlich muss das System über das Vorhandensein und den Speicherort der
neuen Bibliotheken informiert werden. Diesen Part erledigt folgender Befehl, den Sie
immer ausführen müssen, wenn Sie neue Bibliotheken auf Ihrem System installiert
haben:
# ldconfig
Die Installation von FreeType 2.1.5 ist damit abgeschlossen.
3.5.6
Installation von zlib
(optional, u.a. für PHP und GD-Lib benötigt)
Die Homepage der freien Datenkompressionsbibliothek lautet http://www.zlib.org, die
aktuelle Version ist 1.2.1. Laden Sie sich die Software von dieser Seite oder einem
ihrer vielen Mirrors herunter und extrahieren Sie diese durch Eingabe von tar xvzf
zlib-1.2.1.tar.gz (338 KB).
Wechseln Sie in das neu erzeugte Verzeichnis zlib-1.2.1 und rufen Sie die Übersicht
der Konfigurationsoptionen auf:
# ./configure --help
Die Liste ist bei dieser Software extrem kurz, die Wahl der Konfigurationsoptionen
fällt deshalb sehr leicht:
Hinweis
# ./configure --prefix=/usr/local/zlib-1.2.1 --shared
Wenn Sie kein spezielles Installationsverzeichnis definieren möchten, können
Sie auch nur den Befehl ./configure --shared verwenden.
Die Konfiguration der Software ist extrem schnell fertig, übersetzen Sie nun die Software:
# make
Der Kompilierungsvorgang sollte ohne Fehler durchlaufen. Installieren Sie nun die
Software mit dem Befehl
# make install
Als Nächstes müssen Sie das System darüber informieren, dass Sie neue Bibliotheken
installiert haben. Der bekannte Einzeiler erledigt dies mal wieder:
# echo /usr/local/zlib-1.2.1/lib >> /etc/ld.so.conf
3.5 Installation diverser Zusatzsoftware unter Unix/Linux
129
Alternativ können Sie die Dateien des Unterverzeichnisses lib Ihrer zlib-Installation in
einen dem System bekannten Pfad für Bibliotheken wie z.B. /lib kopieren. Lassen Sie
das System nun die Liste der Bibliotheken neu erzeugen:
# ldconfig
So einfach ist das: Die freie Datenkompressionsbibliothek zlib ist nun vollständig
installiert.
3.5.7
Installation von JPEGSrc
(optional, u.a. für PHP benötigt)
JPEGSrc ist freie Bibliothek zur Kompression und Dekompression von JPEG-Bildern.
Die Homepage dieser Bibliothek lautet http://www.ijg.org, laden Sie sich die jeweils
aktuelle Version (momentan 6b) herunter und entpacken Sie diese durch Eingabe von
tar xvzf jpegsrc.v6b.tar.gz (599 KB).
Rufen Sie im neu erzeugten Verzeichnis jpeg-6b die Liste der zur Verfügung stehenden Konfigurationsoptionen auf und studieren Sie die möglichen Optionen:
# ./configure --help
Ich habe mich nach Durchsicht der möglichen Optionen für folgenden Aufruf des configure-Skriptes entschieden:
Hinweis
# ./configure --prefix=/usr/local/jpegsrc-6b --enable-shared
Auch hier ist die Angabe eines Installationsverzeichnisses (--prefix=/usr/local/
jpegsrc-6b) optional und kann weggelassen werden.
Langsam wird es zur Gewohnheit: Die Übersetzung der Software erfolgt durch den
Aufruf von
# make
Dem Makefile von JPEGSrc fehlen leider die entsprechenden Aufrufe, um die nötigen
Installationsverzeichnisse zu erzeugen. Ich habe auch diesen Fehler (bzw. Feature)
den Autoren der Bibliothek gemeldet und eventuell sind diese bereinigt worden,
wenn Sie das Buch in den Händen halten. Falls die Fehler nicht behoben worden sind,
müssen Sie halt die benötigten Verzeichnisse per Hand erstellen:
#
#
#
#
#
#
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
/usr/local/jpegsrc-6b
/usr/local/jpegsrc-6b/lib
/usr/local/jpegsrc-6b/include
/usr/local/jpegsrc-6b/bin
/usr/local/jpegsrc-6b/man
/usr/local/jpegsrc-6b/man/man1
130
3 Erweiterte Installation
Nun können Sie die Software, gemäß Ihren Angaben beim Aufruf des configure-Skriptes, erfolgreich unter /usr/local/jpegsrc-6b installieren durch Ausführen des Befehls
# make install
Da Sie eine Bibliothek installiert haben, müssen Sie das System über das Vorhandensein einer neuen Bibliothek informieren. Fügen Sie dazu eine Zeile der Datei
/etc/ld.so.conf hinzu, die auf den Speicherort der neu installierten Bibliothek von
JPEGSrc verweist:
# echo /usr/local/jpegsrc-6b/lib >> /etc/ld.so.conf
Erzeugen Sie nun die Liste der dem System bekannten und verwendeten Bibliotheken
neu mit dem Befehl:
# ldconfig
Kopieren Sie außerdem die Include-Dateien mit folgendem Kommando:
# cp /usr/local/jpegsrc-6b/include/* /usr/local/include
Die Installation dieser JPEG Bibliothek ist abgeschlossen.
3.5.8
Installation von LibPNG (optional, u.a. für PHP und
GD-Lib benötigt)
Die LibPNG wird von der GD-Lib benötigt und ist im Internet unter http://www.libpng.org
zu erreichen. Laden Sie sich die aktuelle Version (z.Z. 1.2.5) herunter und entpacken Sie
diese durch das Kommando tar xvzf libpng-1.2.5.tar.gz (495 KB).
Es existiert für LibPNG kein configure-Skript, welches für uns die Erzeugung des
Makefiles übernimmt. Im Verzeichnis libpng-1.2.5 existiert ein Unterverzeichnis
namens scripts, welches Makefiles für diverse Plattformen enthält. Wir kopieren uns
deshalb ein passendes Makefile durch Eingabe von
# cp scripts/makefile.linux makefile
Editieren Sie nun diese Datei und setzen Sie in Zeile 16 ein späteres Installationsverzeichnis. Ich habe mich dabei für das Verzeichnis /usr/local/libpng-1.2.5 entschieden,
demnach sieht diese Zeile wie folgt aus:
prefix=/usr/local/libpng-1.2.5
Speichern Sie das Makefile und erzeugen Sie das von Ihnen gewünschte Installationsverzeichnis per Hand:
# mkdir /usr/local/libpng-1.2.5
Starten Sie schließlich die Kompilierung von LibPNG 1.2.5 mit:
# make
3.5 Installation diverser Zusatzsoftware unter Unix/Linux
131
Die Installation dieser Bibliothek erledigt der Befehl:
# make install
Erweiteren Sie die Liste der dem System bekannten Pfade für Bibliotheken oder
kopieren Sie die neu installierten Bibliotheken in einen bereits bekannten Pfad. Wenn
Sie den Suchpfad für Bibliotheken erweitern möchten, hilft Ihnen dieser Befehl:
# echo /usr/local/libpng-1.2.5/lib >> /etc/ld.so.conf
Erzeugen Sie nun die Liste der dem System bekannten Bibliotheken neu:
# ldconfig
Die Installation der nächsten Bibliothek ist damit abgeschlossen.
3.5.9
Installation von GD-Lib (optional, u.a. für PHP
benötigt)
Die GD-Lib ist eine ANSI-C Bibliothek zur dynamischen Erzeugung von Bildern und
Grafiken in diversen Formaten (u.a. PNG und JPEG). Die Homepage dieser Software
lautet http://www.boutell.com/gd/ und ist aktuell in der Version 2.0.17. Laden Sie sich
die aktuelle Version (540 KB) herunter und entpacken Sie diese mit tar xvzf gd2.0.17.tar.gz.
Wechseln Sie nun in das neu entpackte Verzeichnis gd-2.0.17 (cd gd-2.0.17) und starten
Sie die Vorbereitung der Software durch Eingabe von:
Hinweis
# ./configure
Unter Umständen kann es nötig sein, dass Sie die Installationsverzeichnisse der
FreeType-, LibPNG- und LibJPEG-Bibliothek durch die Optionen --with-freetype=Verzeichnis, --with-png=Verzeichnis und --with-jpeg=Verzeichnis angeben
müssen. Optional ist die Wahl eines speziellen Installationsverzeichnisses mit
./configure --prefix=/usr/local/gd-2.0.17.
Starten Sie daraufhin die Kompilierung der Software:
# make
Schließlich können Sie die Installation der Software durch das Kommando
# make install
abschließen. Sofern Sie ein spezielles Installationsverzeichnis für die Software
gewählt haben (z.B. /usr/local/gd-2.0.17) müssen Sie die Liste der bekannten Pfade für
Bibliotheken erweitern:
# echo /usr/local/gd-2.0.17/lib >> /etc/ld.so.conf
132
3 Erweiterte Installation
Erzeugen Sie daraufhin die Liste der bekannten Bibliotheken neu:
# ldconfig
Die Installation ist damit abgeschlossen.
3.5.10 Installation der LibTiff (optional, u.a. für PHP und
PDFLib benötigt)
Laden Sie sich von http://www.libtiff.org die aktuelle Version (momentan 3.5.7) herunter und entpacken Sie diese durch die Eingabe von tar xvzf tiff-v3.5.7.tar.gz (929 KB).
Schauen Sie sich (in tiff-v3.5.7) nun die Übersicht der möglichen Konfigurationsoptionen an:
# ./configure --help
Da die Anzahl der möglichen Optionen wirklich sehr gering ist, habe ich mich für folgenden Aufruf entschieden:
Hinweis
# ./configure --prefix=/usr/local/libtiff-3.5.7
Die Angabe eines separaten Installationsverzeichnis (--prefix=...) ist optional.
Die Software wird für die Kompilierung und Installation vorbereitet und es wird
Ihnen eine Übersicht der späteren Installationsverzeichnisse aufgelistet. Bestätigen
Sie diese Übersicht durch Eingabe von yes und die Software wird entsprechend vorbereitet. Starten Sie die Kompilierung mit:
# make
Erzeugen Sie nun das Installationsverzeichnis der LibTiff 3.5.7 unterhalb des Verzeichnisses /usr/local:
# mkdir /usr/local/libtiff-3.5.7
Installieren Sie die Software durch folgenden Befehl:
# make install
Da es sich bei LibTiff um eine Bibliothek handelt, die auch von anderen Programmen
verwendet wird, muss der Speicherort dieser Bibliothek dem System bekannt gegeben werden, sofern ein spezielles Installationsverzeichnis (z.B. /usr/local/libtiff-3.5.7)
verwendet wird. Die Liste der Verzeichnisse, in denen das System Bibliotheken sucht
bzw. findet, steht in der Datei /etc/ld.so.conf. Tragen Sie deshalb den Pfad zu Ihrer LibTiff-Installation in diese Datei ein:
# echo /usr/local/libtiff-3.5.7/lib >> /etc/ld.so.conf
3.5 Installation diverser Zusatzsoftware unter Unix/Linux
133
Erzeugen Sie nun die Liste der dem System bekannten Bibliotheken neu und beenden
Sie damit die Installation der LibTiff:
# ldconfig
3.5.11 Installation der PDFLib (optional, u.a. für PHP
benötigt)
Hinweis
Falls Sie aus Ihren Programmen dynamisch PDF-Dateien erzeugen möchten, benötigen Sie die PDFLib von Thomas Merz. Laden Sie sich die aktuelle Version (moment
5.0.2) von http://www.pdflib.com herunter und entpacken Sie diese mit tar xvzf PDFlibLite-5.0.2-Unix-src.tar.gz (2,6 MB). Achtung: Die Bibliothek ist in ihrem Funktionsumfang abgespeckt und nur bedingt kostenlos. Sie muss, insbesondere bei gewerblichem
Einsatz, lizenziert werden. Weitere Informationen finden Sie auf der Homepage der
PDFLib!
Es gibt zwei verschiedene Versionen der PDFLib, die vorkompilierte und nicht
vorkompilierte, d.h. im Quelltext vorliegende Variante. Achten Sie darauf, dass
Sie die im Quelltext verfügbare Version herunterladen (siehe http://www.pdflib.
com/products/pdflib/download-source.html).
Wechseln Sie in das neu entpackte Verzeichnis PDFlib-Lite-5.0.2-Unix-src und schauen
Sie sich die zur Verfügung stehenden Konfigurationsoptionen an:
# ./configure --help
Ich würde gerne in Java, C++ und Perl dynamisch PDF-Dateien erzeugen und habe
mich deshalb für folgenden Konfigurationsaufruf entschieden (eine Zeile!):
Hinweis
# ./configure --prefix=/usr/local/pdflib-5.0.2 --enable-shared
--with-java=/usr/local/java --with-perl=/usr/bin/perl --enable-cxx
Sofern Sie die verschiedenen Optionen (z.B. --with-java) nicht benötigen, können Sie diese auch weglassen.
Sie erhalten eine Zusammenfassung der von Ihnen gewählten Optionen und können
nun die Kompilierung der PDFLib starten:
# make
Sobald diese erfolgreich abgeschlossen ist, können Sie die Software installieren:
# make install
Die reine Installation der PDFLib ist abgeschlossen, erweitern Sie zusätzlich den
Suchpfad für Systembibliotheken um den Pfad zu Ihrer PDFLib-Installation, damit
134
3 Erweiterte Installation
diese Erweiterung dem System bekannt ist und von verschiedenen Programmen
genutzt werden kann. Benutzen Sie dazu folgenden Befehl:
Hinweis
# echo /usr/local/pdflib-5.0.2/lib >> /etc/ld.so.conf
Dieser Schritt ist nur bei Verwendung eines eigenen Installationsverzeichnisses
(z.B. /usr/local/pdflib-5.0.2) notwendig.
Dieser flotte Einzeiler fügt der Datei /etc/ld.so.conf, die die Liste der Verzeichnisse enthält, in denen das System Bibliotheken suchen soll, einen Eintrag hinzu, der auf das
Unterverzeichnis lib der soeben getätigten PDFLib-Installation verweist und somit
die in diesem Verzeichnis installierte Bibliothek libpdf.so dem System zur Verfügung
stellt. Erzeugen Sie nun die Liste der dem System bekannten Bibliotheken neu und
beenden Sie damit die Installation der PDFLib:
# ldconfig
Alternativ können Sie die neu installierte Bibliothek auch einfach in ein dem System
bereits als Suchpfad für Bibliotheken bekannten Verzeichnis kopieren:
# cp /usr/local/pdflib-5.0.2/lib/libpdf.so /lib
Ein einfacher symbolischer Verweis erledigt diesen Job natürlich auch:
# ln -s /usr/local/pdflib-5.0.2/lib/libpdf.so /lib/libpdf.so
3.5.12 Installation von GhostScript (optional)
Ich werde Ihnen in einem späteren Kapitel vorstellen, wie Sie beliebige Inhalte mit
Linux-Bordmitteln in PDF-Dateien umwandeln können. Besorgen Sie sich dazu von
http://www.cs.wisc.edu/~ghost/ die aktuellste Version von GhostScript (momentan 7.07)
und entpacken Sie diese durch Eingabe von tar xvzf ghostscript-7.07.tar.gz (4,7 MB).
Wechseln Sie in das neu entpackte Verzeichnis von GhostScript und schauen Sie sich
die zur Verfügung stehenden Konfigurationsoptionen an:
# ./configure --help
Zur Installation von GhostScript nach /usr/local/ghostscript-7.07 habe ich folgenden
configure-Befehl gewählt:
Hinweis
# ./configure --prefix=/usr/local/ghostscript-7.07
Die Angabe eines besonderen Installationsverzeichnisses ist optional.
3.6 Apache 2 in einer Chroot-Umgebung
135
Sobald dieser Befehl abgeschlossen ist, können Sie die Kompilierung der Software
starten:
# make
Die Installation der Software erledigt dieses Kommando schnell:
# make install
Die Installation von GhostScript ist damit abgeschlossen. Sie benötigen jedoch zusätzlich noch ein Programm namens a2ps, welches Sie unter http://www.gnu.org/
software/a2ps/a2ps.html herunterladen müssen. Entpacken Sie auch dieses Programm
(aktuelle Version 4.13b) mit Hilfe des Befehls tar xvzf a2ps-4.13b.tar.gz (1,85 MB) und
rufen Sie im Verzeichnis a2ps-4.13 die Konfigurationsoptionen auf:
# ./configure --help
Nach Durchsicht der verfügbaren Optionen habe ich mich für folgenden Aufruf entschieden:
Hinweis
# ./configure --prefix=/usr/local/a2ps-4.13
Wie immer ist die Definition eines Installationsverzeichnisses optional.
Sobald dieser Befehl abgeschlossen ist, können Sie die Kompilierung der Software
starten:
# make
Die Installation der Software ist flott erledigt:
# make install
Die Installation von a2ps ist damit abgeschlossen.
3.6
Apache 2 in einer Chroot-Umgebung
Hinweis
Ich habe in diesem Buch bereits mehrfach die Vor- und Nachteile einer Chroot-Umgebung vorgestellt (u.a. im Kapitel mod_security). Im folgenden Kapitel möchte ich die
Installation des Apache 2 in einer solchen Umgebung veranschaulichen, wobei ich die
relativ aufwändige Installation von Drittanbietermodulen (z.B. mod_php) nicht
besprechen werde.
Die Basis dieses Kapitels bildet eine Anleitung, die ursprünglich von Jan Mattila
geschrieben und unter http://www.cgisecurity.com/webservers/apache/chrootapache2howto.html veröffentlicht worden ist.
136
3 Erweiterte Installation
Hinweis
3.6.1
Grundinstallation des Apache 2
Wenn Sie bereits über eine funktionsfähige lokale Installation des Apache 2 verfügen, können Sie dieses Kapitel überspringen. Erstellen Sie aber dennoch einen
separaten Benutzer zur Ausführung des Apache (vgl. Ende dieses Kapitels).
Die Grundinstallation des Apache 2 erfolgt bei der Verwendung einer Chroot-Umgebung wie gewohnt. Laden Sie sich von http://httpd.apache.org die aktuellste Version
(2.0.48) des Apache 2 herunter (6,25 MB) und entpacken Sie diese mit
# tar xvzf httpd-2.0.48.tar.gz
Wechseln Sie in das neu erzeugte Verzeichnis httpd-2.0.48 (cd httpd-2.0.48) und rufen
Sie eine Übersicht der zur Verfügung stehenden Optionen auf:
# ./configure --help
Nach Durchsicht der verfügbaren Optionen können Sie die Vorbereitung der Installation beispielsweise wie folgt starten (Standardkonfiguration, spätere Installation nach
/usr/local/apache2):
Hinweis
# ./configure –-prefix=/usr/local/apache2
Falls Sie weitere Optionen verwenden möchten, können Sie diese dem oben
genannten Befehl einfach anhängen. Aus Sicherheitsgründen ist die Deaktivierung der Module mod_actions, mod_asis, mod_autoindex, mod_imap,
mod_include, mod_status, mod_userdir, mod_auth_anon, mod_cern_meta,
mod_digest, mod_dav, mod_info und mod_proxy ratsam, sofern diese nicht
unbedingt benötigt werden.
Sobald dieser Befehl abgeschlossen ist, können Sie die Kompilierung des Apache 2
starten:
# make
Schließlich kann die Installation der Software nach /usr/local/apache2 durch Eingabe
des Befehls
# make install
erfolgen. Aus Sicherheitsgründen sollte danach eine separate Gruppe (apache2) und
ein separater Benutzer erstellt werden, die ausschließlich zur Ausführung des Apache
2 verwendet werden. Die Erstellung einer neuen Gruppe erfolgt durch den folgenden
Befehl:
# groupadd apache2
3.6 Apache 2 in einer Chroot-Umgebung
137
Dieser Gruppe fügen wir einen einzigen Benutzer namens apache2 hinzu, der später
zur Ausführung des Apache verwendet wird:
# useradd -g apache2 -d /dev/null -s /bin/false apache2
Das Heimatverzeichnis des Benutzers wird auf das virtuelle Datennirwana /dev/null
gesetzt. Durch die Verwendung des Programms /bin/false als Loginshell wird es ein
Angreifer, der eventuell durch einen gezielten Angriff gegen den Apache Zugriff auf
das lokale System erhalten hat, sehr schwer haben, diese Zugriffsmöglichkeit zu missbrauchen. Widmen wir uns nun dem Aufbau der eigentlichen Chroot-Umgebung:
3.6.2
Einrichtung der Chroot-Umgebung
Als Basisverzeichnis für die Chroot-Umgebung habe ich mich für das Verzeichnis
/chroot/httpd entschieden. Sie können prinzipiell jedes beliebige Verzeichnis dazu
benutzen. Sofern Sie sich für ein anderes Verzeichnis entschieden haben, müssen Sie
die nachfolgend aufgeführten Befehle entsprechend anpassen. Bitte beachten Sie
außerdem, dass es aus einer gesicherten Chroot-Umgebung heraus unter normalen
Umständen nicht möglich ist, auf Dateien und Verzeichnisse außerhalb dieser Umgebung auf Dateisystemebene zuzugreifen. Aufgrund dessen müssen alle Dateien,
Geräte und Verzeichnisse, die der Apache zur Ausführung benötigt, manuell aus
dem normalen Dateisystem in die Chroot-Umgebung kopiert beziehungsweise in der
Chroot-Umgebung erneut erstellt werden. Dazu muss zunächst die Basisverzeichnisstruktur innerhalb der Chroot-Umgebung erstellt werden:
#
#
#
#
#
#
#
#
#
#
#
#
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
–p
–p
–p
–p
–p
–p
–p
–p
–p
–p
–p
–p
/chroot/httpd/dev
/chroot/httpd/etc
/chroot/httpd/lib
/chroot/httpd/usr/lib
/chroot/httpd/usr/libexec
/chroot/httpd/usr/local/apache2/bin
/chroot/httpd/usr/local/apache2/logs
/chroot/httpd/usr/local/apache2/conf
/chroot/httpd/usr/local/apache2/lib
/chroot/httpd/usr/local/apache2/htdocs
/chroot/httpd/usr/share/zoneinfo/Europe
/chroot/httpd/var/run
Diese Befehle ergeben eine minimale Verzeichnisstruktur unterhalb des als ChrootBasisverzeichnis definierten Verzeichnisses /chroot/httpd, in die später Dateien und
Verzeichnisse aus dem »echten« Root-Verzeichnisbaum (/) kopiert werden.
Für die Ausführung des Apache ist das Vorhandensein des virtuellen Datennirwanas
/dev/null sowie des Gerätes /dev/urandom notwendig, so dass wir diese innerhalb der
Chroot-Umgebung erzeugen müssen:
# mknod /chroot/httpd/dev/null c 1 3
# mknod /chroot/httpd/dev/urandom c 2 4
138
3 Erweiterte Installation
Außerdem müssen wir für dieses Gerät spezielle Berechtigungen definieren:
# chown root.root /chroot/httpd/dev/null
# chmod 666 /chroot/httpd/dev/null
Nun folgt wohl der unangenehmste und zeitraubendste Teil dieses Kapitels: Da der
Apache während der Ausführung in der Chroot-Umgebung nicht auf die benötigten
(externen) Bibliotheken zugreifen kann, müssen diese Bibliotheken in die gesicherte
Umgebung kopiert werden. Dazu müssen wir jedoch zunächst mit Hilfe des Befehls
ldd herausfinden, welches Bibliotheken der Apache benötigt:
# ldd /usr/local/apache2/bin/httpd
Die Ausgabe dieses Befehls ist recht lang und zeigt die durch den Apache zur Ausführung verwendeten Bibliotheken:
Hinweis
libaprutil-0.so.0 => /usr/local/apache2.chroot/lib/libaprutil-0.so.0 (0x40015000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4003d000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40044000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x400dd000)
libapr-0.so.0 => /usr/local/apache2.chroot/lib/libapr-0.so.0 (0x40103000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40124000)
librt.so.1 => /lib/librt.so.1 (0x40175000)
libm.so.6 => /lib/libm.so.6 (0x40188000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401aa000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401d7000)
libdl.so.2 => /lib/libdl.so.2 (0x401ec000)
libc.so.6 => /lib/libc.so.6 (0x401ef000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Unter Umständen kann die Anzahl der benutzten Bibliotheken auf dem von
Ihnen verwendeten System von dieser Ausgabe abweichen.
Die Bibliotheken müssen nun händisch in die Chroot-Umgebung kopiert werden,
damit diese dem Apache auch innerhalb der Chroot-Umgebung zur Ausführung zur
Verfügung stehen. Da wir recht bequem sind, können wir uns ein kleines Skript
schreiben, welches diese Aufgabe für uns übernimmt:
Hinweis
# for i in `ldd /usr/local/apache2/bin/httpd | awk '{ print $3 }'` ; do cp $i
/chroot/httpd/lib/`basename $i`; done
Das `-Zeichen ist ein so genannter Backtick, den Sie auf Ihrer Tastatur links
neben der (æ___)-Taste (Rückschritttaste) finden. Um dieses Zeichen zu erhalten, drücken Sie die (ª)-Taste und die Taste links neben dem (æ___) sowie
danach die (____). Innerhalb des awk-Befehls werden einfache Anführungszeichen verwendet, die Sie durch Betätigen der (ª)-Taste sowie der Taste oberhalb
der rechten (ª)-Taste ((#)-Taste) erhalten.
3.6 Apache 2 in einer Chroot-Umgebung
139
Dieses kleine Shellskript führt den oben genannten Befehl aus und kopiert in einer
for-Schleife jede verwendete Bibliothek in das Zielverzeichnis /chroot/httpd/lib. Der
awk-Befehl sorgt dafür, dass aus der Ausgabe des Befehls ldd nur der volle Dateipfad
einer Bibliothek (z.B. /usr/local/apache2/lib/libaprutil-0.so.0) in der Variablen i gespeichert wird. Diese Variable i wird mit dem Namen $i durch den Kopierbefehl cp angesprochen und an die korrekte Stelle in der Chroot-Umgebung (/chroot/httpd/lib)
kopiert. Der Befehl basename extrahiert dabei den Dateinamen (z.B. libaprutil-0.so.0)
aus der vollen Pfadangabe (z.B. /usr/local/apache2/lib/libaprutil-0.so.0). Alles klar?
In dem Verzeichnis /chroot/httpd/lib befinden sich nun alle Bibliotheken, die der Apache zur Ausführung benötigt. Leider benötigen diese Bibliotheken selbst wieder eine
Reihe von Bibliotheken, wie der Befehl ldd herausfindet:
# ldd /chroot/httpd/lib/*
Die benötigten Bibliotheken sind:
/chroot/httpd/lib/ld-linux.so.2:
statically linked
/chroot/httpd/lib/libapr-0.so.0:
libc.so.6 => /lib/libc.so.6 (0x40034000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libaprutil-0.so.0:
libc.so.6 => /lib/libc.so.6 (0x40029000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libc.so.6:
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libcrypt.so.1:
libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libdb-4.0.so:
libc.so.6 => /lib/libc.so.6 (0x400ac000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libdl.so.2:
libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libexpat.so.0:
libc.so.6 => /lib/libc.so.6 (0x40039000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libgdbm.so.2:
libc.so.6 => /lib/libc.so.6 (0x4001a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libm.so.6:
libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libnsl.so.1:
libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
/chroot/httpd/lib/libpthread.so.0:
(0x80000000)
(0x80000000)
(0x40000000)
(0x40000000)
(0x80000000)
(0x40000000)
(0x80000000)
(0x80000000)
(0x40000000)
(0x40000000)
140
3 Erweiterte Installation
Hinweis
libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/chroot/httpd/lib/librt.so.1:
libc.so.6 => /lib/libc.so.6 (0x40027000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40154000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Unter Umständen variiert die Ausgabe auf dem von Ihnen benutzten System.
Wie die Ausgabe erkennen lässt, benötigen im Prinzip alle Bibliotheken dieselben
drei Dateien, so dass wir diese schnell manuell in die Chroot-Umgebung kopieren
können (eine Zeile):
# cp /lib/libc.so.6 /lib/ld-linux.so.2 /lib/libpthread.so.0 /chroot/httpd/lib/
Zusätzlich benötigt der Apache noch zwei weitere Bibliotheken, die wir ebenfalls in
die Chroot-Umgebung kopieren müssen (eine Zeile):
# cp /lib/libnss_compat.so.2 /lib/libnss_files.so.2 /chroot/httpd/lib/
Neben den genannten Bibliotheken braucht der Apache zur erfolgreichen Ausführung eine Menge weiterer Dateien. Eine Liste dieser Dateien liefert uns unter anderem der Befehl strace, der in jeder modernen Unix- beziehungsweise Linuxvariante
enthalten sein sollte und Details (Systemaufrufe, Signale etc.) über den Ablauf eines
Programms ausgibt.
# strace -o apache_ablauf.txt /usr/local/apache2/bin/httpd
Durch Angabe des Parameters -o ist die Ausgabe des strace-Befehls in die Datei
apache_ablauf.txt geschrieben worden, damit wir diese manuell analysieren können.
Bevor wir jedoch diese Ausgabe untersuchen können, müssen wir zunächst den Apache beenden, der durch das Programm strace gestartet worden ist:
# killall httpd
Damit wir die Dateien finden, die zur Ausführung des Apache 2 in der Chroot-Umgebung benötigt werden, müssen wir die Protokolldatei apache_ablauf.txt nach allen Systemaufrufen durchsuchen, in denen Dateien geöffnet werden (engl.: open):
# cat apache_ablauf.txt | grep open
Dieser Befehl produziert folgende Ausgabe (gekürzt):
open("/etc/ld.so.preload", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/local/apache2/lib/i686/mmx/libaprutil-0.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/local/apache2/lib/i686/libaprutil-0.so.0", O_RDONLY) = -1 ENOENT (No such
3.6 Apache 2 in einer Chroot-Umgebung
141
file or directory)
open("/usr/local/apache2/lib/mmx/libaprutil-0.so.0", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/local/apache2/lib/libaprutil-0.so.0", O_RDONLY) = 3
[ ... ]
open("/usr/local/apache2/lib/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/etc/ld.so.cache", O_RDONLY)
= 4
open("/lib/libnss_compat.so.2", O_RDONLY) = 4
open("/etc/passwd", O_RDONLY)
= 4
open("/etc/resolv.conf", O_RDONLY)
= 4
open("/usr/local/apache2/lib/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/etc/ld.so.cache", O_RDONLY)
= 4
open("/lib/libnss_files.so.2", O_RDONLY) = 4
open("/etc/host.conf", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/etc/hosts", O_RDONLY)
= 4
open("/usr/local/apache2/logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 4
open("/usr/local/apache2/logs/error_log", O_RDWR|O_APPEND|O_CREAT, 0666) = 7
open("/usr/local/apache2/conf/mime.types", O_RDONLY) = 8
open("/usr/local/apache2/conf/httpd.conf", O_RDONLY) = 5
Um den Apache erfolgreich in der Chroot-Umgebung zu betreiben, müssen wir alle
Dateien, die die Ausgabe des oben genannten Befehls geliefert hat, in die gesicherte
Umgebung kopieren. Allerdings haben wir eine Vielzahl der ausgeführten Dateien
bereits aus dem Verzeichnis /lib in die Chroot-Umgebung kopiert, so dass wir nur
noch folgende Dateien aus dem Verzeichnis /etc kopieren müssen (eine Zeile):
# cp /etc/resolv.conf /etc/nsswitch.conf /etc/hosts /chroot/httpd/etc/
Zusätzlich benötigen wir noch die Dateien /etc/passwd und /etc/group, wobei wir aus
Sicherheitsgründen nur die Informationen über die Gruppe beziehungsweise den
Benutzer apache2 in die entsprechenden Dateien der Chroot-Umgebung schreiben:
# grep apache2 /etc/passwd > /chroot/httpd/etc/passwd
# grep apache2 /etc/group > /chroot/httpd/etc/group
Des Weiteren brauchen wir Informationen über die Zeitzone, in der sich der Server
befindet. Dazu kopieren wir einfach die Datei /usr/share/zoneinfo/Europe/Berlin in die
Chroot-Umgebung:
# cp /usr/share/zoneinfo/Europe/Berlin /chroot/httpd/usr/share/zoneinfo/Europe/
Schließlich benötigen wir die Dateien mime.types, error_log und access_log, die wir
ebenfalls in die Chroot-Umgebung kopieren müssen (je Befehl eine Zeile):
142
3 Erweiterte Installation
# cp /usr/local/apache2/logs/access_log /chroot/httpd/usr/local/apache2/logs/
# cp /usr/local/apache2/logs/error_log /chroot/httpd/usr/local/apache2/logs/
# cp /usr/local/apache2/conf/mime.types /chroot/httpd/usr/local/apache2/conf/
Damit ist der eigentliche Aufbau der Chroot-Umgebung endlich abgeschlossen.
3.6.3
Konfiguration des Apache und Test der
Chroot-Umgebung
Die Konfiguration des Apache ist recht einfach:
Wir müssen den Apache anweisen, dass dieser unter der manuell angelegten Benutzer- beziehungsweise Gruppenkennung apache2 laufen soll. Dazu müssen Sie die
Datei /usr/local/apache2/conf/httpd.conf editieren und etwa in Zeile 266-267 die folgenden Anweisungen definieren:
User apache2
Group apache2
Speichern Sie die Datei httpd.conf und kopieren Sie den Inhalt des Unterverzeichnisses
htdocs aus dem normalen Dateisystem in die Chroot-Umgebung:
Hinweis
# cp -R /usr/local/apache2/htdocs /chroot/httpd/usr/local/apache2/
Alternativ können Sie selbstverständlich auch Ihre eigenen Dokumente in das
Dokumentenverzeichnis htdocs kopieren.
Außerdem müssen Sie nach der Änderung der Datei httpd.conf diese in die ChrootUmgebung kopieren (eine Zeile):
# cp /usr/local/apache2/conf/httpd.conf /chroot/httpd/usr/local/apache2/conf/
Schließlich benötigen wir alle Dateien aus dem Unterverzeichnis bin der lokalen Apache-Installation in der Chroot-Umgebung:
# cp /usr/local/apache2/bin/* /chroot/httpd/usr/local/apache2/bin/
Jetzt ist es an der Zeit, die Chroot-Umgebung das erste Mal zu testen. Geben Sie dazu
folgenden Befehl ein, um den Apache zu starten:
# chroot /chroot/httpd/ /usr/local/apache2/bin/httpd
Dieser Befehl erstellt unterhalb des Verzeichnisses /chroot/httpd eine Chroot-Umgebung und sperrt den Apache sozusagen in dieser Umgebung ein. Des Weiteren wird
innerhalb der Chroot-Umgebung der Befehl /usr/local/apache2/bin/httpd ausgeführt, um
den Apache zu starten. Bitte beachten Sie, dass es sich dabei nicht um das reale Verzeichnis /usr/local/apache2 handelt, sondern um das in der Chroot-Umgebung vorhandene Verzeichnis /chroot/httpd/usr/local/apache2. Das reale Verzeichnis /usr/local/apache2
wird nun eigentlich nicht mehr benötigt.
3.6 Apache 2 in einer Chroot-Umgebung
143
Rufen Sie jetzt die Startseite des Apache auf Ihrem lokalen Server unter http://localhost
auf. Sie werden feststellen, dass sich freudestrahlend der Indianer meldet: Die Einrichtung der Chroot-Umgebung war erfolgreich!
3.6.4
Abschlussarbeiten
Zum Abschluss möchte ich ein simples Startskript vorstellen, welches unter Linux
zum Start beziehungsweise Stopp des Apache 2 in der genannten Chroot-Umgebung
dienen kann. Erstellen Sie dazu die Datei /etc/init.d/apache2.sh und schreiben Sie die
folgenden Befehle in diese:
#!/bin/sh
# Start-/Stoppskript fuer den Apache 2
# in Chroot-Umgebung
chroot_bin=`which chroot`
case $1 in
start)
echo "Starte den Apache 2 in Chroot-Umgebung..."
$chroot_bin /chroot/httpd/ /usr/local/apache2/bin/httpd
;;
stop)
echo "Beende den Apache 2."
killall httpd
;;
restart)
echo "Starte den Apache 2 neu..."
$0 stop
$0 start
;;
*)
echo "Benutzung: $0 [start|stop|restart]"
exit 1
esac
Listing 3.1 Beispielskript zum Start/Stopp des Apache 2 in der Chroot-Umgebung
144
3 Erweiterte Installation
Speichern Sie die Datei und machen Sie diese ausführbar:
# chmod 755 /etc/init.d/apache2.sh
Mit Hilfe dieses Skriptes können Sie den Apache nun nach Belieben starten
# /etc/init.d/apache2.sh start
und stoppen:
# /etc/init.d/apache2.sh stop
Der Aufbau und die Konfiguration der Chroot-Umgebung sowie der Test des Apache
2 ist damit abgeschlossen. Dieses Kapitel zeigt relativ anschaulich, wie aufwändig es
ist, den Apache in einer Chroot-Umgebung zu betreiben. Die Installation und Einbettung von externen Drittanbietermodulen (z.B. PHP) sei als Aufgabe dem interessierten Leser überlassen. Viel Spaß :-)
3.7
Metux MPM
Ein elementarer Vorteil des Apache 2 gegenüber dem Apache 1.3.x ist die Unterstützung verschiedener Laufzeitverhalten (Multi Processing Modules, MPM), die der
Administrator bei der Installation des Apache auswählen kann. Mit Hilfe des Moduls
perchild sollte es deshalb erstmalig möglich sein, virtuelle Server mit beliebigen Benutzer- und Gruppenkennungen auszuführen. Obwohl dies in punkto Sicherheit und
Performance eine der vielversprechendsten Erweiterungen des Apache überhaupt
darstellt, haben die Entwickler des Apache aus mir nicht bekannten Gründen die
Weiterentwicklung des Moduls stark eingeschränkt bzw. teilweise ganz aufgegeben.
Der Deutsche Enrico Weigelt (http://www.metux.de) war mit der schleppenden
Entwicklung des Moduls perchild unzufrieden und hat im Laufe dieses Jahres (2003)
mit der Entwicklung eines eigenen Laufzeitmoduls namens metuxmpm
(http://www.metux.de/mpm/) auf Basis des Moduls perchild, begonnen. Ziel dieses
Moduls, welches sich momentan (Februar 2004) noch im Beta-Stadium befindet, ist
die Bereitstellung eines stabilen Laufzeitverhaltens, welches die Ausführung von virtuellen Server mit jeweils eigenen Benutzerkennungen ermöglicht. Inzwischen wird
Enrico Weigelt von einer Vielzahl von Freiwilligen unterstützt, die miteinander über
eine Mailingliste ([email protected]) kommunizieren und das Modul fortlaufend
weiterentwickeln. Mit der Veröffentlichung einer ersten stabilen Version wird im
Lauf des Jahres (2004) zu rechnen sein, die dann auch offiziell Teil des Apache werden soll. Nachfolgend möchte ich die Installation und Konfiguration des Moduls vorstellen, wobei noch mal darauf hingewiesen sei, dass das Modul noch nicht als stabil
gilt und deshalb nicht auf einem Produktivsystem eingesetzt werden sollte.
Hinweis
3.7 Metux MPM
Ich möchte mich an dieser Stelle nochmals ganz herzlich bei Enrico Weigelt
(http://www.metux.de), dem Autor des Moduls metuxmpm, für die Unterstützung bei der Dokumentation dieses Moduls bedanken. Eine Version des
Moduls für den Apache 2.0.48 war bei der Drucklegung des Buches noch nicht
verfügbar.
3.7.1
Hinweis
145
Installation
Falls Sie das Modul metuxmpm nicht manuell installieren möchten, finden Sie
unter ftp://ftp.suse.com/pub/people/poeml/apache2/8.2-i386 und http://debian.helasnet
vorgefertigte Pakete für SuSE bzw. Debian.
Um das Modul metuxmpm manuell zu installieren, müssen Sie sich zunächst von
http://httpd.apache.org die aktuell unterstützte Version 2.0.47 des Apache 2 herunterladen und mit Hilfe des Befehls
# tar xvzf httpd-2.0.47.tar.gz
entpacken. Hinweis: Wechseln Sie noch nicht in das neu erzeugte Verzeichnis httpd2.0.47, da Sie zunächst einen Patch installieren müssen.
Da es momentan für das Modul noch keine offizielle Downloadmöglichkeit gibt, hat
einer der Entwickler (Asbjorn Sannes) unter http://www.sannes.org/metuxmpm/ einige
Informationen und Downloads zusammengestellt. Von dort müssen Sie sich deshalb
die aktuelle Version des Moduls als Patch (http://www.sannes.org/metuxmpm/r7/httpd2.0.47-metuxmpm-r7.diff) herunterladen. Daraufhin können Sie die Software mit folgendem Befehl in die aktuelle Version des Apache (2.0.47) integrieren:
# patch -p0 < httpd-2.0.47-metuxmpm-r7.diff
Die Ausgabe des Befehls patch zeigt nun die Dateien an, die durch die Integration des
Moduls metuxmpm verändert worden sind:
patching
patching
patching
patching
patching
patching
patching
file
file
file
file
file
file
file
httpd-2.0.47/server/mpm/config.m4
httpd-2.0.47/server/mpm/experimental/metuxmpm/Makefile.in
httpd-2.0.47/server/mpm/experimental/metuxmpm/config5.m4
httpd-2.0.47/server/mpm/experimental/metuxmpm/metuxmpm.c
httpd-2.0.47/server/mpm/experimental/metuxmpm/mpm.h
httpd-2.0.47/server/mpm/experimental/metuxmpm/mpm_default.h
httpd-2.0.47/srclib/apr/network_io/unix/sockets.c
Wechseln Sie in das Quellverzeichnis des Apache (cd httpd-2.0.47) und sorgen Sie für
die Aktualisierung einiger, zur Kompilierung des Apache, benötigter Dateien:
# ./buildconf
Hinweis
146
3 Erweiterte Installation
Dieser Befehl verwendet u.a. die Programme libtool und autoconf. Sollten Sie die
Programme nicht installiert haben, müssen Sie diese mit Hilfe der Softwareverwaltung Ihrer Distribution (z.B. YaST) oder manuell nachinstallieren.
Die Ausführung des Befehls buildconf ist notwendig, da der vorhin installierte Patch
des metuxmpm den Quellcode des Apache verändert hat und somit u.a. eine Aktualisierung des configure-Skriptes notwendig ist. Daraufhin lässt sich die erfolgreiche
Integration des metuxmpm in den Quellcode des Apache mit folgendem Befehl überprüfen:
# ./configure --help | grep -B 1 metuxmpm
Dieser Befehl gibt eine Liste der zur Kompilierung des Apache zur Verfügung stehenden Optionen aus und durchsucht diese nach dem Schlüsselwort metuxmpm. Der
Parameter -B 1 führt zusätzlich dazu, dass die vor der eigentlichen Fundstelle stehende Zeile ebenfalls ausgegeben wird. Es erscheint folgende Ausgabe.
--with-mpm=MPM
Choose the process model for Apache to use.
MPM={beos|worker|prefork|mpmt_os2|perchild|leader|threadpool|metuxmpm}
Erfreulicherweise wurde die Liste der verfügbaren Laufzeitverhalten (MPM) um das
manuell installierte metuxmpm erweitert und die eigentliche Installation des Apache 2
kann beginnen. Dabei könnte eine minimale Installation des Apache wie folgt aussehen:
Hinweis
# ./configure --prefix=/usr/local/apache2 --with-mpm=metuxmpm
Dies ist wirklich eine sehr minimalistische Variante, um den Apache zu installieren bzw. die Installation vorzubereiten. Selbstverständlich können Sie diesem
Befehl weitere Optionen, die Sie durch Eingabe des Befehls ./configure --help
erhalten, hinzufügen. Lesen Sie diesbezüglich bitte auch die entsprechenden
Erläuterungen zur Installation des Apache 2 in diesem Buch.
Die eigentliche Kompilierung des Apache wird durch den Befehl
# make
gestartet. Sobald dieser abgeschlossen ist, können Sie die Installation nach
/usr/local/apache2 durch Eingabe des Kommandos
# make install
beenden. Widmen wir uns nun der Konfiguration des Moduls:
3.7 Metux MPM
3.7.2
147
Konfiguration
Generell werden durch das Modul metuxmpm die folgenden drei Konfigurationsanweisungen bereitgestellt:
Multiplexer
Startet einen Multiplexer-Kindprozeß unter der angegebenen Benutzer- und Gruppenkennung.
Konfigurationsanweisung:
Multiplexer
Syntax:
Multiplexer Benutzerkennung Gruppenkennung
Standardwert (Default):
nicht definiert
Enthalten in Modul:
Metuxmpm
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit Hilfe der Multiplexer-Anweisung definieren Sie einen so genannten MultiplexerKindprozess, der mit einer von Ihnen zu definierenden Benutzer- und Gruppenkennung gestartet werden soll, wobei momentan nur der Einsatz eines Multiplexers
sinnvoll ist. Der Multiplexer untersucht die eingehenden Clientanfragen auf ihre HostHeader und ordnet diese dementsprechend den virtuellen Servern zu. Ein Beispiel:
Hinweis
Multiplexer www-data www-data
Die Benutzer und Gruppen, die Sie zur Ausführung der virtuellen Server
benutzen möchten, müssen auf Ihrem System real existieren!
Diese Anweisung startet einen Multiplexer mit der Benutzerkennung www-data und
der gleichnamigen Gruppenkennung. Generell kann als Multiplexer dieselbe Benutzer- und Gruppenkennung verwendet werden, mit der auch der Apache ausgeführt
wird. Sie erhalten die Benutzerkennung durch Eingabe von:
# grep -E '^User' /usr/local/apache2/conf/httpd.conf
Bei dem von mir verwendeten System liefert dieser Befehl folgende Ausgabe, wobei
nur die erste Zeile für uns relevant ist:
Hinweis
User www-data
UserDir public_html
Auf vielen System wird die Benutzerkennung nobody verwendet.
148
3 Erweiterte Installation
Auch die Gruppenkennung, mit der der Apache ausgeführt wird, lässt sich leicht
herausfinden (vgl. User- und Group-Anweisung):
# grep -E '^Group' /usr/local/apache2/conf/httpd.conf
Dabei ist der Name der Gruppenkennung, mit der der Apache auf meinem Testsystem ausgeführt wird, mit dem bereits genannten Benutzernamen identisch:
Hinweis
Group www-data
Auf vielen System wird die Gruppe nogroup zur Ausführung des Apache verwendet.
Falls noch kein separater Benutzer zur Ausführung des Apache existiert oder Sie die
virtuellen Server aus Sicherheitsgründen mit einer speziellen Benutzerkennung
betreiben möchten, können Sie diesen selbstverständlich auch manuell anlegen. Dazu
sollten Sie jedoch zunächst eine eigenes Gruppe erzeugen:
# groupadd apache2
Nun können Sie der neu erstellten Gruppen einen Benutzer namens apache2 hinzufügen:
# useradd -g apache2 -d /dev/null -s /bin/false apache2
Die entsprechende Multiplexer-Anweisung sieht infolgedessen wie folgt aus:
Multiplexer apache2 apache2
Processor
Der Processor verarbeitet die eigentlichen Clientanfragen.
Konfigurationsanweisung:
Processor
Syntax:
Processor Benutzerkennung Gruppenkennung
Standardwert (Default):
nicht definiert
Enthalten in Modul:
Metuxmpm
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Während der Multiplexer die Clientanfragen nur entgegennimmt, werden diese
durch den so genannten Processor verarbeitet. Auch diese Anweisung erwartet die
Angabe einer Benutzer- und Gruppenkennung, die zur Ausführung verwendet werden soll, wobei die definierte Gruppenkennung mit der der Multiplexer-Anweisung
übereinstimmen muss:
Processor sebastian apache2
3.7 Metux MPM
149
Aufgrund dieser Konfiguration können Sie einen virtuellen Server anlegen, der mit
der Benutzerkennung sebastian und der Gruppenkennung apache2 betrieben wird.
Prinzipiell ist auch die Ausführung mehrerer virtueller Server mit ein- und derselben
Benutzer- und Gruppenkennung möglich.
AssignUserID
Bindet einen virtuellen Server an eine bestimmte Benutzer- und Gruppenkennung.
Konfigurationsanweisung:
AssignUserID
Syntax:
AssignUserID Benutzername Gruppenname
Standardwert (Default):
nicht definiert
Enthalten in Modul:
Metuxmpm
Kontext:
Server-Kontext, Virtual-Host Kontext
Anweisung aktiv:
nein
Mit der AssignUserID-Anweisung können Sie einem virtuellen Server eine Benutzerund Gruppenkennung zuweisen, mit der ein virtueller Server ausgeführt werden soll,
wobei diese vorher durch eine Multiplexer- bzw. eine Processor-Anweisung definiert
worden sein müssen. Ein Beispiel:
AssignUserID sebastian apache2
Durch diese Anweisung wird der entsprechende virtuelle Server mit der Benutzerkennung sebastian und der Gruppenkennung apache2 ausgeführt.
3.7.3
Praxisbeispiel
Da die korrekte Verwendung der oben genannten Konfigurationsanweisungen
sicherlich etwas verwirrend ist, möchte ich ein kleines Beispiel für den Einsatz des
metuxmpm vorstellen. Hinweis: Die nachfolgende Konfiguration verwendet die
Benutzerkennung sebastian und die Gruppenkennung apache2. Außerdem wird als
Installationsverzeichnis des Apache 2 das Verzeichnis /usr/local/apache2 verwendet.
Sollten diese Werte auf dem von Ihnen verwendeten System variieren, müssen Sie
diese entsprechend anpassen.
Erstellen Sie zunächst testweise zwei neue Domains namens example.com und
example2.com, indem Sie die entsprechende Zonen in Ihrem Nameserver anlegen.
Sofern Sie keinen Zugriff auf einen Nameserver haben, können Sie diese Einträge
temporär auch in der Datei /etc/hosts (Unix/Linux) bzw. C:\WinNT\System32\
Drivers\Etc\hosts (Windows 2000/XP) vornehmen. Die entsprechenden Einträge
sehen beispielsweise wie folgt aus:
192.168.0.6
192.168.0.6
www.example.com example.com
www.example2.com example2.com
Hinweis
150
3 Erweiterte Installation
Die hier verwendete IP-Adresse 192.168.0.6 ist gemäß der von Ihnen verwendeten Adresse anzupassen.
Speichern Sie die Datei und fügen Sie der zentralen Konfigurationsdatei httpd.conf des
Apache folgende Anweisungen hinzu:
Multiplexer apache2 apache2
Processor sebastian apache2
Speichern Sie die Datei und fügen Sie der zentralen Konfigurationsdatei httpd.conf des
Apache folgende Anweisungen hinzu:
NameVirtualHost *
KeepAlive Off
Entfernen Sie eine eventuell vorhandene Auskommentierung (»#«) und fügen Sie die
folgenden Zeilen der Datei hinzu:
<VirtualHost *>
AssignUserID sebastian apache2
Servername www.example.com
DocumentRoot /usr/local/apache2/htdocs
ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"
</VirtualHost>
Hinweis
<VirtualHost *>
AssignUserID sebastian apache2
Servername www.example2.com
DocumentRoot /srv/www/htdocs
</VirtualHost>
Diese Konfiguration ist unvollständig, verkürzt und für die Praxis nicht sonderlich sinnvoll. Sie dient lediglich der Veranschaulichung.
Die oben genannte Konfiguration erstellt zunächst einen Multiplexer, der die Anfragen der Clients entgegennimmt und einen Processor. Dieser Processor dient zur Ausführung zweier virtueller Server (www.example.com und www.example2.com), wobei
die Zuweisung des zuständigen Processors an den jeweiligen virtuellen Server mit
Hilfe der AssignUserID-Anweisung erfolgt. Ermöglichen Sie nun außerdem die Ausführung von CGI-Skripten im Verzeichnis cgi-bin des ersten virtuellen Servers, indem
Sie ca. in Zeile 608 der Datei httpd.conf die Option ExecCGI einfügen, so dass die entsprechende Stelle in der Datei wie folgt aussieht:
3.7 Metux MPM
151
<Directory "/usr/local/apache2/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
Speichern Sie die Änderungen an der Datei httpd.conf und starten Sie den Apache neu.
Erstellen Sie zusätzlich im Verzeichnis /usr/local/apache2/cgi-bin eine Datei namens
test.pl mit folgendem Inhalt:
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "<html>";
print "<h2>Test von metuxmpm</h2>";
print "Hallo Welt<br>\n";
print "Meine Benutzer- und Gruppenkennung lautet: <br><b>\n";
system("/usr/bin/id");
print "</b>\n<br>";
print "\n Ich bin der Benutzer: <br><b>\n";
system("/usr/bin/whoami");
print "</b>\n<br>";
print "Fertig :-)<br>\n";
print "</html>";
Speichern Sie auch diese Datei und geben Sie ihr die Ausführberechtigung:
# chmod +x /usr/local/apache2/cgi-bin/test.pl
Starten Sie den Apache neu und rufen Sie die Datei unter der Adresse
http://www.example.com/cgi-bin/test.pl auf und Sie werden feststellen, dass der virtuelle
Server für die Domain www.example.com tatsächlich unter einer eigenen Benutzerkennung ausgeführt wird:
Demnach verrichtet das Modul metuxmpm erwartungsgemäß korrekt seinen Dienst,
quod erat demonstrandum :-)
152
3 Erweiterte Installation
Abbildung 3.1 Die Testseite zeigt die ordnungsgemäße Funktionsweise
des Moduls metuxmpm
3.8
Updates
Von Zeit zu Zeit bringt die Apache Software Foundation neuere Versionen des
Apache Webservers heraus. Diese bringen teilweise neue Funktionen, beheben kritische Fehler oder Sicherheitsprobleme (Stichwort: chunk encoding, vgl. http://www.
cert.org/advisories/CA-2002-17.html sowie http://httpd.apache.org/info/security_bulletin_
20020809a.txt, kritischer Fehler in der Win32, OS/2 und Netware-Variante des Apache, behoben in 2.0.42) und es ist gerade im Falle der Veröffentlichung einer kritischen Sicherheitslücke immer sinnvoll, ein Update zu machen. Zwar gilt für
Updates die Systemadministrator-Maxime Never change a running system, aber falls
es sich um ein sicherheitskritisches Update handelt, sollten Sie es in jedem Fall einspielen. Der Ablauf eines Updates deckt sich mit der Neuinstallation des Apache,
allerdings sollten Sie vor dem Ausführen des Befehls make install den alten Server
anhalten. Sie sollten außerdem vor dem Update eine Sicherung Ihrer alten Installation vornehmen, damit Sie diese, im Falle eines unerwartet auftretenden Problems,
sicher wieder zurückspielen können. Wenn Sie eine vorkompilierte Version des
Apache benutzt haben, können Sie die alte Version einfach löschen und die Neue
einspielen (Konfigurationsdateien vorher sichern!). Sollten Sie eine durch Ihre
jeweilige Distribution (SuSE, RedHat, Debian etc.) bereitgestellte Version des Apache benutzen, kann ein Update unter Umständen problematisch sein, denn nicht
immer werden rasch aktualisierte Pakete durch die Distributoren bereitgestellt, d.
h., es kann teilweise nötig sein (z. B. im Falle eines Sicherheitsproblems), das Update
des Apache manuell durchzuführen. Leider ist es mit einigem Aufwand verbunden,
die durch den Bereitsteller der zuvor verwendeten Version des Apache (z.B. SuSE)
verwendeten Konfigurationsoptionen herauszubekommen, so dass man diese bei
einem Update selber nutzen kann. Verwendet man die ursprünglich genutzten
Optionen nicht, kann es passieren, dass man unter Umständen andere Verzeichnisse benutzt, als es ursprünglich der Fall war und somit das Update nicht vollständig und erfolgreich durchgeführt werden kann. Wenn Ihnen jedoch die ursprünglich verwendeten Konfigurationsoptionen vorliegen, sollte ein Update auch ohne
Verwendung eines durch den jeweiligen Distributor (Hersteller, z. B. SuSE) zur Verfügung gestellten Paketes problemlos möglich sein.
Wenn Sie möchten, können Sie sogar die alte Konfiguration der vorherigen Version
übernehmen. Kopieren Sie dazu die Datei config.nice aus dem Quellverzeichnis der
3.8 Updates
153
alten Version in das Quellverzeichnis der neueren Version und führen Sie diese Datei
aus. Aus diesem Grunde sollten Sie bei der Installation des Apache zumindest die
Datei config.nice sichern, damit Sie im Falle eines Updates die alte Konfiguration ohne
Probleme wieder einspielen können. Im Apache 1.3.x hieß diese Datei übrigens config.status (diese Datei existiert zwar weiterhin, hat aber eine völlig neue Bedeutung
bekommen). Für den von mir verwendeten Installationsaufruf der Version 2.0.47
sieht die Datei config.nice wie folgt aus:
#! /bin/sh
#
# Created by configure
"./configure" \
"--enable-layout=Apache" \
"[email protected]"
Ich möchte Ihnen den Ablauf eines Updates anhand eines konkreten Beispieles von
der Version 2.0.47 auf 2.0.48 vorstellen. In meinem Heimatverzeichnis /home/sebastian
habe ich die alte Version (Verzeichnisname: /home/sebastian/httpd-2.0.47) komplett
gesichert und die neue Version frisch vorliegen (Verzeichnis: /home/sebastian/httpd2.0.48). Die Installation der alten Version ist seinerzeit nach /usr/local/apache2 erfolgt,
die Konfigurationsoptionen stehen in der Datei /home/sebastian/httpd-2.0.47/config.nice.
Ich kopiere also die Datei config.nice in das Verzeichnis der neuen Version:
/home/sebastian # cp httpd-2.0.47/config.nice ./httpd-2.0.48/
Ich wechsele in das Verzeichnis der Version 2.0.48 und führe das Konfigurationsskript, welches ich ja bereits in der Version 2.0.47 benutzt habe, aus:
/home/sebastian/httpd-2.0.48 # ./config.nice
Die Konfiguration der neuen Version beginnt und sobald diese abgeschlossen ist,
kann die Software auch schon kompiliert werden:
/home/sebastian/httpd-2.0.48 # make
Nun beende ich die alte Version des Häuptlings und spiele die neue Version ein:
/home/sebastian/httpd-2.0.48 # killall httpd
/home/sebastian/httpd-2.0.48 # make install
Keine Angst, es werden dabei keine Konfigurationsdateien der alten Version überschrieben. Der neue Apache muss sich nun ohne Probleme starten lassen:
# /usr/local/apache2/bin/httpd
Das eigentliche Update ist damit schon abgeschlossen, durch folgenden Aufruf kann
man die korrekte Installation der neuen Version überprüfen:
# /usr/local/apache2/bin/httpd -v
154
3 Erweiterte Installation
Der Befehl sollte die Versionsnummer und das Kompilierungsdatum des Apache
ausgeben:
Server version: Apache/2.0.48
Server built: Oct 05 2002 11:15:30
Interessant ist, dass man dem Skript config.nice auch noch eigene Parameter mit angeben kann, die an den alten Aufruf des configure-Skriptes angehängt werden. In der
Datei config.nice steht eine eventuell kryptisch anmutende Zeichenkette [email protected], die dafür
sorgt, dass der Parameter, der an das aufgerufene Shellskript config.nice übergeben
worden ist, an den alten Aufruf von configure angehängt wird. Somit lassen sich nachträglich Änderungen an den ursprünglich verwendeten Konfigurationsoptionen vornehmen. Wenn Sie beispielsweise das Modul mod_imap in Ihrer ursprünglichen Serverkonfiguration verwendet haben, dieses jedoch jetzt nicht mehr nutzen möchten,
können Sie das Skript config.nice wie folgt aufrufen:
# ./config.nice --disable-imap
Es stehen Ihnen beim Aufruf von config.nice prinzipiell alle Optionen zur Verfügung,
die es bei der Neuinstallation des Apache gibt (siehe vorherige Kapitel).
Und nicht vergessen: Das nächste Update ist immer das Schwerste :-)
4 Betrieb
4.1
Starten/Stoppen des Apache unter
Unix/Linux
Sie können den Apache unter Unix/Linux direkt durch die eigentliche Programmdatei httpd steuern, die Sie im Unterverzeichnis bin Ihrer lokalen Installation des Apache finden (z.B. /usr/local/apache2/bin/httpd). Eine Liste der zur Verfügung stehenden
Parameter erhalten Sie durch Eingabe des Befehls
Hinweis
# /usr/local/apache2/bin/httpd -h
Sofern Sie den Apache in ein anderes Verzeichnis installiert haben, müssen Sie
den Befehl entsprechend anpassen.
Folgende Parameter sind bei der Ausführung der Programmdatei httpd verfügbar:
Parameter
Bedeutung
-D Name
Wenn Sie innerhalb der Konfigurationsdatei httpd.conf einen separaten Bereich mittels eines <IfDefine>-Containers definiert haben,
können Sie durch Angabe des Parameter -D die Ausführung aller
Anweisungen erzwingen, die innerhalb des durch Name spezifizierten <IfDefine>-Containers stehen. Alle Konfigurationsanweisungen, die außerhalb des genannten <IfDefine>-Containers stehen,
werden nicht ausgeführt.
-d Verzeichnis
Falls gewünscht, können Sie das Basisinstallationsverzeichnis des
Servers anhand dieses Parameters angeben (entspricht der Konfigurationsanweisung ServerRoot).
-f Datei
Ermöglicht die Benutzung einer alternativen Konfigurationsdatei
für den Server. Falls der Parameter nicht angegeben wird, wird die
Konfigurationsdatei httpd.conf aus dem Unterverzeichnis conf der
lokalen Installation des Apache verwendet (z.B.
/usr/local/apache2/conf/httpd.conf).
-C »Anweisung«
Der Parameter gibt Ihnen die Möglichkeit, eine Konfigurationsanweisung zu definieren, die vor der Einlesung der gesamten Konfigurationsdatei httpd.conf aktiviert wird.
-c »Anweisung«
Definieren Sie eine Konfigurationsanweisung, die nach der Einlesung der gesamten Konfigurationsdatei httpd.conf aktiviert wird
(vergleichbar mit -C).
Tabelle 4.1 Mögliche Kommandozeilenparameter der Programmdatei
httpd unter Unix/Linux
156
4 Betrieb
Parameter
Bedeutung
-e Ebene
Entsprechend der Konfigurationsanweisung LogLevel können Sie
mit diesem Parameter die Detailtiefe der Meldungen definieren, die
während des Betriebs des Servers in die durch die ErrorLogAnweisung bestimmte Datei protokolliert werden.
-E Datei
Wenn Sie die Fehler-/Warnmeldungen, die beim Start des Apache
auftreten, in eine eigene Datei speichern möchten, können Sie dies
unter Angabe des Parameters -E und einer Protokollierungsdatei
tun.
-v
Beim Aufruf dieses Parameters werden die Versionsangabe sowie
das Kompilierungsdatum ausgegeben. Ein Beispiel:
Server version: Apache/2.0.48
Server built: Nov 29 2003 12:05:36
-V
Gibt diverse Informationen über die Parameter aus, die zur Kompilierung und Installation des Apache 2 genutzt worden sind.
Beispiel:
Server version: Apache/2.0.48
Server built: Nov 29 2003 12:05:36
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR=»server/mpm/prefork«
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=»/usr/local/httpd-2.0.48«
-D SUEXEC_BIN=»/usr/local/httpd-2.0.48/bin/suexec«
-D DEFAULT_PIDLOG=»logs/httpd.pid«
-D DEFAULT_SCOREBOARD=»logs/apache_runtime_status«
-D DEFAULT_LOCKFILE=»logs/accept.lock«
-D DEFAULT_ERRORLOG=»logs/error_log«
-D AP_TYPES_CONFIG_FILE=»conf/mime.types«
-D SERVER_CONFIG_FILE=»conf/httpd.conf«
Tabelle 4.1 Mögliche Kommandozeilenparameter der Programmdatei
httpd unter Unix/Linux (Forts.)
4.1 Starten/Stoppen des Apache unter Unix/Linux
157
Parameter
Bedeutung
-h
Ausgabe einer Übersicht der zur Verfügung stehenden Optionen
(entspricht dieser Liste).
-l
Mit Hilfe dieses Parameters können Sie sich eine Liste der Module
ausgeben lassen, die fest in den Server integriert sind. Ein Beispiel:
compiled in modules:
core.c
mod_access.c
mod_auth.c
mod_ext_filter.c
mod_include.c
mod_deflate.c
mod_log_config.c
mod_env.c
mod_setenvif.c
mod_proxy.c
proxy_connect.c
proxy_ftp.c
proxy_http.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_info.c
mod_cgi.c
mod_vhost_alias.c
mod_negotiation.c
mod_dir.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_so.c
Tabelle 4.1 Mögliche Kommandozeilenparameter der Programmdatei
httpd unter Unix/Linux (Forts.)
158
4 Betrieb
Parameter
Bedeutung
-L
Der Parameter erzeugt eine Liste der aufgrund der von Ihnen
gewählten Konfiguration des Apache zur Verfügung stehenden
Konfigurationsanweisungen und gibt diese Liste (lang!), inklusive
einer kurzen Beschreibung für jede Anweisung, aus.
-t -D DUMP_VHOSTS
Dieser Befehl ist eine Sonderform der Parameter -t sowie -D und
gibt eine Übersicht über die konfigurierten virtuellen Server aus.
Zusätzlich wird eine Überprüfung der Syntax durchgeführt.
Ein Beispiel:
VirtualHost configuration:
194.11.23.99:443 www.fantasie-ag.de
(/usr/local/apache2_ssl/conf/httpd.conf:1040)
Syntax OK
-t
Führt eine syntaktische Überprüfung der Konfigurationsdatei
httpd.conf durch und weist auf eventuell vorhandene Fehler hin.
Tabelle 4.1 Mögliche Kommandozeilenparameter der Programmdatei
httpd unter Unix/Linux (Forts.)
Die genannten Parameter können Sie dem Aufruf der Programmdatei httpd einfach
beifügen, wie folgendes Beispiel zeigt:
# /usr/local/apache2/bin/httpd -t -D DUMP_VHOSTS
Gemäß der oben genannten Tabelle überprüft dieser Befehl die in der Konfigurationsdatei httpd.conf verwendete Syntax und gibt eine Liste der momentan aktiven virtuellen Server aus:
VirtualHost configuration:
194.11.23.99:443 www.fantasie-ag.de (/usr/local/apache2_ssl/conf/httpd.conf:1040)
Syntax OK
Um den eigentlichen Server zu starten, können Sie folgenden Befehl verwenden:
# /usr/local/apache2/bin/httpd
Alternativ können Sie ein Shellskript namens apachectl verwenden, um den Server zu
steuern. Sie finden das Skript ebenfalls im Unterverzeichnis bin Ihrer lokalen Installation des Apache und es bietet die nachfolgenden Parameter:
4.1 Starten/Stoppen des Apache unter Unix/Linux
159
Parameter
Bedeutung
start
Startet den Apache und gibt gegebenenfalls eine Fehlermeldung
aus, falls dieser bereits läuft. Man spricht in diesem Zusammenhang auch von einem Daemon, da der Apache als Serverprozess
dauerhaft läuft und die Anfragen der Clients bearbeitet.
stop
Stoppt den Server/Daemon.
restart
Neustart des Apache-Daemon: Sendet dem Apache-Prozess ein
SIGHUP-Signal. Wenn der Daemon nicht läuft, wird er gestartet.
Dieser Befehl überprüft mittels der Option configtest vor der Einleitung des Neustarts automatisch die Konfigurationsdateien, um
sicherzustellen, dass sich der Apache neu starten lässt.
fullstatus
Gibt einen umfassenden Status-Report von mod_status zurück.
Damit dies funktioniert, muss mod_status aktiviert sein und ein
textbasierter Browser (z.B. Lynx) installiert sein.
Die URL, über die entfernt auf den Status-Report zugegriffen werden kann, kann über die Variable STATUSURL im apachectl-Skript
gesetzt werden.
status
Gibt einen kurzen Status-Report zurück (vergleichbar mit der fullstatus-Option, jedoch ohne die Anzahl der aktuellen Requests).
graceful
»Eleganter« Neustart des Apache-Daemons: Sendet dem ApacheProzess ein SIGUSR1-Signal. Wenn der Daemon nicht läuft, wird er
gestartet.
Der Unterschied zu einem restart (Neustart) besteht darin, dass
momentan offene Verbindungen nicht unterbrochen werden.
Dieser Befehl überprüft mittels der Option configtest vor der Einleitung des Neustarts automatisch die Konfigurationsdateien,
um sicherzustellen, dass sich der Apache neu starten lässt.
Auf Plattformen, die das USR1-Signal nicht erlauben (z.B. Win32),
wird automatisch ein anderes Signal (wie z.B. WINCH) verwendet.
configtest
Überprüft die Syntax der Konfigurationsdatei(en). Ist die Syntax in
Ordnung, wird »Syntax OK« zurückgegeben, andernfalls eine
detaillierte Information über den Syntax-Fehler.
help
Zeigt eine kurze Hilfe an, die mit der Hilfe der Programmdatei
httpd (siehe oben) identisch ist.
Tabelle 4.2 Mögliche Kommandozeilenparameter des Shellskriptes
apachectl unter Unix/Linux
Die vorgestellten Parameter können Sie dem Aufruf des Skriptes apachectl einfach beifügen, wie folgendes Beispiel zeigt:
# /usr/local/apache2/bin/apachectl start
160
4 Betrieb
Der Befehl startet den Apache und gibt eine Warnmeldung aus, die uns an dieser
Stelle jedoch vorerst (noch) nicht interessieren soll (vgl. ServerName-Anweisung):
httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1
for ServerName
Um den Server zu stoppen, können Sie folgenden Befehl verwenden:
# /usr/local/apache2/bin/apachectl stop
Wenn Sie den Apache gerade erst neu installiert haben, müssen Sie unter Umständen
in der Konfigurationsdatei httpd.conf ein paar Änderungen vornehmen, bevor Sie den
Apache-Daemon starten können, da der Apache standardmäßig versucht, unter der
Benutzerkennung »nobody« und der Gruppenkennung »#-1« zu starten. Falls dies
nicht funktioniert (siehe Fehlermeldungen in der Error-Logdatei, z.B. /usr/local/
apache2/logs/error_log), sollten Sie für Apache einen User und eine Gruppe definieren
und die zugehörigen Einträge in der Konfigurationsdatei httpd.conf (z.B. /etc/
apache2/httpd.conf) ändern (siehe Kapitel »Benutzer- und Gruppenverwaltung«):
Beispiel: User »wwwrun« der Gruppe »aprun«
# groupadd aprun
# useradd -c "Benutzer fuer den Apache" -g aprun \
-d /usr/local/apache2 -s /bin/false wwwrun
Eintrag in httpd.conf:
User wwwrun
Group aprun
Starten Sie nun den Apache-Daemon mit
# /usr/local/apache2/bin/apachectl start
Rufen Sie im Browser http://localhost/ auf. Falls der Apache korrekt arbeitet, sollten Sie
eine Willkommensseite sehen. Andernfalls hilft Ihnen ein Blick in die Error-Logdatei
(z.B. /usr/local/apache2/logs/error_log) weiter.
4.2
Starten/Stoppen des Apache unter
Microsoft Windows
Durch eine Verknüpfung im Ordner Autostart des Startmenüs sowie die Installation
als Dienst, die durch Ausführung von %SystemRoot%\system32\services.msc /s bzw.
unter Systemsteuerung→ Verwaltung→Dienste überwacht werden kann, setzt der Server nun bei jedem Systemstart automatisch ein. Dabei wird die Datei Apache.exe -k runservice im Unterverzeichnis bin des lokalen Installationsverzeichnisses des Apache 2
ausgeführt. Falls ein automatischer Start des Apache verhindert werden soll, so kann
dies in der Systemsteuerung eingestellt werden.
4.2 Starten/Stoppen des Apache unter Microsoft Windows
161
Wenn der Apache läuft und die Datei ApacheMonitor.exe gestartet ist, befindet sich in
der Taskleiste ein kleines Icon (Feder mit grünem Pfeil in weißem Kreis) und informiert so über die Aktivität des Apache. Sobald der Server gestoppt ist, wird aus dem
grünen Pfeil in der Taskleiste ein kleiner roter Punkt, der die Inaktivität des Apache
darstellt. Durch einen Linksklick auf dieses Icon lässt sich der Server stoppen, starten
und komplett neu starten. Durch einen Klick mit der rechten Maustaste auf diesem
Icon hat man die Möglichkeit, in die Systemsteuerung zur Verwaltung der Dienste zu
gelangen (»Open Services« im Menü genannt) oder den so genannten »Apache Monitor« aufzurufen.
Abbildung 4.1 Apache Service Monitor unter Windows
Dort kann der Status des Servers geprüft und gegebenenfalls gestartet, gestoppt und
komplett neu gestartet werden. Auch befindet sich dort unter Services wieder der Verweis in die Systemsteuerung. Im Startmenü wurde bei der Installation des Apache
eine Verknüpfung für diesen eingerichtet, die die Kontrolle über die Aktivitäten des
Servers ermöglicht. Der Apache Server wird übrigens beim Beenden des Apache Service Monitor nicht automatisch mit beendet.
Der Aufbau der Verzeichnisstruktur unter Windows ist mit der Struktur unter
Unix/Linux fast identisch:
Laufwerk:\Pfad\Apache
Apache2
bin
Hier befinden sich ausführbare Programme wie htpasswd, rotatelogs etc. sowie
das eigentliche Apache-Programm (httpd.exe).
162
4 Betrieb
cgi-bin
CGI (Common Gateway Interface)-Programme sind in diesem Verzeichnis zu finden. Nach der Installation ist dort nur ein einziges Skript namens printenv.pl vorhanden, welches Umgebungsvariablen anzeigt.
conf
Die zentrale Konfigurationsdatei httpd.conf des Indianers liegt hier sowie eine
Tabelle mit MIME-Typen.
error
Die Informationsseiten des Apache, die im Falle eines Fehlers angezeigt werden,
befinden sich in diesem Verzeichnis und können entsprechend den jeweiligen
Wünschen und Gegebenheiten angepasst werden.
htdocs
Die Informationen und Dateien (Grafiken, HTML-Dateien etc.), die veröffentlicht
werden sollen, werden in diesem Verzeichnis gespeichert.
icons
Im PNG- und GIF-Format befinden sich hier diverse kleine Bildchen (so genannte
Icons), die der Apache bei diversen Anlässen (u.a. Verzeichnislistings etc.) anzeigt.
logs
Die Logdateien, die Auskunft über eventuell aufgetretene Fehler und die Anzahl
bzw. Inhalte der Clientanfragen geben, befinden sich im Verzeichnis »logs«.
manual
Das komplette Handbuch des Apache 2.0 im HTML-Format.
modules
Der vorkompilierten Version des Apache liegen viele Module als Shared Objects bei.
Dies sind im Einzelnen:
mod_access
mod_actions
mod_alias
mod_asis
mod_auth
mod_auth_anon
mod_auth_dbm
mod_auth_digest
mod_autoindex
4.2 Starten/Stoppen des Apache unter Microsoft Windows
mod_cache
mod_cern_meta
mod_cgi
mod_dav
mod_dav_fs
mod_dir
mod_disk_cache
mod_env
mod_expires
mod_file_cache
mod_headers
mod_imap
mod_include
mod_info
mod_isapi
mod_log_config
mod_mem_cache
mod_mime
mod_mime_magic
mod_negotiation
mod_proxy
mod_proxy_connect
mod_proxy_ftp
mod_proxy_http
mod_rewrite
mod_setenvif
mod_speling
mod_status
mod_unique_id
mod_userdir
mod_usertrack
mod_vhost_alias
163
164
4 Betrieb
proxy
Falls der Apacheserver gleichzeitig auch als Proxyserver eingesetzt wird, werden
in diesem Verzeichnis die durch die Clients aufgerufenen Seiten zwischengespeichert.
5 Konfiguration
5.1
Einleitung
5.1.1
Begriffsdefinition
Ich benutze in diesem Buch zahlreiche Begriffe, die ich kurz erklären möchte. Teilweise benutze ich sogar mehrere Begriffe für ein und dieselbe Sache, also aufgepasst:
Konfigurationsanweisung: Eine Konfigurationsanweisung ist eine Konfigurationsoption, die in der zentralen Konfigurationsdatei httpd.conf des Apache gesetzt wird
und das Verhalten des Servers in irgendeiner Weise beeinflusst oder sogar verändert. Von mir verwendete Synonyme sind Anweisung, Option, Konfigurationsoption,
Konfigurationsparameter und Direktive.
Syntax: Konfigurationsoptionen verfügen immer über ein vorgegebenes Aussehen
und eine ganz bestimmte Anzahl an möglichen Parametern. Die Syntax einer Option definiert das korrekte Aussehen und den sprachlich richtigen Aufruf einer
Option. Es handelt sich also dabei im Prinzip um eine Art Rechtschreibung für
Konfigurationsoptionen.
URL: Als URL bezeichne ich einen vollständigen Uniform Resource Locator, der aus
einem Schema (z.B. http), einem Hostnamen (www.beispiel.de) sowie einer optional
Pfadangabe (z.B. kontakt.html) besteht. Ein Beispiel: http://httpd.apache.org/docs2.0/configuring.html
URL-Pfad: Als URL-Pfad benenne ich den Teil einer URL, der nach der Angabe eines Schemas und eines Hostnamens erscheint. Dabei ist der URL-Pfad praktisch die
Sichtweise aus dem Internet auf eine Datei bzw. ein Verzeichnis. Für unser Beispiel
von eben sieht der zugehörige URL-Pfad wie folgt aus: /docs-2.0/configuring.html
Dateipfad: Der Pfad zu einer Datei aus Sicht des Dateisystems. Sofern ein Dateipfad
nicht mit einem vorangehenden Forwardslash (»/«) beginnt, wird dieser als relativ
zu dem als ServerRoot definierten Verzeichnis eingestuft (z.B. conf/httpd.conf). Ist
dieser Slash vorhanden, wird von einer absoluten Pfadangabe (z.B. /usr/local/
apache2/conf/httpd.conf) ausgegangen.
Verzeichnispfad: Der Pfad zu einem Verzeichnis aus Sicht des Dateisystems. Auch
hier wird davon ausgegangen, dass bei es sich bei Vorhandensein eines vorangehenden Forwardslash um einen absoluten Verzeichnispfad handelt (z.B. /usr/
local/apache2/conf). Fehlt dieser Slash, wird eine Verzeichnisangabe (z.B. conf/) als
relativ zu dem als ServerRoot definierten Verzeichnis angesehen.
Dateiname: Der Name einer Datei ohne Pfadangaben (z.B. kontakt.html).
Regulärer Ausdruck: Gemeint ist ein regulärer Ausdruck, eine Art Suchmuster für
Zeichenkette (vgl. Anhang).
166
5 Konfiguration
Dateinamenserweiterung: Mit diesem umständlichen Wort, welches ich teilweise
auch als Dateiendung abkürze, wird die Endung einer Datei beschrieben (z.B.
.html).
MIME-Typ: Der MIME-Typ definiert das Format einer Information und sorgt dafür, dass Informationen durch das jeweils richtige Programm verarbeitet werden,
welches ein ausgewähltes Format (z.B. text/html) versteht.
5.1.2
Konfigurationsdateien
Der Apache besitzt eine zentrale Konfigurationsdatei namens httpd.conf, die alle Konfigurationsanweisungen enthält. Bei der Standardinstallation (--enable-layout=Apache)
befindet sich diese Datei im Verzeichnis /usr/local/apache2/conf, ebenfalls genutzte Orte
für die Lagerung dieser Datei sind, abhängig von den gewählten Installationsoptionen und der Installationsart, folgende Verzeichnisse:
/etc/httpd (SuSE)
/etc/httpd/conf (RedHat)
/var/www/conf (OpenBSD)
/etc/apache (Solaris)
/usr/etc/apache2 (Debian)
Weitere Auskunft über den Speicherort der Datei httpd.conf gibt die Datei config.layout, die dem Quellcode des Apache beiliegt. Sollten Sie dennoch die Datei httpd.conf
nicht finden, suchen Sie diese mit folgendem Befehl:
# find / -name httpd.conf -print
Neben dieser zentralen Datei liegen der Installation des Apache noch einige weitere
Dateien bei, die diverse Aufgaben übernehmen:
highperformance-std.conf, highperformance.conf: Diese Dateien enthalten Beispielwerte für diverse Konfigurationsoptionen, die die Performance des Apache steigern
sollen. Weitere Informationen zur Steigerung der Performance finden Sie in der
Datei perf-tuning.html, die im Unterverzeichnis misc Ihres Apache-Handbuchs
(docs/manual) zu finden ist.
httpd-std.conf: Die Standardkonfigurationsdatei des Apache, welche direkt nach
der Installation identisch ist, mit der Datei httpd.conf, sofern kein Update vorgenommen worden ist.
magic: Falls mod_mime den Typ einer Datei und damit die entsprechenden Header
nicht feststellen kann, werden die ersten paar Bytes der unerkannten Datei ausgelesen und mit den in der Datei magic stehenden Werten verglichen, um doch noch
den korrekten Header für die Datei zu setzen.
5.1 Einleitung
167
mime-types: In dieser Datei sind die entsprechenden Header den jeweiligen Dateitypen zugeordnet. Ruft ein Client beispielsweise eine Datei mit der Endung .html
oder .htm auf, wird automatisch der Headertyp text/html (vgl. Zeile 426 in der Datei
mime.types) gesetzt.
ssl-std.conf, ssl.conf: Die gesamte SSL-Konfiguration wurde inzwischen ausgelagert,
weil die Konfigurationsdatei httpd.conf einfach zu lang geworden ist.
5.1.3
Syntax der Konfigurationsanweisungen
Die folgenden Kapitel beschäftigen sich mit der Konfiguration des Apache und
beschreiben alle Konfigurationsanweisungen. Ich habe mir zur Beschreibung und
Erklärung jedes Konfigurationsparameters folgende Darstellungsform ausgedacht:
Konfigurationsanweisung:
Name der Anweisung
Syntax:
Anweisungsname Optionen
Standardwert (Default):
standardmäßig vorgegebener Wert
Enthalten in Modul:
mod_???
Kontext:
Global, <VirtualHost>, <Directory> etc.
Anweisung aktiv:
ja | nein
Zuerst wird der Name der Konfigurationsanweisung genannt, gefolgt von der
Anzahl und Syntax der möglichen Optionen und Parameter. Wenn eine Anweisung
mehrere Varianten haben kann, so werden diese Varianten durch eine Pipe (senkrechter Strich, »|«) getrennt. Optionale Parameter werden in eckigen Klammern genannt,
die bei Angabe eines solchen (optionalen) Parameters natürlich weggelassen werden
müssen.
Als nächster Punkt wird der direkt nach der Installation vorgegebene Wert aufgelistet, d.h. der Standardwert. Sofern eine Anweisung keinen Standardwert besitzt bzw.
dieser nach der Installation des Apache gesetzt ist, taucht der in der Konfigurationsdatei httpd.conf direkt nach der Installation vorhandene Aufruf einer Anweisung auf.
Außerdem wird der Name des Moduls angegeben, in dem die jeweilige Option vorhanden ist, teilweise sind dies sogar mehrere Module. Sollten Sie das angegebene
Modul nicht in Ihrem Apache integriert haben, können Sie die vorgestellte Option
auch nicht nutzen, eine Neuinstallation bzw. ein Update des Servers ist unter
Umständen nötig.
Als vorletzte Angabe erfolgt die Nennung eines Kontextes, d.h. eines Gültigkeitsbereiches, in dem eine bestimmte Konfigurationsanweisung stehen darf. Einige
Anweisungen können durchaus in mehreren Bereichen verwendet werden und weisen deshalb mehrere Kontexte auf.
Zu guter Letzt wird angegeben, ob die Anweisung standardmäßig gesetzt, d.h. aktiv
ist, oder nicht (durch ein »#«-Zeichen zu Beginn der zugehörigen Zeile in der Konfigurationsdatei httpd.conf des Apache auskommentiert).
168
5 Konfiguration
Für die Konfigurationsanweisung DocumentRoot, die bekanntlich sehr früh in der
Konfigurationsdatei httpd.conf des Apache auftaucht und von sehr zentraler Bedeutung ist, würde diese Darstellungsform wie folgt aussehen:
Konfigurationsanweisung:
DocumentRoot
Syntax:
DocumentRoot Verzeichnis
Standardwert (Default):
/usr/local/apache2/htdocs
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Basiskonfiguration, <VirtualHost>
Anweisung aktiv:
ja
Die Konfigurationsanweisung DocumentRoot erwartet als einzigen Parameter die
Angabe eines Verzeichnisses, in dem die zu veröffentlichenden Informationen gespeichert sind. Je nach gewählter Installationseinstellung (vgl. dazu Datei config.layout)
wird ein Verzeichnis unterhalb des Hauptinstallationsverzeichnisses des Apache
genommen. Für das von mir verwendete Layout Apache kommt hier das Verzeichnis
/usr/local/apache2/htdocs zum Einsatz, da dieses laut Definition für die Speicherung und
Bereitstellung der Webseiten vorgesehen ist. Enthalten ist diese Direktive im Kernmodul des Apache (mod_core) und es kann sowohl in der Basiskonfiguration des Servers (Server-Kontext) als auch in einem VirtualHost-Kontext genutzt werden. Standardmäßig ist diese Option in der Serverkonfiguration aktiviert.
5.1.4
Kommentare
Kommentare gibt es in der zentralen Konfigurationsdatei httpd.conf des Apache
extrem viele. Diese Kommentare werden durch das so genannte Rautezeichen (»#«)
definiert und der Apache überliest jede Zeile, die zu Beginn ein derartiges Zeichen
enthält. Wenn Sie Kommentare in httpd.conf einfügen möchten, so benutzen Sie ebenfalls das Rautezeichen. Wenn Sie einen eigenen Kommentar einfügen möchten, so
können Sie diesen beispielsweise wie folgt kennzeichnen:
# Hallo, ich bin ein Kommentar
Wie Sie vielleicht schon gemerkt haben, ist die Konfigurationsdatei httpd.conf mit Hinweisen, Kommentaren und Dokumentationen der Entwickler des Apache geradezu
übersäht (im positiven Sinne!). Diese kurzen, aber sehr präzisen Hilfestellungen sollten Sie, sofern Sie einigermaßen der englischen Sprache mächtig sind, durchlesen und
beachten. Eine typische Hilfestellung der Entwickler des Servers beinhalt zum Beispiel die Konfigurationsanweisung ServerAdmin:
#
#
#
#
#
ServerAdmin: Your address, where problems with the
server should be
e-mailed. This address appears on some servergenerated pages, such
as error documents. e.g. [email protected]
5.1 Einleitung
169
Natürlich werde ich im Laufe des Buchs auf die verschiedenen Konfigurationsoptionen des Apache eingehen und diese näher erläutern, so dass auch nicht sonderlich
erfahrene sowie der englischen Sprache nicht oder nur schlecht bewanderte Leser den
Server gemäß ihren Wünschen und Anforderungen konfigurieren können.
5.1.5
Mehrzeilige Anweisungen
Wie unter Unix/Linux üblich, können Zeilen durch Angabe des Backslashs »\«
umbrochen werden, wenn beispielsweise Konfigurationsanweisungen zu lang oder
unübersichtlich geworden sind. Unter Umständen kann es eventuell zu einer Fehlermeldung kommen, da der Apache nicht bei jeder Anweisung einen Zeilenumbruch
erlaubt. Ansonsten können Sie die Anweisung wie folgt auf mehrere Zeilen verteilen:
BrowserMatch "Microsoft Data Access Internet Publishing Provider" \
redirect-carefully
Zur Sicherheit sollten Sie die Konfigurationsdatei vor dem Start des Apache auf eventuelle Konfigurations- bzw. Syntaxfehler untersuchen. Diese Aufgabe kann der Apache mit Angabe des Parameters –t selbst vornehmen. Durch folgenden Befehl rufen
Sie einen Syntaxcheck auf, sofern das Installationsverzeichnis wirklich /usr/local/
apache2 lautet:
# /usr/local/apache2/bin/httpd -t
Die Überprüfung des Syntax sollte keine Fehlermeldung zurückliefern:
Syntax OK
Sie können nun den Server wie gewohnt starten, ohne dass es zu Fehlermeldungen,
die durch Zeilenumbrüche verursacht worden sind, kommen sollte. Hinweis: Sofern
eine Anweisung nicht übermäßig lang wird, sollten Sie diese in eine Zeile schreiben.
Diese Aussage gilt insbesondere für Programmlistings und Benutzereingaben (u.ä.).
5.1.6
Aufteilung auf mehrere Konfigurationsdateien
Die Größe und der Umfang der Konfigurationsdatei httpd.conf machen sie, gerade für
Anfänger, sehr schwer durchschaubar und unübersichtlich. Deshalb gibt es die Möglichkeit, bestimmte Teile der Konfiguration in eigene Dateien auszugliedern, um
somit den Umfang von httpd.conf zu begrenzen. Die Datei ssl.conf ist ein Beispiel für
die Auslagerung eines Teils der Konfiguration des Apache in eine eigene Datei. Weitere sinnvolle Auslagerungen sind VirtualHosts und Modulanweisungen. Bitte
beachten Sie jedoch, dass eine zu detaillierte Auslagerung in externe Dateien bisweilen für Verwirrung sorgen kann. Eine externe Konfigurationsdatei wird mit folgender
Anweisung in die Datei httpd.conf integriert:
Include conf/beispiel.conf
170
5 Konfiguration
Die Verzeichnisangabe conf bezieht sich immer auf das Hauptverzeichnis der lokalen
Apache-Installation, d.h. der Server sucht in diesem Beispiel also nach einer Datei
namens beispiel.conf, die unterhalb des Hauptinstallationsverzeichnisses (z.B.
/usr/local/apache2) in einem Unterverzeichnis conf liegt (vollständiger Pfad:
/usr/local/apache2/conf/beispiel.conf). Es besteht zudem die Möglichkeit, in einer IncludeAnweisung komplette Verzeichnisse in die Konfiguration zu integrieren, in dem
diese Include-Anweisung nicht auf eine spezielle Datei, sondern auf ein ganzes Verzeichnis verweist:
Include conf/BeispielA
Dieser Befehl würde dementsprechend alle Dateien unterhalb des Verzeichnisses BeispielA öffnen und in die Serverkonfiguration integrieren. BeispielA ist dabei ein Unterverzeichnis im Verzeichnis conf der lokalen Apache-Installation (z.B. /usr/local/
apache2/conf/BeispielA).
5.1.7
Kontexte
In meinen Ausführungen zu den Konfigurationsoptionen des Apache stößt man,
ebenso wie in der bekannten Literatur, immer wieder auf den Begriff Kontext. Ein
Kontext definiert den Anwendungs- und Gültigkeitsbereich einer Konfigurationsanweisung des Apache. Die im Laufe dieses Buches vorgestellten und erläuterten
Konfigurationsanweisungen verfügen alle über mindestens einen Kontext, in dem die
Benutzung der jeweiligen Konfigurationsanweisung möglich und erlaubt ist, teilweise ist die Verwendung einer Anweisung sogar in mehreren Kontexten möglich.
Prinzipiell unterscheidet man folgende Kontexte:
Server-Kontext: Eine Anweisung, die im Server-Kontext steht, ist eine global gültige
Einstellung, die das grundlegende Verhalten des Server bestimmt und nachhaltig
verändert. Einige Konfigurationsanweisungen sind nur in diesem Kontext gültig,
manche sind darüber hinaus auch in einem VirtualHost-Kontext möglich. Stellenweise verwende ich für den Server-Kontext auch das Synonym Basiskonfiguration.
Man bezeichnet alle Anweisungen außerhalb der <VirtualHost>-Container als Teil
der globalen Serverkonfiguration.
Container-Kontext: Es gibt eine Reihe von Konfigurationsanweisungen, die sich auf
einen bestimmten, durch einen so genannten Container eingegrenzten Bereich beziehen und auch nur in diesem Bereich gültig sind. Die begrenzenden Container
sind z.B. <Directory>, <Files> und <Location> Anweisungen.
VirtualHost-Kontext: Durch einen virtuellen Host (VirtualHost) kann man auf einem Server mehrere (virtuelle) Server gleichzeitig betreiben, die alle voneinander
unabhängig arbeiten. Für den aufrufenden Client ist es praktisch kaum möglich,
eine Unterscheidung zu treffen, ob es sich um einen virtuellen Host handelt oder
nicht. Durch einen virtuellen Host können mehrere Benutzer auf ein und demselben Server ihre Webseiten voneinander unabhängig betreiben, wobei die zur Verfügung stehenden Ressourcen des Systems aufgeteilt werden. Dabei überschreiben
einige der im Kontext eines Virtual-Hosts stehenden Konfigurationsanweisungen
5.2 Basiskonfiguration
171
die im Bereich des Server-Kontextes getätigten Einstellungen, da es sich dabei im
Prinzip um einen Server im Server handelt. Die Nutzung von Container-Kontexten
sowie .htaccess-Kontexten ist auch innerhalb eines Virtual-Host-Kontextes möglich.
.htaccess-Kontext: Anweisungen, die in einer .htaccess-Datei stehen, verhalten sich
nahezu analog zu Anweisungen, die in einem <Directory>-Container stehen. Der
wichtigste Unterschied ist jedoch, dass die Anweisungen, die in einer .htaccess-Datei stehen, durch die Option AllowOverride in der zentralen Konfigurationsdatei
httpd.conf überschrieben werden können.
Befindet sich eine Anweisung außerhalb des für sie gültigen Kontextes, d.h. außerhalb ihres Gültigkeitsbereiches, gibt der Apache eine Fehlermeldung aus, die auf die
Nutzung einer Anweisung außerhalb des erlaubten Kontextes hinweist. Ich habe beispielsweise versucht, die Anzahl der beim Start des Apache ebenfalls startenden Serverprozesse in einem <Directory> Kontext zu setzen. Da die Verwendung der Option
StartServers in einem <Directory> Container nicht statthaft ist, erhalte ich eine Fehlermeldung des Apache und der Server startet nicht:
kingpin:/usr/local/apache2/bin# ./httpd
Syntax error on line 332 of /usr/local/apache2/conf/httpd.conf:
StartServers not allowed here
Die Fehlermeldung enthält sogar die Nummer der Zeile (hier 332), in der ich unerlaubterweise versuchte, die Option StartServers zu verwenden. Sollten Sie mehrere
syntaktische Fehler in der Konfigurationsdatei httpd.conf haben, wird nur der zuerst
auftretende Fehler gemeldet und die weitere Abarbeitung der gesamten Konfigurationsdatei abgebrochen.
5.2
Basiskonfiguration
Bevor ich auf die Vielzahl der zur Verfügung stehenden Konfigurationsoptionen eingehe, sollen Sie eine detaillierte Einführung in die Basiskonfiguration des Servers
erhalten. Die durch das mod_core genannte Kernmodul des Apache bereitgestellten
Direktiven und Konfigurationsoptionen bestimmen die Basiskonfiguration und das
grundlegende Verhalten des Servers.
Die Basiskonfigurationsoptionen von mod_core lassen sich prinzipiell in drei verschiedene Bereiche einordnen: Serveridentifikation, Dateistandorte und Grenzwertbestimmung.
Es gibt noch einige weitere Anweisungen, auf die ich aber erst im weiteren Verlauf
dieses Kapitels eingehen möchte.
Der erste Bereich bestimmt u.a. anhand der Optionen ServerAdmin und ServerTokens,
welche Informationen auf durch den Server generierten Dokumenten (z.B. Fehlermeldungen) erscheinen sollen. Zusätzlich werden die Direktiven ServerName und
UseCanonicalName dazu genutzt, um selbst referenzierende, d.h. auf den Server selbst
verweisende URLs zu erzeugen. Fordert ein Client beispielsweise ein Verzeichnis
an, vergisst jedoch, den abschließenden Forwardslash (»/«) anzugeben (z.B.
http://www.domain.tld/dir1 anstatt richtigerweise http://www.domain.tld/dir1/), so muss
172
5 Konfiguration
der Apache den Client an den vollständigen Namen sowie den abschließenden Forwardslash weiterleiten, damit der Client die ursprünglich von ihm gewünschten
Informationen erhält.
Die durch mod_core ebenfalls bereitgestellten sieben Direktiven CoreDumpDirectory,
DocumentRoot, ErrorLog, LockFile, PidFile, ScoreBoardFile und ServerRoot geben Auskunft über den Standort einiger Dateien, die der Server für seine korrekte Ausführung benötigt. Beginnt der angegebene Pfadname nicht mit einem führenden Forwardslash (»/«), so wird der Pfad als relativ zu dem als ServerRoot definierten
Verzeichnis interpretiert. Ist der Apache beispielsweise nach /usr/local/apache2 installiert und das ErrorLog liegt im Verzeichnis logs/error_log, interpretiert der Server diese
Datei als eine Datei im Unterverzeichnis logs der Apache-Installation und verweist
deshalb auf den Pfad /usr/local/apache2/logs/error_log. Beachten Sie bitte außerdem die
Sicherheitshinweise im Laufe des Buches zu den Dateistandorten und ihren Berechtigungen!
Den dritten und letzten Teil der durch das Kernmodul des Apache bereitgestellten
Basisdirektiven bilden die Anweisungen zur Begrenzung der Ressourcen des Servers.
Es gibt vier LimitRequest*-Anweisungen, die den Umfang der Beanspruchung der
Ressourcen des Servers bei Zugriffen (engl: request) von Clients beschränken. Die drei
RLimit*-Direktiven regeln den Umfang der Ressourcen, die ein Unterprozess des
Apache, etwa zur Abarbeitung einer CGI oder SSI-Anfrage, für sich beanspruchen
kann. Die letzte durch mod_core bereitgestellte Direktive ThreadStackSize regelt auf der
Netware-Plattform die Größe des Stacks.
Nach der Erläuterung dieser drei Gruppen von Basisdirektiven, die alle durch
mod_core angeboten werden, werde ich gegen Ende dieses Kapitels auf die Konfiguration einiger Direktiven eingehen, die zwar nicht durch das Kernmodul des Apache
bereitgestellt werden, aber dennoch zur Basiskonfiguration des Servers gehören und
auf keinen Fall fehlen dürfen.
Hinweis
Um eine der nachfolgend vorgestellten und erläuterten Optionen zu ändern, öffnen
Sie mit Ihrem Lieblingseditor die zentrale Konfigurationsdatei httpd.conf des Apache,
die sich meist im Unterverzeichnis conf Ihrer lokalen Apache-Installation befindet,
und suchen Sie in der Datei nach den jeweiligen Konfigurationsoptionen.
Alle hier vorgestellten Konfigurationsoptionen beziehen sich auf die Version
2.0.48 des Apache (Stand: 30.11.2003). Bis Sie dieses Buch in Händen halten,
kann es durchaus sein, dass sich die Syntax einzelner Anweisungen zwischenzeitlich geändert hat oder neue Anweisungen hinzugekommen sind, da der
Apache 2 sich noch in der Entwicklung befindet.
5.2 Basiskonfiguration
5.2.1
173
Serveridentifikation
ServerName
Angabe des Servernamens und Ports (optional)
Konfigurationsanweisung:
ServerName
Syntax:
ServerName Domainname[:Port]
Standardwert (Default):
#ServerName new.host.name:80
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein (auskommentiert)
Die Anweisung ServerName gibt den so genannten fully-qualified-domain-name (FQDN)
eines Servers an, über den der Server durch einen Client angesprochen werden soll.
Dies ist der im DNS (domain name system) eingetragene, registrierte, vollständige und
gültige Name eines Servers. Der Apache muss immer wissen, wie der Name des Servers lautet, auf dem er läuft. Kann er den Namen des Servers nicht auflösen, gibt es
eine Fehlermeldung und die als localhost definierte IP-Adresse 127.0.0.1 wird als Servername genutzt. Eine derartige Fehler- bzw. Warnmeldung sieht wie folgt aus:
httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1
for ServerName
Der Server beschwert sich also, dass er keinen gültigen Namen des Servers finden
kann, weil dieser wahrscheinlich gar nicht oder falsch konfiguriert ist. Ist dies der Fall
wird, wie dieses Beispiel zeigt, die IP-Adresse 127.0.0.1 als ServerName genutzt.
Ein gültiger Eintrag für die Konfigurationsanweisung ServerName wäre beispielsweise folgender:
ServerName www.domain.tld
Sollten Sie noch keinen im DNS registrierten Namen für Ihren Server haben, wenden
Sie sich bitte an Ihren Administrator bzw. den Administrator des für Sie zuständigen
Nameservers oder Providers. Verwenden Sie in der Zwischenzeit die IP-Adresse des
Servers, wie dieses Beispiel zeigt:
ServerName 194.53.77.113
Sobald Sie einen gültigen Namen für Ihren Server erhalten haben, können Sie diesen
als ServerName verwenden. Neu in der Version 2 des Apache ist die optionale Angabe
eines Ports, auf dem der Apache lauschen soll. In der alten Version 1.3 existierte dazu
eine eigene Anweisung namens Port, die es inzwischen jedoch überhaupt nicht mehr
gibt. Für unser obiges Beispiel sieht die Angabe des ServerName mit einer Portnummer wie folgt aus:
ServerName www.domain.tld:80
174
5 Konfiguration
Die Anweisung bindet den Apache an den Standardport 80 (TCP), der Name des Servers lautet www.domain.tld. Der Apache verwendet den Namen und Port des Servers
bei der Generierung von selbstreferenzierenden, d.h. auf den Server selbst verweisenden, URLs. Wird kein eindeutiger ServerName definiert, so kann dies unter Umständen zu dem unerwünschten Verhalten führen, dass bei ungünstiger Konfiguration
eine Selbstreferenzierung auf den realen Hostnamen des Servers (rechnername.domain.tld) verweist, anstatt auf den gewählten Alias des Servers
(www.domain.tld). Sollten Sie Probleme mit Ihrem Servernamen haben oder handelt es
sich bei Ihrem Server um ein Entwicklungs- oder Testsystem, können Sie als ServerName auch die IP-Adresse 127.0.0.1 verwenden:
ServerName 127.0.0.1
ServerAlias
ServerAlias definiert alternative Hostnamen für einen Server.
Konfigurationsanweisung:
ServerAlias
Syntax:
ServerAlias Hostname
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
VirtualHost-Kontext
Anweisung aktiv:
nein
Wenn Sie für einen virtuellen Server einen alternativen Hostnamen definieren möchten, können Sie dies mit der ServerAlias-Anweisung realisieren. Dabei ist die Definition weiterer Hostnamen nur in Verbindung mit namenbasierenden virtuellen Servern möglich, die Anweisung erwartet die Angabe eines (oder auch mehrerer)
alternativer Hostnamen. Ein Beispiel:
<VirtualHost *>
ServerName hotzenplotz.beispiel.de
ServerAlias www.beispiel.de beispiel.de internet.beispiel.de
...
</VirtualHost>
Diese Anweisungen würden einen neuen virtuellen Server definieren, der zugleich
als Standard fungieren würde. Der vollständige Rechnername (rechnername.domain.tld) dieses Servers lautet hotzenplotz.beispiel.de, der Server ist jedoch
auch unter den Adressen www.beispiel.de, beispiel.de und internet.beispiel.de erreichbar,
da entsprechende ServerAlias-Anweisungen alternative Hostnamen für den Server
definieren.
Zusätzlich können Sie auch Wildcards (z.B. *) benutzen, um alle Anfragen mit einer
Anweisung abzufangen:
ServerAlias *.beispiel.de
5.2 Basiskonfiguration
175
Bitte beachten Sie jedoch, dass im Nameserver ein Alias für die mit NameVirtualHost
definierte IP-Adresse vorhanden sein muss (vgl. Anhang).
ServerPath
ServerPath definiert einen URL-Pfad für einen namenbasierenden virtuellen Server.
Konfigurationsanweisung:
ServerPath
Syntax:
ServerPath Url-Pfad
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
VirtualHost-Kontext
Anweisung aktiv:
nein (nicht vorhanden)
Gerade ältere Clients unterstützen den mit HTTP/1.1 definierten Host-Header noch
nicht und übermitteln dem Apache somit nicht den Hostnamen der Website, die Sie
abrufen möchten. Dadurch gelangen diese Clients beim Zugriff auf den Server auf den
ersten virtuellen Server des Systems, da der Apache nicht entscheiden kann, welchen
virtuellen Server ein Client wirklich wollte. Mit der Konfigurationsanweisung ServerPath können Sie für ältere Clients den URL-Pfad definieren, der zu einem bereits bestehenden virtuellen Server gehört. Diese Funktion ist jedoch äußerst rudimentär und
funktioniert nicht zufriedenstellend. Da die meisten Clients inzwischen HTTP/1.1
unterstützen, benötigen Sie diese Konfigurationsanweisung eigentlich nicht mehr.
ServerAdmin
Angabe einer administrativen E-Mail-Adresse.
Konfigurationsanweisung:
ServerAdmin
Syntax:
ServerAdmin E-Mail-Adresse
Standardwert (Default):
ServerAdmin [email protected]
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Wie der Name schon vermuten lässt, wird mit der Option ServerAdmin die E-MailAdresse einer verantwortlichen Person gesetzt, die mit der Administration des Servers vertraut ist. Diese E-Mail-Adresse, üblicherweise [email protected], erscheint
bei der Darstellung einer Fehlermeldung, die an den Client gesendet wird, damit die
Endnutzer sich im Falle eines dauerhaften Problems mit der oder dem Verantwortlichen in Verbindung setzen können. Lautet die E-Mail-Adresse des Administrators
etwa [email protected] so würde die Anweisung wie folgt aussehen:
ServerAdmin [email protected]
176
5 Konfiguration
ServerSignature
Angabe einer Fußzeile bei serverseitig generierten Dokumenten.
Konfigurationsanweisung:
ServerSignature
Syntax:
ServerSignature On | Off | EMail
Standardwert (Default):
ServerSignature On
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Kontext
Anweisung aktiv:
ja
Mit der Option ServerSignature kann eine optionale Fußzeile an serverseitig generierte
Dokumente (Fehlermeldungen, Verzeichnislistings, Ausgabe von mod_status und
mod_info etc.) angehängt werden. Die Fußnote wird nicht bei durch CGI-Skripte
dynamisch erzeugten Inhalten angehängt, sie enthält durch den Parameter On die
Version des Apache und den Namen des Servers (ServerName). Der Parameter EMail
fügt diesen beiden Angaben zusätzlich noch die als ServerAdmin angegebene E-MailAdresse des Administrators hinzu. Wenn Sie dieses Verhalten nicht wünschen, können Sie die Verwendung einer zusätzlichen Fußzeile durch den Parameter Off ganz
abschalten. Ein Beispiel für die Verwendung der Konfigurationsoption ServerSignature:
ServerSignature On
Bitte beachten Sie jedoch, dass es unter Umständen einer Anpassung der vorgegebenen Fehlerseiten, die Sie im Unterverzeichnis error Ihrer Apache-Installation finden,
bedarf, bevor auch bei der Angabe des Parameters On bzw. EMail alle gewünschten
Informationen (Name des Servers, Version, Administrator) angezeigt werden. Weitere Informationen zur Individualisierung der Fehlermeldungen erhalten Sie im
Laufe dieses Buches. Hinweis: Ab der Version 2.0.44 des Apache werden die in der
Versionsangabe des Servers enthaltenen Informationen durch die ServerTokensAnweisung bestimmt.
ServerTokens
ServerTokens bestimmt den Inhalt des Rückgabewert des HTTP-Headers.
Konfigurationsanweisung:
ServerTokens
Syntax:
ServerTokens Minimal | ProductOnly | OS | Full
Standardwert (Default):
Full
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein (nicht vorhanden)
5.2 Basiskonfiguration
177
Wenn ein Client auf den Server zugreift, schickt der Server eine Antwort auf HTTPProtokollebene, einen so genannten Header, an den Client zurück. Mit der Konfigurationsanweisung ServerTokens kann der Umfang der an den Client gesendeten Informationen bestimmt werden.
Standardmäßig ist die Anweisung in der httpd.conf überhaupt nicht gesetzt und es
wird deshalb ein vollständiger Rückgabewert (Parameter: Full) an den Client gesendet, der sich aus dem Namen und Version der verwendeten Serversoftware sowie
den zur Verfügung stehenden Modulen und Erweiterungen zusammensetzt. Der Server liefert in diesem Fall beispielsweise folgende Informationen an einen Client
zurück:
Apache/2.0.48 (Unix) PHP/4.3.4
Sie haben mit dieser Anweisung verschiedene Möglichkeiten, den Umfang der an den
Client gesendeten Informationen einzuschränken. Die kürzeste Auskunft, die an den
Client gesendet werden kann, ist folgende:
ServerTokens ProductOnly
Dabei gibt der Server nur die verwendete Serversoftware ohne Angabe von Versionsnummer oder gar der zur Verfügung stehenden Erweiterungen preis. Der Server liefert in diesem Fall die folgende, recht spartanische Antwort:
Apache
Wenn Sie diese Option nutzen, stellen Sie sicher, dass die Anweisung ServerSignature
auf Off gestellt ist, damit auf Fehlerseiten etc. keine Informationen über Versionsnummern etc. enthalten sind!
Sie können die Auskunft um die verwendete Versionsnummer erweitern, wenn Sie
die Konfigurationsanweisung ServerTokens wie folgt wählen:
ServerTokens Minimal
Der Server würde dementsprechend etwa folgende Antwort an den Client senden:
Apache/2.0.48
Die letzte Möglichkeit, die diese Anweisung bietet, ist der Parameter OS, der zusätzlich zur verwendeten Serversoftware und Version das dem Server zugrunde liegende
Betriebssystem (z.B. Unix oder Win32) preisgibt. Sie setzen diese Informationsstufe
mit der Anweisung:
ServerTokens OS
Der Server antwortet wie gewünscht mit dem Namen der Serversoftware, der entsprechenden Version sowie dem dem Server zugrunde liegenden Betriebssystem:
Apache/2.0.48 (Unix)
178
5 Konfiguration
Ich persönlich bin der Ansicht, dass man nicht jedem Nutzer die verwendeten Softwareversionen und Module auf die Nase binden sollte, und empfehle daher, die Konfigurationsanweisung auf den Wert ProductOnly zu setzen und die Anweisung ServerSignature auf Off. Der Client erhält damit nur die Information, dass es sich bei dem
Server um einen Apache handelt, und bekommt keinerlei Informationen über die
Versionsnummer und die genutzten Module.
Sicherlich ist es beispielsweise mit dem Programm nmap (http://www.insecure.org/nmap/)
möglich, aufgrund der unterschiedlichen TCP/IP-Implementierungen der auf dem
Markt erhältlichen Betriebssysteme, das dem Server zugrunde liegende Betriebssystem
relativ genau festzustellen und somit entsprechende Informationen über den Server zu
sammeln. Verwendet man dazu jedoch ein Programm wie PortSentry von
http://www.psionic.com (gehört inzwischen zu Cisco!) zur Erkennung und Bekämpfung
von Portscans, kann man sich einen relativ guten Schutz gegen ScriptKiddies und
unerfahrene Hacker aufbauen.
Wenn Sie möchten, können Sie den Umfang der an den Client gesendeten Informationen auch im Quellcode des Apache bestimmen. Entpacken Sie dazu den Quellcode
des Apache, öffnen Sie die Datei ap_release.h, die Sie im Unterverzeichnis include finden, und ändern Sie die Werte in Zeile 74 – 78 gemäß Ihren Vorstellungen. Für die
von mir genutzte Version 2.0.48 sehen die Zeilen 74 – 78 dieser Datei wie folgt aus:
#define
#define
#define
#define
#define
AP_SERVER_BASEVENDOR "Apache Software Foundation"
AP_SERVER_BASEPRODUCT "Apache"
AP_SERVER_MAJORVERSION "2"
AP_SERVER_MINORVERSION "0"
AP_SERVER_PATCHLEVEL "48"
Eventuell erscheinen die Zeilen in Ihrer Version des Apache ein paar Zeilen weiter
unten, da unter Umständen der Datei ap_release.h zusätzlicher Quellcode hinzugefügt
worden ist. Ich habe diese Zeilen jedenfalls wie folgt geändert:
#define
#define
#define
#define
#define
AP_SERVER_BASEVENDOR "Microsoft"
AP_SERVER_BASEPRODUCT "Microsoft-IIS"
AP_SERVER_MAJORVERSION "5"
AP_SERVER_MINORVERSION "0"
AP_SERVER_PATCHLEVEL ""
Speichern Sie die Datei ap_release.h und kompilieren Sie den Apache neu. Setzen Sie
nun die Konfigurationsoption ServerTokens auf den Wert Minimal und Ihr Server meldet sich zukünftig als Microsoft-IIS/5.0 wie folgender Auszug aus der Antwort des
Servers auf eine Anfrage eines Clients beweist:
HTTP/1.1 200 OK
Date: Sun, 29 Nov 2003 11:41:55 GMT
Server: Microsoft-IIS/5.0.
Content-Location: index.html.en
Vary: negotiate,accept,accept-language,accept-charset
TCN: choice
Last-Modified: Fri, 04 May 2001 00:01:18 GMT
5.2 Basiskonfiguration
179
ETag: "39856e-5b0-40446f80;3985b1-961-8562af00"
Accept-Ranges: bytes
Content-Length: 1456
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en
Expires: Sun, 29 Nov 2003 11:41:55 GMT
Ich möchte an dieser Stelle eindringlich darauf hinweisen, dass das Verschleiern von
Systeminformationen, oft abwertend Security by obscurity genannt, keine Stärkung der
Sicherheit eines Systems darstellt. Es handelt sich dabei, wie in diesem Beispiel,
vielmehr um einen Spaß, der nicht wirklich etwas bringt und unter Umständen (z.B.
bei Modifizierung der lokalen TCP/IP-Implementation) sogar die gesamte TCP/IPImplementierung Ihres System verlangsamt und gegebenenfalls schädigt. Wenn Sie
allerdings (wie ich) Spaß an solchen Scherzen haben, sollten Sie sich einmal die
Programme IP-Personality (http://ippersonality.sourceforge.net) und Kernel OS-Faker
(http://www.hit2000.org/kosf/) ansehen, die für die Versionen 2.4.x bzw. 2.2.x des
Linux-Kernels nette Spielereien mit der TCP/IP-Umgebung Ihres Betriebssystems
ermöglichen. Dadurch sind Programme wie der Portscanner nmap (http://www.
insecure.org/nmap) nicht mehr in der Lage, das jeweilige Betriebssystem (inklusive
Version!) eines entfernten Rechners anhand der unterschiedlichen TCP/IP-Implementierungen zu bestimmen, da das Netzwerkverhalten eines anderen Betriebssystems emuliert wird und derartige Programme vorsätzlich getäuscht werden.
Zur Optimierung der Sicherheit Ihres Systems möchte ich Sie an dieser Stelle auf die
entsprechenden Kapitel in diesem Buch und bekannte externe Quellen verweisen.
UseCanonicalName
Bestimmt die Art und Weise, wie der Server seinen Namen und Port feststellt.
Konfigurationsanweisung:
UseCanonicalName
Syntax:
UseCanonicalName on | off | dns
Standardwert (Default):
UseCanonicalName on
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, .htaccess-Kontext
Anweisung aktiv:
ja
Der Server muss in vielen Fällen eine selbstreferenzierende Adresse (URL) erzeugen,
d.h. eine URL die auf den Server selbst verweist. Durch die Anweisung UseCanonicalName wird die Art und Weise bestimmt, wie der Server seinen eigenen Namen und
Port bestimmt. Ist diese Anweisung auf den Wert On gestellt, benutzt der Server den
Namen und Port des durch die Konfigurationsanweisung ServerName gesetzten Wertes. Dazu folgendes Beispiel:
ServerName server1.beispiel.de:80
UseCanonicalName On
180
5 Konfiguration
Erzeugt der Server nun auf sich selbst verweisende URLs, verwendet er den Namen
und Port, des als ServerName angegebenen Wertes. Die Angabe eines Ports ist hier
übrigens optional. Falls kein Port angegeben worden ist, wird der Standardport 80
(TCP) verwendet. Außer zur Erzeugung von selbstreferenzierenden Adressen werden der Name und der Port des Servers zudem in CGI- und PHP-Skripten durch die
Variablen SERVER_NAME und SERVER_PORT bereitgestellt und somit durch den
Server vorgegeben.
Alternativ kann die Konfigurationsanweisung UseCanonicalName auch den Wert Off
erhalten, wodurch im Falle einer selbstreferenzierenden Adresse, der Name und Port
des Servers durch den vom Client übermittelten Wert bestimmt werden. Übermittelt
ein Client keine Informationen über den Namen des gewünschten Servers sowie dessen Port, wird der durch die Anweisung ServerName gesetzte Name und Port benutzt.
Enthält die Anweisung ServerName keine Portangabe, wird der durch die Direktive
Listen definierte Port angesprochen. Hier ein Beispiel für die Verwendung von UseCanonicalName:
UseCanonicalName Off
Falls Sie massenweise IP-basiertes, virtuelles Hosting benutzen, ist der dritte mögliche Parameter von UseCanonicalName namens DNS der Richtige für Sie, denn mit dieser Einstellung startet der Server einen reverse DNS lookup der IP-Adresse des Servers,
um seine eindeutige Adresse für selbstreferenzierende URLs zu bestimmen. In diesem Falle würde die UseCanonicalName-Anweisung wie folgt aussehen:
UseCanonicalName DNS
5.2.2
Erweiterte Basiskonfiguration
Die nachfolgenden Konfigurationsoptionen werden größtenteils nicht durch
mod_core bereitgestellt, sie sind jedoch derart wichtig, dass diese in der Grundkonfiguration des Servers nicht fehlen dürfen.
HostnameLookups
HostnameLookups schaltet die Auflösung der IP-Adressen der Clients in deren Hostnamen ein oder aus.
Konfigurationsanweisung:
HostnameLookups
Syntax:
HostnameLookups on | off | double
Standardwert (Default):
HostnameLookups Off
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Kontext
Anweisung aktiv:
ja
5.2 Basiskonfiguration
181
Mit dieser Konfigurationsoption schalten Sie die Auflösung der IP-Adressen der
Clients in deren Hostnamen ein bzw. aus. Ist diese Option eingeschaltet (HostnameLookups On), wird bei jeder Anfrage eines Clients versucht, den Hostnamen des entfernten Clients zu bestimmen. D.h. es wird – sofern dies möglich ist – aus der
zugreifenden IP-Adresse 204.62.129.132 der Hostname www.apache.org ermittelt. Die
Standardeinstellung (HostnameLookups Off) deaktiviert diese Auflösung, um unnötigen Netzwerkverkehr zu vermeiden. Sie steigert die Antwortgeschwindigkeit auf
eingehende Anfragen der Clients, da nicht für jede Anfrage eine DNS-Abfrage gestartet wird. Sie sollten die Auflösung der IP-Adressen der zugreifenden Clients in deren
Hostnamen deaktivieren, um eine höhere Antwortgeschwindigkeit auf die Anfragen
der Clients zu erreichen. Verwenden Sie lieber im Nachhinein das Programm logresolve, welches Teil der Apache Distribution ist, um die Hostnamen der Clients sozusagen offline zu bestimmen und auszuwerten. Außerdem können Analyseprogramme
zur Auswertung der Logdateien wie analog oder webalizer inzwischen selbstständig
und ohne eine Aktion des Benutzers die IP-Adressen der Clients bei der Auswertung
in deren entsprechenden Hostnamen umwandeln.
Der dritte mögliche Parameter dieser Konfigurationsanweisung lautet double und
steht für eine doppelte Auflösung der DNS-Informationen eines Clients. In der Literatur wird diese Variante als paranoid beschrieben, da sie zunächst einen so genannten
Reverse-Lookup, d.h. die Rückauflösung einer IP-Adresse (204.62.129.132) auf einen
Hostnamen (www.apache.org) vornimmt und danach die Auflösung des gefundenen
Hostnamen auf eine IP-Adresse (Forward-Lookup) versucht. Erst wenn mindestens
eine der durch die Auflösung des Hostnamens in die entsprechende IP-Adresse mit
der ursprünglich zur Rückauflösung der IP-Adresse des Clients in den Hostnamen
übereinstimmt, wird der Hostname des Clients protokolliert. Verwenden Sie diese
Option nicht, da sich diese wirklich extrem schlecht auf die Performance des Servers
auswirkt.
Sollten Sie übrigens das Modul mod_access zur Zugriffskontrolle auf einen bestimmten Bereich des Servers verwenden, wird aus Sicherheitsgründen automatisch und
unabhängig des von Ihnen gewählten Parameters für die Option HostnameLookups
eine doppelte DNS-Abfrage (HostnameLookups double) des zugreifenden Clients vorgenommen, damit dieser eindeutig identifiziert werden kann. Das Ergebnis dieser
doppelten DNS-Abfrage steht Ihnen im Gegensatz zu dem von Ihnen gewählten
Parameters dieser Konfigurationsanweisung (on, off oder double) nicht generell zur
Verfügung. Ansonsten können Sie in CGI-Skripten und Server-Side Includes die Variable REMOTE_HOST zur Identifizierung des Hostnamens (HostnameLookups On)
oder der IP-Adresse (HostnameLookups Off) des Clients benutzen.
Die Verwendung der Konfigurationsoption HostnameLookups ist übrigens auch innerhalb diverser Kontexte möglich, so dass z.B. nur DNS-Abfragen durchgeführt werden, wenn ein Client auf bestimmte Bereiche des Servers zugreift:
<Location /intern/admin.php>
HostnameLookups On
</Location>
182
5 Konfiguration
In diesem Beispiel könnte man in dem PHP-Skript den Wert der Umgebungsvariablen REMOTE_HOST abfragen und gegebenenfalls den Zugriff auf dieses Skript verwehren.
Tipp: Sie erhalten den Hostnamen eines Clients durch Verwendung des folgenden
PHP-Codes, der je nach eingesetzter PHP-Version und -Konfiguration dessen Hostnamen durch den ersten oder den zweiten echo-Befehl zurückliefert:
<?
echo $REMOTE_HOST;
echo "\n";
echo $_SERVER['REMOTE_HOST'];
?>
ForceType
ForceType erzwingt einen bestimmten MIME-Typ.
Konfigurationsanweisung:
ForceType
Syntax:
ForceType Mime-Typ
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Kontext
Anweisung aktiv:
nein
Mit der ForceType-Anweisung können Sie für alle Dateien in einem bestimmten Verzeichnis einen gewissen MIME-Typen erzwingen. Dabei wird eine ForceType-Anweisung meist in einem <Directory>-, <Location>- oder <Files>-Container aufgerufen,
um einen vordefinierten MIME-Typen an den Client zu senden, wenn dieser eine der
im Container gespeicherten Dateien abruft. Die Anweisung überschreibt alle bereits
definierten MIME-Typen und hebt auch die Zuordnungen von MIME-Typen zu den
entsprechenden Dateiendungen auf. Ein Beispiel:
ForceType image/gif
Diese Anweisung würde alle Dateien, unabhängig von deren Endung und Inhalt, als
Bilddateien im GIF-Format kennzeichnen. In der Praxis kann die ForceType-Anweisung beispielsweise Sinn machen, wenn man in einem bekannten Verzeichnis Daten
in einem bestimmten Format vorliegen hat, deren Dateiendung jedoch nicht mit der
für diesen Dateityp sonst üblichen Endung versehen sind. Solche Daten könnten etwa
dynamisch durch ein Programm erzeugt worden sein.
5.2 Basiskonfiguration
183
IdentityCheck
Aktiviert die RFC1413-kompatible Protokollierung der Identität des entfernten
Benutzers.
Konfigurationsanweisung:
IdentityCheck
Syntax:
IdentityCheck on | off
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Kontext
Anweisung aktiv:
nein
Diese Konfigurationsoption schaltet die RFC1413-kompatible Speicherung des entfernten Benutzernamens in den Zugriffsstatistiken des Servers für jede eingehende
Verbindung ein, sofern der Client überhaupt über einen ident-Server verfügt und auf
derartige Anfragen antworten kann (und will). Ist diese Konfigurationsanweisung
eingeschaltet, sendet der Server bei jedem Zugriff eines Clients eine Anfrage an den
Ident-Server auf dem Client und fragt dort nach dem lokalen Benutzernamen des auf
den Server zugreifenden Benutzers. Heutzutage verfügt jedoch kaum noch ein Client
über einen solchen Server, so dass die Anfragen des Servers ins Leere laufen und sich
die Antwortzeiten des Servers stark verlangsamen. Zudem können Sie der durch
einen ident-Lookup (Ident-Anfrage) zurückgelieferten Identität eines entfernten Benutzers nicht trauen, da diese Informationen leicht gefälscht werden können. Außerdem
kann das Vorhandensein einer Firewall auf der Clientseite bei eingeschaltetem IdentityCheck zu erheblichen Zeitverzögerungen von bis zu 30 Sekunden führen, bevor eine
erfolgreiche Verbindung zwischen Client und Server zustande kommt. Sollte ein entfernter Client hinter einem Proxy-Server hängen, bekommen Sie den Benutzernamen
des entfernten Benutzers sowieso nicht heraus. Eventuell erhalten Sie nur die Kennung des Proxy-Prozesses auf dem Server. Verwenden Sie auf keinen Fall die durch
die Konfigurationsoption IdentityCheck eventuell zurückgelieferten Informationen
über die Identität eines entfernten Benutzers zu jeglicher Art von Authentifizierung!
Ursprünglich war das Identification Protocol (ident, vgl. RFC 1413) dazu gedacht, in
einem Kommunikationskanal, der durch beiderseits bekannte IP-Adressen und Ports
spezifiziert ist, eine eindeutige Bestimmung des auf der Gegenseite der Kommunikation die Verbindung zwischen Client und Server anfragenden Prozesses (und des
dahinterstehenden Benutzernamens) zu ermöglichen. Im Idealfall können somit zwei
Systemadministratoren den lokalen Benutzer bestimmen, der unter Umständen auf
dem entfernten System ein Problem oder einen unerlaubten Zugriff verursacht hat.
Deaktivieren Sie diese Konfigurationsanweisung, insbesondere wenn es sich bei
Ihrem Server um einen im Internet erreichbaren Server handelt!
184
5 Konfiguration
Listen
Festlegung der IP-Adresse und des Ports, auf der der Server lauscht.
Konfigurationsanweisung:
Listen
Syntax:
Listen IP[:Port]
Standardwert (Default):
Listen 80
Enthalten in Modul:
mpm_leader, mpm_threadpool,
mpm_worker, mpm_perchild, mpm_prefork
oder mpm_winnt
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Listen-Anweisung ist, im Vergleich zu vorhergehenden Versionen des Apache
nun eine vorgeschriebene Anweisung, die unbedingt in der Serverkonfiguration enthalten sein muss. Ist dies nicht der Fall, verweigert der Server den Start. Dabei gibt die
Listen-Anweisung an, auf welcher IP-Adresse und welchen Port der Server lauschen
soll. Die Angabe einer IPv6-Adresse wie fe80::a00:20ff:fea7:ccea ist, sofern IPv6 von
dem dem Server zugrundeliegenden Betriebssystem unterstützt wird, möglich, muss
allerdings in eckige Klammern gesetzt werden. Der Standardwert dieser Anweisung
sieht wie folgt aus und bindet den Apache an alle lokalen Netzwerkkarten und IPAdressen auf Port 80:
Listen 80
Ohne die Angabe einer IP-Adresse lauscht der Server unter allen möglichen IPAdressen des Servers! Die Bindung an eine bestimmte IP-Adresse (IPv4) und einen
bestimmten Port (z.B. 80) schaut folgendermaßen aus:
Listen 1.2.3.4:80
Für eine IPv6-Adresse sieht dieselbe Anweisung so aus:
Achtung
Listen [fe80::a00:20ff:fea7:ccea]:80
Die Portangabe der Listen-Anweisung überschreibt die Portangabe bei der
Direktive ServerName! Folgendes Beispiel soll diesen Sachverhalt kurz verdeutlichen:
ServerName 192.168.0.3:80
Listen 192.168.0.3:81
Interessanterweise wird der Server aufgrund der Listen-Anweisung nicht auf Port 80,
sondern auf Port 81 horchen. Soll der Server auf ausgesuchten Interfaces und eventu-
5.2 Basiskonfiguration
185
ell sogar auf verschiedenen Ports laufen, ist dies durch die Angabe mehrerer ListenAnweisungen durchaus möglich:
Listen 192.168.0.3:80
Listen 192.168.0.5:1234
Die Listen-Anweisung steht in allen Multi-Processing-Modules (MPM) wie z.B. Worker,
Perchild, Prefork oder MPM_WinNT zur Verfügung (vgl. Kapitel über Laufzeitverhalten und Funktionsweise des Apache).
LoadFile
Bindet eine externe Bibliothek oder Objektdatei in den Server ein.
Konfigurationsanweisung:
LoadFile
Syntax:
LoadFile Datei
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_so
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit Hilfe dieser Anweisung können Sie externe Bibliotheken oder Objektdateien in
den Server einbinden, die beim Start oder Neustart des Apache automatisch geladen
werden. Unter Umständen ist dieser Schritt notwendig, um externe Module oder
Erweiterungen erfolgreich zu betreiben, wobei die Anweisung als einzigen Parameter
die Angabe einer (oder mehrerer) Datei(en) erwartet, die zusätzlich geladen werden
soll(en). Ein Beispiel:
LoadFile modules/libxmlparse.so
Durch eine derartige Anweisung würde beim Start und Neustart des Servers die
Datei libxmlparse.so aus dem Unterverzeichnis modules der lokalen Apache-Installation geladen werden. Die Pfadangabe kann nicht nur in relativer Form zu dem als ServerRoot definierten Verzeichnis, sondern auch in absoluter Form erfolgen, wie folgendes Beispiel zeigt:
LoadFile /usr/local/apache2/modules/libxmlparse.so
LoadModule
LoadModule lädt ein externes Modul in den Server.
Konfigurationsanweisung:
LoadModule
Syntax:
LoadModul Modulname Datei
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_so
186
5 Konfiguration
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Wenn Sie externe Module in die Serverkonfiguration einbinden möchten, müssen Sie
die LoadModule-Anweisung nutzen. Als Parameter erwartet die Anweisung die
Angabe des internen Modulnamens sowie den absoluten oder relativen Pfad der zu
ladenden Datei, jeweils getrennt durch ein Leerzeichen (Space). Ein Beispiel:
LoadModule php4_module modules/libphp4.so
Hinweis
Diese Anweisung lädt das Modul mit dem internen Namen php4_module in den Server, welches im Unterverzeichnis modules der lokalen Apache-Installation als Datei
libphp4.so vorliegt. Bitte beachten Sie, dass der Modulname (hier: php4_module) nicht
frei wählbar und durch das jeweilige Modul fest vorgegeben ist. Konsultieren Sie im
Zweifelsfall die Dokumentation des externen Moduls, um den korrekten Modulnamen in Erfahrung zu bringen.
In früheren Versionen des Apache war die Reihenfolge der LoadModule-Anweisungen für die Aktivierung der einzelnen Module entscheidend und führte teilweise dazu, dass eine strikte Reihenfolge eingehalten werden musste, damit die
einzelnen Module ordnungsgemäß funktionierten. Der Apache 2 hingegen
steuert die Aktivierungsreihenfolge der einzelnen Module automatisch, so dass
die Reihenfolge der einzelnen LoadModule-Anweisungen innerhalb der Konfigurationsdatei httpd.conf für den erfolgreichen Betrieb des Servers irrelevant ist!
Aus diesem Grunde sind einige Anweisungen wie ClearModuleList sowie AddModule überflüssig geworden und nicht mehr im Apache 2 enthalten.
AssignUserId
AssignUserId bindet einen virtuellen Server an eine bestimmten Benutzer- bzw. Gruppenkennung.
Konfigurationsanweisung:
AssignUserId
Syntax:
AssignUserId Benutzerkennung Gruppenkennung
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mpm_perchild
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit Hilfe dieser Anweisung können Sie bei Verwendung des Multi Processing
Moduls (MPM) perchild, einen virtuellen Server an eine bestimmte Benutzer- und
Gruppenkennung binden, so dass alle Anfragen, die an den definierten virtuellen Server gehen, durch diesen Prozess verarbeitet werden.
Hinweis
5.2 Basiskonfiguration
187
Das MPM perchild funktioniert momentan noch nicht auf allen Plattformen. Die
Entwickler des Apache arbeiten jedoch mit Hochdruck daran, das Modul für
alle Plattformen zur Verfügung zu stellen, die das Laufzeitmodul generell
unterstützen. Generell eignet sich das Modul in besonderem Maße für Internet
Service Provider (ISP), da das Modul im Zusammenspiel mit der ChildPerUserId-Anweisung, die Möglichkeit bereitstellt, virtuelle Server von Kunden unter
eigenen Benutzerkennungen zu betreiben, wodurch ein erheblicher Gewinn an
Sicherheit und Stabilität erreicht wird.
Als Parameter erwartet diese Konfigurationsanweisung die Angabe einer Benutzerund Gruppenkennung, unter der der Prozess laufen soll, wobei diese vorher durch
eine ChildPerUserId-Anweisung definiert werden muss. Folgendes Beispiel dazu:
Hinweis
<VirtualHost 194.128.69.11>
ServerAdmin [email protected]
DocumentRoot /var/www/kunden/beispiel.de
ServerName www.beispiel.de
ErrorLog logs/www.beispiel.de-error_log
CustomLog logs/www.beispiel.de-access_log common
AssignUserId sebastian users
...
</VirtualHost>
Dieses Beispiel enthält aus Gründen der Übersichtlichkeit die notwendige
ChildPerUserId-Anweisung nicht und führt aufgrunddessen zu einer entsprechenden Fehlermeldung. Lesen Sie deshalb bitte auch die Hinweise zur
ChildPerUserId-Anweisung, da dort ein vollständiges Beispiel vorgestellt wird!
Hinweis
Dieses Beispiel eines IP-basierten virtuellen Servers bindet den virtuellen Server für
www.beispiel.de an den Kindprozess des Apache, der unter der Benutzerkennung
sebastian und der Gruppenkennung users läuft. Dieser Kindprozeß muss jedoch vorher durch eine ChildPerUserId-Anweisung definiert werden.
Eine relativ stabile und fortgeschrittene Alternative zur Verwendung des MPM
perchild stellt das Modul metuxmpm dar, welches ebenfalls in diesem Buch
besprochen wird.
ChildPerUserId
Weist einem virtuellen Server eine eigene Benutzer- und Gruppenkennung zu.
Konfigurationsanweisung:
ChildPerUserId
Syntax:
ChildPerUserId Benutzerkennung Gruppenkennung Kindprozessnummer
Standardwert (Default):
nicht vorhanden
188
5 Konfiguration
Enthalten in Modul:
mpm_perchild
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Diese Konfigurationsanweisung ist neu im Apache 2.x und zugleich revolutionär,
denn sie weist einem virtuellen Server eine eigene Benutzer- und Gruppenkennung
zu, wodurch ein erheblicher Sicherheits- und Stabilitätsgewinn erreicht wird. Leider
funktioniert das Modul perchild, welches die Grundlage für diese und die vorherige
Anweisung darstellt, noch nicht einwandfrei, so dass es bei der Ausführung zu Fehlermeldungen kommen kann.
Nichtsdestotrotz erwartet diese Anweisung als Parameter die Angabe einer Benutzerund Gruppenkennung sowie einer Anzahl an Kindprozessen, die unter der angegebenen Benutzer- und Gruppenkennung gestartet werden sollen. Dabei darf die
Anzahl der Kindprozesse die durch die NumServers-Anweisung festgelegte
Gesamtanzahl an Kindprozessen nicht überschreiten. Wenn Sie beispielsweise fünf
Kindprozesse erzeugen lassen, stehen Ihnen die Kindprozesse eins bis fünf zur Verfügung. Falls einem Kindprozess keine eigene Benutzer- und Gruppenkennung zugewiesen wurde, erbt dieser die durch die User- und Group-Anweisung definierte
Benutzer- und Gruppenkennung des Hauptservers. Folgendes Beispiel dazu:
User nobody
Group nogroup
ChildPerUserId sebastian user 2
NameVirtualHost *
<VirtualHost 194.128.69.11>
ServerAdmin [email protected]
DocumentRoot /var/www/kunden/beispiel.de
ServerName www.beispiel.de
ErrorLog logs/www.beispiel.de-error_log
CustomLog logs/www.beispiel.de-access_log common
AssignUserId sebastian users
</VirtualHost>
Dieses Beispiel eines IP-basierten virtuellen Servers zeigt die Verwendung der ChildPerUserId-Anweisung und sorgt dafür, dass der virtuelle Server für die Domain
www.beispiel.de unter der Benutzerkennung sebastian und der Gruppenkennung users
ausgeführt wird, wobei insgesamt zwei Kindprozesse (siehe ChildPerUserId-Anweisung) mit dieser Benutzer- und Gruppenkennung zur Verfügung stehen. Hinweis:
Verwenden Sie aus Sicherheitsgründen niemals die Benutzer- bzw. Gruppenkennung
root für einen virtuellen Server!
Auch an dieser Stelle sei nochmals auf das Modul metuxmpm als sinnvolle Alternative
zur Verwendung des MPM perchild hingewiesen.
5.2 Basiskonfiguration
189
AcceptMutex
AcceptMutex definiert eine Methode zur Synchronisierung der Kindprozesse.
Konfigurationsanweisung:
AcceptMutex
Syntax:
AcceptMutex Methode
Standardwert (Default):
AcceptMutex default
Enthalten in Modul:
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Die AcceptMutex-Anweisung definiert bei Verwendung des Multi-Processing
Modules (MPM) prefork eine Methode, die der Apache zur Synchronisation der Kindprozesse nutzen soll. In früheren Versionen des Apache konnte diese Methode einmalig bei der Kompilierung ausgewählt werden, so dass diese fest in den Server integriert war. Der Apache 2 hingegen erlaubt die Verwendung der folgenden Methoden:
default
Diese Methode ist gleichzeitig der Standardwert der AcceptMutex-Anweisung und
verwendet für das dem Server zugrundeliegende Betriebssystem optimale Verfahren
zur Synchronisation der Kindprozesse. Falls keine eventuell vorhandenen Probleme
mit der für Ihr Betriebssystem optimalen Methode bekannt sind und Sie außerdem
den expliziten Einsatz einer anderen Methode nicht wünschen, sollten Sie diese Einstellung verwenden. Ein Beispiel:
AcceptMutex default
flock
Verwendet den Systemaufruf flock(), um die durch die LockFile-Anweisung definierte
Datei vor mehrfachem Zugriff zu schützen.
fcntl
Benutzt den Systemaufruf fcntl(), um die durch die LockFile-Anweisung definierte
Datei vor mehrfachem Zugriff zu schützen.
sysvsem
Durch diese Methode werden SysV-artige Semaphoren für die Synchronisation der
Kindprozesse verwendet. Die Methode sollte nur auf dem Betriebssystem IRIX verwendet werden, da sie einige Probleme (z.B. Denial of Service-Angriffe oder unsauberes Programmende) nach sich ziehen kann.
pthread
Mit dieser Methode kommen POSIX-Threads (pthreads) bei der Synchronisation der
Kindprozesse zum Einsatz. Sie scheint besonders für das Betriebssystem Sun Solaris
geeignet zu sein.
190
5 Konfiguration
Bitte beachten Sie, dass nicht alle Methoden unter allen Betriebssystemen zur Verfügung stehen. Sollte die von Ihnen gewählte Methode unter einem Betriebssystem
nicht verfügbar sein, wird eine Nachricht in die durch die ErrorLog-Anweisung definierte Protokolldatei geschrieben und dort die für Ihr Betriebssystem möglichen
Methoden aufgelistet.
ListenBackLog
Bestimmt die maximale Größe der Warteschlange für schwebende Verbindungen.
Konfigurationsanweisung:
ListenBackLog
Syntax:
ListenBackLog Anzahl
Standardwert (Default):
ListenBackLog 511
Enthalten in Modul:
mpm_prefork, mpm_worker, mpm_perchild
und mpm_winnt
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit Hilfe dieser Konfigurationsanweisung legen Sie die maximale Größe der Warteschlange für schwebende Verbindungen fest. Normalerweise benötigt die Voreinstellung keinerlei Modifikation, da diese selbst bei mehreren Millionen Anfragen am Tag
ausreichend groß sein sollte, zumal der Standardwert von 512 auf manchen Betriebssystem (z.B. Linux) zu hoch ist und automatisch auf den maximalen Wert heruntergesetzt wird. Ein Beispiel:
ListenBackLog 256
Generell sollten Sie den Wert der ListenBackLog-Anweisung nie unterhalb von 100 setzen. Sollten Sie Opfer einer Denial of Service-Attacke werden, kann es sinnvoll sein,
den Wert der ListenBackLog-Anweisung über den Standardwert von 511 zu erhöhen.
KeepAlive
Aktiviert oder deaktiviert persistente Verbindungen.
Konfigurationsanweisung:
KeepAlive
Syntax:
KeepAlive on | off
Standardwert (Default):
KeepAlive On
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
5.2 Basiskonfiguration
191
Diese Konfigurationsanweisung aktiviert oder deaktiviert persistente Verbindungen
zum Server, d.h. über eine TCP-Verbindung können mehrere Anfragen an den Server
geschickt werden. Dadurch werden die Anfragen schneller bearbeitet und zusätzlich
Bandbreite gespart, da nicht für jede Anfrage eine neue TCP-Verbindung aufgebaut
werden muss.
Aktivieren Sie diese Anweisung immer, da Sie somit eine größere Anzahl an Anfragen in geringerer Zeit mit weniger Bandbreitenverbrauch bewältigen können! Einige
ältere (und inzwischen eigentlich nicht mehr verbreitete) Clients besitzen fehlerhafte
Implementierungen der Unterstützung von KeepAlive-Verbindungen. Für derartige
Clients lassen sich aber solche Verbindungen deaktivieren:
KeepAlive On
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
Sofern die KeepAlive-Funktionalität in der Serverkonfiguration aktiviert wird, wird
diese Funktion für alle Clients die sich mit dem Namen Mozilla/2 bzw. MSIE4.02b
melden, abgeschaltet.
KeepAliveTimeout
Definiert die Wartezeit bis zum Eintreffen einer erneuten Anfrage bei einer KeepAlive-Anfrage.
Konfigurationsanweisung:
KeepAliveTimeout
Syntax:
KeepAliveTimeout Sekunden
Standardwert (Default):
KeepAliveTimeout 15
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Wenn Sie die Anweisung KeepAlive aktiviert haben, definiert diese Option wie lange
(in Sekunden) der Server auf die nächste Anfrage eines Clients in einer persistenten
Verbindung wartet, bevor die Verbindung geschlossen wird. Werte zwischen 5 und
25 Sekunden sind für diese Option sinnvoll, auf größeren Websites sollte der Wert
etwa zwischen 5-10 liegen bzw. auf niedrig frequentierten Servern entsprechend
höher. Nachdem eine erneute Anfrage eingetroffen ist, gelten für diese Anfrage wieder die Bestimmungen der Timeout-Anweisung. Ein Beispiel:
KeepAliveTimeout 10
192
5 Konfiguration
KeepAliveRequests
Bestimmt die Anzahl der Anfragen während einer persistenten Verbindung (veraltet).
Konfigurationsanweisung:
KeepAliveRequests
Syntax:
KeepAliveRequests Anzahl
Standardwert (Default):
KeepAliveRequests 100
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Anzahl der Anfragen während einer persistenten Verbindung definiert diese
Konfigurationsoption. Der Wert 0 definiert eine unlimitierte Anzahl an Anfragen, es
wird jedoch empfohlen einen festen Wert vorzugeben, der aus Performancegründen
recht hoch liegen sollte. Beispiel:
Hinweis
KeepAliveRequests 100
Diese Anweisung steht in neueren Versionen des Apache (z.B. 2.0.48) nicht
mehr zur Verfügung und ist durch die MaxKeepAliveRequests-Anweisung
ersetzt worden, deren Syntax und Funktion jedoch identisch ist.
MaxKeepAliveRequests
Bestimmt die Anzahl der Anfragen während einer persistenten Verbindung.
Konfigurationsanweisung:
MaxKeepAliveRequests
Syntax:
MaxKeepAliveRequests Anzahl
Standardwert (Default):
MaxKeepAliveRequests 100
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
In neueren Versionen des Apache 2 ist die KeepAliveRequests-Anweisung nicht mehr
verfügbar und in MaxKeepAliveRequest umbenannt worden. Generell definiert die
Anweisung jedoch immer noch die Anzahl der Anfragen während einer persistenten
Verbindung. Der Wert 0 definiert dabei eine unlimitierte Anzahl an Anfragen, es wird
jedoch empfohlen einen festen Wert vorzugeben, der aus Performancegründen recht
hoch liegen sollte. Beispiel:
MaxKeepAliveRequests 100
5.2 Basiskonfiguration
193
Timeout
Bestimmt ein Zeitlimit in Sekunden für Clientanfragen.
Konfigurationsanweisung:
Timeout
Syntax:
Timeout Sekunden
Standardwert (Default):
Sekunden 300
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Timeout-Anweisung definiert ein Zeitlimit in Sekunden für eine Clientanfrage,
bevor die Verbindung serverseitig geschlossen wird. Das Zeitlimit gilt für die folgenden drei Fälle, wobei diese in Zukunft auch einzeln konfigurierbar sein sollen:
1. Die Gesamtzeit um eine GET-Anfrage eines Clients vollständig zu empfangen,
2. Die Zeit zwischen dem Empfang von bestimmten TCP-Paketen einer PUT- oder
POST-Anfrage,
3. Die Zeit zwischen den Bestätigungen von TCP-Paketen, die als Antwort vom Server geschickt wurden.
Sobald in einem dieser drei Fälle das angegebene Zeitlimit (Voreinstellung: 5 Minuten)
erreicht ist, wird die Verbindung serverseitig geschlossen. Die Voreinstellung von
5 Minuten stellt einen guten Wert für das Zeitlimit dar. Die Entwickler des Apache
empfehlen aus folgenden Gründen die weitere Herabsenkung des Zeitlimits nicht:
1. Langsamere Clients könnten Opfer des Zeitlimits werden und der Zugriff auf Informationen könnte Ihnen verwehrt werden.
2. Fehler im Quellcodes des Apache könnten dazu führen, dass der Zähler beim Versenden einer Serverantwort nicht auf 0 gesetzt wird, so dass das Zeitlimit weiterläuft, obwohl bereits weitere Daten zwischen Server und Client übermittelt
wurden.
Früher war das Zeitlimit sogar auf 1200 Sekunden gesetzt, 300 Sekunden sollten jedoch
bei den heute üblichen Verbindungsgeschwindigkeiten bei weitem ausreichen.
FileETag
Bestimmt das Aussehen und den Inhalt des HTTP-Headers Etag.
Konfigurationsanweisung:
FileETag
Syntax:
FileETag [ + | -] Option
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, .htaccess Kontext
Anweisung aktiv:
nein
194
5 Konfiguration
Bei jeder Antwort des Servers wird der HTTP-Header ETag gesendet, der den Entity
Tag (deutsch Wesen, Dasein) einer Datei darstellt. Dieser wird insbesondere von
Proxy-Servern verwendet, um zu entscheiden, ob sich der Inhalt einer Datei seit dem
letzten Abruf geändert hat. Ein Beispiel für einen ETag könnte etwa so aussehen:
ETag: "1d35aa-5b0-40446f80;1d35c0-946-7aa0cb40"
Dabei wird der ETag neben dem Datum der letzten Änderung, aus der Größe und
dem Inode-Wert der Datei erzeugt. Im Inode (inode = engl. information node, Informationsknoten) werden alle relevanten Informationen über eine Datei gespeichert
außer deren Name und die eigentlichen in der Datei enthaltenen Daten. Dazu gehören etwa die Dateiberechtigungen, Besitzer und Gruppe der Datei sowie die Zugriffsund Änderungszeiten. Mit der FileETag-Anweisung können Sie den Inhalt und das
Aussehen der Daten die zur Erzeugung des ETags herangezogen werden, bestimmen.
Dabei stehen Ihnen folgende Optionen zur Verfügung:
Inode: Wenn der Inode-Wert zur Bildung des ETags herangezogen werden soll,
müssen Sie diese Option angeben.
Size: Sofern die Größe berücksichtigt werden soll, müssen Sie diese Option angeben.
MTime: Wenn das Datum der letzten Änderung in die Generierung des ETags einfließen soll, müssen Sie diese Option verwenden. Die Zeit der letzten Änderung
(engl. modification time) kann auch durch Angabe des äquivalenten Parameters
LMTime (oder LastModifiedTime) erreicht werden.
All: Alle Optionen (Inode, Size und MTime) werden zur Generierung des ETagWerts benutzt.
None: Wenn Sie nicht möchten, dass ein ETag-Wert generiert wird, können Sie dies
durch Setzen der Option None erreichen.
Dabei können Sie die Optionen entweder absolut angeben oder einer vorhergehenden Definition durch Angabe eines vorangestellten Plus- oder Minuszeichen hinzufügen bzw. entfernen. Ein Beispiel:
FileETag None
<Directory /daten>
FileETag +Size +MTime
</Directory>
Die erste Anweisung deaktiviert die Generierung eines ETags. Die darauf folgende
<Directory>-Anweisung sorgt jedoch dafür, dass der ETag für das Verzeichnis /daten
mit Hilfe von Größe (+Size) und Änderungsdatum (+MTime) einer Datei erzeugt
wird.
AcceptPathInfo
Aktiviert oder deaktiviert die Akzeptierung von Pfadinformationen in URL-Adressen.
5.2 Basiskonfiguration
195
Konfigurationsanweisung:
AcceptPathInfo
Syntax:
AcceptPathInfo On | Off | Default
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, .htaccess Kontext
Anweisung aktiv:
nein
Die Anweisung bestimmt, ob Anfragen mit erweiterten Pfadangaben akzeptiert oder
zurückgewiesen werden sollen. Wenn Sie beispielsweise ein Verzeichnis namens
/daten haben, würde eine Anfrage für /daten/index.html/beispiel.pdf bzw. /daten/nichtvorhanden.html/beispiel.pdf /beispiel.pdf als erweiterte Pfadangabe interpretiert werden. Sie
können der AcceptPathInfo-Anweisung drei Parameter übergeben:
Off
Sollte in einer Anfrage eine erweitere Pfadangabe enthalten sein, wird diese mit einer
entsprechenden Fehlermeldung (»not found«, nicht gefunden) quittiert.
On
Wenn eine Anfrage eine erweiterte Pfadangabe enthält, wird versucht, das Ziel der
erweiterten Pfadangabe an den nachfragenden Client zu liefern. Der Client erhält eine
Fehlermeldung, wenn das Ziel seiner Anfrage nicht vorhanden ist.
Default
Die Behandlung der erweiterten Pfadinformationen bleibt dem jeweilig im Kontext
gültigen Handler überlassen.
Um beispielsweise Server-Side Includes für eine bestimmte Datei zu nutzen, die
erweiterte Pfadinformation interpretiert und eventuell sogar durch ein externes
Skript jagt, könnten Sie folgende Anweisungen definieren:
<Files "dynamische_pfade.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>
In der Serverkonfiguration ist es normalerweise nicht möglich, erweiterte Pfadinformationen zu interpretieren, da diese ausgeschaltet sind. Mit dieser Anweisung können Sie für eine Datei namens dynamische_pfade.shtml die Verarbeitung als Server-Side
Include aktivieren und in diesem Skript erweiterte Pfadinformationen auswerten. Die
Anweisung wurde hinzugefügt, da die Behandlung von PATH_INFO (hinter dem tatsächlichen Dateinamen angefügte Pfadangaben) für einige Module geändert wurde.
Module, die bisher als Handler implementiert waren, jetzt aber als Filter implementiert sind, akzeptieren möglicherweise keine Requests mit PATH_INFO mehr. Filter
wie INCLUDES sind durch den Core-Handler implementiert und weisen deshalb
Requests mit PATH_INFO ab. Mit dieser Anweisung können Sie also den Core-Hand-
196
5 Konfiguration
ler zwingen, Requests mit PATH_INFO zu akzeptieren, und dadurch die Fähigkeit
wiederherstellen, PATH_INFO in Server-Side Includes zu benutzen.
AllowEncodedSlashes
Erlaubt oder verbietet das Vorhandensein von kodierten Pfadtrennzeichen in URLAdressen.
Konfigurationsanweisung:
AllowEncodedSlashes
Syntax:
AllowEncodedSlashes On | Off
Standardwert (Default):
AllowEncodedSlashes Off
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host Kontext
Anweisung aktiv:
nein
Wenn die URL-Adresse einer Clientanfrage ein kodiertes Pfadtrennzeichen (z.B. %2F
für / und %5C für \) enthält, wird diese Anfrage normalerweise mit einer Fehlermeldung (404 Not found, nicht gefunden) quittiert. Dieses Verhalten kann jedoch, gerade
bei Verwendung der AcceptPathInfo-Anweisung, unter Umständen nicht erwünscht
sein. Daher können Sie mit Hilfe der AllowEncodedSlashes-Anweisung das Vorhandensein von kodierten Pfadtrennzeichen in URL-Adressen erlauben:
AllowEncodedSlashes On
Aus Sicherheitsgründen sollten Sie in der Regel jedoch das Vorhandensein von
kodierten Pfadtrennzeichen in URL-Adressen deaktivieren:
Hinweis
AllowEncodedSlashes Off
Sofern Sie kodierte Pfadtrennzeichen (z.B. %2F für / unter Unix/Linux bzw.
%5C für \ unter Windows/Dos) in URL-Adressen erlauben, werden diese nicht
automatisch dekodiert, d.h. sie verbleiben unverändert in der ansonsten dekodierten URL-Adresse.
ScriptInterpreterSource
Definiert die Quelle zur Ausführung von CGI-Skripten unter Windows.
Konfigurationsanweisung:
ScriptInterpreterSource
Syntax:
ScriptInterpreterSource script | registry| registry-script
Standardwert (Default):
ScriptInterpreterSource script
Enthalten in Modul:
mod_core (Kernmodul)
5.2 Basiskonfiguration
197
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, .htaccess Kontext
Anweisung aktiv:
nein
Unter Windows ist es möglich, die Quelle zu bestimmen, die den Interpreter für CGISkripte festlegt. Entweder muss der Interpreter, wie es auch unter Unix/Linux üblich
ist in der ersten Zeile des Skriptes definiert werden (Standardeinstellung) oder der
Apache kann die Windows-Registry abfragen, welches Programm für die Ausführung von CGI-Skripten (Dateiendung: .pl) vorgesehen ist. Sofern das Skript den Speicherort des Interpreters definiert, muss die erste Zeile eines Skriptes immer so aussehen:
Hinweis
#!C:\Perl\Perl.exe
Den Pfad müssen Sie gegebenenfalls anpassen.
Wenn die Windows-Registry den Speicherort des Interpreters eines CGI-Skriptes
definieren soll, verwenden Sie diese Anweisung:
ScriptInterpreterSource registry
Sie erhalten eine Fehlermeldung, wenn in der Registry dem Dateityp mit der Endung
.pl kein Programm zugeordnet ist. Bei der Ausführung eines CGI-Skriptes würde bei
oben genannter Konfiguration folgender Fehler erscheinen, wenn in der Registry
Dateien mit der Endung .pl kein Programm zugeordnet sein sollte:
Hinweis
D:/Apache/Apache2/cgi-bin/hello_world.pl is not executable; ensure interpreted
scripts have "#!" first line
Bitte beachten Sie, dass der Apache bei Verwendung der Option registry versucht, jede Datei innerhalb des durch die ScriptAlias-Anweisung als CGI-BIN
definierten Verzeichnisses, auszuführen. Aufgrunddessen kann es unter
Umständen zur unerwünschten Ausführung von externen Programmen kommen, die gegebenenfalls den gesamten Server zum Absturz bringen können, da
der Apache innerhalb des CGI-BIN-Verzeichnisses eine Datei aufgerufen hat,
für deren Öffnung eigentlich ein anderes Programm (z.B. Microsoft Internet
Explorer für .html-Dateien) vorgesehen ist. Speichern Sie deshalb keine Dateien
(z.B. Bilder) in dem als CGI-BIN definierten Verzeichnis, denen in der Registry
nicht ein entsprechender Interpreter zugeordnet ist.
Um das genannte Verhalten zu entschärfen, existiert in neueren Versionen des Apache (z.B. 2.0.48) für die ScriptInterpreterSource-Anweisung eine neue Option namens
Registry-Strict, die den Unterschlüssel Shell\ExecCGI\Command zur Ausführung von
198
5 Konfiguration
CGI-Skripten verwendet. Dieser Unterschlüssel muss manuell in der Registry mit
Hilfe des Programms regedit.exe angelegt werden und soll die versehentliche Ausführung von externen Programmen verhindern.
CGIMapExtension
Definiert die Quelle zur Ausführung von CGI-Skripten unter Netware.
Konfigurationsanweisung:
CGIMapExtension
Syntax:
CGIMapExtension CGI-Pfad Dateiendung
Standardwert (Default):
CGIMapExtension none
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung ist nur unter Netware verfügbar und definiert die Quelle (Interpreter) zur Ausführung von CGI-Skripten. Als Parameter erwartet sie die Angabe eines
CGI-Pfades sowie einer Dateiendung, die mit dem Interpreter assoziiert werden soll.
Ein Beispiel:
CGIMapExtension sys:\beispiel.nlm .cgi
In diesem Beispiel werden alle CGI-Skripte mit der Endung .cgi an den Interpreter
Beispiel weitergereicht.
AddDefaultCharset
Definiert einen Standardzeichensatz.
Konfigurationsanweisung:
AddDefaultCharset
Syntax:
AddDefaultCharset On | Off | Zeichensatz
Standardwert (Default):
AddDefaultCharset ISO-8859-1
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess Container
Anweisung aktiv:
ja
Die AddDefaultCharset-Anweisung definiert einen Zeichensatz, der an einen Client
gesendet werden soll, sofern eine übermittelte Information keinerlei Angabe über den
verwendeten Zeichensatz enthält. Die Standardeinstellung definiert den Zeichensatz
ISO-8859-1, der auch als Latin1 bekannt ist und alle Schriftzeichen der westeuropäischen und amerikanischen Sprachen enthält, außer einigen Sonderzeichen wie z.B.
5.2 Basiskonfiguration
199
die in Deutschland üblichen Anführungszeichen unten. Die Anweisung erwartet
einen der drei folgenden Parameter:
On
Mit diesem Parameter wird automatisch ein Zeichensatz an den Client gesendet, falls
eine Information keine explizite Angabe eines Zeichensatzes enthält. Beispiel:
AddDefaultCharset On
Der Server benutzt in diesem Fall den Zeichensatz ISO-8859-1, d.h. Latin1.
Off
Sofern Sie nicht möchten, dass automatisch ein Zeichensatz an den Client gesendet
wird, wenn dieser Informationen abruft, die keinerlei Angaben über den verwendeten Zeichensatz enthalten, können Sie diese Funktionalität durch den Parameter Off
abschalten. Ein Beispiel:
AddDefaultCharset Off
Der Server sendet nicht mehr automatisch die Angabe über den verwendeten Zeichensatz.
Zeichensatz
Sie können auch explizit einen Zeichensatz angeben, der an den Client gesendet wird,
falls ein Dokument keine Angabe über den verwendeten Zeichensatz enthält. Ein Beispiel:
AddDefaultCharset ISO-8859-1
In diesem Fall wird standardmäßig ISO-8859-1 (Latin 1) verwendet. Eine Liste der
offiziell definierten Zeichensätze finden Sie unter http://www.iana.org/assignments/
character-sets.
ContentDigest
Schaltet die Erzeugung des Content-MD5-Headers ein.
Konfigurationsanweisung:
ContentDigest
Syntax:
ContentDigest On | Off
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Container
Anweisung aktiv:
nein
200
5 Konfiguration
Mit dieser Anweisung können Sie die Generierung des so genannten Content-MD5Headers ein- oder ausschalten. Ein Beispiel:
ContentDigest On
Diese Anweisung erzeugt für Informationen, die durch das Kernmodul des Apache
an den Client gesendet wurden, eine Art digitalen Fingerabdruck und sendet diesen
Wert in der Antwort des Servers auf eine eingehende Anfrage eines Clients mit. Dieses digitale Siegel soll die Echtheit der durch den Server übermittelten Antwort
garantieren, wobei der Schutz nicht sonderlich hoch ist, da ein Angreifer einen eigenen digitalen Stempel erzeugen und an den Client senden könnte. Außerdem unterstützen die wenigsten Clients diesen Header. Zusätzlich muss dieser Wert für jede
Anfrage neu erzeugt werden, so dass mit erheblichen Performanceeinbußen zu rechnen ist.
ContentDigest Off
Schalten Sie deshalb die Generierung von digitalen Fingerabdrücken für die vom Server übermittelten Daten aus. Hinweis: Der Content-MD5-Header wird nur für solche
Dateien an den Client übermittelt, die vom Kernmodul (mod_core) des Apache
bedient worden sind. Für Inhalte, die durch externe Module (z.B. mod_php) erzeugt
werden, wird dieser Header nicht erzeugt.
DefaultType
Definiert einen standardmäßigen MIME-Typen für alle Dateien, sofern dieser nicht
automatisch bestimmt werden konnte.
Konfigurationsanweisung:
DefaultType
Syntax:
DefaultType Mime-Typ
Standardwert (Default):
DefaultType text/plain
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Container
Anweisung aktiv:
ja
Unter Umständen kann es passieren, dass durch einen Client ein Dokument angefordert wird, dessen MIME-Typ nicht eindeutig bestimmt werden kann, da der Datei
z.B. die entsprechende Endung fehlt. Dennoch muss der Server in diesem Fall einen
Datentyp übermitteln, der durch die DefaultType-Anweisung definiert wird. Ein Beispiel:
DefaultType image/gif
5.2 Basiskonfiguration
201
Innerhalb eines <Directory>-Kontextes könnte diese Anweisung dazu genutzt werden, den korrekten MIME-Typen zu übermitteln, wenn in einem Verzeichnis Bilddateien ohne Dateiendung .gif vorliegen. Hinweis: Im Gegensatz zur ForceTypeAnweisung überschreibt diese Anweisung keine bestehenden Zuordnungen von
Dateiendung zu MIME-Typen und spezifiziert lediglich einen Standarddateitypen.
EnableMMap
Bestimmt, ob der Apache während der Übertragung von Informationen an den Client
Speicherabbilder von lokalen Dateien erzeugen soll.
Konfigurationsanweisung:
EnableMMap
Syntax:
EnableMMap On | Off
Standardwert (Default):
# EnableMMAP off
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess Container
Anweisung aktiv:
nein (auskommentiert)
Diese Anweisung schaltet die Verwendung von Speicherabbilden (Fachbegriff:
Memory Mapping) beim Lesen einer lokalen Datei ein oder aus, wenn Informationen
zwischen dem Client und dem Server ausgetauscht werden. Standardmäßig wird die
Abbildung einer Datei erzeugt, wenn die Bearbeitung einer Anfrage den Zugriff auf
den Inhalt einer Datei erfordert. Dies ist beispielsweise im Falle einer Server-Side
Include-Datei notwendig und nur möglich, wenn das dem Server zugrundeliegende
Betriebssystem solche Abbilder erlaubt. Auf manchen Systemen führt diese Anweisung zur Steigerung der Performance des Apache. Sofern Sie aber eine Multiprozessor-Maschine oder ein via NFS gemountetes DocumentRoot-Verzeichnis benutzen,
sollten Sie die Erzeugung von Speicherabbildungen unbedingt ausschalten:
EnableMMap Off
EnableSendfile
Schaltet die Verwendung des Systemaufrufs sendfile() ein oder aus.
Konfigurationsanweisung:
EnableSendfile
Syntax:
EnableSendfile On | Off
Standardwert (Default):
# EnableSendfile On
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess Container
Anweisung aktiv:
nein (auskommentiert)
202
5 Konfiguration
Der Systemaufruf sendfile() ist eigentlich in allen modernen Unix- bzw. Linux-Varianten enthalten und wurde eingeführt, um einen schnelleren Datenaustausch zwischen Festplatte und TCP-Socket sowie zwischen zwei Dateideskriptoren mit möglichst geringer Prozessorbelastung zu ermöglichen. Dadurch ist der Apache in der
Lage, solche Anfragen, bei denen das vorherige Auslesen und Verarbeiten lokaler
Dateien durch den Server nicht notwendig ist (z.B. statische .html-Dateien), direkt an
den Client zu senden, ohne dabei jemals die angeforderte Datei selbst lesen zu müssen. Dadurch wird in der Regel ein erheblicher Performancegewinn erreicht, wobei es
unter bestimmten Umständen (u.a. Verwendung von IPv6 unter Linux oder via
NFS/SMB eingebundenes Dokumentenverzeichnis) zu Problemen kommen kann. In
diesem Fall sollten Sie die Verwendung des Systemaufrufs sendfile() deaktivieren:
EnableSendfile Off
Auf den meisten Plattformen sollte der Systemaufruf sendfile() jedoch keine Probleme bereiten und kann ruhigen Gewissens benutzt werden:
Hinweis
EnableSendfile On
Im Juni 2003 berichtete ein Administrator auf der offiziellen Apache-Mailingliste (vgl. Anhang), dass beim Download einer sehr großen Datei (>=500 MB)
von seinem Sun Solaris 9-System (Apache 2.0.46, Netra T1 200/UltraSPARCIIe) die Prozessorlast auf 100% stieg und die Systemperformance stark beeinträchtigt wurde. Die Lösung des beschriebenen Problems war schließlich die
Deaktivierung der Verwendung des Systemaufrufs sendfile(). Sollten Sie also
auf der von Ihnen verwendeten Plattform starke Performanceprobleme mit
dem Apache erfahren, könnte die (De-) Aktivierung des Systemaufrufs sendfile() die passende Lösung sein.
IfDefine
Ermöglicht die Verwendung konditioneller Konfigurationsanweisungen.
Konfigurationsanweisung:
IfDefine
Syntax:
<IfDefine [!]Parametername>...</IfDefine>
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Container
Anweisung aktiv:
nein
Der <IfDefine>-Container definiert einen konditionellen Konfigurationsabschnitt
innerhalb der zentralen Konfigurationsdatei httpd.conf des Apache. Dabei werden die
innerhalb des Containers stehenden Direktiven nur ausgeführt, wenn ein angegebener Parameter gesetzt ist und dieser dadurch den Wert wahr (true) erhält. Sofern der
5.2 Basiskonfiguration
203
angegebene Parameter nicht vorhanden ist bzw. den Wert unwahr (false) hat, werden
die innerhalb des Containers stehenden Anweisungen ignoriert. Der Testparameter
kann dabei in zwei Varianten angegeben werden:
Parameter
Sofern der angegebene Parameter definiert ist, werden die innerhalb des <IfDefine>Containers stehenden Anweisungen ausgeführt.
!Parameter
Nur wenn der angegebene Parameter nicht definiert ist, werden die innerhalb des
<IfDefine>-Containers stehenden Anweisungen ausgeführt.
Sie können einen solchen Testparameter durch Übergabe an die eigentliche Programmdatei httpd beim Start des Apache definieren, indem Sie die Kommandozeilenoption -D gefolgt vom Parameter aufrufen. Ein Beispiel:
# /usr/local/apache2/bin/httpd -DProxy
Diese Anweisung startet den Apache-Server und übergibt durch die Option -D den
Testparameter Proxy, auf den innerhalb der Konfigurationsdatei des Apache direkt
Bezug genommen werden kann:
<IfDefine Proxy>
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>
Hinweis
Sofern der Parameter Proxy beim Start des Apache definiert wurde, werden die innerhalb des <IfDefine>-Containers angegebenen Anweisungen ausgeführt, andernfalls
nicht. Der Sinn dieser Anweisung liegt darin, verschiedene Konfigurationsszenarien
(Produktivsystem, Entwicklungssystem etc.) zu definieren, die je nach Übergabe
eines Parameters in Kraft treten.
Zwischen der Kommandozeilenoption -D und dem eigentlichen Testparameter
darf kein Leerzeichen stehen (z.B. -DTestparameter).
IfModule
Ermöglicht die Verwendung konditioneller Konfigurationsanweisungen in Abhängigkeit von einem vorhandenen Modul.
Konfigurationsanweisung:
IfModule
Syntax:
<IfModule [!]Modulname>...</IfModule>
Standardwert (Default):
<IfModule !mpm_winnt.c> (mehrfach
vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
204
5 Konfiguration
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Container
Anweisung aktiv:
Ja
Der <IfModul>-Container ist funktional und syntaktisch mit der bereits vorgestellten
<IfDefine>-Anweisung identisch, allerdings definiert diese einen konditionellen Konfigurationsabschnitt innerhalb der zentralen Konfigurationsdatei httpd.conf des Apache, der sich nur auf die An- oder Abwesenheit eines bestimmten Moduls bezieht.
Dabei werden die innerhalb des Containers stehenden Direktiven nur ausgeführt,
wenn ein angegebenes Modul vorhanden ist und der Test dadurch den Wert wahr
(true) erhält. Sofern das angegebene Modul nicht vorhanden ist, erhält der Test den
Wert unwahr (false) und die innerhalb des Containers stehenden Anweisungen werden ignoriert. Der Testname kann dabei in zwei Varianten angegeben werden:
Modulname.c
Sofern das angegebene Modul vorhanden ist, werden die innerhalb des <IfModul>Containers stehenden Anweisungen ausgeführt. Hinweis: Als Modulname muss hier
der vollständige Dateiname eines Moduls (inklusive Dateiendung) angegeben werden!
!Modulname.c
Nur wenn das angegebene Modul nicht vorhanden ist, werden die innerhalb des
<IfModul>-Containers stehenden Anweisungen ausgeführt. Hinweis: Als Modulname muss hier ebenfalls der vollständige Dateiname eines Moduls (inklusive Dateiendung) angegeben werden! Ein Beispiel:
<IfModule prefork.c>
StartServers
5
MinSpareServers
5
MaxSpareServers
10
MaxClients
150
MaxRequestsPerChild 0
</IfModule>
Nur wenn der Apache mit dem durch das Multi-Processing-Module Prefork bereitgestelltem Laufzeitverhalten übersetzt worden ist, kommen die innerhalb des <IfModule>-Containers ausgeführten Anweisungen zum Tragen, ansonsten nicht.
5.2.3
Datei- und Verzeichnisstandorte
CoreDumpDirectory
Definition eines Verzeichnisses zum Schreiben von Programmabbildern im Falle
eines gravierenden Fehlverhaltens des Servers.
5.2 Basiskonfiguration
205
Konfigurationsanweisung:
CoreDumpDirectory
Syntax:
CoreDumpDirectory Verzeichnis
Standardwert (Default):
nicht verfügbar (ServerRoot)
Verfügbar in Modul:
mpm_leader, mpm_threadpool,
mpm_worker, mpm_perchild und
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
Nein
Kommt es während der Ausführung des Apache-Servers zu einem gravierenden
Problem, beispielsweise wenn ein Apache-Prozess versucht, in den Speicherbereich
eines anderen Prozesses zu schreiben, dann wechselt der Server in das durch diese
Konfigurationsanweisung angegebene Verzeichnis und versucht dort, eine so
genannte Core-Datei zu schreiben, bevor das Betriebssystem den fehlgeleiteten Prozess stoppt. Dabei wird ein Abbild des fehlerhaften Programms in eine binäre Datei
namens core geschrieben, welche später dazu genutzt werden kann, den Grund für
dieses Fehlverhalten herauszufinden. Falls es zu einem schwerwiegenden Fehlverhalten des Servers kommt, sollten Sie die verschiedenen Logdateien des Servers untersuchen, da diese oft wichtige Informationen über mögliche Ursachen enthalten.
Die Anweisung CoreDumpDirectory ist standardmäßig nicht aktiv, verweist aber dennoch auf das Verzeichnis, welches durch die Option ServerRoot gesetzt worden ist. Da
das als ServerRoot gesetzte Verzeichnis korrekterweise nicht dem Benutzer gehört, der
den Apache ausführt, kann das Core-Dump im Falle eines Falles gar nicht geschrieben werden, da der Apache-Benutzer nicht die nötigen Rechte besitzt, um in das Verzeichnis zu schreiben. Die Aktivierung dieser Konfigurationsoption durch Angabe
eines alternativen, auch für den Apache-Benutzer beschreibbaren Verzeichnisses ist
gerade für den Fall von Performance- und Stabilitätsproblemen sehr ratsam.
Entweder Sie erstellen dazu ein völlig neues Verzeichnis oder Sie geben ein bereits
bestehendes Verzeichnis an, in welches auch der Benutzer, der den Apache ausführt,
schreiben darf (z.B. /tmp). Wenn Sie das Verzeichnis /tmp benutzen möchten, so sieht
die entsprechende Anweisung wie folgt aus:
Hinweis
CoreDumpDirectory "/tmp"
Die Verwendung des Verzeichnisses /tmp wird aus Sicherheitsgründen nicht
empfohlen, da dort jeder Benutzer per Definition Schreib- und Lesezugriff
besitzt.
Falls Sie ein eigenes Verzeichnis für das Schreiben von Core-Dumps erstellen möchten, so erzeugt der folgende Befehl ein separates Verzeichnis unterhalb Ihrer ApacheInstallation, sofern diese nach /usr/local/apache2 erfolgt ist:
# mkdir /usr/local/apache2/temp
206
5 Konfiguration
Geben Sie dieses Verzeichnis an den Benutzer ab, der den Apache ausführt:
Hinweis
# chown wwwrun.aprun /usr/local/apache2/temp
Wahrscheinlich existiert dieser Benutzer/diese Gruppe auf dem von Ihnen verwendeten System nicht, so dass Sie den Befehl entsprechend ändern müssen.
Des weiteren kann es auf manchen Systemen gegebenenfalls notwendig sein,
durch Ausführung des Befehls ulimit die Erzeugung von Core-Dumps (Speicherabbilden) überhaupt zu ermöglichen. Schreiben Sie in einem solchen Fall
einfach einen entsprechenden Aufruf in die Startdatei des Apache (z.B.
/usr/local/apache2/bin/apachectl).
Geben Sie jetzt das neu erstellte Verzeichnis in der Konfigurationsdatei des Apache
an und starten Sie den Server neu:
CoreDumpDirectory "temp/"
Die Angabe des Verzeichnisses erfolgt hier in relativer Schreibweise, d.h. das als CoreDumpDirectory angegebene Verzeichnis bezieht sich auf das als ServerRoot gesetzte
Verzeichnis und verweist in diesem Fall auf das Verzeichnis /usr/local/apache2/temp.
Selbstverständlich ist auch die absolute Angabe eines Verzeichnisses möglich:
CoreDumpDirectory "/usr/local/apache2/temp"
Der Server ist nun in der Lage, Core-Dumps zu schreiben, da er auch Schreibrechte
für das als CoreDumpDirectory vorgesehene Verzeichnis besitzt.
Bitte beachten Sie, dass die Anweisung CoreDumpDirectory nicht auf den OS/2-,
BeOS- und Netware- Plattformen verfügbar ist.
DocumentRoot
Angabe eines Basisverzeichnisses, welches die im Internet zu veröffentlichenden
Informationen enthält.
Konfigurationsanweisung:
DocumentRoot
Syntax:
DocumentRoot Verzeichnis
Standardwert (Default):
/usr/local/apache2/htdocs
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
Ja
Durch die Konfigurationsanweisung DocumentRoot lässt sich ein Verzeichnis bestimmen, welches die im Internet zu veröffentlichenden Informationen (z.B. HTMLDateien, Bilder, Grafiken, Texte, Videos, PHP-Skripte etc.) enthält. Dieses Dokumentenverzeichnis kann sowohl innerhalb als auch außerhalb des als ServerRoot angegebenen Verzeichnisses liegen. Der Standardwert dieser Option entspricht dem bei der
5.2 Basiskonfiguration
207
Installation gewählten Wert, welcher sich entweder durch die direkte Übergabe der
Anweisung an das configure-Skript (--htdocsdir) oder durch Nutzung eines vordefinierten Installationslayouts (--enable-layout) setzen lässt. Dabei schlagen diese vordefinierten Layouts eines der folgenden Verzeichnisse als Dokumentenverzeichnis (DocumentRoot) vor:
/usr/local/apache2/htdocs (klassisches Apache-Installationslayout)
/usr/local/share/htdocs (GNU-Standardinstallationspfad)
/Local/Library/WebServer/Documents (Installationslayout des Mac OS X Servers,
Rhapsody)
/usr/Documents (benutzt von Darwin/Mac OS)
/var/www/html (Pfad für Red Hat Linux 7.x)
/opt/apache/share/htdocs (zugeschnitten für das /opt-Dateisystem, in der Praxis eher
selten genutzt)
/boot/home/apache/htdocs (Dokumentenverzeichnis des BeOS-Betriebssystems)
/usr/local/httpd/htdocs (Standardinstallationsverzeichnis der SuSE Distribution)
/var/www/htdocs (genutzt durch BSD/OS, wie z.B. OpenBSD)
/var/apache/htdocs (verwendet von Sun Solaris 8)
/usr/share/apache2/default-site/htdocs (Debian)
In der Praxis sieht eine gültige Angabe der Konfigurationsoption DocumentRoot
gemäß meiner Installation nach /usr/local/apache2 wie folgt aus:
DocumentRoot /usr/local/apache2/htdocs
Auf einem mir ebenfalls vorliegenden SuSE-Linux-System sieht diese Anweisung wie
folgt aus:
DocumentRoot /usr/local/httpd/htdocs
Wenn Sie ein Verzeichnis als DocumentRoot gewählt haben, welches physikalisch
nicht existiert, gibt der Apache eine Warnmeldung beim Start aus:
Warning: DocumentRoot [/var/web2] does not exist
Der Server startet trotzdem, beim Zugriff auf den Server erhält der Client jedoch eine
Fehlermeldung, dass das Hauptverzeichnis (»/«) nicht gefunden werden konnte.
Hinweis: Damit ist natürlich nicht das Wurzelverzeichnis des Dateisystems, sondern
das als DocumentRoot definierte Verzeichnis gemeint!
LockFile
Speicherort der serialization lock-Datei.
208
5 Konfiguration
Konfigurationsanweisung:
LockFile
Syntax:
LockFile Dateiname
Standardwert (Default):
#LockFile logs/accept.lock
Verfügbar in Modul:
mpm_threadpool, mpm_leader,
mpm_prefork, mpm_perchild, mpm_worker
Kontext:
Server-Kontext
Anweisung aktiv:
nein (auskommentiert)
Falls Sie den Apache mit den Optionen USE_FCNTL_SERIALIZED_ACCEPT bzw.
USE_FLOCK_SERIALIZED_ACCEPT übersetzt haben, wird ein so genanntes LockFile
benötigt. Sie können mit dieser Option den Dateinamen für das LockFile setzen, die
Prozess-ID (PID) des Apache wird der Datei automatisch angehängt. Generell brauchen Sie sich um die Verwendung der Option LockFile keinerlei Gedanken zu machen,
es sei denn, dass Sie das Verzeichnis logs, in dem die LockDatei standardmäßig gespeichert wird, per NFS (Network File System) eingebunden haben: In diesem Fall müssen Sie die Direktive LockFile unbedingt auf einen lokalen Dateinamen setzen, denn
das Locking via NFS funktioniert nicht ordnungsgemäß und kann zum Absturz des
Apache führen. Wenn Sie beispielsweise das LockFile im Verzeichnis /usr/local/
apache2 speichern möchten, würde die Anweisung wie folgt aussehen:
Hinweis
LockFile /usr/local/apache2/accept.lock
Sie sollten es aus Sicherheits- und Performancegründen vermeiden, die LockDatei in einem für jeden Benutzer beschreibbaren Verzeichnis (z.B. /tmp) anlegen zu lassen, da in einem solchen Fall ein lokaler Benutzer durch Anlegen
einer gleichnamigen Datei den Start des Servers erfolgreich unterbinden
könnte.
PidFile
Festlegung einer Datei zur Speicherung der Prozess-ID des Apache.
Konfigurationsanweisung:
PidFile
Syntax:
PidFile Dateiname
Standardwert (Default):
PidFile logs/httpd.pid
Verfügbar in Modul:
mpm_leader, mpm_threadpool,
mpm_worker, mpm_perchild und
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
ja
5.2 Basiskonfiguration
209
Der Apache speichert, ebenso wie viele andere als so genannte Daemons unter Unix
bzw. Linux laufende Programme, nach dem Start seine eigene Prozess-ID (PID) in
einer separaten Datei ab, damit der Administrator dem Server anhand dieser Identifikationsnummer Signale schicken kann. Diese Signale können diverse Aktionen auslösen, beispielsweise lässt sich der Server sofort stoppen oder zur erneuten Einlesung
seiner Konfigurationsdateien zwingen.
Die Option PidFile erwartet die Angabe einer Datei, in der diese Prozess-ID gespeichert werden soll. Enthält diese Datei keinen führenden Forwardslash (»/«), so wird
die Angabe relativ zu dem als ServerRoot definierten Basisinstallationsverzeichnis des
Apache verstanden. Ein Beispiel:
PidFile logs/httpd.pid
Da diese Anweisung keinen Slash am Anfang der Datei- bzw. Verzeichnisangabe enthält, wird davon ausgegangen, dass es sich um ein Verzeichnis unterhalb des als ServerRoot angegebenen Verzeichnisses handelt, die Verzeichnisangaben werden also
relativ interpretiert. Wurde der Apache beispielsweise nach /usr/local/apache2 installiert, so wird die Datei mit der Prozess-ID dementsprechend in die Datei
/usr/local/apache2/logs/httpd.pid geschrieben. Die Angabe eines absoluten Pfads ist
natürlich ohne Probleme möglich, wie folgendes Beispiel zeigt:
PidFile /var/run/httpd.pid
Hinweis
Die Datei mit der Nummer des Prozesses wird durch den als root-Benutzer laufenden
Prozess des Apache erzeugt, sobald der Server gestartet wird. Diese Konfigurationsanweisung hat auf einem Windows-System keinerlei Wirkung. Weitere Informationen über die Verwendung der Prozess-ID des Servers zur Steuerung und Kontrolle
des Apache erhalten Sie im Laufe dieses Buches, wenn die Funktionsweise und das
Laufzeitverhalten des Apache erklärt wird.
Auch bei dieser Anweisung sollten Sie es aus Sicherheits- und Performancegründen vermeiden, die Datei mit der Prozess-ID in einem für jeden Benutzer
beschreibbaren Verzeichnis (z.B. /tmp) anlegen zu lassen, da in einem solchen
Fall ein lokaler Benutzer gegebenenfalls durch Anlegen einer gleichnamigen
Datei den Start des Servers erfolgreich unterbinden könnte.
ScoreBoardFile
Datei zur Speicherung von serverinternen Prozessinformationen.
Konfigurationsanweisung:
ScoreBoardFile
Syntax:
ScoreBoardFile Dateiname
Standardwert (Default):
#ScoreBoardFile logs/apache_runtime_status
Verfügbar in Modul:
Mpm_prefork, mpm_perchild, mpm_worker
Kontext:
Server-Kontext
Anweisung aktiv:
Nein (auskommentiert)
210
5 Konfiguration
Der Apache benutzt ein so genanntes ScoreBoard für die Kommunikation zwischen
dem Haupt- und den Kindprozessen. Auf einigen Systemen kann es nötig sein, eine
Datei für diese Kommunikation zu bestimmen. Falls die Konfigurationsoption ScoreBoardFile nicht gesetzt worden ist, versucht der Apache zunächst, das ScoreBoard
vollständig im Speicher (anonymous shared memory) zu erzeugen. Schlägt dies fehl,
wird versucht, die Datei auf der lokalen Festplatte zu erzeugen. Wenn kein System Vkompatibles System zur Verfügung steht, wird das ScoreBoard automatisch in einer
normalen Datei gespeichert, deren Name die ScoreBoardFile-Anweisung bestimmt.
Wird die Anweisung ScoreBoardFile gesetzt, generiert der Apache die Datei im lokalen
Dateisystem und bietet somit Drittanbietern die Möglichkeit, auf diese zuzugreifen:
ScoreBoardFile logs/apache_runtime_status
Zur Verbesserung der Performance sollten Sie, sofern die Verwendung eines ScoreBoards in Dateiform notwendig ist, dieses nicht auf der lokalen Festplatte, sondern
auf einer Ramdisk speichern.
ServerRoot
Angabe des Hauptinstallationsverzeichnisses des Apache.
Konfigurationsanweisung:
ServerRoot
Syntax:
ServerRoot Verzeichnis
Standardwert (Default):
/usr/local/apache2
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Konfigurationsanweisung ServerRoot gibt das Hauptinstallationsverzeichnis des
Apache an. Bei der Installation des Apache wird automatisch die Anweisung ServerRoot gemäß dem gewählten Installationsverzeichnis angepasst, welches bei der Installation anhand des Parameters --prefix oder --enable-layout angegeben werden kann.
Eine manuelle Änderung sollte daher im Regelfall nicht mehr nötig sein. Unterhalb
des Hauptverzeichnisses des Apache werden meist die Logfiles, Module, Konfigurationsdateien und Webseiten, die der Server bereitstellt, gespeichert. Für das von mir
gewählte Installationslayout namens Apache sieht das Hauptverzeichnis der ApacheInstallation wie folgt aus:
/usr/local/apache2:
bin
Hier befinden sich ausführbare Programme wie htpasswd, rotatelogs etc. sowie
das eigentliche Apache-Programm.
build
In diesem Verzeichnis werden einige Skripte und Regeln gespeichert, die während
der Installation des Servers genutzt worden sind. So gibt es beispielsweise ein
5.2 Basiskonfiguration
211
Skript zum Kopieren der DSO-Module, da an dieser Stelle die Entwickler des Apache aus verschiedenen Gründen Libtool nicht benutzen (möchten).
cgi-bin
CGI-Programme (CGI – Common Gateway Interface) sind in diesem Verzeichnis
zu finden. Nach der Installation ist dort ein Perl-Skript namens printenv.pl vorhanden, welches Umgebungsvariablen des Servers anzeigt. Außerdem befindet sich
dort ein Shellskript, welches ebenfalls ausgewählte Umgebungsvariablen des Servers anzeigt.
conf
Die zentrale Konfigurationsdatei httpd.conf des Indianers liegt hier sowie eine
Tabelle mit MIME-Typen.
error
Die Informationsseiten des Apache, die im Falle eines Fehlers angezeigt werden,
befinden sich in diesem Verzeichnis und können entsprechend den jeweiligen
Wünschen und Gegebenheiten angepasst werden.
htdocs
Die Informationen und Dateien (Grafiken, Html-Dateien etc.), die veröffentlicht
werden sollen, werden in diesem Verzeichnis gespeichert.
icons
Im PNG- und GIF- Format befinden sich hier diverse kleine Bildchen (so genannte
Icons), die der Apache bei diversen Anlässen (u.a. Verzeichnislistings) anzeigt.
include
In diesem Verzeichnis sind die in C geschriebenen Header-Dateien des Apache sowie einige Zusatzmodule gespeichert.
lib
Der Apache bringt eine Reihe von eigenen Bibliotheken mit, die in diesem Verzeichnis gesichert werden. Dazu gehören u.a. die Bibliothek libapr der Apache Portable Runtime sowie die Apache Portable Runtime Utils, deren Bibliothek libapr-util
heißt.
logs
Die Logdateien, die Auskunft über eventuell aufgetretene Fehler und die Anzahl
bzw. Inhalte der Clientanfragen geben, befinden sich in diesem Verzeichnis.
man
Die unter Unix/Linux bekannten und oft genutzten Handbücher (genannt manpages)
des Apache und der von ihm genutzten und bereitgestellten Zusatzprogramme.
modules
Wenn Sie Module als Dynamic Shared Objects übersetzt haben, werden diese Module in diesem Verzeichnis gespeichert.
212
5 Konfiguration
proxy (optional!)
Falls der Apache-Server gleichzeitig auch als Proxyserver eingesetzt wird, werden
in diesem Verzeichnis die durch die Clients aufgerufenen Seiten zwischengespeichert.
Unter Windows wird der Apache standardmäßig unter C:\Program Files\Apache
Group\Apache2 installiert und es zeigt sich in diesem Verzeichnis folgende Struktur:
C:\Program Files\Apache Group\Apache2:
bin
Hier befinden sich ausführbare Programme wie htpasswd, rotatelogs etc. sowie
das eigentliche Apache-Programm.
build
Dieses Verzeichnis existiert unter Windows in der binären Variante nicht.
cgi-bin
CGI-Programme (CGI – Common Gateway Interface) sind in diesem Verzeichnis
zu finden. Nach der Installation ist dort ein Perl-Skript namens printenv.pl vorhanden, welches Umgebungsvariablen des Servers anzeigt.
conf
Die zentrale Konfigurationsdatei httpd.conf des Indianers liegt hier sowie eine Tabelle mit MIME-Typen. Ebenso finden sich Beispiele für die Konfiguration von SSL
und der Datei httpd.conf.
error
Die Informationsseiten des Apache, die im Falle eines Fehlers angezeigt werden,
befinden sich in diesem Verzeichnis und können entsprechend den jeweiligen
Wünschen und Gegebenheiten angepasst werden.
htdocs
Die Informationen und Dateien (Grafiken, Html-Dateien, etc.), die veröffentlicht
werden sollen, werden in diesem Verzeichnis gespeichert.
icons
Im PNG und GIF Format befinden sich hier diverse kleine Bildchen (so genannte
Icons), die der Apache bei diversen Anlässen (u.a. Verzeichnislistings) anzeigt.
include
In der vorkompilierten Variante des Apache existiert dieses Verzeichnis, ebenso
wie das Unterverzeichnis build, nicht.
lib
Das Verzeichnis existiert in der Standardinstallation nicht.
logs
Die Logdateien, die Auskunft über eventuell aufgetretene Fehler und die Anzahl
bzw. Inhalte der Clientanfragen geben, befinden sich in diesem Verzeichnis.
5.2 Basiskonfiguration
213
manual
In diesem Verzeichnis sind die kompletten Handbücher des Apache gespeichert.
modules
Wenn Sie Module als Dynamic Shared Objects übersetzt haben, werden diese Module in diesem Verzeichnis gespeichert.
proxy
Falls der Apache-Server gleichzeitig auch als Proxyserver eingesetzt wird, werden
in diesem Verzeichnis die durch die Clients aufgerufenen Seiten zwischengespeichert.
Die meisten Verzeichnis- bzw. Dateiangaben, die innerhalb der Datei httpd.conf
gemacht werden, müssen in relativer Form angegeben werden, d.h., bei der Angabe
eines Verzeichnisses oder einer Datei setzt der Server automatisch das als ServerRoot
gesetzte Verzeichnis davor. Ein Beispiel:
ServerRoot "/usr/local/apache2"
PidFile logs/httpd.pid
Das Hauptinstallationsverzeichnis (ServerRoot) ist auf /usr/local/apache2 gesetzt, das
PidFile ist in relativer Form (logs/httpd.pid) angegeben. Der Server interpretiert die
Angabe (logs/httpd.pid) und setzt das als ServerRoot angegebene Verzeichnis davor,
so dass das PidFile demzufolge unter /usr/local/apache2/logs/httpd.pid gespeichert wird.
Das als ServerRoot genutzte Verzeichnis kann beim manuellen Start des Apache auch
direkt als Parameter an den Server übergeben werden. Wenn Sie beispielsweise das
Verzeichnis /opt/apache als Hauptinstallationsverzeichnis des Apache nutzen, so
können Sie dieses Verzeichnis unter Angabe des Parameters –d als ServerRoot setzen.
Der Aufruf des Apache-Servers würde demnach wie folgt aussehen:
Hinweis
# /opt/apache/bin/httpd –d /opt/apache
Bitte beachten Sie außerdem, dass Verzeichnisangaben unter Windows nicht
wie sonst üblich, mit einem Backslash (»\«) angegeben werden müssen, sondern dieser Backslash immer durch einen Forwardslash ersetzt werden muss
(»/«)! Wenn Sie beispielsweise das Hauptverzeichnis des Apache (ServerRoot)
auf das Verzeichnis C:\Apache2 verweisen lassen möchten, so ist folgende
Anweisung falsch und wird zu einer Fehlermeldung führen:
ServerRoot C:\Apache2
Korrekterweise muss diese Anweisung wie folgt aussehen:
ServerRoot C:/Apache2
Dieser Umstand ist unter Windows immer wieder Grund für zahlreiche Probleme mit
dem Server oder darauf laufenden Programmen bzw. Skripten.
214
5 Konfiguration
AccessFileName
Definition einer Datei mit zusätzlichen Konfigurationsanweisungen.
Konfigurationsanweisung:
AccessFileName
Syntax:
AccessFileName Dateiname
Standardwert (Default):
AccessFileName .htaccess
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Der Apache erlaubt die Auslagerung von bestimmten Konfigurationsanweisungen in
externe Dateien. Mit dieser Konfigurationsanweisung legen Sie den Namen solcher
externen Konfigurationsdateien fest, wobei Sie auch mehrere Dateinamen angeben
können:
AccessFileName .htaccess .zugriffsrechte
Bevor der Apache ein angefordertes Dokument an einen Client sendet, überprüft dieser mit Hilfe der Anweisung, ob sich in dem Verzeichnis, in dem das Dokument
gespeichert ist, eine Datei namens .htaccess oder .zugriffsrechte befindet, in der weitere
Konfigurationsanweisungen enthalten sein können. Falls eine solche Datei vorhanden ist, werden die in dieser Datei enthaltenen Konfigurationsanweisungen ausgeführt, wobei die AllowOverride-Anweisung bestimmt, welche Art von Anweisungen
in einer solchen ausgelagerten Datei enthalten sein dürfen. Interessanterweise sucht
der Apache auch in allen übergeordneten Verzeichnissen nach solchen Dateien mit
ausgelagerten Konfigurationsanweisungen. Dies hat zur Folge, dass bei einem
Zugriff auf die Datei /usr/local/web/index.html im Verzeichnis /, /usr, /usr/local und
/usr/local/web nach einer Datei mit dem durch die Anweisung AccessFileName definierten Dateinamen (z.B. .htaccess) gesucht wird.
Um diese unnötigen Suchen zu vermeiden, sollten Sie die Auslagerung von Anweisungen in externe Dateien komplett deaktivieren und nur für einzelne Verzeichnisse,
in denen eine solche Funktionalität tatsächlich benötigt wird, aktivieren:
<Directory />
AllowOverride None
</Directory>
Dadurch können bestehende Konfigurationsanweisungen nicht durch externe Konfigurationsdateien überschrieben werden. Wenn Sie dann externe Konfigurationsdateien für einzelne Verzeichnisse benötigen, können Sie diese explizit für ein Verzeichnis erlauben:
<Directory /usr/local/apache2/htdocs/logs>
AllowOverride AuthConfig
</Directory>
5.2 Basiskonfiguration
215
Im Verzeichnis /usr/local/apache2/htdocs/logs können Sie nun Dateien mit externen
Konfigurationsanweisungen des Apache installieren, Dateien in übergeordneten Verzeichnissen werden nicht beachtet. Diese Textdateien dürfen allerdings nur solche
Anweisungen enthalten, die direkt zur Authentifizierung dienen (vgl. AllowOverride).
Um das eben vorgestellte Verzeichnis /usr/local/apache2/htdocs/logs zu schützen, da es
beispielsweise die grafische Auswertung des Zugriffs auf unseren Webserver enthält,
könnte man etwa eine .htaccess-Datei im Unterverzeichnis logs anlegen, die folgende
Anweisungen enthält:
AuthType Basic
AuthName "Auswertung der Zugriffe auf den Server"
AuthUserFile /usr/local/apache2/conf/.htpasswd
require valid-user
Um einem Benutzer durch Angabe eines Benutzernamens und eines Passworts den
Zugriff auf dieses Verzeichnis zu gewähren, muss man nur noch eine entsprechende
Passwortdatei erstellen. Sie können eine solche Datei mit dem Programm htpasswd
(Unix/Linux) bzw. htpasswd.exe (Win32) erzeugen, das der Apache-Distribution beiliegt. Um einem Benutzer namens peter den Zugriff auf dieses Verzeichnis zu erlauben, verwenden Sie beispielsweise Befehl:
# /usr/local/apache2/bin/htpasswd -c /usr/local/apache2/conf/.htpasswd peter
Sie müssen danach ein Passwort für den Benutzer peter definieren und zur Sicherheit
zweimal eingeben. Wenn Sie weiteren Benutzern den Zugriff auf das Verzeichnis
gewähren möchten, lassen Sie danach den Parameter -c (engl. create, erzeugen) beim
Aufruf des Programms htpasswd weg, da dieser ansonsten die bereits vorhandene
Datei löscht bzw. eine neue Datei anlegt und damit die alte überschreibt!
Um also auch dem Benutzer hans den Zugriff auf das geschützte Verzeichnis zu
ermöglichen, könnten Sie folgenden Befehl benutzen:
# /usr/local/apache2/bin/htpasswd /usr/local/apache2/conf/.htpasswd hans
Bitte beachten Sie, dass eine Datei mit externen Konfigurationsanweisungen und verschlüsselten Passwörtern durch den Apache lesbar sein muss, damit diese aktiv werden können. Sie erreichen dies beispielsweise, indem Sie die Datei für alle Benutzer,
d.h. auch den Benutzer des Apache, lesbar machen:
# chmod 644 /usr/local/apache2/conf/.htpasswd
Wichtig dabei ist, dass eine .htpasswd-Datei immer außerhalb des zu schützenden
Bereichs gespeichert ist, damit ein Benutzer die Datei nicht herunterladen und entschlüsseln kann! Wenn Sie sichergehen sein möchten, dass man die .htpasswd-Datei
nicht stehlen kann, speichern Sie diese außerhalb des als DocumentRoot definierten
Verzeichnisses (z.B. unter /usr/local/apache2/conf/.htpasswd).
Weitere Informationen zur Verwendung von externen Konfigurationsdateien (meist
.htaccess) und htpasswd finden Sie in den Erläuterungen zu den Konfigurationsoptionen AllowOverride und AuthUserFile sowie im Anhang des Buchs. Zusätzliche Infor-
216
5 Konfiguration
mationen zu diesem Thema finden Sie ebenfalls im Handbuch des Apache unter
http://httpd.apache.org/docs-2.0/howto/htaccess.html.
AllowOverride
Definiert die Art von Konfigurationsanweisungen, die in externen Konfigurationsdateien des Apache auftauchen dürfen.
Konfigurationsanweisung:
AllowOverride
Syntax:
AllowOverride Optionen
Standardwert (Default):
AllowOverride None (mehrfach vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
<Directory>-Container
Anweisung aktiv:
ja
Mit der Konfigurationsanweisung AllowOverride können Sie bestimmen, ob der Apache externe Konfigurationsdateien unterstützen soll oder nicht. Dazu definieren Sie
durch diese Anweisung die Art von Konfigurationsanweisungen, die in einer solchen
externen Datei enthalten sein dürfen. Bitte beachten Sie, dass Sie nur solche Konfigurationsanweisungen in externen Dateien verwenden können, die laut Definition überhaupt in solchen Kontexten erlaubt sind. Konsultieren Sie dazu die Beschreibungen
der einzelnen Anweisungen sowie das Handbuch des Apache!
Als mögliche Optionen stehen Ihnen dabei die nachfolgenden Werte zur Verfügung:
None
Die Option None deaktiviert die Verwendung von externen Konfigurationsdateien
komplett. Sollte eine derartige Datei im Dateisystem vorhanden sein, wird der Server
diese einfach ignorieren und überhaupt nicht lesen.
All
Sofern der Parameter All gesetzt ist, können Sie jede Konfigurationsanweisung des
Apache in einer externen Konfigurationsdatei benutzen, sofern diese laut Definition
überhaupt in einem so genannten .htaccess-Kontext, d.h. in einer externen Konfigurationsdatei, eingesetzt werden darf. Vergleichen Sie dazu bitte die Beschreibungen zu
den einzelnen Direktiven sowie das Handbuch des Apache. Dieser Parameter sollte
niemals gewählt werden, denn er ermöglicht lokalen Benutzern die Veränderung von
essentiellen Eigenschaften und Verhaltensweisen des Servers, die eigentlich nur
durch den Administrator geändert werden sollten.
AuthConfig
Dieser Parameter ist wohl der am häufigsten benutzte Parameter der Anweisung
AllowOverride, denn er gibt an, dass jede Konfigurationsoption, die direkt mit
Authentifizierung zu tun hat, in einer externen Konfigurationsdatei verwendet werden kann. Dadurch lassen sich beispielsweise passwortgeschützte Verzeichnisse (vgl.
AccessFileName-Anweisung) realisieren. Verfügbar sind u.a. die Anweisungen AuthUserFile, AuthGroupFile, AuthType und Require.
5.2 Basiskonfiguration
217
FileInfo
Der Parameter FileInfo ermöglicht die Verwendung von allen Direktiven, die sich auf
gespeicherte Dokumente beziehen. Dazu gehören u.a. die Anweisungen DefaultType,
ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter
sowie alle Add*- und Remove*-Anweisungen des Moduls mod_mime.
Indexes
Indexes erlaubt die Verwendung von Konfigurationsanweisungen, die das Verhalten
des Servers bei einer Verzeichnisindizierung bestimmen. Dazu gehören u.a. die
Anweisungen AddIcon, DirectoryIndex und ReadmeName.
Limit
Der Limit-Parameter gestattet die Verwendung von Anweisungen, die den Zugriff
auf den Server beschränken (z.B. Allow, Deny oder Order).
Options
Der letzte mögliche Parameter der Anweisung AllowOverride erlaubt die Verwendung von Konfigurationsanweisungen, die verzeichnisspezifische Verhaltensweisen
definieren (z.B. CheckSpelling, Options).
Die Anweisung AllowOverride erlaubt die Angabe eines oder auch mehrerer der
soeben vorgestellten Parameter. Dazu folgen zwei Beispiele für die Verwendung
eines bzw. zweier Parameter:
AllowOverride AuthConfig
AllowOverride AuthConfig Indexes
5.2.4
Benutzer- und Gruppenverwaltung
User
Definition eines Benutzers, mit dessen Kennung der Apache-Serverprozess laufen
soll.
Konfigurationsanweisung:
User
Syntax:
User Benutzername
Standardwert (Default):
User nobody
Verfügbar in Modul:
mpm_leader, mpm_threadpool,
mpm_worker, mpm_perchild und
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Wird der Apache gestartet, so startet dieser sofort eine gewisse Anzahl von Unterprozessen, die unter einer bestimmten Benutzerkennung laufen und die Anfragen der
Clients beantworten. Der ursprüngliche Serverprozess, der auch die Unterprozesse
218
5 Konfiguration
erzeugt, läuft unter der Benutzerkennung des root-Benutzers, da es nur diesem
Benutzer erlaubt ist, einen so genannten privilegierten Port, d.h. einen Port kleiner als
1024, zu benutzen.
Die Benutzerkennung der Unterprozesse, die letztlich die Anfragen der Clients bearbeiten, wird durch den Konfigurationsparameter User bestimmt und kann entweder
der Name eines im lokalen System vorhandenen Benutzers oder dessen nummerische
Benutzer-ID (mit vorangestelltem »#«) sein. Nach der Installation sieht die Definition
des Benutzers wie folgt aus:
User nobody
Ebenso wäre die Verwendung der nummerischen Kennung (ID) des Benutzers nobody
möglich. Sie erhalten die nummerische ID des Users nobody durch folgenden Aufruf:
# cat /etc/passwd | grep nobody
Das von mir verwendete Debian-System liefert folgenden Eintrag zurück:
nobody:x:65534:65534:nobody:/home:/bin/sh
Unter Umständen können die hier gezeigten Werte für Ihr System abweichen, das
Prinzip ist jedoch immer gleich:
Benutzername:Passwort:Benutzer-ID:Gruppen-ID:Beschreibung:Heimatverzeichnis:Shell
Das Passwort wird verschlüsselt und ist hier durch ein einfaches »x« gekennzeichnet,
auf manchen Systemen (z.B. FreeBSD 4.5) wird ein verschlüsseltes Kennwort auch
durch ein Sternchen »*« symbolisiert. Die Benutzer-ID ist eine von 0 bis 65535 fortlaufende Nummer, die für jeden Benutzer einmalig ist. Die Gruppen-ID symbolisiert die
Kennung der Benutzergruppe, der ein Benutzer zugeordnet ist. Diese erhalten Sie
durch folgenden Befehl:
# cat /etc/group | grep Gruppen-ID
Für das von mir gezeigte Beispiel des Benutzers nobody, der zur Gruppe 65534 gehört,
sieht diese Zeile demnach wie folgt aus:
# cat /etc/group | grep 65534
Da Sie die nummerische ID des Benutzers nobody kennen, können Sie diese auch in
der httpd.conf des Apache angeben, wobei bei der Angabe einer nummerischen Benutzer-ID immer ein Raute-Zeichen (»#«) vorangestellt werden muss:
User #65534
Wenn Sie das »#«-Zeichen vergessen sollten, werden Sie beim Start des Apache etwa
folgende Fehlermeldung erhalten und der Start des Servers wird abgebrochen:
httpd: bad user name 65534
5.2 Basiskonfiguration
219
Es ist auch möglich, den Apache direkt unter der Benutzerkennung eines anderen
Benutzers als der des root-Benutzers zu starten, jedoch ist es dem Server in diesem
Fall nicht mehr möglich, bei der Erstellung der Unterprozesse zur Bearbeitung der
Clientanfragen in die Haut bzw. Rolle eines anderen Benutzers zu wechseln, da nur
der root-Benutzer das Recht besitzt, ohne Passwortabfrage in die Rolle jedes lokalen
Benutzers zu wechseln. Achtung: Verwenden Sie unter keinen Umständen die Benutzerkennung des root-Benutzers als Parameter für die Option User, denn dies würde
eine große Sicherheitslücke in Ihr System reißen und könnte gegebenenfalls zur einer
erfolgreichen Hackerattacke führen, da es beliebigen Benutzern durch simple Tricks
möglich wäre, jede Datei des lokalen Systems zu lesen! Sollten Sie dennoch den Server unter der Kennung des root-Benutzers betreiben möchten, wovon ich an dieser
Stelle noch mal sehr deutlich abraten möchte, so müssen Sie den Server neu installieren und vor der Installation folgende Umgebungsvariable setzen, die an den Compiler übergeben wird:
# env CFLAGS='-DBIG_SECURITY_HOLE' ./configure
--prefix=/usr/local/apache2_user_root
Die Option, die an den Compiler übergeben wird, lautet BIG_SECURITY_HOLE und
spricht Bände. Die Option wird gekennzeichnet durch die Angabe des Parameters –D
und gefolgt durch den kompletten Aufruf des configure-Skriptes des Apache mit den
entsprechenden von Ihnen verwendeten Parametern. Wenn Sie den Apache in der
Art kompiliert und installiert haben, würde folgendes in Perl geschriebenes CGISkript genügen, um die kritischsten Dateien Ihres Systems zu lesen:
#!/usr/bin/perl
##
## (C) 2002 by Sebastian Wolfgarten, <[email protected]>
##
## Beschreibung: Wenn der Apache unter der Kennung des root## Benutzers laeuft, so kann jeder Benutzer beliebige Dateien des
## lokalen Systems lesen. Dazu gehoeren auch systemkritische
## Dateien wie /etc/passwd und /etc/shadow, wie das nachfolgende
## (sehr simple) Beispiel beweist:
##
## Installation: Kopieren Sie diese Datei in das
## "cgi-bin" Verzeichnis Ihrer Apache-Installation, machen Sie es
## ausfuehrbar (chmod +x printpasswd), aendern Sie gegebenenfalls
## den Pfad zu Ihrem Perl-Interpreter und rufen Sie es mit Ihrem
## Browser auf. Viel Spass!
##
## Hinweis: Lassen Sie NIEMALS den Apache unter der Kennung
## des root-Benutzers laufen!
##
print "Content-type: text/plain\n\n";
print "<html>\n";
220
5 Konfiguration
print "<title>Apache als root-Benutzer</title>\n";
print "<h1>Anzeige der Datei /etc/passwd</h1>\n";
open(passwortdatei,"/etc/shadow") || print "Kann /etc/passwd nicht oeffnen\n";
while (<passwortdatei>) {
print $_;
print "<BR>\n";
}
close(passwortdatei);
print "\n";
print "<h1>Anzeige der Datei /etc/shadow</h1>\n";
open(shadowdatei,"/etc/shadow") || print "Kann /etc/shadow nicht oeffnen\n";
while (<shadowdatei>) {
print $_;
print "<BR>\n";
}
close(shadowdatei);
print "</html>\n";
Listing 5.1 Beispielprogramm zum Auslesen beliebiger lokaler Dateien
Sobald Sie den Apache starten und dieses Skript ausführen, wird eine schlichte
HTML-Seite erzeugt, die die auf Ihrem System verwendete Passwortdatei /etc/passwd
inklusive der zur Verschlüsselung genutzten Datei /etc/shadow ausliest.
Tun Sie sich und Ihren Daten deshalb einen Gefallen und lassen Sie den Server NIEMALS
unter der Benutzerkennung des root-Benutzers laufen!
Beachten Sie außerdem, dass die Konfigurationsoption User auf der Windows-, Netware- und OS/2-Plattform noch nicht unterstützt wird. Sollten Sie eine der genannten
Plattformen einsetzen, können Sie diesen Part einfach überspringen.
Teilweise läuft der Apache unter der Kennung des Benutzers nobody und der Gruppe
nogroup. Dies ist zwar durchaus möglich, aber nur sehr begrenzt ratsam, da es eventuell zu Überschneidungen mit anderen Diensten des Servers (z.B. Proxy-Server) kommen kann, wenn diese ebenfalls unter der besagten Kennung laufen. Die Erzeugung
einer eigenen Gruppe und eines eigenen Benutzers für den Apache ist daher äußerst
ratsam und sollte unbedingt durchgeführt werden.
Wenn Sie den Apache beispielsweise nach /usr/local/apache2 installiert haben, so können Sie durch folgenden Befehl einen neuen Benutzer namens wwwrun zum lokalen
System hinzufügen (eine Zeile!):
# useradd -c "Benutzer fuer den Apache" -g aprun
-d /usr/local/apache2 -s /bin/false -p SICHER wwwrun
5.2 Basiskonfiguration
221
Dieser Befehl fügt dem lokalen System einen Benutzer namens wwwrun hinzu, der als
Heimatverzeichnis das Verzeichnis /usr/local/apache2 hat, als Shell die Datei /bin/false
benutzt und dessen Passwort SICHER lautet. Er gehört der Gruppe aprun an, wobei
Sie beachten müssen, dass die Gruppe aprun vor dem Ausführen dieses Befehls auf
dem lokalen System bereits existiert, andernfalls erhalten Sie eine entsprechende Fehlermeldung:
useradd: unknown group aprun
Lesen Sie gegebenenfalls die Anleitung zur Konfigurationsanweisung Group und
fügen Sie die neue Gruppe aprun dem System hinzu. Der oben genannte Befehl
useradd fügt zusätzlich eine Beschreibung in die Datei /etc/passwd für den Benutzer
wwwrun hinzu, damit Sie später auch wissen, warum Sie diesen Benutzer seinerzeit
erzeugt haben und welche Funktion dieser einnimmt. Die Shell lautet /bin/false, damit
sich niemand als Benutzer wwwrun auf dem lokalen System anmelden kann. Das hier
gewählte Passwort SICHER sollte selbstverständlich geändert werden in eine Zeichenkette mit unterschiedlicher Groß- und Kleinschreibung sowie einer Kombination
aus Buchstaben und Zahlen! Die allgemeine Syntax für das manuelle Hinzufügen
neuer Benutzer sieht wie folgt aus (gekürzt):
# useradd –c Kommentar –d Heimatverzeichnis –g Gruppe
–p Passwort –s Shell Benutzername
Sollten Sie einen Kommentar hinzufügen wollen, so müssen Sie diesen in Anführungszeichen setzen. Es gibt noch eine Reihe weiterer Optionen für den Befehl
useradd, die u.a. eine bestimmte Benutzer-ID für den neu erstellten Benutzer setzen
oder die Gültigkeit des Benutzerkontos einschränken. Sie erhalten weitere Informationen zur Verwendung des Befehls useradd durch Eingabe eines der beiden Befehle:
Hinweis
# man useradd
# useradd --help
Auf Systemen mit einer traditionellen Benutzer- und Gruppenverwaltung, d.h.
auf Systemen die zur Verschlüsselung der Kennwörter nicht das ShadowSystem verwenden, lauten die Befehle zur Erzeugung von Benutzern nicht
useradd und groupadd, sondern adduser und addgroup! Die heute auf dem Markt
verfügbaren Unix und Linux-Versionen sollten jedoch alle das Shadow-System
zur Verschlüsselung von Passwörtern verwenden, so dass Sie die Befehle
useradd und groupadd verwenden müssen, es sei denn, ein leichtsinniger und
sehr unerfahrener Administrator hat die Verschlüsselung von Passwörtern mit
Hilfe des Shadow-Systems deaktiviert.
Die verschiedenen Systeme bieten teilweise auch eigene Werkzeuge an, um die allgemeine Administration sowie die Erzeugung von Benutzern zu vereinfachen. Beispiele
für diese Werkzeuge sind etwa Yast (SuSE) und userconf (RedHat). Nutzen Sie diese
Tools, wenn Sie noch nicht so erfahren im Umgang mit der Unix- bzw. Linux-Plattform sind (oder wenn Sie einfach zu faul sind, die entsprechenden Befehle manuell
einzugeben).
Hinweis
222
5 Konfiguration
Im Vergleich zum Apache 1.3.x ist es im Apache 2.x nicht mehr möglich, die
User- oder Group-Anweisung innerhalb eines <VirtualHost>-Containers zu
benutzen. Sie müssen daher auf die Verwendung von suEXEC respektive die
SuEXECUserGroup-Anweisung oder ein geeignetes Laufzeitmodell (z.B.
PerChild) ausweichen.
Group
Angabe einer Gruppe, mit deren Kennung der Apache-Serverprozess laufen soll.
Anweisung:
Group
Syntax:
Group Gruppenname
Standardwert (Default):
Group #-1
Verfügbar in Modul:
mpm_leader, mpm_threadpool,
mpm_worker, mpm_perchild und
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Durch diese Konfigurationsoption wird eine Gruppe definiert, mit deren Kennung
die Apache Serverprozesse, die die Anfragen der Clients beantworten, laufen sollen.
Der Server startet zunächst unter der Kennung des root-Benutzers und legt eine
gewisse Anzahl von Unterprozessen an, die die Anfragen der Clients bearbeiten und
unter der Kennung eines bestimmten Benutzers und Gruppe, die durch diesen Parameter gesetzt wird, laufen. Wird der initiale Serverprozess dagegen nicht durch den
root-Benutzer gestartet, so ist es dem Apache nicht möglich, die Gruppenzugehörigkeit der Unterprozesse nachträglich zu verändern, d.h., diese gehören auch nach dem
Programmstart der ursprünglich den Start des Apache auslösenden Benutzergruppe.
Wenn Sie beispielsweise die Gruppe webuser erstellt haben und Sie möchten den Apache unter der Kennung dieser Gruppe betreiben, so sieht die entsprechende Konfigurationsanweisung wie folgt aus:
Group webuser
Die Angabe der nummerischen Kennzahl (ID) einer Gruppe ist ebenfalls möglich,
diese muss jedoch, ebenso wie in der User-Direktive, durch ein vorangestelltes »#«Zeichen gekennzeichnet werden. Sie erhalten die nummerische ID einer Gruppe
durch folgenden Befehl (allgemein):
# cat /etc/group | grep Gruppenname
Für die von mir beispielhaft vorgestellte Gruppe webuser würde dieser Befehl wie
folgt aussehen:
# cat /etc/group | grep webuser
5.2 Basiskonfiguration
223
Mit diesem Befehl suchen Sie in der Datei /etc/group nach der Zeichenkette webuser
und finden in etwa einen solchen Eintrag:
webuser:x:33:
Die einzelnen Werte in dieser Datei sind durch Doppelpunkte getrennt, der Wert in
der dritten Spalte (33) symbolisiert die Nummer der Gruppe webuser. Prinzipiell hat
die Datei /etc/group folgenden Aufbau:
Gruppenname:Passwort:Gruppen-ID:Mitgliederliste
Daraus ergibt sich für uns folgende Anweisung in der Konfigurationsdatei des Apache:
Group #33
Nach der Installation des Apache sieht die Konfiguration der Option Group wie folgt
aus, was in den meisten Fällen der Gruppe nobody bzw. nogroup entspricht:
Group #-1
Die Konfigurationsanweisung Group wird, ebenso wie die Anweisung User, auf der
Windows-, Netware- und OS/2-Plattform nicht unterstützt. Sollten Sie eine der
genannten Plattformen benutzen, so können Sie diesen Teil getrost überspringen.
Es ist durchaus sinnvoll, für den Apache einen eigenen Benutzer sowie eine eigene
Gruppe zu definieren, mit dessen bzw. deren Kennung der Server laufen kann. Erstellen Sie deshalb auf dem lokalen System eine neue Gruppe namens aprun, zu der später
ein neu erstellter und dedizierter Benutzer für den Apache hinzugefügt werden kann:
# groupadd aprun
Das Anlegen einer neuen Gruppe ist, wie Sie unschwer sehen können, wirklich einfach und bedarf im Prinzip nur des Aufrufs des Programms groupadd, gefolgt von der
Angabe des Namens der neuen Gruppe. Der Befehl sieht also wie folgt aus:
# groupadd Gruppenname
Nun können Sie, falls noch nicht geschehen, einen eigenen Benutzer für den Apache
anlegen und in die Konfigurationsdatei httpd.conf des Apache die neu angelegte Gruppe
sowie den entsprechenden Benutzer eintragen, damit diese Verwendung finden:
Group aprun
User wwwrun
Starten Sie den Apache neu und Sie werden sehen, dass die Unterprozesse des Apache, die die eigentlichen Anfragen der Clients bearbeiten, unter der Kennung des neu
erzeugten Benutzers (inklusive der neu erstellen Gruppe) laufen. Geben Sie zur Überprüfung folgenden Befehl ein:
# ps aux | grep httpd
224
5 Konfiguration
Dieser Befehl sucht Ihnen aus der Liste der aktuell laufenden Prozesse alle Prozesse
heraus, die die Zeichenkette httpd enthalten. Bei einer meiner Testinstallationen mit
dem MPM Prefork sieht die Ausgabe des oben genannten Befehls wie folgt aus (leicht
gekürzt):
root
wwwrun
wwwrun
wwwrun
wwwrun
wwwrun
766
767
768
769
770
771
0.0
0.0
0.0
0.0
0.0
0.0
0.7
0.7
0.7
0.7
0.7
0.7
4200
4224
4224
4224
4224
4224
1816
1832
1832
1832
1832
1832
?
?
?
?
?
?
S
S
S
S
S
S
19:40
19:40
19:40
19:40
19:40
19:40
0:00
0:00
0:00
0:00
0:00
0:00
./httpd
./httpd
./httpd
./httpd
./httpd
./httpd
Hier lässt sich prima sehen, dass der ursprüngliche Prozess unter der Kennung des
root-Benutzers gestartet worden ist, die Unterprozesse jedoch unter einer eigenen
Kennung (wwwrun) laufen. Diese Prozesse laufen auch unter der richtigen Gruppenkennung, wie der folgende Befehl zeigt:
# ps --Group aprun u
Sollten Sie einen anderen Gruppennamen als aprun gewählt haben, müssen Sie diesen
natürlich ersetzen. Sie erhalten in etwa folgende Ausgabe (Spaltenüberschriften wurden entfernt):
wwwrun
wwwrun
wwwrun
wwwrun
wwwrun
767
768
769
770
771
0.0
0.0
0.0
0.0
0.0
0.7
0.7
0.7
0.7
0.7
4224
4224
4224
4224
4224
1832
1832
1832
1832
1832
?
?
?
?
?
S
S
S
S
S
19:40
19:40
19:40
19:40
19:40
0:00
0:00
0:00
0:00
0:00
./httpd
./httpd
./httpd
./httpd
./httpd
Hinweis
Die verschiedenen Systeme bieten teilweise auch eigene Werkzeuge an, um die allgemeine Administration sowie die Erzeugung von Benutzern zu vereinfachen. Beispiele
für diese Werkzeuge sind etwa Yast (SuSE) und userconf (RedHat). Nutzen Sie diese
Tools, wenn Sie noch nicht so erfahren im Umgang mit Benutzer der Unix- bzw.
Linux-Plattform sind (oder einfach faul sind).
Sollten Sie eine veraltete Version Ihres Unix bzw. Linux-Betriebssystems verwenden, kann es unter Umständen sein, dass diese noch die traditionelle Passwort-Verwaltung, d.h. ohne die Unterstützung von Shadow-Passwörtern, verwendet. In diesem Falle müssen Sie den Befehl addgroup benutzen, um eine
neue Gruppe dem System hinzuzufügen. Inzwischen sollten jedoch die meisten
auf dem Markt verfügbaren Systeme die Verwendung von Shadow-Passwörtern unterstützen, es sein denn, der Administrator hat die Verwendung von
derartigen Verschlüsselungstechniken (aus welchem Grund auch immer) deaktiviert. Wenn Sie die neu erstellte Gruppe löschen möchten, so können Sie dies
mit dem Befehl groupdel tun. Führen Sie beispielsweise folgendes Kommando
aus, um die Beispiel-Gruppe aprun zu löschen:
# groupdel aprun
5.2 Basiskonfiguration
225
Bitte beachten Sie jedoch, dass Sie keine Gruppe löschen können, wenn es sich dabei
um die primäre Gruppe mindestens eines lokalen Benutzers handelt! In diesem Fall
erhalten Sie prompt eine Fehlermeldung:
groupdel: cannot remove user's primary group.
Löschen Sie vorher die Benutzer, die diese Gruppe als primäre Gruppe benutzten,
oder ordnen Sie diese Benutzer einer neuen Gruppe zu und löschen Sie danach durch
oben genannten Befehl die Gruppe. Normalerweise sollte nur der eigens für den Apache erstellte Benutzer die Gruppe als primäre Gruppe benutzen, aber wenn Sie aus
irgendeinem Grund weitere Benutzer erstellt haben, die diese Gruppe als primäre
Gruppe benutzen, so erhalten Sie eine Liste der Benutzer durch folgenden Einzeiler:
# cat /etc/passwd | grep `cat /etc/group | grep aprun | awk
-F: '{ print $3}'`
Hinweis
Dieser Befehl gibt den Inhalt der Datei /etc/passwd (cat /etc/passwd) aus und sucht in
dieser Datei nach einem Wert (grep ...), der in der Datei /etc/group (cat /etc/group) steht.
Dieser Wert ist die Gruppen-ID der Gruppe aprun (grep aprun) und steht in der Datei
/etc/group immer in der dritten Spalte jeder Zeile (awk '{ print $3}'), wobei diese Spalten jeweils durch Doppelpunkte voneinander getrennt sind (–F:).
Sollten Sie ein System mit traditioneller Passwortverwaltung verwenden, lautet
der Befehl zum Löschen einer Gruppe übrigens delgroup, die Benutzung erfolgt
analog zu den hier vorgestellten Befehlen.
BS2000Account
Spezifiziert den nicht privilegierten Benutzer auf BS2000-kompatiblen Systemen.
Konfigurationsanweisung:
BS2000Account
Syntax:
BS2000Account Benutzername
Standardwert (Default):
nicht vorhanden
Verfügbar in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Wenn Sie den Apache auf einem BS2000-System (Mainframe) betreiben, müssen Sie
mit dieser Anweisung den nicht privilegierten Benutzer angeben, der durch die UserAnweisung definiert worden ist. Dieser wird benötigt, da das BS2000-System intern
einen so genannten Sub-Logon (=Wechsel der Anwendungsumgebung) durchführt,
um zu verhindern, dass CGI-Skripte in einem privilegierten Modus ausgeführt werden.
226
5.2.5
5 Konfiguration
Ressourcenbegrenzung und Prozessmanagement
LimitRequestBody
Legt die Gesamtgröße einer HTTP-Anfrage eines Clients an den Server fest.
Konfigurationsanweisung:
LimitRequestBody
Syntax:
LimitRequestBody Bytes
Standardwert (Default):
LimitRequestBody 0 (falls vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Kontext, <Location>-Kontext,
<Files>-Kontext, .htaccess-Kontext
Anweisung aktiv:
nein
Die Konfigurationsoption LimitRequestBody legt die Gesamtgröße der Daten im Body
einer HTTP-Anfrage eines Clients an den Server fest. Standardmäßig ist die Größe auf
0 eingestellt, was einer beliebig großen Datenmenge entspricht. Die Größe kann bis zu
2147483648 Byte betragen, was exakt 2 GB entspricht. Wird der Wert durch die vom
Client gesendeten Daten überschritten, erhält dieser eine entsprechende Fehlermeldung. Die Anweisung gibt dem Administrator bessere Kontrolle über abnormales
Clientverhalten, was der Vermeidung von Denial of Service-Attacken dienen kann.
Die Anweisung LimitRequestBody kann sogar innerhalb eines <Location>- oder
<Files>-Kontext verwendet werden, wodurch die Größenbeschränkung bis auf Dateiebene benutzt werden kann.
Oft gibt es die Möglichkeit, Daten via Webinterface auf einen Server zu spielen oder
beispielsweise einer E-Mail anzuhängen. Damit die Benutzer nicht mehr als 1 MB
(1024 x 1024 Byte) pro Anfrage an den Server senden können, wäre folgende Anweisung denkbar:
<Location /attach2mail.php>
LimitRequestBodySize 1048576
</Location>
Die Berechnung ist sehr einfach, ein Byte entsprich acht Bit, 1 Kilobyte sind 1024 Byte
und ein Megabyte sind 1024 Kilobyte, d.h. 1048576 Byte. Ein Gigabyte sind dementsprechend 1024 Megabyte, alles klar?
LimitRequestFields
Beschränkt die Anzahl der Felder im HTTP-Header einer Clientanfrage.
Konfigurationsanweisung:
LimitRequestFields
Syntax:
LimitRequestFields Anzahl
Standardwert (Default):
LimitRequestFields 100 (falls vorhanden)
5.2 Basiskonfiguration
227
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit der Konfigurationsoption LimitRequestFields kann der Administrator die Anzahl
der Felder im HTTP-Header einer Clientanfrage beschränken, um Kontrolle über
unerwünschtes Verhalten eines Clients zu erhalten oder einen gewissen Schutz gegen
Denial of Service-Attacken zu haben. Als Parameter wird eine Ganzzahl zwischen 0,
was einer unendlichen Anzahl an Feldern im HTTP-Header einer Clientanfrage entspricht, und 32767 erwartet. Diese Ganzzahl sollte immer größer sein, als die maximal
durch einen Client gesendete Anzahl an Header-Feldern, denn ansonsten erhält der
Client eine entsprechende Fehlermeldung. In der Praxis sollte ein Wert von 20 eigentlich ausreichend sein, es gibt jedoch auch teilweise Clients, die eine größere Anzahl an
Feldern im Header senden. Um die Anzahl der maximal erlaubten Felder im Header
einer Clientanfrage auf 50 zu setzen, benutzen Sie folgende Konfigurationsanweisung:
LimitRequestFields 50
LimitRequestFieldSize
Beschränkt die maximale Größe eines Request-Headers einer Clientanfrage.
Konfigurationsanweisung:
LimitRequestFieldSize
Syntax:
LimitRequestFieldSize Bytes
Standardwert (Default):
LimitRequestFieldSize 8190 (falls vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit dieser Option kann die maximale Größe (in Byte) eines Request-Headers angepasst werden, der Standard- und Maximalwert ist 8190 Byte. Übergibt man bei der
Kompilierung des Apache den Parameter DEFAULT_LIMIT_REQUEST_FIELDSIZE
kann der Maximalwert (und zugleich Standardwert) notfalls geändert werden. Die
Anweisung sieht in der Konfigurationsdatei des Apache wie folgt aus:
LimitRequestFieldSize 8190
Auch diese Option dient, wie eigentlich alle in diesem Teil vorgestellten Optionen,
dem Schutz vor unerwünschten und missgeleiteten Clientanfragen und Denial of Service-Angriffen.
228
5 Konfiguration
LimitRequestLine
Bestimmt die maximale Länge einer Clientanfrage an den Server.
Konfigurationsanweisung:
LimitRequestLine
Syntax:
LimitRequestLine Bytes
Standardwert (Default):
LimitRequestLine 8190 (falls vorhanden)
Enthalten in Modul:
Mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Ruft ein Client beispielsweise eine Datei namens kontakt.html ab, wird in Wirklichkeit
folgendes Kommando an den Server gesendet:
GET kontakt.html HTTP/1.1
Mit der Konfigurationsanweisung LimitRequestLine kann die maximale Länge einer
solchen Anfrage, die ein Client an den Server senden darf, bestimmt werden. Die
Größe wird in Byte angegeben, der Wert muss zwischen 0 und 8190 liegen. Dieser
Standardwert ist zugleich der Maximalwert für die Länge der Anfrage an den Server
und kann bei der Übergabe des Parameters DEFAULT_LIMIT_REQUEST_LINE beliebig geändert werden. Setzen Sie den Wert keinesfalls auf Null oder auf einen sehr
geringen Wert, denn die Clients würden ansonsten eine Fehlermeldung der Art
Request-URI Too Large, Status 414 zurückbekommen. Auch diese Option dient dem
Schutz vor unerwünschten und missgeleiteten Clientanfragen und Denial of ServiceAngriffen. Der Standardwert von 8190 sollte eigentlich nicht geändert werden und es
ergibt sich daraus folgende Anweisung in der httpd.conf:
LimitRequestLine 8190
Limit
Erstellung von Zugriffsbeschränkungen in Abhängigkeit von der verwendeten
HTTP-Methode.
Konfigurationsanweisung:
Limit
Syntax:
<Limit Methode...>...</Limit>
Standardwert (Default):
<Limit GET POST OPTIONS PROPFIND>
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Kontext
Anweisung aktiv:
nein (auskommentiert)
5.2 Basiskonfiguration
229
Normalerweise gelten Zugriffsbeschränkungen, die Sie u.a. mit der Allow-, Denyoder Order-Anweisung definieren können, für alle verwendbaren HTTP-Methoden.
Mit der Limit-Anweisung können Sie dagegen eine Zugriffsbeschränkung erstellen,
die nur für eine (oder auch mehrere) HTTP-Methode(n) gültig ist. Wenn der Zugriff
auf eine Information mit einer nicht in dem <Limit>-Container aufgeführten Methode
erfolgt, werden die Zugriffsbeschränkungen ignoriert. Ein Beispiel:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
In diesem Beispiel gilt die Zugriffsbeschränkung nur für die HTTP-Methoden POST,
PUT und DELETE, alle anderen Methoden sind ungeschützt. Mögliche Methoden
sind GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK und UNLOCK. Sofern die GETMethode angegeben wird, beschränkt dies auch HEAD-Anfragen. Hinweis: Der
Name einer HTTP-Methode muss immer in Großbuchstaben angegeben werden!
LimitExcept
Erstellung von Zugriffsbeschränkungen für alle Methoden außer den aufgeführten.
Konfigurationsanweisung:
LimitExcept
Syntax:
<LimitExcept Methode...>...</LimitExcept>
Standardwert (Default):
<LimitExcept GET POST OPTIONS PROPFIND>
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Kontext
Anweisung aktiv:
nein (auskommentiert)
Der <LimitExcept>-Container (engl. limit = beschränken, except = außer) definiert eine
Zugriffsbeschränkung, die für alle HTTP-Methoden gilt, außer den genannten
Methoden, d.h., diese Anweisung ist das Gegenstück zur Limit-Anweisung. Möglich
ist dabei die Angabe einer oder auch mehrerer HTTP-Methoden, für die eine Zugriffsbeschränkung nicht gelten soll. Ein kleines Beispiel:
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
Dieses Beispiel erfordert eine Authentifizierung für alle Anfragen, die nicht die
POST- oder GET-Methode benutzen. Hinweis: Der Name einer HTTP-Methode muss
immer in Großbuchstaben angegeben werden!
230
5 Konfiguration
LimitXMLRequestBody
Definiert die maximale Größe einer XML-basierten Anfrage.
Konfigurationsanweisung:
LimitXMLRequestBody
Syntax:
LimitXMLRequestBytes Bytes
Standardwert (Default):
LimitXMLRequestBytes 1000000
Enthalten in Modul:
Mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit der Konfigurationsanweisung LimitXMLRequestBody lässt sich die maximale
Länge einer XML-basierten Anfrage, die ein Client an den Server senden darf, bestimmen. Die Größe wird in Byte angegeben, der Standardwert liegt bei 1000000 Byte.
Wenn Sie als maximale Größe 0 angeben, kann eine Anfrage beliebig groß sein. Diese
Option dient dem Schutz vor unerwünschten und missgeleiteten Clientanfragen und
Denial of Service Angriffen. Der Standardwert von 1000000 sollte eigentlich nicht geändert werden und es ergibt sich daraus folgende Anweisung in der httpd.conf:
LimitXMLRequestBody 1000000
SendBufferSize
Definiert die Größe des TCP-Puffers.
Konfigurationsanweisung:
SendBufferSize
Syntax:
SendBufferSize Größe
Standardwert (Default):
Abhängig vom verwendeten Betriebssystem
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Die Anweisung definiert die Größe des TCP-Puffers in Byte. Normalerweise wird als
Standardwert die TCP-Puffergröße des jeweiligen Betriebssystems benutzt, den Sie
unverändert übernehmen sollten. Nur falls Sie ein veraltetes Betriebssystem verwenden und der Server über eine sehr schnelle Anbindung verfügt, sollten Sie die TCPPuffergröße erhöhen. Die Standard- und maximale Größe des TCP-Puffers Ihres
Betriebssystems müssen Sie gegebenenfalls in der Dokumentation nachschlagen oder
direkt beim jeweiligen Hersteller erfragen.
5.2 Basiskonfiguration
231
RLimitCPU
Setzt ein Zeitlimit für Serverprozesse.
Konfigurationsanweisung:
RLimitCPU
Syntax:
RLimitCPU Soft-Limit [Max-Limit]
Standardwert (Default):
Abhängig vom verwendeten Betriebssystem
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess- Kontext
Anweisung aktiv:
nein
Diese Option setzt die Zeit in Sekunden, die ein Serverprozess verbrauchen darf,
bevor er vom System beendet wird. Als Wert für Soft-Limit oder Max-Limit kann auch
max benutzt werden, was dem durch das dem Server zugrundeliegende Betriebssystem gegebenen Maximalwert entspricht. Der hier angegebene Wert in Sekunden gilt
nur für Unterprozesse der Kindprozesse des Apache wie die Ausführung von CGIoder SSI- Skripten und nicht für vom Hauptprozess des Apache ausgeführte Prozesse
wie z.B. Logdateien.
RLimitMEM
Setzt die maximale Speichernutzung eines Serverprozesses.
Konfigurationsanweisung:
RLimitMEM
Syntax:
RLimitMEM Soft-Limit [Max-Limit]
Standardwert (Default):
Abhängig vom verwendeten Betriebssystem
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess- Kontext
Anweisung aktiv:
nein
Die Konfigurationsoption RLimitMEM ist mit der bereits erläuterten Option
RLimitCPU identisch, nur begrenzt die Anweisung RLimitMEM nicht die maximale
CPU-Beanspruchung in Sekunden, sondern die maximale Speichernutzung (MEM)
eines Prozesses. Abermals lässt sich als Wert für die Parameter Soft-Limit und MaxLimit, die übrigens in Byte je Prozess angegeben werden müssen, der Platzhalter max
verwenden, der den durch das Betriebssystem maximal zulässigen Wert der Speichernutzung symbolisiert. Auch hier gilt, dass der angegebene Wert in Bytes nur für
Unterprozesse der Kindprozesse des Apache wie bei der Ausführung von CGI- oder
SSI-Skripten gültig ist und nicht für vom Hauptprozess des Apache ausgeführte Prozesse wie z.B. Logdateien.
232
5 Konfiguration
RLimitNPROC
Bestimmt die maximale Anzahl an Prozessen pro Benutzer.
Konfigurationsanweisung:
RLimitNPROC
Syntax:
RLimitNPROC Soft-Limit [Max-Limit]
Standardwert (Default):
Abhängig vom verwendeten Betriebssystem
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess- Kontext
Anweisung aktiv:
nein
Diese Anweisung ähnelt den bereits vorgestellten Optionen RLimitCPU und RLimitMEM, bestimmt jedoch die maximale Anzahl an Prozessen je Benutzer. Damit ist es
beispielsweise in einer virtuellen Serverumgebung (Stichwort: Massenhosting) möglich, die Anzahl an Prozessen und damit den Umfang der Beanspruchung der Systemressourcen durch einen einzelnen Benutzer zu reglementieren. Um die Prozesse
eindeutig einem Benutzer zuordnen zu können, sollten Sie den suEXEC-Wrapper verwenden, da ansonsten Prozesse mit der Kennung des Hauptnutzers des Webservers
(z.B. wwwrun) ausgeführt werden und nicht mit der Kennung des eigentlich vorgesehenen Benutzers. Die Verwendung der RLimitNPROC-Anweisung wird unter einigen Betriebssystemen leider nicht unterstützt.
ThreadStackSize
Bestimmt die Stackgröße pro Thread.
Konfigurationsanweisung:
ThreadStackSize
Syntax:
ThreadStackSize Bytes
Standardwert (Default):
ThreadStackSize 65536 (falls vorhanden)
Verfügbar in Modul:
mpm_netware (Novell)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Wird die Novell-Plattform verwendet, kann mit dieser Anweisung die Größe des
Stacks je Threads (in Bytes) bestimmt werden. Die Anweisung könnte wie folgt aussehen:
ThreadStackSize 65536
Diese Anweisung ist eine der sehr wenigen Anweisungen, die wirklich nur unter Netware zur Verfügung steht. Der Standardwert beträgt 64 KByte.
5.2 Basiskonfiguration
233
MaxMemFree
Setzt eine Obergrenze für die Speicherbelegung.
Konfigurationsanweisung:
MaxMemFree
Syntax:
MaxMemFree Größe
Standardwert (Default):
nicht vorhanden
Verfügbar in Modul:
mpm_worker, mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Bei Verwendung des Laufzeitmodells (MPM) worker, prefork oder netware setzt
diese Anweisung die maximale Größe des Speichers (in Kbyte), die der Apache belegen darf, bevor dieser den Speicher wieder freigeben muss. Falls die Anweisung den
Wert 0 hat oder überhaupt nicht gesetzt ist, gibt es keine Obergrenze für die maximale Speicherbelegung.
MaxClients
Definiert die maximale Anzahl an Kindprozessen, die vom Hauptprozeß zur Beantwortung von Clientanfragen gestartet wird.
Konfigurationsanweisung:
MaxClients
Syntax:
MaxClients Anzahl
Standardwert (Default):
MaxClients 256
Verfügbar in Modul:
mpm_worker, mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die MaxClients-Anweisung definiert bei der Verwendung eines prozessbasierten
Laufzeitmodells (z.B. prefork) die maximale Anzahl an gleichzeitig laufenden Kindprozessen, die zur Verarbeitung von Clientanfragen erzeugt werden. Damit setzt
diese Anweisung ebenso die maximale Anzahl an parallel durch den Server zu verarbeitenden Clientanfragen. Wenn die maximale Anzahl an Clientanfragen überschritten ist, werden neue Anfragen zwar weiterhin angenommen, aber nicht direkt durch
den Server bearbeitet, sondern in eine Warteschlange gesteckt, bis ein Prozess zur
Bearbeitung der Anfrage zur Verfügung steht. Die maximale Größe dieser Warteschlange legen Sie durch die ListenBackLog-Anweisung fest.
Als Faustregel gilt etwa ein Drittel des verfügbaren Arbeitsspeichers als Obergrenze
für die maximale Anzahl an gleichzeitig laufenden Kindprozessen, so dass ein Server
mit 512 MB RAM beispielsweise folgende Anweisung nutzen könnte:
MaxClients 165
234
5 Konfiguration
Falls der Server für weitere Dienste (z.B. Datenbank oder E-Mail) genutzt wird, sollten
Sie den Wert weiter reduzieren. Die absolute Obergrenze liegt bei 256, aber in vielen
Dokumentationen findet sich ein Wert von 150 für die MaxClients-Anweisung, den ich
auch für ausreichend erachte. Einzig beim Betrieb eines hochfrequentierten Servers sollten Sie den Wert durch Angabe des Compiler-Flag HARD_SERVER_LIMIT bei der
Kompilierung des Apache weiter erhöhen, wobei Sie dazu einen wirklich starken Server (RAM > 1-2 GB) benötigen.
Wenn Sie ein Thread-basiertes Laufzeitmodell für Ihren Server verwenden (z.B. worker), beschränkt die MaxClients-Anweisung die maximale Anzahl an gleichzeitig zur
Verarbeitung von Clientanfragen verfügbaren Threads. Der Standardwert ist 16 multipliziert mit dem Wert der ThreadsPerChild-Anweisung. Falls Sie diesen Wert erhöhen möchten, müssen Sie gleichzeitig den Wert der ServerLimit-Anweisung erhöhen.
MaxRequestsPerChild
Bestimmt die maximale Anzahl an Anfragen, die ein Kindprozess in seinem Leben
verarbeiten soll.
Konfigurationsanweisung:
MaxRequestsPerChild
Syntax:
MaxRequestsPerChild Anzahl
Standardwert (Default):
MaxRequestsPerChild 10000
Verfügbar in Modul:
mpm_worker, mpm_prefork, mpm_perchild
und mpm_winnt
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Mit Hilfe dieser Anweisung können Sie eine maximale Anzahl an Anfragen definieren, die ein Kindprozess in seinem Leben verarbeiten soll. Nachdem ein Kindprozess
die von Ihnen gesetzte Anzahl an Anfragen verarbeitet hat, wird er beendet und ein
neuer Kindprozess gestartet (falls nötig). Wenn Sie den Wert der Anweisung auf 0
setzen, wird das Leben eines Kindprozesses nie erlischen. Ein Beispiel:
MaxRequestsPerChild 5000
Durch die Einstellung wird ein Kindprozess beendet, nachdem er 5000 Anfragen verarbeitet hat. Im Normalfall sollten Sie den Wert der MaxRequestsPerChild-Anweisung
auf 0 setzen, so dass ein Kindprozess niemals beendet wird. Sofern Sie mit Stabilitätsproblemen und Abstürzen des Servers zu kämpfen haben, sollten Sie einen Wert größer 0 verwenden, denn im Falle eines aufgetretenen Fehlers eines externen Moduls
(z.B. nicht freigegebener Speicher) wird der gesamte Server nur minimal beeinträchtigt, da der fehlgeleitete Kindprozess nach einiger Zeit automatisch beendet wird.
Zusätzlich sorgt eine Einstellung größer 0 dafür, dass die Gesamtanzahl an laufenden
Prozessen durch eine maximale Lebenszeit je Prozess reduziert wird, wenn der Server seine Last reduziert. Hinweis: Bei einer persistenten Verbindung zum Server (vgl.
KeepAlive-Anweisung) zählt diese als eine einzige Anfrage, obwohl darüber mehrere
5.2 Basiskonfiguration
235
Anfragen an den Server gestellt werden können. Bei Verwendung von Novell Netware bzw. Microsoft Windows sollten Sie den Wert dieser Anweisung auf 0 setzen
(Voreinstellung).
MaxRequestsPerThread
Limitiert die Anzahl an Anfragen, die ein einzelner Thread während seines Lebens
maximal verarbeiten darf.
Konfigurationsanweisung:
MaxRequestsPerThread
Syntax:
MaxRequestsPerThread Anzahl
Standardwert (Default):
MaxRequestsPerThread 0
Enthalten in Modul:
mpm_beos_module
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Hinweis
Um die Anzahl an Anfragen zu begrenzen, die ein einzelner Thread während seines
Lebens verarbeiten soll, müssen Sie die MaxRequestsPerThread-Anweisung verwenden, wobei ein Thread standardmäßig beliebig viele Anfragen verarbeiten darf und
dessen Lebenszeit somit unbegrenzt ist (Parameter: 0). Wenn die Anzahl der zu bearbeitenden Anfragen begrenzt ist, stirbt ein Thread, sobald er die definierte Anzahl an
Anfragen bearbeitet hat und ein neuer Thread wird erstellt. Generell ist es ratsam, die
Anzahl der durch einen Thread zu verarbeitenden Anfragen und damit dessen
Lebenszeit zu begrenzen, da ein fehlgeleiteter Thread, der beispielsweise aufgrund
eines Programmierfehlers fortlaufend Speicher reserviert, nur minimale Auswirkungen auf die Stabilität des gesamten Servers hat.
Sofern Sie persistente Verbindungen durch die KeepAlive-Anweisung erlaubt
haben, wird nur die erste Anfrage gezählt. Weitere Anfragen, die über diese
dauerhafte Verbindung gesendet werden, werden nicht berücksichtigt.
MaxSpareServers
Setzt eine maximale Anzahl an ungenutzt laufenden Prozessen.
Konfigurationsanweisung:
MaxSpareServers
Syntax:
MaxSpareServers Anzahl
Standardwert (Default):
MaxSpareServers 10
Verfügbar in Modul:
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
ja
236
5 Konfiguration
Diese Anweisung dient zur Definition einer maximalen Anzahl an leer laufenden
Kindprozessen, d.h. solchen Prozessen, die nicht mit der Verarbeitung von Clientanfragen beschäftigt sind. Sofern mehr untätige Prozesse vorhanden sind, als die
durch die MaxSpareServers-Anweisung definierte Obergrenze erlaubt, werden diese
untätigen Kindprozesse durch den Vaterprozess beendet und somit der gesamte Server entlastet. Ein Beispiel:
MaxSpareServers 10
Hinweis
Die Konfiguration sorgt dafür, dass der Server bis zu zehn unbeschäftigte Kindprozesse duldet (Standardeinstellung). Eine Veränderung dieses Wertes ist nur auf hochfrequentierten Systemen (> 1 Millionen Zugriffe/Tag) sinnvoll bzw. wenn Sie mit
einer stark schwankenden Anzahl an Anfragen zu tun haben, die sich zeitlich nicht
genau eingrenzen lassen. In einem solchen Fall ist ein Wert von 50-100 durchaus
angebracht, vorausgesetzt der Server verfügt über genügend Arbeitsspeicher (min.
>1-2 GB).
Wenn Sie die MaxSpareServers-Anweisung auf einen Wert setzen, der niedriger
ist, als der Wert der MinSpareServers-Anweisung, wird der Apache den Wert
automatisch erhöhen (MinSpareServers-Anweisung+1).
MinSpareServers
Setzt eine minimale Anzahl an ungenutzt laufenden Prozessen.
Konfigurationsanweisung:
MinSpareServers
Syntax:
MinSpareServers Anzahl
Standardwert (Default):
MinSpareServers 5
Verfügbar in Modul:
mpm_prefork
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Anweisung ist das Gegenstück zur MaxSpareServer-Anweisung und dient zur
Definition einer minimalen Anzahl an leer laufenden Kindprozessen, d.h. solchen
Prozessen, die nicht mit der Verarbeitung von Clientanfragen beschäftigt sind. Sofern
weniger untätige Prozesse vorhanden sind, als die durch die MinSpareServers-Anweisung definierte Untergrenze erlaubt, werden durch den Vaterprozess des Apache
neue Kindprozesse erzeugt, wobei dieser maximal einen Prozess pro Sekunde angelegt. Ein Beispiel:
MinSpareServers 25
Die Konfiguration sorgt dafür, dass der Server sofort neue Kindprozesse erzeugt,
wenn die Anzahl der unbeschäftigten Kindprozesse unter 25 sinkt. Eine Veränderung
des vorgegebenen Wertes von fünf macht nur auf hochfrequentierten Systemen
5.2 Basiskonfiguration
237
(> 1 Millionen Zugriffe/Tag) Sinn bzw. wenn Sie mit einer stark schwankenden
Anzahl an Anfragen zu tun haben, die sich zeitlich nicht genau eingrenzen lassen. In
einem solchen Fall ist ein Wert von >30 durchaus angebracht, vorausgesetzt der Server verfügt über genügend Arbeitsspeicher (min. >1-2 GB). Andernfalls sollten Sie die
Standardeinstellung verwenden:
MinSpareServers 5
MaxSpareThreads
Setzt eine maximale Anzahl an leer laufenden Threads je Kindprozess.
Konfigurationsanweisung:
MaxSpareThreads
Syntax:
MaxSpareThreads Anzahl
Standardwert (Default):
MaxSpareThreads 10 (für mpm_perchild)
MaxSpareThreads 500 (für mpm_worker)
MaxSpareThreads 100 (für mpm_netware)
Verfügbar in Modul:
mpm_netware, mpm_worker, mpm_perchild
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Diese Anweisung definiert bei Verwendung eines thread-basierten Laufzeitmoduls
(z.B. perchild) eine maximale Anzahl an leer laufenden Threads je Kindprozess, die
momentan nicht mit der Beantwortung von Clientanfragen beschäftigt sind. Sollten
mehr leer laufende Threads in einem Kindprozess vorhanden sein, als die durch die
MaxSpareThreads-Anweisung definierte Obergrenze erlaubt, werden diese untätigen
Threads durch den Server beendet und somit der gesamte Server entlastet. Ein Beispiel:
MaxSpareThreads 10
Die Konfiguration sorgt dafür, dass der Server bis zu zehn unbeschäftigte Threads je
Kindprozess duldet (Standardeinstellung für mpm_perchild). Ein weiteres Beispiel
für das MPM worker:
MaxSpareThreads 500
Dies ist die Standardeinstellung des mpm_worker und sorgt dafür, dass der Server
insgesamt maximal 500 leer laufende Threads duldet. Sollte die Anzahl der leer laufenden Threads über 500 steigen, werden einzelne Kindprozesse, die eine durch die
ThreadsPerChild-Anweisung definierte (feste) Anzahl an Threads verwenden, beendet, bis die Anzahl der leer laufenden Threads unter die maximale Obergrenze (hier:
500) sinkt. Ein allerletztes Beispiel dazu:
MaxSpareThreads 100
238
5 Konfiguration
Hinweis
Mit Hilfe dieser Standardeinstellung des mpm_netware erlaubt der Server die Existenz von maximal 100 ungenutzten Threads. Sollten mehr Threads vorhanden sein,
werden diese einzeln beendet.
Der Wert der MaxSpareThreads-Anweisung ist eingeschränkt und kann nicht
beliebig gewählt werden, d.h. der Apache korrigiert den von Ihnen gewählten
Wert unter Umständen. Generell gilt, dass das MPM perchild für die Anweisung MaxSpareThreads einen Wert erwartet, der gleich (bzw. kleiner) mit dem
Wert der Anweisung ThreadLimit ist. Bei Verwendung des mpm_netware muss
der Wert von MaxSpareThreads größer sein, als der der MinSpareThreads-Anweisung. Schließlich verlangen die Laufzeitmodelle leader, threadpool und worker,
dass der Wert der MaxSpareThreads-Anweisung größer bzw. gleich der Summe
der Werte der MinSpareThreads- und ThreadsPerChild-Anweisung ist.
MinSpareThreads
Setzt eine minimale Anzahl an leer laufenden Threads je Kindprozess.
Konfigurationsanweisung:
MinSpareThreads
Syntax:
MinSpareThreads Anzahl
Standardwert (Default):
MinSpareThreads 5 (für mpm_perchild)
MinSpareThreads 250 (für mpm_worker)
MinSpareThreads 10 (für mpm_netware)
Verfügbar in Modul:
mpm_netware, mpm_worker, mpm_perchild
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Anweisung ist das Gegenstück zur MaxSpareThreads-Anweisung und dient zur
Definition einer minimalen Anzahl an leer laufenden Threads je Kindprozess, d.h.
solchen Threads, die nicht mit der Verarbeitung von Clientanfragen beschäftigt sind.
Falls weniger untätige Threads je Kindprozess vorhanden sind, als die durch die
MinSpareThreads-Anweisung definierte Untergrenze erlaubt, werden durch den Apache neue Threads innerhalb eines Kindprozesses erzeugt. Ein Beispiel:
MinSpareThreads 5
Die Konfiguration (Standardeinstellung des mpm_perchild) sorgt dafür, dass der Server sofort neue Threads erzeugt, wenn die Anzahl der unbeschäftigten Threads je
Kindprozess unter fünf sinkt, d.h. die Anzahl der minimal verfügbaren Threads entspricht bei Verwendung des MPM perchild dem Produkt der NumServers- und
MinSpareThreads-Anweisung. Wenn Sie beispielsweise den Wert der Konfigurationsanweisung NumServers und MinSpareThreads auf 5 setzen, stehen Ihnen zur Beantwortung von Clientanfragen 25 unbeschäftigte Threads zur Verfügung.
5.2 Basiskonfiguration
239
Bei Verwendung der Laufzeitmodelle worker, leader oder threadpool gilt der definierte Wert serverweit:
MinSpareThreads 75
Dies ist die Standardeinstellung des mpm_worker und sorgt dafür, dass der Server
minimal 75 leer laufende Threads erzeugt. Sollte die Anzahl der leer laufenden
Threads unter 75 sinken, werden einzelne Kindprozesse erzeugt, die eine durch die
ThreadsPerChild-Anweisung definierte (feste) Anzahl an Threads starten, bis die Mindestanzahl an leer laufenden Threads erreicht ist. Das letzte Beispiel:
MinSpareThreads 10
Mit Hilfe dieser Standardeinstellung des mpm_netware erwartet der Server das Vorhandensein von minimal 10 ungenutzten Threads. Sollten weniger Threads vorhanden sein, werden einzelne Threads durch den einfach strukturierten Hauptprozess
gestartet.
MaxThreads
Definiert bei Verwendung des MPM netware eine maximale Obergrenze an erlaubten
Threads.
Konfigurationsanweisung:
MaxThreads
Syntax:
MaxThreads Anzahl
Standardwert (Default):
MaxThreads 250
Verfügbar in Modul:
mpm_netware
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die MaxThreads-Anweisung definiert bei Verwendung des MPM netware eine maximale Obergrenze an erlaubten Threads und bestimmt somit die maximale Anzahl an
gleichzeitig durch den Server zu verarbeitenden Clientanfragen (vgl. MaxClientsAnweisung). Sollten Sie eine sehr große Anzahl an gleichzeitigen Anfragen auf Ihrem
Server haben, sollten Sie den Wert, je nach Größe des Arbeitsspeichers des Systems, auf
bis zu 2048 erhöhen. Sofern Sie einen noch höheren Wert wünschen, müssen Sie diesen
bei der Kompilierung des Apache mit dem Compiler-Flag HARD_THREAD_LIMIT
setzen.
MaxThreadsPerChild
Setzt eine maximale Anzahl an erlaubten Threads pro Kindprozess.
Konfigurationsanweisung:
MaxThreadsPerChild
Syntax:
MaxThreadsPerChild Anzahl
Standardwert (Default):
MaxThreadsPerChild 64
240
5 Konfiguration
Verfügbar in Modul:
mpm_perchild, mpm_worker
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Bei Verwendung eines thread-basierten Laufzeitmodells (mpm_perchild oder
mpm_worker) mit einer variablen Anzahl an Threads je Kindprozess definiert diese
Anweisung die maximale Anzahl an Threads, die je Kindprozess überhaupt erzeugt
werden können. Ein Beispiel:
MaxThreadsPerChild 64
Diese Konfiguration ist der Standardwert der MaxThreadsPerChild-Anweisung und
gleichzeitig deren Maximalwert. Sofern Sie einen noch höheren Wert wünschen, müssen Sie diesen bei der Kompilierung des Apache mit dem Compiler-Flag
HARD_THREAD_LIMIT setzen und gleichzeitig den Wert der ThreadLimit-Anweisung erhöhen.
NumServers
Bestimmt für das MPM perchild eine maximale Anzahl an gleichzeitig verfügbaren
Kindprozessen .
Konfigurationsanweisung:
NumServers
Syntax:
NumServers Anzahl
Standardwert (Default):
NumServers 2
Verfügbar in Modul:
mpm_perchild
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Anweisung definiert für das MPM perchild eine maximale Anzahl an gleichzeitig
laufenden Kindprozessen. Ein Beispiel:
NumServers 2
Diese Konfiguration bewirkt, dass gleichzeitig zwei Kindprozesse gestartet werden,
die wiederum eine Vielzahl von Threads starten (vgl. MaxThreadsPerChild-Anweisung). Da sich die maximale Anzahl an gleichzeitig verarbeitbaren Clientanfragen
durch die Multiplikation der Anzahl der Kindprozesse mit der Anzahl der verfügbaren Threads ergibt, halte ich diesen Wert für zu gering. Sofern Sie eine größere Internetseite oder viele virtuelle Server bereitstellen, rate ich mindestens zu folgender Einstellung:
NumServers 5
5.2 Basiskonfiguration
241
Durch diese Anweisung werden fünf Kindprozesse gestartet, die eine durch die MaxThreadsPerChild-Anweisung definierte Anzahl an Threads starten. Wenn Ihr Server
über ausreichend (>1-2 GB) Arbeitsspeicher verfügt, sollten Sie mit dieser Einstellung
eine befriedigende Anzahl an gleichzeitigen Clientanfragen verarbeiten können. Hinweis: Falls Sie einen Wert größer 8 verwenden möchten, müssen Sie ebenfalls den
Wert der ServerLimit-Anweisung ändern und den Server komplett neustarten.
ServerLimit
Setzt eine Obergrenze für die Anzahl an Prozessen.
Konfigurationsanweisung:
ServerLimit
Syntax:
ServerLimit Anzahl
Standardwert (Default):
ServerLimit 256 (mpm_prefork)
ServerLimit 16 (mpm_worker)
Verfügbar in Modul:
mpm_prefork, mpm_worker, mpm_perchild,
mpm_threadpool, mpm_leader
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Für das Modul mpm_prefork setzt diese Direktive eine absolute Obergrenze an
gleichzeitig ausgeführten Kindprozessen zur Verarbeitung von Clientanfragen (vgl.
MaxClients-Anweisung). Bei Verwendung des mpm_worker definiert diese Anweisung eine absolute Obergrenze an gleichzeitig ausgeführten Threads. Bitte beachten
Sie, dass eine Veränderung dieser Anweisung einen kompletten Stop sowie anschließenden Start (kein Neustart!) des Servers erfordert. Außerdem müssen Sie bei der
Verwendung dieser Anweisung besonders vorsichtig sein, denn falls das maximale
Limit des Servers zu hoch gesetzt wird, wird unbenutzter Speicher reserviert, was
unnötig die Performance des Servers senkt. Zusätzlich kann der Server instabil laufen
oder eventuell überhaupt nicht starten, wenn die Werte der ServerLimit- und MaxClients-Anweisung für Ihr System zu hoch definiert sind.
Generell gilt, dass Sie die ServerLimit-Anweisung nur verwenden müssen, wenn Sie
bei der Benutzung des mpm_prefork den Wert der MaxClients-Anweisung größer als
256 (Kindprozesse) definieren möchten. In diesem Fall sollte die maximale Grenze
des Servers (ServerLimit) mit dem Wert der MaxClients-Anweisung identisch sein. Ein
Beispiel:
Hinweis
MaxClients 350
ServerLimit 350
Eine derart hohe Einstellung kann nur benutzt werden, wenn der Apache mit
dem Compiler-Flag HARD_SERVER_LIMIT entsprechend modifiziert worden
ist. Zusätzlich benötigen Sie für eine solche Konfiguration mindestens 1 GB
Arbeitsspeicher (besser 2 GB).
242
5 Konfiguration
Für das mpm_worker sollten Sie die ServerLimit-Anweisung nur verwenden, wenn
Sie den Wert der MaxClients- und ThreadsPerChild-Anweisung über 16 erhöhen wollen. Auch in diesem Fall sollte die maximale Grenze des Servers (ServerLimit) mit dem
Wert der MaxClients- und ThreadsPerChild-Anweisung identisch sein. Ein Beispiel:
Hinweis
MaxClients 32
ServerLimit 32
Sie benötigen für eine derartige Konfiguration mindestens 1 GB Arbeitsspeicher
(besser 2 GB).
StartServers
Definiert die Anzahl an Kindprozessen, die beim Start des Apache erzeugt werden
sollen.
Konfigurationsanweisung:
StartServers
Syntax:
StartServers Anzahl
Standardwert (Default):
StartServers 3 (mpm_leader,
mpm_threadpool, mpm_worker)
StartServers 5 (mpm_prefork)
StartServers 2 (mpmt_os2)
Verfügbar in Modul:
mpm_worker, mpm_leader, mpm_prefork,
mpmt_os2, mpm_threadpool
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Anweisung definiert u.a. für das MPM worker eine Anzahl an Kindprozessen,
die beim Start des Servers erzeugt werden sollen. Ein Beispiel:
StartServers 2
Diese Konfiguration bewirkt, dass gleichzeitig zwei Kindprozesse gestartet werden,
die wiederum eine Vielzahl von Threads starten (vgl. MaxThreadsPerChild-Anweisung). Da sich die maximale Anzahl an gleichzeitig verarbeitbaren Clientanfragen
durch die Multiplikation der Anzahl der Kindprozesse mit der Anzahl der verfügbaren Threads ergibt, halte ich diesen Wert für zu gering. Sofern Sie eine größere Internetseite oder viele virtuelle Server bereitstellen, rate ich zu folgender Einstellung:
StartServers 5
Durch diese Anweisung werden fünf Kindprozesse gestartet, die eine durch die MaxThreadsPerChild-Anweisung definierte Anzahl an Threads starten. Wenn Ihr Server
über genügend (>1-2 GB) Arbeitsspeicher verfügt, sollten Sie mit dieser Einstellung
eine ausreichende Anzahl an Clientanfragen verarbeiten können.
5.2 Basiskonfiguration
243
StartThreads
Definiert die Anzahl an Threads, die beim Start des Apache erzeugt werden sollen.
Konfigurationsanweisung:
StartThreads
Syntax:
StartThreads Anzahl
Standardwert (Default):
StartThreads 5 (für mpm_perchild)
StartThreads 50 (für mpm_netware)
StartThreads 10 (für mpm_beos)
Verfügbar in Modul:
mpm_netware, mpm_perchild, mpm_beos
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Diese Anweisung definiert für das MPM netware bzw. perchild die Anzahl an
Threads je Kindprozess, die beim Start des Apache erzeugt werden sollen. Ein Beispiel:
StartThreads 5
Die Standardeinstellung des mpm_perchild sorgt dafür, dass fünf Threads je Kindprozess beim Start des Apache erzeugt werden. Die Anzahl der Kindprozesse, die der
Vaterprozess des Apache beim Start erzeugen soll, wird durch die NumServersAnweisung bestimmt. Die Standardeinstellung des mpm_netware lautet:
StartThreads 50
Da es sich bei dem mpm_netware um einen einzelnen Prozess handelt, definiert dieser Parameter die Gesamtanzahl an Threads, die zur Verarbeitung von Clientanfragen insgesamt zur Verfügung stehen.
ThreadLimit
Setzt eine Obergrenze für die maximale Anzahl an Threads je Kindprozess.
Konfigurationsanweisung:
ThreadLimit
Syntax:
ThreadLimit Anzahl
Standardwert (Default):
ThreadLimit 64 (für mpm_worker)
ThreadLimit 1920 (für mpm_winnt)
Verfügbar in Modul:
mpm_winnt, mpm_worker
Kontext:
Server-Kontext
Anweisung aktiv:
ja
244
5 Konfiguration
Diese Anweisung ist prinzipiell mit der ServerLimit-Anweisung identisch, allerdings
dient sie in einer thread-basierten Umgebung zur Definition der maximalen Anzahl
an Threads je Kindprozess. Bitte beachten Sie, dass eine Veränderung dieser Anweisung einen kompletten Stop sowie anschließenden Start (kein Neustart!) des Servers
erfordert. Außerdem müssen Sie bei der Verwendung dieser Anweisung besonders
vorsichtig sein, denn falls das maximale Limit des Servers (ThreadLimit) zu hoch
gesetzt wird, wird unbenutzter Speicher reserviert, was unnötig die Performance des
Servers senkt. Zusätzlich kann der Server instabil laufen oder eventuell überhaupt
nicht starten, wenn die Werte der ThreadLimit- und ThreadsPerChild-Anweisung für
Ihr System zu hoch definiert sind.
Generell gilt, dass Sie die ThreadLimit-Anweisung mit dem Wert der ThreadsPerChildAnweisung identisch sein sollte. Ein Beispiel:
ThreadsPerChild 25
ThreadLimit 25
Diese Konfiguration erlaubt die Existenz von maximal 25 Threads je Kindprozess.
ThreadsPerChild
Definiert die Anzahl an Threads je Kindprozess, die beim Start des Apache erzeugt
werden sollen.
Konfigurationsanweisung:
ThreadsPerChild
Syntax:
ThreadsPerChild Anzahl
Standardwert (Default):
ThreadsPerChild 25 (für mpm_worker)
ThreadsPerChild 64 (für mpm_winnt)
Verfügbar in Modul:
mpm_winnt, mpm_worker, mpm_leader,
mpm_threadpool
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Anweisung definiert u.a. bei Verwendung des mpm_worker oder mpm_winnt
die Anzahl an Threads, die beim Start des Apache durch jeden Kindprozess erzeugt
werden sollen. Ein Beispiel für mpm_winnt (Standardeinstellung):
ThreadsPerChild 64
Da auf Windows-basierten Systemen nur ein Kindprozess existiert, stellt dieser Wert
gleichzeitig die maximale Anzahl an Clientanfragen dar, die der Server simultan
bedienen kann. Sofern Ihr Server über ausreichend Arbeitsspeicher verfügt, sollten
Sie diesen Wert unbedingt erhöhen. Ein anderes Beispiel für mpm_worker (Standardeinstellung):
ThreadsPerChild 25
5.2 Basiskonfiguration
245
Bei Verwendung des mpm_worker, mpm_leader oder mpm_threadpool werden
durch diese Einstellung beim Start des Servers durch jeden Kindprozess 25 Threads
erzeugt, ein Wert, der für kleinere Internetseiten durchaus ausreichend sein dürfte.
Sofern Sie eine größere Anzahl an Zugriffen haben oder viele virtuelle Server betreiben, sollten Sie den Wert entsprechend erhöhen (genügend Arbeitsspeicher vorausgesetzt).
5.2.6
Dateien und Verzeichnisse
In der Praxis müssen Administratoren die globale Konfiguration für einzelne Verzeichnisse oder Dateien durch Angabe eigener Konfigurationsanweisungen
beschränken, da diese beispielsweise wichtige Daten enthalten, die einem besonderen
Schutz bedürfen. Sie haben deshalb die Möglichkeit, eine beliebige Anzahl an Konfigurationsanweisungen für Verzeichnisse, URLs und Dateien zu gruppieren. In diesem Zusammenhang spricht man auch von einem Container, der für einen bestimmten Teil des Servers (z.B. Verzeichnisse, Dateien, URLs) eine besondere Konfiguration
ermöglicht, die losgelöst von der übergeordneten Konfiguration funktioniert und nur
für die Daten gilt, die innerhalb des Containers gespeichert sind. Dabei muss der
Beginn und das Ende eines Konfigurationscontainers besonders gekennzeichnet werden, wie folgendes (allgemeine) Beispiel zeigt:
<Anweisung>
...
</Anweisung>
Die Kennzeichnung ist HTML- bzw. XML-ähnlich und bezeichnet den Beginn einer
Gruppierung von Anweisungen (<Anweisung>) und das Ende (</Anweisung>)
einer solchen Gruppierung. Es stehen Ihnen in diesem Zusammenhang die folgenden
Konfigurationsanweisungen zur Verfügung:
Directory
Gruppiert eine Anzahl an Konfigurationsanweisungen für ein zu bestimmendes Verzeichnis.
Konfigurationsanweisung:
Directory
Syntax:
<Directory Pfad>...</Directory>
Standardwerte (Default):
<Directory »/usr/local/apache2/htdocs«>
(mehrfach vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Mit einem <Directory>-Container können Sie eine Gruppe an Konfigurationsanweisungen definieren, die nur für ein von Ihnen zu definierendes Verzeichnis (und dessen Unterverzeichnisse!) gelten sollen. Innerhalb dieses Containers können Sie jede
246
5 Konfiguration
Konfigurationsanweisung benutzen, die innerhalb eines <Directory>-Containers
benutzt werden darf. Als einzigen Parameter erwartet die Anweisung die Angabe
eines Verzeichnispfades, für den die gruppierten Konfigurationsanweisungen gelten
sollen. Dabei muss die Verzeichnisangabe in absoluter Form erfolgen und sollte,
sofern diese Leerzeichen enthält, durch Anführungszeichen umschlossen werden:
<Directory /usr/local/apache2/htdocs>
Options Indexes FollowSymLinks
</Directory>
Dieser Container schaltet für ein Verzeichnis namens /usr/local/apache2/htdocs die Optionen Indexes und FollowSymLinks ein (vgl. Options-Anweisung). Hinweis: Diese Optionen gelten übrigens auch für alle Unterverzeichnisse von /usr/local/apache2/htdocs! Wenn
Sie die vorgenommenen Konfigurationsanweisungen für bestimmte Unterverzeichnisse deaktivieren möchten, müssen Sie weitere Container definieren. Zur besseren
Übersicht sollten Sie die in Konfigurationscontainern angegebenen Anweisungen einrücken, so wie ich das in dem vorgestellten Beispiel getan habe.
Neben der Angabe eines absoluten Pfades ermöglicht die <Directory>-Anweisung
auch die Benutzung von Pfadmustern zur Übereinstimmung mit mehreren Verzeichnissen. Innerhalb eines solchen Musters entspricht das Fragezeichen (»?«) genau
einem beliebigen Zeichen und das Sternchen (»*«) einem oder auch keinem Zeichen.
Sogar einzelne Zahlen- oder Zeichenbereiche können durch Angabe von eckigen
Klammern zusammengefasst werden und auch die Verwendung von einfachen regulären Ausdrücken ist durch eine vorangestellte Tilde möglich.
Dazu möchte ich Ihnen kurz einige Beispiele vorstellen:
<Directory "/usr/local/apache2/htdocs/logs">
...
</Directory>
Diese Anweisungen definieren einen Container für das Verzeichnis /usr/local/
apache2/htdocs/logs. Innerhalb dieses Containers könnten Sie jetzt beliebige Konfigurationsanweisungen (ausgedrückt durch die drei Punkte) für dieses spezielle Verzeichnis vornehmen, die nur für dieses eine Verzeichnis gelten würden, sofern die Verwendung der von Ihnen benutzten Konfigurationsanweisungen überhaupt innerhalb
eines <Directory>-Containers zulässig ist. Ein weiteres Beispiel:
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
Diese Anweisungen gelten für das Root-Verzeichnis des Dateisystems (»/«) mit allen
Unterverzeichnissen. Es verbietet die Angabe weiterer Konfigurationsanweisungen
in .htaccess-Dateien (vgl. AllowOverride- Anweisung) und erlaubt die Verfolgung von
symbolischen Verweisen. Sofern Sie keine symbolischen Verweise benutzen, können
Sie die Rechte für das Wurzelverzeichnis des Systems noch restriktiver setzen:
5.2 Basiskonfiguration
247
<Directory />
Options None
AllowOverride None
</Directory>
Generell ist es ratsam, zunächst jegliche Optionen zu verbieten, bevor Sie für einzelne
Verzeichnisse bestimmte Optionen wieder explizit erlauben.
Einige Beispiele zur Verwendung von Zahlen- und Zeichenbereichen innerhalb eines
<Directory>-Containers:
<Directory "/home/[a-c]">
...
</Directory>
<Directory "/home/pe*">
...
</Directory>
<Directory "/home/m??er">
...
</Directory>
<Directory "/home/*/public_html">
...
</Directory>
Anmerkung: Die drei Punkte symbolisieren beliebige Konfigurationsanweisungen,
die innerhalb eines Containers definiert werden können. Die erste <Directory>Anweisung erzeugt einen Container, der die Verzeichnisse /home/a, /home/b und
/home/c umfasst. Das zweite Beispiel definiert einen Container, der alle Verzeichnisse
unterhalb des Verzeichnisses /home umfasst, die mit der Zeichenkette pe beginnen
und mit beliebigen Zeichen enden (z.B. /home/peter oder /home/pedro). Das vorletzte
Beispiel ist sehr interessant, denn es erzeugt einen Container für alle Verzeichnisse
unterhalb von /home, deren Name mit dem kleingeschriebenen Buchstaben m beginnt,
gefolgt von zwei beliebigen Zeichen und mit der Zeichenkette er endet (z.B.
/home/meyer, /home/meier, /home/mayer). Das vierte und zugleich letzte Beispiel generiert durch das Sternchen (*) einen Container für alle Unterverzeichnisse namens
public_html im Heimatverzeichnis jedes einzelnen Benutzers (z.B. /home/pete/
public_html, /home/sebi/public_html, /home/franz/public_html, /home/ursula/public_html).
Nachfolgend möchte ich Ihnen noch die Verwendung von regulären Ausdrücken mit
einer <Directory>-Anweisung vorstellen:
<Directory ~ "^/home/.*/[a-z]{4}">
...
</Directory>
Reguläre Ausdrücke müssen in einer <Directory>-Anweisung durch eine vorangestellte Tilde gekennzeichnet und mit Anführungszeichen umschlossen werden. Der
vorgestellte reguläre Ausdruck (vgl. Anhang) in einer <Directory>-Anweisung sorgt
dafür, dass für jedes Verzeichnis unterhalb von /home ein Container erzeugt wird,
sofern dieses Verzeichnis aus vier Buchstaben von a bis z besteht (z.B. /home/sebi,
/home/pete, /home/alex, /home/andy).
248
5 Konfiguration
DirectoryMatch
Gruppiert eine Anzahl an Konfigurationsanweisungen für ein mit Hilfe eines regulären Ausdrucks zu bestimmendes Verzeichnis.
Konfigurationsanweisung:
DirectoryMatch
Syntax:
<DirectoryMatch Ausdruck>...</DirectoryMatch>
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die Konfigurationsanweisung <DirectoryMatch> ist mit der <Directory>-Anweisung
funktional identisch, allerdings erwartet diese Anweisung, wie alle Direktiven mit
dem Wort »Match« im Namen, als einzigen Parameter einen regulären Ausdruck
zum Aufbau eines Verzeichniscontainers. Zwar ist in einer <Directory>-Anweisung
die Verwendung eines regulären Ausdrucks möglich, aber ursprünglich ist dazu die
Benutzung der <DirectoryMatch>-Anweisung vorgesehen. Ein Beispiel:
<DirectoryMatch "^/home/.*/[a-z]{4}">
...
</DirectoryMatch>
Diese Anweisungen erzeugen einen Verzeichniscontainer für alle Verzeichnisse
unterhalb des Verzeichnisses /home, die aus vier Buchstaben von a bis z bestehen (z.B.
/home/sebi, /home/pete, /home/alex, /home/andy). Ein weiteres Beispiel:
<DirectoryMatch "^/home/(sebi|peter|hans|franz)">
...
</DirectoryMatch>
Diese Anweisung definiert einen Verzeichniscontainer, der die Verzeichnisse
/home/sebi, /home/peter, /home/hans und /home/franz umfasst. Findige Leser werden
wahrscheinlich jetzt aufschreien und völlig zu Recht argumentieren, dass ein senkrechter Strich in einem regulären Ausdruck normalerweise für ein logisches Oder
steht und nicht für ein logisches Und. Damit haben Sie auch vollkommen recht, denn
ein senkrechter Strich steht in einem regulären Ausdruck wirklich für das logische
Oder und erzeugt deshalb einen Container für eines der folgenden Verzeichnisse:
/home/sebi
/home/peter
/home/hans
/home/franz
Der Container entspricht eigentlich einem der aufgeführten Verzeichnisse (logisches
Oder), kann allerdings auch mehrfach Anwendung finden, was dazu führt, dass die
einzelnen Verzeichnisse zu einer logischen Einheit miteinander verknüpft werden.
5.2 Basiskonfiguration
249
Wenn man also ein Verzeichnis des Containers alleine und lösgelöst von den anderen
Verzeichnissen betrachtet, handelt es sich um eine logische Oder-Verknüpfung.
Betrachtet man alle Verzeichnisse des Containers in ihrer Gesamtheit, handelt es sich
dabei um eine logische Und-Verknüpfung.
Files
Gruppiert eine Anzahl an Konfigurationsanweisungen für zu benennende Dateien.
Konfigurationsanweisung:
Files
Syntax:
<Files Dateiname>...</Files>
Standardwerte (Default):
<Files ~ »^\.ht«>
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>-Container, <Location>-Container, .htaccess
Anweisung aktiv:
ja
Mit einem <Files>-Container können Sie eine Gruppe an Konfigurationsanweisungen
definieren, die nur für eine oder mehrere Dateien gelten sollen. Dabei ist die Syntax
mit der der <Directory>-Anweisung soweit identisch und innerhalb dieses Container
können Sie jede Konfigurationsanweisung benutzen, die in einem <Files>-Containers
benutzt werden darf. Zusätzlich können Sie eine <Files>-Anweisung beispielsweise
innerhalb einer <Directory>-, <DirectoryMatch>- und <Location>- bzw. <LocationMatch>-Anweisung benutzen.
Als einzigen Parameter erwartet die Anweisung die Angabe eines Dateinamens, für
den die gruppierten Konfigurationsanweisungen gelten sollen. Dabei muss die
Angabe in relativer Form erfolgen und sollte, sofern diese Leerzeichen enthält, durch
Anführungszeichen umschlossen werden:
<Files beispiel.html>
order deny,allow
deny from all
allow from .beispiel.de
</Files>
Diese Anweisung erzeugt einen Container für die Datei beispiel.html, der den Zugriff
auf diese Datei nur Clients innerhalb der Domain beispiel.de erlaubt. Zur besseren
Übersicht sollten Sie die in Konfigurationscontainern angegebenen Anweisungen einrücken, so wie ich das in dem vorgestellten Beispiel getan habe. Eine <Files>-Anweisung kann auch wunderbar in eine übergeordnete <Directory>-Anweisung eingebaut
werden:
<Directory "/usr/local/apache2/htdocs/daten">
<Files beispiel.html>
order deny,allow
deny from all
250
5 Konfiguration
allow from .beispiel.de
</Files>
</Directory>
Diese Anweisung würde einen Zugriff auf eine Datei namens beispiel.html aus dem
Verzeichnis /usr/local/apache2/htdocs/daten nur erlauben, wenn dieser Zugriff aus
einem beliebigen Teilnehmer der Domain beispiel.de erfolgt.
Neben der Angabe eines relativen Dateipfades ermöglicht die <Files>-Anweisung
auch die Benutzung von einfachen regulären Ausdrücken, wobei dies durch eine vorangestellte Tilde möglich ist.
Dazu möchte ich Ihnen kurz einige Beispiele vorstellen:
<Files *.html>
...
</Files>
Diese Anweisung erklärt einen Container für alle Dateien mit der Endung .html im
aktuellen Verzeichnis. Innerhalb des Containers könnten Sie jetzt beliebige Konfigurationsanweisungen (ausgedrückt durch die drei Punkte) für diese Dateien vornehmen, die nur für .html-Dateien gelten würden, sofern die Verwendung der von Ihnen
benutzten Konfigurationsanweisungen überhaupt innerhalb eines <Files>-Containers
zulässig ist. Ein weiteres Beispiel:
<Files "b*.html">
Order deny,allow
deny from all
allow from 192.168
</Files>
Diese Anweisungen führen dazu, dass alle Dateien mit der Endung .html, deren
Name mit dem Buchstaben b beginnt, nur aus dem Netzwerkbereich 192.168 abrufbar
sind.
Nachfolgend möchte ich Ihnen noch die Verwendung von regulären Ausdrücken mit
einer <Files>-Anweisung vorstellen:
<Files ~ "\.(gif|jpe?g|png)$">
...
</Files>
Reguläre Ausdrücke müssen in einer <Files>-Anweisung durch eine vorangestellte
Tilde gekennzeichnet und mit Anführungszeichen umschlossen werden. Der vorgestellte reguläre Ausdruck (vgl. Anhang) in einer <Files>-Anweisung sorgt dafür, dass
für alle Dateien mit der Endung .gif, .jpg, .jpeg und .png ein Container erzeugt wird.
Interessant ist dabei die Verwendung des Fragezeichens, da dieses dafür sorgt, dass
der Buchstabe e im Suchwort jpeg vorkommen kann, aber nicht unbedingt muss, so
dass auch Dateien mit der Endung .jpg durch den Container abgedeckt werden.
5.2 Basiskonfiguration
251
FilesMatch
Gruppiert eine Anzahl an Konfigurationsanweisungen für mit Hilfe von regulären
Ausdrücken zu bestimmende Dateien.
Konfigurationsanweisung:
FilesMatch
Syntax:
<FilesMatch Ausdruck>...</FilesMatch>
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, .htaccess
Anweisung aktiv:
nein
Die Konfigurationsanweisung <FilesMatch> ist mit der <Files>-Anweisung funktional
identisch, allerdings erwartet diese Anweisung (wie alle Optionen mit dem Wort
»Match« im Namen) als einzigen Parameter einen regulären Ausdruck zum Aufbau
eines Dateicontainers. Zwar ist in einer <Files>-Anweisung die Verwendung eines
regulären Ausdrucks möglich, aber ursprünglich ist dazu die Benutzung der <FilesMatch>-Anweisung vorgesehen. Ein Beispiel:
<FilesMatch "\.(html|htm|php|jsp)$">
...
</FilesMatch>
Diese Anweisung erzeugt einen Dateicontainer für alle Dateien im aktuellen Verzeichnis, deren Endung .html, .htm, .php oder .jsp lautet. Natürlich können Sie auch
eine <FilesMatch>-Anweisung in einen <Directory>- oder <Location>-Container einbauen:
<Directory "/usr/local/apache2/htdocs/dev">
<FilesMatch "\.(html|htm|php|jsp)$">
order deny,allow
deny from all
allow from development.beispiel.de
</FilesMatch>
</Directory>
Diese Anweisungen beschränken den Zugriff auf Dateien mit der Endung .html, .htm,
.php oder .jsp im Verzeichnis /usr/local/apache2/htdocs/dev und lassen diesen nur zu,
wenn der Zugriff von der Adresse development.beispiel.de erfolgt.
Ein weiteres Beispiel zur Verwendung der FilesMatch-Anweisung ist folgendes:
<FilesMatch \.exe$>
Order deny,allow
Deny from all
</FilesMatch>
252
5 Konfiguration
Mit Hilfe dieser Konfiguration könnte man beispielsweise das Herunterladen von
sämtlichen .exe-Dateien vom Server unterbinden. Selbstverständlich könnte man
diese Aufgabe auch durch eine entsprechende Files-Anweisung erledigen, wobei mir
die Verwendung der FilesMatch-Anweisung einfacher erscheint.
Location
Gruppiert eine Anzahl an Konfigurationsanweisungen für einen URL-Pfad.
Konfigurationsanweisung:
Location
Syntax:
<Location Url-Pfad>...</Location>
Standardwerte (Default):
#<Location /server-status> (mehrfach
vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein (auskommentiert)
Die Konfigurationsanweisung <Location> ist mit den Anweisungen <Directory> und
<Files> funktional identisch und dient ebenfalls dazu, Konfigurationsanweisungen
zu gruppieren. Dabei bezieht sich die <Location>-Anweisung nicht auf Dateien oder
Verzeichnisse, sondern auf URL-Pfade (z.B. www.beispiel.de/downloads/). Die Syntax ist
mit dem der <Directory>- bzw. <Files>-Anweisung soweit identisch und innerhalb
dieses Containers können Sie jede Konfigurationsanweisung benutzen, die in einem
<Location>-Container benutzt werden darf. Hinweis: Eine <Location>-Anweisung
sollte immer für Verzeichnisse oder URL-Pfade benutzt werden, die innerhalb des als
DocumentRoot definierten Verzeichnisses (z.B. /usr/local/apache2/htdocs) liegen. Sobald
Sie auf Verzeichnisse außerhalb des als DocumentRoot definierten Verzeichnisses
zugreifen wollen, müssen Sie eine <Directory>- bzw. <Files>-Anweisung benutzen!
Der einzige Parameter der <Location>-Anweisung ist die Angabe eines URL-Pfades,
für den ein Container erzeugt werden soll. Ein Beispiel:
<Location /daten>
order deny,allow
deny from all
allow from .beispiel.de
</Location>
Diese Anweisung erzeugt einen Container für den URL-Pfad /daten und erlaubt den
Zugriff auf diesen Pfad nur für Teilnehmer der Domain beispiel.de.
Neben der Angabe eines relativen Dateipfades ermöglicht die <Location>-Anweisung
auch die Benutzung von einfachen regulären Ausdrücken, wobei diese durch eine
vorangestellte Tilde kenntlich gemacht werden müssen.
Dazu möchte ich Ihnen kurz einige Beispiele vorstellen:
<Location ~ "/(daten|privat)">
...
</Location>
5.2 Basiskonfiguration
253
Diese Anweisung erzeugt einen Container für die URL-Pfade /daten und /privat, der
auf einem einfachen regulären Ausdruck basiert. Die drei Punkte innerhalb des Containers stehen für beliebige Konfigurationsanweisungen, die den Zugriff auf den
URL-Pfad bestimmten könnten, sofern die Verwendung der benutzten Konfigurationsanweisungen in einem <Location>-Container zulässig ist. Auch die Verwendung
von Jokerzeichen wie Fragezeichen (?) und Sternchen (*) ist möglich, wie folgendes
Beispiel zeigt:
<Location /dat*>
...
</Location>
Diese Anweisung erstellt einen Container für alle URL-Pfade, die mit der Zeichenkette dat beginnen (z.B. /daten, /data oder /data-mining). Als Jokerzeichen steht das Fragezeichen (»?«) genau für ein beliebiges Zeichen und das Sternchen (»*«) für ein, mehrere oder auch kein Zeichen.
Sehr häufig wird eine <Location>-Anweisung auch in Zusammenspiel mit einer SetHandler-Anweisung benutzt:
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .beispiel.de
</Location>
Diese Anweisung stellt unter der Adresse /status den durch mod_status erzeugten
Statusbericht des Servers zur Verfügung und erlaubt den Zugriff auf diese sensiblen
Informationen nur von Teilnehmern der Domain beispiel.de.
LocationMatch
Gruppiert eine Anzahl an Konfigurationsanweisungen für mit Hilfe von regulären
Ausdrücken zu bestimmende URL-Pfade.
Konfigurationsanweisung:
LocationMatch
Syntax:
<LocationMatch
Ausdruck>...</LocationMatch>
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
Nein
Die Konfigurationsanweisung <LocationMatch> ist mit der <Location>-Anweisung
funktional identisch, allerdings erwartet diese Anweisung (wie alle Optionen mit
dem Wort »Match« im Namen) als einzigen Parameter einen regulären Ausdruck
254
5 Konfiguration
zum Aufbau eines URL-Pfad-Containers. Zwar ist in einer <Location>-Anweisung die
Verwendung eines regulären Ausdrucks auch möglich, aber ursprünglich ist dazu
die Benutzung der <LocationMatch>-Anweisung vorgesehen. Ein Beispiel:
<LocationMatch "/downloads/(windows|linux)">
...
</LocationMatch>
Diese Anweisung erzeugt einen URL-Pfad-Container für die URL-Pfade /downloads/windows und /downloads/linux.
5.2.7
Aliase und Umleitungen
Sendet ein Client eine Anfrage an den Server, wird bei der Entscheidung welche
lokale Datei an den entfernten Client gesendet werden soll, der URL-Pfad einer
Anfrage an das durch die Konfigurationsanweisung DocumentRoot spezifizierte Verzeichnis angehängt. Deshalb sind die Dateien und Verzeichnisse, die sich unterhalb
des durch die Option DocumentRoot definierten Verzeichnisses befinden, prinzipiell
für Anfragen aus dem Internet abrufbar. Eine Beispielkonfiguration:
ServerName "www.beispiel.de"
DocumentRoot "/usr/local/apache2/htdocs"
Ruft ein Client beispielsweise das Dokument http://www.beispiel.de/kontakt.html ab,
schaut der Apache in dem Verzeichnis /usr/local/apache2/htdocs nach der Datei kontakt.html und liefert diese (sofern vorhanden) an den Client aus. Ebenso verhält es sich
mit Unterverzeichnissen, die ein Client anfordert:
ServerName "www.beispiel.de"
DocumentRoot "/usr/local/apache2/htdocs"
Fragt ein Client das Dokument http://www.beispiel.de/info/kontakt.html an, schaut der
Apache intern im Verzeichnis /usr/local/apache2/htdocs/info nach der Datei kontakt.html
und liefert diese (sofern vorhanden) an den Client.
Wenn Sie zusätzlich virtuelle Server betreiben, gibt es für jeden virtuellen Server
eigene ServerName- und DocumentRoot-Anweisungen, die auf andere Verzeichnisse
und Dateien verweisen. Alternativ können Sie das Modul mod_vhost_alias benutzen,
welches dynamisch das entsprechende DocumentRoot für einen virtuellen Server
bestimmen kann, ohne das der Apache in der Konfigurationsdatei httpd.conf über
einen Eintrag für diesen virtuellen Server verfügt. Weitere Informationen zum Aufbau und Betrieb eines virtuellen Servers erhalten Sie im Kapitel über virtuelle Server.
Manchmal ist es nötig, Dateien und Informationen zu veröffentlichen, die außerhalb
des als DocumentRoot definierten Verzeichnisses liegen. Der Apache bietet dazu mehrere Lösungsansätze, auf Unix/Linux-Systemen können z.B. Teile des Dateisystems
mit Hilfe von so genannten symbolischen Links, also Verweisen innerhalb des Dateisystems, in das als Basisverzeichnis des Apache (DocumentRoot) gekennzeichnete Verzeichnis integriert werden. Aus Sicherheitsgründen folgt der Apache solchen symbo-
5.2 Basiskonfiguration
255
lischen Verweisen nur, wenn für den jeweiligen Abschnitt die Konfigurationsoption
FollowSymLinks oder SymLinksIfOwnerMatch gesetzt ist. Alternativ können Sie auch
die Konfigurationsoption Alias benutzen, um Teile des Dateisystems in das DocumentRoot und damit in die im Internet zu veröffentlichenden Informationen zu integrieren. Um beispielsweise den Inhalt des Verzeichnisses /var/web im Internet zu veröffentlichen, könnten Sie die folgende Anweisung benutzen, wenn das Verzeichnis
/var/web außerhalb des von Ihnen als DocumentRoot definierten Verzeichnisses liegt:
ServerName "www.beispiel.de"
DocumentRoot "/usr/local/apache2/htdocs"
Alias /docs /var/web
Sollte ein Client die Adresse http://www.beispiel.de/docs/info.html aufrufen, schaut der
Apache aufgrund des definierten Aliases unter /var/web/docs nach einer Datei namens
info.html und sendet diese an den Client. Damit haben Sie ein Verzeichnis, welches
außerhalb Ihres als DocumentRoot definierten Verzeichnisses liegt, in Ihre Webpräsenz integriert. Die Konfigurationsanweisung ScriptAlias verhält sich übrigens exakt
gleich, allerdings werden alle durch die ScriptAlias-Anweisung in die Webpräsenz
integrierten Dateien als CGI-Skripte behandelt. Ein Beispiel für die Benutzung der
ScriptAlias-Anweisung ist übrigens die Definition des Verzeichnisses cgi-bin, die so
(oder so ähnlich) eigentlich Teil jeder Apache Konfiguration sein sollte:
ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"
Wenn Sie mehr und vor allem eine dynamischere Flexibilität bei der Realisierung von
Verzeichnisaliasen benötigen, sollten Sie sich die Erläuterungen zu den Konfigurationsoptionen ScriptAliasMatch und AliasMatch einmal genauer ansehen, denn diese
Anweisungen ermöglichen die Verwendung von regulären Ausdrücken (regular
expressions) bei der Erzeugung von Aliasen und Umleitungen. Reguläre Ausdrücke
sind definierbare Suchmuster (vgl. Anhang), die dynamisch, d.h. während der Ausführung, mit Hilfe der durch den Client übermittelten Informationen dazu verwendet
werden, einen Alias oder eine Umleitung zu definieren. Der Vorteil dabei liegt in
einer meist einmaligen Definition eines Suchmusters, auf das mehrere oder sogar alle
Clientanfragen zutreffen und das dynamisch für den entsprechenden Alias bzw. die
Umleitung sorgt. Ein Beispiel:
ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*) /home/$1/cgi-bin/$2
Dieses zugegebenermaßen recht komplizierte Konstrukt sorgt dafür, dass die Anforderung eines CGI-Skriptes der Form http://www.beispiel.de/~benutzername/cgibin/test.cgi auf ein Verzeichnis namens /home/benutzername/cgi-bin verweist, und dort
auf die Datei test.cgi. Zusätzlich wird die resultierende Datei test.cgi ebenfalls als CGISkript behandelt.
Die in der Konfigurationsanweisung ScriptAliasMatch in Klammern eingeschlossenen
Werte definieren reguläre Ausdrücke (regular expressions, Suchmuster), auf die im
zweiten Teil der Anweisung durch Benutzung der Variablen $1 und $2 zurückgegriffen werden kann, wobei die Variablen $1 und $2 natürlich für den Wert des ersten
bzw. des zweiten Suchmusters stehen.
256
5 Konfiguration
Aliase, Umleitungen und Benutzerverzeichnisse
Traditionell kann das Heimatverzeichnis eines Benutzers unter Unix/Linux durch
~benutzername/ angesprochen werden. Wenn Sie beispielsweise in das Heimatverzeichnis des lokalen Benutzers sebastian wechseln möchten, können Sie folgenden
Befehl verwenden:
# cd ~sebastian/
Das Modul mod_userdir greift diese Idee auf und gibt jedem lokalen Benutzer die
Möglichkeit, seine eigenen und persönlichen Inhalte im Internet unter der Adresse
http://www.beispiel.de/~benutzername/ zu veröffentlichen. Aus Sicherheitsgründen wird
allerdings nicht der komplette Inhalt des Heimatverzeichnisses ins Internet gestellt,
sondern nur der Inhalt eines durch die Konfigurationsanweisung UserDir zu spezifizierenden Verzeichnisses. Der Name dieses Verzeichnisses lautet public_html und
eine Anfrage der Form http://www.beispiel.de/~benutzername/index.html würde auf die
lokale Datei /home/benutzername/public_html/index.html verweisen, wobei /home/benutzername das in der Datei /etc/passwd definierte Heimatverzeichnis des jeweiligen
Benutzers ist. Teilweise wird das Heimatverzeichnis eines Benutzers nicht in der
Datei /etc/passwd spezifiziert, aber auch in diesem Fall gibt es mit der Anweisung
UserDir Möglichkeiten, den Benutzern ein individuelle und persönliche Internetadresse unterhalb der eigenen Domain (z.B. http://www.beispiel.de/~benutzername/) zur
Verfügung zu stellen.
Einige Benutzer können sich nicht mit dem »~«-Symbol identifizieren und wünschen
deshalb ein anderes Symbol, um die Bereiche der lokalen Benutzer gegenüber den
anderen Bereichen einer Internetseite abzugrenzen. Diese Funktionalität wird von
mod_userdir leider nicht unterstützt, d.h., Sie sind entweder auf die Verwendung des
»~«-Zeichens angewiesen, oder Sie benutzen einen kleinen Trick mit Hilfe einer AliasMatch-Anweisung, um die individuellen und benutzerspezifischen Bereiche einer
Internetseite zu kennzeichnen:
AliasMatch ^/mitarbeiter/([^/]*)/?(.*) /home/$1/public_html/$2
Mit dieser Anweisung könnten die benutzerspezifischen Inhalte, die ein Benutzer im
Verzeichnis /home/benutzername/public_html/ gespeichert hat, unter der Adresse
http://www.beispiel.de/mitarbeiter/benutzername/ im Internet veröffentlicht werden.
Umleiten von Anfragen
Die bisher in diesem Abschnitt kurz besprochenen Direktiven sorgen dafür, dass der
Apache Dokumente und Informationen irgendwo aus dem lokalen Dateisystem holt
und an den Client sendet.
In der Praxis können sich die Strukturen von Internetseiten sehr schnell ändern,
Dokumente die eventuell schon von den Clients in das Adressbuch des jeweiligen
Browsers aufgenommen wurden, sind überhaupt nicht mehr vorhanden oder plötzlich an einem anderen Standort gespeichert. Es ergibt sich daraus die Notwendigkeit,
dass eingehende Anfragen, die Informationen von einem nicht mehr aktuellen oder
sogar nicht mehr vorhandenen Teil einer Internetseite nachfragen, an den neuen Spei-
5.2 Basiskonfiguration
257
cherort der nachgefragten Informationen umgeleitet werden. Der englische Fachbegriff für eine derartige Umleitung heißt Redirection. Diese kann u.a. mit Hilfe der Konfigurationsoptionen Redirect und RedirectMatch realisiert werden.
Wenn Sie beispielsweise auf Ihrer Internetseite ein Verzeichnis namens /nachrichten
dafür benutzten, die aktuellen und vergangenen Nachrichten Ihres Unternehmens im
Internet zu veröffentlichen und Sie dieses Verzeichnis aufgrund der Umstellung auf
eine neue Software in /news umbenannt haben, so können Sie alle Anfragen vom alten
Verzeichnis nachrichten auf das neue Verzeichnis /news umleiten:
Redirect permanent /nachrichten/ http://www.beispiel.de/news/
Wird die Seite http://www.beispiel.de/nachrichten/index.html aufgerufen, erfolgt durch
diese Konfiguration automatisch eine Weiterleitung auf die neue Adresse
http://www.beispiel.de/news/index.html! Sie können dabei die eingehenden Anfragen
nicht nur an eine interne, d.h. innerhalb Ihrer Internetadresse befindliche, Adresse
umleiten, sondern auch an eine beliebige externe Adresse, wie folgendes Beispiel
zeigt:
Redirect permanent / http://www.beispiel.com
Sollte sich Ihre Firma beispielsweise entschlossen haben, für alle internationalen
Internetseiten auf eine gemeinsame .com-Domain zu verweisen, könnte dies beispielsweise mit der vorgestellten Redirect-Anweisung realisiert werden. Der bekannte
Hersteller Hewlett-Packard leitet so Anfragen an die Domain http://www.hewlettpackard.de auf die internationale Seite http://www.hp.com weiter.
Für kompliziertere Um- und Weiterleitungen bietet der Apache zusätzlich die Konfigurationsoption RedirectMatch, die ebenfalls durch mod_alias bereitgestellt wird. Im
Gegensatz zur Redirect-Anweisung unterstützt RedirectMatch die Verwendung von
regulären Ausdrücken bei der Um- und Weiterleitung von eingehenden Anfragen.
Dadurch sind viel speziellere Weiterleitungen möglich, die ganz verschiedenartigen
Suchmustern entsprechen können. Wenn Sie beispielsweise nur die Startseite Ihres
Internetangebots auf eine neue Seite umleiten möchten, alle anderen Anfragen jedoch
wie gewohnt auf Ihre alte Internetseite gehen sollen, könnten Sie etwa folgende
Anweisung benutzen:
RedirectMatch permanent ^/$ http://www.beispiel.com/startseite.html
Dieses Suchmuster sorgt dafür, dass Anfragen an die Seite http://www.beispiel.de an die
Adresse http://www.beispiel.com/startseite.html weitergeleitet werden. Fragt ein Client
eine spezielle Unterseite wie z.B. http://www.beispiel.de/download.html nach, wird diese
nicht umgeleitet, sondern (sofern vorhanden) an den Client ausgeliefert. Auch eine
temporäre Umleitung aller eingehenden Anfragen auf eine andere Adresse lässt sich
mit einer RedirectMatch-Anweisung realisieren:
RedirectMatch temp .* http://www.beispiel.com/startseite.html
Noch intelligentere Um- und Weiterleitungen sind mit dem Modul mod_rewrite möglich, da es neben der Verwendung von regulären Ausdrücken auch an Bedingungen
258
5 Konfiguration
geknüpfte Um- und Weiterleitungen ermöglicht. Die durch dieses Modul bereitgestellten Direktiven benutzen neben einem regulären Ausdruck (Suchmuster) durch
den Client übermittelte Informationen wie Browsername und -version, IP-Adresse
o. Ä., um eine Um- oder Weiterleitung zu realisieren. Dabei ist auch die Zuhilfenahme eines externes Programms oder einer Datenbank möglich. Das Modul wurde
durch den Deutschen Ralf S. Engelschall entwickelt (http://www.engelschall.com).
Datei nicht gefunden
Wer kennt diese ärgerlichen Fehlermeldungen (»file not found«) nicht? Es ist bei der
Schnellebigkeit von Informationen unvermeidbar, dass durch Clients Dokumente
angefordert werden, die nicht mehr verfügbar sind. Dabei kann dieser Umstand
durch mehrere Faktoren entstehen. Zum einen kann es sein, dass ein administrativer
Benutzer die nicht gefundenen Dokumente bzw. Informationen in andere Bereiche
der Internetseite verschoben oder sogar komplett gelöscht hat. Für den Fall, dass
Informationen nur an eine andere Stelle verschoben worden sind, sollten Sie die
bereits kurz vorgestellten Möglichkeiten der Weiter- und Umleitung von eingehenden Anfragen benutzen. Nur so können Sie sicherstellen, dass Bookmarks und Verweise auf Ihre Internetseite weiterhin ihre Gültigkeit behalten, obwohl die Informationen inzwischen unter einer dem Client wahrscheinlich nicht bekannten, anderen
Adresse erreichbar sind.
Ein weiterer Grund für nicht gefundene Informationen sind unbeabsichtigte Rechtschreibfehler bei der Eingabe einer Internetadresse oder in Verweisen auf eine Internetseite. Zur Lösung dieses Problems verfügt der Apache über ein Modul namens
mod_speling, dessen Schreibweise (nur ein »l«, korrekt wären zwei!) durchaus Symbolcharakter hat. Sollte eine nachgefragte Datei nicht gefunden werden, sucht das
Modul nach einer ähnlichen Datei und sendet dem Client eine Information über den
neuen Standort dieser ähnlichen Datei. Sollte es mehrere passende Dateien geben,
erhält der Client eine Liste dieser ähnlichen Dateien und kann daraus eine Datei auswählen, in der Hoffnung, die ursprünglich gewünschte Information zu bekommen.
Ein besonderes Merkmal von mod_speling ist außerdem, dass es Vergleiche zwischen
zwei Dateien unabhängig von deren Groß- und Kleinschreibung durchführt, so dass
auch unerfahrenen Benutzern geholfen werden kann, die aufgrund der Wahl ihres
Betriebssystems und/oder persönlichen Erfahrungsschatzes nicht wissen, dass Internetadressen und Datei- sowie Verzeichnisangaben unter Unix/Linux einer sehr exakten Schreibweise bedürfen. Allerdings darf man mod_speling nicht zu sehr in den
Himmel loben, mehr als unbeabsichtigte und einfache Schreibfehler kann es auch
nicht korrigieren, zumal jede falsche Anfrage den Server mit einer Weiterleitung
sowie einer zusätzlichen clientseitigen Anfrage beansprucht.
Sollten alle Versuche, die ursprünglich vom Client gewünschten Informationen zu
finden, fehlschlagen, erhält der Client eine Fehlermeldung, dass die von ihm
gewünschte Information nicht vorhanden ist (HTTP Statuscode 404, vgl. Anhang). Die
Datei, die im Falle eines Fehlers an den Client gesendet werden soll, bestimmt die
Direktive ErrorDocument, deren Aussehen mannigfaltig geändert und auf die jeweiligen Wünsche und Bedürfnisse zugeschnitten werden kann. Wir werden uns der
Anpassung dieser Datei in einem eigenen Abschnitt dieses Buches zuwenden.
5.2 Basiskonfiguration
259
Für die Bereitstellung von Benutzerverzeichnissen, die Umleitung von Anfragen und
das Verhalten bei einer nicht gefundenen Datei können folgende Konfigurationsanweisungen genutzt werden:
Alias
Bildet eine URL auf eine Position im Dateisystem ab.
Anweisung:
Alias
Syntax:
Alias Url-Pfad Dateipfad | Verzeichnispfad
Standardwerte (Default):
Alias /icons/ »/usr/local/apache2/icons/«
(Anweisung mehrfach vorhanden)
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Kontext
Anweisung aktiv:
ja
Die Konfigurationsanweisung Alias bildet eine URL auf einen beliebigen Speicherort
auf dem lokalen Dateisystem ab, auch wenn dieser außerhalb des als DocumentRoot
definierten Verzeichnisses liegt. Damit lassen sich Teile des Dateisystems in den
Bereich der im Internet zu veröffentlichenden Informationen integrieren, die eigentlich außerhalb dieses Bereichs und damit außerhalb der Zugriffsbefugnis des Apache
und eines anfragenden Clients liegen.
Wenn Sie beispielsweise den Inhalt des Verzeichnisses /var/download im Internet veröffentlichen wollen, Ihr als DocumentRoot definiertes Verzeichnis jedoch
/usr/local/apache2/htdocs lautet, können Sie mit Hilfe der Alias-Anweisung den Inhalt
des Verzeichnisses /var/download unter der Adresse http://www.beispiel.de/download/
bereitstellen:
Alias /download/ /var/download/
Die Anzahl der Alias-Anweisungen in der Konfigurationsdatei httpd.conf des Apache
ist übrigens nicht begrenzt. Enthält der angelegte Alias einen abschließenden Forwardslash (»/«), muss das entsprechende Verzeichnis auch einen abschließenden
Slash enthalten. Enthält der Alias keinen abschließenden Slash, muss die entsprechende Verzeichnisangabe auch keinen Slash enthalten! Folgende Alias-Anweisungen wären deshalb gültig:
Alias /bilder/ /var/web/bilder/
Alias /bilder /var/web/bilder
Diese beiden Anweisungen sind korrekt, sie enthalten entweder sowohl in dem fiktiven, als Alias definierten Namen (/bilder/) als auch im abgebildeten Verzeichnis
(/var/web/bilder/) einen abschließenden Schrägstrich oder in keinem von beiden. Enthält nur einer der beiden Parameter der Alias-Anweisung einen abschließenden
260
5 Konfiguration
Schrägstrich, erhalten Sie eine Fehlermeldung. Eine solche Definition ist deshalb
ungültig:
Alias /bilder/ /var/web/bilder
Die Fehlerseiten des Apache werden übrigens auch mit Hilfe einer Alias-Anweisung
in den Server eingebunden, wie dieses Beispiel zeigt:
Alias /error/ "/usr/local/apache2/error/"
Das Verzeichnis /usr/local/apache2/error enthält die Dokumente, die im Falle eines Fehlers an den Client gesendet werden sollen. Da dieses Verzeichnis außerhalb des als
DocumentRoot definierten Verzeichnisses liegt, muss es durch eine Alias-Anweisung
integriert werden.
AliasMatch
Bildet eine URL mit Hilfe eines regulären Ausdrucks auf eine Position im Dateisystem ab.
Anweisung:
AliasMatch
Syntax:
AliasMatch Suchmuster Dateipfad |
Verzeichnispfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Kontext
Anweisung aktiv:
nein
Diese Konfigurationsoption ist identisch mit der Alias-Anweisung, allerdings können
zusätzlich reguläre Ausdrücke bei der Definition eines Alias verwendet werden. Sie
finden im Anhang dieses Buches eine ausführliche Anleitung zur Verwendung von
regulären Ausdrücken.
Ein denkbarer Aufruf der AliasMatch-Anweisung ist folgender:
AliasMatch ^/(.*)\.gif$ /var/web/bilder/$1.gif
Diese Anweisung würde jede Anfrage an eine beliebige Datei mit der Endung .gif in
das Verzeichnis /var/web/bilder umleiten. Wird beispielsweise die Adresse
http://www.beispiel.de/logo.gif aufgerufen, sucht der Apache in dem Verzeichnis
/var/web/bilder nach der Datei logo.gif und sendet diese (sofern vorhanden) an den
Client. Diese Umleitung gilt allerdings nur für (Bild-)-Dateien, deren Endung .gif lautet. Dateien eines anderen Typs, deren Endung nicht .gif lautet, werden von dieser
Umleitung nicht erfasst.
5.2 Basiskonfiguration
261
Wenn Sie zum Beispiel neben .gif- auch .jpg-Bilder aus dem Verzeichnis /var/web/bilder
anstatt aus Ihrem als DocumentRoot definierten Verzeichnis beziehen möchten, können Sie dies etwa mit folgender AliasMatch-Anweisung realisieren:
AliasMatch ^/(.*)\.(gif|jpg)$ /var/web/bilder/$1.$2
Diese Anweisung überprüft, ob eine Anfrage nach einer beliebigen Bilddatei mit der
Endung .jpg oder .gif erfolgt, und sucht im Verzeichnis /var/web/bilder nach einer solchen Datei. Dabei lassen sich die in Klammern gesetzten Werte im Zielpfad
/var/web/bilder durch fortlaufende Ganzzahlen ($1 und $2) referenzieren. Der Wert $1
steht dabei für den beliebigen Namen einer Datei (ohne Endung), der durch das erste
in Klammern eingeschlossene Suchmuster (.*) repräsentiert wird. Das zweite Suchmuster (gif|jpg) steht für die Endung einer Datei, die entweder .gif oder .jpg lauten
soll, wobei auf deren Wert mit der Variable $2 zugegriffen werden kann. Im Zielpfad
/var/web/bilder wird der vollständige Dateiname aus diesen beiden Variablen mit der
Anweisung $1.$2 (Dateiname.Endung) zusammengesetzt und somit die AliasMatchAnweisung abgeschlossen.
Sie können die AliasMatch-Anweisung übrigens auch benutzen, um die lästigen Attacken auf den Microsoft Internet Information Server abzufangen, indem Sie alle Anfragen, die anscheinend auf den IIS abzielen, nicht mit einer normalen Fehlermeldung
darüber aufklären, dass es die nachgefragte Datei nicht gibt, sondern indem Sie dem
Angreifer einfach eine leere Datei zurückliefern. Dies hat den Vorteil, dass sich Ihre
Logdateien nicht mit Fehlermeldungen über nicht gefundene Dateien füllen und Sie
außerdem Bandbreite und Serverkapazität sparen. Normale Fehlerdokumente sind
nämlich bis zu 3 KB groß und verursachen damit in der Masse eine beachtliche Größe
an unnötigem Traffic, der nur durch Fehler im Internet Information Server ausgelöst
wird! Legen Sie also eine leere Datei (z.B. leider_kein_iis.html) unterhalb Ihres als
DocumentRoot (z.B. /usr/local/apache2/htdocs) definierten Verzeichnisses an und fügen
Sie die folgenden Anweisungen der zentralen Konfigurationsdatei httpd.conf des
Apache hinzu:
AliasMatch
AliasMatch
AliasMatch
AliasMatch
AliasMatch
AliasMatch
(.*)/system32(.*) "/usr/local/apache2/htdocs/leider_kein_iis.html"
(.*)/Admin.dll "/usr/local/apache2/htdocs/leider_kein_iis.html"
(.*)/root.exe "/usr/local/apache2/htdocs/leider_kein_iis.html"
(.*)/cmd.exe "/usr/local/apache2/htdocs/leider_kein_iis.html"
(.*)/default.ida "/usr/local/apache2/htdocs/leider_kein_iis.html"
(.*)/httpodbc.dll "/usr/local/apache2/htdocs/leider_kein_iis.html"
Jede eingehende Anfrage, die einen der Schlüsselbegriffe system32, Admin.dll, root.exe,
cmd.exe, default.ida oder httpodbc.dll enthält, wird automatisch mit der leeren Antwortseite leider_kein_iis.html beantwortet. Sicherlich lässt sich ein derartiger Nimda/CodeRed/wasauchimmer-Schutz auch eleganter mit einer RedirectMatch-Anweisung
umsetzen, aber ich finde die hier präsentierte Idee gut, da sie gerade bei großen Seiten, die sich vielen sinnlosen Angriffen auf Schwachstellen des Internet Information
Server ausgesetzt fühlen, eine ordentliche Menge an für die Betreiber oft kostspieligen Datenverkehr (Traffic) erspart, indem sie auf die eingehenden Angriffe eine leere
Antwort schickt.
262
5 Konfiguration
CheckSpelling
Aktiviert oder deaktiviert die Unterstützung für das Modul mod_speling.
Konfigurationsanweisung:
CheckSpelling
Syntax:
CheckSpelling on | off
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_speling
Kontext:
Server-Kontext, VirtualHost- Kontext,
<Directory>-Container, <Location>-Container,<Files>-Container, .htaccess Container
Anweisung aktiv:
nein
Die Konfigurationsanweisung CheckSpelling aktiviert (on) oder deaktiviert (off) das
Modul mod_speling. Dieses Modul zur Fehlerkorrektur kann drei verschiedene
Arten von durch den Benutzer verursachten Fehlern korrigieren:
Falsche Groß- und Kleinschreibung
Ruft ein Client die Datei InfO.html anstatt info.html auf, sorgt mod_speling dafür,
dass die Datei info.html an diesen gesendet wird. Diese Funktion ist sehr wichtig, da
viele Benutzer nicht wissen, dass der Apache und die gesamte Unix/Linux-Umgebung auf die korrekte Groß- und Kleinschreibung (Fachbegriff: case sensitive) sehr großen Wert legt und falsch geschriebene Befehle im Gegensatz zur Wintendo-Welt nicht
akzeptiert werden.
Fehlende Dateiendungen
Falls ein Benutzer das Dokument info.html abrufen will, dabei jedoch vergisst die
Dateiendung .html einzugeben, wird mod_speling diesen dusseligen Fehler des
Benutzers korrigieren und die ursprünglich gewünschte Datei info.html ausliefern.
Tippfehler bis zu einem Zeichen
Mod_speling kann kleinere Tippfehler der Benutzer von bis zu einem falschen Zeichen erkennen und beseitigen. Dazu gehören u.a. Buchstabendreher oder komplett
fehlende Buchstaben. Bei einer Anfrage nach den Dateien inf.html oder infos.html
wird dem Client korrekterweise die ähnliche (und eigentlich gewünschte) Datei
info.html übermittelt.
Sollte eine Datei trotz dieser Korrekturen nicht eindeutig zugeordnet werden können,
erhält der nachfragende Client eine Fehlermeldung, dass die von ihm gewünschte
Datei nicht vorhanden ist. Sollten mehrere ähnliche Dateien existieren, präsentiert
mod_speling dem Client eine Liste mit diesen ähnlichen Dokumenten und der Client
hat die Möglichkeit, aus dieser Liste das von ihm gewünschte Dokument auszuwählen und abzurufen. Bitte beachten Sie, dass mod_speling nur die vorhandenen Dateinamen und Verzeichnisse mit den angefragten Dokumenten vergleicht und gegebenenfalls korrigiert. Es kann die in der eigentlichen Anfrage enthaltenen Daten, die
sich nicht direkt auf lokale Verzeichnisse und Dateien beziehen, nicht korrigieren.
Wenn Sie beispielsweise für jeden lokalen Benutzer ein individuelles Verzeichnis
5.2 Basiskonfiguration
263
unter der Adresse http://www.beispiel.de/~benutzername/ eingerichtet haben und ein
Client möchte die Seite des Benutzers andreas abrufen, vertippt sich jedoch bei der
Eingabe des Benutzernamens (http://www.beispiel.de/~andeas/), so wird mod_speling
diesen Fehler nicht korrigieren können, da es nicht weiß, dass es den lokalen Benutzer
andeas nicht gibt!
ErrorDocument
Definiert die Antwort an den Client im Falle eines aufgetretenen Fehlers.
Konfigurationsanweisung:
ErrorDocument
Syntax:
ErrorDocument Fehlercode Dokument
Standardwerte (Default):
ErrorDocument 404
/error/HTTP_NOT_FOUND.html.var
(mehrfach vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost- Kontext,
<Directory>-Container, <Location>-Container,<Files>-Container, .htaccess Container
Anweisung aktiv:
ja
Sollte bei der Bearbeitung einer Clientanfrage ein Fehler auftreten, kann der Apache
eine der vier nachfolgenden Reaktionen durchführen:
Rückgabe einer statischen Fehlerseite
Eine vorgegebene Fehlerseite des Apache wird zurückgegeben, sofern mod_negotiation
eingeschaltet ist und der Client die entsprechenden Informationen übermittelt, sogar in
der Landessprache des jeweiligen Benutzers. Die vordefinierten Fehlerseiten sind im
Unterverzeichnis error Ihrer lokalen Apache-Installation gespeichert.
Rückgabe einer individuellen Fehlerseite
Sie haben die Möglichkeit eigene und damit individuelle Fehlermeldungen zu gestalten und diese anstatt der langweiligen, vordefinierten Dokumente an den Client zu
schicken.
Umleitung an eine lokale Adresse
Sollte eine von einem Client angeforderte Datei nicht mehr existieren, können Sie diesen an eine beliebige lokale Adresse umleiten.
Weiterleitung an eine externe Adresse
Tritt bei der Bearbeitung einer Clientanfrage ein Fehler auf, können Sie den Client
auch an eine externe Adresse weiterleiten, die nicht Teil Ihrer Internetseite ist. Bei der
Weiterleitung an eine externe Adresse bzw. bei der Angabe des Protokolls http:// in
der Reaktion auf einen aufgetretenen Fehler, sendet der Apache sofort eine Umleitung an den Client, ohne dass die eigentliche Fehlermeldung vorher an den Client
gesendet wird. Diese Funktion kann einige Clients und automatisierte Suchroboter
verwirren, da diese die Gültigkeit einer Adresse anhand des zurückgegebenen HTTPStatuscodes überprüfen.
264
5 Konfiguration
Die erste Reaktion ist die Standardeinstellung, die zweite bis vierte Reaktion benötigen zusätzlich als Parameter der Konfigurationsoption ErrorDocument die Angabe
eines HTTP-Statuscodes (vgl. Anhang) sowie einer URL oder einer Nachricht. Teilweise sendet der Apache auch zusätzliche Informationen über einen aufgetretenen
Fehler, die die Entstehung oder die Ursache eines Problems bzw. eines Fehlers näher
erläutern. Hier folgt ein Beispiel für jede mögliche Reaktion des Apache auf einen aufgetretenen Fehler:
ErrorDocument
ErrorDocument
ErrorDocument
ErrorDocument
Internetseite
500 http://www.beispiel.de/cgi-bin/server_fehler
404 /cgi-bin/nicht_gefunden.pl
401 /nicht_authorisiert.html
403 "Sie haben die erforderliche Berechtigung, auf diesen Bereich der
zuzugreifen."
Das erste Beispiel sorgt dafür, dass der Apache im Falle eines internen Server-Fehlers
(HTTP-Statuscode 500) den Client an ein CGI-Skript namens server_fehler unter der
externen Adresse http://www.beispiel.de/cgi-bin/ weiterleitet. Der Client bekommt den
Statuscode für die eigentliche Fehlermeldung dabei nicht angezeigt, sondern wird
direkt weitergeleitet. Bitte beachten Sie dabei, dass bei der Weiterleitung an eine
externe Adresse der Statuscode 401 (unauthorized, nicht autorisiert) nicht benutzt werden darf, da dieser ausschließlich für lokale Adressen und einfache Textnachrichten
bestimmt ist!
Das nächste Beispiel leitet den Client im Falle einer nicht gefundenen Datei (Statuscode 404) an ein lokales CGI-Skript namens nicht_gefunden.pl weiter, welches sich im
Verzeichnis cgi-bin befindet. Dieses Skript könnte beispielsweise eine Liste der nicht
gefundenen Dokumente in eine Datenbank schreiben. Damit ließe sich eine Übersicht
der am häufigsten nachgefragten, aber dennoch nicht vorhandenen Dokumente
erstellen und eventuelle Fehler in der Serverkonfiguration könnten sichtbar werden.
Alternativ könnte das Skript dem Administrator eine E-Mail senden, wenn ein Client
ein nicht vorhandenes Dokument aufgerufen hat. Diese Funktion sollten Sie jedoch
nur auf bestimmte und wichtige Bereiche Ihrer Internetseite begrenzen, da es bei
einem recht häufig frequentierten Server durchaus zu einer gewissen Anzahl an nicht
gefundenen Dokumenten kommen kann.
Beispiel Nummer drei gibt eine lokale Datei an den Client zurück, die sich im Hauptverzeichnis (DocumentRoot) der im Internet zu veröffentlichenden Informationen
befindet. Dies könnte eine von Ihnen gestaltete Fehlerseite sein, die darauf hinweist,
dass der Bereich, auf den der Client zugreifen will, passwortgeschützt ist und somit
eine Authentifizierung erforderlich ist.
Das letzte Beispiel gibt direkt einen Fehlertext an den Client zurück, der übrigens
auch HTML-Code enthalten darf. Es wäre also auch folgende Anweisung denkbar,
den HTML-Code müssten Sie allerdings noch aufbessern:
ErrorDocument 403 "<html><title>Fehlerseite 403</title><h1>Es ist ein Fehler
aufgetreten: Sie haben nicht die nötige Berechtigung, auf diese Adresse
zuzugreifen.</h1></html>"
5.2 Basiskonfiguration
265
Die Umleitung auf eine lokale Datei oder eine externe Adresse sollte jedoch bevorzugt werden, da sich in einer derartigen ErrorDocument-Anweisung nur sehr wenig
HTML-Code unterbringen lässt.
LimitInternalRecursion
Limitiert die Anzahl interner Umleitungen bzw. Unteranfragen.
Konfigurationsanweisung:
LimitInternalRecursion
Syntax:
LimitInternalRecursion Zahl [ Zahl ]
Standardwerte (Default):
LimitInternalRecursion 10
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost- Kontext
Anweisung aktiv:
nein
Während der Bearbeitung einer Clientanfragen kann es unter Umständen vorkommen, dass eine Anfrage eines Clients durch den Apache intern an ein Skript oder ein
externes Programm weitergegeben und somit umgeleitet werden muss (vgl. ActionsAnweisung). Ebenso kann es passieren, dass der Apache infolge einer Clientanfrage
eine eigene Unteranfrage für eine spezielle Datei oder Information starten muss.
Mit Hilfe der LimitInteralRecursion-Anweisung können Sie die Anzahl der Umleitungen und Unteranfragen definieren, die der Server je Clientanfrage maximal akzeptieren soll. Der erste Parameter der Anweisung bestimmt dabei die maximale Anzahl an
Umleitungen, denen der Apache intern folgen soll. Die zweite Anweisung definiert
die Anzahl an Verschachtelungen, die Unteranfragen insgesamt haben dürfen. Ein
Beispiel:
LimitInternalRecursion 5 7
Durch eine derartige Konfiguration weisen Sie den Apache an, dass dieser während
einer Clientanfrage maximal fünf internen Umleitungen und (maximal) siebenfach
verschachtelten Unteranfragen folgt. Falls Sie keine separate Anzahl an Verschachtelungen der Unteranfragen definieren möchten, können Sie den zweiten Parameter
auch vollständig weglassen:
LimitInternalRecursion 10
Durch diese Konfiguration wird der Wert zehn beiden Parametern zugewiesen.
Options
Bestimmt Eigenschaften und zur Verfügung stehende Optionen eines Verzeichnisses.
Konfigurationsanweisung:
Options
Syntax:
Options [+|-] Optionen
Standardwerte (Default):
Options FollowSymLinks
(Anweisung mehrfach vorhanden)
266
5 Konfiguration
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, .htaccess Container
Anweisung aktiv:
ja
Mit dieser Konfigurationsanweisung bestimmen Sie, welche Eigenschaften in einem
bestimmten Verzeichnis verfügbar sein sollen. Mögliche Eigenschaften, die Sie aktivieren oder deaktivieren können, sind zum Beispiel die automatische Generierung
von Verzeichnisindizes (sofern keine Indexdatei vorhanden ist) oder das Erlauben
der Ausführung von Server-Side Includes.
Die Benutzung einer Options-Anweisung innerhalb eines <Directory>- oder .htaccessContainers sorgt dafür, dass die festgelegten Eigenschaften für das jeweilige Verzeichnis sowie alle Unterverzeichnisse definiert werden! Wenn Sie eine OptionsAnweisung innerhalb der Server- oder VirtualHost-Konfiguration definieren, so gelten die festgelegten Eigenschaften für alle Verzeichnisse und Dateien des Servers.
Die Konfigurationsanweisung Options verlangt die Angabe einer (oder auch mehrerer) Eigenschaften, die wie folgt lauten:
None
Keine der hier vorgestellten Eigenschaften wird für das jeweilige Verzeichnis aktiviert.
All
Schaltet die Optionen ExecCGI, FollowSymLinks, Includes und Indexes ein.
ExecCGI
Mit dieser Option erlauben Sie die Ausführung von CGI-Skripten in einem bestimmten Verzeichnis.
FollowSymLinks
Unter Unix/Linux kann mit Hilfe eines so genannten symbolischen Verweises (symbolic link) beim Zugriff auf eine Datei oder ein Verzeichnis auf ein anderes Ziel verwiesen werden, wenn beispielsweise eine Datei oder ein ganzes Verzeichnis an einen
anderen Standort verschoben worden ist und die Datei oder das Verzeichnis aus
Kompatibilitätsgründen weiterhin auch unter dem alten Speicherort verfügbar sein
soll. Fordert ein Client nun eine Datei an, die durch einen symbolischen Verweis auf
eine anderen Standort verweist, bestimmt diese Option, ob der Server dem symbolischen Verweis folgen und die Datei, auf der der Verweis zeigt, an den Client liefern
soll oder nicht. Wenn der Server einem symbolischen Verweis folgen soll, so müssen
zumindest Leserechte bestehen, damit der Apache die Zieldatei des Verweises an den
Client senden kann. Wenn der Server einem symbolischen Verweis nicht folgen soll,
erhält der Client beim Zugriff auf einen symbolischen Link eine entsprechende Fehlermeldung. Hinweis: Folgt der Server einem symbolischen Link, der durchaus auch
auf ein Ziel außerhalb des als DocumentRoot definierten Verzeichnisses verweisen
kann, ändert dies nicht den Pfadnamen, der beispielsweise zum Abgleich eines
5.2 Basiskonfiguration
267
<Directory>-Abschnitts verwendet werden kann. Innerhalb eines <Location>-Containers wird diese Konfigurationsoption komplett ignoriert.
SymLinksIfOwnerMatch
Die Option ist mit der bereits erläuterten Eigenschaft FollowSymLinks identisch,
besitzt allerdings eine höhere Priorität als diese und verfolgt einen symbolischen Verweis nur, wenn die Datei, auf die verwiesen wird, auch dem Benutzer gehört, dem
der symbolische Link gehört. FollowSymLinks nimmt dagegen keine Unterscheidung
zwischen dem Besitzer eines symbolischen Links und dem Besitzer des Ziels vor. Verwenden Sie daher besser die Option SymLinksIfOwnerMatch, wenn Sie symbolische
Verweise unterstützen möchten.
Includes
Erlaubt die Ausführung von so genannten Server-Side Includes (SSI).
IncludesNOEXEC
Diese Eigenschaft ist mit der Option Includes identisch, allerdings verbietet sie die
Einbindung von externen CGI-Skripten (#include) sowie die Ausführung von Programmen innerhalb von SSI-Skripten (#exec). IncludesNOEXEC hat eine höhere Priorität als Includes und überschreibt die durch Includes festgelegten Eigenschaften.
Indexes
Greift ein Client auf ein Verzeichnis zu (z.B. http://www.beispiel.de/verzeichnis/), wird
normalerweise die durch die Konfigurationsoption DirectoryIndex bestimmte Datei
(üblicherweise index.html, main.html, index.htm oder auch index.php) an den Client
zurückgeliefert. Sollte eine derartige Datei nicht vorhanden sein, bestimmt die Eigenschaft Indexes, ob der Apache einen Verzeichnisindex erstellen und an den Client senden soll oder ob der Zugriff auf das vom Client angeforderte Verzeichnis mit einer
Fehlermeldung (Forbidden, Zugriff nicht erlaubt) angewiesen werden soll (HTTPStatuscode 403, vgl. Anhang).
MultiViews
Mit der Eigenschaft MultiViews erzeugt der Apache beim Zugriff auf eine nicht existierende Datei anhand des angeforderten Dateinamens und der -endung eine Liste
der alternativ zur Verfügung stehenden Dateien und wertet die bei der Clientanfrage
übermittelten Daten über die bevorzugte Aufbereitungsart von Informationen aus,
um (sofern möglich) dem Client eine alternative Variante zu senden, die dennoch die
ursprünglich gewünschten Informationen enthält. Ein praktisches Beispiel für MultiViews wäre eine Anfrage eines Clients nach einer Datei, für die auf dem Server mehrere Varianten in unterschiedlichen Sprachen zur Verfügung stehen. Der Apache
prüft anhand der Headerinformationen die bei der Clientanfrage übermittelt worden
sind, welche Sprache (z.B. Deutsch, Englisch, Französisch) und welche Darstellungsform (z.B. HTML-Dateien, PDF-Dateien, reiner Text) ein Client bevorzugt und liefert
(falls vorhanden) die optimale Sprach- und Typvariante an den Client. Sollte für die
vom Client gewünschte Variante kein entsprechendes Dokument vorhanden sein,
kann der Client zusätzlich akzeptierte Sprachen und Formate definieren, so dass der
Apache die ursprünglich angeforderten Informationen in einer akzeptierten Variante
an den Client zurückliefern kann, die zwar in Sprache und Typ von der ursprünglich
268
5 Konfiguration
angeforderten Datei abweichen, deren Inhalt jedoch identisch ist. Weitere Informationen über den Sinn und Zweck der MultiViews-Option finden Sie im Kapitel über Content Negotiation.
Sie können die Eigenschaften auf zwei verschiedene Arten definieren: Entweder setzen Sie die Eigenschaften absolut oder Sie fügen zu einer Liste von bereits bestehenden Eigenschaften Optionen hinzu bzw. entfernen Eigenschaften aus einer vorhandenen Liste. Wenn Sie Eigenschaften absolut und nur für ein bestimmtes Verzeichnis
setzen möchten, können Sie dies wie folgt tun:
Options SymLinksIfOwnerMatch Indexes
Wenn Sie aus einer bereits bestehenden Liste von Eigenschaften eine zusätzliche
Eigenschaft hinzufügen oder eine bereits vorhandene entfernen möchten, gehen Sie
beispielsweise wie folgt vor:
Options -FollowSymLinks -Includes +Indexes
Das vorangestellte Minuszeichen entfernt eine Eigenschaft, ein Pluszeichen fügt eine
Eigenschaft zu den bereits vorhandenen Optionen hinzu. Vorhandene Optionen ergeben sich meist aus den für übergeordnete Verzeichnisse festgelegten Eigenschaften,
die automatisch auch für ein Unterverzeichnis gültig sind. Folgendes Beispiel soll diesen Umstand kurz verdeutlichen:
<Directory /daten>
Options Includes SymLinksIfOwnerMatch
</Directory>
<Directory /daten/urlaubsbilder>
Options Indexes
</Directory>
Für ein Verzeichnis namens Daten wird festgelegt, dass die Ausführung von ServerSide Includes (Includes) erlaubt ist. Außerdem soll der Apache symbolischen Verweisen an ihr Ziel folgen, wenn das Zielobjekt dem Benutzer gehört, dem auch der symbolische Verweis gehört (SymLinksIfOwnerMatch). Der zweite <Directory>-Abschnitt
definiert eine Eigenschaft (Indexes) für das Verzeichnis /daten/urlaubsbilder, welches
ein Unterverzeichnis des bereits konfigurierten Verzeichnisses /daten darstellt. Durch
die Neudefinition verlieren die bereits vorgenommenen Eigenschaften Includes und
SymLinksIfOwnerMatch der ersten <Directory>-Anweisung ihre Gültigkeit und werden für dieses eine Unterverzeichnis /daten/urlaubsbilder von der Option Indexes überschrieben. Das heißt, der Server wird zwar im Falle einer nicht vorhandenen Indexdatei für das Verzeichnis /daten/urlaubsbilder eine Verzeichnis- und Dateiübersicht
erstellen (Indexes), aber er wird in diesem Verzeichnis weder Server-Side Includes
ausführen, noch symbolischen Verweisen folgen!
Wenn Sie jedoch möchten, dass zu einer Liste von bereits in übergeordneten Verzeichnissen definierten Eigenschaften, neue Optionen hinzugefügt oder gelöscht werden sollen, sollten Sie die Schreibweise mit dem vorangestellten Plus- bzw. Minuszeichen benutzen, wie nachfolgendes Beispiel zeigt:
5.2 Basiskonfiguration
269
<Directory /daten>
Options Indexes Includes
</Directory>
<Directory /daten/bilder>
Options +FollowSymLinks -Includes
</Directory>
Für das Verzeichnis /daten werden die Optionen Indexes und Includes definiert, also
die automatische Generierung von Verzeichnisindizes sowie die Erlaubnis zur Ausführung von Server-Side Includes (SSI). Das Unterverzeichnis /daten/bilder übernimmt
diese Optionen, fügt die Eigenschaft zur Verfolgung von symbolischen Verweisen
hinzu und deaktiviert gleichzeitig die Verwendung von Server-Side Includes für das
Unterverzeichnis.
Wenn Sie lieber für jedes Verzeichnis die Eigenschaften explizit angeben möchten, um
beispielsweise einen besseren Überblick über die definierten Eigenschaften zu bekommen, können Sie die Optionen auch absolut für jedes Verzeichnis einzeln setzen:
<Directory /daten>
Options Indexes Includes
</Directory>
<Directory /daten/bilder>
Options Indexes FollowSymLinks
</Directory>
Dieses Beispiel ist mit dem oben genannten Beispiel funktional identisch, die Bezeichnung der definierten Eigenschaften erfolgt jedoch nicht mit einem vorangestellten
Plus- oder Minuszeichen, sondern in absoluter Form.
Redirect
Leitet eine Anfrage durch Rückgabe eines HTTP-Statuscodes an eine interne oder
externe Adresse um.
Konfigurationsanweisung:
Redirect
Syntax:
Redirect [Status] Url-Pfad URL
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess Container
Anweisung aktiv:
nein
Wenn Sie einen Bereich Ihrer Internetseite entfernt oder verschoben haben, können
Sie die Redirect-Anweisung benutzen, um Ihre Clients über diesen Umstand zu informieren und sie auf die neue Adresse umzuleiten. Als neue Adresse kann entweder
eine interne oder eine externe Internetadresse definiert werden, wobei auch ein expliziter Verweis auf eine bestimmte Datei oder ein bestimmtes Verzeichnis Verzeichnis
möglich ist!
270
5 Konfiguration
Die Umleitung, die auch HTTP-Redirect genannt wird, erfolgt über eine spezielle
Information (Location genannt) in der Antwort des Servers auf die Anfrage eines
Clients und wird in der Regel ohne weitere Interaktion des Benutzers automatisch
vorgenommen.
Wenn Sie beispielsweise auf Ihrer Internetseite www.beispiel.de einen Downloadbereich (www.beispiel.de/download) eingerichtet hatten, aus dem die Benutzer Ihre
selbst entwickelten Programme herunterladen konnten, und Sie dafür jetzt bei einem
besonders günstigen Provider eine eigene Adresse eingerichtet haben, könnten Sie
etwa die folgende Anweisung benutzen, um die Anfragen automatisch umzuleiten:
Redirect /download http://www.firma.de/download
Greift ein Client auf das Verzeichnis /download oder darunter liegende Objekte zu,
wird dieser automatisch auf die Adresse http://www.firma.de/download umgeleitet.
Erfolgt beispielsweise eine Anfrage für eine Datei namens beispiel.exe aus dem alten
Verzeichnis (http://www.beispiel.de/download/beispiel.exe), wird diese Anfrage auf die
Adresse http://www.firma.de/download/beispiel.exe umgeleitet.
Sie können auch alle Anfragen auf eine Internetseite umleiten, indem Sie etwa folgende Anweisung benutzen:
Redirect / http://members.aol.com/willi76
Eine derartige Anweisung könnte beispielsweise als extrem günstige Web-Visitenkarte bei einem Internetprovider zum Einsatz kommen, denn viele Kunden besitzen
bereits eine Homepage (z.B. http://members.aol.com/willi76) mit einer kaum einzuprägenden Internetadresse bei ihrem Zugangsprovider (z.B. T-Online oder AOL) und
sind so in der Lage eine eigene Internetadresse wie http://www.beispiel.de zu bekommen, die einfach auf die vorhandene Homepage weiterleitet.
Die Umleitung muss übrigens in absoluter Form (z.B. http://www.beispiel.de/news)
angegeben werden, auch wenn diese innerhalb ein und derselben Internetseite stattfindet. Die Redirect-Anweisung überschreibt außerdem sowohl die Alias-, als auch die
ScriptAlias-Option, wobei die Reihenfolge der Anweisungen innerhalb der zentralen
Konfigurationsdatei httpd.conf des Apache keine Rolle spielt.
Optional ist die Angabe eines HTTP-Statuscodes in der Redirect-Anweisung, wobei
diese Angabe entweder in nummerischer Form (vgl. Anhang) oder durch Angabe
eines der vier vordefinierten Werte erfolgen kann. Standardmäßig wird immer der
Statuscode 302 an den Client gesendet, der dem Statusnamen temp entspricht. Dies
bedeutet, dass eine Information für eine zeitlich begrenzte Zeit nicht (mehr) an der
durch den Client nachgefragten Adresse verfügbar ist, sondern sich inzwischen an
einem anderen, näher zu spezifizierenden Standort befindet.
Wenn Sie beispielsweise eine permanente Umleitung (HTTP-Statuscode 301) definieren möchten, könnten Sie folgende Anweisung benutzen:
Redirect 301 /alt http://www.beispiel.de/neu
5.2 Basiskonfiguration
271
Diese Anweisung würde die Anfrage eines Clients mit dem HTTP-Statuscode 301
beantworten und die Anfrage auf das Verzeichnis /alt auf die neue Adresse
http://www.beispiel.de/neu umleiten. Alternativ gibt es vier vordefinierte Statusnamen:
temp
Eine zeitlich begrenzt geltende Umleitung, beispielsweise im Falle von Wartungsarbeiten am eigentlichen Server, erreichen Sie durch Angabe des Statusnamens temp
(HTTP-Statuscode 302). Ein Beispiel:
Redirect temp / http://www.beispiel.de/wartungsarbeiten.html
Diese Anweisung würde alle eingehenden Anfragen auf die Adresse
http://www.beispiel.de/wartungsarbeiten.html umleiten, die entsprechende Hinweise
über den Grund und die Dauer der laufenden Wartungsarbeiten bereithält.
permanent
Wenn sich die Struktur Ihrer Internetseite grundlegend geändert hat, können Sie die
Clients über diese dauerhafte Änderung durch den Statusnamen permanent (HTTPStatuscode 301) aufklären:
Redirect permanent /nachrichten http://www.beispiel.de/news
Diese Anweisung leitet jede Anfrage auf das Verzeichnis nachrichten an die Adresse
http://www.beispiel.de/news weiter und fügt der Umleitung einen Vermerk hinzu, dass
die neue Adresse dauerhaft als Ersatz für die alte Adresse dienen wird.
seeother
Eigentlich soll der Client den Benutzer bei der Antwort eines Servers mit dem HTTPStatuscode 303 (See other, vgl. Anhang) mit einer entsprechenden Meldung über
diese sanfte Umleitung informieren. Der Statuscode verweist auf eine andere
Adresse, soll aber eigentlich kein richtiger Redirect sein. Praktisch leiten einige
Clients (u.a. IE 6, Lynx) den Benutzer ohne eine entsprechende Meldung direkt zum
neuen Speicherort der Informationen um. Andere Browser (u.a. Netscape 4) zeigen
eine Seite mit dem Hinweis, dass die Informationen an einem anderen Standort verfügbar sind.
gone
Wie der Name bereits andeutet, gibt es die angeforderte Information überhaupt nicht
mehr, auch unter keiner alternativen Adresse. Die Angabe des Parameters gone
erlaubt übrigens keine Angabe eines Ziels, da es kein alternatives Ziel mehr gibt. Ein
gültiger Aufruf mit dem Parameter gone sieht dementsprechend so aus:
Redirect gone /bilder
Sie können Umleitungen übrigens nicht nur durch den Apache definieren, sondern
auch durch die Entwicklung eines kleinen Programms, welches den Client umleitet.
Eine solche Umleitungsanweisung findet sich häufig im HTML-Quelltext einer Internetseite:
<meta http-equiv="refresh" content="3; URL=index.html">
272
5 Konfiguration
Diese Anweisung muss im Kopf (<Head>) einer HTML-Seite stehen und leitet den
Client nach einer Wartezeit von 3 Sekunden auf die Seite index.html weiter. Auch in
der populären Programmiersprache PHP lässt sich mit Hilfe des Header-Befehls eine
derartige Umleitung schnell realisieren:
<? header:("Location: http://www.beispiel.de/index.html"); ?>
Beachten Sie jedoch, dass vor dem Aufruf dieses Befehls keinerlei Daten an den Client
zurückgesendet werden dürfen, oder Sie erhalten eine Fehlermeldung (»headers
already sent by...«).
Anhänger der Programmiersprache Perl wissen natürlich schon, wie eine Umleitung
in ihrer Sprache realisiert werden kann:
#!/usr/bin/perl
$Ziel = "http://www.beispiel.de/";
print "Status: 302 Found\n";
print "Location: $Ziel\n";
print "URI: <$Ziel>\n";
print "Content-type: text/html\r\n\r\n";
Eine ganz fiese Umleitung ließe sich auch mit JavaScript realisieren, sofern der Benutzer die Verwendung von JavaScript aktiviert hat. Aus Gründen der Vollständigkeit
möchte ich auch dieses Beispiel kurz vorstellen, wobei ich aus Gewissensgründen
und aufgrund der clientseitig eventuell nicht vorhandenen JavaScript-Unterstützung
jedoch davon abraten möchte:
<SCRIPT LANGUAGE="JavaScript">
<!-function redirect()
{
window.location = "http://www.beispiel.de/"
}
setTimeout("redirect();", 5000)
//-->
</SCRIPT>
Auch dieses fiese Skript leitet den Benutzer nach fünf Sekunden (5000 Millisekunden)
an die neue Adresse weiter, sofern JavaScript vorhanden und aktiviert ist.
Bitte schauen Sie sich auch die nachfolgend besprochene Konfigurationsoption
RedirectMatch an, da diese Umleitungen auf der Basis von regulären Ausdrücken
erlaubt.
RedirectMatch
Leitet eine Anfrage durch Rückgabe eines HTTP-Statuscodes an eine interne oder
externe Adresse um, wobei die Verwendung von regulären Ausdrücken möglich ist.
5.2 Basiskonfiguration
273
Konfigurationsanweisung:
RedirectMatch
Syntax:
Redirect [Status] Suchmuster URL
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess Container
Anweisung aktiv:
nein
Die Konfigurationsanweisung RedirectMatch ist absolut identisch mit der bereits vorgestellten Option Redirect, allerdings erlaubt RedirectMatch zusätzlich die Verwendung von regulären Ausdrücken bei der Definition einer Umleitung. Die Verwendung von Statusnamen und nummerischen Statuscodes ist auch in einer
RedirectMatch-Anweisung möglich.
Ich hatte in meinen Erläuterungen zur Option Redirect eine fiktive Situation vorgestellt, in der der Downloadbereich einer Internetseite auf einen anderen Server verschoben worden ist. Mit einer RedirectMatch-Anweisung könnte man überprüfen,
welche Art von Datei durch einen Client angefordert worden ist, und nur Zugriffe auf
bestimmte Dateitypen wie .zip oder .exe auf einen neuen Downloadserver umleiten:
RedirectMatch (.*)\.(zip|exe)$ http://www.firma.de/download/$1.$2
Das erste in Klammern eingeschlossene Suchmuster gilt der durch einen Client angeforderten Datei, wobei durch die Anweisung (.*) bewusst jeder Dateiname mit diesem
Muster übereinstimmt. Die eigentliche Unterscheidung übernimmt hier das zweite
Suchmuster, welches überprüft, ob die nachgefragte Datei die Endung .zip oder .exe
hat, um gegebenenfalls auf die neue Adresse für Downloads http://www.firma.de/
download/$1.$2 zu verweisen. Die Variablen $1 und $2 referenzieren die in Klammern
eingeschlossenen Suchmuster und bezeichnen hier den Dateinamen ($1) und dessen
Endung ($2). Der erste Schrägstrich vor dem Punkt zwischen dem Dateinamen und
dessen Endung sorgt übrigens dafür, dass der Punkt auch wirklich als solcher interpretiert wird, denn ein Punkt hat in der Welt der regulären Ausdrücke eine besondere
Bedeutung, auf die ich in späteren Kapiteln noch eingehen werde.
Ein weiteres, sehr praxisnahes Beispiel wäre die Umstellung von PHP auf eine neuere
Version, wodurch die Skripte nicht mehr die Endung .php4, sondern nur noch .php
besitzen:
RedirectMatch permanent (.*)\.php4$ http://www.beispiel.de$1.php
Das in Klammern eingeschlossene Suchmuster passt auf jede Datei, die die Endung
.php4 besitzt und leitet jede Anfrage auf eine Datei mit einer solchen Endung an die
Adresse http://www.beispiel.de weiter, wobei dort nach einer gleichnamigen Datei mit
der Endung .php gesucht wird.
Eventuell haben Sie die Grundstruktur Ihrer Internetseite geändert und möchten alle
Anfragen auf das Verzeichnis images und die dort abgelegten Bilder auf ein neues
274
5 Konfiguration
Verzeichnis namens bilder umleiten. Dies könnte beispielsweise mit folgender Anweisung kurz und trotzdem effektiv realisiert werden:
RedirectMatch permanent ^/images/(.*)\.(.*) http://www.beispiel.de/bilder/$1.$2
Sofern im neuen Verzeichnis bilder dieselben Datei vorhanden sind, wie im ursprünglichen Verzeichnis images, werden die Clients auf die neue Adresse umgeleitet, wo sie
die gewünschten Informationen finden. Wenn es Dateien gibt, die im neuen Verzeichnis bilder eventuell nicht vorhanden sind, sollten Sie die Auswertung der Dateinamen
und -endungen eventuell übergehen:
RedirectMatch permanent ^/images/ http://www.beispiel.de/bilder/
Alternativ können Sie auch eine Auswertung der Dateiendungen vornehmen und
beispielsweise nur Anfragen auf Bilder mit der Dateiendung .jpg auf die neue
Adresse umleiten:
RedirectMatch permanent ^/images/(.*)\.jpg http://www.beispiel.de/bilder/$1.jpg
Eine ebenfalls sehr hübsche Verwendung des RedirectMatch-Befehls ist die Beantwortung von Attacken auf den Microsoft Internet Information Server, der uns in diesem
Buch schon des Öfteren beschäftigt hat:
RedirectMatch
RedirectMatch
RedirectMatch
RedirectMatch
RedirectMatch
RedirectMatch
(.*)/system32(.*) http://www.microsoft.com
(.*)/Admin.dll http://www.microsoft.com
(.*)/root.exe http://www.microsoft.com
(.*)/cmd.exe http://www.microsoft.com
(.*)/default.ida http://www.microsoft.com
(.*)/httpodbc.dll http://www.microsoft.com
Diese Anweisungen überprüfen, ob in der durch den Client angeforderten Adresse
Hinweise auf Angriffe auf den Internet Information Server gefunden werden können.
Wenn dies der Fall ist, werden derartige Anfragen direkt an den schuldigen Softwarehersteller weitergeleitet, da auf unserem Server leider kein Internet Information Server vorhanden ist. Diese sechs Anweisungen lassen sich elegant in eine einzige
packen:
RedirectMatch ^.*\.(exe|dll|ida).* http://www.microsoft.com
Auch diese Anweisung prüft, ob die Anfrage eines Clients aufgrund der nachgefragten Dateiendung einen potenziellen Angriff auf den Internet Information Server darstellt, und leitet einen Client gegebenenfalls zur Homepage des verursachenden Softwareherstellers um. Sollten Sie jedoch Dateien auf Ihrer Homepage anbieten, die
ebenfalls die besagten Endungen .exe, .dll oder .ida besitzen können, sollten Sie diese
Regel nicht benutzen und auf die bereits vorgestellten Regeln ausweichen.
5.2 Basiskonfiguration
275
Noch intelligentere Um- und Weiterleitungen können Sie übrigens mit mod_rewrite
erreichen, welches neben der Verwendung von regulären Ausdrücken zusätzlich die
Auswertung von Umgebungsvariablen und durch den Client übermittelte Informationen ermöglicht. Schauen Sie sich zu mod_rewrite einfach das entsprechende Kapitel
in diesem Buch an.
RedirectMatch ist trotzdem ein guter Ansatz, der im Gegensatz zu mod_rewrite sicherlich recht einfach handzuhaben ist und auch von Administratoren genutzt werden
kann, die bei der Verwendung von regulären Ausdrücken nicht unbedingt sattelfest
sind.
RedirectPermanent
Antwortet auf eine eingehende Anfrage mit einer dauerhaften Umleitung an eine
interne oder externe Adresse.
Konfigurationsanweisung:
RedirectPermanent
Syntax:
RedirectPermanent Url-Pfad URL
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess Container
Anweisung aktiv:
nein
RedirectPermanent ist identisch mit der Konfigurationsoption Redirect und deren Parameter permanent. Die Anweisung sendet auf eine eingehende Anfrage eine dauerhafte
Umleitung mit dem HTTP-Statuscode 301, die auf eine interne oder auch eine externe
Adresse verweisen kann:
RedirectPermanent /alt http://www.beispiel.de/neu
Alle eingehenden Anfragen für ein Verzeichnis namens alt werden auf die Adresse
http://www.beispiel.de/neu dauerhaft umgeleitet.
Denkbar wäre außerdem ein Szenario, in dem ein Kunde bereits bei seinem Zugangsprovider (z.B. T-Online, AOL) eine eigene Internetseite besitzt und bei Ihnen als Internet Provider eine eigene Domain reserviert hat. Sie können alle Anfragen auf die
Domain des Kunden an dessen Internetseite bei seinem Zugangsprovider durch eine
RedirectPermanent-Anweisung sehr geschickt umleiten:
RedirectPermanent / http://members.aol.com/baerchen23/
Der Kunde hat eine einprägsame Internetadresse http://www.beispielfirma.de und kann
die Homepage kostenlos bei seinem Zugangsprovider hinterlegen. Ein großer Nachteil dieser Methode ist natürlich die Sichtbarkeit der unprofessionell wirkenden
Homepage-Adresse bei dem Zugangsprovider, nachdem die Umleitung stattgefunden hat.
276
5 Konfiguration
RedirectTemp
Antwortet auf eine eingehende Anfrage mit einer zeitlich begrenzten Umleitung an
eine interne oder externe Adresse.
Konfigurationsanweisung:
RedirectTemp
Syntax:
RedirectTemp Url-Pfad URL
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess Container
Anweisung aktiv:
nein
RedirectTemp ist, ebenso wie RedirectPermanent, identisch mit der Konfigurationsanweisung Redirect und deren Parameter temp. Eingehende Anfragen werden mit
einer zeitlich begrenzten Umleitung durch den HTTP-Statuscode 302 auf eine alternative Adresse umgeleitet, wobei als Ziel sowohl die eigene Internetadresse als auch
eine externe Internetseite möglich sind.
Wenn Sie beispielsweise Wartungsarbeiten an Ihrem Server vornehmen möchten,
könnten Sie dies etwa durch folgende zeitlich begrenzte Umleitung realisieren:
RedirectTemp / http://www.beispiel.de/wartungsarbeiten.html
Alle eingehenden Anfragen werden auf die Adresse http://www.beispiel.de/
wartungsarbeiten.html umgeleitet, wo entsprechende Informationen zum Grund und
der voraussichtlichen Dauer der Wartungsarbeiten stehen könnten.
ScriptAlias
Bildet eine Url auf einen Standort innerhalb des lokalen Dateisystems ab und betrachtet das jeweilige Ziel als CGI-Skript.
Konfigurationsanweisung:
ScriptAlias
Syntax:
ScriptAlias Url-Pfad Dateipfad |
Verzeichnispfad
Standardwerte (Default):
ScriptAlias /cgi-bin/
»/usr/local/apache2/cgi-bin/«
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Mit dieser Konfigurationsoption können Sie ein Verzeichnis definieren, welches ausschließlich CGI-Skripte enthält. Dieses Verzeichnis wird oftmals cgi-bin genannt und
beim Zugriff auf eine Datei innerhalb dieses Verzeichnisses, wird die entsprechende
5.2 Basiskonfiguration
277
Datei als CGI-Skript interpretiert und ausgeführt, sofern die entsprechenden Berechtigungen vorhanden sind. In der Verwendung ist die ScriptAlias-Anweisung im Prinzip mit der bereits erläuterten Alias-Anweisung identisch:
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
Greift ein Client beispielsweise auf die Adresse http://www.beispiel.de/cgibin/printenv.pl zu, wird das CGI-Skript /usr/local/apache2/cgi-bin/printenv.pl ausgeführt,
sofern dieses vorhanden ist und über die entsprechenden Berechtigungen (755) verfügt.
ScriptAliasMatch
Bildet eine Url unter Verwendung von regulären Ausdrücken auf einen Standort
innerhalb des lokalen Dateisystems ab und betrachtet das jeweilige Ziel als CGISkript.
Konfigurationsanweisung:
ScriptAliasMatch
Syntax:
ScriptAliasMatch Suchmuster Url-Pfad
Dateipfad | Verzeichnispfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_alias
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
ScriptAliasMatch ist mit der Option ScriptAlias identisch, allerdings erlaubt ScriptAliasMatch zusätzlich die Verwendung von regulären Ausdrücken bei der Abbildung
einer URL auf einen lokalen Datei- oder Verzeichnispfad.
Um für Ihre Internetseite ein cgi-bin-Verzeichnis zu erstellen, können Sie entweder die
vorgestellte ScriptAlias-Anweisung benutzen oder auf eine alternative ScriptAliasMatch-Anweisung setzen:
ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache2/cgi-bin$1
Jede Anfrage, die eine Datei im Verzeichnis cgi-bin Ihrer Internetseite aufruft, wird
unter /usr/local/apache2/cgi-bin gesucht und als CGI-Skript ausgeführt, sofern die Datei
vorhanden ist und über die entsprechenden Berechtigungen verfügt.
Wenn Sie beispielsweise für Ihre lokalen Benutzer individuelle Verzeichnisse der
Form http://www.beispiel.de/~benutzername/ eingerichtet haben, können Sie mit folgendem Konstrukt den Benutzern die Möglichkeit der Ausführung von CGI-Skripten
einräumen:
ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*) /home/$1/cgi-bin/$2
278
5 Konfiguration
Dieses zugegebenermaßen recht komplizierte Konstrukt sorgt dafür, dass die Anforderung eines CGI-Skriptes der Form http://www.beispiel.de/~benutzername/cgi-bin/test.cgi
auf ein Verzeichnis namens /home/benutzername/cgi-bin verweist und dort auf die Datei
test.cgi. Zusätzlich wird die resultierende Datei test.cgi als CGI-Skript behandelt.
Die in der Konfigurationsanweisung ScriptAliasMatch in Klammern eingeschlossenen
Werte definieren reguläre Ausdrücke (regular expressions, Suchmuster), auf die im
zweiten Teil der Anweisung durch Benutzung der Variablen $1 und $2 zurückgegriffen werden kann, wobei die Variablen $1 und $2 natürlich für den Wert des ersten
bzw. des zweiten Suchmusters stehen. Das erste Suchmuster $1 fragt den übermittelten Benutzernamen ab und das zweite Suchmuster $2 steht für den Namen des aufgerufenen CGI-Skriptes. Diese Werte werden in den Zielpfad eingebaut und ersetzen
dort den Benutzernamen (/home/benuztername) sowie den angeforderten Dateinamen
(cgi-bin/dateiname). Ein Zugriff auf die Adresse http://www.beispiel.de/~peter/cgibin/test.cgi wird auf den lokalen Pfad /home/peter/cgi-bin/test.cgi abgebildet und führt
das Skript aus, sofern die entsprechenden Berechtigungen vorhanden sind.
UserDir
Legt das Verzeichnis fest, in dem die lokalen Benutzer ihre im Internet zu veröffentlichenden Informationen ablegen können.
Konfigurationsanweisung:
UserDir
Syntax:
UserDir Verzeichnisname
Standardwerte (Default):
UserDir public_html
Enthalten in Modul:
mod_userdir
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die Konfigurationsanweisung UserDir ist die einzige durch das Modul mod_userdir
verfügbare Direktive und spezifiziert das lokale Verzeichnis, in dem die lokalen Benutzer Informationen speichern können, die im Internet unter der Adresse
http://www.beispiel.de/~benutzername abrufbar sein sollen. Im einfachsten Fall ist dies ein
Unterverzeichnis des entsprechenden Heimatverzeichnisses des lokalen Benutzers:
UserDir public_html
Mit dieser Anweisung ist es den lokalen Benutzern möglich, ein Verzeichnis namens
public_html in ihrem Heimatverzeichnis zu erzeugen und dort Informationen abzulegen, die sie im Internet veröffentlichen möchten.
Greift ein Client beispielsweise auf die Adresse http://www.beispiel.de/~peter/ zu,
schaut der Apache in der Passwortdatei des Systems /etc/passwd nach dem Heimatverzeichnis des Benutzers peter (z.B. /home/peter) und gibt die angeforderte Datei aus
dem Unterverzeichnis public_html des Heimatverzeichnisses /home/peter zurück. Eine
Anfrage nach http://www.beispiel.de/~peter/bild23.jpg würde deshalb auf die Datei
/home/peter/public_html/bild23.jpg verweisen.
5.2 Basiskonfiguration
279
Sie können jedoch auch einen absoluten Pfad für die UserDir-Anweisung benutzen:
UserDir /usr/home
Der angeforderte Benutzername wird automatisch an diesen Pfad angehängt, so dass
eine Anfrage für die Datei http://www.beispiel.de/~peter/bild23.jpg in diesem Fall im
Verzeichnis /usr/home/peter auf die Datei bild23.jpg verweisen würde. Bei der Angabe
eines absoluten Verzeichnispfades überprüft der Apache dessen Existenz und gibt
gegebenenfalls eine Fehlermeldung zurück, wenn ein Verzeichnis nicht existiert.
Alternativ kann auch ein Platzhalter bei der Angabe des Benutzerverzeichnisses verwendet werden, der automatisch durch den entsprechenden Benutzernamen ersetzt
wird:
UserDir /usr/home/*/web
Eine Anfrage auf eine Adresse wie http://www.beispiel.de/~peter/bild23.jpg würde auf
das Verzeichnis /usr/home/peter/web verweisen und dort auf die Datei bild23.jpg. Der
Platzhalter »*« wird also durch den Benutzernamen ersetzt, dessen persönliche Internetseite ein Client durch seine Anfrage angefordert hat.
Die UserDir-Anweisung kann übrigens auch auf einen anderen Server verweisen,
wenn das Heimatverzeichnis des entsprechenden Benutzers nicht auf dem lokalen
System liegt. Folgende Anweisung ist auch denkbar:
UserDir http://mitarbeiter.firma.de/~*/
Eine Anfrage auf die Internetseite http://www.beispiel.de/~peter/ würde somit automatisch auf die Adresse http://mitarbeiter.firma.de/~peter/ weitergeleitet.
Wenn Sie die Verwendung von individuellen Adressen für Ihre lokalen Benutzer der
Form http://www.beispiel.de/~benutzername/ ausschalten möchten, müssen Sie dies
explizit angeben:
UserDir disabled
Sie können individuelle Benutzerverzeichnisse auch für einzelne Benutzer freischalten:
UserDir disabled
UserDir enable hans peter franz
Diese Anweisung würde individuelle Benutzeradressen der Form http://www.beispiel.
de/~benutzername/ für alle Benutzer verbieten, nur die drei Benutzer Hans, Peter und
Franz könnten individuelle Informationen im Internet veröffentlichen. Sie können
auch persönliche Benutzerverzeichnisse für alle Benutzer global erlauben und für einzelne Benutzer deaktivieren:
UserDir public_html
UserDir disabled hans peter root
280
5 Konfiguration
Diese Einstellung erlaubt es allen lokalen Benutzern, Informationen im Internet unter
einer Adresse der Form http://www.beispiel.de/~benutzername/ zu veröffentlichen,
außer den Benutzern Hans und Peter. Ebenso ist es untersagt, dass der root-Benutzer
Informationen im Internet veröffentlicht, und zumindest diese Einstellung sollten Sie
auf jeden Fall aus Sicherheitsgründen in Ihre Konfiguration aufnehmen!
Sie können außerdem die Kurzschreibweise enable bzw. disable benutzen, wenn Ihnen
die Wörter enabled und disabled nicht gefallen.
5.2.8
Handler
Seit der Version 1.1 bietet der Apache die Möglichkeit, Handler zu benutzen. Ein
Handler ist dabei eine vordefinierte Aktion, die ausgeführt werden kann, wenn ein
Client auf einen bestimmen Dateitypen oder einen bestimmten Bereich einer Webseite zugreift. Intern verfügt der Apache bereits über sieben Handler, die durch die
verschiedensten Module bereitgestellt werden. Ein Beispiel für einen Handler ist cgiscript, der dafür sorgt, dass alle Dateien mit der Endung .cgi als CGI-Skripte interpretiert und ausgeführt werden. Der Vorteil eines Handlers liegt darin, dass die ihm
zugeordneten Dateien nicht mehr direkt vom Apache an den Client geliefert werden.
Dadurch ergibt sich für Sie die Möglichkeit, nach Belieben eigene und selbst entwickelte Aktionen mit den besagten Dateien durchzuführen. Solche Aktionen könnten
z.B. Daten hinzufügen oder entfernen, bevor diese an den Client gesendet werden.
Beispiele zur Entwicklung eigener Handler folgen am Ende dieses Kapitels.
Interne Handler
Der Apache verfügt nach der Installation bereits über sieben interne Handler, die die
verschiedensten Funktionen wahrnehmen:
default-handler
Dies ist der Standardhandler, der immer aktiv wird, wenn statische Informationen
abgerufen werden. Der Handler braucht nicht explizit aktiviert zu werden, es sei
denn, in einer übergeordneten Anweisung wurde ein anderer Handler definiert und
Sie möchten den ursprünglichen Stand wiederherstellen.
send-as-is
Das Modul mod_asis stellt einen Handler bereit, der es erlaubt, Dateien »so wie sie
sind« (send-as-is) an den Client zu liefern. Die entsprechenden Dateien müssen die
HTTP-Header bereits enthalten, d.h. der Apache fügt den ausgelieferten Informationen keine Daten mehr hinzu.
cgi-script
Dieser Handler wird durch mod_cgi bereitgestellt und interpretiert eine angegebene
Datei als CGI-Skript, auch wenn diese nicht in dem normalerweise für CGI-Skripte
vorgesehenen Verzeichnis gespeichert ist (z.B. cgi-bin). CGI-Skripte können dadurch
in jedem beliebigen Verzeichnis gespeichert und benutzt werden.
imap-file
5.2 Basiskonfiguration
281
Inzwischen veraltet, stellt dieser Handler die Möglichkeit zur Verfügung, bestimmte
Dateien als Konfigurationsdateien von Image-Maps zu benutzen. Weitere Informationen zur Verwendung von Image-Maps finden Sie im Handbuch des Apache unter
http://httpd.apache.org/docs-2.0/mod/mod_imap.html.
server-info
Durch das Modul mod_info wird ein Handler namens server-info bereitgestellt, der
dafür sorgt, dass Informationen über die Konfiguration des Servers unter einer zu
definierenden Adresse abrufbar sind.
server-status
Statusinformationen über den Server können unter einer zu definierenden Adresse
abgerufen werden, die durch den Handler server-status bereitgestellt werden.
type-map
Durch das Modul mod_negotiation wird der Handler type-map zur Verfügung
gestellt, der für die Kennzeichnung von Map-Dateien genutzt werden kann. Weitere
Informationen dazu finden Sie in den Erläuterungen zu den von mod_negotiation
bereitgestellten Direktiven.
Die Konfigurationsanweisungen Add- und RemoveHandler habe ich bereits in den
Erläuterungen zu mod_mime vorgestellt. Die nachfolgenden drei Anweisungen vervollständigen die Liste der zur Verwendung von Handlern nötigen Konfigurationsschritte:
SetHandler
Bestimmt für alle Dateien in einem Verzeichnis einen gemeinsamen Handler.
Konfigurationsanweisung:
SetHandler
Syntax:
SetHandler Handlername
Standardwerte (Default):
# SetHandler server-status (mehrfach vorhanden)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, Virtual-Host-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
nein (auskommentiert)
Die Konfigurationsanweisung SetHandler ist mit der Anweisung AddHandler funktional identisch, allerdings definiert SetHandler für alle Dateien in einem Verzeichnis
einen gemeinsamen Handler. Sie sollten die Anweisung daher in einem begrenzenden <Directory>-, <Location>- oder <Files>-Container verwenden, um die ungewollte
Anwendung eines Handlers zu vermeiden. Ein Beispiel:
<Location /serverstatus>
SetHandler server-status
</Location>
282
5 Konfiguration
Diese Konfiguration stellt Statusinformationen über den Server unter der Adresse
/serverstatus zur Verfügung. In der Praxis wird die SetHandler-Anweisung oft in
Zusammenspiel mit der RemoveHandler-Anweisung verwendet, um eine vorherige
Definition eines Handlers für einen bestimmten Bereich zu deaktivieren:
<Directory /usr/local/apache2/cgi-bin>
Options +ExecCGI
SetHandler cgi-script
RemoveHandler .txt
</Directory>
Die Anweisungen sorgen dafür, dass alle Dateien im Verzeichnis /usr/local/apache2/cgibin als CGI-Skripte betrachtet werden, außer solche mit der Endung .txt. In der Praxis
wird es wahrscheinlich seltener vorkommen, dass im Verzeichnis cgi-bin auch Textdateien abgelegt sind, aber das Beispiel soll einfach die Verwendung von Set- und
RemoveHandler verdeutlichen.
Ein Beispiel, welches in der Realität sicherlich öfters vorkommt, ist die Bereitstellung
von CGI-Funktionalitäten für die individuellen Verzeichnisse der Benutzer. Dazu
könnte folgende <Directory>-Anweisung genutzt werden:
<Directory /home/*/public_html/cgi-bin>
Options +ExecCGI
SetHandler cgi-script
</Directory>
Nach dem Neustart des Apache können die lokalen Benutzer im Unterverzeichnis
cgi-bin ihres individuellen Benutzerverzeichnisses (z.B. http://www.beispiel.de/
~benutzername/) auch CGI-Skripte ausführen.
Action
Deklaration eines Handlers oder Zuweisung eines CGI-Skriptes zu einem bestimmten
MIME-Typen.
Konfigurationsanweisung:
Action
Syntax:
Action MIME-Typ CGI-Skript (oder)
Action Handlername CGI-Skript
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_actions
Kontext:
Server-Kontext, Virtual-Host-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess-Container
Anweisung aktiv:
nein
Die Action-Anweisung ermöglicht Ihnen zwei grundverschiedene Funktionen zu realisieren: Erstens können Sie damit einem MIME-Typen ein festes CGI-Skript zuweisen, welches bei einem Zugriff auf einen derartigen Dateityp automatisch ausgeführt
5.2 Basiskonfiguration
283
wird, oder Sie benutzen die Action-Anweisung, um den Namen und den Pfad eines
neuen Handlers zu definieren. In den Erklärungen zur Konfigurationsanweisung
AddHandler habe ich folgendes Beispiel vorgestellt:
Action fussnote /cgi-bin/fussnote.pl
AddHandler fussnote .html .htm
Dieses Beispiel sorgt dafür, dass in dem jeweiligen Kontext alle Dateien mit der
Endung .html und .htm durch den Handler fussnote verarbeitet werden. Der Handler
fussnote verweist hier auf ein Perl-Skript im cgi-bin Verzeichnis, welches allen ihm
übergebenen Dateien eine spezielle Fußnote beifügt. Den Quellcode für das Programm finden Sie in den Erläuterungen zur AddHandler-Anweisung.
Die Action-Anweisung kann auch dafür genutzt werden, einem bestimmten MIMETypen ein festes CGI-Skript zuzuweisen, welches bei jedem Zugriff auf den entsprechenden Dateitypen ausgeführt wird:
Action image/gif /cgi-bin/bilder.pl
Diese Anweisung definiert für jede Bilddatei mit der Endung .gif ein Perl-Skript
namens bilder.pl, welches bei jedem Zugriff auf eine solche Datei ausgeführt wird.
Eine solche Anweisung könnte etwa dazu genutzt werden, abwechselnd verschiedene Werbebanner einzublenden:
#!/usr/bin/perl
@bildersammlung = ("A.gif","B.gif","C.gif","D.gif","E.gif");
print "Content-Type: image/gif\n\n";
print "<img src='$bildersammlung[rand(5)]'>\n";
Das Perlskript definiert zunächst einen Array namens bildersammlung mit Bildern, die
später nach dem Zufallsprinzip ausgewählt und angezeigt werden. Danach sendet es
dem Client eine Information über den Inhalt der nachfolgenden Daten, sucht aus der
Liste der fünf zur Verfügung stehenden Bildern eines aus und stellt dieses Bild dar.
Script
Aktiviert ein CGI-Skript für eine bestimmte Methode (z.B. PUT, GET etc.).
Konfigurationsanweisung:
Script
Syntax:
Script Methode CGI-Skript
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_actions
Kontext:
Server-Kontext, Virtual-Host-Kontext,
<Directory>-Container
Anweisung aktiv:
nein
284
5 Konfiguration
Die Script-Anweisung definiert ein CGI-Skript, welches bei der Verwendung einer
bestimmten HTTP-Methode ausgeführt wird. Als Parameter erwartet diese Option
eine HTTP-Methode und den Pfad eines CGI-Skriptes, welches bei einem Zugriff auf
die angegebene Methode ausgeführt werden soll. Ein Beispiel:
Script GET /cgi-bin/get.cgi
Mit dieser Anweisung wird bei einem Zugriff mit der GET-Methode das CGI-Skript
get.cgi ausgeführt, welches im Verzeichnis cgi-bin der lokalen Apache-Installation
gespeichert ist. Den Namen der HTTP-Methode sollten Sie dabei immer in Großbuchstaben angeben. Hinweis: Bei der Verwendung der Methode GET muss der Anfrage
zusätzlich ein Parameter übergeben werden, damit das entsprechende CGI-Skript
aktiv wird. Um das CGI-Skript get.cgi aus unserem vorherigen Beispiel zu aktivieren,
müsste die Anfrage eines Clients wie folgt aussehen:
GET /beispiel.html?parameter HTTP/1.1
5.2.9
Verzeichnisindizes und Listings
DirectoryIndex
Definiert eine Liste mit Indexdateien nach denen gesucht wird, falls ein Client ein
Verzeichnis anfordert.
Konfigurationsanweisung:
DirectoryIndex
Syntax:
DirectoryIndex Dateiname
Standardwert (Default):
DirectoryIndex index.html index.html.var
Enthalten in Modul:
mod_dir
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja
Die DirectoryIndex-Anweisung definiert eine Liste von Dateien, nach denen der Server
suchen soll, falls ein Client ein Verzeichnis anfordert, in dem dieser seiner Anfrage
einen finalen Forwardslash hinzufügt (z.B. /daten/) oder überhaupt keine Zieldatei
übermittelt. In der Liste der möglichen Indexdateien muss ein Dateiname in relativer
Form zum angeforderten Verzeichnis angegeben werden. Dabei können auch mehrere Indexdateien angegeben werden, wobei der Server die erste Datei, die er findet,
an den Client sendet. Sofern keine der angegebenen Dateien existiert und die Option
Indexes gesetzt ist, erzeugt der Server eine Liste der in dem angeforderten Verzeichnis
vorhandenen Dateien und Verzeichnisse (so genanntes Directory- oder Verzeichnislisting). Ein Beispiel:
DirectoryIndex index.html
5.2 Basiskonfiguration
285
In diesem Fall würde eine Anfrage für http://www.beispiel.de/daten/ die Datei
http://www.beispiel.de/daten/index.html zurückliefern, sofern diese existiert. Falls diese
nicht existiert, wird in Abhängigkeit von der Options-Anweisung ein Verzeichnislisting erzeugt. Sie können übrigens auch mehrere Indexdateien angeben und sogar
PHP- bzw. CGI-Skripte:
DirectoryIndex index.html index.php /cgi-bin/index.pl
Durch eine solche Einstellung würde der Server zuerst nach einer Datei namens
index.html suchen, bevor er das PHP-Skript index.php oder das CGI-Skript index.pl
suchen würde. Hinweis: Auch lokale URL-Pfade (z.B. /cgi-bin/index.pl) sind als
Indexdatei möglich.
In der Praxis findet man häufig solche Konstrukte:
DirectoryIndex index.html index.html.var index.php main.php default.htm index.htm
main.html default.html
AddAlt
In Abhängigkeit eines Dateinamens kann bei der Auflistung eines Verzeichnisinhalts
anstatt eines kleinen Icons eine alternative Beschreibung angezeigt werden.
Konfigurationsanweisung:
AddAlt
Syntax:
AddAlt Beschreibung Dateiname
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
nein
Mit dieser Anweisung können Sie bei der Auflistung eines Verzeichnisinhalts einen
alternativen Text bestimmen, der in Abhängigkeit des vorliegenden Dateitypen angezeigt wird. Dabei erwartet die Anweisung eine Beschreibung sowie einen Dateinamen, für den diese Beschreibung gelten soll. Die Beschreibung muss immer in
Anführungszeichen, der Dateiname kann sowohl in vollständiger (z.B. beispiel.gif)
oder partieller Form (z.B. a*.gif) und unter Verwendung von Jokerzeichen (z.B. *.pdf)
angegeben werden.
Einige Beispiele:
AddAlt "PDF Datei" *.pdf
AddAlt "Komprimierte Daten" *.zip *.rar *.Z *.tar.gz
AddAlt "Bilddatei im GIF-Format" beispiel.gif
Das erste Beispiel führt dazu, dass die Beschreibung »PDF-Datei« ausgegeben wird,
sofern eine beliebige Datei mit der Endung .pdf vorliegt. Im nächsten Beispiel wird
die Beschreibung »Komprimierte Daten« benutzt, um eine Reihe von Dateiformaten
286
5 Konfiguration
(.zip, .rar, .Z, .tar.gz) zu beschreiben. Das letzte Beispiel gilt nur für die Datei beispiel.gif und bestimmt für diese Datei die Beschreibung »Bilddatei im GIF-Format«.
Hinweis: Sie müssen für das jeweilige Verzeichnis den Parameter FancyIndexing (vgl.
IndexOptions-Anweisung) eingeschaltet haben, damit diese Anweisung aktiv wird.
AddAltByEncoding
In Abhängigkeit einer MIME-Kodierung kann bei der Auflistung eines Verzeichnisinhalts anstatt eines kleinen Icons eine alternative Beschreibung angezeigt werden.
Konfigurationsanweisung:
AddAltByEncoding
Syntax:
AddAltByEncoding Beschreibung MIMEEnkodierungstyp
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
nein
Diese Anweisung ist syntaktisch und funktional mit der bereits beschriebenen AddAlt-Anweisung identisch. Allerdings definiert diese bei der Auflistung eines Verzeichnisinhalts einen alternativen Text in Abhängigkeit zur vorliegenden MIMEKodierung. Dabei erwartet die Anweisung eine Beschreibung sowie eine MIMEKodierung, für die diese Beschreibung gelten soll. Die Beschreibung muss immer in
Anführungszeichen angegeben werden. Ein Beispiel:
AddAltByEncoding "gzip-komprimierte Datei" x-gzip
Die Anweisung erzeugt die Beschreibung »gzip-komprimierte Datei« für die MIMEKodierung x-gzip. Hinweis: Sie müssen für das jeweilige Verzeichnis den Parameter
FancyIndexing (vgl. IndexOptions-Anweisung) eingeschaltet haben, damit diese
Anweisung aktiv wird.
AddAltByType
In Abhängigkeit eines MIME-Typen kann bei der Auflistung eines Verzeichnisinhalts
anstatt eines kleinen Icons eine alternative Beschreibung angezeigt werden.
Konfigurationsanweisung:
AddAltByType
Syntax:
AddAltByType Beschreibung MIME-Typ
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
nein
5.2 Basiskonfiguration
287
Diese Anweisung ist syntaktisch und funktional identisch mit der bereits beschriebenen AddAltByEncoding-Anweisung, allerdings definiert diese bei der Auflistung eines
Verzeichnisinhalts einen alternativen Text in Abhängigkeit zum vorliegenden MIMETypen. Dabei erwartet die Anweisung eine Beschreibung sowie einen MIME-Typen,
für den diese Beschreibung gelten soll. Die Beschreibung muss immer in Anführungszeichen angegeben werden. Ein Beispiel:
AddAltByType "PDF-Datei" application/pdf
Die Anweisung erzeugt die Beschreibung »PDF-Datei« für alle Dateien mit dem
MIME-Typen application/pdf, d.h. alle Dateien im beliebten PDF-Format. Hinweis:
Sie müssen für das jeweilige Verzeichnis den Parameter FancyIndexing (vgl. IndexOptions-Anweisung) eingeschaltet haben, damit diese Anweisung aktiv wird.
AddDescription
Definiert einen beschreibenden Text bei der Auflistung eines Verzeichnisinhalts für
eine Datei.
Konfigurationsanweisung:
AddDescription
Syntax:
AddDescription Beschreibung Datei
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
nein
Für eine angegebene Datei kann diese Anweisung eine Beschreibung definieren.
Dabei erwartet die Anweisung eine Beschreibung, die immer in Anführungszeichen
eingeschlossen sein muss sowie eine Datei, für die diese Beschreibung gelten soll. Der
Dateiname kann sowohl in vollständiger (z.B. beispiel.gif) oder partieller Form (z.B.
a*.gif) und unter Verwendung von Jokerzeichen (z.B. *.pdf) angegeben werden.
Ein Beispiel:
AddDescription "Handbuch des Apache 2" apache.pdf
Die Anweisung erzeugt für die Datei apache.pdf die Beschreibung »Handbuch des
Apache 2«. Hinweis: Die Beschreibung kann auch HTML-Elemente enthalten. Sollte
Ihre Beschreibung jedoch zu lang sein, wird diese abgeschnitten und führt eventuell
dazu, dass der Rest des Verzeichnislistings nicht korrekt dargestellt wird. Außerdem
müssen Sie für das jeweilige Verzeichnis den Parameter FancyIndexing (vgl. IndexOptions-Anweisung) eingeschaltet haben, damit diese Anweisung aktiv wird.
288
5 Konfiguration
AddIcon
Bestimmt, welches Icon für eine Datei angezeigt werden soll.
Konfigurationsanweisung:
AddIcon
Syntax:
AddIcon Datei Dateiendung
Standardwert (Default):
AddIcon /icons/binary.gif .bin .exe
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja (mehrfach vorhanden)
Sofern Sie für ein Verzeichnis FancyIndexing eingeschaltet haben (vgl. IndexOptionsAnweisung), können Sie mit dieser Option ein Icon bestimmen, welches als bildliche
Beschreibung für eine Dateiendung benutzt werden soll. Dabei können Sie als Dateiendung entweder ^^DIRECTORY^^ für ein Verzeichnis oder ^^BLANKICON^^
benutzen, um die Verzeichnisauflistung ordentlich zu formatieren. Alternativ können
Sie auch eine Dateierweiterung, ein Jokerzeichen oder einen vollständigen bzw. partiellen Dateinamen angeben. Ein Beispiel:
AddIcon /icons/binary.gif .bin .exe
Die Anweisung ordnet allen Dateien mit der Endung .bin oder .exe ein beschreibendes
Bild namens binary.gif aus dem Verzeichnis /icons/ zu. Hinweis: Die Dateiendung
kann auch Jokerzeichen wie »*« enthalten, so dass das zugewiesene Icon für alle
zutreffenden Dateiendungen gilt. Dennoch sollten Sie die AddIconByType-Anweisung
der AddIcon-Anweisung vorziehen.
AddIconByEncoding
Bestimmt, welches Icon für einen bestimmten Kodierungstyp angezeigt werden soll.
Konfigurationsanweisung:
AddIconByEncoding
Syntax:
AddIconByEncoding Datei Mime-Enkodierungstyp
Standardwert (Default):
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja (mehrfach vorhanden)
5.2 Basiskonfiguration
289
Wenn Sie FancyIndexing (vgl. IndexOptions-Anweisung) eingeschaltet haben, kann mit
dieser Anweisung ein Icon definiert werden, welches in Abhängigkeit zu einem
bestimmten MIME-Kodierungstypen angezeigt wird:
AddIconByEncoding /icons/komprimiert.png x-compress
Diese Anweisung ordnet einer Datei mit dem MIME-Kodierungstypen x-compress das
Icon /icons/komprimiert.png zu.
AddIconByType
Bestimmt, welches Icon für einen bestimmten MIME-Typen angezeigt werden soll.
Konfigurationsanweisung:
AddIconByType
Syntax:
AddIconByType Datei Mime-Typ
Standardwert (Default):
AddIconByType (TXT,/icons/text.gif) text/*
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja (mehrfach vorhanden)
Wenn Sie FancyIndexing (vgl. IndexOptions-Anweisung) eingeschaltet haben, kann mit
dieser Anweisung ein Icon definiert werden, welches in Abhängigkeit zu einem
bestimmten MIME-Typen angezeigt wird:
AddIconByType /icons/text.png text/html
Diese Anweisung ordnet das Icon text.png aus dem Verzeichnis /icons/ allen Dateien zu,
deren Inhalt vom Typ text/html ist. Hinweis: Der MIME-Typ kann auch Jokerzeichen
wie »*« enthalten, so dass das zugewiesene Icon für alle zutreffenden Dateitypen gilt.
HeaderName
Setzt eine Datei, die oberhalb eines Verzeichnislistings angezeigt werden soll.
Konfigurationsanweisung:
HeaderName
Syntax:
HeaderName Dateiname
Standardwert (Default):
HeaderName HEADER.html
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja
Die Anweisung HeaderName bestimmt eine Datei, die oberhalb eines Verzeichnislistings angezeigt werden soll. Diese Datei ist gleichzeitig der einzige Parameter der
Anweisung und muss in relativer Form zu dem aufgerufenen Verzeichnis angegeben
werden. Dabei muss die Datei einen beliebigen textbasierten Inhalt (z.B. test/html,
290
5 Konfiguration
text/plain) haben. Die Verwendung eines CGI-Skriptes ist ebenfalls möglich, wenn
der Dateiname des CGI-Skriptes (nicht dessen Ausgabe!) als Textdatei (AddType
text/html .cgi) definiert wurde. Ein Beispiel:
HeaderName seitenkopf.html
Durch diese Konfiguration würde oberhalb jedes Verzeichnislistings die Datei seitenkopf.html angezeigt werden. Hinweise: Sofern der Parameter MultiViews der OptionsAnweisung eingeschaltet ist, führt der Apache Content Negotiation durch. Sollte der
Dateiname auf eine statische Datei, d.h. nicht auf ein CGI-Skript verweisen und sollte
zusätzlich ebenfalls der Parameter Includes der Options-Anweisung aktiviert sein,
wird die Datei nach Server-Side Include Befehlen untersucht. Sollte die durch die HeaderName-Anweisung angegebene Datei HTML-Befehle enthalten, können Sie mit dem
Parameter +SuppressHTMLPreamble der IndexOptions-Anweisung erreichen, dass
diese Befehle nicht interpretiert werden.
ReadmeName
Setzt eine Datei, die unterhalb eines Verzeichnislistings angezeigt werden soll.
Konfigurationsanweisung:
ReadmeName
Syntax:
ReadmeName Dateiname
Standardwert (Default):
ReadmeName README.html
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja
Die Anweisung ReadmeName ist syntaktisch und funktional mit der HeaderNameAnweisung identisch, allerdings bestimmt diese eine Datei, die unterhalb eines Verzeichnislistings angezeigt werden soll. Diese Datei ist gleichzeitig auch der einzige
Parameter der Anweisung und muss in relativer Form zum aufgerufenen Verzeichnis
angegeben werden. Dabei muss die Datei einen beliebigen textbasierten Inhalt (z.B.
test/html, text/plain) haben. Die Verwendung eines CGI-Skriptes ist ebenfalls möglich, wenn der Dateiname des CGI-Skriptes (nicht dessen Ausgabe!) als Textdatei
(AddType text/html .cgi) definiert wurde. Ein Beispiel:
ReadmeName fussnote.html
Durch diese Konfiguration würde unterhalb jedes Verzeichnislistings die Datei fussnote.html angezeigt werden. Hinweis: Sofern der Parameter MultiViews der OptionsAnweisung eingeschaltet ist, führt der Apache Content Negotiation durch. Sollte der
Dateiname auf eine statische Datei, d.h. nicht auf ein CGI-Skript verweisen und sollte
zusätzlich ebenfalls der Parameter Includes der Options-Anweisung aktiviert sein,
wird die Datei nach Server-Side Include Befehlen untersucht. Sollte die durch ReadmeName angegebene Datei HTML-Befehle enthalten, können Sie mit dem Parameter
+SuppressHTMLPreamble der IndexOptions-Anweisung erreichen, dass diese Befehle
nicht interpretiert werden.
5.2 Basiskonfiguration
291
IndexIgnore
Definiert eine Liste von Dateien, die bei einem Verzeichnislisting nicht angezeigt werden sollen.
Konfigurationsanweisung:
IndexIgnore
Syntax:
IndexIgnore Dateiname
Standardwert (Default):
IndexIgnore .??* *~
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja
Mit Hilfe der IndexIgnore-Anweisung können Sie eine Liste von Dateien definieren,
die in einem Verzeichnislisting nicht angezeigt werden sollen. Als einzigen Parameter
erwartet diese Anweisung eine Liste von Dateinamen, wobei es sich dabei um einen
vollständigen oder partiellen Dateinamen, eine Dateiendung oder auch ein Dateimuster handeln darf. Ein Beispiel:
IndexIgnore README .htaccess *~
Diese Anweisung sorgt dafür, dass Dateien mit dem Namen README und .htaccess
nicht angezeigt werden, wenn der Inhalt eines Verzeichnisses aufgelistet wird.
Zusätzlich werden alle Dateien verborgen, die einen beliebigen Namen haben und
mit einer Tilde enden. In der Praxis sollten Sie etwa folgende Anweisung benutzen:
IndexIgnore .??* *~ *.bak *.BAK *.inc
Dateien, die mit einem Punkt beginnen, werden nicht angezeigt. Außerdem werden
Dateien mit der Endung .BAK und .bak sowie .inc versteckt. Sollten Sie Zusatzprogramme und Dienste wie CVS oder DAV benutzen, fügen Sie von dieser Erweiterung
erstellte Dateien und Endungen ebenfalls dieser Anweisung hinzu.
IndexOptions
Nimmt verschiedene Einstellungen für die Verzeichnisindizierung vor.
Konfigurationsanweisung:
IndexOptions
Syntax:
IndexOptions [+|-] Option
Standardwert (Default):
IndexOptions FancyIndexing VersionSort
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, .htaccess-Container
Anweisung aktiv:
ja
292
5 Konfiguration
Die IndexOptions-Anweisung bestimmt das Verhalten des Servers bei der Verzeichnisindizierung. Dabei erwartet die Anweisung die Angabe einer oder auch mehrerer
der nachfolgender Optionen:
DescriptionWidth=[x|*]
Die Option bestimmt die Größe (in Bytes) der Spalte, die die Beschreibung eines Verzeichnisses oder einer Datei enthält. Zwei Beispiele:
DescriptionWidth=30
DescriptionWidth=*
Die erste Zeile definiert eine maximale Größe von 30 Bytes für die Beschreibungsspalte. Durch die zweite Zeile wird die Größe auf den Wert gesetzt, der nötig ist, um
die längste Beschreibung ordentlich darzustellen. Ein weiteres Beispiel:
-DescriptionWidth
In dieser Einstellung wird die Größe der Beschreibungsspalte durch mod_autoindex
automatisch bestimmt. Dieses Verhalten legt mod_autoindex auch an den Tag, falls
die Option DescriptionWidth überhaupt nicht gesetzt ist.
FancyIndexing
Mit dieser Option schalten Sie die Verwendung der hier vorgestellten Konfigurationsanweisungen ein. Ist diese Option ausgeschaltet, haben die in diesem Part vorgestellten Anweisungen keine Wirkung.
FoldersFirst
Sofern diese Option eingeschaltet ist, werden die Unterverzeichnisse zuerst aufgelistet, gefolgt von den normalen Dateien innerhalb eines Verzeichnisses. Diese Option
funktioniert nur, wenn der Parameter FancyIndexing eingeschaltet ist.
HTMLTable (Option ist noch experimentell!)
Beim Betrieb unter bestimmten Plattformen (z.B. WinNT) kann es vorkommen, dass
die Dateinamen nicht ordentlich dargestellt werden können, da die Schreibweise der
Dateinamen höchst unterschiedlich ist. Mit dieser noch experimentellen Option können Sie automatisch eine Tabelle erzeugen lassen, die die Dateinamen strukturiert
darstellt.
IconsAreLinks
Mit dieser Option schalten Sie die Verlinkung der Icons ein. Dadurch kann der Benutzer entweder auf den Dateinamen oder auch auf das Icon klicken, um eine Information nachzufragen.
IcosHeight[=Pixelzahl]
Im Zusammenspiel mit IconWidth sorgt diese Option dafür, dass im HTML-Quelltext
des Verzeichnislistings Größenangaben (Höhe) für das jeweilige Icon hinzugefügt
werden. Dabei können Sie eine feste Größe für alle Icons festlegen, wie folgendes
Beispiel zeigt:
IconHeight=20
5.2 Basiskonfiguration
293
Alternativ können Sie die Größenangabe auch weglassen, um die Standardgröße
eines Icons zu benutzen.
IconWidth[=Pixelzahl]
Im Zusammenspiel mit IconHeight sorgt diese Option dafür, dass im HTML-Quelltext
des Verzeichnislistings Größenangaben (Breite) für das jeweilige Icon hinzugefügt
werden. Dabei können Sie eine feste Größe für alle Icons festlegen, wie folgendes Beispiel zeigt:
IconWidth=20
Alternativ können Sie die Größenangabe auch weglassen, um die Standardgröße
eines Icons zu benutzen.
IgnoreClient
Sofern der Client die Sortierung der dargestellten Dateien- und Verzeichnisse nicht
ändern können soll, können Sie diese Option verwenden, die alle Sortierbefehle des
Clients ignoriert.
NameWidth=[x|*]
Die Option bestimmt die Größe (in Bytes) der Spalte, die den Namen eines Verzeichnisses oder einer Datei enthält. Zwei Beispiele:
NameWidth=30
NameWidth=*
Die erste Zeile definiert eine maximale Größe von 30 Bytes für die Namensspalte.
Durch die zweite Zeile wird die Größe auf den Wert gesetzt, der nötig ist, um den
längsten Namen darzustellen. Ein weiteres Beispiel:
-NameWidth
Durch diese Einstellung wird die Größe der Namensspalte durch mod_autoindex
automatisch bestimmt. Dieses Verhalten legt mod_autoindex auch an den Tag, falls
die Option NameWidth überhaupt nicht gesetzt ist.
ScanHTMLTitles
Sofern für eine Datei keine Beschreibung definiert wurde, versucht der Server bei
Vorhandensein dieser Option den Titel der HTML-Dateien auszulesen, um diesen als
Beschreibung zu verwenden. Hinweis: Diese Option ist rechen- und speicherintensiv,
da der Server jede Datei auf einen möglichen Titel untersuchen muss.
SuppressColumnSorting
Wenn Sie dem User die Möglichkeit geben wollen, das Verzeichnislisting nach
Dateigröße, Kurzbeschreibung oder letztem Änderungsdatum zu ordnen, dürfen Sie
diese Option nicht aktivieren. Ist die Spaltensortierung aktiviert, kann das Verzeichnislisting durch Klicken auf den Spaltenheader neu sortiert werden.
SuppressDescription
294
5 Konfiguration
Diese Option unterdrückt die Beschreibung eines Verzeichnisses oder einer Datei,
sofern die Option FancyIndexing gesetzt wurde.
SuppressHTMLPreamble
Falls ein Verzeichnis eine Kopfdatei enthält, die Sie durch die HeaderName-Anweisung definiert haben, wird diese standardmäßig nach den ersten, einleitenden
HTML-Befehlen, d.h. nach Befehlen wie <HTML> und <HEAD>, eingefügt. Mit dieser Option können Sie dieses Verhalten ändern und die Anzeige mit dem Inhalt der
Kopfdatei beginnen. Dabei muss die Kopfdatei über passende einleitende HTMLBefehle verfügen. Sofern keine Headerdatei vorhanden ist, werden die HTMLBefehle automatisch erzeugt.
SuppressIcon
Die Option SuppressIcon verbirgt die Anzeige von Icons innerhalb eines Verzeichnislistings. Natürlich wird auch diese Option nur aktiv, wenn die Option FancyIndexing
aktiviert ist.
SuppressLastModified
Sofern Sie nicht möchten, dass das letzte Änderungsdatum einer Datei innerhalb
eines Verzeichnislistings angezeigt wird, können Sie diese Verhaltensweise mit der
Option SuppresLastModified ausschalten.
SuppressRules
Diese Option verbirgt die Anzeige von horizontalen Linien innerhalb eines Verzeichnislistings. Auch diese Option wird nur aktiv, wenn die Option FancyIndexing aktiviert ist.
SuppressSize
Falls Sie die Größe einer Datei nicht anzeigen möchten, können Sie dies durch die
SuppressSize-Option abschalten.
TrackModified
Durch diese Option werden in der Serverantwort die beiden HTTP-Header Last-Modified und ETag des aufgelisteten Verzeichnisses hinzugefügt, damit der Client und eventuell vorgeschaltete Proxy-Server die Verzeichnislistings zwischenzuspeichern. Dies ist
allerdings nur auf solchen Systemen möglich, die die Verwendung des Befehls stat()
korrekt unterstützen. Die meisten Unix/Linux-Systeme, das unter OS/2 verfügbare JFS
sowie NTFS (Windows NT, 2000 etc.) unterstützen diesen Befehl, FAT16 und FAT32Partitionen leider nicht. Hinweis: Manche Betriebssysteme kontrollieren nicht die Veränderungen an Größe oder Datum einer Datei innerhalb eines Verzeichnisses. Unter
Unix/Linux führt eine Veränderung der Größe bzw. des Datumsstempels nicht zu
einer Veränderung des letzten Bearbeitungsdatums. Sofern sich diese Verhaltensweise
als problematisch herausstellt, schalten Sie diese Option ab.
VersionSort
Neu im Apache 2 ist u.a. auch die automatische Unterstützung der versionsbezogenen Sortierung von Dateien innerhalb eines Verzeichnislistings. Zeichenketten werden alphabetisch sortiert und führende Nullen werden ignoriert. Dabei müssen die
einzelnen Dateien einer der drei folgenden Formen entsprechen:
5.2 Basiskonfiguration
295
Dateiname-a
Dateiname-a.b
Dateiname-a.b.c
Daraus ergibt sich beispielsweise folgende Sortierreihenfolge:
Beispieldatei-1.7
Beispieldatei-1.7.2
Beispieldatei-1.7.12
Beispieldatei-1.8.2
Beispieldatei-1.8.2a
Beispieldatei-1.12
None
Sofern Sie FancyIndexing deaktivieren möchten, müssen Sie die None-Option benutzen.
Insgesamt möchte ich noch darauf hinweisen, dass mehrere IndexOptions-Anweisungen innerhalb eines einzelnen Verzeichnisses miteinander kombiniert und verschmolzen werden. Die Verwendung eines Plus- oder Minuszeichens zur Hinzufügung oder Entfernung von Optionen ist möglich, wobei diese auf die bereits
vorhandenen Einstellungen der IndexOptions-Anweisung angewendet werden.
Sofern eine Option nicht über ein vorangestelltes Plus- oder Minuszeichen verfügt, werden alle vorhandenen Optionen gelöscht! Ein Beispiel:
Hinweis
IndexOptions +ScanHTMLTitles -IconsAreLinks FancyIndexing
IndexOptions +SuppressSize
Diese Anweisungen sind identisch mit folgender Anweisung:
IndexOptions FancyIndexing +SuppressSize
Da die Option FancyIndexing im ersten Beispiel nicht über ein vorangestelltes
Pluszeichen verfügt, werden alle bereits vorgenommenen Optionen gelöscht
und die Option SuppressSize hinzugefügt, so dass die beiden Beispiele identisch sind.
IndexOrderDefault
Definiert die Standardsortierung eines Verzeichnisindexes.
Konfigurationsanweisung:
Syntax:
Standardwert (Default):
Enthalten in Modul:
Kontext:
Anweisung aktiv:
IndexOrderDefault
IndexOrderDefault Ascending | Descending
Name | Date | Size | Description
nicht vorhanden
mod_autoindex
Server-Kontext, Virtual-Host Kontext,
<Directory>-Kontext, <Location> Kontext,
<Files>-Kontext, .htaccess-Kontext
nein
296
5 Konfiguration
Mit dieser Anweisung können Sie die standardmäßige Sortierreihenfolge bestimmen,
die bei der Anzeige eines Verzeichnislistings, für das FancyIndexing aktiviert worden
ist, angewendet werden soll. Normalerweise werden die Verzeichnislistings aufsteigend nach den vorliegenden Dateinamen sortiert, wobei Sie auch eine Reihe anderer
Sortierkriterien festlegen können. Die Anweisung erwartet die Angabe zweier Parameter, zum einen die Sortierreihenfolge (aufsteigend oder absteigend, engl. ascending oder descending) und zum anderen den Sortierschlüssel. Dabei können Sie als
Sortierschlüssel den Namen (name), das Datum (date), die Größe (size) oder die
Beschreibung (description) einer Datei bzw. eines Verzeichnisses benutzen.
DefaultIcon
Bestimmt ein Standardicon.
Konfigurationsanweisung:
DefaultIcon
Syntax:
DefaultIcon URL-Pfad
Standardwert (Default):
nicht vorhanden
Enthalten in Modul:
mod_autoindex
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess-Container
Anweisung aktiv:
nein
Sofern FancyIndexing (vgl. IndexOptions-Anweisung) verwendet wird und für einen
Dateitypen kein beschreibendes Bildchen (Icon) definiert wurde, können Sie mit dieser Anweisung eine Art Standardbildchen bestimmen. Dabei erwartet die Anweisung
die Angabe eines relativen URL-Pfades zu dem Bildchen. Ein Beispiel:
DefaultIcon /icons/unbekannt.gif
Diese Einstellung sorgt dafür, dass bei eingeschaltetem FancyIndexing, das Icon unbekannt.gif angezeigt wird, wenn für einen Dateitypen kein explizites Icon definiert
wurde.
5.2.10 Umgebungsvariablen
Der Apache stellt einen Mechanismus bereit, um bestimmte Daten, die meist während einer Clientanfrage übermittelt worden sind, als so genannte Umgebungsvariablen zu speichern und in diversen Konfigurationsanweisungen zu verwenden bzw.
auszuwerten. Dabei handelt es sich um Apache-interne Umgebungsvariablen, die
außer dem Namen nichts mit den Umgebungsvariablen des zugrundeliegenden
Betriebssystems gemeinsam haben! Wenn Sie auf Betriebssystemebene Umgebungsvariablen definieren möchten, auf die Sie in der Konfiguration des Apache Bezug
nehmen wollen, so müssen Sie diese im Startskript des Apache definieren. Folgende
Konfigurationsanweisungen können auf Apache-interne Umgebungsvariablen Bezug
nehmen:
5.2 Basiskonfiguration
297
BrowserMatch
Definiert in Abhängigkeit des vom Client verwendeten Browsers eine Umgebungsvariable.
Konfigurationsanweisung:
BrowserMatch
Syntax:
BrowserMatch Ausdruck Umgebungsvariable
[=Wert]
Standardwerte (Default):
BrowserMatch »Mozilla/2« nokeepalive
(mehrfach vorhanden)
Enthalten in Modul:
mod_setenvif
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
ja
Die Konfigurationsanweisung BrowserMatch definiert in Abhängigkeit des vom
Benutzer verwendeten Browsers eine Umgebungsvariable, wobei bei der Überprüfung der vom Benutzer verwendeten Version ein regulärer Ausdruck (vgl. Anhang)
herangezogen werden kann. Dabei wird die Groß- und Kleinschreibung im Gegensatz zur Anweisung BrowserMatchNoCase penibel beachtet. Prinzipiell ist die Konfigurationsanweisung BrowserMatch eine Sonderform der SetEnvIf-Anweisung.
Dabei erwartet die Anweisung neben diesem regulären Ausdruck die Angabe einer
neu zu definierenden Umgebungsvariablen sowie (optional) einen Wert für diese
Variable. Auch die Definition von mehreren Umgebungsvariablen (inkl. Werten) ist
möglich. Dabei können Sie Umgebungsvariable in dreierlei Form bestimmen:
Variablenname
Sofern Sie einfach nur den Namen einer neu zu definierenden Variablen angeben,
wird diese mit dem Wert »1« erzeugt. Es handelt sich dabei praktisch um eine boolesche Variable, die nur den Wert 0 oder 1 haben kann.
!Variablenname
Ein solcher Aufruf entfernt eine bereits definierte Umgebungsvariable. Das Ausrufezeichen kann innerhalb eines regulären Ausdrucks auch zur Verneinung verwendet
werden (vgl. Anhang).
Variablenname=Wert
Die dritte mögliche Form kommt wohl in der Praxis am häufigsten vor und weist
einer neuen Umgebungsvariablen einen festen Wert zu. Folgende Beispiele dazu:
BrowserMatch
BrowserMatch
BrowserMatch
BrowserMatch
^Mozilla Browser=netscape Bildformat=jpeg
^Lynx Format=nur_text
MSIE !Format
^Googlebot Suchroboter
298
5 Konfiguration
Die erste Anweisung definiert zwei neue Umgebungsvariablen namens Browser und
Bildformat und weist denen jeweils einen Wert zu, sofern der Benutzer einen Browser
verwendet, der sich unter der Kennung Mozilla meldet (etwa Netscape). Mit einer
derartigen Anweisung könnte man die Benutzer des Netscape Communicators auf
eine speziell für sie optimierte Version einer Internetseite umleiten. Leider meldet
sich der Internet Explorer, entgegen der sonst üblichen Microsoft'schen Arroganz, mit
derselben Kennung wie der Netscape und es kann deshalb zu ungewollten Überschneidungen bei der Anwendung der vorgestellten Anweisungen kommen. Eine
kleine Übersicht über die verschiedenen Browserkennungen finden Sie im Anhang
dieses Buches.
Die nächste Anweisung erstellt eine neue Umgebungsvariable namens Format, die
den Wert nur_text erhält, wenn ein Benutzer den konsolen- und textbasierenden
Browser Lynx verwendet.
Sollte ein Benutzer eine Version des Microsoft Internet Explorers verwenden, wird
die Umgebungsvariable Format durch die dritte Anweisung gelöscht.
Hinweis
Das letzte Beispiel setzt die boolesche Umgebungsvariable Suchroboter, wenn sich ein
Browser unter der Kennung Googlebot meldet.
Sofern Sie zur Überprüfung von Browserversionen eine Zeichenkette mit Leerzeichen vergleichen, schließen Sie diese mit Anführungszeichen ein. Außerdem
müssen Sie Sonderzeichen durch einen vorangestellten Backslash ihrer besonderen Bedeutung berauben (vgl. Anhang).
BrowserMatchNoCase
Definiert in Abhängigkeit des vom Client verwendeten Browsers eine Umgebungsvariable, wobei Groß- und Kleinschreibung ignoriert wird.
Konfigurationsanweisung:
BrowserMatchNoCase
Syntax:
BrowserMatchNoCase Ausdruck Umgebungsvariable [=Wert]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_setenvif
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
nein
Diese Anweisung ist mit der bereits vorgestellten Option BrowserMatch funktional
und syntaktisch identisch, allerdings ignoriert diese beim Vergleich des regulären
Ausdrucks mit der vom Benutzer verwendeten Browservariante die Groß- und Kleinschreibung. Auch diese Anweisung erwartet neben einem regulären Ausdruck die
Angabe einer neu zu definierenden Umgebungsvariablen sowie (optional) einem
5.2 Basiskonfiguration
299
Wert für diese Variable. Sogar die Festlegung mehrerer Umgebungsvariablen (inkl.
Werten) ist möglich. Für die Umgebungsvariable sind folgende drei Formen möglich:
Variablenname
Sofern Sie einfach nur den Namen einer neu zu definierenden Variablen angeben,
wird diese mit dem Wert 1 erzeugt. Es handelt sich dabei praktisch um eine boolesche
Variable, die den Wert 0 oder 1 haben kann.
!Variablenname
Ein solcher Aufruf entfernt eine bereits definierte Umgebungsvariable. Das Ausrufezeichen kann auch innerhalb eines regulären Ausdrucks zur Verneinung verwendet
werden (vgl. Anhang).
Variablenname=Wert
Die dritte mögliche Form kommt wohl in der Praxis am häufigsten vor und weist
einer neuen Umgebungsvariablen einen festen Wert zu. Ein Beispiel:
BrowserMatchNoCase linux Betriebssystem=Linux
BrowserMatchNoCase win Betriebssystem=Windows
BrowserMatchNoCase freebsd Betriebssystem=FreeBSD
Sofern die Produktkennung des vom Client verwendeten Browsers entweder die Zeichenkette Linux, Win oder FreeBSD enthält, wird eine Umgebungsvariable namens
Betriebssystem definiert und der Name des vom Client verwendeten Betriebssystems
eingetragen. Die Groß- und Kleinschreibung innerhalb der Produktkennung wird
beim Vergleich mit dem regulären Ausdruck, der hier nur aus einer einzelnen Zeichenkette besteht, ignoriert.
Die Konfigurationsanweisungen BrowserMatch und BrowserMatchNoCase sind übrigens Sonderformen der Optionen SetEnvIf und SetEnvIfNoCase, die nur zur Überprüfung der vom Client verwendeten Browservariante eingesetzt werden können. Deshalb sind folgende Anweisungen identisch:
BrowserMatchNoCase linux Betriebssystem=Linux
SetEnvIfNoCase User-Agent linux Betriebssystem=Linux
PassEnv
Weitergabe von Umgebungsvariablen des Systems an CGI- oder SSI-Skripte.
Konfigurationsanweisung:
PassEnv
Syntax:
PassEnv Umgebungsvariable
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_env
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
nein
300
5 Konfiguration
Sofern Sie Umgebungsvariablen des Systems an selbst geschriebene Skripte oder Programme (z.B. CGI-, SSI- oder PHP-Skripte) übergeben möchten, können Sie diese
unter Angabe des Variablennamens mit der Anweisung PassEnv weitergeben. Ein
Beispiel:
Hinweis
PassEnv ORACLE_HOME
Wenn Sie eine Umgebungsvariable referenzieren, müssen Sie diese in der Shell
definieren, aus der der Apache gestartet worden ist. Sofern Sie den Apache über
ein eigenes Startskript (z.B. /etc/init.d/apache2) starten, ist es ratsam, die Definition der später in der Konfiguration des Apache zu referenzierenden Variablen direkt in dieses Startskript einzubauen. Achten Sie dabei unbedingt auf die
korrekte Groß- und Kleinschreibung! Alternativ lässt sich eine derartige Anweisung auch in das Startskript (z.B. /usr/local/apache2/bin/apachectl) des Apache integrieren.
SetEnv
Definiert eine Umgebungsvariable.
Konfigurationsanweisung:
SetEnv
Syntax:
SetEnv Umgebungsvariable Wert
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_env
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess-Container
Anweisung aktiv:
nein
Sie können auch eigene Umgebungsvariablen definieren, die Sie in selbstgeschriebenen Programmen oder Skripten benutzen können. Ich habe beispielsweise schon die
Erfahrung gemacht, dass es im Zusammenspiel von Oracle und PHP mit den deutschen Umlauten zu Problemen gekommen ist, da der Zeichensatz falsch eingestellt
war. Ein solches Problem kann man beispielsweise mit einer PassEnv- oder mit einer
SetEnv-Anweisung lösen:
SetEnv NLS_LANG GERMAN_GERMANY.WE8ISO8859P1
Diese Anweisung würde dazu führen, dass Oracle in Zukunft u.a. für Meldungen,
Sortierreihenfolgen, Datums- und Zahlenformate die deutsche Sprache mit einem
entsprechenden deutschen Zeichensatz benutzt.
SetEnvIf
Definiert eine Umgebungsvariable in Abhängigkeit von einer während der Anfrage
eines Clients übermittelten Information.
5.2 Basiskonfiguration
301
Konfigurationsanweisung:
SetEnvIf
Syntax:
SetEnvIf Merkmal Ausdruck Umgebungsvariable [=Wert]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_setenvif
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
nein
Während es mit der Anweisung BrowserMatch nur möglich ist, eine Umgebungsvariable in Abhängigkeit von der durch den Benutzer verwendeten Browservariante zu
setzen, erlaubt die Konfigurationsanweisung SetEnvIf die freie Definition von Umgebungsvariablen in Abhängigkeit von jedem verfügbaren HTTP-Header (vgl. Anhang)
oder einem der folgenden Merkmale:
Remote_Host:
Dieses Merkmal enthält den
p5084DCFA.dip.t-dialin.net).
vollständigen
Hostnamen
des
Clients
(z.B.
Remote_Addr:
Das Gegenstück zu Remote_Host heißt Remote_Addr und enthält die entsprechende
IP-Adresse eines Clients (z.B. 80.132.220.250).
Remote_User:
Sofern ein Benutzer sich für den Zugriff auf einen Bereich des Servers authentifiziert
hat, enthält dieses Merkmal den zur Authentifizierung genutzten Benutzernamen.
Request_Method:
Enthält die HTTP-Methode, mit der ein Client eine Anfrage an den Server gestellt hat
(z.B. GET, POST etc.).
Request_Protocol:
Der Name und die Version des zur Anfrage an den Server genutzten Protokolls wird
durch dieses Merkmal repräsentiert (z.B. HTTP/1.0 oder HTTP/1.1).
Request_URI:
Entspricht der URI der Clientanfrage.
Wenn Sie ein Merkmal angeben, welches weder in der Liste der verfügbaren HTTPHeader noch in den soeben genannten Merkmalen vorhanden ist, wird versucht eine
Übereinstimmung zu finden, indem das Merkmal als eine durch eine vorhergehende
SetEnvIf- oder SetEnvIfNoCase-Anweisung definierte Umgebungsvariable angesehen
wird. Dadurch können Sie mehrere SetEnvIf-Anweisungen miteinander kombinieren
und praktisch das Ergebnis vorangegangener Variablendefinitionen benutzen.
302
5 Konfiguration
Zusätzlich kann ein Merkmal in Form eines Suchmusters, d.h. in Form eines reguläreren Ausdrucks angegeben werden. Ein paar Beispiele:
SetEnvIf Request_URI "\.gif$" Bildformat=gif
SetEnvIf Request_URI "\.jpg$" Bildformat=jpg
SetEnvIf Request_URI "\.png$" Bildformat=png
Die drei Anweisungen setzen die Umgebungsvariable Bildformat auf ein bestimmtes
Format (jpg, gif oder png), wenn ein Client eine (Bild-) Datei mit einer derartigen
Endung angefordert hat. Derartige Regeln könnten etwa dazu verwendet werden,
alle Anfrage für einen bestimmten Dateitypen (etwa Bilddateien) nicht oder separat
zu protokollieren. Dazu folgendes Beispiel:
SetEnvIf Request_URI "\.gif$" Bildformat=gif
SetEnvIf Request_URI "\.jpg$" Bildformat=jpg
SetEnvIf Request_URI "\.png$" Bildformat=png
CustomLog bilder_anfragen.log common env=Bildformat
CustomLog access.log common env=!Bildformat
Wenn ein Client eine Bilddatei mit der Endung .gif, .jpg oder .png aufruft, wird eine
Umgebungsvariable namens Bildformat gesetzt. Existiert eine solche Variable, d.h.
wurde ein Bild durch einen Client angefordert, wird im Verlauf diese Anfrage in eine
separate Logdatei namens bilder_anfragen.log protokolliert, ansonsten landet die
Anfrage in der Gesamtprotokolldatei access.log. Mit solch relativ einfachen Mitteln
lassen sich getrennte Logdateien für verschiedene Dateitypen realisieren.
Zur Verwendung der SetEnvIf-Anweisung zwei weitere Beispiele:
SetEnvIf Remote_Host "^marketing\.firma\.com" Marketing
SetEnvIf Remote_User "^Peter$" Benutzer=Peter
Hinweis
Die erste Anweisung definiert die Umgebungsvariable Marketing, wenn die Anfrage
eines Clients von einem Rechner mit der Adresse marketing.firma.com kam. Das letzte
Beispiel definiert eine Umgebungsvariable namens Benutzer mit dem Wert Peter,
wenn sich vorher ein Benutzer mit dem Namen Peter authentifiziert hat.
Die Anweisung SetEnvIf beachtet die exakte Groß- und Kleinschreibung bei der
Überprüfung eines Merkmals mit einem regulären Ausdruck! Wenn Sie sich
über die Schreibweise eines Merkmals nicht sicher sind, sollten Sie stattdessen
die SetEnvIfNoCase-Anweisung benutzen.
SetEnvIfNoCase
Definiert eine Umgebungsvariable in Abhängigkeit von einer während der Anfrage
eines Clients übermittelten Information, ohne dabei auf Groß- und Kleinschreibung
zu achten.
5.2 Basiskonfiguration
303
Konfigurationsanweisung:
SetEnvIfNoCase
Syntax:
SetEnvIfNoCase Merkmal Ausdruck Umgebungsvariable [=Wert]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_setenvif
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container, .htaccess- Container
Anweisung aktiv:
nein
Diese Konfigurationsanweisung ist syntaktisch und funktional mit der vorgestellten
SetEnvIf-Option identisch, allerdings wird beim Vergleich zwischen Merkmal und
regulärem Ausdruck die Groß- und Kleinschreibung nicht beachtet. Die verfügbaren
Variablen und Merkmale sind ebenfalls identisch. Einige Beispiele:
SetEnvIfNoCase Remote_User "^peter$" Benutzer=Peter
Diese Anweisung definiert eine Umgebungsvariable namens Benutzer mit dem Wert
Peter, unabhängig davon, wie der Benutzer das Wort Peter in einer vorher durchgeführten Authentifizierung geschrieben hat. Dabei kann der Benutzer diesen Namen
natürlich nur so eingeben, wie dieser z.B. mit htpasswd angelegt worden ist. Der Vorteil der Nichtbeachtung von Groß- und Kleinschreibung liegt in diesem Fall natürlich
auf der Hand, denn unabhängig davon, wie der Benutzername Peter bei der Erzeugung des Passwortes geschrieben worden ist (z.B. pEtEr), greift trotzdem unsere
Variablendefinition.
UnsetEnv
Löscht eine bereits definierte Umgebungsvariable.
Konfigurationsanweisung:
UnsetEnv
Syntax:
UnsetEnv Umgebungsvariable
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_env
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
nein
Wenn Sie eine (oder mehrere) bereits vorhandene Umgebungsvariable löschen möchten, können Sie dies mit der UnsetEnv-Anweisung erreichen. Sinn könnte das Löschen
einer vorhandenen Variablen etwa im Zuge einer Definierung mittels SetEnv machen:
UnsetEnv NLS_LANG
SetEnv NLS_LANG GERMAN_GERMANY.WE8ISO8859P1
304
5 Konfiguration
Zunächst wird die Umgebungsvariable NLS_LANG gelöscht, damit man einen
Grundzustand erhält und genau weiß, dass die Variable NLS_LANG keinen (falschen) Wert enthält. Im Anschluß wird die Variable NLS_LANG direkt wieder definiert und steht zur Benutzung in eigenen Skripten wie gewohnt zur Verfügung. Sie
können auch mehrere Umgebungsvariablen gleichzeitig löschen, indem Sie diese
durch ein Leerzeichen voneinander trennen:
UnsetEnv NLS_LANG ORACLE_HOME
Spezielle Umgebungsvariablen
Da es in der Vergangenheit immer wieder Kompatiblitätsprobleme gegeben hat, wurden spezielle Umgebungsvariablen eingeführt, die die Verhaltensweise des Apache
gegenüber veralteten oder als fehlerhaft funktionierend bekannten Clients beeinflussen können. In der zentralen Konfiguration httpd.conf des Apache stehen zurzeit folgende BrowserMatch-Anweisungen, die diese speziellen Umgebungsvariablen benutzen:
BrowserMatch
BrowserMatch
BrowserMatch
BrowserMatch
BrowserMatch
BrowserMatch
BrowserMatch
"Mozilla/2" nokeepalive
"MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
"RealPlayer 4\.0" force-response-1.0
"Java/1\.0" force-response-1.0
"JDK/1\.0" force-response-1.0
"Microsoft Data Access Internet Publishing Provider" redirect-carefully
"^WebDrive" redirect-carefully
Die speziellen Umgebungsvariablen bedeuten Folgendes:
downgrade-1.0
Eine Anfrage wird intern als HTTP/1.0-Anfrage behandelt, da es bei einigen Clients
(u.a. MSIE 4.0b2) aufgrund einer fehlerhaften HTTP/1.1-Implementierung zu Problemen kommen könnte. Der Apache gleicht praktisch die durch die Entwickler eines
Browsers gemachten Fehler aus und kann trotz dieser Fehler im Client Anfragen von
solchen entgegennehmen und bearbeiten.
force-no-vary
Einige Clients (u.a. MSIE 4 und Lynx 2.7-2.8) haben Probleme mit transparentem
Content Negotiation und einem durch den Server in diesem Zusammenhang gesendeten HTTP-Header namens Vary. Durch diese Variable kann der Apache angewiesen werden, für eine bestimmte Browserversion diesen HTTP-Header nicht zu senden.
force-response-1.0
Ursprünglich zur Beseitigung von Problemen mit den Proxy-Servern der Firma AOL
entwickelt, sorgt diese Variable dafür, dass eine Antwort des Servers nach dem alten
Standard HTTP/1.0 an den Client geschickt wird.
nokeepalive
Zahlreiche Clients haben Probleme mit persistenten Verbindungen, die Sie durch die
Anweisung KeepAlive steuern können. Dazu gehören etwa frühe Version des Micro-
5.2 Basiskonfiguration
305
soft Internet Explorers (4.0b2) und des Netscape Navigators 2.0, der sogar die erste
Browservariante war, die überhaupt persistente Verbindungen anbot (wenn auch
nicht funktionsfähig). Für solche Clients, die ernsthafte Probleme mit persistenten
Verbindungen haben, können Sie diese Funktionalitäten abschalten.
redirect-carefully
Mit dieser Variablen können Sie den Server veranlassen, Umleitungen von Clients
vorsichtiger durchzuführen. Ursprünglich wurde diese Variable eingeführt, da
bestimmte Clients (z.B. Microsoft WebFolders) erhebliche Probleme mit Umleitungen
hatten.
Die Benutzung dieser speziellen Variablen ist absolut optional. Zwar sind derartige
Anweisungen in der Standardkonfiguration des Apache vorhanden, aber in Anbetracht der Tatsache, dass die Browservarianten, für die diese Hilfen ursprünglich entwickelt worden sind, kaum noch verbreitet sind, muss man sich wirklich überlegen,
ob man die speziellen Variablen weiterhin benutzt oder nicht. Sofern Sie auf Nummer
sicher gehen wollen, dass es nicht doch zu Problemen mit veralteten Clients kommt,
können Sie die vorgestellten Anweisungen unverändert stehen lassen. Eine Übersicht
der zurzeit bekannten Probleme mit diversen Clientvarianten finden Sie übrigens im
Internet unter http://httpd.apache.org/docs-2.0/misc/known_client_problems.html.
5.2.11 Server-Side Includes
Server-Side Includes sind Befehle, die beispielsweise in normale HTML-Dateien eingebunden werden können und serverseitig aufgerufen werden, bevor das Ergebnis
an den Client gesendet wird. Im Apache 2 wird die Möglichkeit der Nutzung von Server-Side Includes durch einen Ausgabefilter namens INCLUDES realisiert:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Diese Anweisungen definieren einen MIME-Typen für Dateien mit der Endung .shtml
und ordnen diesen Dateien den Ausgabefilter INCLUDES zu, damit diese Dateien als
Server-Side Includes betrachtet werden. Innerhalb der Verzeichnisse, in denen Server-Side Includes ausgeführt werden können, muss mindestens die folgende Option
gesetzt werden:
Options +Includes
Dieser Befehl erfolgt meist in einem <Directory>- oder .htaccess-Container. Bei der
Entwicklung von Server-Side Includes stehen Ihnen folgende Konfigurationsanweisungen zur Verfügung:
SSIStartTag
Definiert die Zeichenkette, die den Beginn eines Server-Side Include-Befehls kennzeichnet.
306
5 Konfiguration
Konfigurationsanweisung:
SSIStartTag
Syntax:
SSIStartTag Zeichenkette
Standardwerte (Default):
SSIStartTag »<!--«
Enthalten in Modul:
mod_include
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung definiert die Zeichenkette, die innerhalb eines Dokumentes den
Beginn eines Server-Side Include-Befehls kennzeichnet. Für PHP-Programmierer
könnte etwa folgende Anweisung Sinn machen, da sich dieser Befehl sehr an die
unter PHP verwendete Schreibweise anlehnt:
SSIStartTag "<SSI"
Mit einer solchen Anweisung müsste jeder Abschnitt mit Server-Side Include-Befehlen innerhalb eines Dokumentes mit der Zeichenkette <SSI beginnen. Hinweis: Setzen
Sie die Zeichenkette zur Kennzeichnung des Beginns von Server-Side Include-Befehlen immer in Anführungszeichen.
SSIEndTag
Definiert die Zeichenkette, die das Ende eines Server-Side Include-Befehls kennzeichnet.
Konfigurationsanweisung:
SSIEndTag
Syntax:
SSIEndTag Zeichenkette
Standardwerte (Default):
SSIEndTag »-->«
Enthalten in Modul:
mod_include
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung definiert die Zeichenkette, die innerhalb eines Dokumentes das
Ende eines Server-Side Include-Befehls kennzeichnet. Für PHP-Programmierer
könnte etwa folgende Anweisung Sinn machen, da sich dieser Befehl sehr an die
unter PHP verwendete Schreibweise anlehnt:
SSIStartTag "SSI>"
Hinweis
Mit einer solchen Anweisung müsste jeder Abschnitt mit Server-Side Include-Befehlen innerhalb eines Dokumentes mit der Zeichenkette SSI> enden.
Setzen Sie die Zeichenkette zur Kennzeichnung des Beginns von Server-Side
Include-Befehlen immer in Anführungszeichen.
5.2 Basiskonfiguration
307
SSIErrorMsg
Bestimmt eine Meldung, die im Falle eines Fehlers angezeigt wird.
Konfigurationsanweisung:
SSIErrorMsg
Syntax:
SSIErrorMsg Meldung
Standardwerte (Default):
SSIErrorMsg »[an error occurred while
processing this directive]«
Enthalten in Modul:
mod_include
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess- Container
Anweisung aktiv:
nein
Die Konfigurationsanweisung SSIErrorMsg bestimmt eine Meldung, die im Falle
eines unerwartet aufgetretenen Fehlers angezeigt wird. Bei der Meldung handelt es
sich um eine einfache Zeichenkette, die in Anführungszeichen gesetzt werden muss.
Ein Beispiel:
SSIErrorMsg "<!-- Es ist ein Fehler bei der Ausführung eines SSI-Befehls aufgetreten.
Sollte dieser Fehler dauerhaft bestehen, wenden Sie sich bitte an den Administrator.
-->"
SSITimeFormat
Das SSITimeFormat formatiert Datumsangaben.
Konfigurationsanweisung:
SSITimeFormat
Syntax:
SSITimeFormat Format
Standardwerte (Default):
SSITimeFormat »%A, %d-%b-%Y %H:%M:%S
%Z«
Enthalten in Modul:
mod_include
Kontext:
Server-Kontext, VirtualHost-Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess-Container
Anweisung aktiv:
nein
Wenn Sie innerhalb eines Server-Side Include-Befehls das aktuelle Datum ausgeben
möchten, welches Sie durch Ausgabe der DATE Umgebungsvariablen erhalten, so
können Sie das Format dieses Datums durch die Anweisung SSITimeFormat bestimmen. Dabei ist das Format identisch mit der Funktion strftime() einer Standardbibliothek der Programmiersprache C (vgl. Anhang). Ein Beispiel:
SSITimeFormat "m.%d.%Y"
308
5 Konfiguration
Diese Anweisung würde als Datum etwa 27.11.2002 ausgeben. Im Anhang des
Buches finden Sie zur Formatierung von Zeitangaben, die durch die Funktion strftime() erzeugt worden sind, weitergehende Informationen.
SSIUndefinedEcho
Diese Anweisung bestimmt eine Meldung, die im Falle einer nicht definierten Variable ausgegeben werden soll.
Konfigurationsanweisung:
SSIUndefinedEcho
Syntax:
SSIUndefinedEcho Meldung
Standardwerte (Default):
SSIUndefinedEcho »<!-- undef -->«
Enthalten in Modul:
mod_include
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Falls eine Variable ausgegeben werden soll, die nicht definiert ist, kann mit dieser
Anweisung eine entsprechende Fehlermeldung bestimmt werden, die in diesem Fall
an den Client gesendet wird. Ein Beispiel:
SSIUndefinedEcho "Die Variable hat keinen Wert."
XBitHack
XBitHack definiert den Umgang von Dateien mit Ausführungsrechten.
Konfigurationsanweisung:
XBitHack
Syntax:
XBitHack on | off | full
Standardwerte (Default):
XBitHack off
Enthalten in Modul:
mod_include
Kontext:
Server-Kontext, Virtual-Host Kontext,
<Directory>-Container, <Location>-Container, <Files>-Container, .htaccess Container
Anweisung aktiv:
nein
Die XBitHack-Anweisung definiert die Behandlung von HTML-Dateien, falls diese
über die Ausführberechtigung verfügen. Dabei stehen drei Parameter zur Verfügung:
Off
Dateien, die eine Ausführberechtigung haben, werden nicht gesondert behandelt.
On
Jede .html-Datei, die eine Ausführberechtigung hat, wird als Server-Side IncludeDatei angesehen und ausgeführt.
5.2 Basiskonfiguration
309
Full
Dieser Parameter ist funktional mit dem Parameter On identisch, allerdings wird
dadurch zusätzlich untersucht, ob die Gruppe, die der Inhaber einer Datei angehört,
ebenfalls über das Ausführungsrecht verfügt. Sofern auch für die Gruppe das Recht
gesetzt ist, wird ein Last-Modified-Header erzeugt, der an den Client gesendet wird.
Dadurch kann der Client und eventuell zwischengeschaltete Proxy-Server die
Dateien speichern, damit diese, sofern es keine inhaltliche Änderung gegeben hat,
nicht erneut übertragen werden müssen.
5.2.12 suEXEC
Hinweis
Die durch den Apache ausgeführten CGI-Skripte laufen immer unter der Kennung
des Benutzers und der Gruppe, mit der auch der Apache läuft (z.B. nobody). Oft kann
es jedoch Sinn machen, eine andere Benutzerkennung für die Ausführung eines CGISkriptes zu definieren. Dazu gibt es den so genannten switch user for exec (suEXEC)Wrapper, der ein durch den Apache übergebenes Programm nach eingehender
Sicherheitsüberprüfung unter einer angegebenen Benutzerkennung ausführt.
Eine sehr gute Alternative zur Verwendung von suEXEC stellt das Laufzeitmodell metuxmpm dar, welches ebenfalls in diesem Buch besprochen wird.
Installation und Konfiguration von suEXEC
Sofern Sie die Unterstützung für suEXEC noch nicht in den Apache integriert haben,
müssen Sie den Server erneut kompilieren. Dazu könnten Sie das configure-Skript wie
folgt aufrufen:
Hinweis
# ./configure --prefix=/usr/local/apache2_suEXEC --enable-suEXEC --with-suEXECcaller=nobody --with-docroot=/usr/local/apache2_suEXEC/htdocs --with-suEXECuidmin=500 --with-suEXEC-gidmin=500 --with-suEXEClogfile=/usr/local/apache2_suEXEC/logs/suEXEC_log --with-suEXECsafepath="/usr/local/bin:/usr/bin:/bin"
Sofern Sie weitere Konfigurationsparameter angeben möchten, können Sie
diese einfach dem Kommando beifügen. Ebenso müssen Sie eventuell die verwendeten Verzeichnisse und Werte an Ihre lokalen Gegebenheiten anpassen.
Weitere Informationen zu den verfügbaren suEXEC-Parametern finden Sie im
Kapitel über die Installation des Apache.
Der Befehl installiert den Apache nach /usr/local/apache2_suEXEC und schaltet die
Unterstützung für suEXEC explizit ein (--enable-suEXEC). Er erlaubt den Aufruf des
suEXEC-Programms nur durch den lokalen Benutzer nobody (--with-suEXECcaller=nobody), mit dessen Kennung der Apache läuft und beschränkt die Ausführung
von CGI-Skripten durch suEXEC auf das Unterverzeichnis htdocs der lokalen ApacheInstallation (--with-docroot=/usr/local/apache2_suEXEC/htdocs). Zusätzlich dürfen
Benutzer und Gruppen mit einer Kennung kleiner 500 das Programm suEXEC nicht
310
5 Konfiguration
aufrufen (--with-suEXEC-uidmin=500 und --with-suEXEC-gidmin=500), was die Sicherheit erheblich erhöht. Außerdem wird eine Logdatei definiert (--with-suEXEC-logfile=/usr/local/apache2_suEXEC/logs/suEXEC_log) und der Suchpfad für ausführbare
Programme wird auf die Verzeichnisse /usr/local/bin, /usr/bin und /bin beschränkt.
Nachdem dieser Befehl abgeschlossen ist, können Sie die Kompilierung des Apache
starten:
# make
Die Installation in das durch die Option --prefix
/usr/local/apache2_suEXEC erfolgt durch folgenden Befehl:
definierte
Verzeichnis
# make install
Öffnen Sie die Konfigurationsdatei httpd.conf des Apache und definieren Sie ca. in
Zeile 255-256 die Benutzer- und die Gruppenkennung, mit der der Server und der
suEXEC-Wrapper ausgeführt werden sollen:
Hinweis
User nobody
Group nogroup
Eventuell können die Werte auf Ihrem System abweichen. Allerdings müssen
die beiden Werte mit den Werten übereinstimmen, die Sie beim Aufruf des configure-Skriptes des Apache verwendet haben.
Starten Sie nun den Server und erstellen Sie im Unterverzeichnis cgi-bin Ihrer lokalen
Apache-Installation (z.B. /usr/local/apache2_suEXEC/cgi-bin) eine Datei namens
suEXEC_test und füllen Sie diese mit folgenden Befehlen:
#!/usr/bin/perl
print "Content-type:text/html\n\n";
print "<HTML><HEAD><TITLE>Testskript fuer suEXEC</TITLE></HEAD><BODY>";
print "<h1>Benutzer- und Gruppenkennung, <BR>mit der dieses Skript ausgefuehrt
wird:</h1>";
print `id`;
Speichern Sie die Datei und ändern Sie die Berechtigungen für dieses Skript:
# chown nobody.nogroup /usr/local/apache2_suEXEC/cgi-bin/suEXEC_test && chmod +x
/usr/local/apache2_suEXEC/cgi-bin/suEXEC_test
Rufen Sie nun die Datei suEXEC_test in einem Browser auf (z.B. http://localhost/cgibin/suexec_test) und das Skript wird die Benutzer- und Gruppenkennung des Benutzers (hier: nobody) ausgeben, der das Skript ausführt:
Benutzer- und Gruppenkennung,
mit der dieses Skript ausgefuehrt wird:
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
5.3 Fortgeschrittene Konfiguration
311
Genau dieses Verhalten wollten wir durch die Installation von suEXEC bezwecken,
das Skript wird durch den lokalen Benutzer nobody ausgeführt, der über minimale
Rechte auf dem System verfügt.
Für den Apache 2.0 steht eine neue Anweisung zur Verwendung von suEXEC in Verbindung mit virtuellen Servern zur Verfügung:
SuEXECUserGroup
Diese Anweisung definiert den Benutzer und die Gruppe, mit deren Kennung ein
CGI-Skript ausgeführt werden soll.
Konfigurationsanweisung:
SuEXECUserGroup
Syntax:
SuEXECUserGroup Benutzername Gruppenname
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_suEXEC
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Eine weitere Neuerung im Apache 2 ist die Möglichkeit, mithilfe der SuEXECUserGroup-Anweisung den Benutzer und die Gruppe zu definieren, mit deren Kennung
ein CGI-Skript ausgeführt werden soll. Damit lässt sich beispielsweise für die Ausführung von CGI-Skripten eines virtuellen Servers ein eigener Benutzer und eine
eigene Gruppe spezifizieren, mit deren Kennung die CGI-Skripte des virtuellen Servers ausgeführt werden. In der Version 1.3.x des Apache war dazu noch die UserAnweisung notwendig.
SuEXECUserGroup peterh kunden
Diese Anweisung führt dazu, dass alle CGI-Skripte in dem Kontext mit der Benutzerkennung peterh und der Gruppenkennung kunden ausgeführt werden. Hinweis: Die
Anweisung bezieht sich NUR auf CGI-Skripte, PHP-Skripte sind nicht betroffen. Falls
Sie diese Skripte ebenfalls einem bestimmten Benutzer zuordnen möchten, müssen
Sie ein entsprechendes Laufzeitmodell (z.B. perchild) wählen.
5.3
Fortgeschrittene Konfiguration
5.3.1
Virtuelle Server
Unter dem Begriff VirtualHosts (virtuelle Server) versteht man die Verwaltung mehrerer Domains/Websites auf einem einzigen Server, die sich zwar die Ressourcen des
Servers teilen, ansonsten aber völlig autonom voneinander agieren.
VirtualHosts wurden erfunden, weil die Anzahl der Websites und Domains derart
rasch anstieg, dass es technisch und ökonomisch nicht mehr möglich war, jeder Inter-
312
5 Konfiguration
netseite einen eigenen und dedizierten Server zur Verfügung zu stellen. Deshalb teilen sich mehrere Internetseiten einen Server, wobei jede Website in einem separaten
Teil des Dateisystems des Servers untergebracht ist. Folgendes Schema veranschaulicht das Prinzip eines virtuellen Servers:
/usr/local/apache2/beispiel.de/htdocs
www.beispiel.de
/usr/local/apache2/firma.com/htdocs
Client 1
Festplatte(n)
des Servers
Internet
www.schreinerei-mueller.de
Apache
www.firma.com
/usr/local/apache2/schreinereimueller.de/htdocs
Client 2
Client N
Abbildung 5.1 Schematische Darstellung virtueller Server
Prinzipiell unterscheidet man zwei verschiedene Arten von virtuellen Servern: Zum
einen gibt es IP-basierte virtuelle Server, die je virtuellem Server exakt eine dedizierte
IP-Adresse verlangen und es gibt die durch HTTP/1.1 bereitgestellten namenbasierten virtuellen Server, die mit nur einer IP-Adresse (fast) beliebig viele virtuelle Server
beherbergen können. Durch den Apache werden beide Variante unterstützt, wobei in
der Praxis gerade bei kleineren Providern die namensbasierte Variante deutlich häufiger anzutreffen ist, als die IP-basierte Form.
IP-basierte virtuelle Server
Die Verwendung eines IP-basierten virtuellen Servers war die ursprünglichste Form
eines VirtualHosts, da aufgrund einer Beschränkung des HTTP/1.0-Protokolls ein
Client gegenüber dem Server nicht eindeutig übermitteln konnte, welchen virtuellen
Server er abrufen möchte, so dass für jeden virtuellen Server eine eigene und dedizierte IP-Adresse festgelegt werden musste. Damit ein Server mehrere IP-Adressen
haben konnte, musste man entweder mehrere Netzwerkkarten in diesen einbauen,
oder auf die Verwendung von IP-Aliasen zurückgreifen. Durch einen IP-Alias
erzeugt man auf einem System eine virtuelle Netzwerkkarte und weist dieser eine
eigene IP-Adresse zu, so dass das System unter mehreren IP-Adressen erreichbar ist.
Unter Linux ist dies beispielsweise mit dem Befehl ifconfig möglich:
# ifconfig eth0:1 192.168.0.20 netmask 255.255.255.0 up
Wenn Sie nicht wissen, wie Sie einen IP-Alias für Ihr System erzeugen können, konsultieren Sie bitte die Betriebssystemdokumentation. Hier nochmal eine schematische
Darstellung des Prinzips eines IP-basierten virtuellen Servers:
5.3 Fortgeschrittene Konfiguration
313
Server verfügt über mehrere
IP-Adressen, z. B.:
1.2.3.4
1.2.3.5
www.beispiel.de
www.beispiel.de entspricht 1.2.3.4
www.firma.com entspricht 1.2.3.5
Client 1
Webserver
Client N
Bei der Verwendung eines IP-basierten
virtuellen Servers muss jede Domain
über eine dedizierte und einzigartige IPAdresse verfügen.
www.firma.com
Abbildung 5.2 Schema eines IP-basierten virtuellen Servers
Wie Sie diesem Schema entnehmen können, muss bei einem IP-basierten virtuellen
Server jede Domain eine eigene IP-Adresse besitzen. Mit der weitgehenden Verbreitung von HTTP/1.1 verdrängen namensbasierte virtuelle Server jedoch immer mehr
die IP-basierten VirtualHosts.
Namenbasierte virtuelle Server
Die Einführung von HTTP/1.1 ermöglichte die Verwendung von namenbasierten
virtuellen Servern, da ein Client bei diesem Protokoll durch den so genannten HostHeader dem Server genau mitteilen konnte, welchen virtuellen Server er abrufen
möchte. Dadurch war es erstmals möglich, mit nur einer IP-Adresse mehrere virtuelle
Server zu betreiben! In der Praxis werden namenbasierte virtuelle Server den IPbasierten sehr oft vorgezogen, da die Anzahl der IP-Adressen je Server meist stark
beschränkt ist. Gerade kleinere Provider, die nur über eine beschränkte Anzahl an IPAdressen verfügen, nutzen deshalb namenbasierte virtuelle Server, um mit nur einer
IP-Adresse mehrere virtuelle Server zu betreiben. Ein Nachteil von namenbasierten
virtuellen Servern ist allerdings, dass Clients, die nur den (veralteten) HTTP/1.0 Standard unterstützen, diese nicht aufrufen können, da sie dem Server nicht explizit mitteilen können, welchen virtuellen Server sie abrufen möchten. Dadurch landet ein solcher Client immer auf der Seite des ersten für die entsprechende IP-Adresse
konfigurierten virtuellen Servers. Inzwischen unterstützen jedoch alle gängigen
Browser das HTTP/1.1-Protokoll, so dass es eigentlich keinerlei Probleme mit älteren
Browserversionen mehr geben sollte.
Der zweite Nachteil von namenbasierten virtuellen Servern ist, dass es aufgrund der
Struktur des SSL-Protokolls nicht möglich ist, diese als durch SSL gesicherte Server zu
benutzen. Für eine sichere SSL-Verbindung bedarf der Server laut Definition einer
eigenen und exklusiven IP-Adresse, die der Server im Falle eines namenbasierten virtuellen Servers nicht besitzt, da dieser sich eine IP-Adresse mit den anderen virtuellen
314
5 Konfiguration
Servern teilt. Zur Veranschaulichung eine schematische Darstellung über die Funktionsweise eines namenbasierten virtuellen Servers:
Server verfügt nur über eine
IP-Adresse, z. B.:
1.2.3.4
www.beispiel.de
www.beispiel.de entspricht 1.2.3.4
www.firma.com entspricht auch 1.2.3.4
Client 1
Webserver
Client N
Mit nur einer IP-Adresse lassen sich
mehrere virtuelle Server betreiben.
www.firma.com
Abbildung 5.3 Schema eines namenbasierten virtuellen Servers
Virtuelle Server sind in der Praxis eines der am häufigsten genutzten Funktionen des
Apache. Nachfolgend werden alle zum Aufbau eines virtuellen Servers nötigen Konfigurationsanweisungen inklusive zahlreicher Beispiele vorgestellt:
VirtualHost
Der VirtualHost definiert einen virtuellen Server und fasst Konfigurationsanweisungen für diesen zusammen.
Konfigurationsanweisung:
VirtualHost
Syntax:
<VirtualHost Adresse[:Port]>...</VirtualHost>
Standardwerte (Default):
#<VirtualHost *>
Enthalten in Modul:
Mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein (auskommentiert)
Diese Konfigurationsanweisung definiert einen virtuellen Server und erzeugt einen
Container, in dem Anweisungen, die nur für den einen virtuellen Server gelten sollen,
gruppiert werden können. Innerhalb dieses Containers kann jede Anweisung benutzt
werden, deren Benutzung generell in einem <VirtualHost>-Container zulässig ist.
Sobald der Server eine Anfrage für einen virtuellen Server bekommt, benutzt er nur
die Anweisungen aus dem <VirtualHost>-Container. Als einzigen Parameter erwartet die Konfigurationsanweisung die IP-Adresse oder den vollständigen Domain-
5.3 Fortgeschrittene Konfiguration
315
namen eines virtuellen Servers, die Angabe einer Portnummer ist optional. Sofern als
Portnummer ein Sternchen (*) gewählt wird, ist der virtuelle Server unter allen IPAdressen erreichbar, auf denen der Apache auf Anfragen wartet. Anmerkung: Interessanterweise überprüft der Apache nicht, ob die angegebene IP-Adresse im System
überhaupt definiert ist. Wenn Sie also fälschlicherweise eine IP-Adresse benutzen, die
nicht Ihrem System zugeordnet ist, werden Sie keine Fehlermeldung vom Apache
erhalten!
Dazu einige Beispiele:
<VirtualHost 62.146.56.2>
...
</VirtualHost>
<VirtualHost www.beispiel.de>
...
</VirtualHost>
<VirtualHost 62.146.56.2:*>
...
</VirtualHost>
<VirtualHost 62.146.56.2:8080>
...
</VirtualHost>
Anmerkung: Die drei Punkte symbolisieren beliebige Konfigurationsanweisungen,
die innerhalb eines <VirtualHost>-Containers vorgenommen werden können. Da
diese Anweisungen die vorgestellten Beispiele unnötig verkomplizieren würden,
habe ich diese vorerst weggelassen und durch drei Punkte ersetzt.
Das erste Beispiel ist das klassische Beispiel eines namenbasierten virtuellen Servers,
denn es weist einem virtuellen Server eine IP-Adresse zu, die gleichzeitig auch von
anderen virtuellen Servern benutzt wird (vgl. NameVirtualHost-Anweisung). Eine
derartige Anweisung wird sich in den meisten Konfigurationen des Apache wiederfinden.
Das nächste Beispiel verwendet einen vollständigen Domainnamen zur Deklaration
eines virtuellen Servers, allerdings sollten Sie von dieser Variante tunlichst absehen,
denn sie erfordert eine DNS-Abfrage beim Start des Apache und verlangsamt
dadurch den Start des Servers. Zusätzlich führt eine fehlgeschlagene DNS-Abfrage
dazu, dass ein virtueller Server nicht aktiv wird.
Wenn ein virtueller Server unter allen Portnummern erreichbar sein soll, auf denen
der Apache lauscht, können Sie dies durch die Angabe des Sternchen (*) erreichen,
wie das dritte Beispiel veranschaulicht. Das letzte Beispiel zeigt, wie ein virtueller Server nur unter einer bestimmten Portnummer erreichbar sein kann. Dabei müssen Sie
darauf achten, dass der Server generell auch auf diesem Port auf eingehende Anfragen horcht (vgl. Listen-Anweisung).
Die Deklaration eines virtuellen Servers kann im Prinzip unbegrenzt oft erfolgen,
allerdings verbraucht jeder virtuelle Server zusätzliche Systemressourcen, die nur im
begrenzten Maße zur Verfügung stehen. Ein virtueller Server kann übrigens auch
unter mehreren IP-Adressen erreichbar sein, wie folgendes Beispiel zeigt:
316
5 Konfiguration
<VirtualHost 62.146.56.2 195.23.239.4>
...
</VirtualHost>
Diese Anweisung weist dem virtuellen Server mehrere IP-Adressen zu, unter denen
dieser erreichbar ist.
Sofern ein virtueller Server unter einer IPv4- und einer IPv6-Adresse erreichbar sein
soll, so können Sie dies wie folgt erreichen:
NameVirtualHost 192.168.0.2:80
NameVirtualHost [fe80::a00:20ff:fea7:ccea]:80>
Hinweis
<VirtualHost 192.168.0.2:80 [fe80::a00:20ff:fea7:ccea]:80>
…
</VirtualHost>
Die dargestellten Adressen dienen lediglich der Veranschaulichung. Die drei
Punkte symbolisieren dabei die innerhalb des VirtualHost-Containers normalerweise enthaltene Konfiguration, die ich bei diesem Beispiel aus Gründen der
Übersichtlichkeit entfernt habe.
Wie Sie dem oben genannten Beispiel entnehmen können, müssen Sie in einem solchen Fall jeweils für die IPv4- und die IPv6-Adresse Ihres Servers eine eigene NameVirtualHost-Anweisung definieren. Daraufhin können Sie beide Adressen in einer
VirtualHost-Anweisung ansprechen.
Aufbau eines <VirtualHost>-Containers
Fast alle Konfigurationsanweisungen, die in der globalen Serverkonfiguration verwendet werden können, können auch innerhalb eines virtuellen Servers benutzt werden. Sofern eine Anweisung für einen virtuellen Server nicht explizit definiert worden ist, erbt der virtuelle Server die Einstellungen des übergeordneten, d.h. des
globalen Hauptservers. Der minimalste Aufbau eines virtuellen Servers sieht etwa so
aus:
<VirtualHost 62.146.56.2>
Servername www.beispiel.de
DocumentRoot /usr/local/apache2/beispiel.de
</VirtualHost>
Diese Anweisungen deklarieren einen virtuellen Server auf der IP-Adresse
62.146.56.2, der unter dem Namen www.beispiel.de erreichbar sein soll und deren im
Internet zu veröffentlichenden Informationen im Dateisystem des Servers unter
/usr/local/apache2/beispiel.de gespeichert sind. Da keinerlei Angaben über Logdateien
etc. gemacht worden sind, erbt dieser virtuelle Server die Einstellung des Hauptservers und übernimmt diese für sich, d.h. die Fehlermeldung des virtuellen Servers
werden in die ErrorLog-Datei des Hauptservers protokolliert. In der Praxis hat sich
deshalb folgende Konfiguration für einen virtuellen Server bewährt:
5.3 Fortgeschrittene Konfiguration
317
# www.beispiel.de
<Virtualhost 62.146.56.2>
ServerName www.beispiel.de
ServerAlias beispiel.de
ServerAdmin [email protected]
DocumentRoot /usr/local/apache2/beispiel.de
ScriptAlias /cgi-bin/ /usr/local/apache2/beispiel.de/cgi-bin/
ErrorLog /usr/local/apache2/logs/beispiel.de-error_log
CustomLog /usr/local/apache2/logs/beispiel.de-access_log common
</VirtualHost>
Anmerkung: Die erste Zeile stellt einen Kommentar dar, der angibt, um welchen virtuellen Server es sich im nachfolgenden <VirtualHost>-Container handelt. Bei einer
kleinen Anzahl an virtuellen Servern mag ein solcher Kommentar überflüssig erscheinen, aber aus eigener Erfahrung weiß ich, dass bei Vorhandensein einiger dutzend
virtueller Server solche Kommentare auf jeden Fall Sinn machen.
Die Anweisungen deklarieren einen virtuellen Server, der auf der IP-Adresse
62.146.56.2 horcht und unter dem Namen www.beispiel.de erreichbar ist. Sofern die
DNS-Einträge entsprechend vorhanden ist, läßt sich der virtuelle Server auch mit beispiel.de ansprechen (vgl. ServerAlias-Anweisung). Der Server hat ein eigenes DocumentRoot, in dem die im Internet zu veröffentlichenden Informationen gespeichert sind.
Ebenso erhält der virtuelle Server ein eigenes CGI-BIN-Verzeichnis, in dem der Benutzer eigene CGI-Skripte ausführen kann (vgl. ScriptAlias-Anweisung). Zusätzlich werden die Fehlermeldungen und Zugriffe des Servers in separaten Logdateien protokolliert, wobei für die Zugriffe das Common Log Format (CLF) verwendet wird (vgl.
CustomLog-Anweisung).
Wenn Sie zur Deklaration eines virtuellen Servers eine IPv6-Adresse verwenden
möchten, müssen Sie die IP-Adresse in eckigen Klammern einschließen! Für das vorgestellte Beispiel eines virtuellen Servers könnte dies etwa so aussehen:
Hinweis
# www.beispiel.de
<Virtualhost [fe80::a00:20ff:fea7:ccea]>
ServerName www.beispiel.de
ServerAlias beispiel.de
ServerAdmin [email protected]
DocumentRoot /usr/local/apache2/beispiel.de
ScriptAlias /cgi-bin/ /usr/local/apache2/beispiel.de/cgi-bin/
ErrorLog /usr/local/apache2/logs/beispiel.de-error_log
CustomLog /usr/local/apache2/logs/beispiel.de-access_log common
</VirtualHost>
Sofern Sie für die IPv6-Adresse zusätzlich eine Portnummer definieren möchten, müssen Sie diese außerhalb der eckigen Klammern angeben (z.B.
[fe80::a00:20ff:fea7:ccea]:80).
318
5 Konfiguration
Bevor Sie jedoch überhaupt einen namenbasierten virtuellen Server deklarieren können, benötigen Sie zunächst eine NameVirtualHost-Anweisung:
NameVirtualHost
Der NameVirtualHost Konfiguriert eine IP-Adresse zur Benutzung für virtuelle Server.
Konfigurationsanweisung:
NameVirtualHost
Syntax:
NameVirtualHost IP[:Port]
Standardwerte (Default):
#NameVirtualHost *
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
nein (auskommentiert)
Sofern Sie namenbasierte virtuelle Server betreiben möchten, müssen Sie die NameVirtualHost-Anweisung benutzen, um IP-Adressen zu definieren, die zur Deklaration
von virtuellen Servern benutzt werden dürfen. Dabei erwartet die Anweisung einen
Hostnamen oder eine IP-Adresse, die zur Erzeugung von virtuellen Servern benutzt
werden darf. Optional ist dagegen die Angabe einer Portnummer, wenn der Standardport des Apache (meist TCP Port 80) nicht verwendet werden soll. Damit beim
Start des Apache keine DNS-Abfrage gemacht werden muss, sollten Sie in der NameVirtualHost-Anweisung ausschließlich IP-Adressen verwenden!
Wenn der Apache etwa zwei virtuelle Server (www.beispiel.de und www.firma.com)
unter der IP-Adresse 62.146.56.2 beheimaten soll, könnten Sie folgende Konfiguration
vornehmen:
NameVirtualHost 62.146.56.2
<VirtualHost 62.146.56.2>
ServerName www.beispiel.de
...
</VirtualHost>
<VirtualHost 62.146.56.2>
ServerName www.firma.com
...
</VirtualHost>
Wenn ein virtueller Server ausschließlich unter einer bestimmten Portnummer
erreichbar sein soll, können Sie diese Portnummer neben der IP-Adresse/Hostname
an die NameVirtualHost-Anweisung übergeben:
NameVirtualHost 62.146.56.2:8080
Sie müssen allerdings darauf achten, dass der Apache überhaupt unter dieser Portnummer erreichbar ist (vgl. Listen-Anweisung). Hinweis: Wenn Sie eine Portnummer
definieren, auf der der Apache nicht auf eingehende Anfragen wartet, erhalten Sie
keine Fehlermeldung!
5.3 Fortgeschrittene Konfiguration
319
Bei der Verwendung von IPv6-Adressen müssen Sie diese in eckige Klammern einschließen:
NameVirtualHost [fe80::a00:20ff:fea7:ccea]
Sofern Sie neben einer IPv6-Adresse auch eine spezielle Portnummer für die virtuellen Server definieren möchten, müssen Sie diese nach der zweiten eckigen Klammer
der IPv6-Adresse angeben:
NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080
Wenn Sie nur namenbasierte virtuelle Server betreiben, können Sie auch das Sternchen (*) als Jokerzeichen für die NameVirtualHost-Anweisung verwenden, denn damit
wird keine feste Zuordnung von Hostnamen und IP-Adresse vorgenommen. Zwei
virtuelle Server könnten damit etwa so erzeugt werden:
NameVirtualHost *
<VirtualHost *>
ServerName www.beispiel.de
...
</VirtualHost>
<VirtualHost 1.2.3.4>
ServerName www.firma.com
...
</VirtualHost>
Wie Sie sehen können, kann eine <VirtualHost>-Anweisung in diesem Fall entweder
einen Hostnamen respektive IP-Adresse oder ein Sternchen als Adresse verwenden.
Konfigurationsbeispiele
IP-basierter virtueller Server
Der Server ist bereits unter einer IP-Adresse (194.123.17.59) und einem Domainnamen
(www.beispiel.de) erreichbar. Das DocumentRoot-Verzeichnis dieses Hauptserver lautet
/usr/local/apache2/htdocs. Jetzt soll für eine befreundete Firma ein zusätzlicher virtueller
Server angelegt werden, der ebenfalls über eine eigene IP-Adresse (194.123.17.47) und
Domain (www.firma.com) verfügen soll. Die im Internet zu veröffentlichenden Informationen (DocumentRoot) der befreundeten Firma sollen unter /usr/local/apache2/firma.com
gespeichert werden. Wichtig ist vor allen Dingen, dass die Logdateien beider Parteien
strikt voneinander getrennt werden.
Es ergibt sich daraus folgende Konfiguration (unwichtige Passagen gekürzt):
Listen 194.123.17.59:80
Listen 194.123.17.47:80
ServerName www.beispiel.de
DocumentRoot /usr/local/apache2/htdocs
ErrorLog /usr/local/apache2/logs/beispiel.de-error_log
CustomLog /usr/local/apache2/logs/beispiel.de-access_log common
...
320
5 Konfiguration
# www.firma.com
<Virtualhost 194.123.17.47>
ServerName www.firma.com
ServerAlias firma.com
ServerAdmin [email protected]
DocumentRoot /usr/local/apache2/firma.com
ScriptAlias /cgi-bin/ /usr/local/apache2/firma.com/cgi-bin/
ErrorLog /usr/local/apache2/logs/firma.com-error_log
CustomLog /usr/local/apache2/logs/firma.com-access_log common
</VirtualHost>
Diese Anweisungen erledigen exakt die gestellten Anforderungen, denn zunächst wird
ein Hauptserver definiert, der für die Domain beispiel.de Informationen im Internet veröffentlicht, die im lokalen Dateisystem unter /usr/local/apache2/htdocs gespeichert sind.
Zusätzlich werden für diesen Hauptserver zwei Logdateien definiert, die weiteren
Konfigurationsanweisungen habe ich hier bewußt ausgelassen und durch drei Punkte
gekennzeichnet. Der <VirtualHost>-Container definiert für die IP-Adresse 194.12.17.47
einen IP-basierten virtuellen Server, der unter den Adresse www.firma.com und
firma.com im Internet erreichbar ist. Ferner verfügt dieser virtuelle Server über einen
separaten Bereich auf der Festplatte des Servers (/usr/local/apache2/firma.com) sowie zwei
vom Hauptserver getrennte Logdateien.
Namenbasierter virtueller Server
Auch in diesem Beispiel ist der Server bereits unter einer IP-Adresse (194.123.17.37)
und einem Domainnamen (www.beispiel.de) erreichbar. Das DocumentRoot-Verzeichnis
dieses Hauptserver lautet /usr/local/apache2/htdocs. Obwohl leider nur eine eigene IPAdresse zur Verfügung steht, sollen drei befreundete Firmen (Firma1, Firma2 und
Firma3) zusätzlich als virtuelle Server angelegt werden. Die im Internet zu veröffentlichenden Informationen (DocumentRoot) der befreundeten Firmen sollen, ebenso wie
die Logdateien, in separaten Verzeichnissen getrennt voneinander gespeichert werden.
Es ergibt sich daraus folgende Konfiguration (unwichtige Passagen gekürzt):
Listen 194.123.17.37:80
ServerName www.beispiel.de
DocumentRoot /usr/local/apache2/htdocs
ErrorLog /usr/local/apache2/logs/beispiel.de-error_log
CustomLog /usr/local/apache2/logs/beispiel.de-access_log common
...
NameVirtualHost 194.123.17.37
# www.firma1.de
<Virtualhost 194.123.17.37>
ServerName www.firma1.de
ServerAlias firma1.de
ServerAdmin [email protected]
DocumentRoot /usr/local/apache2/firma1.de
ScriptAlias /cgi-bin/ /usr/local/apache2/firma1.de/cgi-bin/
ErrorLog /usr/local/apache2/logs/firma1.de-error_log
CustomLog /usr/local/apache2/logs/firma1.de-access_log common
5.3 Fortgeschrittene Konfiguration
321
</VirtualHost>
# www.firma2.de
<Virtualhost 194.123.17.37>
ServerName www.firma2.de
ServerAlias firma2.de
ServerAdmin [email protected]
DocumentRoot /usr/local/apache2/firma2.de
ScriptAlias /cgi-bin/ /usr/local/apache2/firma2.de/cgi-bin/
ErrorLog /usr/local/apache2/logs/firma2.de-error_log
CustomLog /usr/local/apache2/logs/firma2.de-access_log common
</VirtualHost>
# www.firma3.de
<Virtualhost 194.123.17.37>
ServerName www.firma3.de
ServerAlias firma3.de
ServerAdmin [email protected]
DocumentRoot /usr/local/apache2/firma3.de
ScriptAlias /cgi-bin/ /usr/local/apache2/firma3.de/cgi-bin/
ErrorLog /usr/local/apache2/logs/firma3.de-error_log
CustomLog /usr/local/apache2/logs/firma3.de-access_log common
</VirtualHost>
Diese Anweisungen erledigen exakt die gestellten Anforderungen, denn zunächst
wird ein Hauptserver definiert, der für die Domain beispiel.de Informationen im Internet veröffentlicht, die im lokalen Dateisystem unter /usr/local/apache2/htdocs gespeichert sind. Zusätzlich werden für diesen Hauptserver zwei Logdateien definiert, die
weiteren Konfigurationsanweisungen habe ich hier bewußt ausgelassen und durch
drei Punkte gekennzeichnet. Bevor der erste virtuelle Server definiert wird, muss die
NameVirtualHost-Anweisung dafür sorgen, dass es überhaupt möglich ist, mit nur
einer IP-Adresse mehrere virtuelle Server zu erstellen. Dabei definieren die <VirtualHost>-Container drei virtuelle Server für die IP-Adresse 194.12.17.37, die unter der
Adresse www.firma1.de, www.firma2.de und www.firma3.de im Internet erreichbar sind.
Jeder dieser drei virtuellen Server verfügt über ein eigenes Verzeichnis (DocumentRoot), in dem die im Internet zu veröffentlichenden Information gespeichert werden
können. Ferner verfügen alle drei virtuellen Server über getrennte Logdateien und
eigene cgi-bin-Verzeichnisse.
Dynamische virtuelle Server
Bei einer sehr großen Anzahl an virtuellen Servern wird die Pflege der Konfigurationsdatei des Apache sehr umständlich und die Datei wächst auf eine sehr bedenkliche Größe an, die zu vermeidbaren Performanceeinbußen führt. Es ist daher ratsam,
bei einer sehr großen Anzahl an virtuellen Hosts die Verwaltung der virtuellen Server
zu dynamisieren, d.h. die Verwaltung der virtuellen Server wird durch die Angabe
von Variablen in der Konfigurationsdatei des Apache an externe Programme oder
Module auszulagert.
Mod_rewrite liesse sich sicherlich für ein solches Vorhaben benutzen, aber mit
mod_vhost_alias gibt es praktisch die perfekte Lösung zur Dynamisierung von virtuellen Servern. Die Idee dieses Moduls ist es, nahezu konfigurationsidentische virtuelle
322
5 Konfiguration
Server anhand von Variablen über das Dateisystem abzubilden. Dabei wird in einem
bestimmten Verzeichnis für jeden virtuellen Server ein eigenes Verzeichnis angelegt,
welches genauso heißt, wie der vollständige Name des virtuellen Servers lautet (z.B.
www.beispiel.de). In der Konfigurationsdatei des Apache steht praktisch ein DummyVirtualHost-Eintrag, der anhand von Variablen auf die im Dateisystem als physikalische Verzeichnisse vorhandenen virtuellen Server abgebildet wird. Dadurch lassen
sich neue virtuelle Server anlegen und aktivieren, ohne dass der Apache neugestartet
werden muss! Dieses Schema verdeutlicht die Funktionsweise von mod_vhost_alias:
Apache mit
mod_vhost_alias
www.beispiel.de entspricht
/webs/www.beispiel.de
www.beispiel.de
www.addison-wesley.de
www.firma.com
Ein universeller Eintrag in
der Konfigurationsdatei
httpd.conf für alle
virtuellen Server.
ServerDie einzelnen virtuellen festplatte(n)
Server werden mit Hilfe
globaler Variablen auf
physikalische
Verzeichnisse des Servers
abgebildet.
www.firma.com entspricht
/webs/www.firma.com
www.addison-wesley.de entspricht
/webs/www.addison-wesley.de
<VirtualHost 1.2.3.4>
VirtualDocumentRoot /webs/%0
...
</VirtualHost>
Abbildung 5.4 Schematische Darstellung der Funktionsweise von mod_vhost_alias
Durch das Modul mod_vhost_alias werden die folgenden Konfigurationsanweisungen bereitsgestellt:
VirtualDocumentRoot
Dynamische Definition von Verzeichnissen für namenbasierte virtuelle Server.
Konfigurationsanweisung:
VirtualDocumentRoot
Syntax:
VirtualDocumentRoot Verzeichnispfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_vhost_alias
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Konfigurationsanweisung definiert die Verzeichnisse (vgl. DocumentRootAnweisung) für namensbasierte virtuelle Server. Der angegebene Verzeichnispfad
kann diverse Variable enthalten, die die Anfragen der Client dynamisch auf das
Dateisystems des Servers abbilden. Die einfachste Form ist folgende:
VirtualDocumentRoot /var/websites/%0
5.3 Fortgeschrittene Konfiguration
323
Die Variable %0 entspricht dem kompletten Hostnamen einer Domain (z.B.
www.firma.com) und sorgt in diesem Beispiel dafür, dass Sie im Verzeichnis /var/websites für jeden virtuellen Server, den Sie anlegen möchten, nur ein entsprechende
Unterverzeichnisse anlegen müssen. Diese Unterverzeichnisse müssen genauso heißen, wie der vollständige Hostname des virtuellen Servers, d.h. eine Anfrage für
www.beispiel.de würde die im Internet zu veröffentlichenden Informationen aus dem
Verzeichnis /var/websites/www.beispiel.de beziehen. Falls dieses Verzeichnis nicht vorhanden sein sollte, erhält der Client eine Fehlermeldung. Auch die Verwendung von
symbolischen Verweisen ist möglich, wenn die Optionen (vgl. Options-Anweisung)
entsprechend gesetzt. Damit bei der Benutzung von selbstreferenzierenden Umleitungen auch der richtige Hostname an den Client gesendet wird, sollten Sie die folgende Anweisung im Zusammenspiel mit dynamischen virtuellen Servern unbedingt
ausschalten:
UseCanonicalName Off
Fehlt eine derartige Anweisung und sendet ein Client keinen Host-Header, so wird
der in der globalen Serverkonfiguration als ServerName definierte Name an den Client
zurückgeliefert, was wohl nicht zu dem gewünschten Ergebnis führen würde. Sie
können die Verwendung von mod_vhost_alias auch auf eine bestimmte IP-Adresse
beschränken, wenn Sie die Anweisungen innerhalb eines <VirtualHost>-Containers
aufrufen:
NameVirtualHost 1.2.3.4
<VirtualHost 1.2.3.4>
ServerName server.beispiel.de
UseCanoncicalName Off
VirtualDocumentRoot /var/websites/%0
...
</VirtualHost>
Diese Anweisungen würden die Verwendung von mod_vhost_alias auf die IPAdresse 1.2.3.4 beschränken. Liefert ein Client keinen Host-Header, so wird der
Name des Servers (hier: server.beispiel.de) verwendet. Die Variable %0 steht auch in
diesem Beispiel für den gesamten Hostnamen eines virtuellen Servers (z.B.
www.beispiel.de). Neben dieser Variablen stehen Ihnen eine Reihe weiterer Variablen
zur Verfügung, die Sie bei der Abbildung von namenbasierten virtuellen Server auf
das Dateisystem benutzen können:
%0
Diese Variable
www.beispiel.de).
enthält den
vollständigen Hostnamen
eines
Servers (z.B.
%n
Durch die Variable %n wird der n-te Teil des Hostnamens eines virtuellen Servers
angesprochen, wobei die einzelnen Teile durch einen Punkt voneinander getrennt
werden. Wenn ein virtueller Server beispielsweise www.beispiel.de heißt, würde %2
für den zweiten Teil, d.h. beispiel stehen.
324
5 Konfiguration
%-n
Auch diese Variable entspricht dem n-ten Teil des Hostnamen eines virtuellen Servers, allerdings wird bei der Numerierung mit dem letzten Teil des Hostnamens
begonnen. %-1 steht bei einem virtuellen Server namens www.beispiel.de für den letzten Teil des Hostnamens, d.h. für die Domainendung de.
%n+
Entspricht dem n-ten Teil und allen dahinterfolgenden Teilen des Hostnamens eines
virtuellen Servers, d.h. für unser Beispiel www.firma.com wäre %2+ gleichbedeutend
mit firma.com.
%-n+
Entspricht dem n-ten Teil und allen vorangehenden Teilen des Hostnamens eines virtuellen Servers. Lautet der Name eines virtuellen Servers beispielsweise
www.beispiel.de lautet, steht %2.-1 für www.beispiel.
%n.x
Jetzt wird es interessant, denn %n.x entspricht dem x-ten Zeichen des n-ten Teils des
Hostnamens eines virtuellen Servers. Auch eine Kombination mit den bereits vorgestellten Variablen ist möglich, so dass %2.1 für das erste Zeichen des zweiten Teils des
Hostnamens eines virtuellen Servers steht. Wenn der Name eines virtuellen Servers
beispielsweise www.beispiel.de lautet, steht %2.1 für das erste Zeichen des zweiten
Teils des Hostnamens, d.h. für den Buchstaben b.
%n.-x
Diese Variable entspricht dem x-ten Zeichen des n-ten Teils des Hostnamens eines
virtuellen Servers, wobei die Nummerierung in rückwärtiger Reihenfolge erfolgt.
Wenn der Name eines virtuellen Servers beispielsweise www.beispiel.de lautet, steht
%2.-1 für das letzte Zeichen des zweiten Teils des Hostnamens, d.h. für den Buchstaben l.
%n.x+
Steht für das x-te und alle nachfolgenden Zeichen des n-ten Teils des Hostnamens
eines virtuellen Servers. Sofern ein virtueller Server etwa development.firma.com heißt,
so entspricht %1.5+ dem Teilbegriff lopment.
%n.-x+.
Entspricht dem x-ten Teil des Hostnamen eines virtuellen Servers sowie alle vorangegangenen Zeichen, wobei die Zählung rückwärts erfolgt. Die Variable %1.-5+ steht
also für das fünfte und alle vorangegangenen Zeichen des ersten Teils des Hostnamens eines virtuellen Servers. Heißt ein Server etwa development.firma.com steht
%1.-5+ für develop.
%p
Steht für die Portnummer einer Anfrage (meist 80).
%%
Für den eher unwahrscheinlichen Fall, dass Sie das Prozentzeichen in einem Verzeichnisnamen verwenden möchten, müssen Sie dieses mit %% angeben.
5.3 Fortgeschrittene Konfiguration
325
Wenn Sie eine sehr große Anzahl an virtuellen Servern auf Ihrem Server beheimaten,
ist es aus Performancegründen ratsam, dass Sie die Verzeichnisse der einzelnen
Domains nicht in ein Verzeichnis packen, sondern eine strukturierte Gliederung (etwa
nach Domainendungen) o.ä. vornehmen. Deshalb könnte eine VirtualDocumentRootAnweisung etwa so aussehen:
UseCanonicalName Off
VirtualDocumentRoot /var/webs/%-1/%0
Eine Anfrage für www.beispiel.de würde jetzt aus dem Verzeichnis /var/webs/de/
www.beispiel.de bedient werden. Diese Struktur läßt sich natürlich noch nach Belieben
verfeinern.
VirtualDocumentRootIP
Dynamische Definition von Verzeichnissen für IP-basierte virtuelle Server.
Konfigurationsanweisung:
VirtualDocumentRootIP
Syntax:
VirtualDocumentRootIP Verzeichnispfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_vhost_alias
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die Konfigurationsanweisung VirtualDocumentRootIP ist mit der fast gleichnamigen
Anweisung VirtualDocumentRoot funktional und syntaktisch identisch, allerdings
bezieht diese sich nur auf IP-basierte virtuelle Server. Dazu ein Beispiel:
VirtualDocumentRootIP /var/websites/%0
Die Variable %0 entspricht der kompletten IP-Adresse eines IP-basierten virtuellen
Servers (z.B. 195.128.75.11) und sorgt in diesem Beispiel dafür, dass Sie im Verzeichnis /var/websites für jeden IP-basierten Server, den Sie erzeugen möchten, ein Verzeichnis anlegen müssen. Dieses Verzeichnis muss genauso heissen, wie die vollständige IP-Adresse des virtuellen Servers, d.h. eine Anfrage für 195.128.75.11 würde die
im Internet zu veröffentlichenden Informationen aus dem Verzeichnis /var/websites/195.128.75.11 beziehen. Falls dieses Verzeichnis nicht vorhanden sein sollte,
erhält der Client eine Fehlermeldung. Auch die Verwendung von symbolischen Verweisen ist möglich, wenn die Optionen (vgl. Options-Anweisung) entsprechend
gesetzt. Damit bei der Benutzung von selbstreferenzierenden Umleitungen auch der
richtige Hostname an den Client gesendet wird, sollten Sie die folgende Anweisung
im Zusammenspiel mit dynamischen (IP-basierten) virtuellen Servern unbedingt wie
folgt setzen:
UseCanonicalName DNS
326
5 Konfiguration
Fehlt eine derartige Anweisung und sendet ein Client keinen Host-Header, so wird
der in der globalen Serverkonfiguration als ServerName definierte Name an den Client
zurückgeliefert, was wohl nicht zu dem gewünschten Ergebnis führen würde. Innerhalb der VirtualDocumentRootIP-Anweisung können Sie übrigens alle Variablen
benutzen, die auch für die Anweisung VirtualDocumentRoot verfügbar sind. In der
Praxis dürften die Variable %1 bis %4 am häufigsten Verwendung finden!
VirtualScriptAlias
Dynamische Definition des cgi-bin-Verzeichnisses für namenbasierte virtuelle Server.
Konfigurationsanweisung:
VirtualScriptAlias
Syntax:
VirtualScriptAlias Verzeichnispfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_vhost_alias
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Wenn die dynamisch erstellten virtuellen Server auch eigene CGI-BIN-Verzeichnisse
bekommen sollen, können Sie mit der Anweisung VirtualScriptAlias ein Verzeichnis
definieren, in dem die Ausführung von CGI-Skripten für die (namenbasierten) virtuellen Server erlaubt ist (vgl. ScriptAlias-Anweisung). Ein Beispiel:
VirtualScriptAlias /var/websites/%0/cgi-bin
Hinweis
Sobald ein Client versucht, auf ein CGI-Skript unter der Adresse www.beispiel.de/cgibin/test.pl zuzugreifen, würde diese Datei test.pl aus dem Verzeichnis /var/websites/www.beispiel.de/cgi-bin/ aufgerufen.
Bei Verwendung von mod_vhost_alias kann es bei der Umsetzung der CGI-BINVerzeichnisse zu Fehlern kommen, wenn in der serverweiten Konfiguration
zusätzlich das Modul mod_alias und die ScriptAlias-Anweisung aktiv ist. Deaktivieren Sie in diesem Fall die ScriptAlias-Anweisung und verwenden Sie zur
Definition der CGI-BIN-Verzeichnisse ausschließlich die VirtualScriptAliasAnweisung! Zur Veranschaulichung soll die folgende Beispielkonfiguration
dienen:
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
VirtualScriptAlias /kunden/%0/cgi-bin/
Durch diese Konfiguration würde eine Anfrage für die Datei /cgi-bin/beispiel.pl immer
im Verzeichnis /usr/local/apache2/cgi-bin landen und die CGI-BIN-Verzeichnisse der
virtuellen Server würden nicht funktionieren. Deaktivieren Sie deshalb in einem solchen Fall die ScriptAlias-Anweisung und verwenden Sie nur die VirtualScriptAliasAnweisung!
5.3 Fortgeschrittene Konfiguration
327
VirtualScriptAliasIP
Dynamische Definition des cgi-bin-Verzeichnisses für IP-basierte virtuelle Server.
Konfigurationsanweisung:
VirtualScriptAliasIP
Syntax:
VirtualScriptAliasIP Verzeichnispfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_vhost_alias
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Wenn die dynamisch erstellten virtuellen Server auch eigene cgi-bin-Verzeichnisse
bekommen sollen, können Sie mit der Anweisung VirtualScriptAliasIP ein Verzeichnis
definieren, in dem die Ausführung von CGI-Skripten für die IP-basierten virtuellen
Server erlaubt ist (vgl. ScriptAlias-Anweisung). Ein Beispiel:
VirtualScriptAliasIP /var/websites/%0/cgi-bin
Sobald ein Client versucht, auf ein CGI-Skript unter der Adresse 195.158.141.27/cgibin/test.pl zuzugreifen, würde diese Datei test.pl aus dem Verzeichnis /var/websites/195.158.141.27/cgi-bin/ aufgerufen. Hinweis: Bitte lesen Sie auch die Erläuterungen zur Verwendung von mod_vhost_alias in Kombination mit mod_alias oder
mod_userdir (vgl. VirtualScriptAlias-Anweisung).
mod_vhost_alias und Zugriffsstatistiken
Ein Problem bei der Verwendung von mod_vhost_alias ist die Protokollierung von
Zugriffen auf die einzelnen virtuellen Server. Leider ist es bei der Verwendung von
mod_vhost_alias nicht möglich, für jeden virtuellen Server eine seperate Logdatei zu
führen. Dadurch werden alle Zugriffe auf die einzelnen virtuellen Server in die Logdatei des Hauptservers protokolliert und müssen manuell aus dieser Datei gefiltert
werden.
Findige Leser werden sich vielleicht ein eigenes Skript mit Unix/Linux-Werkzeugen
basteln, dies ist aber nicht nötig, da der Apache ein entsprechendes Skript bereits mitliefert. Im Unterverzeichnis support des entpackten Apache-Quellcodes ist ein Perlskript namens split-logfiles, welches exakt diese Aufgabe erledigt. Das Skript liest
Daten aus der Standardeingabe (vgl. Anhang) und legt eine Logdatei je virtuellem
Server an. Falls für einen virtuellen Server bereits Logdaten vorhanden sind, werden
die neuen Daten einfach angehangen. Kopieren Sie die Datei split-logfiles in den Systempfad, damit Sie das Programm später einfacher aus einem Cronjob aufrufen können:
# mv /home/sebastian/httpd-2.0.42/support/split-logfile /usr/bin
Wenn Sie den Apache an einem anderen Ort als /home/sebastian entpackt haben
(wovon ich ausgehe), müssen Sie diesen Befehl entsprechend ändern. Mich persön-
328
5 Konfiguration
lich stört an dem Programm split-logfile, dass das Programm die gefilterten Logdateien einfach in das aktuelle Verzeichnis schreibt und nicht in ein zu definierendes
Verzeichnis (es lebe die Ordnung!). Deshalb habe ich das Skript mit einem einzigen
Befehl modifiziert, damit die erzeugten Logdateien sauber in ein festes Verzeichnis
kopiert werden. Die letzten Zeilen des Perlskriptes sehen normalerweise wie folgt
aus:
printf $vhost "%s", $log_line;
}
exit 0;
Ich habe diese Zeilen wie folgt geändert:
printf $vhost "%s", $log_line;
}
system("mv -b *.log /var/log/apache");
exit 0;
Hinweis
Der eingefügte system()-Befehl verschiebt alle Dateien aus dem aktuellen Verzeichnis
mit der Endung .log in das Verzeichnis /var/log/apache und erstellt dort eine Sicherheitskopie einer bereits vorhandenen Logdatei. Den Parameter -b können Sie auch
weglassen, wenn Sie keine Sicherheitskopien der einzelnen Logdateien haben möchten.
Überprüfen Sie unbedingt die erste Zeile des split-logfile Skriptes, denn diese
Datei definiert den Interpreter für das Skript und standardmäßig zeigt dieser
Interpreter auf die Datei /usr/local/bin/perl. Auf vielen Systemen ist Perl jedoch
an einer anderen Stelle installiert, so dass die erste Zeile des Skriptes entsprechend angepasst werden muss. Wenn Sie sich nicht sicher sind, in welchem
Verzeichnis das Perl-Programm gespeichert ist, erhalten Sie den korrekten Pfad
mit diesem Befehl:
# type perl
Den zurückgegebenen Pfad müssen Sie in die erste Zeile von split-logfile eintragen.
Wird beispielsweise der Pfad /usr/bin/perl zurückgeliefert, müssen Sie die erste Zeile
so ändern:
#!/usr/bin/perl
Speichern Sie die Datei und setzen Sie die Ausführberechtigung (chmod +x split-logfile), falls diese noch nicht vorhanden ist. Diese Hinweise gelten übrigens für alle
(Perl-) Skripte.
Sie können das Skript split-logfile entweder manuell oder automatisiert aufrufen. Der
manuelle Aufruf erfolgt durch:
# cat /var/log/apache/access.log | split-logfile
Hinweis
5.3 Fortgeschrittene Konfiguration
329
Die Pfade der Logdateien im Skript selbst und den vorgestellten Befehlen müssen Sie gegebenfalls gemäß Ihren lokalen Pfaden anpassen. Nachdem der
Befehl abgeschlossen ist, befinden sich im Verzeichnis /var/log/apache die Logdateien der einzelnen virtuellen Server, die durch externe Programme ausgewertet werden können (z.B. webalizer). Eine weitere Möglichkeit, die Logdateien für die einzelnen virtuellen Server zu erzeugen, ist der Aufruf des
Skriptes durch einen Eintrag in der Datei /etc/crontab:
Hinweis
5 23 * * * root /bin/cat /var/log/apache/access.log | split-logfile
Passen Sie die Dateipfade entsprechend an! Durch diesen Befehl werden die
Logdateien der einzelnen virtuellen Servern jede Nacht um 23:05 Uhr erzeugt.
Starten Sie den cron-Daemon neu und die Zeile wird aktiv. Unter SuSE Linux
können Sie dies durch folgenden Befehl erreichen:
# rccron restart
Unter Debian hilft folgender Befehl:
# /etc/init.d/cron restart
Ein Kapitel über die Auswertung der Logdateien durch externe Programme finden
Sie im Verlauf dieses Buches.
5.3.2
URL-Manipulation mit mod_rewrite
Eingehende Anfragen lassen sich mit den Konfigurationsanweisungen Alias und AliasMatch umschreiben und an eine alternative Adresse umleiten. Zwar erlaubt AliasMatch die Benutzung von regulären Ausdrücken, aber für kompliziertere Umleitungen sind diese beiden Anweisungen nicht zu gebrauchen.
mod_rewrite ermöglicht u.a. komplizierteste Umschreibungen und Weiterleitungen,
die sogar an Bedingungen geknüpft werden können. Dabei stellt das Modul eine
unglaubliche Flexibilität zur Verfügung, deren komplette Beschreibung den Rahmen
dieses Buches sprengen würde.
Der Autor von mod_rewrite, der Deutsche Ralf S. Engelschall (http://www.engelschall.
com) beschreibt sein Modul als »regelbasierte Umschreibungs-Engine« und als das
Schweizer Messer der URL-Umschreibungen. Es dient dazu, eingehende Anfragen
unter Beachtung und Anwendung vorher definierter Regelsätze umzuleiten.
RewriteEngine
Aktiviert oder deaktiviert die Verwendung von mod_rewrite und dessen Konfigurationsoptionen.
330
Konfigurationsanweisung:
5 Konfiguration
RewriteEngine
Syntax:
RewriteEngine on | off
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost- Kontext,
.htaccess-Kontext, <Directory>-Container,
<Location>-Container, <Files>-Container
Anweisung aktiv:
nein
Diese Konfigurationsoption bestimmt die Verwendung von mod_rewrite und der
durch dieses Modul bereitgestellten Konfigurationsanweisungen. Der Umschreibungsalgorithmus lässt sich komplett ausschalten und alle Konfigurationsanweisungen des Moduls mod_rewrite werden übersprungen:
RewriteEngine off
Sofern Sie dynamische Umschreibungen mit Hilfe von mod_rewrite vornehmen
möchten, müssen Sie die Verwendung von mod_rewrite explizit einschalten:
RewriteEngine on
Bitte beachten Sie, dass die Aktivierung von mod_rewrite in der Serverkonfiguration
auch wirklich nur innerhalb der globalen Serverkonfiguration Gültigkeit besitzt. Sie
berührt dabei <VirtualHost>-, <Directory>- oder <Location>-Anweisungen keineswegs
und ist auch nicht automatisch in einer .htaccess-Datei gültig: Sie müssen für diese
Bereiche die Umschreibungs-Engine explizit aktivieren!
RewriteBase
Diese Anweisung legt eine Basis-URL für die Umschreibungen auf Verzeichnisebene
fest.
Konfigurationsanweisung:
RewriteBase
Syntax:
RewriteBase Url-Pfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_rewrite
Kontext:
.htaccess-Kontext, <Directory>-Container
Anweisung aktiv:
nein
Oft entspricht die nach außen sichtbare Struktur einer Internetseite nicht deren wirklicher, physikalischer Verzeichnis- und Dateistruktur auf dem Server. Wenn dies der
Fall ist und Sie beispielsweise mit einer Alias-Anweisung ein virtuelles Verzeichnis
auf ein reales abbilden, müssen Sie mit der Konfigurationsanweisung RewriteBase die
Basis-URL für die weiteren Umschreibungen definieren. Dies geschieht meist in
5.3 Fortgeschrittene Konfiguration
331
einem Verzeichnisabschnitt oder in einer .htaccess-Datei, bevor die eigentlichen
Umschreibungsregeln definiert werden.
Sie könnten beispielsweise eine Alias-Anweisung benutzen, um eine eingehende
Anfrage für ein Verzeichnis namens /news auf das interne Verzeichnis /daten/nachrichten umzuleiten:
Alias /news /daten/nachrichten
Damit der Server weiß, dass wir durch das virtuelle Verzeichnis /news auf die Informationen, die ja eigentlich unter /daten/nachrichten gespeichert sind, zugreifen, müssen wir das Basisverzeichnis für die künftigen Umschreibungen erneut definieren.
Dazu geben wir die Adresse ein, unter der das aktuelle Verzeichnis von außen, d.h.
aus dem Internet, erreichbar ist:
RewriteBase /news
Vorher müssen wir allerdings die Umschreibungsengine aktivieren, wobei diese
Anweisung nur einmal vorgenommen werden muss:
RewriteEngine On
Jetzt können wir Umschreibungen ohne Probleme vornehmen:
RewriteRule ^wetter_heute\.html$ wetter_morgen.html
Eingehende Anfragen auf die Datei /news/wetter_heute.html werden jetzt korrekterweise auf die Datei wetter_morgen.html umgeschrieben.
RewriteCond
Definition von Bedingungen für RewriteRule-Anweisungen.
Konfigurationsanweisung:
RewriteCond
Syntax:
RewriteCond Testargument Muster [Flag]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost-Kontext, <Location>Container, .htaccess-Kontext, <Directory>-Container
Anweisung aktiv:
nein
Mit dieser Konfigurationsanweisung können Sie Bedingungen (engl. conditions) für
eine RewriteRule-Anweisung definieren. Sollten die aufgestellten Bedingungen erfüllt
werden, wird die darauf folgende RewriteRule-Anweisung ausgeführt. Andernfalls
wird die RewriteRule-Anweisung übersprungen. Ein Beispiel:
RewriteCond %{REMOTE_HOST}% \.aol\.com$
RewriteRule ^/index.html /index-aol_benutzer.html [R=permanent]
332
5 Konfiguration
Diese Regel prüft zunächst, ob in der Adresse des Benutzers der Name aol.com vorkommt, d.h., diese Regel zielt auf Benutzer des beliebten Internetproviders AOL ab.
Sollte dies der Fall sein, wird bei einem Zugriff auf die Startseite index.html der Benutzer auf eine speziell für ihn optimierte Version der Startseite (index-aol_benutzer.html)
dauerhaft umgeleitet.
Der erste Parameter einer RewriteCond-Anweisung ist das so genannte Testargument,
welches anhand einer oder mehrerer durch die Anfrage des Clients oder in der allgemeinen Umgebung des Servers zur Verfügung stehende Variablen die Grundlage für
eine aufgestellte Bedingung einer Umschreibungsregel bildet. Durch so genannte
Backreferences können Sie auch auf vorangegangene RewriteRule- und RewriteCondAnweisungen zurückgreifen, auf deren Verwendung wir im Laufe dieses Kapitels
noch weiter eingehen werden.
Als zweites Argument verlangt die Anweisung RewriteCond einen regulären Ausdruck, der mit dem Wert und dem Inhalt des ersten Parameters der RewriteCondAnweisung, d.h. mit dem Testargument, verglichen werden soll.
Ein Beispiel: Wir möchten abhängig von dem durch den Client benutzten Browsertyp
eine Umleitung vornehmen, da wir gestalterische Elemente in unserer Internetseite
verwendet haben, die eventuell nicht durch jeden Browsertyp in einer annehmbaren
Form dargestellt werden können. Sollte ein Client deshalb einen Browser verwenden,
von dem wir sicher wissen, dass dieser die benutzten Designelemente nicht oder nur
schlecht darstellen kann, können wir den Client auf eine entsprechend präparierte
Seite umleiten, wo die eingangs gewünschten Informationen ohne besondere Designelemente abrufbar sind:
RewriteCond
RewriteRule
RewriteCond
RewriteRule
%{HTTP_USER_AGENT} ^Mozilla.*
...
%{HTTP_USER_AGENT} ^Lynx.*
...
Diese beiden RewriteCond-Anweisungen überprüfen den Browsertyp eines Clients
auf die Produktnamen, die normalerweise durch den Netscape Navigator und den
Microsoft Internet Explorer oder den konsolenbasierten Browser Lynx übermittelt
werden. Die durch drei Punkte angedeutete RewriteRule-Anweisung könnte nun,
abhängig von dem durch den Client verwendeten Browsertyp, die Umleitung auf
eine entsprechend präparierte Homepage vornehmen.
Durch das Voranstellen eines Ausrufezeichens kann ein überprüftes Muster auch
negiert werden, wie folgendes Beispiel zeigt:
RewriteCond %{HTTP_USER_AGENT} !^Lynx.*
RewriteRule ...
Diese RewriteCond-Anweisung würde für alle Browser zutreffen, die nicht als Produktnamen die Kennung »Lynx« übermitteln, d.h., sie gilt für alle Browser außer
dem konsolenbasierten Textbrowser Lynx.
Innerhalb der RewriteCond- und RewriteRule-Anweisung stehen Ihnen fast alle in der
Umgebung des Servers bereitgestellten Variablen zur freien Verfügung. Eine Übersicht
5.3 Fortgeschrittene Konfiguration
333
dieser Umgebungsvariablen wie z.B. DOCUMENT_ROOT und REMOTE_HOST) finden Sie Anhang dieses Buches, außerdem stehen Ihnen noch die nachfolgenden Variablen zur Verfügung:
Datum und Uhrzeit
TIME_YEAR
Enthält das Jahr (engl. year) der aktuellen Serveruhrzeit.
TIME_MON
Entspricht den aktuellen Monat (engl. month) der Serverzeit.
TIME_DAY
Der aktuelle Tag (engl. day) der Serveruhrzeit wird in dieser
Variablen gespeichert.
TIME_HOUR
Die Stundenzahl (engl. hour) der aktuellen Uhrzeit auf dem Server
ist in dieser Variablen enthalten.
TIME_MIN
Wenn Sie die aktuelle Minute (engl. minute) haben möchten,
können Sie diese Variable benutzen.
TIME_SEC
Auch die aktuelle Sekundenzahl der Serverzeit wird in einer
Variablen namens TIME_SEC gespeichert.
TIME_WDAY
Sollten Sie Ihre Besucher beispielsweise am Sonntag darauf hinweisen möchten, dass diese mal wieder in die Kirche gehen sollten,
können Sie die Variable TIME_WDAY verwenden, die den
aktuellen Tag der Woche enthält (engl. weekday).
TIME
Auch die vollständige Serverzeit wird in einer einzigen Variablen
namens TIME gespeichert.
Durch diese Variablen sind beispielsweise zeit- und datumsabhängige Umleitungen
realisierbar. Folgendes Beispiel leitet die Benutzer in der Zeit von 8-18 Uhr auf die
Seite index_tag.html und in der restlichen Zeit auf die Seite index_nacht.html, um:
RewriteCond
RewriteCond
RewriteRule
RewriteRule
%{TIME_HOUR}%{TIME_MIN} >0800
%{TIME_HOUR}%{TIME_MIN} <1800
^index\.html$ index_tag.html
^index\.html$ index_nacht.html
Eventuell möchten Sie am Heiligen Abend den Besuchern Ihrer Internetseite eine spezielle Seite präsentieren, die diesen ein frohes Fest und einen guten Rutsch wünscht:
RewriteCond %{TIME_DAY}%{TIME_MON} =2412
RewriteRule ^/index\.html$ index_weihnachten.html [R,L]
Eine derartige Umleitung ist mit mod_rewrite wirklich gut und recht einfach zu realisieren.
334
5 Konfiguration
Spezielle Variablen
API_VERSION
Dies ist die Versionsnummer des Application Programming Interface (API) des Apache, einer Art Schnittstelle zwischen dem
Kern des Servers und den verfügbaren Modulen wie z.B.
mod_rewrite oder mod_alias. Sie wird definiert in der Datei
ap_mmn.h, die im Unterverzeichnis include Ihrer lokalen Apache-Installation gespeichert ist, und entspricht für die mir vorliegende Version 2.0.39 des Apache der Nummer 20020612.
Diese Versionsnummer wird wohl für Entwickler von Zusatzmodulen für den Apache interessant sein.
THE_REQUEST
Diese Variable enthält die volle Anfrage, die ein Client an den
Server gesendet hat. Dabei werden keine zusätzlichen durch
den Browser geschickten Headerfelder gespeichert. Ein möglicher Wert dieser Variable wäre etwa GET /index.html HTTP/1.1.
REQUEST_URI
Entspricht dem Zielobjekt, das ein Client angefordert hat. In
unserem kleinen Beispiel zur Variable THE_REQUEST entspräche dies dem Wert /index.html.
REQUEST_FILENAME
Der volle lokale Pfad einer angeforderten Datei im Dateisystem
wird in dieser Variablen gespeichert.
IS_SUBREQ
Enthält den Wert wahr, wenn eine Anfrage Teil einer bereits
verarbeiteten Anfrage ist, andernfalls falsch.
Es existieren zusätzlich noch folgende vier Abfrageformate für die Variablen einer
RewriteCond-Anweisung:
%{ENV:Variable}
Mit diesem Aufruf können Sie eine beliebige Umgebungsvariable des Apache-Prozesses auslesen. Dies ist besonders dann hilfreich, wenn vorhergehende RewriteRuleAnweisungen neue Umgebungsvariablen definiert haben, die Sie dann durch eine
neue RewriteCond-Anweisung auslesen und benutzen können. Dadurch sind sinnvolle und mehrfach verschachtelte Umleitungen möglich, die dennoch sehr speziell
und individuell sind. Ein Beispiel könnte etwa so aussehen:
RewriteCond %{ENV:Anfragequelle} ^intern.*
Diese Abfrage würde die Umgebungsvariable Anfragequelle, die vorher durch eine
RewriteRule-Anweisung definiert worden ist, abfragen. Sollte diese den Wert intern
besitzen, würde die nachfolgende RewriteRule-Anweisung ausgeführt, ansonsten nicht.
%{LA-U:Variable}
Es gibt Variablen, die aufgrund der zeitlich nacheinander abfolgenden Bearbeitungsphasen einer Clientanfrage erst nach der Verarbeitung durch mod_rewrite zur Verfügung stehen, d.h., eine einfache Abfrage einer solchen Variablen würde ein leeres
Ergebnis zurückliefern, da diese Variable für mod_rewrite einfach noch nicht vorhanden ist. In einem solchen Fall muss eine Vorausschau (engl. look ahead, la) einen internen Sub-Request durchführen, um so den endgültigen Wert einer Variable zu bestimmen, der eigentlich erst in einer späteren Bearbeitungsphase einer Clientanfrage
5.3 Fortgeschrittene Konfiguration
335
bekannt ist. Ein oft dargestelltes Beispiel, welches in der Realität sicherlich häufiger
zum Einsatz kommt, ist die Abfrage der Umgebungsvariablen REMOTE_USER, die
erst in der Authentifizierungsphase einer Anfrage definiert wird. Diese Authentifizierungsphase wird intern jedoch nach dem Einsatz von mod_rewrite durchgeführt, d. h.,
mod_rewrite muss praktisch dem weiteren Ablauf einer Abfrage vorgreifen, um den
Wert für die Variable REMOTE_USER zu erhalten. Ein Beispiel:
RewriteCond %{LA-U:REMOTE_USER} ^administrator$
Diese Bedingung überprüft, ob die Variable REMOTE_USER dem Wert Administrator
entspricht. Sollte dies der Fall sein, würde eine darauffolgende RewriteRule-Anweisung ausgeführt.
Wenn Sie eine RewriteCond-Anweisung in einer .htaccess-Datei vornehmen, können
Sie getrost auf die Vorausschau (look ahead) von Variablenwerten verzichten, da der
Apache diese Dateien erst in einer sehr späten Phase der Abarbeitung einer Clientanfrage bearbeitet, so dass bereits alle anderen Module zum Einsatz gekommen sind
und die entsprechenden Variablen zur Verfügung stehen.
%{LA-F:Variable}
Diese Formatangabe ist der vorhergehenden Formatangabe sehr ähnlich, allerdings
funktioniert der interne Sub-Request nicht auf URL-Basis, sondern auf Basis des
Dateinamens. Das Ergebnis ist meist dasselbe, dennoch ist die Verwendung von
LA-U dieser Formatangabe vorzuziehen.
%{HTTP:Header}
Mit dieser Formatangabe erhalten Sie Zugriff auf den Inhalt eines bei der Anfrage des
Client übermittelten HTTP-Headers. Ein Beispiel:
RewriteCond %{HTTP:REMOTE_ADDR} ^1\.2\.3\.4$
Diese Bedingung überprüft die IP-Adresse des Benutzers und würde eine darauf folgende RewriteRule-Anweisung nur ausführen, wenn der Benutzer die IP-Adresse
1.2.3.4 hätte.
Zusätzlich kann die RewriteCond-Anweisung als Muster neben einem regulären Ausdruck auch eines der speziellen Argumente benutzen:
-d
Dieses Argument überprüft, ob das übergebene Verzeichnis physikalisch vorhanden
ist. Eventuell definierte Zugangsbeschränkungen werden nicht berücksichtigt. Ein
Beispiel:
RewriteCond %{REQUEST_URI} -d
-f
Untersucht, ob die angegebene Datei überhaupt physikalisch existiert. Ein Beispielaufruf:
RewriteCond %{REQUEST_FILENAME} -f
336
5 Konfiguration
-s
Das Argument ist prinzipiell mit dem bereits vorgestellten Argument -f identisch,
allerdings ist das Ergebnis nur exakt dann positiv, wenn die Größe der untersuchten
Datei größer ist als Null. Beispiel:
RewriteCond %{REQUEST_FILENAME} -s
-l
Dieses Argument kann überprüfen, ob es sich bei der angegebenen Datei bzw. dem
angegebenen Verzeichnis um einen symbolischen Verweis handelt. Eine sinnvolle
Verwendung dieses Arguments wäre die Überprüfung, ob es sich bei einem CGISkript um eine wirkliche Datei oder einen symbolischen Link handelt. Sollte es sich
dabei um einen symbolischen Link handeln, könnte die Ausführung des Skriptes verhindert werden:
RewriteCond %{REQUEST_FILENAME} !-l
Eine hierauf folgende RewriteRule-Anweisung würde nur ausgeführt, wenn es sich
bei dem angesprochenen Skript nicht um einen symbolischen Link handeln würde.
-F
Das bereits vorgestellte Argument -f prüft die physikalische Existenz einer Datei. Das
Argument -F geht jedoch noch einen Schritt weiter und führt eine interne Anfrage
durch, die überprüft, ob die angegebene Datei existiert und darüberhinaus trotz eventuell vorhandener Zugriffsbeschränkungen für einen Client abrufbar ist. Ein Beispiel:
RewriteCond %{REQUEST_FILENAME} -F
Bitte beachten Sie jedoch, dass derartige RewriteCond-Anweisungen sehr prozessorintensiv sind.
-U
Wenn Sie überprüfen möchten, ob die angeforderte URL trotz eventuell vorhandener
Zugriffsbeschränkungen für einen Client erreichbar ist, können Sie das Argument -U
benutzen. Bitte beachten Sie jedoch, dass derartige RewriteCond-Anweisungen sehr
prozessorintensiv sind.
=Zeichenkette
Sie können mit diesem Argument untersuchen, ob eine Bedingung, auf die Sie prüfen,
exakt den Wert einer von Ihnen definierten Zeichenkette hat. Ich habe beispielsweise
vorhin das aktuelle Datum des Servers mit dem Datum des Heiligen Abends verglichen:
RewriteCond %{TIME_DAY}%{TIME_MON} =2412
>Zeichenkette
Ich habe vorhin das Argument >Zeichenkette benutzt, als ich abhängig von der jeweiligen Uhrzeit eine andere Version meiner Homepage ins Internet stellen wollte:
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0800
5.3 Fortgeschrittene Konfiguration
337
Allgemein können Sie mit diesem Argument testen, ob eine Bedingung größer ist, als
die von Ihnen übergebene Zeichenkette.
<Zeichenkette
Um zu überprüfen, ob eine Bedingung kleiner ist als die von Ihnen übergebene Zeichenkette, können Sie das Argument <Zeichenkette benutzen. Ich habe dieses ebenfalls
in der vorhin durchgeführten Unterscheidung zwischen Tag und Nacht benutzt:
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1800
Als dritten und letzten Parameter ermöglicht RewriteCond die Angabe von so genannten Flags (engl. Kennzeichen, Markierung), die so auch einer RewriteRule-Anweisung
übergeben werden können. Folgende Markierungen sind dabei möglich:
nocase, NC
Wenn Sie dieses Kennzeichen einer RewriteCond-Anweisung übergeben, wird beim
Vergleich zwischen der Bedingung und dem regulären Ausdruck nicht zwischen
Groß- und Kleinschreibung unterschieden. Gerade beim Vergleich von Zeichenketten
ist es oft nicht exakt voraussagbar, welche genaue Schreibweise der Wert des Testarguments hat. Ein Beispiel:
RewriteCond %{REQUEST_URI} ^index\.html$ [NC]
Diese Anweisung überprüft den Namen der vom Client angeforderten Datei mit dem
Wert index.html, ohne dabei auf Groß- und Kleinschreibung zu achten. Eine darauffolgende RewriteRule-Anweisung würde auch ausgeführt, wenn ein Client die Datei
Index.html oder inDex.HTml angefordert hat. Das Kürzel NC in den eckigen Klammern kann übrigens auch durch die Zeichenkette nocase ersetzt werden. Ich denke,
dass gerade für Anfänger die vielen Abkürzungen der Merkmale (Flags) in
mod_rewrite eventuell etwas verwirrend sind und rate daher Anfängern lieber die
etwas längere Schreibweise nocase zu verwenden, da jeder Benutzer, der der englischen Sprache zumindest einigermaßen mächtig ist, wahrscheinlich aus dem Begriff
nocase die Nichtbeachtung von Groß- und Kleinschreibung erahnen kann.
ornext, OR
Wenn Sie mehrere direkt aufeinander folgende RewriteCond-Anweisungen vornehmen, werden diese normalerweise mit einem logischen UND verknüpft. Es kann
jedoch durchaus sinnvoll sein, eine logische ODER-Verknüpfung zwischen zwei
RewriteCond-Anweisungen vorzunehmen. Benutzen Sie dazu das Merkmal OR,
wobei auch hier die lange Schreibweise ornext möglich und für unerfahrene Benutzer
ratsam ist. Folgendes Beispiel verknüpft zwei Regeln mit einem logischen ODER:
RewriteCond %{REMOTE_HOST} ^.*\.domainA.de$ [OR]
RewriteCond %{REMOTE_HOST} ^.*\.domainB.de$
Diesen beiden Regeln könnte nun eine RewriteRule-Anweisung folgen, die den
Zugriff von jedem Rechner der Adresse DomainA.de oder von jedem Rechner der
DomainB.de verbietet.
Hinweis
338
5 Konfiguration
Wenn Sie mehrere Merkmale (Flags) für eine RewriteRule- oder RewriteCondAnweisung definieren möchten, müssen Sie die einzelnen Merkmale durch ein
Komma trennen!
Wie bereits erwähnt, werden aufeinander folgende RewriteCond-Anweisungen automatisch mit einem logischen UND verknüpft, d.h., die einzelnen Bedingungen müssen alle wahr sein, damit eine nachfolgende RewriteRule-Anweisung ausgeführt wird.
RewriteCond
RewriteCond
RewriteCond
RewriteRule
%{HTTP_USER_AGENT} !^Lynx.*
%{REMOTE_HOST} ^.*\.domainA\.de [NC]
%{TIME_DAY}%{TIME_MON} =3112
^/index\.html$ /silvester.html [R,L]
Diese drei RewriteCond-Anweisungen werden mit einem logischen UND verknüpft,
d.h., sie müssen alle wahr sein, damit die RewriteRule-Anweisung ausgeführt wird.
Die Regeln bedeuten, dass ein Client, dessen Browser sich nicht (symbolisiert durch
ein vorangestelltes Ausrufezeichen) als Lynx meldet und der von der Adresse
domainA.de kommt, am 31.12. des Jahres beim Zugriff auf die Datei index.html auf die
Datei silvester.html umgeleitet wird. Auf der Seite silvester.html könnten dann die besten Wünsche für das kommende Jahr stehen, die Sie Ihren Benutzern übermitteln
möchten. Sie könnten auch die drei Regeln durch ein logisches ODER verknüpfen:
RewriteCond
RewriteCond
RewriteCond
RewriteRule
%{HTTP_USER_AGENT} ^Lynx.* [OR]
%{REMOTE_HOST} ^.*\.domainA\.de [NC]
%{TIME_DAY}%{TIME_MON} =3112
^/index\.html$ /silvester_kein_schnickschnack.html [R,L]
Die Bedeutung dieser drei Regeln ist fast mit dem Beispiel von eben identisch, allerdings wird jeder Client, der sich entweder als Lynx meldet oder von der Adresse
domainA.de kommt, am 31.12. des Jahres beim Zugriff auf die Seite index.html auf die
Seite silvester_kein_schnickschnack.html umgeleitet. Auf dieser Seite könnten Sie für
bestimmte Benutzer, die über keinen grafischen Browser verfügen, eine speziell präparierte Seite mit Wünschen zum neuen Jahr bereitstellen, die ohne jeglichen grafischen Schnickschnack auskommt.
Wenn Sie überprüfen möchten, ob eine Variable keinen Wert enthält oder überhaupt
nicht gesetzt ist, können Sie folgende RewriteCond-Anweisung benutzen:
RewriteCond %{Beispielvariable} !^$
Sie müssen die entsprechende Variable (hier: Beispielvariable) durch die Variable ersetzen, die Sie überprüfen möchten. Diese RewriteCond-Anweisung wird nur wahr,
wenn die entsprechende Variable auch einen Wert enthält.
Den letzten Teil meiner Erklärungen zur RewriteCond-Anweisung möchte ich den so
genannten Back-References widmen, die so auch in der in diesem Teil schon öfter
genannten RewriteRule-Anweisung benutzt werden können. Back-References sind, wie
die Übersetzung des englischen Begriffes verdeutlicht, Bezugnahmen auf vorhergehende Definitionen von Suchmustern in einer RewriteCond- und RewriteRule-Anwei-
5.3 Fortgeschrittene Konfiguration
339
sung. Dabei können Sie jeweils nur auf die Gruppen einer solchen Anweisung
zurückgreifen, die sich durch runde Klammern definieren lassen. Die Referenzierung
auf eine Gruppe des regulären Ausdrucks einer RewriteRule-Anweisung erfolgt durch
Angabe eines ganzzahligen und fortlaufenden Indexes, der mit einem vorangestellten
Dollarzeichen angegeben werden muss (z.B. $1 für die erste Gruppe usw.). Sollten Sie
eine Gruppe referenzieren (z.B. $6), die nicht existiert, ist das Ergebnis einer solchen
Bezugnahme immer leer.
In einer RewriteRule-Anweisung können Referenzen in der Umschreibungsadresse
verwendet werden. Dabei ist der einfachste Fall die Referenzierung auf eine Gruppe,
die in der jeweiligen RewriteRule-Anweisung selbst definiert worden ist:
RewriteRule ^(.*\.jpg) /usr/local/apache2/htdocs/bilder$1 [L]
Der Dateiname einer Bilddatei mit der Endung .jpg wird durch die Variable $1 referenziert, da dies die erste in Klammern zu einer Gruppe zusammengefasste Referenz
ist.
Sie können auch auf Gruppen von RewriteCond-Anweisungen durch Angabe eines
Prozentzeichens gefolgt von einer ganzzahligen und fortlaufenden Indexzahl zugreifen (z.B. %1). Dabei ist %1 immer die erste Gruppe der zuletzt vorkommenden
RewriteCond-Anweisung, d.h., es ist nicht möglich, bei mehrfacher Benutzung von
RewriteCond-Anweisungen auf Gruppen zurückzugreifen, die vor der zuletzt vorgenommenen RewriteCond-Anweisung definiert worden sind. Auch bei den mit einem
Prozentzeichen gekennzeichneten Referenzen gilt, dass die Referenzierung auf eine
nicht vorhandene Gruppe einen leeren Wert zurückgibt.
Ich möchte anhand eines kleinen Beispiels die Verwendung der Referenzen $1 bei
einer RewriteRule-Anweisung bzw. %1 im Falle einer RewriteCond-Anweisung erläutern.
Wenn Sie beispielsweise die individuellen Benutzeradressen der Form
http://www.beispiel.de/~benutzername/ auf einen anderen Server verschoben haben, da
die Anzahl Ihrer lokalen Benutzer inzwischen zu groß für den ursprünglichen Server
geworden ist, können Sie alle eingehenden Anfragen mit folgender Anweisung auf
einen anderen Server umleiten:
RewriteRule ^/~(.+) http://mitarbeiter.beispiel.de/~$1 [R,L]
Im Muster der Anweisung wird der Name des angeforderten Benutzerverzeichnisses
in Klammern gefasst und damit als eine Einheit und Gruppe definiert. In der Umleitungsadresse wird diese Gruppe durch die Variable $1 referenziert, wodurch jede eingehende Anfrage für ein Benutzerverzeichnis vom alten Server auf den neuen Server
und die neue Adresse http://mitarbeiter.beispiel.de umgeleitet wird. Ein weiteres Beispiel für die Referenzierung auf Gruppen von regulären Ausdrücken in einer RewriteRule-Anweisung ist folgendes: Wenn Sie beispielsweise die Verzeichnisse Ihrer
lokalen Benutzer im Internet veröffentlichen wollen, können Sie entweder die Konfigurationsanweisung UserDir verwenden oder folgende RewriteRule-Anweisung:
RewriteRule ^/~(.*)/(.*) /home/$1/public_html/$2
340
5 Konfiguration
Der erste in Klammern eingeschlossene Begriff verweist auf den übergebenen Benutzernamen, das zweite in Klammern angegebene Suchmuster auf die jeweilige Datei
bzw. das jeweilige Verzeichnis, welches von einem Client angefordert worden ist.
Auf diese beiden Gruppen wird durch Angabe der Variablen $1 und $2 in der
Umschreibungsadresse referenziert.
RewriteLock
Definition einer Lockdatei zur Kommunikation zwischen dem Apache und einem
Map-Programm.
Konfigurationsanweisung:
RewriteLock
Syntax:
RewriteLock Dateiname
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Um eine Verbindung zwischen einem Map-Programm (vgl. RewriteMap-Anweisung)
und dem Apache zu synchronisieren, muss mit dieser Anweisung immer eine so
genannte Lock-Datei definiert werden. Eine Lock-Datei ist jedoch nur dann erforderlich, wenn Sie Map-Dateien des Typ prg (Program) verwenden. Als einziges Argument erwartet die RewriteLock-Anweisung die Angabe eines Dateinamens für diese
Lock-Datei, die entweder in relativer Form zu dem als ServerRoot definierten Verzeichnis oder in absoluter Form angegeben werden kann. Dabei muss die Lock-Datei
auf dem lokalen Dateisystem gespeichert werden und darf nicht auf Dateisystemen
abgespeichert werden, die via NFS in das lokale System eingebunden sind. Ein Beispiel für die Definition einer Lock-Datei mit einem absoluten Dateipfad:
RewriteLock /usr/local/apache2/logs/rewrite.lock
RewriteLog
Definiert den Dateinamen zur Speicherung von Informationen des mod_rewriteModuls.
Konfigurationsanweisung:
RewriteLog
Syntax:
RewriteLog Datei
Standardwerte (Default):
nicht verfügbar
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
5.3 Fortgeschrittene Konfiguration
341
Mit dieser Option können Sie eine Datei festlegen, in die der Server durch mod_rewrite
dynamisch ausgeführte Manipulationen protokolliert. Ich habe die Konfigurationsanweisungen RewriteLog und RewriteLogLevel zwar bereits im Kapitel über die verfügbaren Logdateien erklärt, aber ich denke, dass diese beiden Anweisungen für die
erfolgreiche Verwendung von mod_rewrite unerlässlich sind und deshalb einer
erneuten Nennung bedürfen.
Die Datei kann entweder in relativer Form zum als ServerRoot definierten Verzeichnis
angegeben werden, oder in absoluter Form:
RewriteLog "logs/rewrite.log"
Die Genauigkeit der protokollierten Manipulationsaktionen regelt die Konfigurationsoption RewriteLogLevel. Wenn Sie keinerlei Informationen über die durch
mod_rewrite vorgenommenen Manipulationen wünschen, setzen Sie diese Logdatei
nicht auf das Datennirwana /dev/null, denn es gibt interne Ausgaben von mod_rewrite,
die auf jeden Fall in dieses Logfile geschrieben werden müssen. Setzen Sie stattdessen
die Konfigurationsoption RewriteLogLevel auf den Wert 0. Wenn Sie nur die Konfigurationsoption RewriteLog setzen und die Anweisung RewriteLogLevel nicht definieren, wird mod_rewrite die angegebene Logdatei nicht benutzen! Die Datei wird zwar
erstellt, aber die Dateigröße beträgt immer 0 Byte und die wichtigen Ausgaben von
mod_rewrite gehen verloren!
RewriteLogLevel
RewriteLogLevel gibt den Umfang der in der Logdatei von mod_rewrite gespeicherten
Informationen an.
Konfigurationsanweisung:
RewriteLogLevel
Syntax:
RewriteLogLevel Wert
Standardwerte (Default):
nicht verfügbar
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Den Umfang der in der Logdatei von mod_rewrite gespeicherten Informationen gibt
diese Konfigurationsoption an, wobei die Intensität der protokollierten Daten von 0
(nichts) bis 9 (alles) reicht. Benutzen Sie auf einem Live-System eine Protokollierungsintensität von 1 – 2. Außer wenn es Probleme mit den durch mod_rewrite durchzuführenden Manipulationen gibt, sollten Sie diesen Wert erhöhen. Ein Beispiel:
RewriteLogLevel 2
RewriteMap
Definition einer Umschreibungszuordnung (Map) für die spätere Verwendung in
einer RewriteRule-Anweisung.
342
5 Konfiguration
Konfigurationsanweisung:
RewriteMap
Syntax:
RewriteMap Zuordnungsname Zuordnungstyp:Dateipfad
Standardwerte (Default):
nicht verfügbar
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit der Konfigurationsanweisung RewriteMap können Sie eine Umschreibungszuordnung, eine so genannte Map, für den späteren Gebrauch in einer RewriteRule-Anweisung definieren. In einer solchen Umschreibungszuordnung werden Informationen
gespeichert, die später anhand einer Schlüsselsuche nachgeschaut und in die Umschreibungsadresse einer RewriteRule-Anweisung eingefügt werden können. Dabei stehen
Ihnen fünf verschiedene Typen von Umschreibungszuordnungen zur Verfügung:
txt
Dieser Typ definiert eine einfache Textdatei für die Umschreibungszuordnung. Diese
Textdatei enthält je Zeile einen Suchschlüssel und einen entsprechenden Wert, wobei
leere Zeilen und solche, denen ein Kommentarzeichen (#) vorangeht, übersprungen
werden. Der Suchschlüssel und der eigentliche Wert müssen in der Textdatei durch
mindestens ein Leerzeichen oder besser durch Tabulatoren getrennt werden. Ein
beliebtes Beispiel für die Verwendung einer einfachen Textdatei als Zuordnung ist
die Umschreibung von Benutzernamen auf Heimatverzeichnisse:
# Beispielkommentar in einer Textdatei, die als
# Umschreibungszuordnung von Benutzer- auf
# Heimatverzeichnisse benutzt wird.
dr.frank
/var/web/s.frank # Dr. S. Frank
indiana.jones
/var/web/indy
# Dr. Jones
ernie.mccracken /var/web/ernie
# Bowling-Gott
s.wolfgarten
/home/seb/public_html
# S.Wolfgarten
Wir speichern diese Textdatei als userdirs.txt im Verzeichnis /usr/local/apache2/conf und
bauen die Datei in eine RewriteMap-Anweisung ein:
RewriteMap benutzerverzeichnisse txt:/usr/local/apache2/conf/userdirs.txt
Eine entsprechende Umschreibungsregel mit RewriteRule könnte etwa so aussehen:
RewriteRule ^/~([^/]+)/(.*)$ ${user-dir:$1}/$2
Ein mögliches Szenario wäre der Aufbau eines kleinen Softwarearchivs, in dem man
unter einer vorher festgelegten Adresse automatisch die jeweils aktuellste Version
eines Softwarepaketes herunterladen kann. Beispielsweise könnte man den aktuellen
Linuxkernel unter der Adresse http://www.beispiel.de/download/linuxkernel zum Download bereitstellen. Dazu ließe sich folgende Textdatei benutzen, die man später durch
eine RewriteMap-Anweisung in den Apache einbindet:
5.3 Fortgeschrittene Konfiguration
343
# Der aktuelle Linuxkernel ist 2.4.23.
# Alle Befehle in eine Zeile schreiben!
linuxkernel http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.23.tar.gz
Wenn eine neue Kernelversion erscheint, müsste man den Link zu dieser Software
manuell in diese Textdatei schreiben. Dies mag bei einer kleinen Anzahl von Softwarepaketen nicht viel Aufwand sein, wenn man das Softwarearchiv jedoch einigermaßen professionell betreiben möchte, muss man ein Skript schreiben, welches von
den Internetseiten der jeweiligen Softwarepakete die aktuelle Version rausfischt und
automatisch in die Textdatei einträgt, die von RewriteRule benutzt wird. Für den
Linuxkernel könnte folgender Einzeiler den Link zur aktuellsten Version von der
Internetseite http://www.kernel.org ziehen:
perl -MLWP::Simple -e 'getprint("http://www.kernel.org")' | grep 'F</a>' | awk F"http://" '{print $2}' | head -n1 | cut -d\" -f1
Wenn Sie Lust und Zeit haben, könnten Sie eine komplette Lösung in Perl schreiben,
die automatisch die Textdatei mit den Umschreibungszuordnungen entsprechend
der neuen Kernelversion modifiziert. Der genannte Einzeiler ist wirklich ein Schnellschuss und soll nur zur Anschauung dienen.
rnd
Der Typ rnd (engl. random, willkürlich) ist mit dem vorgestellten Typ txt prinzipiell
identisch, da es sich bei beiden Typen um einfache Textdateien handelt. Im Gegensatz
zum txt-Typ entspricht beim rnd-Typ jedoch nicht unbedingt immer ein Suchschlüssel auch genau einem Wert. Es ist vielmehr möglich, einem Suchschlüssel mehrere
durch ein »|«-Zeichen getrennte Werte zuzuordnen. Bei einer solchen Zuordnung
von einem Schlüssel und mehreren Werten wird jeweils ein Wert zufällig und willkürlich (engl. random) ausgewählt. Eine Umschreibungszuordnung des Typs rnd
sieht demnach wie folgt aus (allgemein):
Suchschlüssel Wert1|Wert2|Wert3|Wert4
Als Beispiel könnten wir auf unserer Internetseite einen Bereich definieren, der beim
Zugriff eines Clients aus einer Umschreibungszuordnung eine beliebige Adresse auswählt und den Client an diese Adresse weiterleitet. Dazu definieren wir eine Datei
namens url.rnd, die wir unter /usr/local/apache2/conf abspeichern und beispielsweise
mit folgenden Werten füllen:
Hinweis
# Kommentar: Internetseiten mit seriösen Informationen
news http://www.focus.de|http://www.spiegel.de|http://www.cnn.com
sport http://www.sport1.de|http://www.bundesliga.de|http://www.formel1.de
Jeder Befehl (z.B. news oder sport) muss in eine Zeile geschrieben werden, ein
gegebenenfalls aus drucktechnischen Gründen entstandener Zeilenumbruch
muss entfernt werden.
344
5 Konfiguration
Wir sprechen diese Umschreibungszuordnung in der Konfigurationsdatei httpd.conf
des Apache wie folgt an:
RewriteMap url rnd:/usr/local/apache2/conf/url.rnd
Die entsprechende RewriteRule-Anweisung sieht folgendermaßen aus:
RewriteRule ^/info/(.*)$ ${url:$1}
Bei einem Zugriff auf die Adresse http://www.beispiel.de/info/news wird der Client auf
eine der in der Datei url.rnd für das Schlüsselwort news definierten Adressen
(www.focus.de, www.spiegel.de oder www.cnn.com) umgeleitet. Sollte ein Client beispielsweise die Adresse http://www.beispiel.de/info/sport aufrufen, wird in der Datei
url.rnd nach dem Schlüsselwort sport gesucht und der Client an eine der unter der
Rubrik Sport definierten Adressen (z.B. www.sport1.de, www.bundesliga.de oder
www.formel1.de) weitergeleitet.
dbm
Im Unterverzeichnis bin Ihrer lokalen Apache-Installation befindet sich ein Skript
namens dbmmanage, mit dem Sie so genannte DBM-Dateien erzeugen können. Diese
Dateien liegen im binären NDBM-Format vor und wenn Sie mit großen Umschreibungszuordnungen (z.B. mehrere hundert Zeilen lang) arbeiten, sollten Sie dieses
Format den normalen Textdateien vorziehen, da die Abarbeitungsgeschwindigkeit
von DBM-Dateien besser ist, als die von normalen Textdateien. Der Aufbau einer
DBM-Datei ist mit dem einer reinen Textdatei identisch, d.h. zu jedem Suchschlüssel
gehört ebenfalls genau ein Wert. Wenn Sie vorhandene Textdateien in das binäre
DBM-Format umwandeln möchten, bietet Ihnen das Handbuch des Apache folgendes Skript namens txt2dbm zur Konvertierung an:
#!/usr/bin/perl
# txt2dbm -- Konvertierung von Textdateien in das
# binäre DBM-Format
use NDBM_File;
use Fcntl;
($txtmap, $dbmmap) = @ARGV;
open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n";
tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644) or die "Couldn't create
$dbmmap!\n";
while (<TXT>) {
next if (/^\s*#/ or /^\s*$/);
$DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/);
}
untie %DB;
close(TXT);
Sorgen Sie dafür, dass das Skript txt2dbm (z.B. chmod +x txt2dbm) ausführbar ist und
Sie können bereits bestehende Umschreibungszuordnungen durch folgenden Befehl
umwandeln:
# txt2dbm beispiel.txt beispiel
5.3 Fortgeschrittene Konfiguration
345
Für unser Beispiel der individuellen Benutzerverzeichnisse könnte der Aufruf von
txt2dbm etwa so aussehen:
# txt2dbm user-dirs.txt user-dirs
Dieses Skript erzeugt zwei Dateien namens user-dirs.dir und user-dirs.pag, die wir in
der Konfigurationsdatei httpd.conf des Apache zur Umstellung auf DBM-Dateien als
Umschreibungszuordnung (Map) benutzen können:
RewriteMap benutzerverzeichnisse dbm:/usr/local/apache2/conf/userdirs.dir
Die folgende RewriteRule-Anweisung könnte die DBM-Datei nutzen:
RewriteRule ^/~([^/]+)/(.*)$ \ ${benutzerverzeichnisse:$1}/$2
int
Neben den bereits vorgestellten Typen von Umschreibungszuordnungen gibt es den
int-Typ, der vier interne Funktionen des Apache bereitstellt. Die erste bereitgestellte
Funktion lautet toupper und konvertiert den übergebenen Schlüssel in Großbuchstaben. Das Gegenstück dazu lautet tolower und wandelt den Schlüssel in Kleinbuchstaben um. Außerdem gibt es die Funktion escape, die den übergebenen Schlüssel umformatiert und die im Schlüssel vorhandenen Sonderzeichen einer Hex-Codierung
unterzieht. Die letzte bereitgestellte Funktion lautet unescape und konvertiert die Sonderzeichen aus der Hex-Codierung zurück. Unter Umständen kann es nötig sein, in
einer Adresse enthaltene Sonderzeichen wie Fragezeichen, Leerzeichen etc. einer
Hex-Codierung zu unterziehen, damit diese verarbeitet werden können. Beim
Gebrauch einer der vier internen Funktionen müssen Sie keine RewriteMap-Anweisung benutzen, da die vier Funktionen bereits als eingebaute Umschreibungszuordnungen vorhanden sind. Der Aufruf einer solchen Funktion kann deshalb direkt in
der RewriteRule-Anweisung erfolgen:
RewriteRule ^/(.*) ${escape:$1} [R]
prg
Die Quelle einer Umschreibungszuordnung kann auch ein von Ihnen entwickeltes
Programm sein. Dabei ist die Wahl der verwendeten Programmiersprache eigentlich
egal, allerdings muss das fertige Programm in der Lage sein, Daten von der Standardeingabe (stdin) zu lesen, diese zu verarbeiten und das Ergebnis an die Standardausgabe (stdout) zu schicken. Bedenken Sie bei der Entwicklung eines eigenen Programms jedoch, dass das verwendete Programm so einfach wie möglich gestrickt sein
sollte, denn sollte das externe Programm abstürzen, wird die weitere Bearbeitung der
RewriteRule an dieser Stelle stoppen.
Ich möchte an dieser Stelle eine kleine Einführung in die Entwicklung eines eigenen
Programms als Quelle einer Umschreibungszuordnung geben. Das Programm soll
Daten aus der Standardeingabe lesen, diese verarbeiten und dann an die Standardausgabe schicken. Als erstes Beispiel möchte ich dazu eine einfache datenbankbasierende Umschreibung von angeforderten Dokumenten vornehmen. Beim Zugriff eines
Clients auf ein bestimmtes Verzeichnis soll die angeforderte Datei an eine Datenbank
346
5 Konfiguration
übergeben werden. Enthält die Datenbank für diese Datei eine Umschreibungsadresse, soll der Client auf die neue Adresse umgeleitet werden. Zusätzlich soll in
diesem Fall der Zeitpunkt des Zugriffs protokolliert werden.
Ich möchte das Programm zunächst in Perl implementieren, da diese Programmiersprache weit verbreitet ist und deren Syntax recht leicht zu verstehen ist. Gemäß der
oben gemachten Anforderung sieht mein Perl-Programm so aus:
#!/usr/bin/perl -w
#
#
#
#
#
#
#
db_lookup.pl - Liest Daten aus der Standardeingabe
und vergleicht diese mit den Daten einer MySQL
Datenbank. Sollten Uebereinstimmungen gefunden werden,
wird das aktuelle Daten (mit Uhrzeit) in die Datenbank
geschrieben.
# DBI = eine Schnittstelle (database independent interface)
# zwischen Perl und diversen Datenbanktypen
use DBI;
# Verwenden Sie in externen Programmen niemals
# gepuffertes I/O, sondern stattdessen NUR
# ungepuffertes I/O! In Perl koennen Sie durch
# folgende Anweisung ungepufferte I/O verwenden:
$| = 1;
# Mit welchem Benutzername und welchem
# Passwort soll sich das Skript mit der
# Datenbank verbinden?
$db_benutzer = "sebastian";
$db_passwort = "geheim123";
# Aufbau der Verbindung zur MySQL-Datenbank
$datenbankhandler = DBI-> connect('DBI:mysql:zuordnungen',$db_benutzer,
$db_passwort,{ RaiseError => 1, AutoCommit => 1});
# Waehrend Daten ueber
# die Standardeingabe reinkommen
while (<STDIN>) {
#
#
#
#
Aktivieren Sie diese drei Zeilen, wenn Sie
Probleme mit Ihrem selbstentwickelten Programm
haben und Sie wissen moechten, welche Daten
wirklich ueber Standardeingabe kommen!
#open(logdatei,">stdin.log");
#print logdatei $_;
#close(logdatei);
5.3 Fortgeschrittene Konfiguration
# Vergleich der reingekommenen Daten mit denen
# in der MySQL-Datenbank
$sql_select = $datenbankhandler->prepare("SELECT * from umschreibungen where
datei='$_'");
# Ausfuehrung der SQL Anfrage
$sql_select->execute;
# Wenn kein passendes Ergebnis gefunden werden
# konnte, gib einfach "NULL" aus
if (!($sql_select->rows)) {
print "NULL\n";
} else {
#
#
#
#
#
#
Wenn es ein Ergebnis gibt, gib die dritte
Spalte des Ergebnisses (die
Zielumschreibungsdatei) aus. Es ist die dritte
Spalte, da jedoch die Zaehlung bei 0 anfaengt,
muessen Sie die dritte Spalte mit der Ziffer 2
referenzieren ($ergebnis[2])
while (@ergebnis = $sql_select->fetchrow_array) {
print "$ergebnis[2]\n";
$datum = localtime(time);
# Aktuellen Zeitpunkt in eine extra Tabelle
# protokollieren, damit spaeter
# festgehalten werden kann, welche Dateien
# wann nachgefragt worden sind und auf
# welche Dateien diese umgeschrieben worden
# sind.
$zeit_sql = $datenbankhandler-> prepare("INSERT INTO logdatei
(uhrzeit,umschreibungsdatei) values ('$datum','$ergebnis[1]')");
$zeit_sql->execute;
}
}
}
Listing 5.2 Beispielprogramm (in Perl) für dynamische URL-Umschreibungen
mit mod_rewrite unter Verwendung einer MySQL-Datenbank
347
348
5 Konfiguration
Zunächst bindet das Perlskript die DBI (DataBase Independent Interface) ein, eine Art
standardisierte Schnittstelle zwischen Perl und verschiedenen Datenbanksystemen
(z.B. MySQL). Sollten Sie diese Erweiterung nicht installiert haben, müssen Sie sich
von der Internetseite http://www.cpan.org die aktuelle Version herunterladen und
installieren. In vielen Distributionen (z.B. SuSE, RedHat, Debian) ist die DBI bereits
enthalten. Schauen Sie eventuell auf den Installationsmedien Ihres jeweiligen
Betriebssystems nach dieser freien Schnittstelle.
Danach wird ein Benutzername und ein Passwort für den Zugriff auf die MySQLDatenbank definiert, den Sie entsprechend Ihrer Gegebenheiten ändern müssen. Sollten Sie noch keine Benutzerstruktur für MySQL definiert haben, können Sie die Verbindung zur Datenbank mit der Kennung des Benutzers root aufnehmen, das Passwort lautet »« (leere Zeichenkette, d.h. kein Passwort vergeben!). Der Benutzername
root hat hier übrigens nichts mit dem Systembenutzer root eines Unix/Linux-Systems
gemeinsam, die Namen sind leider nur identisch! Genauer gesagt existiert in der
Benutzertabelle ein Eintrag für einen Benutzer namens root, für den kein Passwort
definiert worden ist.
Die nächste Anweisung nimmt unter Verwendung des von Ihnen definierten Benutzernamens und Passworts die Verbindung zu MySQL auf und verbindet sich dort mit
der Datenbank zuordnungen. Die Struktur für die Datenbank zuordnungen habe ich in
eine kleine Datei namens zuordnungen.sql geschrieben:
DROP DATABASE IF EXISTS zuordnungen;
CREATE DATABASE zuordnungen;
USE zuordnungen;
DROP TABLE IF EXISTS umschreibungen;
CREATE TABLE umschreibungen (
id integer not null primary key auto_increment,
datei varchar(255) not null,
umschreibungsdatei varchar(255) not null
);
DROP TABLE IF EXISTS logdatei;
CREATE TABLE logdatei (
id integer not null primary key auto_increment,
uhrzeit varchar(255),
umschreibungsdatei varchar(255)
);
Listing 5.3 Beispielhafte SQL-Datenstruktur für dynamische URL-Umschreibungen
5.3 Fortgeschrittene Konfiguration
349
Sie können diese SQL-Struktur durch den folgenden Befehl an MySQL übergeben,
sofern Sie die vorgestellte Struktur in einer Datei namens zuordnungen.sql gespeichert
haben:
# mysql < zuordnungen.sql
Sobald die Verbindung zur Datenbank aufgebaut ist, liest das Skript Daten aus der
Standardeingabe und vergleicht die eingegangenen Daten mit den Inhalten einer
MySQL-Tabelle. Wenn kein übereinstimmender Eintrag zwischen den Daten der
Standardeingabe und den Inhalten der MySQL-Datenbank gefunden werden konnte,
gibt das kleine Programm die Zeichenkette NULL zurück, gefolgt von einem
abschließenden Zeilenumbruch, der durch den Ausdruck \n symbolisiert wird. Sollte
dagegen eine Übereinstimmung zwischen den Daten aus der Standardeingabe und
den Daten der MySQL-Datenbank bestehen, wird die Zieldatei auf die der Client
umgeleitet werden soll, ausgegeben und mit einem abschließenden Zeilenumbruch
versehen. Zusätzlich wird in einer zweiten Tabelle namens logdatei das aktuelle
Datum sowie die aktuelle Uhrzeit gespeichert, so dass es später möglich ist, eine
Übersicht über den Zeitpunkt der Zugriffe auf den Server zu erhalten.
Fügen Sie eine Umschreibungsregel in die MySQL-Datenbank ein und testen Sie
damit das Skript. Starten Sie dazu MySQL durch die Eingabe von
# mysql
Sie befinden sich nun im so genannten MySQL-Monitor. Sie haben dort u.a. die Möglichkeit, Daten direkt in Ihre Datenbank einzugeben oder aus der Datenbank zu lesen.
Sollten Sie Probleme haben, sich mit Ihrer MySQL-Datenbank zu verbinden, überprüfen Sie, ob die MySQL-Datenbank läuft und verfügbar ist. Wenn Sie bereits ein eigenes Rechtesystem implementiert haben, kann die Angabe eines Benutzernamens und
eines Passworts für die Verbindung zur MySQL-Datenbank notwendig sein. In diesem Fall verbinden Sie sich mit folgendem Befehl mit Ihrer MySQL-Datenbank, wenn
Ihr Benutzername Hans und Ihr Passwort Wurst lautet:
# mysql -U Hans -pWurst
Zunächst müssen Sie jedoch MySQL sagen, mit welcher Datenbank Sie jetzt arbeiten
möchten. Um mit der soeben erstellten Datenbank zuordnungen zu arbeiten, geben Sie
bitte folgenden Befehl ein:
mysql> use zuordnungen;
Sie können auf Datenbankebene eine Datei definieren, die beim Zugriff eines Clients
automatisch auf eine von Ihnen zu definierende Datei umgeschrieben wird. Wenn Sie
beispielsweise die Datei kontakt.html auf die Datei impressum.html umschreiben möchten, geben Sie folgenden Befehl ein:
mysql> INSERT INTO umschreibungen (datei,umschreibungsdatei) VALUES ('kontakt.
html','impressum.html');
350
5 Konfiguration
Nachdem Sie diesen Befehl an den Server gesendet haben, können Sie überprüfen, ob
der von Ihnen vorgenommene Eintrag korrekt in der Datenbank vorhanden ist:
mysql> SELECT * FROM umschreibungen;
Sie erhalten eine Liste aller Einträge der Tabelle umschreibungen und sollten in dieser
Liste auch den von Ihnen vorgenommenen Eintrag finden:
+----+--------------+--------------------+
| id | datei
| umschreibungsdatei |
+----+--------------+--------------------+
| 1 | kontakt.html | impressum.html
|
+----+--------------+--------------------+
1 row in set (0.00 sec)
Verlassen Sie das MySQL-System und begeben Sie sich zurück auf die Konsole:
mysql> quit;
Sie haben nun die Möglichkeit, das Perlskript zu überprüfen und die korrekte Eintragung der Datei kontakt.html in der MySQL-Datenbank zu verifizieren. Wenn Sie dem
Perlskript den Wert kontakt.html übergeben, sollte dieses Skript die entsprechende
Umschreibungsdatei impressum.html zurückliefern. Wenn keine entsprechende
Umschreibungsdatei gefunden werden konnte, sollte das Skript den Wert NULL
zurückgeben. Testen Sie das Perlskript:
# echo "kontakt.html" | /usr/local/apache2/bin/db_lookup.pl
Den Pfad und den Namen der Datei db_lookup.pl müssen Sie gegebenenfalls entsprechend der von Ihnen gewählten Einstellung anpassen. Dieser Befehl sollte den Wert
der Umschreibungsdatei zurückliefern, in dem von mir vorgestellten Beispiel wäre
dies die Datei impressum.html. Wenn Sie das Skript mit einer Datei testen, für die es
keine Umschreibungsregel in der MySQL-Datenbank gibt, wird es die Zeichenkette
NULL zurückgeben:
# echo "blafasel.html" | /usr/local/apache2/bin/db_lookup.pl
Sollte das Skript gemäß Ihren Erwartungen funktionieren, können Sie die entsprechende RewriteMap-Anweisung in der zentralen Konfigurationsdatei httpd.conf des
Apache vornehmen:
RewriteEngine On
RewriteMap db_umschreibungen prg:/usr/local/apache2/bin/db_lookup.pl
Wenn Sie bereits vorher Umschreibungen mit mod_rewrite vorgenommen haben,
können Sie die Anweisung RewriteEngine On weglassen, da diese nur einmal im
jeweiligen Konfigurationsabschnitt des Apache auftauchen muss. Fügen Sie auch die
entsprechende RewriteRule-Anweisung hinzu:
RewriteRule ^/info/(.*) /${db_umschreibungen:$1}
5.3 Fortgeschrittene Konfiguration
351
Speichern Sie die Änderungen an der Konfigurationsdatei des Apache und starten Sie
den Server neu. Greift ein Client auf eine Datei des real nicht existierenden Verzeichnisses info (z.B. http://www.beispiel.de/info/kontakt.html) zu, wird das von Ihnen
geschriebene externe Programm mit dem Namen der angeforderten Datei (z.B.
kontakt.html) gefüttert. Sollte ein Eintrag für eine Umschreibung in der MySQL-Datenbank für diese Datei existieren, wird der Client auf die in der Datenbank spezifizierte
Datei umgeleitet. Existiert kein Eintrag für diese Datei, erhält der Client eine Fehlermeldung, da es das lokale Verzeichnis info in Ihrem DocumentRoot wahrscheinlich
nicht gibt.
Selbstverständlich kann man das vorgestellte Programm auch in einer anderen Programmiersprache wie ANSI-C realisieren. Die entsprechende Variante könnte beispielsweise so aussehen:
/**
Beispiel fuer die vorgestellte Umschreibungsloesung
mit Hilfe eines externen Programms. Implementierung
in ANSI-C, Kompilierung (eine Zeile):
gcc db_lookup.c -o db_lookup -I/usr/include/mysql -lmysqlclient
**/
/**
Wir benötigen eine Reihe von Funktionen und Befehlen, die jedoch in externen
Bibliotheken definiert sind. Deshalb binden wir zunächst diese Bibliotheken in unser
Programm ein. Diese Bibliotheken sollten eigentlich auf jedem System vorhanden sein,
die Includedateien von MySQL (u.a. mysql.h) muessen Sie wahrscheinlich separat
installieren.
**/
#include <stdlib.h>
#include <stdio.h>
#include <mysql.h>
/**
Hier definieren wir den Datenbankserver (host), die eigentliche Datenbank (db), den
Benutzer (user), das Passwort (passwd) und die Tabelle (table), auf die wir
zugreifen wollen. Dieser Define sorgt dafuer, dass wir nicht immer wieder die
Logindaten eingeben muessen, sondern auf diese vordefinierten "Konstanten"
zurueckgreifen koennen. Die Werte fuer den Benutzernamen und das Passwort muessen Sie
gegebenenfalls noch an die von Ihnen gewaehlten Werte anpassen. Sofern Sie noch kein
feinstrukturiertes Rechtesystem benutzen, koennen Sie als Benutzername auch root
(kein Kennwort) waehlen.
**/
#define host "localhost"
#define db "zuordnungen"
#define user "sebastian"
352
5 Konfiguration
#define passwd "geheim123"
#define table "umschreibungen"
/**
Die MySQL API benutzt eigene Datenstrukturen, definiert in der mysql.h, um eine
Verbindung mit der Datenbank aufzunehmen. "mysql" ist das eigentliche MySQL-Objekt,
"*ergebnis" ist ein Zeiger auf das Ergebnis(-set) und "row" die eigentliche
Ergebniszeile.
**/
MYSQL mysql;
MYSQL_RES *ergebnis;
MYSQL_ROW row;
int main() {
/** Variablendeklarationen
sql_query = SQL-Befehl, den wir an den Server senden
ergebnisfelder = Anzahl Spalten im Ergebnisset
anzahl_ergebnisse = Anzahl an Ergebnissen unserer SQL-Abfrage
eingabe_stdin = Enthaelt spaeter den Wert, den das Programm aus der Standardeingabe
erhalten hat
**/
char sql_query[256];
char eingabe_stdin[512];
unsigned int ergebnisfelder;
int anzahl_ergebnisse;
/**
Zunaechst lesen wir die Werte, die an das Programm ueber die Standardeingabe
uebergeben worden sind und speichern diese in der Variable eingabe_stdin.
**/
fgets(eingabe_stdin, 512, stdin);
/**
Versuche eine Verbindung zur Datenbank herzustellen und wenn keine Verbindung
zustande kommt, beende das Programm mit einer Fehlermeldung.
**/
if (!mysql_connect(&mysql,host,user,passwd)) {
exit(-1);
}
/**
Waehle die von uns genutzte Datenbank aus. Sollte dies fehlschlagen, beende das
Programm mit einer Fehlermeldung.
**/
5.3 Fortgeschrittene Konfiguration
353
if (mysql_select_db(&mysql,db)) {
mysql_close(&mysql);
exit(-1);
}
/**
Die SQL-Abfrage wird zusammengebaut und mit dem Wert der Variable eingabe_stdin
gefuellt.
**/
sprintf(sql_query,"select * from umschreibungen where datei = '%s'",eingabe_stdin);
/**
Senden der SQL-Abfrage und Abfangen der Ergebnisse.
**/
mysql_query(&mysql,sql_query);
ergebnis = mysql_use_result(&mysql);
/**
Eine Zaehlvariable benutzen wir spaeter, wenn keine Ergebnisse gefunden werden
konnten.
**/
anzahl_ergebnisse = 0;
ergebnisfelder = mysql_num_fields(ergebnis);
/**
Eine Schleife durchlaeuft die Ergebnisse der SQL-Abfrage und gibt das dritte Feld
(vollstaendiger Dateiname der Umschreibungsdatei) aus. Der Zaehler von MySQL geht
(ebenso wie bei Perl) mit Null los und deshalb muss das dritte Feld mit row[2]
referenziert werden. Unser interner Zaehler wird bei einem gefundenen Ergebnis direkt
um eine Ganzzahl erhoeht.
**/
while((row = mysql_fetch_row(ergebnis))) {
printf("%s\n",row[2]);
anzahl_ergebnisse++;
}
/**
Wenn keinerlei Ergebnisse gefunden werden konnten, steht unser interner Zaehler immer
noch auf Null. Deshalb geben wir in einem solchen Fall einfach den Wert Null, gefolgt
von einem Zeilenumbruch (\n), aus.
**/
if (anzahl_ergebnisse == 0) {
printf("NULL\n");
}
/**
354
5 Konfiguration
Schliessen der Verbindung zur MySQL-Datenbank.
**/
mysql_close(&mysql);
}
Listing 5.4 Beispielprogramm (in C) für dynamische URL-Umschreibungen mit mod_rewrite
unter Verwendung einer MySQL-Datenbank
Das Programm bindet zunächst drei zur Ausführung des Programms benötigte
Bibliotheken durch einen include-Befehl ein. Diese Bibliotheken gehören eigentlich
zur Standardausstattung jedes Unix/Linux-Systems und sollten vorhanden sein. Die
Header-Dateien von MySQL (wie mysql.h) müssen Sie eventuell nachinstallieren, konsultieren Sie dazu bitte das Handbuch Ihrer jeweiligen Distribution. Danach wird ein
Benutzername und ein Passwort für den Zugriff auf die MySQL-Datenbank definiert,
den Sie entsprechend Ihrer Gegebenheiten ändern müssen. Sollten Sie noch keine
Benutzerstruktur für MySQL definiert haben, können Sie die Verbindung zur Datenbank mit der Kennung des Benutzers root aufnehmen, das Passwort lautet »« (leere
Zeichenkette, d.h., es ist kein Passwort vergeben!). Der Benutzername root hat hier
übrigens nichts mit dem Systembenutzer root eines Unix/Linux-Systems gemeinsam,
die Namen sind leider nur identisch. Genauer gesagt existiert in der Benutzertabelle
ein Eintrag für einen Benutzer namens root, für den kein Passwort definiert worden
ist.
Im nächsten Schritt werden drei Datenstrukturen definiert, die im Namen durch die
MySQL-Headerdatei mysql.h vorbestimmt sind. Dabei handelt es sich um eigene
Datenstrukturen, die durch die MySQL-API bereitgestellt werden, um eine Verbindung mit der Datenbank aufzunehmen. Dabei ist mysql das eigentliche MySQLObjekt, *ergebnis ist ein Zeiger auf das Ergebnis(-set) und row die eigentliche Ergebniszeile. Im Hauptteil werden einige Variablen definiert, die im Verlauf des Programms
benötigt werden, deren Bedeutung und Funktion Sie den Kommentaren des Quelltextes entnehmen können. Das Programm liest dann zunächst den Wert der Standardeingabe (Fachbegriff: stdin) ein und speichert den Inhalt in einer eigenen Variablen.
Infolgedessen wird eine Verbindung zu MySQL aufgebaut, die korrekte Datenbank
ausgewählt und mit dem Inhalt der Standardeingabe eine Abfrage an die Datenbank
gesendet. Dabei verwendet das Programm dieselben SQL-Strukturen, die ich Ihnen
bereits bei den Erläuterungen zu der in Perl geschriebenen Variante des Umschreibungsprogramms vorgestellt habe. Wenn ein Ergebnis für die gesendete Abfrage
gefunden werden konnte, wird dieses Ergebnis ausgegeben und der interne Zähler
um eine Ganzzahl erhöht. Danach sollte die erfolgreiche Umschreibung in eine
andere Tabelle protokolliert werden, damit später der Zeitpunkt und die Häufigkeit
der Umschreibungen ausgewertet werden können. In diesem Beispiel habe ich im
Gegensatz zu der in Perl entwickelten Variante jedoch die Protokollierung in eine
andere Tabelle aus Zeitgründen weggelassen. Befindet sich der Zähler dagegen auf
dem Wert 0, d.h., es wurde kein passender Wert in der Datenbank gefunden, gibt das
Programm die Zeichenkette NULL, gefolgt von einem Zeilenumbruch (\n), aus.
Zuletzt wird die Verbindung zur MySQL-Datenbank getrennt.
5.3 Fortgeschrittene Konfiguration
355
Im Gegensatz zu dem vorgestellten Perlprogramm, müssen Sie das in C geschriebene
Programm kompilieren. Wenn Sie die Quelldatei db_lookup.c genannt und im Verzeichnis /usr/local/apache2/bin gespeichert haben, können Sie dies mit folgendem
Befehl erledigen:
# gcc /usr/local/apache2/bin/db_lookup.c \
-o /usr/local/apache2/bin/db_lookup -I/usr/include/mysql -lmysqlclient
Unter Umständen müssen Sie die Datei bzw. Verzeichnispfade für die Includedateien
(hier: /usr/include/mysql) und die MySQL-Bibliothek (libmysqlclient) gemäß den von
Ihnen gewählten Installationsverzeichnissen anpassen. Wenn Sie sich nicht sicher
sind, wo die Includedateien installiert worden sind, können Sie die Datei mysql.h, die
Teil dieser Includedateien ist, suchen:
# find / -name mysql.h -print
Sollte diese Suche wider Erwarten kein Ergebnis liefern, müssen Sie die Includedateien
mit der Softwareverhaltung Ihrer Distribution (z.B. Yast bei SuSE) nachinstallieren.
Die MySQL-Clientbibliothek, die Ihnen überhaupt den Zugriff auf die MySQL-Datenbank ermöglicht, sollte ebenfalls installiert und in einem dem System bekannten
Suchpfad für Bibliotheken gespeichert sein. Diese bekannten Suchpfade werden in der
Datei /etc/ld.so.conf (Linux) definiert. Sollte eine Datei namens libmysqlclient.so auf
Ihrem System nicht vorhanden sein, müssen Sie auch die MySQL-Clientbibliotheken
mit der Softwareverwaltung Ihrer Distribution nachinstallieren. Unter Umständen ist
diese Datei auf Ihrem System auch vorhanden, sie befindet sich nur nicht im korrekten
Verzeichnis:
# find / -name libmysqlclient.so -print
Suchen Sie die Datei und kopieren Sie diese gegebenenfalls in einen dem System
bekannten Suchpfad wie /lib. Danach muss die Kompilierung ohne Fehlermeldung
erfolgreich durchlaufen, die kompilierte Datei befindet sich mit dem Namen
db_lookup im Verzeichnis /usr/local/apache2!
Sie haben ja bereits in den Erläuterungen zu der in Perl geschriebenen Variante des
Programms erfahren, wie Sie Werte in die MySQL-Datenbank einfügen und wieder
auslesen. Sie haben nun die Möglichkeit, das Programm zu überprüfen und die korrekte Eintragung der Datei kontakt.html, die Sie bereits während der Entwicklung des
Perlprogramms in die Datenbank eingefügt haben, in der MySQL-Datenbank zu verifizieren. Wenn Sie dem Programm den Wert kontakt.html übergeben, sollte dieses die
entsprechende Umschreibungsdatei impressum.html zurückliefern. Wenn keine entsprechende Umschreibungsdatei gefunden werden konnte, sollte das Programm den
Wert NULL zurückgeben. Testen Sie das in C entwickelte Programm so, wie Sie es
bereits mit dem Perlskript getan haben:
# echo "kontakt.html" | /usr/local/apache2/bin/db_lookup
Den Pfad und den Namen der Datei db_lookup müssen Sie gegebenenfalls entsprechend den von Ihnen gewählten Einstellungen anpassen. Dieser Befehl sollte den
356
5 Konfiguration
Wert der Umschreibungsdatei zurückliefern, in dem von mir vorgestellten Beispiel
wäre dies die Datei impressum.html. Wenn Sie das Programm mit einer Datei testen,
für die es keine Umschreibungsregel in der MySQL-Datenbank gibt, wird es die Zeichenkette NULL zurückliefern:
# echo "blafasel.html" | /usr/local/apache2/bin/db_lookup
Sollte das Programm gemäß Ihren Erwartungen funktionieren, können Sie die entsprechende RewriteMap-Anweisung in der zentralen Konfigurationsdatei httpd.conf
des Apache vornehmen:
RewriteEngine On
RewriteMap db_umschreibungen prg:/usr/local/apache2/bin/db_lookup
Wenn Sie bereits vorher Umschreibungen mit mod_rewrite vorgenommen haben,
können Sie die Anweisung RewriteEngine On weglassen, da diese nur einmal im
jeweiligen Konfigurationsabschnitt des Apache auftauchen muss. Fügen Sie auch die
entsprechende RewriteRule-Anweisung hinzu:
RewriteRule ^/info/(.*) /${db_umschreibungen:$1}
Speichern Sie die Änderungen an der Konfigurationsdatei des Apache und starten Sie
den Server neu. Greift ein Client auf eine Datei des real nicht existierenden Verzeichnisses info (z.B. http://www.beispiel.de/info/kontakt.html) zu, wird das von Ihnen
geschriebene externe Programm mit dem Namen der angeforderten Datei (z.B.
kontakt.html) gefüttert. Sollte ein Eintrag für eine Umschreibung in der MySQL-Datenbank für diese Datei existieren, wird der Client auf die in der Datenbank spezifizierte
Datei umgeleitet. Existiert kein Eintrag für diese Datei, erhält der Client eine Fehlermeldung, da es das lokale Verzeichnis info in Ihrem DocumentRoot wahrscheinlich
nicht gibt.
Dies waren zwei wirklich einfach gestrickte Programme, die Ihnen zeigen sollen, wie
man externe Programme in Zusammenarbeit mit mod_rewrite verwendet. Bedenken
Sie dabei immer:
Keep it simple
Die externen Programme sollten aus Geschwindigkeitsgründen relativ klein und einfach gestrickt sein. Wenn das externe Programm abstürzt, wird es durch den Apache
automatisch neu gestartet. Sollte es einen ernsthaften Programmierfehler geben,
könnten Sie damit die Funktion und die Performance des Apache erheblich beeinträchtigen, da der Server durch Ihr Programm womöglich in eine Programmschleife
gerät, aus der der Apache nicht mehr herauskommt und in letzter (und schlimmster)
Konsequenz abstürzt. Die von mir hier exemplarisch vorgestellten Programme sind
wirklich nur Beispiele und sollten nur nach sehr genauer Prüfung in einem Produktivsystem eingesetzt werden, wenn überhaupt. Es handelt sich dabei um eine Vorführung und ein veranschaulichendes Beispiel und glänzt aus Zeitgründen leider nicht
mit schönem und gutem Programmierstil!
5.3 Fortgeschrittene Konfiguration
357
RewriteOptions
RewriteOptions setzt Optionen für den Umschreibungsalgorithmus.
Konfigurationsanweisung:
RewriteOptions
Syntax:
RewriteOptions Optionen
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost-Kontext,
.htaccess-Kontext, <Directory>-Container,
<Location>-Container, <Files>-Container
Anweisung aktiv:
nein
Ursprünglich wurde diese Konfigurationsanweisung als Allzweckanweisung entwickelt, die Sondereinstellungen für das Verhalten von mod_rewrite definieren sollte.
Gegenwärtig gibt es jedoch nur zwei Optionen für den Umschreibungsalgorithmus
(Rewriting Engine) von mod_rewrite namens inherit und MaxRedirects. Die erste
Option kann mit folgender Konfigurationsanweisung gesetzt werden:
RewriteOptions inherit
Wird diese Option in einem <VirtualHost>-Abschnitt definiert, so werden die Einstellungen für die Konfigurationsanweisungen RewriteRule, RewriteMap und RewriteCond
des übergeordneten Hauptservers, d.h. der globalen Serverkonfiguration, übernommen. In einem Verzeichnisabschnitt werden die jeweiligen Einstellungen der
.htaccess-Datei des übergeordneten Verzeichnisses übernommen.
Die zweite Option MaxRedirects ist erst ab dem Apache 2.0.45 verfügbar und definiert
die maximale Anzahl an internen Umleitungen (redirects), die mod_rewrite ausführt.
Ein Beispiel:
RewriteOptions MaxRedirects=10
Mit dieser Anweisung, die gleichzeitig die Standardkonfiguration von MaxRedirects
darstellt, führt mod_rewrite maximal zehn interne Umleitungen aus, bevor die weitere Verarbeitung der Umschreibungsregeln abgebrochen und an den Client eine entsprechende Fehlermeldung (Internal server error, interner Server-Fehler) gesendet
wird. Die Anweisung soll damit Endlosschleifen, die durch falsche oder fehlerhafte
Umschreibungsregeln hervorgerufen worden sind, verhindern.
Hinweis
358
5 Konfiguration
Generell sollten Sie beim Setzen dieser Konfigurationsoption das Vorhandensein von übergeordneten Konfigurationsoptionen genauestens prüfen,
denn unter Umständen existieren in übergeordneten Verzeichnissen Umschreibungsregeln, die so in den untergeordneten Verzeichnissen keinen Sinn ergeben, da dort beispielsweise eine völlig andere Verzeichnis- und Dateistruktur
vorhanden ist. Ich rate Ihnen daher, die Konfigurationsoption nicht zu setzen
und lieber für jeden <Directory>- und <VirtualHost>-Abschnitt eigene
Umschreibungsregeln zu definieren, falls überhaupt nötig.
RewriteRule
Bei RewriteRule handelt es sich um die Definition einer Umschreibungsregel.
Konfigurationsanweisung:
RewriteRule
Syntax:
RewriteRule Muster Umschreibungsadresse
[Merkmale]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_rewrite
Kontext:
Server-Kontext, VirtualHost-Kontext,
.htaccess-Kontext, <Directory>-Container,
<Location>-Container, <Files>-Container
Anweisung aktiv:
nein
Die wohl wichtigste Konfigurationsanweisung von mod_rewrite lautet RewriteRule
und definiert eine Umschreibungsregel. Dabei erwartet die Konfigurationsanweisung
mindestens zwei Parameter, zum einen das Suchmuster und zum anderen die zugehörige Umschreibungsadresse. Bei dem Muster handelt es sich um einen regulären
Ausdruck (POSIX regular expression) eines URL-Pfads, der beim Zugriff eines Clients
mit dem tatsächlich angeforderten URL-Pfad verglichen wird und im Falle eines
zutreffenden Musters mit dem zweiten Parameter von RewriteRule, der Umschreibungsadresse ersetzt wird. Dabei kann es sich bei der Umschreibungsadresse um eine
absolute (interne und externe) Adresse, einen URL-Pfad oder um einen Dateiund/oder Verzeichnispfad handeln. Sie können beliebig viele RewriteRule-Anweisungen vornehmen, die jeweils genau eine Umschreibungsregel definieren, wobei
RewriteRule-Anweisungen oft mit Hilfe der Konfigurationsanweisung RewriteCond an
Bedingungen geknüpft werden.
Gerade für Benutzer, die mit der Verwendung von regulären Ausdrücken nicht so
vertraut sind, mögen RewriteRule-Anweisungen kompliziert und unverständlich aussehen. Ich möchte Ihnen aus diesem Grunde eine kurze Übersicht über das mögliche
Aussehen und das daraus resultierende Ergebnis einiger regulärer Ausdrücke vorstellen:
.
Der Punkt symbolisiert innerhalb eines regulären Ausdrucks nicht das Ende eines
Satzes, sondern ein beliebiges Schriftzeichen (z.B. Buchstaben, Zahlen, Sonderzei-
5.3 Fortgeschrittene Konfiguration
359
chen). Wenn Sie in einem Suchmuster einen Punkt finden möchten, müssen Sie diesen
durch einen vorangestellten Backslash (»\«) explizit kennzeichnen. In der Fachsprache spricht man davon, dass man den Punkt escapen muss.
[abc]
Entspricht einem der drei Buchstaben a, b oder c. In der Praxis begegnet man oft Konstrukten wie [a-zA-Z], die für einen beliebigen Buchstaben von A – Z stehen, wobei
die Groß- und Kleinschreibung durch die zweifache Definition (a-zA-Z) egal ist, d.h.,
der Buchstabe T wird beispielsweise ebenso durch dieses Muster abgedeckt, wie dessen kleingeschriebene Variante (»t«). Im Prinzip könnte man für ein derartiges Muster auch das Muster (a|b|c) benutzen, wobei diese Schreibweise eigentlich kaum Verwendung findet.
[^abc]
Das vorangestellte ^-Zeichen sorgt dafür, dass ein Zeichen außer a, b oder c mit diesem Muster übereinstimmt. Wenn Sie beispielsweise keine Zahlen in einem Muster
finden möchten, könnten Sie etwa folgenden regulären Ausdruck verwerden: [^0-9]
(alternative Schreibweise: [^0123456789].
Text1|Text2
Dieses Muster stimmt entweder mit Text1 oder Text2 überein. Das logische Oder wird
also in einem regulären Ausdruck durch einen senkrechten Strich, die unter
Unix/Linux so genannte Pipe, symbolisiert.
?
Entspricht einer Übereinstimmung mit nur einem oder auch keinem Zeichen eines
vorangestellten regulären Ausdrucks.
*
Dieses Zeichen entspricht einer beliebigen Anzahl (auch Null) von Zeichen eines vorangestellten Suchmusters.
+
Entspricht einem (oder mehreren) Zeichen eines vorangehenden Suchmusters.
{x,y}
Mit der Angabe {x,y} können Sie eine Häufigkeit von x bis y angeben, mit der das vorangehende Suchmuster vorkommen darf. Sie können auch eine feste Anzahl an Suchelementen in einem Muster abdecken durch Angabe von {x}, wobei x eine beliebige
Ganzzahl ist. Wenn Sie beispielsweise einen beliebigen Text mit Groß- und Kleinbuchstaben abdecken möchten, der eine Länge von zwei bis vier Buchstaben hat, können Sie folgendes Suchmuster verwenden: [a-zA-Z]{2,4}
(text)
Beschreibt den regulären Ausdruck text, wobei sich durch die runden Klammern
Ausdrücke gruppieren lassen. Dadurch können in RewriteRule-Anweisungen Bezugnahmen auf einzelne Klammern in Form von Variablen wie $1 für die erste Klammer
($2 für die zweite etc.) vorgenommen werden.
360
5 Konfiguration
^a
Dieses Muster sorgt nur für eine Übereinstimmung, wenn der zu überprüfende String
mit dem kleingeschriebenen Buchstaben a beginnt, wobei für a auch jeder andere
Buchstabe, jede andere Zahl oder auch Zeichenkette stehen kann (von beliebiger
Menge).
a$
Dieses Muster sorgt nur für eine Übereinstimmung, wenn der zu überprüfende String
mit dem kleingeschriebenen Buchstaben a endet, wobei für a auch jeder andere Buchstabe, jede andere Zahl oder auch Zeichenkette stehen kann (von beliebiger Anzahl).
!
Das Ausrufezeichen kann ein Suchmuster negieren, d.h., Sie können damit alle
Schriftzeichen finden, die nicht einem bestimmten Muster entsprechen. Wenn Sie beispielsweise nicht möchten, dass ein Text mit einem bestimmten Wort (Suchbegriff)
beginnt, können Sie etwa folgenden regulären Ausdruck verwenden: !^Suchbegriff
Bitte beachten Sie, dass Sie bei der Negation von regulären Ausdrücken keine Gruppierungen in Klammern bilden können, da eine solche Gruppe keinen Inhalt hat,
wenn die Negation nicht zutrifft. Sie können deshalb in der Umschreibungsadresse
die Klammern nicht wie sonst üblich durch eine Variable (z.B. $1 für die erste Klammer) referenzieren.
\
Bestimmte Schriftzeichen, die in der Fachsprache Metazeichen genannt werden, müssen mit einem Backslash (»\«) versehen werden, wenn das nachfolgende (Sonder-)
Zeichen nicht in seiner speziellen Bedeutung als Sonderzeichen, sondern als normales
Schriftzeichen verwendet werden soll. Wenn Sie beispielsweise in einer Zeichenkette
einen Punkt finden wollen, so müssen Sie diesen mit einem vorangestellten Backslash
kennzeichnen, da es sich bei dem Punkt um ein solches Metazeichen handelt, welches
normalerweise für irgendein (beliebiges!) Schriftzeichen (z.B. A, r, 3, ö, ß etc.) steht
und nicht für das oft am Ende eines Satzes verwendete Schriftzeichen.
Weitere Informationen zur Verwendung von regulären Ausdrücken finden Sie im
Anhang dieses Buches sowie im Literaturverzeichnis. Unter Unix/Linux erhalten Sie
zusätzlich eine englischsprachige Anleitung durch Eingabe von:
# man regex
# info regex
Nachdem Sie einen kleinen Ein- und Überblick in den grundlegenden Aufbau und
die Verwendung von regulären Ausdrücken bekommen haben, möchte ich Ihnen
jetzt einige Beispiele für sehr einfache RewriteRule-Anweisungen vorstellen:
RewriteRule ^/nachrichten(.*)$ /news$1 [R]
RewriteRule ^/impressum\.html$ http://www.beispiel.com/kontakt.html [R]
RewriteRule ^/~(.*)/(.*)$ /usr/home/$1/public_html/$2
Hinweis
5.3 Fortgeschrittene Konfiguration
361
Zeilenumbrüche müssen gegebenenfalls entfernt werden.
Die erste Umschreibungsregel sorgt dafür, dass alle eingehenden Anfragen auf eine
beliebige Datei oder ein Verzeichnis unterhalb des Verzeichnisses nachrichten auf das
Verzeichnis news umgeleitet werden. Greift ein Client beispielsweise auf die Adresse
http://www.beispiel.de/nachrichten/wetter.html zu, wird er dadurch auf die Adresse
http://www.beispiel.de/news/wetter.html umgeleitet. Zerpflücken wir zunächst einmal
die Struktur dieses recht einfachen regulären Ausdrucks, das Suchmuster sieht wie
folgt aus:
^/nachrichten(.*)$
Sie haben bereits einige Hinweise und Erläuterungen zur Verwendung von regulären
Ausdrücken bekommen und können eventuell die Bedeutung dieses Suchmusters
selbst herleiten? Das Muster entspricht einer Zeichenkette, die mit einem Forwardslash
(^/) beginnt, gefolgt von dem Wort nachrichten und einer beliebig langen Folge von
Schriftzeichen (.*), die gleichzeitig das Ende der gesamten Zeichenkette ($) markieren.
In der Umschreibungsadresse /news wird durch die Variable $1 auf die Klammer (.*)
und damit auf die beliebige Folge von Schriftzeichen referenziert. Dadurch werden
diese Schriftzeichen (z.B. Name einer Datei) einfach komplett an den neuen Verzeichnisnamen /news angehängt, so dass aus http://www.beispiel.de/nachrichten/boerse.html
plötzlich http://www.beispiel.de/news/boerse.html wird.
Der Kern der zweiten RewriteRule-Anweisung sieht folgendermaßen aus:
^/impressum\.html$
Wissen Sie bereits, was dieses zugegebenermaßen recht kurze Suchmuster bedeutet?
Es prüft eine eingehende Anfrage auf den Dateinamen impressum.html, um einen
Client gemäß der Umschreibungsadresse umzuleiten. Dabei darf die Datei impressum.html nicht in einem Unterverzeichnis vorkommen, sondern muss im Hauptverzeichnis des Servers gespeichert sein, da der Anforderungsbefehl des Clients exakt
mit der Zeichenkette impressum beginnen (^impressum) muss und keine weiteren Zeichen vor dem Wort impressum enthalten darf. Folgende Anforderung würde deshalb
nicht auf diese Regel zutreffen:
http://www.beispiel.de/info/impressum.html
Gültig wäre einzig und allein folgende Anforderung:
http://www.beispiel.de/impressum.html
Sollte ein Client diese Adresse aufrufen, wird er automatisch auf die Adresse
http://www.beispiel.com/kontakt.html umgeleitet.
Die dritte und letzte Regel besteht im Kern aus folgendem regulären Ausdruck:
^/~(.*)/(.*)$
Dabei entsteht ein Muster, welches zu einer Anforderung passt, die auf ein individuelles Benutzerverzeichnis wie http://www.beispiel.de/~sebastian/ abzielt. Dabei muss die
362
5 Konfiguration
Anforderung mit einem Forwardslash und einer Tilde beginnen (^/~), gefolgt von
einer beliebig langen Zeichenkette, die durch den ersten in Klammern eingeschlossenen Teil (.*)/ repräsentiert wird. Danach muss eine beliebig lange Zeichenkette (.*) folgen, die gleichzeitig den Anforderungsbefehl abschließt ($). In der Umschreibungsadresse wird auf die erste Klammer durch die Variable $1 referenziert, die dem
angeforderten Verzeichnisnamen (z.B. sebastian) entspricht. Die zweite Klammer
wird durch den Wert $2 repräsentiert und entspricht dem angeforderten Dateinamen.
Die RewriteRule-Anweisung
RewriteRule ^/~(.*)/(.*)$ /usr/home/$1/public_html/$2
sorgt also dafür, dass die Anfragen auf die individuellen Verzeichnisse der Benutzer
auf das lokale Verzeichnis /usr/home umgeleitet werden. Dort befindet sich für jeden
Benutzer ein Verzeichnis mit seinem Namen, in dem im Unterverzeichnis public_html
die im Internet zu veröffentlichenden Informationen gespeichert werden. Ruft ein
Client beispielsweise die Adresse http://www.beispiel.de/~sebastian/index.html auf,
schaut der Apache im Verzeichnis /usr/home/sebastian/public_html nach einer Datei
namens index.html und liefert diese Datei an den Client.
Sie werden Referenzierungen der Form $1 oder $2 in der Umschreibungsadresse von
RewriteRule-Anweisung recht häufig sehen. Diese Variable heißen Backreferences und
repräsentieren einen in Klammern eingeschlossenen Teil des regulären Ausdrucks
einer RewriteRule- oder RewriteCond-Anweisung. Dabei sind es praktisch Rückverweise der Form $N bzw. %N, wobei N hier ein ganzzahliger Wert von 0 bis 9 sein
kann, der den Wert der N-ten Klammer einer RewriteCond bzw. RewriteRule-Anweisung entspricht. Das Dollarzeichen (z.B. $1) bezieht sich dabei auf einen in runden
Klammern eingeschlossenen Wert einer RewriteRule-Anweisung, das Prozentzeichen
(z.B. %1) steht für einen in Klammern eingeschlossenen Teil eines Suchmusters einer
RewriteCond-Anweisung. Weitere Informationen zur Verwendung von Backreferences
finden Sie in den Erläuterungen zur Konfigurationsanweisung RewriteCond.
Sie können neben einfachen Umschreibungsadressen und Backreferences auch beliebige Servervariablen und Umschreibungszuordnungen (vgl. RewriteMap) in der Konfigurationsanweisung RewriteRule verwenden. Dabei ist die Syntax weitgehend mit
der bereits vorgestellten Anweisung RewriteCond identisch, weitere Beispiele enthält
der Abschnitt über die Konfigurationsoption RewriteMap.
Die RewriteRule-Anweisung ermöglicht ebenso wie die RewriteCond-Anweisung die
Verwendung von so genannten Flags, d.h. vordefinierter Merkmale zur Kennzeichnung einer Umschreibungsregel. Dabei existieren folgende Merkmale und können
von Ihnen verwendet werden:
redirect, R
Dieses Merkmal erzeugt eine temporäre Umleitung auf die Umschreibungsadresse
einer RewriteRule-Anweisung. Wenn Sie beispielsweise alle Anfragen für Dateien mit
der Endung .php3 auf die entsprechenden Dateien mit der Endung .php umleiten
möchten, könnten Sie etwa folgende RewriteRule-Anweisung benutzen:
RewriteRule ^/(.*)\.php3$ /$1.php [R]
5.3 Fortgeschrittene Konfiguration
363
Sie können zudem HTTP-Statuscodes (vgl. Anhang) im Bereich von 300-400 verwenden, um die Umleitung genauer zu definieren. Standardmäßig wird eine dementsprechende Anfrage eines Clients mit einer temporären Umleitung und dem Statuscode
302 beantwortet, eine permanente Umleitung (HTTP-Statuscode 301) könnte etwa so
aussehen:
RewriteRule ^/(.*)\.php3$ /$1.php [R=301]
Dabei macht eine permanente Umleitung in vielen Fällen Sinn, wenn Sie wie im vorgestellten Beispiel ein Versionsupdate eingespielt haben. Neben den numerischen
Statuscodes können Sie auch die entsprechenden Namen wie permanent, seeother
oder temp benutzen:
RewriteRule ^/(.*)\.php3$ /$1.php [R=permanent]
Gerade für Anfänger empfehle ich die Verwendung von ausgeschriebenen Befehlen
und damit die Vermeidung von Kurzformen für die zahlreichen von mod_rewrite zur
Verfügung gestellten Befehle, da Sie sonst schnell den Überblick über die Bedeutung
einzelner Umschreibungsbefehle verlieren. Für das von uns durchgeführte Versionsupdate könnte der vollausgeschriebene RewriteRule-Befehl etwa so aussehen:
RewriteRule ^/(.*)\.php3$ /$1.php [Redirect=permanent]
Ich halte diese Schreibform für übersichtlicher und gerade für Anfänger bzw. nicht so
erfahrene Einsteiger ist diese Form sicherlich verständlicher.
forbidden, F
Der Client bekommt sofort eine Antwort mit dem HTTP-Statuscode 403, d.h., der
Zugriff auf eine bestimmte Adresse ist für den Client nicht erlaubt. Mit diesem Merkmal können Sie beispielsweise im Zusammenspiel mit einer RewriteCond-Anweisung
den Zugriff für bestimmte Clients auf gewisse Informationen verbieten. Sie müssen
dazu keine Umschreibungsadresse definieren, sondern können stattdessen einfach
einen Minusstrich verwenden. Um den Zugriff auf eine Datei namens geheim.html zu
verbieten, könnten Sie folgende Anweisung benutzen:
RewriteRule ^/geheim\.html$ - [forbidden]
Sicherlich macht bei einer derart einfachen Regel die Verwendung von mod_rewrite
nur bedingt Sinn, aber zumindest die allgemeine Syntax wird veranschaulicht. Um
ein sinnvolles Beispiel zu zeigen, können wir mit Hilfe einer RewriteCond-Bedingung
den Zugriff auf unsere Internetseite verbieten, wenn ein böser Client mit dem Internet
Explorer versucht, auf unsere Internetseite zuzugreifen:
RewriteCond %{HTTP_USER_AGENT} ^.*MSIE.*
RewriteRule ^/$ - [forbidden]
Der Internet Explorer meldet sich auf meinem Windows 2000 Professional-System
mit folgender Kennung: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0). Eine kurze
Übersicht der Kennungen der verschiedenen Browser-Typen finden Sie im Anhang
dieses Buches. Ein weiteres Beispiel aus der Praxis wäre das Verbot eines Zugriffs auf
364
5 Konfiguration
eine Internetseite außer von einem bestimmten IP-Adressbereich (z.B. dem firmeninternen Bereich). Um den Zugriff auf eine Internetseite für alle Clients zu verbieten,
die nicht aus dem IP-Adressbereich 192.168.0.x stammen, könnten Sie etwa folgende
RewriteCond- und RewriteRule-Anweisung verwenden:
RewriteCond %{REMOTE_ADDR} ^192\.168\.0\.[0-9]
RewriteRule ^/$ - [forbidden]
gone, G
Sollten Sie Inhalte vom Webserver gelöscht haben, die auch an keinem Ihnen bekannten alternativen Ort gespeichert sind, können Sie eingehende Anfragen mit dem
HTTP-Statuscode 410 beantworten, d.h. diese Inhalte sind überhaupt nicht mehr vorhanden bzw. unwiderruflich gelöscht. Wenn Sie das Merkmal Gone benutzen, müssen
Sie ebenfalls keine Umschreibungsadresse definieren. Folgendes Beispiel zeigt die
Verwendung des Gone-Merkmals:
RewriteRule ^/bundesliga_2000_2001.html$ - [gone]
Diese Regel beantwortet eine eingehende Anfrage für eine Datei namens
bundesliga_2000_2001.html mit einem Hinweis, dass die gewünschte Datei nicht mehr
vorhanden ist (HTTP-Statuscode 410).
proxy, P
Sofern Sie das Modul mod_proxy in die Serverkonfiguration eingebunden haben,
können Sie Inhalte von fremden Servern transparent, d.h. für den Client nicht sichtbar, auf Ihrem Webserver einblenden. Sie sollten sich besser die Erlaubnis von dem
jeweiligen Serverbetreiber einholen oder Sie werden schnell rechtliche Probleme
bekommen. Eine mögliche RewriteRule-Anweisung könnte etwa so aussehen:
RewriteRule ^/web/(.*)$ http://www.addison-wesley.de/$1 [P]
Greift ein Client auf eine Datei unterhalb der Adresse http://www.beispiel.de/web/ zu,
wird er auf die Internetseite des Verlags weitergeleitet, wobei in der Adresszeile des
Browsers die eingangs durch den Client angeforderte Adresse zu sehen ist und der
Client somit nicht merkt, dass er die ursprünglich angeforderte Seite verlassen hat.
Bitte beachten Sie außerdem, dass das Modul mod_proxy in der Serverkonfiguration
vorhanden sein muss, oder Sie erhalten eine Fehlermeldung (»Zugriff verweigert«).
Sie können das korrekte Vorhandensein des Moduls mod_proxy etwa durch folgenden
Befehl überprüfen, sofern Sie den Apache 2 nach /usr/local/apache2 installiert haben:
# /usr/local/apache2/bin/httpd -l | grep proxy
Dieser Befehl liefert eine Liste der verfügbaren Module Ihrer lokalen Apache-Installation und sucht aus dieser Liste alle Module mit dem Suchbegriff proxy heraus. Sollte
dieser Befehl einen leeren Wert zurückliefern, müssen Sie den Apache neu kompilieren, sofern Sie mod_rewrite in Verbindung mit mod_proxy nutzen möchten! Ein Beispielaufruf des configure-Skriptes des Apache könnte in etwa so aussehen:
# ./configure --prefix=/usr/local/apache2 --enable-rewrite --enable-proxy
5.3 Fortgeschrittene Konfiguration
365
Weitere Informationen zur Installation des Apache entnehmen Sie bitte dem entsprechenden Kapitel.
last, L
Wie der Name schon sagt, symbolisiert dieses Merkmal die letzte Umschreibungsregel und sorgt dafür, dass keine weiteren RewriteRule-Anweisungen mehr ausgeführt werden. Das Merkmal ist vergleichbar mit dem Befehl last der Programmiersprache Perl bzw. dem Befehl break der Programmiersprache C.
next, N
Das Gegenstück zum vorherigen Merkmal heißt Next und sorgt dafür, dass alle vorhandenen Umschreibungsregeln erneut abgearbeitet werden. Das Merkmal ist vergleichbar mit dem Befehl continue der Programmiersprache C und dem Befehl next
der Programmiersprache Perl. Seien Sie sehr vorsichtig bei der Verwendung dieses
Merkmals, denn Sie können so eine unendliche Schleife erzeugen, die unter Umständen sogar den Server zum Absturz bringen kann.
chain, C
Sie können mit dem chain-Merkmal aufeinander folgende RewriteRule-Anweisungen
miteinander verknüpfen. Sollte eine mit dem chain-Merkmal versehene RewriteRule-Anweisung nicht ausgeführt werden, wird automatisch die darauf folgende
RewriteRule-Anweisung ebenfalls nicht ausgeführt. Enthält die nicht ausgeführte
RewriteRule-Anweisung ihrerseits auch das chain-Merkmal wird die nächste RewriteRule-Anweisung ferner nicht ausgeführt usw. Dieses Verknüpfungssystem lässt sich
beliebig weit verschachteln.
skip, S
Mit dem skip-Merkmal können Sie die Anzahl der nachfolgenden RewriteRule-Anweisungen angeben, die übersprungen werden sollen. Damit werden kleine Fallunterscheidungen mit Hilfe eines If-Then-Else ähnlichen Konstrukts möglich und Sie können die Ausführungsgeschwindigkeit Ihrer Umschreibungsregeln erheblich
verbessern, wenn Sie das skip-Merkmal immer dort einsetzen, wo eine Regel den
Benutzer umleitet und Sie sicher sind, dass keine weiteren Umschreibungen mehr
erfolgen. Ein Beispiel:
RewriteRule
RewriteRule
RewriteRule
RewriteRule
^/index\.html$ /hauptseite\.html [redirect,skip=2]
^/nachrichten/(.*)$ http://www.focus.de/$1 [proxy,skip=1]
^/index\.htm$ /hauptseite\.html [redirect]
^/hauptseite\.html$ /main.php [redirect]
Die erste RewriteRule-Anweisung leitet alle eingehenden Anfragen für die Datei
index.html auf eine Datei namens hauptseite.html um (redirect) und überspringt die
nächsten zwei RewriteRule-Anweisungen (skip=2).
Die zweite Regel führt bei einer Anfrage nach http://www.beispiel.de/nachrichten/ eine
Proxy-Anfrage an die Internetseite www.focus.de durch und präsentiert das Ergebnis
dem Benutzer. Danach überspringt sie die nachfolgende Regel.
Das vorletzte Beispiel leitet auch alle Anfragen für die Datei index.htm auf die richtige
Startseite hauptseite.html um. Zum Schluss erfolgt noch eine Umleitung von der Datei
366
5 Konfiguration
hauptseite.html auf ein PHP-Skript namens main.php, welches die Daten für die Startseite dynamisch aus einer MySQL-Datenbank holen könnte.
type, T
Mit dem Merkmal type können Sie einen MIME-Typ definieren, der bei der Beantwortung einer Anfrage eines Clients durch den Server gesendet werden soll. Damit ließe
sich beispielsweise die durch mod_alias bereitgestellte ScriptAlias-Direktive nachbilden und jede Datei in einem bestimmten Verzeichnis als CGI-Skript behandeln.
Wenn Sie beispielsweise in einem Unterverzeichnis namens Bilder Ihrer Internetseite
einige Bilddateien im JPEG-Format gespeichert haben, könnten Sie etwa folgende
Umschreibungsregel verwenden und bei einem Zugriff eines Clients auf dieses Verzeichnis durch mod_rewrite automatisch den korrekten Typ setzen lassen:
RewriteRule ^/bilder/(.*)$ - [Type=image/jpeg,Last]
Sie müssen dabei keine Umschreibungsadresse angeben, es reicht ein einfaches
Minuszeichen! Durch diese Regel werden alle Dateien im Verzeichnis /bilder als JPEGDateien behandelt. Eine Übersicht der verschiedenen MIME-Typen finden Sie im
Handbuch des Apache bzw. im Internet und in der Datei mime.types im Unterverzeichnis conf Ihrer lokalen Apache-Installation.
qsappend, QSA
Beim Zugriff auf eine Adresse kann der Client weitere Parameter in Form eines so
genannten Query-Strings übergeben. Ein typisches Beispiel für eine Anfrage mit
einem durch den Client übermittelten Query-String sähe beispielsweise so aus:
http://www.beispiel.de/kontakt.php?standort=frankfurt
Es wird ein PHP-Skript namens kontakt.php aufgerufen, welches als einzigen Parameter
die Variable standort mit dem Wert frankfurt übermittelt bekommen hat. Ein solches
Skript könnte etwa die Kontaktadresse und die Telefonnummer der Frankfurter Niederlassung einer Firma aus einer Datenbank holen und ausgeben. Dabei werden das
Skript und der Query-String durch ein einfaches Fragezeichen voneinander getrennt.
Wenn Sie eine Umschreibungsregel für eine Datei definieren, werden die als QueryString übergebenen Parameter normalerweise abgeschnitten und erst später an die
Umschreibungsadresse respektive -datei übergeben, d.h., Sie haben nicht die Möglichkeit, neben dem ursprünglich verwendeten Query-String noch weitere Daten an
die Zieldatei Ihrer Umschreibung anzuhängen. Folgendes Beispiel soll diesen
Umstand kurz verdeutlichen:
RewriteRule ^/index\.html$ /main.php [redirect]
Wenn Sie jetzt den Server starten und die Adresse http://www.beispiel.de/
index.html?bla=fasel aufrufen, wird der Query-String ohne Änderung an die Datei
main.php weitergeleitet, weshalb Sie auf der Seite http://www.beispiel.de/main.php?
bla=fasel landen. Findige Anwender könnten auf die Idee kommen, dass man den
zusätzlichen Query-String einfach an die Umschreibungsadresse anhängen muss:
RewriteRule ^/index\.html$ /main.php?foo=bar [redirect]
5.3 Fortgeschrittene Konfiguration
367
Rufen Sie jetzt die Adresse http://www.beispiel.de/index.html?bla=fasel auf, werden Sie
sofort auf die Adresse http://www.beispiel.de/main.php?foo=bar weitergeleitet, d.h., die
eingangs als Query-String übermittelten Parameter gehen verloren!
Sie müssen daher das Merkmal qsappend (engl. append query-string, etwa: Beifügen
des Anforderungsparameters) verwenden, um die Daten des ursprünglich übermittelten Query-Strings ebenfalls in der Umschreibungsadresse zu verwenden:
RewriteRule ^/index\.html$ /main.php?foo=bar [qsappend,redirect]
Starten Sie den Server neu und rufen Sie die Adresse http://www.beispiel.de/
index.html?bla=fasel auf und Sie werden sehen, dass eine Umleitung nach
http://www.beispiel.de/main.php?foo=bar&bla=fasel erfolgt, d.h. der ursprüngliche QueryString und der Query-String der RewriteRule-Anweisung werden miteinander zu einem
Anforderungsparameter verknüpft!
noescape, NE
Sollten in der Umschreibungsadresse Sonderzeichen enthalten sein, wie z.B. Ausrufezeichen oder Leerzeichen, müssen diese in entsprechende Escape-Werte (so genannte
Escape-Sequenzen) umgewandelt werden. Unter Umständen kann diese Umwandlung jedoch nicht erwünscht sein und durch Angabe des Merkmals noescape verhindert werden. Allerdings laufen Sie durch die Abschaltung der Umwandlung von Sonderzeichen in die entsprechenden Escape-Werte Gefahr, dass es zu Problemen oder
gar Fehlern beim Aufruf eines Dokumentes kommt, da die Sonderzeichen nicht richtig übergeben worden sind!
nosubreq, NS
Das Merkmal nosubreq sorgt dafür, dass die aktuelle Regel übersprungen wird, wenn
die aktuelle Anforderung eine vom Apache selbst bzw. einem seiner Module (z.B.
mod_userdir und mod_include) ausgelöste, interne Anfrage ist. Eine interne Anfrage
wird beispielsweise ausgelöst, wenn mod_include versucht, herauszufinden, welche
Datei die durch die Konfigurationsanweisung DirectoryIndex spezifizierte Startseite
ist (z.B. index.html), die an den Client geliefert werden soll.
Gerade im Zusammenspiel von RewriteRule-Anweisungen und CGI-Skripten gibt es
oft Probleme, wenn CGI-Skripte interne Sub-Anfragen verursachen. In derartigen
Fällen sollten Sie das Merkmal nosubreq benutzen.
nocase, NC
Sinnvollerweise sollten Sie beim Vergleich des regulären Ausdrucks mit dem Testargument die Beachtung von Groß- und Kleinschreibung deaktivieren. Gerade die
unterschiedliche Groß- und Kleinschreibung ist oft Ursache von Verwechslungen
oder nicht funktionierenden Umschreibungsregeln.
passthrough, PT
Sofern Sie eine Umschreibungsadresse durch ein anderes Modul (z.B. mod_alias oder
mod_userdir) weiter verarbeiten lassen möchten, müssen Sie das Merkmal passthrough (engl. etwa: weitergeben, durchreichen) angeben. Dabei wird die Anfrage so
modifiziert, dass das URI-Feld der internen request_rec-sub auf den Wert des Feldes
filename gesetzt wird. Da mod_rewrite URL-Adressen in Dateinamen umschreibt,
368
5 Konfiguration
kennt es daher das Ziel einer Umschreibungsregel als Dateinamen und die Ausgabe
von mod_rewrite kann von anderen Modulen (z.B. mod_alias) bearbeitet werden. Ein
Beispiel:
RewriteRule ^/nachrichten(.*) /news$1 [PT]
Alias /news /aktuelles
Die RewriteRule-Anweisung würde jede Anfrage für das Verzeichnis /nachrichten auf
das Verzeichnis /news umleiten. Die Alias-Anweisung sorgt dafür, dass die Inhalte
nicht unter /news, sondern unter /aktuelles verfügbar sind. Wenn Sie das Merkmal
passthrough (bzw. die Kurzform PT) weglassen, würde die angegebene Alias-Anweisung nicht ausgeführt!
cookie, CO
Seit der Version 2.0.42 kann mod_rewrite auch Cookies setzen. Dabei muss der
Cookie in folgendem Format angegeben werden:
Cookie=Name:Wert:Domain[:Gültigkeit]
Ein möglicher Aufruf wäre etwa:
Cookie=Benutzername:Wer_ist_Paul:beispiel.de:30
Dieser Aufruf würde einen Cookie namens Benutzername mit dem Wert Wer_ist_Paul
erzeugen, der für die Domain beispiel.de und einen Zeitraum von 30 Minuten gültig
wäre.
env, E
Ein sehr nützliches Merkmal heißt env und erlaubt die Definition von Umgebungsvariablen in einer RewriteRule-Anweisung, die Sie später in anderen RewriteRuleAnweisungen oder selbstentwickelten Programmen (z.B. in Perl, PHP) auslesen und
verwerten können. Ich möchte Ihnen dieses sehr praktische Feature anhand eines
leicht modifizierten Beispiels vorstellen, welches ursprünglich von Ken Coar
(http://ken.coar.org), einem der Entwickler des Apache und Vize-Präsidenten der Apache Software Foundation, geschrieben worden ist:
SetEnvIfNoCase Referer !"^http://www\.beispiel\.de/" extern=1
SetEnvIfNoCase Request_URI "\.(gif|jpg|png)" ist_ein_bild=1
RewriteEngine On
RewriteCond
${ENV:extern} =1
RewriteCond
${ENV:ist_ein_bild} =1
RewriteRule
.* - [Last,Env=bilddiebe:1]
CustomLog logs/bilddiebe_log common env=bilddiebe
Zunächst setzt eine SetEnvIfNoCase-Anweisung eine Umgebungsvariable namens
extern mit dem Wert 1, wenn der durch den Client übermittelte Referer, d.h. der Hinweis, der die letzte durch den Client besuchte Webseite enthält, nicht auf die Internetseite http://www.beispiel.de verweist. Dies ist beispielsweise der Fall, wenn jemand
unerlaubterweise auf den Inhalt Ihrer Homepage zugreift, ohne sich wirklich auf
5.3 Fortgeschrittene Konfiguration
369
Ihrer Internetseite zu befinden, d.h., eine andere Internetseite hat vermutlich Inhalte
Ihrer Internetseite als eigene Inhalte eingebunden. Die zweite SetEnvIfNoCase-Anweisung definiert eine Umgebungsvariable namens ist_ein_bild, wenn es sich bei der
durch den Client angeforderten Datei um eine Bilddatei mit der Endung .gif, .jpg oder
.png handelt. Die nächste Anweisung schaltet die Benutzung des Umschreibungsalgorithmus von mod_rewrite, die so genannte Rewrite Engine, ein. Die beiden
RewriteCond-Bedingungen überprüfen, ob die beiden Umgebungsvariablen extern
und ist_ein_bild jeweils den Wert 1 haben, d.h., ob es sich um einen externen Zugriff
auf eine Datei in den besagten Bildformaten handelt. In diesem Fall wird die
RewriteRule-Anweisung ausgeführt, die den Zugriff verbietet, und die Umgebungsvariable bilddiebe definiert. Darüberhinaus wird die Verarbeitung weiterer Anweisungen von mod_rewrite sofort abgebrochen (Merkmal Last) und die CustomLog-Anweisung protokolliert die Zugriffe böser Bilddiebe im Common Log Format in eine Datei
namens bilddiebe_log, die im Unterverzeichnis logs der lokalen Apache-Installation
gespeichert wird.
Eine weitere Lösung, um bösen Bilddieben das Handwerk zu legen, ist folgende Variante, die gänzlich ohne das Setzen neuer Umgebungsvariablen auskommt und stattdessen auf bereits vorhandenen Variablen der Server bzw. Clientumgebung basiert:
RewriteCond %{HTTP_REFERER} !^/$
RewriteCond %{HTTP_REFERER} !^http://www\.beispiel\.de/.*$ [NC]
RewriteRule /+bilder/+.* - [F]
Durch die beiden RewriteCond-Bedingungen ist der Zugriff auf Dateien aus dem Verzeichnis images nur möglich, wenn der Wert des Referers leer ist, da der Client keinen
geschickt hat, oder wenn der Referer mit http://www.beispiel.de/ beginnt, d.h. von der
lokalen Seite kommt. Durch die zusätzliche Angabe von Pluszeichen (vgl. Erläuterungen zu regulären Ausdrücken) kann diese Zugriffssperre auch nicht durch eigentlich
ungültige Verzeichnisangaben wie ///images oder /images// umgangen werden.
Verwenden Sie entweder den ausgeschriebenen Namen eines Merkmals (z.B. redirect)
oder dessen Kurzform (z.B. R für redirect). Wenn Sie mehrere Merkmale miteinander
kombinieren möchten, trennen Sie die einzelnen Merkmale durch ein Komma:
RewriteRule ^/index\.cgi$ /cgi-bin/lookup.cgi?seite=index [QSA,R]
Bevor ich Sie an diverse externe Informationsquellen verweise, möchte ich ein
abschließendes Beispiel vorstellen:
RewriteEngine On
RewriteRule ^/$ http://www.beispiel.de/?userid=pepe23 [proxy]
RewriteRule ^/(.*) http://www.beispiel.de/$1 [proxy]
Dieses Beispiel könnte eine mögliche Lösung für einen Webmaster sein, der an einem
Partnerprogramm eines externen Anbieters teilnimmt und dort über eine bestimmte
Benutzerkennung verfügt, die an eine speziell präparierte Seite übergeben werden
muss. Zunächst wird durch die RewriteEngine-Anweisung der Umschreibungsalgorithmus von mod_rewrite aktiviert. Danach wird jede Anfrage für die Startseite des
370
5 Konfiguration
eigenen Servers (RewriteRule ^/$ ...) an die externe Adresse http://www.beispiel.de/
?userid=pepe23 weitergegeben, wobei auch der fiktive Parameter userid=pepe23
berücksichtigt wird. Durch die Angabe des Kennzeichen proxy, welches das Vorhandensein des Moduls mod_proxy erzwingt, wird der Inhalt des externen Partners in
die eigene Seite transparent, d.h. für den Client nicht sichtbar, eingebunden. Die
dritte und letzte Regel leitet alle Anfragen, die nicht an die Startseite der eigenen
Website gehen (z.B. Grafiken, Bilder oder beliebige Dateien), transparent an die
externe Quelle weiter.
Weitere Informationen zur Verwendung von mod_rewrite finden Sie im Internet u.a.
auf folgenden Webseiten:
http://www.modrewrite.com
http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html
http://www.apacheref.com/ref/mod_rewrite.html
Generell kann man nur eine wirkliche Empfehlung für die Verwendung von
mod_rewrite aussprechen: Probieren geht über Studieren :-)
Sollten Sie wider Erwarten keine Aufgabe haben, die Sie mit mod_rewrite lösen können, denken Sie sich eine fiktive Aufgabe aus. Lesen Sie die Ihnen vorliegenden
Dokumentationen und probieren Sie die Umschreibungsregeln aus! Definieren Sie
eine Logdatei und einen entsprechend hohen Loglevel und verfolgen Sie die Ausgaben, die Ihre Regeln erzeugen. Gegebenenfalls müssen Sie die von Ihnen erstellten
Regeln modifizieren. mod_rewrite ist derart komplex, dass es in seiner Gesamtheit
betrachtet, den Rahmen dieses Buches sprengen würde. Wenn Sie weiterhin Probleme mit der Verwendung von mod_rewrite haben, melden Sie sich bei einer der im
Anhang dieses Buches vorgestellten Mailinglisten an und fragen Sie dort nach Hilfe.
Alternativ können Sie auch eines der zahlreichen Foren zum Apache und insbesondere zu mod_rewrite versuchen! Viel Erfolg ;-)
5.4
Sonstige Module
5.4.1
Der Apache als Proxy-Server (mod_proxy)
Der Apache kann mit Hilfe des Moduls mod_proxy auch als Proxy-Server fungieren
(proxy = lat. benachbart). Hinweis: Die Zwischenspeicherung von Informationen
wurde in der Version 2 des Apache in ein eigenes Modul namens mod_cache ausgelagert.
Das Grundprinzip eines Proxy-Servers veranschaulicht folgendes Schema:
5.4 Sonstige Module
371
Der Proxy-Server ruft stellvertretend für
den jeweiligen Client die Internetseite
http://www.addison-wesley.de ab und
speichert diese lokal zwischen.
Client X oder Y ruft die Internetseite
http://www.addison-wesley.de über den
Proxy-Server auf.
Proxy-Server
Internet
Client X
Client Y
Sofern eine durch einen Client
angeforderte Internetseite bereits auf
dem Proxy-Server zwischengespeichert
ist, vergleicht dieser die gespeicherte
Version mit der im Internet verfügbaren
Version und lieferte die jeweils aktuellere
Variante an den Client aus.
Webserver für
www.addison-wesley.de
Abbildung 5.5 Vereinfachtes Prinzip eines Proxy-Servers
Ein Proxy-Server ist ein zwischengeschalteter Server, dessen Aufgabe es ist, einen
zentralisierten und organisierten Internetzugang bereitzustellen. Dabei agiert ein
Proxy-Server praktisch als Vermittler zwischen seinen Clients und dem Internet, da
jede Anfrage eines Clients über den Proxy-Server läuft, der wiederrum für die Clients
die Anfrage ausführt und die Antwort des abgefragten Servers an die Clients weitergibt. Zusätzlich protokolliert ein Proxy-Server die Zugriffe und speichert die Antworten der abgefragten Server auf der lokalen Festplatte zwischen, so dass bei einer weiteren Anfrage für eine bereits gespeicherte Internetseite eine Versionskontrolle
zwischen der lokal zwischengespeicherten Version und der aktuell im Internet verfügbaren Version durchgeführt wird. Sollte die im Internet verfügbare Version aktueller sein, ruft der Proxy-Server diese neuere Version ab, speichert diese zwischen
und sendet die zwischengespeicherte und aktualisierte Version an den Client. Sofern
die zwischengespeicherte Version mit der aktuell im Internet verfügbaren Version
identisch ist, werden die zwischengespeicherten Inhalte an den Client gesendet. In
der Praxis kommen Proxy-Server oft in Unternehmensnetzwerken zum Einsatz, da
sie eine zentralisierte und kontrollierte Zugriffsmöglichkeit auf das Internet bereitstellen. Außerdem lässt sich durch einen Proxy-Server der Zugriff auf heikle Inhalte
einer Internetseite (z.B. Erotik, Gewalt etc.) beschränken bzw. verbieten. Die bekannteste und zweifelsohne beste (freie) Lösung zum Betrieb eines Proxy-Servers heißt
Squid (http://www.squid-cache.org), wobei auch der Apache als Proxy-Server dienen
kann, wie die Erläuterungen zu den durch mod_proxy bereitgestellten Konfigurationsdirektiven zeigen:
372
5 Konfiguration
AllowConnect
AllowConnect aktiviert oder deaktiviert die Tunnelung von Verbindungen zu
bestimmten Ports über den Proxy.
Konfigurationsanweisung:
AllowConnect
Syntax:
AllowConnect Portnummer
Standardwerte (Default):
AllowConnect 443 563
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit dieser Anweisung können Sie eine Reihe von Diensten definieren, auf die der
Proxy-Server mit der Connect-Methode zugreifen soll. Dabei werden Verbindungen
zu diesen Diensten durch den Proxy-Server getunnelt und verschlüsselt. Standardmäßig wird der Zugriff auf die Dienste SSL (Port 443) und NNTPS (Port 563) ermöglicht:
AllowConnect 443 563
Sofern Sie keine weiteren Dienste benötigen, können Sie die Einstellungen so belassen.
Proxy
Definiert einen proxyspezifischen Container.
Konfigurationsanweisung:
Proxy
Syntax:
<Proxy URL>...</Proxy>
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die <Proxy>-Anweisung erstellt einen Container zur Definition von proxyspezifischen Konfigurationsanweisungen, wobei als Parameter eine URL oder ein Jokerzeichen verwendet werden kann. Ein Beispiel:
<Proxy *>
Order Deny,Allow
Deny from all
Allow from firewall.beispiel.de
</Proxy>
5.4 Sonstige Module
373
Diese Konfiguration verbietet den Zugriff auf den Proxy-Server für alle Rechner und
erlaubt den Zugriff einzig durch das System firewall.beispiel.de. Hinweis: Bitte achten
Sie darauf, dass Sie den Zugriff auf den lokalen Proxy-Server beschränken und nur
für privilegierte Clients bereitstellen. Andernfalls könnte Ihr Server für diverse
Angriffe (vgl. Kapitel über mod_security) missbraucht werden.
Ein letztes Beispiel:
<Proxy http://www.beispiel.de>
SetOutputFilter DEFLATE
</Proxy>
Bei einem Zugriff auf die Domain http://www.beispiel.de werden durch die Konfiguration die Daten automatisch mit Hilfe von mod_deflate komprimiert.
ProxyMatch
Definiert einen proxyspezifischen Container anhand eines regulären Ausdrucks.
Konfigurationsanweisung:
ProxyMatch
Syntax:
<ProxyMatch URL>...</ProxyMatch>
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung ist mit der <Proxy>-Anweisung funktional identisch und erstellt
einen proxyspezifischen Container. Dabei erlaubt die Anweisung die Verwendung
von regulären Ausdrücken als Parameter zur Darstellung der URL (vgl. <Proxy>Anweisung).
NoProxy
Diese Anweisung schaltet die eventuelle Nutzung eines übergeordneten Proxy-Servers für gewisse Internetseiten ab.
Konfigurationsanweisung:
NoProxy
Syntax:
NoProxy Domain | Subnetz | IP-Adresse |
Hostname
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
374
5 Konfiguration
Sofern der von Ihnen konfigurierte Proxy-Server auf einen übergeordneten ProxyServer zugreift (vgl. ProxyRemote-Anweisung), können Sie mit dieser Option eine
Liste von Internetseiten definieren, für die der übergeordnete Proxy-Server nicht
benutzt werden soll. Dies könnte etwa in einem lokalen Unternehmensnetzwerk mit
einem eigenen Webserver nützlich sein. Als einzigen Parameter erwartet die NoProxyAnweisung die Angabe eines oder mehrerer Internetseiten, für die der übergeordnete
Proxy-Server umgangen werden soll, wobei folgende Formate möglich sind:
Domain
Wenn Sie alle Zugriffe auf eine bestimmte Domain ohne Verwendung des übergeordneten Proxy-Servers (direkt) ausführen möchten, müssen Sie einen Domainnamen
definieren, für den diese Regelung gelten soll. Dabei muss es sich um einen partiellen
Domainnamen handeln, der mit einem führenden Punkt angegeben wird. Groß- und
Kleinschreibung wird dabei nicht beachtet:
NoProxy .beispiel.de
Diese Anweisung umgeht den übergeordneten Proxy-Server für alle Anfragen auf die
Domain beispiel.de (z.B. www.beispiel.de).
Netzwerkbereich
Sie können auch einen Netzbereich definieren, auf den der Proxy-Server direkt, d.h.
ohne Verwendung des übergeordneten Proxy-Servers, zugreift. Dazu muss ein IPAdressbereich angegeben werden, der optional auch die Angabe der zugehörigen
Netzmaske enthält. In der Praxis wird die Angabe eines Netzwerkbereichs bevorzugt,
wenn ein Netzwerkbereich oder auch ein einzelnes System über ein lokales Netzwerkgerät des Servers direkt erreichbar ist. Ein Beispiel:
NoProxy 192.168
In diesem Fall umgeht der Server den übergeordneten Proxy-Server, wenn der
Zugriff auf den IP-Adressbereich 192.168.x.y erfolgt. Der IP-Adressbereich kann auch
ausgeschrieben werden, wobei optional die Angabe der zugehörigen Netzwerkmaske
in Kurz- (/16) oder Langschreibung (255.255.0.0) möglich ist:
NoProxy 192.168.0.0
NoProxy 192.168.10.0/21
NoProxy 192.168.10.0/255.255.248.0
Das erste dieser drei Beispiele ist funktional mit dem bereits vorgestellten Beispiel
identisch und steht für den IP-Bereich 192.168.x.y. Im zweiten Beispiel erfolgt die
Angabe des IP-Adressbereichs in Kurzschreibweise (/21) und bezeichnet so den IPBereich 192.168.10.x mit der Netzmaske 255.255.248.0. Das letzte Beispiel ist mit dem
zweiten Beispiel funktional identisch, wobei der IP-Adressbereich und die zugehörige Netzmaske ausgeschrieben wurden.
IP-Adresse
Natürlich ist auch die Angabe einer vollständigen IP-Adresse möglich, auf die ein
direkter Zugriff erfolgen soll. Normalerweise ist für eine IP-Adresse nicht unbedingt
5.4 Sonstige Module
375
ein DNS-Eintrag vorhanden, so dass allgemein die Verwendung von IP-Adressen
durchaus Geschwindigkeitsvorteile bringt.
Hostname
Schließlich ist auch die Angabe eines vollständigen Hostnamens möglich, auf den ein
direkter Zugriff, d.h. ohne Verwendung eines übergeordneten Proxy-Servers, durchgeführt werden soll. Dazu muss der Hostname in die entsprechende IP-Adresse aufgelöst werden, was zu Geschwindigkeitseinbußen führt. Ein Beispiel:
NoProxy www.beispiel.de
Durch diese Anweisung erfolgt der Zugriff auf die Adresse www.beispiel.de ohne Verwendung des übergeordneten Proxy-Servers. Hinweis: Bei der Angabe eines vollständigen Hostnamens wird die Groß- und Kleinschreibung nicht beachtet. Ein abschließendes Beispiel:
ProxyRemote * http://firewall.beispiel.de:8080
NoProxy .beispiel.de 192.168.0.0/24
Diese beiden Anweisungen leiten jede Anfrage an einen übergeordneten ProxyServer weiter, der unter der Adresse http://firewall.beispiel.de auf Port 8080 erreichbar
ist. Nur Zugriffe auf beliebige Bereiche der Adresse beispiel.de und 192.168.x.y erfolgen direkt und umgehen den übergeordneten Proxy-Server.
ProxyBadHeader
Definiert das Verhalten des Apache, wenn eine Gegenstelle eine im Header syntaktisch falsche Antwort geschickt hat.
Konfigurationsanweisung:
ProxyBadHeader
Syntax:
ProxyBadHeader IsError | Ignore | StartBody
Standardwerte (Default):
ProxyBadHeader IsError
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Sofern Sie den Apache als Proxy-Server benutzen, können Sie mit der ProxyBadHeader-Anweisung ab der Version 2.0.44 des Indianers bestimmen, wie dieser auf eine im
Header syntaktisch falsche Antwort (z.B. fehlender Doppelpunkt im Header) einer
Gegenstelle reagieren soll. Dabei stehen Ihnen die folgenden Verhaltensweisen zur
Verfügung:
IsError
Ist im Header einer Antwort der Gegenstelle auf eine Anfrage eines Clients ein syntaktischer Fehler enthalten, so wird die Clientanfrage unterbrochen und eine Fehlermeldung mit dem HTTP-Statuscode (502 Bad gateway) erzeugt. Dieses Verhalten ist
die Standardeinstellung der ProxyBadHeader-Anweisung.
376
5 Konfiguration
Ignore
Sie können mit Hilfe dieser Option die im Header syntaktisch falsche Antwort einer
Gegenstelle ignorieren. Dies könnte beispielsweise ein gewünschtes Verhalten sein,
wenn ihre Clients auf Informationen zugreifen müssen, die auf einem externen Server
(Gegenstelle) gespeichert sind, der jedoch falsche bzw. ungültige Informationen im
Header sendet.
StartBody
Mit dieser Option werden, sobald eine im Header syntaktisch falsche Antwort der
Gegenstelle empfangen worden ist, die restlichen Daten des Headers ausgelesen und
der verbleibende Rest als Body, d.h. eigentlicher Inhalt (Information) der Antwort,
behandelt. Diese Verhaltensweise ist ein Trick, um auch solche Antworten von (fehlerhaften) Servern verarbeiten zu können, die den Header und den eigentlichen Inhalt
einer Anfrage nicht durch eine leere Zeile trennen.
ProxyBlock
Blockiert den Zugriff auf Internetseiten, deren Name eine bestimmte Zeichenkette
enthält.
Konfigurationsanweisung:
ProxyBlock
Syntax:
ProxyBlock * | Wort | Hostname | Domainname
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Wenn Sie den Zugriff auf bestimmte Internetseiten blockieren wollen, können Sie die
ProxyBlock-Anweisung benutzen. Sie erwartet als einzigen Parameter die Angabe
einer Zeichenkette, die im Namen einer zu sperrenden Internetseite enthalten sein
muss. Alternativ ist auch die explizite Angabe einer verbotenen Domain möglich. Ein
Beispiel:
ProxyBlock xxx
Diese Anweisung blockiert jegliche Zugriffe auf alle Internetseiten, deren Name die
Zeichenkette xxx enthält (z.B. www.megaxxx.com, www.superxxx.com oder www.xxx.com).
Ein weiteres Beispiel:
ProxyBlock www.focus.de www.spiegel.de heise.de
Diese Anweisung blockiert die Zugriffe auf die Internetseiten www.focus.de und
www.spiegel.de. Zusätzlich sind jegliche Zugriffe auf beliebige Bereiche der Internetseite heise.de verboten, so dass den Benutzern des Proxy praktisch der Zugriff auf
einige der größten deutschen Internetseiten verwehrt wird.
5.4 Sonstige Module
377
Wenn Sie generell den Zugriff auf alle Internetseiten sperren möchten, könnten Sie
folgende Anweisung benutzen:
ProxyBlock *
Der praktische Nutzen dieser Anweisung ist eher gering. Dennoch könnte eine derartige Anweisung beispielsweise dazu genutzt werden, den Internetzugriff für
bestimmte Clients vollständig zu sperren.
ProxyDomain
Definiert die Domainadresse des Proxy-Servers bzw. des zugehörigen Netzwerks.
Konfigurationsanweisung:
ProxyDomain
Syntax:
ProxyDomain Domainname
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit dieser Anweisung bestimmen Sie den Domainnamen des Netzwerks, zu dem der
Proxy-Server gehört. Dieser Domainname wird an alle Clientanfragen angehängt, die
nur einen Host- und keinen Domainnamen übermittelt haben. Ein Beispiel:
ProxyRemote * http://firewall.beispiel.de:8080
NoProxy .beispiel.de 192.168.0.0/24
ProxyDomain .beispiel.de
Diese drei Anweisungen sorgen dafür, dass sämtliche Anfragen an den übergeordneten Proxy-Server http://firewall.beispiel.de:8080 weitergeleitet werden, falls diese nicht
für einen beliebigen Bereich der Adresse beispiel.de oder den Netzwerkbereich
192.168.x.y bestimmt sind. Außerdem wird jeder Anfrage, die keinen Domainnamen
enthält, automatisch der Domainname beispiel.de angehängt, so dass aus einer
Anfrage nach www, automatisch die Adresse www.beispiel.de wird.
ProxyErrorOverride
ProxyErrorOverride bestimmt die Weitergabe von Fehlermeldungen externer Server
an interne Clients des Proxies.
Konfigurationsanweisung:
ProxyErrorOverride
Syntax:
ProxyErrorOverride On | Off
Standardwerte (Default):
ProxyErrorOverride Off
Enthalten in Modul:
mod_proxy
378
5 Konfiguration
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung ist neu im Apache 2 und schaltet die ungefilterte Weitergabe von
Fehlermeldungen externer Server an interne Clients ein oder aus. Ein Beispiel:
ProxyErrorOverride Off
Wenn Sie die Fehlermeldungen externer Server direkt an die Clients weitergeben
möchten, können Sie eine derartige Anweisung benutzen. Sofern Sie jedoch im Falle
eines aufgetretenen Fehlers die Standardfehlermeldungen des Apache bzw. eine
durch die ErrorDocument-Anweisung definierte Meldung an den Client schicken
möchten, können Sie folgende Anweisung verwenden:
ProxyErrorOverride On
In der Praxis ließe sich diese Anweisung in einem Unternehmensnetzwerk dazu nutzen, den Clients standardisierte und einheitliche Fehlermeldungen zu präsentieren,
die eventuell die Corporate Identity eines Unternehmens widerspiegeln.
ProxyIOBufferSize
Definiert die Größe des internen Ein- und Ausgabepuffers des Proxy.
Konfigurationsanweisung:
ProxyIOBufferSize
Syntax:
ProxyIOBufferSize Größe
Standardwerte (Default):
ProxyIOBufferSize 8192
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die ProxyIOBufferSize-Direktive bestimmt die Größe eines internen Puffers, der zur
Datenein- und -ausgabe verwendet wird. Ein Beispiel:
ProxyIOBufferSize 8192
Mit Hilfe dieser Anweisung definieren Sie einen Datenein- bzw. -ausgabepuffer von
8192 Bytes (Standardeinstellung). Normalerweise sollten Sie den vorgegebenen Wert
nicht ändern, andernfalls müssen Sie einen Wert zwischen 0 und dem Maximalwert
8192 auswählen.
ProxyMaxForwards
ProxyMaxForwards definiert die maximale Anzahl an Zwischenschritten, bevor eine
Anfrage nicht ausgeführt wird.
5.4 Sonstige Module
379
Konfigurationsanweisung:
ProxyMaxForwards
Syntax:
ProxyMaxForwards Anzahl
Standardwerte (Default):
ProxyMaxForwards 10
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Zur Vermeidung von Denial of Service-Attacken und unerwünschten Anfragen, die
ins Leere laufen, gibt es im Apache 2 die ProxyMaxForwards-Anweisung, die die maximale Anzahl an Zwischenschritten definiert, bevor eine Anfrage nicht ausgeführt
wird. Die Standardeinstellung lautet:
ProxyMaxForwards 10
Durch diese Anweisung wird eine Anfrage nicht mehr ausgeführt, wenn diese bereits
über zehn andere Proxy-Server gegangen ist. In der Praxis ist die Wahrscheinlichkeit,
dass eine Anfrage über mehr als fünf Proxy-Server geleitet wird, sehr gering.
ProxyPass
Erlaubt die Einbindung externer Informationen in den lokalen Server.
Konfigurationsanweisung:
ProxyPass
Syntax:
ProxyPass URL-Pfad URL
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext,
Location-Container
Anweisung aktiv:
nein
Wenn Sie Inhalte externer Quellen in Ihre Internetseite einbinden möchten, können
Sie die ProxyPass-Anweisung benutzen. Diese Anweisung bindet externe Quellen in
die eigene Internetseite ein, so wie es mit mod_rewrite (vgl. RewriteRule-Anweisung)
möglich ist, und stellt diese Inhalte als eigene Inhalte bereit. Dabei erwartet die
Anweisung als ersten Parameter die lokale URL, unter der die durch den zweiten
Parameter definierte Internetseite erreichbar sein soll. Ein Beispiel:
ProxyPass /nachrichten http://www.spiegel.de
Durch diese Konfiguration ist der Inhalt der Internetseite http://www.spiegel.de unter
der lokalen Adresse /nachrichten (z.B. http://www.beispiel.de/nachrichten) erreichbar.
Sofern Sie Zugriffe auf Unterbereiche eines lokalen URL-Pfads, der externe Informationen einbindet, nicht an die externe Informationsquelle senden möchten, können
380
5 Konfiguration
Sie durch ein nachgestelltes Ausrufezeichen, welches die externe Adresse ersetzt, die
Einbindung einer externen Quelle verhindern:
ProxyPass /nachrichten/sport !
ProxyPass /nachrichten http://www.spiegel.de
Diese Anweisungen führen dazu, dass der Inhalt der Internetseite
http://www.spiegel.de unter dem lokalen URL-Pfad /nachrichten verfügbar ist, wobei
eine Anfrage für den URL-Pfad /nachrichten/sport nicht weitergegeben wird. Bitte
beachten Sie dabei, dass ein URL-Pfad, für den die Einbindung eines externen Inhaltes nicht gelten soll, vor der eigentlichen ProxyPass-Anweisung definiert werden
muss. Zusätzlich muss bei Verwendung der ProxyPass-Anweisung innerhalb eines
<Location>-Containers der lokale URL-Pfad weggelassen werden. Ein Beispiel:
<Location /nachrichten>
ProxyPass http://www.spiegel.de
</Location>
Diese Anweisungen sind mit den bereits vorgestellten Anweisungen identisch und
binden den Inhalt der Internetseite http://www.spiegel.de unter der lokalen Adresse
/nachrichten (z.B. http://www.beispiel.de/nachrichten) ein, wobei innerhalb der ProxyPass-Anweisung aufgrund des <Location>-Containers kein lokaler URL-Pfad mehr
definiert werden muss. Hinweis: Bei der Verwendung der ProxyPass-Anweisung
bezeichnet ein Forwardslash (»/«) das Wurzelverzeichnis einer Internetseite als lokalen URL-Pfad, so dass durch die folgende Anweisung der Inhalt der Internetseite des
Verlags als lokaler Inhalt eingebunden wird:
Hinweis
ProxyPass / http://www.addison-wesley.de
Die Einbindung externer Informationen bedarf der Genehmigung des Urhebers. Fragen Sie deshalb den Urheber und Inhaber einer von Ihnen eingebundenen Information schriftlich um Erlaubnis. Schalten Sie außerdem die ProxyRequests-Anweisung aus, wenn Sie die ProxyPass-Anweisung verwenden.
ProxyPassReverse
Korrigiert in Verbindung mit der ProxyPass-Anweisung bei der Einbindung von
externen Inhalten die Adressangabe innerhalb einer Um- bzw. Weiterleitung.
Konfigurationsanweisung:
ProxyPassReverse
Syntax:
ProxyPassReverse URL-Pfad URL
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext, <Location>Container, <Files>-Container, <Directory>-Container
Anweisung aktiv:
nein
5.4 Sonstige Module
381
Diese Konfigurationsanweisung korrigiert in einer selbstreferenzierenden Adresse
oder Um- bzw. Weiterleitung, die durch eine mit einer ProxyPass-Anweisung eingebundenen, externen Quelle erzeugt worden ist, den referenzierten Hostnamen und
schreibt diesen auf die eigene Adresse um. Dadurch ist es einem entfernten Client
nicht möglich, die Adresse einer extern eingebundenen Information herauszufinden.
Ein Beispiel:
ProxyPassReverse /nachrichten http://www.spiegel.de
Diese Anweisung bindet den Inhalt der Internetseite http://www.spiegel.de unter dem
lokalen URL-Pfad /nachrichten ein und ändert alle Referenzierungen (z.B. Umleitungen, Weiterleitungen, Links etc.) auf die eigene und lokale Adresse. Hinweis: Auch
die Nutzung von ProxyPassReverse in Verbindung mit mod_rewrite ist durchaus
denkbar, da die Verwendung der ProxyPassReverse-Anweisung nicht nur mit einer
ProxyPass-Anweisung möglich ist.
ProxyPreserveHost
ProxyPreserveHost gibt den HTTP-Header Host weiter.
Konfigurationsanweisung:
ProxyPreserveHost
Syntax:
ProxyPreserveHost On | Off
Standardwerte (Default):
ProxyPreserveHost Off
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Sofern aktiv, sorgt diese Anweisung dafür, dass statt des durch eine ProxyPassAnweisung definierten Hostnamens der HTTP-Header Host einer eingehenden
Anfrage an den zwischengeschalteten Host weitergereicht wird. Die Anweisung ist
normalerweise deaktiviert (Off).
ProxyReceiveBufferSize
Definiert die maximale Größe von HTTP- und FTP-Verbindungen, die durch
mod_proxy initiiert werden.
Konfigurationsanweisung:
ProxyReceiveBufferSize
Syntax:
ProxyReceiveBufferSize Bytes
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
382
5 Konfiguration
Diese Anweisung dient der Performancesteigerung und definiert eine feste Größe für
den Puffer von ausgehenden HTTP- und FTP-Verbindungen, die durch mod_proxy
durchgeführt werden. Der Wert dieses Puffers muss in Byte angegeben werden und
entweder größer als 512 oder gleich 0 sein. Der Wert 0 stellt die Standardeinstellung
des Systems dar und sollte in Zweifelsfällen verwendet werden. Ein Beispiel:
ProxyReceiveBufferSize 2048
Mit dieser Anweisung legen Sie den Maximalwert für ausgehende HTTP- bzw. FTPVerbindungen auf 2048 Byte fest.
ProxyRemote
Definiert einen übergeordneten Proxy-Server, den der lokale Server benutzen soll.
Konfigurationsanweisung:
ProxyRemote
Syntax:
ProxyRemote Muster Server
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Sofern der lokale Proxy-Server die Anfragen der Clients an einen übergeordneten
Proxy-Server schicken soll, können Sie die ProxyRemote-Anweisung benutzen. Diese
erwartet die Angabe eines Musters sowie des zugehörigen Proxy-Servers, der für das
Muster als übergeordneter Proxy fungiert. Als Muster kann entweder ein Protokoll,
eine partielle Adresse oder ein Jokerzeichen (»*«) dienen. Der entfernte Proxy-Server
muss unter Angabe eines Protokolls, eines Hostnamens sowie eines Ports (optional)
definiert werden, wobei momentan als Protokoll nur HTTP unterstützt wird. Ein Beispiel:
ProxyRemote http://www.beispiel.de http://www.firma.com
Durch diese Anweisung werden alle Anfragen für die Domain http://www.beispiel.de
an die Adresse http://www.firma.com weitergeleitet. Mit Hilfe des Jokerzeichens »*«
können auch alle eingehenden Anfragen an den übergeordneten Proxy-Server weitergereicht werden:
ProxyRemote * http://proxy.provider.net:8080
Mit dieser Anweisung werden alle eingehenden Anfragen an den Port 8080 der
Adresse proxy.provider.net weitergeleitet. Ein interessantes Beispiel zum Schluss:
ProxyRemote ftp http://ftp-proxy.provider.net:8080
Dieses abschließende Beispiel sorgt dafür, dass (passive) FTP-Anfragen als getarnte
HTTP-Anfragen an den Proxy-Server ftp-proxy.provider.net auf Port 8080 weitergelei-
5.4 Sonstige Module
383
tet werden, der derartige Anfragen verarbeiten kann. Hinweis: Wenn der übergeordnete Proxy-Server nicht verfügbar ist, versucht der Apache zunächst, die Anfrage
selbst durchzuführen, bevor der Client eine Fehlermeldung erhält.
ProxyTimeout
ProxyTimeout bestimmt die maximale Dauer einer Anfrage.
Konfigurationsanweisung:
ProxyTimeout
Syntax:
ProxyTimeout Sekunden
Standardwerte (Default):
ProxyTimeout 300
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die ProxyTimeout-Anweisung definiert die maximale Laufzeit einer Anfrage, bevor
eine Fehlermeldung an den Client geschickt wird. Sinn dieser Anweisung ist es, den
Client nach einer angemessenen Zeitspanne über die Nichterreichbarkeit eines entfernten Servers zu informieren, anstatt die Anfrage ins Leere laufen zu lassen. Die
Standardeinstellung lautet:
ProxyTimeout 300
Sollte die Verbindung zwischen dem lokalen Proxy-Server und einem entfernten Server nach fünf Minuten nicht zustande gekommen sein, erhält der Client eine Fehlermeldung. In der Praxis sind Verbindungen, gerade in Unternehmensnetzwerken, aufgrund der verfügbaren Übertragungsraten meist binnen Sekunden hergestellt, so
dass dieser Wert deutlich reduziert werden kann:
ProxyTimeout 60
Steht eine Verbindung zwischen dem Proxy-Server und dem entfernten Server nicht
nach einer Minute, erhält der anfragende Client eine entsprechende Fehlermeldung.
ProxyVia
Definiert die Angabe von Zwischenstationen einer Verbindung im HTTP-Header.
Konfigurationsanweisung:
ProxyVia
Syntax:
ProxyVia On | Off | Full | Block
Standardwerte (Default):
ProxyVia Off
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
384
5 Konfiguration
Die HTTP/1.1-Spezifikation führt den (optionalen) HTTP-Header Via ein, der Informationen über den Datenfluss einer Anfrage über verschiedene Proxy-Server enthalten kann. Dabei kann die ProxyVia-Anweisung einen der folgenden Parameter verwenden:
Off
Der Apache fügt dem HTTP-Header Via keinerlei Informationen hinzu, um so den
Fluss der Daten durch den lokalen Proxy-Server zu dokumentieren. Bereits vorhandene Angaben werden ungefiltert durchgereicht:
ProxyVia Off
Diese Einstellung ist neben dem Parameter Block am sinnvollsten und verbirgt mögliche Informationen über den Datenfluss einer Information.
On
Wenn Sie möchten, dass der Datenfluss durch den lokalen Proxy-Server im HTTPHeader Via mit dem Hostnamen und der entsprechenden HTTP-Version gekennzeichnet wird, müssen Sie den Parameter On verwenden:
ProxyVia On
Diese Anweisung fügt dem HTTP-Header einen entsprechenden Vermerk (Hostname
und HTTP-Version) hinzu, dass der lokale Proxy-Server am Datenfluss einer Information beteiligt war.
Full
Dieser Parameter ist funktional mit dem Parameter On identisch, fügt allerdings
neben dem Hostnamen und der HTTP-Version auch Informationen über den Namen
und die Versionsnummer (z.B. Apache/2.0.42) der verwendeten Software hinzu.
Sofern Sie dieses Verhalten wünschen, können Sie folgende Anweisung benutzen:
ProxyVia Full
Dem HTTP-Header Via werden in diesem Fall Informationen über die verwendete
HTTP-Version (z.B. 1.1), den lokalen Hostnamen (proxy.beispiel.de) sowie den Namen
und die Version der eingesetzten Software (Apache/2.0.42) hinzugefügt. Ich persönlich
bin der Meinung, dass der Reiseweg einer Information und der Zwischenstopp auf
unserem lokalen Proxy-Server niemanden etwas angeht, und rate dazu, den Parameter Off oder Block zu verwenden.
Block
Dieser Parameter entfernt aus jeder Anfrage den möglicherweise enthaltenen HTTPHeader Via und fügt keine neuen Informationen über den Datenfluss einer Information hinzu.
ProxyRequests
ProxyRequests schaltet die Verwendung von mod_proxy ein oder aus.
5.4 Sonstige Module
385
Konfigurationsanweisung:
ProxyRequests
Syntax:
ProxyRequests On | Off
Standardwerte (Default):
ProxyRequests Off
Enthalten in Modul:
mod_proxy
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Um die Proxy-Funktionalitäten des Apache nutzen zu können, müssen Sie diese mit
der ProxyRequests-Anweisung explizit einschalten. Standardmäßig sind diese Funktionen ausgeschaltet und müssen aktiviert werden:
Hinweis
ProxyRequests On
Sofern Sie nur die Inhalte eines externen Servers mit Hilfe einer ProxyPassAnweisung einbinden oder mod_rewrite zur Einbindung externer Inhalte verwenden, müssen Sie die Proxy-Funktionalitäten nicht explizit einschalten. Achtung: Sichern Sie den Zugriff auf Ihren Proxy-Server ab und erlauben Sie den
Zugriff nur durch einen engen Kreis von berechtigten Personen und/oder Systemen.
5.4.2
Auf den Client zugeschnittene Verarbeitung
(mod_negotiation)
Der Apache kann anhand von Daten, die der Client an den Server gesendet hat, Informationen in einem durch den Client gewünschten und akzeptierten Format übermitteln. Der Client sendet dabei Informationen über die von ihm gewünschten Datenformate, Spracheinstellungen, Zeichensätze sowie Codierung und der Apache liefert die
Variante einer Information an den Client, die am besten auf die Wünsche des Client
passt. Es findet praktisch eine Verhandlung über das Aussehen und das Format der
zu liefernden Daten statt. Dieser Vorgang wird Content Negotiation (engl. etwa:
Inhaltsverhandlung) genannt und wird durch das Modul mod_negotiation bereitgestellt. Dabei könnte ein Client die Sprache übermitteln, in der er gerne Informationen
erhalten würde:
AcceptLanguage: de
Der Client würde also die deutsche Sprache für Informationen beliebiger Art bevorzugen. Eine etwas komplexere Anfrage eines Clients könnte angeben, dass dieser
Informationen gerne in Deutsch erhalten würde, Englisch jedoch auch in Ordnung
wäre. Zusätzlich akzeptiert der Clients diverse Medientypen, bevorzugt dabei
HTML-Dateien vor einfachen Textdateien und .gif- oder .jpg-Bildateien vor anderen
Medienformaten. Jedes andere Format würde als letzter Ausweg ebenfalls akzeptiert:
Accept-Language: de; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6,
image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
386
5 Konfiguration
Um den Client eine speziell optimierte Variante der von ihm angeforderten Informationen zu senden, müssen Sie neben der Erstellung der verschiedenen Dateivarianten
eine so genannte Type-Map erstellen oder die MultiViews-Suche aktivieren.
Type-Maps
Eine Type-Map ist praktisch eine Datei, in der die verfügbaren Varianten einer Information aufgelistet werden. Über die Zuweisung des Handlers type-map zu einer
Dateiendung (meist .var für Variante) können Sie Type-Maps aktivieren:
AddHandler Type-Maps var
Wenn Sie eine derartige Anweisung in der globalen Serverkonfiguration vornehmen,
werden Dateien mit der Endung .var in allen Verzeichnissen des Webservers als
Type-Maps deklariert. Die Beschränkung auf bestimmte Verzeichnisse ist jedoch
sinnvoll:
<Location /daten>
AddHandler Type-Maps var
</Location>
MultiViews
Type-Maps sind sehr aufwendig, da zu jeder Datei, zu der eine Variante existiert, eine
entsprechende Type-Map erstellt werden muss. Eine Vereinfachung stellt dabei die
Verwendung von so genannten MultiViews da, die selbst nach einer vorhandenen
und geeigneten Variante einer Datei suchen. Sie können für ein bestimmtes Verzeichnis durch folgende Anweisungen die automatische Suche nach einer geeigneten Variante aktivieren:
Hinweis
<Location /daten>
Options +MultiViews
</Location>
Die Option MultiViews ist übrigens die einzige Option, die bei der Setzung des
Parameters ALL der Konfigurationsanweisung Options nicht gesetzt wird (vgl.
Erläuterungen zu Options)!
Wenn MultiViews aktiviert sind, sucht der Apache bei der Anforderung einer nicht
vorhandenen Datei nach gleichnamigen Dateien und erstellt eine Liste, die mit den
Präferenzen verglichen wird, die der Client übermittelt hat. Anhand der Übereinstimmungen zwischen gefundenen Dateiformaten und den bevorzugten Formaten des
Clients wird eine entsprechende Variante an den Client geliefert, sofern überhaupt
eine andere Variante vorhanden ist. Ist dies nicht der Fall, erhält der Client eine Fehlermeldung. Geeignet ist die MultiViews-Suche vor allen Dingen dann, wenn Dateien
in verschiedenen Sprachen angeboten werden, deren Dateiendung normalerweise
um das Sprachkürzel erweitert wird, damit der Apache anhand der Konfigurationsanweisung AddLanguage weiß, in welchen Sprachen eine Information vorliegt. Ein
5.4 Sonstige Module
387
Beispiel für ein Dokument in deutscher, englischer und französischer Sprache könnte
etwa so aussehen:
index.html.de
index.html.en
index.html.fr
Wenn durch einen Client keine spezielle Sprache angefordert worden ist, können Sie
mit der LanguagePriority-Anweisung eine Standardsprachvariante definieren, die in
einem solchen Fall an den Client gesendet wird.
Die nachfolgend erläuterten Konfigurationsanweisungen beziehen sich direkt und
indirekt auf die Verwendung von Informationsvarianten (Content Negotiation) mit
dem Apache. Dazu sind nicht alle vorgestellten Anweisungen im Modul
mod_negotiation enthalten, sondern entstammen teilweise auch aus dem Modul
mod_mime, welches ebenfalls sehr stark mit der Verwendung von Informationsvarianten (engl. content negotiation) verknüpft ist.
MultiViewsMatch
Definition der Dateitypen, die bei einer MultiViews-Suche beachtet werden sollen.
Konfigurationsanweisung:
MultiViewsMatch
Syntax:
MultiViewsMatch [NegotiatedOnly | Handlers | Filters |
Any]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Der Apache 2 beachtet im Gegensatz zu seinen Vorgängerversionen bei einer MultiViews-Suche nur solche Dateitypen, die ihm beispielsweise durch die Datei
mime.types aus dem Unterverzeichnis conf Ihrer Apache-Installation bekannt sind. Die
Standardeinstellung, die auch exakt dieses Verhalten auslöst, sieht folgendermaßen
aus:
MultiViewsMatch NegotiatedOnly
Wenn Sie zusätzlich die Auslieferung von Dateien wünschen, auf die sich Handler
und Filter beziehen (z.B. Dateien mit der Endung .cgi), können Sie dieses Verhalten
durch folgende Einstellung erreichen:
MultiViewsMatch Handlers Filters
388
5 Konfiguration
Dabei können Sie entweder beide Optionen Handlers und Filters, oder auch nur eine
Option angeben. Die jeweils kleinste Datei wird ausgewählt und an den Client gesendet.
Sollen alle Dateien in eine MultiViews-Suche einbezogen werden, können Sie folgende Anweisung vornehmen:
MultiViewsMatch Any
Dies ist das Verhalten des Apache in Version 1.3.x und eigentlich nicht sinnvoll, denn
es könnten Dateien an den Client geliefert werden, die dieser niemals sehen sollte
(wie z.B. Backupdateien o.ä.).
AddLanguage
Bekanntmachung von Sprachkürzeln für Datei- und Informationsvarianten.
Konfigurationsanweisung:
AddLanguage
Syntax:
AddLanguage Sprache Name [Name]
Standardwerte (Default):
AddLanguage de .de (mehrfach vorhanden)
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
ja
Mit dieser Konfigurationsoption können Sie Sprachkürzel für Informations- und
Dateivarianten laut ISO 639 definieren, wobei auch für eine Sprache mehrere Namen
angegeben werden können. Ein Beispiel:
AddLanguage de .de .deutsch
AddLanguage en .en
AddLanguage fr .fr
RemoveLanguage
Löschung eines Sprachkürzels für Datei- und Informationsvarianten.
Konfigurationsanweisung:
RemoveLanguage
Syntax:
RemoveLanguage Dateiendung [Dateiendung]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
5.4 Sonstige Module
389
Das Gegenstück zur Anweisung AddLanguage heißt RemoveLanguage und kann dazu
verwendet werden, Dateiendungen bekannter Sprachkürzel aus der Konfiguration
des Servers zu entfernen, wenn diese nicht mehr benötigt werden, oder bestimmte
Informationen beispielsweise in einem Verzeichnis nur noch in einigen Sprachvarianten zur Verfügung stehen (Einbindung über .htaccess-Dateien). Ein Beispielaufruf:
RemoveLanguage .de
LanguagePriority
Festlegung einer Standardsprachvariante für mehrsprachig vorhandene Informationen und Dateien.
Konfigurationsanweisung:
LanguagePriority
Syntax:
LanguagePriority Sprache [Sprachen]
Standardwerte (Default):
LanguagePriority en da nl et fr de el it ja ko no pl pt ptbr ltz ca es sv tw
Enthalten in Modul:
mod_negotiation
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
ja
Sie können durch diese Konfigurationsanweisung festlegen, in welcher Sprachvariante eine Information an den Client übermittelt werden soll, wenn dieser keine bevorzugte Spracheinstellung gesendet hat. Ein Beispiel:
LanguagePriority de en fr
In diesem Beispiel genießt die deutsche Sprache die höchste Priorität und es wird
zunächst versucht, eine deutschsprachige Variante an den Client zu liefern. Sollte
eine derartige Variante nicht vorhanden sein, wird versucht, die englischsprachige
und danach die französischsprachige Variante zu liefern, sofern diese vorhanden
sind. Hinweis: Sie können übrigens auch Varianten einer Sprache an die LanguagePriority-Anweisung übergeben:
LanguagePriority en-us en-gb de fr
Die verschiedenen deutschen Akzente sind leider noch nicht implementiert, aber
diese Anweisung würde zunächst versuchen, eine US-amerikanische Variante einer
Information zu finden (wahrscheinlich die zensierte Variante), danach die in britischem Englisch verfasste Variante und zum Schluss die deutsche und französische
Variante.
390
5 Konfiguration
ForceLanguagePriority
Bestimmt das Verhalten des Servers, wenn ein akzeptables Dokument nicht gefunden
werden konnte.
Konfigurationsanweisung:
ForceLanguagePriority
Syntax:
ForceLanguagePriority none | prefix | any | full
Standardwerte (Default):
ForceLanguagePriority Prefer Fallback
Enthalten in Modul:
mod_negotiation
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
ja
Falls der Server kein eindeutig mit den gewünschten Sprachvarianten des Clients
übereinstimmendes Dokument finden kann, wird die Konfigurationsanweisung LanguagePriority zur zufriedenstellenden Bewältigung einer Anfrage herangezogen. Es
stehen Ihnen dabei folgende Optionen zur Verfügung:
none:
Der Client erhält eine Fehlermeldung, dass das gewünschte Dokument nicht gefunden werden konnte, wenn die von ihm nachgefragte Version nicht existiert.
prefer:
Wenn dieser Parameter gesetzt ist, benutzt ForceLanguagePriority den Wert der LanguagePriority-Anweisung, falls mehrere Varianten einer Information vorhanden sind.
Damit wird verhindert, dass eine Auswahlliste mit möglichen Varianten an den
Client geliefert werden muss, woraus dieser die von ihm gewünschte Information
auswählen kann (HTTP-Statuscode 300, multiple choices). Folgendes Beispiel soll diesen Umstand kurz verdeutlichen:
LanguagePriority en fr de
ForceLanguagePriority Prefer
Sendet ein Client als gewünschte Sprache Englisch und Deutsch mit einer identischen
Priorität, wird die erste übereinstimmende Sprachvariante ausgewählt, d.h. in diesem Fall Englisch.
fallback
Ist dieser Parameter gesetzt, wird die Einstellung der Konfigurationsanweisung LanguagePriority benutzt, um keine Fehlermeldung der Art 406 (not acceptable, engl. etwa:
nicht akzeptierbar) auszulösen. Ein Beispiel:
LanguagePriority en fr de
ForceLanguagePriority Fallback
5.4 Sonstige Module
391
Wenn ein Benutzer als gewünschte Sprache eine Variante angibt, zu der kein passendes Dokument existiert (z.B. es für Spanisch), wird die Information in der ersten passende Sprache ausgeliefert, die durch die Anweisung LanguagePriority (z.B. en für
Englisch) vorher definiert worden ist.
Auch beide Parameter Prefer und Fallback können gemeinsam angegeben werden, so
dass zunächst versucht wird, gemäß dem Verhalten des Parameters Prefer die
gewünschten Informationen an den Client zu liefern. Schlägt dies fehl, wird gemäß
dem Verhalten des Parameters Fallback die erste passende Sprachvariante der durch
die Konfigurationsanweisung LanguagePriority definierten Liste ausgewählt und an
den Client geliefert.
CacheNegotiatedDocs
Erlaubt oder verbietet die Speicherung von Informationsvarianten durch Proxy-Server.
Konfigurationsanweisung:
CacheNegotiatedDocs
Syntax:
CacheNegotiatedDocs on | off
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_negotiation
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit dieser Option legen Sie fest, ob Informationen, von denen mehrere Varianten
existieren, durch so genannte Proxy-Server zwischengespeichert werden sollen, wenn
es sich bei der Anfrage um eine HTTP/1.0-Anfrage handelt. Wenn Sie das Speichern
durch Proxy-Server durch Angabe des Parameters on erlauben, kann es unter
Umständen passieren, dass ein Client eine Variante einer Information bekommt, die
er nicht haben möchte oder im schlimmsten Fall gar nicht verarbeiten kann. Da diese
Anweisung sich nur auf HTTP/1.0-Anfragen bezieht und inzwischen HTTP/1.1 weitest gehend verbreitet ist, sollten Sie diese Konfigurationsanweisung deaktivieren:
CacheNegotiatedDocs off
DefaultLanguage
Definiert eine Standardsprache für alle vorhandenen Dateien.
Konfigurationsanweisung:
DefaultLanguage
Syntax:
DefaultLanguage Sprache
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
392
5 Konfiguration
Diese Konfigurationsanweisung kann dazu benutzt werden, um alle in einem beliebigen Verzeichnis vorhandenen Dateien, deren Name kein Kürzel für die Sprachvariante der enthaltenen Informationen beinhaltet, einem bestimmten Dateientypen
zuzuordnen. Damit können Sie komplette Verzeichnisse beispielsweise als deutschsprachige Inhalte kennzeichnen, ohne dass Sie jede Datei manuell umbenennen müssen. Sie können jedoch die Dateien nur einer bestimmten Sprache zuordnen:
<Location /deutsch>
DefaultLanguage de
</Location>
Diese Anweisungen würden alle Dateien im Verzeichnis /deutsch als deutschsprachige Inhalte kennzeichnen, ohne dass die Dateinamen eine spezielle Erweiterung
benötigen. Hinweis: Verwenden Sie diese Konfigurationsoption nicht in der globalen
Serverkonfiguration (respektive VirtualHost-Konfiguration), da der Hauptserver
auch Dateien enthalten könnte, deren Inhalte in anderen Sprachen vorhanden sind als
angegeben oder solche Dateien, die überhaupt keine Sprachvariante definieren. Nutzen Sie deshalb lieber eine <Location>-, <LocationMatch>- oder <Directory>-Anweisung, um eine Standardsprache für alle vorhandenen Dateien zu definieren.
AddCharset
Bildet eine Dateinamenerweiterung auf einen speziellen Zeichensatz ab.
Konfigurationsanweisung:
AddCharset
Syntax:
AddCharset Zeichensatz Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
AddCharset ISO-8859-1 .iso8859-1 .latin1 (mehrfach
vorhanden)
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Die Konfigurationsanweisung AddCharset bildet eine Erweiterung eines Dateinamens
auf einen bestimmten Zeichensatz ab, der in diesen Dateien enthalten ist. Ein Beispiel
dafür könnten etwa Dokumente in japanischer Sprache sein, für die verschiedene
Zeichensätze existieren:
AddLanguage ja .ja
AddCharset EUC-JP .euc
AddCharset ISO-2022-JP .jis
AddCharset SHIFT_JIS .sjis
Ein Dokument namens xxxx.ja.jis würde in diesem Fall als Dokument in japanischer
Sprache bekannt sein, deren Zeichensatz ISO-2002-JP lautet. Die AddCharset-Option
5.4 Sonstige Module
393
ist hilfreich, um dem Client mitzuteilen, in welchem Zeichensatz eine Information
vorliegt, und dient außerdem dazu, dem Server die Auswahl einer geeigneten Informationsvariante zu erleichtern. Die Namenserweiterung kann entweder mit oder
ohne einen führenden Punkt angegeben werden. Deshalb sind folgende Anweisungen identisch und richtig:
AddCharset EUC-JP .euc
AddCharset EUC-JP euc
RemoveCharset
Entfernt alle vorhandenen Zeichensatzeinstellungen für einen angegebenen Dateitypen.
Konfigurationsanweisung:
RemoveCharset
Syntax:
RemoveCharset Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Mit dieser Konfigurationsoption können Sie alle vorhandenen Zeichensatzeinstellungen für Dateien eines gegebenen Typs deaktivieren. Wenn Sie beispielsweise alle Zeichensatzeinstellungen für die Dateitypen mit der Endung .html und .shtml deaktivieren möchten, können Sie folgende Anweisung benutzen:
RemoveCharset .html .shtml
5.4.3
Einfügen von definierten Inhalten in
Antwortseiten (mod_injection)
Ich möchte in diesem Kapitel am Beispiel des Moduls mod_injection vorstellen, wie
man ein Modul nachträglich in den Apache 2 integriert. Das vorgestellte Modul arbeitet als Ausgabefilter und erlaubt es Ihnen, beliebigen Text dynamisch in eine .htmlDatei einzufügen und somit beispielsweise automatisiert einen Werbebanner einzublenden. Die Homepage des Moduls von Peter Jones lautet http://pmade.org/pjones/
software/mod_injection/ und die Dokumentation finden Sie unter http://pmade.org/
pjones/software/mod_injection/documentation.html (diverse Formate verfügbar, u.a.
HTML- und PDF-Format).
394
5 Konfiguration
Installation
Laden Sie sich die aktuelle Version (0.3.1) von mod_injection von http://pmade.org/
pjones/software/mod_injection/download.html (10 KB) herunter und entpacken Sie es
durch Eingabe von
# tar xvzf mod_injection-0.3.1.tar.gz
Wechseln Sie in das neu entstandene Verzeichnis mod_injection-0.3.1 und führen Sie
dort folgenden Befehl aus:
Hinweis
# make APXS=/usr/local/apache2/bin/axps
Sie müssen den Pfad zum Programm apxs, welches sich im Unterverzeichnis bin
Ihrer lokalen Apache-Installation (z.B. /usr/local/apache2/bin/apxs) befindet, unter
Umständen anpassen. Außerdem müssen Sie das Schlüsselwort APXS unbedingt in Großbuchstaben angeben.
Sobald dieser Befehl abgeschlossen ist, können Sie das Modul in das Unterverzeichnis
modules der lokalen Apache-Installation (z.B. /usr/local/apache2/modules) installieren:
# make install
Fügen Sie außerdem zur Aktivierung des Moduls folgende Zeile der zentralen Konfigurationsdatei httpd.conf des Apache hinzu:
LoadModule injection_module modules/mod_injection.so
Hinweis
Speichern Sie die Änderungen an der Datei und schließen Sie damit die Installation
von mod_injection ab. Sobald Sie den Apache neu starten, steht Ihnen die Funktionalität von mod_injection in vollem Maße zur Verfügung.
Der Installationsvorgang unterscheidet sich oft zwischen den einzelnen Drittanbietermodulen und es lässt sich leider keine definitive Anleitung erstellen, die
für die Installation jedes beliebigen Drittanbietermoduls passt. Vor der Installation eines Drittanbietermoduls sollten Sie die Dokumentation konsultieren, um
dort Informationen über den Installationsvorgang zu erhalten. Die meisten
Module lassen sich nach dem Entpacken durch folgenden Befehl kompilieren:
# make
Nachdem die Kompilierung abgeschlossen ist, erfolgt bei manchen Module (siehe
mod_injection) die Installation durch Eingabe von
# make install
Es gibt allerdings auch Module, bei denen Sie nach der Kompilierung durch folgenden Befehl die entsprechende Datei selbst erzeugen müssen:
# /usr/local/apache2/bin/apxs -i -a -n beispielmodul libmodbeispiel.la
Achtung
5.4 Sonstige Module
395
Der Pfad zum Programm apxs, welches sich normalerweise im Unterverzeichnis
bin der lokalen Apache-Installation (z.B. /usr/local/apache2/bin/apxs) befindet,
muss gegebenenfalls angepasst werden. Der Befehl erzeugt mit Hilfe des Programms apxs aus der kompilierten Datei libmodbeispiel.la das entsprechende
Shared Object (.so), kopiert dieses in das Unterverzeichnis modules der lokalen
Apache-Installation (hier: /usr/local/apache2/modules) und bindet das Modul mit
dem Namen beispielmodul in die Konfigurationsdatei des Apache (hier:
/usr/local/apache2/conf/httpd.conf) ein.
Da ich Ihnen also keine Universallösung präsentieren kann, möchte ich Sie bitten, im
Zweifelsfall die Dokumentation des Moduls zu konsultieren.
Konfiguration
Damit der Ausgabefilter überhaupt aktiviert wird, müssen Sie in der Konfigurationsdatei des Apache beispielsweise folgende Anweisung hinzufügen:
AddOutputFilter INJECTION .html
Die Konfiguration würde den Filter Injection für alle Dateien mit der Endung .html
aktivieren. Alternativ können Sie auch folgende Anweisungen benutzen, um die
Funktion von mod_injection auf ein Verzeichnis zu begrenzen:
<Location /daten>
SetOutputFilter INJECTION
InjectString "<h1>Automatisch eingefügter Text</h1>"
</Location>
Mit Hilfe dieser Konfiguration wäre die Funktion von mod_injection auf das Verzeichnis /daten beschränkt. Allgemein werden durch den Ausgabefilter mod_injection
die folgenden fünf Konfigurationsanweisungen bereitgestellt, die Sie innerhalb eines
begrenzenden Containers (z.B. <Location> oder <Directory>) verwenden sollten:
InjectTag
InjectTag definiert einen Schlüsselpunkt zur automatischen Einfügung von Text.
Anweisung:
InjectTag
Syntax:
InjectTag Zeichenkette
Standardwerte (Default):
InjectTag body
Enthalten in Modul:
mod_injection
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, .htaccess-Kontext
Anweisung aktiv:
nein
Damit mod_injection weiß, an welcher Stelle der Zieldatei eine Zeichenkette einzufügen ist, gibt es die InjectTag-Anweisung. Diese setzt den Schlüsselpunkt, nach dem
396
5 Konfiguration
die durch die InjectString- oder InjectURI-Anweisung definierten Informationen eingefügt werden sollen. Ein Beispiel:
InjectTag body
Die Konfiguration sorgt dafür, dass alle durch mod_injection in die Zieldatei eingefügten Informationen nach dem ersten Vorkommen des HTML-Tag <body> erscheinen (Standardeinstellung). Hinweis: Wenn Sie die InjectTag-Anweisung verwenden,
können Sie die InjectAfter-Anweisung nicht im selben Kontext verwenden.
InjectAfter
InjectAfter definiert ein Suchwort zur automatischen Einfügung von Text.
Anweisung:
InjectAfter
Syntax:
InjectAfter Suchwort
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_injection
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, .htaccess-Kontext
Anweisung aktiv:
nein
Mit der InjectAfter-Anweisung können Sie ein Suchwort definieren, welches in der Zieldatei gesucht wird und nach dessen Fundstelle die durch die InjectString- oder InjectURI-Anweisung definierten Informationen eingefügt werden sollen. Ein Beispiel:
InjectAfter "<!-- Kommentar --!>"
Diese Anweisung bewirkt, dass durch mod_injection in der Zieldatei nach der Zeichenkette <!-- Kommentar --!> gesucht wird und die durch die InjectString- oder InjectURI-Anweisung definierten Informationen nach dem ersten Auffinden dieser Zeichenkette eingefügt werden. Hinweis: Wenn Sie die InjectAfter-Anweisung
verwenden, können Sie die InjectTag-Anweisung nicht im selben Kontext verwenden.
InjectString
InjectString fügt nach dem Schlüsselpunkt eine beliebige Zeichenkette ein.
Anweisung:
InjectString
Syntax:
InjectString Zeichenkette
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_injection
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, .htaccess-Kontext
Anweisung aktiv:
nein
5.4 Sonstige Module
397
Mit Hilfe der Konfigurationsanweisung InjectString können Sie eine beliebige Zeichenkette (z.B. HTML-Befehle) in eine .html-Datei einfügen, wobei der eingefügte
Text in der Zieldatei immer nach dem durch die InjectTag-Anweisung definierten
Schlüsselpunkt erscheint. Die Anweisung erwartet nur die Angabe einer Zeichenkette
beliebiger Länge, die jedoch in Anführungszeichen eingeschlossen werden muss. Ein
Beispiel:
InjectString "<h1>Eingefügter Text</h1>"
Diese Anweisung würde dafür sorgen, dass die Zeichenkette <h1>Eingefügter
Text</h1> nach dem Schlüsselpunkt (vgl. InjectTag- oder InjectAfter-Anweisung) eingefügt wird. Wenn Sie HTML-Befehle einfügen möchten, sollten Sie die Anführungszeichen innerhalb dieser Befehle durch einfache Hochkommata ersetzen und eventuell mit Zeilenumbrüchen arbeiten, wie folgendes Beispiel veranschaulicht:
InjectString "<h1><b><font size='3' color='#FF0000'>&lt;Werbung&gt; Kaufen Sie \
dieses Buch, denn es ist mit 44,95 &euro; noch viel zu billig :- ) \
&lt;/Werbung&gt;</font></b></h1>"
Die Startseite des Apache sieht nach einem Neustart etwas anders aus:
Abbildung 5.6 Willkommensseite des Apache mit automatisch eingefügter Werbung
Die InjectString-Anweisung könnte beispielsweise für solche Anbieter interessant
sein, die kostenlosen Speicherplatz (sog. Webspace) auf ihrem Server für die Kunden
anbieten und bei jedem Aufruf einer Startseite eine Zwangswerbung einblenden
möchten. Hinweis: Wenn Sie die InjectString-Anweisung verwenden, können Sie die
InjectURI-Anweisung nicht im selben Kontext verwenden.
InjectURI
InjectURI fügt nach dem Schlüsselpunkt eine beliebige URI ein.
Anweisung:
InjectURI
Syntax:
InjectURI URI
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_injection
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, .htaccess-Kontext
Anweisung aktiv:
nein
398
5 Konfiguration
Mit der InjectURI-Anweisung können Sie nach dem Schlüsselpunkt (vgl. InjectTagoder InjectAfter-Anweisung) eine beliebige URI einbinden. Dazu folgendes Beispiel:
InjectURI /kontakt.html
Durch eine derartige Konfiguration würde die Datei /kontakt.html nach dem Schlüsselpunkt eingebunden. Hinweis: Bei Verwendung der InjectURI-Anweisung können
Sie die InjectString-Anweisung nicht im selben Kontext verwenden.
InjectType
InjectType ordnet den Ausgabefilter Injection einem bestimmten MIME-Typen zu.
Anweisung:
InjectType
Syntax:
InjectType MIME-Typ
Standardwerte (Default):
InjectType text/html
Enthalten in Modul:
mod_injection
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, .htaccess-Kontext
Anweisung aktiv:
nein
Die letzte durch mod_injection bereitgestellte Anweisung ordnet einem bestimmten
MIME-Typen den Ausgabefilter zu, wobei auch die Verwendung von shellartigen
Jokerzeichen (»*«) möglich ist.
5.4.4
Der Umgang mit verschiedenen Dateitypen
(mod_mime)
Der Apache kann Informationen prinzipiell in beliebigen Dateiformaten veröffentlichen und sendet dem Client eine Information über den Typ einer Datei, wenn dieser
eine Anfrage sendet. Anhand dieser Information weiß der Client, um welche Art es
sich bei der nachgefragten Information handelt (z.B. Bild- oder Videodatei) und kann
entsprechend mit den Informationen arbeiten. Dabei versucht der Apache mit Hilfe
von mod_mime, anhand des Namens einer Datei bzw. deren Endung, den MIME-Typ,
die Sprache, den Zeichensatz und die Kodierung für diese automatisch zu bestimmen
und an den Client zu liefern. Diese Informationen werden teilweise durch
mod_negotiation ausgewertet bzw. verwendet, um dem Client eine Informationsvariante zu liefern, die mit seinen persönlichen Format- und Dateitypvorstellungen optimal übereinstimmt.
Dabei bestimmen die Konfigurationsanweisungen AddCharset, AddEncoding, AddLanguage und AddType den Zeichensatz, die Sprache und den MIME-Typ eines Dokumentes. Die Option TypesConfig gibt den Speicherort der Datei mime.types an, in der
die verschiedenen MIME-Typen mit den entsprechenden Dateiendungen gespeichert
sind.
5.4 Sonstige Module
399
Hinweis
Zusätzlich kann mod_mime Dateihandler und Filter definieren, die Informationen
liefern oder verarbeiten können. Dabei kontrollieren die Anweisungen AddHandler,
AddOutputFilter und AddInputFilter die Module und Skripte, die ein Dokument zur
Verfügung stellen. Lesen Sie zur Verwendung von Ein- und Ausgabefiltern bitte auch
das entsprechende Kapitel in diesem Buch. Die Anweisung MultiViewsMatch ermöglicht es mod_negotiation, diese Dateien in MultiView-Suchen zu berücksichtigen.
Einige der durch mod_mime bereitgestellten Direktiven habe ich bereits in den
Erläuterungen über Content Negotiation aufgelistet und erklärt, da diese nur in
Verbindung mit mod_negotiation wirklich Sinn machen. Dazu gehören u.a. die
Konfigurationsanweisungen AddCharset, AddEncoding, AddLanguage und AddType.
Des Weiteren können die Einstellungen von mod_mime durch das Kernmodul des
Apache (mod_core) unter gewissen Umständen überschrieben werden, lesen Sie deshalb die Erläuterungen zu ForceType, SetHandler, SetInputFilter und SetOutputFilter.
Bitte beachten Sie außerdem, dass die Veränderung von Meta-Informationen für eine
Datei (z.B. Sprache, Kodierung, Zeichensatz) das letzte Bearbeitungsdatum einer
Datei (engl. Last-Modified) nicht verändert. Dies führt dazu, dass im Speicher des
Clients gegebenenfalls noch ältere Varianten einer Information vorhanden sein könnten. Sie müssen deshalb das Bearbeitungsdatum einer Datei verändern, um den Client
auf die inhaltliche Veränderung einer Information hinzuweisen. Wenn Sie die Datei
selbst nicht ändern können oder möchten, können Sie unter Unix/Linux den Befehl
touch zur Veränderung des Bearbeitungsdatums einer Datei benutzen.
Sollte eine Datei mehrere Endungen haben (z.B. index.html.de oder index.de.html) wird
diese normalerweise automatisch mit den entsprechenden Dateitypinformationen
versehen und an den Client ausgeliefert. Wenn ein Dateiname mehrere potenzielle
MIME-Typen enthält (z.B. index.gif.html), wird als Dateityp immer der zuletzt
genannte Typ benutzt, d.h. in diesem Fall text/html.
Zusätzlich können Sie neben dem MIME-Typ auch eine Komprimierung oder eine
Verschlüsselung für eine Datei definieren. Dabei wird ein zusätzlicher HTTP-Header
namens Content-Encoding gesendet, der über das Vorhandensein einer zusätzlichen
Enkodierung (z.B. Verschlüsselung oder Komprimierung) informiert und Informationen darüber enthält, welche Dekodierungstechniken benutzt werden müssen, um
eine Datei wieder in das ursprüngliche Dateiformat zu bringen und damit lesbar zu
machen. Wenn Sie beispielsweise ein in Microsoft Word geschriebenes Dokument
(Dateiendung: .doc) mit einem Programm wie WinZip komprimieren (Dateiendung
.zip), würde eine Datei namens beispiel.doc.zip als eine durch das Programm WinZip
(oder Ähnliches) komprimierte Worddatei erkannt werden.
AddEncoding
AddEncoding ordnet eine Dateiendung einer speziellen Enkodierungsform (z.B. Komprimierung) zu.
400
5 Konfiguration
Konfigurationsanweisung:
AddEncoding
Syntax:
AddEncoding Mime-Typ Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
AddEncoding x-compress Z (mehrfach vorhanden)
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container,<Location>-Container,
<Files>-Container
Anweisung aktiv:
ja
Die Konfigurationsanweisung AddEncoding ordnet einer Dateiendung eine Kodierungsform zu, wie folgende Beispiele veranschaulichen:
AddEncoding x-gzip .gz
AddEncoding x-compress .Z
Diese Anweisungen markieren Dateien mit der Namenserweiterung .gz sowie .Z und
definieren für diese Dateitypen den Enkodierungstypen x-gzip und x-compress. Eine
Dekodierungsform sollte immer mit der Zeichenkette x- beginnen, wobei neuere
Dekodierungformen (z.B. deflate) inzwischen ohne dieses Kennzeichen benutzt werden können. Ebenso ist die Angabe eines Punkts vor dem Dateinamen optional und
muss nicht vorgenommen werden. Deshalb sind folgende Anweisungen mit dem
bereits vorgestellten Beispiel funktional identisch:
AddEncoding x-gzip gz
AddEncoding x-compress Z
AddHandler
Zuordnung einer Dateiendung zu einem bestimmten Handler.
Konfigurationsanweisung:
AddHandler
Syntax:
AddHandler Handler-Name Erweiterung [ Erweiterung ]
Standardwerte (Default):
#AddHandler cgi-script .cgi (mehrfach vorhanden)
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein (auskommentiert)
Die AddHandler-Option weist einer Dateiendung einen Handler zu und überschreibt
damit eventuell bereits vorhandene Zuweisungen für den jeweiligen Dateityp. Als
Parameter erwartet die Option die Angabe eines internen Handlers oder eines Handlers, der zuvor durch eine Action-Anweisung definiert worden ist, gefolgt von einer
Dateiendung, für die dieser Handler gelten soll.
5.4 Sonstige Module
401
Wenn Sie beispielsweise CGI-Skripte mit der Dateiendung .cgi nutzen möchten,
könnten Sie folgende Anweisung verwenden, um Dateien mit einer derartigen
Endung als CGI-Skripte zu betrachten:
AddHandler cgi-script .cgi
Auch hier ist die Angabe des führenden Punkts vor dem Dateinamen optional. Folgende Anweisung ist deshalb mit dem vorherigen Beispiel identisch:
AddHandler cgi-script cgi
Mit einer solchen Anweisung werden alle Dateien mit der Endung .cgi als CGISkripte betrachtet und ausgeführt, sofern die entsprechenden Berechtigungen vorhanden sind und für das jeweilige Verzeichnis die Option ExecCGI gesetzt ist. Dabei
muss es sich allerdings nicht ausschließlich um das Verzeichnis cgi-bin handeln, auch
jedes andere Verzeichnis ist möglich.
Sollten Sie Content Negotiation benutzen, wird in Ihrer Konfigurationsdatei des Apache wahrscheinlich folgende Zeile vorhanden sein:
AddHandler type-map var
Diese Zeile definiert den Handler type-map für Dateien mit der Endung .var (z.B.
index.html.var) und sorgt so dafür, dass der Apache alle Dateien mit dieser Endung als
Informationsvarianten betrachtet. Somit kann der Apache dem Client die von ihm
gewünschte Variante liefern (vgl. Content Negotiation und mod_negotiation).
Ein praktischer Einsatzzweck einer AddHandler-Anweisung wäre etwa die automatische Veränderung von statischen Informationen durch ein CGI-Skript. Dazu könnten
wir etwa folgendes CGI-Skript namens fussnote.pl entwickeln:
#!/usr/bin/perl -w
# Welches Dokument hatte der Client urspruenglich angefordert?
$orginal_dokument = $ENV{'PATH_TRANSLATED'};
# Bevor wir eine Ausgabe an den Client senden, muessen
# wir zunaechst definieren, um welche Art von
# Information es sich handelt. Wenn wir dies nicht tun,
# gibt es eine Fehlermeldung (Internal Server Error).
print "Content-type: text/html\n\n";
# Den vollen Pfad der urspruenglich angeforderten Datei
# lassen wir in der modifizierten Datei in fetter
# Schrift anzeigen.
print "Orginal: <B>$orginal_dokument</B>";
# Nun oeffnen wir die urspruenglich angeforderte Datei
# und geben diese aus.
open(Datei,"$orginal_dokument") or die "Konnte Eingabedatei nicht oeffnen!\n";
while(<Datei>) {
402
5 Konfiguration
# Waehrend Daten aus der Datei kommen, einfach
# ausgeben.
print $_;
}
# Wenn wir fertig sind, die Datei schliessen.
close(Datei);
# Jetzt unsere Fussnote beifuegen.
print "<BR>";
print "Dies ist eine automatisch eingefuegte\n";
print "Fussnote. (C) 2002 by Fritzchen Mueller\n";
print "<BR>Kontakt: ";
print "<a \ href='mailto:info\@beispiel.de'>info\@beispiel.de</a>\n";
Listing 5.5 Beispielprogramm (in Perl) zur automatischen Hinzufügung einer Fußnote
Das Perl-Skript bestimmt zuerst anhand der Umgebungsvariablen PATH_TRANSLATED die Datei, die der Client ursprünglich angefordert hat, und weist der Variablen
$orginal_dokument diesen Dateinamen zu. Bevor Daten an den Client geschickt werden,
wird dieser über die Art der Daten (text/html) informiert, die nun folgen werden. Dies
geschieht durch folgenden Befehl:
print "Content-Type: text/html\n\n";
Der Befehl signalisiert dem Client, dass die nachfolgenden Daten vom Typ text/html
sind. Hinweis: Sie müssen einen derartigen Befehl in jedem CGI-Skript vor der ersten
Ausgabe von Daten an den Client aufrufen, da Sie ansonsten eine Fehlermeldung
(z.B. »internal server error«) erhalten.
Unser selbst entwickeltes Skript gibt als Nächstes den Namen des ursprünglich angeforderten Dokuments aus und versucht diese Datei zu öffnen. Sobald die Datei geöffnet ist, wird sie Zeile für Zeile ausgegeben und wieder geschlossen. Danach erfolgt
die Ausgabe unserer Fußnote, die das Skript gleichzeitig auch beendet.
Speichern Sie das Skript in Ihrem cgi-bin-Verzeichnis (z.B. /usr/local/apache2/cgi-bin)
und setzen Sie die Berechtigungen korrekt:
# chmod 755 /usr/local/apache2/cgi-bin/fussnote.pl
Unter Umständen müssen Sie den Verzeichnispfad gemäß Ihrer lokalen Installation
anpassen. In den meisten Fällen sollte das Skript jedoch ohne Änderungen funktionieren. Fügen Sie außerdem folgende Zeilen in die Konfigurationsdatei httpd.conf des
Apache ein:
Action fussnote /cgi-bin/fussnote.pl
AddHandler fussnote .html .htm
Starten Sie den Apache neu und rufen Sie eine Datei mit der Endung .html oder .htm
auf. Dies könnte etwa die nach der Installation standardmäßig vorhandene Startseite
des Apache sein, die sich durch unser Skript leicht verändert:
5.4 Sonstige Module
403
Abbildung 5.7 Willkommensseite des Apache 2 inklusive eingefügter Kopfzeile
Das Skript hat wie erwartet den vollen Dateipfad des ursprünglich angeforderten
Dokumentes sowie unsere individuelle Fußnote der .html-Datei beigefügt.
AddInputFilter
Zuordnung von Dateierweiterungen zu externen Filtern, die Clientanfragen verarbeiten.
Konfigurationsanweisung:
AddInputFilter
Syntax:
AddInputFilter Filter Erweiterung [ Erweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
Nein
Mit Hilfe der Anweisung AddInputFilter definieren Sie einen Eingabefilter, der aktiv
wird, wenn ein Client Daten durch eine POST-Anfrage an den Server sendet. Sofern
der Dateityp mit einem der durch die Option AddInputFilter definierten Dateitypen
übereinstimmt, wird der Filter auf diese Daten angewendet. Ein Beispiel:
AddInputFilter virenscanner exe
Die Konfigurationsanweisung erwartet demnach den Namen eines Eingabefilters
sowie eines Dateityps, auf die dieser Filter angewendet werden soll. Es können
sowohl mehrere Filter als auch mehrere Dateitypen angegeben werden, auf die ein
(oder auch mehrere) Filter angewendet werden sollen. Wenn der Filter virenscanner
404
5 Konfiguration
nicht nur für die Dateiendung .exe, sondern auch für die ebenfalls potenziell gefährlichen Endungen .vbs, .com, .zip und .doc gelten soll, ist folgende Anweisung denkbar:
AddInputFilter virenscanner exe com zip doc vbs
Auch die Anwendung mehrerer Filter auf bestimmte Dateitypen ist möglich. Diese
müssen durch Semikolon voneinander getrennt werden und werden in der Reihe
ihrer Angabe ausgeführt:
AddInputFilter virenscanner;contentfilter doc vbs
Die Groß- und Kleinschreibung ist unerheblich, in diesem Beispiel würde zunächst
der Filter virenscanner und danach der Filter contentfilter für die Dateitypen .doc und
.vbs ausgeführt. Sind AddInputFilter-Anweisungen in .htaccess-Dateien vorhanden,
werden diese zuletzt ausgeführt, da sie die niedrigste Priorität besitzen. Weitere
Informationen zur Verwendung von Ein- und Ausgabefiltern finden Sie im Handbuch des Apache (http://httpd.apache.org/docs-2.0/) sowie im Verlauf dieses Buches.
AddOutputFilter
Zuordnung von Dateierweiterungen zu externen Filtern, die die Antworten des Servers verarbeiten.
Konfigurationsanweisung:
AddOutputFilter
Syntax:
AddOutputFilter Filter Erweiterung [ Erweiterung ]
Standardwerte (Default):
#AddOutputFilter INCLUDES .shtml (mehrfach vorhanden)
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
ja (teilweise auskommentiert)
Die Anweisung AddOutputFilter ordnet Dateitypen mit einer bestimmten Endung
einem Filter zu, der die Antworten des Servers verarbeitet und gegebenenfalls verändern kann, bevor diese an den Client gesendet werden. Dabei ist die Angabe eines
oder auch mehrerer Filter möglich, die die Antwort des Servers verarbeiten können,
bevor die Daten an den Client gesendet werden. Ein Beispiel:
AddOutputFilter deflate .html
Diese Anweisung würde alle Dateien mit der Endung .html vor der Übertragung an
den Client mit Hilfe des Moduls mod_deflate komprimieren. Die durch AddOutputFilter definierten Filter überschreiben nicht bereits vorhandene Filter, die beispielsweise durch die Anweisung SetOutFilter definiert worden sind, sondern werden
zusätzlich zu den bereits bestehenden Filtern verarbeitet. Die Groß- und Kleinschreibung ist auch hier irrelevant, ebenso wie die Angabe eines führenden Punktes vor
5.4 Sonstige Module
405
dem Dateinamen, d.h. folgende Anweisung ist mit dem bereits genannten Beispiel
identisch:
AddOutputFilter deflate html
Wenn Sie mehrere Filter anwenden möchten, müssen Sie diese Filter durch Semikolon trennen, wobei die Filter nacheinander und in der Reihe ihrer Angabe abgearbeitet werden:
AddOutputFilter includes;deflate shtml
Dieses Beispiel sorgt dafür, dass alle Dateien mit der Endung .shtml als Server-Side
Includes betrachtet werden und danach mit mod_deflate komprimiert werden. Weitere
Informationen zur Verwendung von Ein- und Ausgabefiltern finden Sie im Handbuch des Apache (http://httpd.apache.org/docs-2.0/) sowie im Verlauf dieses Buches.
AddType
AddType ordnet eine Dateiendung einem MIME-Typ zu.
Konfigurationsanweisung:
AddType
Syntax:
AddType Mime-Typ Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
AddType application/x-tar .tgz
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
ja
Die AddType-Anweisung ordnet einer Dateiendung einen bestimmten MIME-Typ zu.
Dabei werden bereits bestehende Zuordnungen für eine gleichnamige Dateiendung
überschrieben, sofern solche überhaupt existieren. Im Allgemeinen kann und sollte
die Option dazu verwendet werden, nicht bekannte Zuordnungen zur Serverkonfiguration hinzuzufügen, die nicht bereits in der Datei mime.types aufgeführt sind (vgl.
TypesConfig-Anweisung). Ein Beispiel:
AddType image/gif .gif
Bei der Dateinamenserweiterung ist die Groß- und Kleinschreibung unerheblich,
auch der vorangestellte Punkt kann weggelassen werden. Insofern ist der folgende
Aufruf mit dem vorgestellten Beispiel identisch:
AddType image/gif gif
Sie können auch mehrere Dateinamenserweiterungen für einen MIME-Typ definieren, die alle durch Leerzeichen voneinander getrennt sein müssen:
AddType image/jpeg jpg jpeg jpe
406
5 Konfiguration
RemoveEncoding
RemoveEncoding entfernt jegliche Art von Enkodierungseinstellungen für eine
bestimmte Dateierweiterung.
Konfigurationsanweisung:
RemoveEncoding
Syntax:
RemoveEncoding Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Durch Verwendung der Konfigurationsanweisung RemoveEncoding können Sie den
mit einem bestimmten Dateiformat assoziierten Enkodierungstyp entfernen, wobei
die Anweisung RemoveEncoding die Option AddEncoding immer überschreibt, da diese
zeitlich nacheinander ausgeführt werden. Dabei ist die Groß- und Kleinschreibung
des Dateityps unerheblich, ebenso wie die Angabe eines führenden Punktes vor der
Dateiendung.
Ein mögliches Anwendungsbeispiel wäre die Verwendung der Anweisung RemoveEncoding in einer .htaccess-Datei:
AddEncoding x-gzip .gz
AddType text/plain .asc
<Files *.gz.asc>
RemoveEncoding .gz
</Files>
Zunächst wird ein Kodierungtyp für alle Dateien mit der Endung .gz sowie für alle
Dateien mit der Endung .asc definiert. Danach wird diese Kodierung für alle Dateien
mit der Endung .gz.asc wieder entfernt.
RemoveHandler
RemoveHandler entfernt jeden Handler für eine bestimmte Dateierweiterung.
Konfigurationsanweisung:
RemoveHandler
Syntax:
RemoveHandler Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
5.4 Sonstige Module
407
Unter Umständen kann es nötig sein, in übergeordneten Verzeichnissen vorgenommene Definitionen von Handlern für einige Dateitypen zu entfernen, bzw. für
bestimmte Dateien aufzuheben. Gerade in .htaccess-Dateien und <Directory>- sowie
<Location>-Anweisungen könnte diese Option zum Einsatz kommen, wobei die
Groß- und Kleinschreibung nicht beachtet wird und auch die Angabe eines führenden Punktes in der Dateinamenserweiterung optional ist. Wenn Sie beispielsweise ein
Verzeichnis namens /includes erstellt haben, in dem Sie Ihre Server-Side Includes
gespeichert haben, könnten Sie die folgenden Anweisungen benutzen, um diese Definition für das Unterverzeichnis downloads zu deaktivieren:
AddHandler server-parsed .shtml
<Location /includes/downloads>
RemoveHandler .shtml
</Location>
Dateien mit der Endung .shtml werden im Verzeichnis /includes/downloads nun nicht
mehr als Server-Side Includes betrachtet und dementsprechend nicht mehr ausgeführt.
RemoveInputFilter
RemoveInputFilter entfernt jeden Eingabefilter für einen bestimmten Dateityp.
Konfigurationsanweisung:
RemoveInputFilter
Syntax:
RemoveInputFilter Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Sofern Sie Eingabefilter definiert haben, können Sie diese mit der Anweisung RemoveInputFilter entfernen. Gerade in .htaccess-Dateien und <Directory>- sowie <Location>Anweisungen könnte die Option zum Einsatz kommen, wobei die Groß- und Kleinschreibung nicht beachtet wird und auch die Angabe eines führenden Punkts in der
Dateinamenserweiterung optional ist. Ein Beispielaufruf:
RemoveInputFilter doc
Dabei kann entweder ein bestimmter Dateityp angegeben werden, für den der Eingabefilter nicht mehr gelten soll, oder eine durch Leerzeichen getrennte Liste von Dateierweiterungen.
408
5 Konfiguration
RemoveLanguage
RemoveLanguage entfernt eine definierte Verknüpfung zwischen einer Sprache und
einer Dateiendung.
Konfigurationsanweisung:
RemoveLanguage
Syntax:
RemoveLanguage Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Durch die AddLanguage-Anweisung lässt sich eine Dateiendung einer bestimmten
Sprache zuordnen. Die RemoveLanguage-Option ist das genaue Gegenstück zur AddLanguage-Anweisung und entfernt die Zuordnung einer Sprache zu einer bestimmten
Dateiendung:
RemoveLanguage .pl
Die Option macht in .htaccess-Dateien und innerhalb von <Directory>- sowie <Location>Anweisungen Sinn, wobei die Groß- und Kleinschreibung nicht beachtet wird und
auch die Angabe eines führenden Punktes in der Dateinamenserweiterung optional ist.
RemoveOutputFilter
RemoveOutputFilter entfernt einen definierten Ausgabefilter für einen bestimmten
Dateitypen.
Konfigurationsanweisung:
RemoveOutputFilter
Syntax:
RemoveOutputFilter Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Sofern Sie einen Ausgabefilter für einen bestimmten Dateitypen definiert haben, können Sie diesen Filter mit der Konfigurationsanweisung RemoveOutputFilter entfernen.
Als einzigen Parameter erwartet die Anweisung die Angabe eines oder mehrerer
Dateitypen, für die der Filter entfernt werden soll. Ein Beispiel:
5.4 Sonstige Module
409
RemoveOutputFilter shtml
Sinnvoll nutzen Sie die Anweisung in .htaccess-Dateien und <Directory>- sowie <Location>-Anweisungen. Die Groß- und Kleinschreibung wird nicht beachtet und auch
die Angabe eines führenden Punktes in der Dateinamenserweiterung ist optional.
RemoveType
RemoveType entfernt den definierten MIME-Typ für einen bestimmten Dateityp.
Konfigurationsanweisung:
RemoveType
Syntax:
RemoveType Dateinamenerweiterung
[ Dateinamenerweiterung ]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
Mit der AddType-Anweisung können Sie einer Dateiendung einen MIME-Typ zuordnen. Die RemoveType-Option ist das genaue Gegenstück zur AddType-Anweisung und
entfernt die Zuordnung eines MIME-Typs zu einer bestimmten Dateiendung:
RemoveType .jpeg
Gerade in .htaccess-Dateien und <Directory>- sowie <Location>-Anweisungen könnte
die Option zum Einsatz kommen, wobei die Groß- und Kleinschreibung nicht beachtet wird und auch die Angabe eines führenden Punkts in der Dateinamenserweiterung optional ist.
ModMimeUsePathInfo
ModMimeUsePathInfo aktiviert oder deaktiviert die Unterstützung von erweiterten
Pfadinformationen durch mod_mime.
Konfigurationsanweisung:
ModMimeUsePathInfo
Syntax:
ModMimeUsePathInfo On | Off
Standardwerte (Default):
ModMimeUsePathInfo Off
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext, VirtualHost-Kontext, .htaccess-Kontext, <Directory>-Container, <Location>-Container,
<Files>-Container
Anweisung aktiv:
nein
410
5 Konfiguration
Diese Anweisung schaltet die Unterstützung für erweiterte Pfadinformationen (vgl.
AcceptPathInfo-Anweisung) durch mod_mime ein (On) oder aus (Off). Standardmäßig
ist die Unterstützung deaktiviert, so dass erweiterte Pfadinformationen durch
mod_mime nicht beachtet und verarbeitet werden.
TypesConfig
TypesConfig definiert den Speicherort der Datei mimes.types.
Konfigurationsanweisung:
TypesConfig
Syntax:
TypesConfig Dateipfad
Standardwerte (Default):
TypesConfig conf/mime.types
Enthalten in Modul:
mod_mime
Kontext:
Server-Kontext
Anweisung aktiv:
ja
Die Konfigurationsanweisung TypesConfig definiert den Speicherort der Datei
mime.types, die Teil der lokalen Apache-Installation ist und die Definitionen der verschiedenen MIME-Typen inklusive Dateiendungen beinhaltet. Als einziges Argument erwartet die Option die Angabe eines Dateipfads, der entweder in relativer
Form zu dem als ServerRoot definierten Verzeichnis (/usr/local/apache2) oder in
absoluter Form angegeben werden kann. Wenn die Datei mime.types unter
/usr/local/apache2/conf/mime.types gespeichert ist und das als ServerRoot definierte Verzeichnis auf das Verzeichnis /usr/local/apache2 zeigt, sieht ein Beispiel mit einer relativen Angabe wie folgt aus:
TypesConfig conf/mime.types
Eine absolute Pfadangabe könnte beispielsweise so aussehen:
TypesConfig /usr/local/apache2/conf/mime.types
Die Liste der MIME-Typen dient dazu, dem Client bei der Übermittlung eines Dokumentes eine Information über den Typ der übermittelten Daten zu senden, damit der
Client weiß, wie er die empfangenen Daten entsprechend verarbeiten kann. Sie sollten diese Liste nicht manuell ändern. Verwenden Sie im Fall der Bekanntmachung
eines neuen MIME-Typs lieber die AddType-Anweisung, zumal bei einem Update des
Apache die Datei mime.types überschrieben wird.
Der Aufbau der Datei ist identisch zur AddType-Anweisung. Der Angabe eines
MIME-Typs folgt die Festlegung einer oder auch mehrerer Dateiendungen, für die
dieser MIME-Typ gelten soll. Dabei spielt die Groß- und Kleinschreibung keine Rolle,
leere Zeilen und Zeilen, die mit einem »#«-Zeichen beginnen, werden ignoriert. Ein
typischer Eintrag in dieser Datei für das .jpg-Bildformat sieht beispielsweise wie folgt
aus:
image/jpeg jpeg jpg jpe
5.4 Sonstige Module
411
MimeMagicFile
MimeMagicFile aktiviert die dynamische Bestimmung des korrekten MIME-Typs für
Dateien anhand ihres Inhalts.
Konfigurationsanweisung:
MimeMagicFile
Syntax:
MimeMagicFile Dateipfad
Standardwerte (Default):
MIMEMagicFile conf/magic
Enthalten in Modul:
mod_mime_magic
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Die einzige durch das Modul mod_mime_magic bereitgestellte Konfigurationsoption
lautet MimeMagicFile und definiert eine Datei namens magic. Mit dieser versucht der
Server ähnlich wie beim unter Unix/Linux verfügbaren Befehls file, anhand der internen Struktur einer Datei den korrekten MIME-Typ zu bestimmen. Dabei wird die
Datei magic mit der Apache Distribution mitgeliefert, sie befindet sich meist im Unterverzeichnis conf Ihrer lokalen Installation. Die Anweisung erwartet als einzigen Parameter eine Datei mit MIME-Definitionen, wobei die Pfadangabe entweder in absoluter oder relativer Form zu dem als ServerRoot definierten Verzeichnis erfolgen kann.
Ein Beispiel:
MIMEMagicFile conf/magic
Das Modul liest praktisch die Struktur der lokalen Dateien aus und vergleicht diese
mit den ihm bekannten Strukturen aus der Datei, die durch die MimeMagicFileAnweisung definiert worden ist. Empfohlen wird der Einsatz dieses Moduls auf
einem Produktivsystem mit vielen Zugriffen. Es ist wohl eher für einen lokalen Intranetserver gedacht, auf dem viele Benutzer Inhalte ablegen und unter Umständen vergessen, die Dateien korrekt zu benennen.
Wenn beispielsweise ein Benutzer eine Bilddatei im weitverbreiteten JPEG-Format
auf den Server überträgt und diese Datei aus irgendeinem unerfindlichen Grund
fälschlicherweise eine andere Dateiendung bekommt, wird ohne Verwendung von
mod_mime_magic die falsche MIME-Kennung an den Client geliefert. Es kommt
unweigerlich zu einer Fehlermeldung auf Seiten des Clients. mod_mime_magic hingegen erkennt diesen Fehler und bereinigt ihn, in dem es an den Client trotz falscher
Dateiendung den richtigen MIME-Typ sendet.
Zur Verdeutlichung habe ich eine Bilddatei mit der Endung .jpg in .gif umbenannt:
# mv test.jpg test.gif
Sollte ein Client diese Datei aufrufen, würde er wahrscheinlich eine Fehlermeldung
erhalten, da es sich nicht um ein im .gif-Format vorliegendes Bild handelt. Der Befehl
file unter Unix/Linux erkennt jedoch den korrekten Dateityp dieser Datei, auch wenn
die Dateiendung eigentlich einen anderen Typ vermuten lässt:
# file test.gif
412
5 Konfiguration
Als Ausgabe erhalte ich korrekterweise die entsprechenden Informationen zu der
umbenannten .jpg-Bilddatei:
test.gif: JPEG image data, JFIF standard 1.02, resolution (DPI), 72 x 72
mod_mime_magic funktioniert ebenso wie der Befehl file, wobei Sie bei der Verwendung von mod_mime_magic die Probleme mit nicht erkannten Dateiformaten gegenüber den Performance-Einbußen abwägen müssen. Im Zweifelsfalle sollten Sie dieses
Modul nicht verwenden.
5.4.5
Caching von Inhalten (mod_cache)
Das Modul mod_cache implementiert einen RFC 2616-kompatiblen Speicher für
HTML-Inhalte, der zur Aufbewahrung von lokalen und zwischengespeicherten
Inhalten genutzt werden kann. Dabei basiert mod_cache auf den Diensten von externen Speichermodulen, wobei dem Apache mit mod_disk_cache und mod_mem_cache
bereits zwei solcher Module beigefügt sind. mod_disk_cache wird zur festplattenbasierten Speicherung von Inhalten verwendet und kommt in der Regel im Zusammenspiel mit mod_proxy zum Einsatz. Sofern lokale Inhalte in den Speicher des Systems (RAM) geladen werden sollen, wird mod_mem_cache verwendet. Hinweis: Das
Modul befindet sich zur Drucklegung dieses Buches in einem sehr experimentellen
Status. Auch die beiden Speichermodule mod_mem_cache und mod_disk_cache sind
momentan noch nicht fertig gestellt, so dass deren Dokumentationen nicht enthalten
sind. Weitere Informationen zum Entwicklungsstand sowie eventuell erhältliche
Dokumentationen für die Module mod_disk_cache und mod_mem_cache erhalten Sie
unter http://httpd.apache.org/docs-2.0/.
Folgende Direktiven werden durch mod_cache bereitgestellt:
CacheDefaultExpire
CacheDefaultExpire bestimmt die Dauer der Zwischenspeicherung einer Datei.
Konfigurationsanweisung:
CacheDefaultExpire
Syntax:
CacheDefaultExpire Sekunden
Standardwerte (Default):
CacheDefaultExpire 3600
(eine Stunde)
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung definiert die Dauer in Sekunden, die ein einzelnes Dokument bzw.
Datei zwischengespeichert wird. Ein Beispiel:
CacheDefaultExpire 86400
5.4 Sonstige Module
413
Dadurch würde standardmäßig ein Dokument einen Tag (=86400 Sekunden) zwischengespeichert, bevor es aus dem rambasierten- oder festplattenbasierten Speicherraum entfernt wird.
CacheDisable
CacheDisable schaltet die Zwischenspeicherung von Informationen für bestimmte
lokale URL-Pfade aus.
Konfigurationsanweisung:
CacheDisable
Syntax:
CacheDisable URL-Pfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Wenn Sie bestimmte lokale URL-Pfade nicht zwischenspeichern möchten, können Sie
diese Pfade mit der CacheDisable-Anweisung definieren. Dabei erwartet die Anweisung den lokalen URL-Pfad, der nicht zwischengespeichert werden soll:
CacheDisable /download
Dadurch werden die Inhalte aus dem URL-Pfad /download (z.B. http://www.beispiel.
de/download) nicht zwischengespeichert. Hinweis: Alle Inhalte, d.h. auch Unterverzeichnisse dieses URL-Pfades, werden nicht zwischengespeichert.
CacheEnable
CacheEnable schaltet die Zwischenspeicherung von Informationen für bestimmte
lokale URL-Pfade ein.
Konfigurationsanweisung:
CacheEnable
Syntax:
CacheEnable Speichertyp URL-Pfad
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die CacheEnable-Anweisung weist mod_cache an, alle Inhalte unterhalb eines lokalen
URL-Pfades zwischenzuspeichern. Dabei erwartet die Anweisung als ersten Parameter die Angabe eines Speichertyps, wobei momentan der Typ mem für mod_mem_cache
sowie disk für mod_disk_cache verfügbar ist. Der zweite Parameter repräsentiert den
lokalen URL-Pfad. Ein Beispiel:
CacheEnable mem /handbuch
414
5 Konfiguration
Diese Anweisung sorgt dafür, dass alle Inhalte unterhalb des lokalen URL-Pfades
/handbuch (z.B. http://www.beispiel.de/handbuch) durch mod_mem_cache, d.h. im Speicher des Systems (RAM) zwischengespeichert werden.
CacheForceCompletion
CacheForceCompletion erzwingt den kompletten Datentransfer, sobald ein gewisses
Volumen einer Information (in %) übertragen worden ist.
Konfigurationsanweisung:
CacheForceCompletion
Syntax:
CacheForceCompletion Prozentsatz
Standardwerte (Default):
CacheForceCompletion
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit Hilfe dieser noch sehr experimentellen Anweisung können Sie den Transfer von
Daten erzwingen, sobald ein gewisser Teil des gesamten Datenvolumens bereits
übertragen worden ist. Dabei erwartet die Anweisung die Angabe eines Prozentsatzes, ab dem der Transfer automatisch erzwungen werden soll. Ein Beispiel:
CacheForceCompletion 80
Hinweis
Durch eine derartige Konfiguration wird der Download von Daten erzwungen,
sofern bereits 80% des gesamten Datenvolumens heruntergeladen worden sind.
Zum Zeitpunkt der Drucklegung dieses Buches (Februar 2004, Apache 2.0.48)
ist diese Anweisung noch nicht implementiert.
CacheIgnoreCacheControl
CacheIgnoreCacheControl ignoriert Anfragen von Clients für nicht zwischengespeicherte Inhalte.
Konfigurationsanweisung:
CacheIgnoreCacheControl
Syntax:
CacheIgnoreCacheControl On | Off
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
5.4 Sonstige Module
415
Wenn mod_cache alle Anfragen ignorieren soll, die auf nicht zwischengespeicherte
Inhalte abzielen, können Sie die CacheIgnoreCacheControl-Anweisung verwenden.
CacheIgnoreNoLastMod
CacheIgnoreNoLastMod ignoriert Antworten, die keinen Last Modified-Header enthalten.
Konfigurationsanweisung:
CacheIgnoreNoLastMod
Syntax:
CacheIgnoreNoLastMod
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
Nein
Diese Anweisung führt dazu, dass Antworten, die keinen Last Modified-Header enthalten, ignoriert werden.
CacheLastModifiedFactor
CacheLastModifiedFactor bestimmt den Faktor, der benutzt wird, um die Gültigkeitsdauer einer Information aus dem letzten Änderungsdatum zu bestimmen.
Konfigurationsanweisung:
CacheLastModifedFactor
Syntax:
CacheLastModifedFactor Faktor
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Sie können einen Wert definieren, der dazu genutzt wird, aus dem letzten Änderungsdatum einer Datei die Gültigkeitsdauer einer Information zu berechnen. Ein
Beispiel:
CacheLastModifedFactor 0.5
CacheMaxExpire
CacheMaxExpire definiert die maximale Zwischenspeicherzeit eines Dokumentes.
Konfigurationsanweisung:
CacheMaxExpire
Syntax:
CacheMaxExpire Sekunden
Standardwerte (Default):
CacheMaxExpire 84600
(ein Tag)
416
5 Konfiguration
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung definiert die maximale Zeit in Sekunden, die ein Dokument zwischengespeichert werden soll. Diese Zeit überschreibt den Inhalt des HTTP-Headers
Expire:
CacheMaxExpire 604800
Mit dieser Anweisung würde ein Dokument maximal eine Woche zwischengespeichert.
CacheMaxStreamingBuffer
CacheMaxStreamingBuffer bestimmt die maximale Größe einer Antwort im Speicher,
bis zu der diese Antwort zwischengespeichert wird (veraltet).
Konfigurationsanweisung:
CacheMaxStreamingBuffer
Syntax:
CacheMaxStreamingBuffer Größe
Standardwerte (Default):
CacheMaxStreamingBuffer 0
Enthalten in Modul:
mod_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Wenn eine Antwort auf eine Anfrage nicht in einem Rutsch, sondern in dauerhaften
Datenströmen (z.B. CGI-Skript) erfolgt, so bestimmt diese experimentelle Anweisung
die maximale Größe einer solchen Antwort, bevor entschieden wird, diese nicht zwischenzuspeichern. Standardmäßig wird eine in Datenströmen erfolgende Antwort
nicht zwischengespeichert, es sei denn, diese enthält einen Content Length-Header.
Dadurch wird verhindert, dass Speicherbereiche für eine Information reserviert werden, die ohnehin vollständig in den Speicher geladen werden kann. Falls Sie Antworten zwischenspeichern wollen, die in dauerhaften Datenströmen erfolgen, können Sie
mit der CacheMaxStreamingBuffer-Anweisung eine maximale Anzahl an Daten (in
Bytes) definieren, bis zu der diese Datenströme zwischengespeichert werden sollen.
Ein Beispiel:
CacheMaxStreamingBuffer 65536
Durch eine derartige Anweisung wird eine in Datenströmen erfolgende Antwort bis
zu einer Größe von 64kb zwischengespeichert. Größere Antworten werden nicht zwischengespeichert. Die Zwischenspeicherung von Daten führt zu keiner Verzögerung
bei der Auslieferung dieser Informationen an den Client.
Hinweis
5.4 Sonstige Module
417
Die Anweisung ist in neueren Versionen des Apache (z.B. 2.0.48) nicht mehr
enthalten.
mod_file_cache
Mit dem experimentellen Modul mod_file_cache können Sie statische Dateien in den
Speicher des Systems laden und dort resistent zwischenspeichern (neudeutsch:
cachen). Dabei ist das Modul eine Erweiterung des im Apache 1.3.x verfügbaren
Moduls mod_mmap_static, wobei der Quellcode in großen Teilen übernommen worden ist. Beim Start des Apache wird durch dieses Modul eine von Ihnen zu definierende Anzahl an statischen Dateien geöffnet und in den Speicher des Systems geladen. Dadurch sind die zwischengespeicherten Informationen schneller verfügbar, da
die entsprechenden Dateien nur einmal beim Start des Apache geöffnet und gelesen
werden müssen, und nicht für jede Anfrage erneut. Allerdings funktioniert diese
Technik nur mit statischen Dateien, die durch den Kern des Apache verarbeitet werden können, d.h. dynamische CGI-, PHP- oder SSI-Skripte können nicht zwischengespeichert werden, da deren Inhalte dynamisch sind und durch clientseitig übermittelte Daten von Anfrage zu Anfrage variieren können. Hinweis: Das Modul ist zur
Drucklegung dieses Buches äußerst experimentell und sollte mit Vorsicht genutzt
werden!
Durch mod_file_cache werden nur zwei Konfigurationsanweisungen bereitgestellt:
CacheFile
CacheFile lädt die Dateideskriptoren einer Liste von Dateien in den Speicher des Systems.
Konfigurationsanweisung:
CacheFile
Syntax:
CacheFile Datei [Datei]...
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_file_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Die CacheFile-Anweisung lädt, im Gegensatz zur MMapFile-Anweisung, nicht die
kompletten Dateien in den Speicher des Systems, sondern nur die Dateideskriptoren
einer durch Leerzeichen getrennten Liste von Dateien. Dadurch ist es auch möglich,
große (statische) Dateien in den Speicher zu laden, ohne dass sich daraus automatisch
ein hoher Speicherverbrauch ergibt. Allerdings ist die Geschwindigkeitssteigerung
nicht so hoch, wie bei Verwendung der MMapFile-Anweisung. Sobald der Server startet, werden die Dateideskriptoren in den Speicher des Systems geladen und dort
automatisch entfernt, wenn der Server heruntergefahren wird. Falls sich eine zwi-
418
5 Konfiguration
schengespeicherte Datei ändert, müssen Sie den Server komplett neu starten, um die
geänderte Version einer Datei erneut zwischenzuspeichern. Ein Beispiel:
CacheFile /usr/local/apache2/htdocs/index.html
Diese Anweisung lädt den Dateideskriptor der Datei /usr/local/apache2/htdocs/index.html
in den Speicher. Sie können auch eine Liste von Dateien angeben, die jeweils durch ein
Leerzeichen voneinander getrennt werden müssen. Auch der mehrmalige Aufruf der
CacheFile-Anweisung zur Zwischenspeicherung von Dateideskriptoren ist möglich. Die
dritte Anweisung ist also mit den ersten beiden identisch:
Hinweis
CacheFile /usr/local/apache2/htdocs/index.html
CacheFile /usr/local/apache2/htdocs/logo.gif
CacheFile /usr/local/apache2/htdocs/index.html /usr/local/apache2/htdocs/logo.gif
Sie müssen bei der Definition von Dateien, deren Dateideskriptor Sie zwischenspeichern möchten, immer absolute Dateipfade verwenden. Auf Dateisystemebene werden keinerlei Verweise (z.B. Symlinks) verfolgt. Achtung: Das Zwischenspeichern von Informationen funktioniert nur und ausschließlich mit
statischen Daten und nicht mit dynamischen Inhalten wie PHP-, CGI- oder SSISkripten!
MMapFile
MMapFile lädt den Inhalt einer Liste von Dateien in den Speicher des Systems.
Konfigurationsanweisung:
MMapFile
Syntax:
MMapFile Datei [Datei]...
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_file_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Mit dieser Anweisung können Sie beim Start des Servers eine Liste von Dateien, die
Sie mit Leerzeichen voneinander trennen müssen, in den Speicher des Systems laden.
Diese Dateien werden automatisch aus dem Speicher entfernt, sobald der Server heruntergefahren wird. Wenn sich eine Datei verändert hat, müssen Sie den Server neu
starten, damit der geänderte Inhalt einer Datei eingelesen wird. Die MMapFileAnweisung bringt eine große Performancesteigerung und ist für statische Inhalte
(z.B. Grafiken, Bilder, Texte etc.) durchaus sinnvoll, da diese sich nicht oder nur sehr
selten ändern. Ein Beispiel:
MMapFile /usr/local/apache2/htdocs/index.html
Diese Anweisung lädt den Inhalt der Datei /usr/local/apache2/htdocs/index.html in den
Speicher. Sie können auch eine Liste von Dateien angeben, die jeweils durch ein Leer-
5.4 Sonstige Module
419
zeichen voneinander getrennt werden müssen. Auch der mehrmalige Aufruf der
MMapFile-Anweisung zur Zwischenspeicherung des Inhaltes von mehreren Dateien
ist möglich. Die dritte Anweisung ist also mit den ersten beiden identisch:
Hinweis
MMapFile /usr/local/apache2/htdocs/handbuch.pdf
MMapFile /usr/local/apache2/htdocs/logo.gif
MMapFile /usr/local/apache2/htdocs/handbuch.pdf /usr/local/apache2/htdocs/logo.gif
Sie müssen bei der Definition von Dateien, deren Inhalte Sie zwischenspeichern
möchten, immer absolute Dateipfade verwenden. Auf Dateisystemebene werden keinerlei Verweise (z.B. Symlinks) verfolgt. Achtung: Das Zwischenspeichern von Informationen funktioniert nur und ausschließlich mit statischen
Daten und nicht mit dynamischen Inhalten wie PHP-, CGI- oder SSI-Skripten!
mod_disk_cache
Das Modul mod_disk_cache, welches das Vorhandensein von mod_cache voraussetzt, stellt eine festplattenbasierte Speicherverwaltung zur Verfügung und wird primär im Zusammenspiel mit mod_proxy verwendet. Es gilt zur Drucklegung dieses
Buches noch als experimentell, stellt jedoch bereits die folgenden Konfigurationsanweisungen zur Verfügung:
CacheDirLength
Definiert die Länge der Unterverzeichnisnamen in der festplattenbasierten Speicherhierarchie.
Konfigurationsanweisung:
CacheDirLength
Syntax:
CacheDirLength Länge
Standardwerte (Default):
CacheDirLength 2
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Für die festplattenbasierte Speicherung von Daten wird eine Verzeichnisstruktur
(inklusive zahlreicher Unterverzeichnisse) aufgebaut, in denen die Informationen
effektiv gespeichert werden können. Dabei definiert die CacheDirLength-Anweisung
die Zeichenlänge der Namen der Unterverzeichnisse, die innerhalb dieser Verzeichnisstruktur erstellt werden sollen. Ein Beispiel:
CacheDirLength 4
Durch diese Konfiguration werden in der Verzeichnisstruktur Unterverzeichnisse mit
einer Länge von je vier Zeichen erstellt. Hinweis: Die Multiplikation aus dem Wert
der CacheDirLength- und dem Wert der CacheDirLevels-Anweisung darf nicht größer
als 20 sein.
420
5 Konfiguration
CacheDirLevels
Gibt die Anzahl an Unterverzeichnisebenen in der Verzeichnisstruktur der Speicherhierarchie an.
Konfigurationsanweisung:
CacheDirLevels
Syntax:
CacheDirLevels Ebenen
Standardwerte (Default):
CacheDirLevels 3
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die CacheDirLevels-Anweisung definiert die Anzahl an Unterverzeichnisebenen in
der Verzeichnisstruktur der Speicherhierarchie. Dabei werden die Daten in einer von
Ihnen zu definierenden Anzahl an Verzeichnisebenen unterhalb des durch die CacheRoot-Anweisung definierten Verzeichnisses gespeichert. Ein Beispiel:
CacheDirLevels 5
Mit Hilfe dieser Einstellung werden die Daten fünf Verzeichnisse unterhalb des von
Ihnen durch die CacheRoot-Anweisung zu definierenden Verzeichnisses gespeichert.
Hinweis: Auch hier sei erwähnt, dass die Multiplikation aus dem Wert der CacheDirLength- und dem Wert der CacheDirLevels-Anweisung nicht größer als 20 sein darf.
CacheExpiryDate
Schaltet die Beachtung von zeitlichen Gültigkeitsbeschränkungen von Daten bei der
Dateisuche ein oder aus.
Konfigurationsanweisung:
CacheExpiryDate
Syntax:
CacheExpiryDate On | Off
Standardwerte (Default):
CacheExpiryDate On
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Konfigurationsanweisung gibt an, ob der Apache beim Durchsuchen der Verzeichnisstruktur der Speicherhierarchie eventuell vorhandene Gültigkeitsbeschränkungen von Dateien, die durch den Header Expires: definiert werden können, berücksichtigen soll (Parameter: On) oder nicht (Parameter: Off). Standardmäßig werden
diese zeitlichen Gültigkeitsbeschränkungen immer beachtet:
CacheExpiryDate On
Hinweis
5.4 Sonstige Module
421
Diese Funktionalität ist in der Version 2.0.48 des Apache noch nicht implementiert.
CacheGcDaily
Bestimmt die tägliche Uhrzeit, wenn der Garbage Collector laufen soll.
Konfigurationsanweisung:
CacheGcDaily
Syntax:
CacheGcDaily Uhrzeit
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit Hilfe der CacheGcDaily-Anweisung können Sie die tägliche Uhrzeit (24 Stundenformat) bestimmen, an dem der so genannte Garbage Collector laufen soll. Der Garbage Collector löscht nicht mehr benutzte und veraltete Inhalte aus dem Cache und
erzeugt damit freien Speicherplatz für neue Inhalte. Ein Beispiel:
Hinweis
CacheGcDaily 23:59
Diese Anweisung ist in der Version 2.0.48 des Apache noch nicht implementiert.
CacheGcInterval
Definiert den Zeitabstand zwischen zwei Abläufen des Garbage Collectors.
Konfigurationsanweisung:
CacheGcInterval
Syntax:
CacheGcInterval Stunden
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Neben einer festen Uhrzeit können Sie auch ein Zeitinterval bestimmen, indem der
Garbage Collector aufgerufen werden soll, um veraltete und nicht mehr benötigte
Informationen aus dem Speicher (Cache) zu löschen. Als einzigen Parameter erwartet
diese Anweisung die Angabe einer Stundenzahl:
CacheGcInterval 24
Hinweis
422
5 Konfiguration
Auch diese Anweisung ist in der Version 2.0.48 des Apache noch nicht implementiert.
CacheMaxFileSize
Gibt die maximale Größe von Dateien an, die im Cache gespeichert werden sollen.
Konfigurationsanweisung:
CacheMaxFileSize
Syntax:
CacheMaxFileSize Größe
Standardwerte (Default):
CacheMaxFileSize 1000000
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die CacheMaxFileSize-Anweisung definiert die maximale Dateigröße (in Bytes) von
Dateien, die überhaupt im Speicher (Cache) gespeichert werden sollen. Ein Beispiel:
CacheMaxFileSize 64000
Durch diese Anweisung werden nur Dateien bis zu einer maximalen Größe von 64000
Bytes im Speicher abgelegt. Dateien, die diese Größe überschreiten, werden nicht
lokal zwischengespeichert.
CacheMinFileSize
Gibt die minimale Größe von Dateien an, die im Cache gespeichert werden sollen.
Konfigurationsanweisung:
CacheMinFileSize
Syntax:
CacheMinFileSize Größe
Standardwerte (Default):
CacheMinFileSize 1
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Die CacheMinFileSize-Anweisung definiert die minimale Dateigröße (in Bytes) von
Dateien, die im Speicher (Cache) gespeichert werden sollen. Ein Beispiel:
CacheMinFileSize 64
Durch eine derartige Konfiguration werden nur Dateien ab einer Größe von 64 Bytes
im Speicher abgelegt. Dateien, die diese Größe unterschreiten, werden nicht lokal
zwischengespeichert.
5.4 Sonstige Module
423
CacheRoot
Definiert das Basisverzeichnis für die festplattenbasierte Speicherverwaltung.
Konfigurationsanweisung:
CacheRoot
Syntax:
CacheRoot Verzeichnis
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit Hilfe der CacheRoot-Anweisung können Sie das Basisverzeichnis für die eigene
Speicherhierarchie definieren. In diesem Verzeichnisses werden alle Daten lokal zwischengespeichert, wobei die CacheDirLevels- und die CacheDirLength-Anweisung die
interne Struktur dieses Basisverzeichnisses vorgeben. Ein Beispiel:
CacheRoot /usr/local/apache2/cache
Hinweis
Fortan werden alle Daten unterhalb des Verzeichnisses /usr/local/apache2/cache zwischengespeichert, wobei die interne Struktur gemäß der CacheDirLevels- und CacheDirLength-Anweisung automatisch angelegt wird.
Wenn das Modul mod_disk_cache geladen oder fest in den Apache integriert
ist, muss diese Anweisung definiert werden. Andernfalls werden Sie eine Fehlermeldung erhalten und der Start des Servers wird unterbunden. Es ist außerdem ratsam, ein separates Verzeichnis (z.B. /usr/local/apache2/cache) für die
Speicherhierarchie zu erstellen und dieses als CacheRoot zu verwenden.
CacheSize
Gibt die Größe des Festplattenspeichers in Kilobytes an.
Konfigurationsanweisung:
CacheSize
Syntax:
CacheSize Größe
Standardwerte (Default):
CacheSize 1000000
Enthalten in Modul:
mod_disk_cache
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Diese Anweisung definiert die Größe des Festplattenspeichers (in Kilobytes), der zur
lokalen Zwischenspeicherung von Daten benutzt wird. Dabei ist die durch die CacheSize-Anweisung definierte Größe nicht ultimativ, d.h. der Speicher kann auch gelegentlich etwas mehr Speicherplatz belegen. In einem solchen Fall wird der Garbage
Collector jedoch bei seinem nächsten Aufruf den belegten Speicherplatz auf einen
424
5 Konfiguration
Wert korrigieren, der kleiner (oder gleich) ist, als der durch die CacheSize-Anweisung
vorgesehene Speicherplatz. Ein Beispiel:
Hinweis
CacheSize 5000000
Wählen Sie als CacheSize immer einen Wert, der niedriger ist, als der insgesamt
zur Verfügung stehende Speicherplatz auf Ihrer Festplatte!
mod_mem_ cache
Bei Verwendung eines so genannten ReverseProxy (vgl. ProxyPass-Anweisung) bzw.
bei der Zwischenspeicherung von lokal erzeugten Daten ist das Modul
mod_mem_cache, welches eine RAM-basierte Speicherverwaltung zur Verfügung
stellt und das Vorhandensein von mod_cache erfordert, am besten geeignet. Dabei
werden durch das Modul die folgenden Konfigurationsanweisungen bereitgestellt:
MCacheMaxObjectCount
Definiert die maximale Anzahl an Objekten, die im Cache gespeichert werden sollen.
Konfigurationsanweisung:
MCacheMaxObjectCount
Syntax:
MCacheMaxObjectCount Anzahl
Standardwerte (Default):
MCacheMaxObjectCount 1009
Enthalten in Modul:
mod_mem_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Die MCacheMaxObjectCount-Anweisung gibt an, wie viele Objekte maximal im Cache
gespeichert werden sollen. Falls die maximale Anzahl an Objekten erreicht ist, wird
gemäß der MCacheRemovalAlgorithm-Anweisung ein anderes Objekt aus dem Speicher entfernt, sobald ein neues hinzugefügt werden soll. Ein Beispiel:
MCacheMaxObjectCount 13001
Durch diese Konfiguration können maximal 13001 Objekte im Cache (RAM bzw.
Arbeitsspeicher) zwischengespeichert werden. Dieser Wert sollte in den meisten Fällen völlig ausreichend sein.
MCacheMaxObjectSize
Gibt die maximale Größe eines Dokumentes an, welches im Cache zwischengespeichert werden soll.
5.4 Sonstige Module
Konfigurationsanweisung:
425
MCacheMaxObjectSize
Syntax:
MCacheMaxObjectSize Größe
Standardwerte (Default):
MCacheMaxObjectSize 10000
Enthalten in Modul:
mod_mem_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Um die maximale Größe (in Bytes) eines Dokumentes zu definieren, welches im
Cache gespeichert werden soll, müssen Sie die MCacheMaxObjectSize-Anweisung verwenden. Ein Beispiel:
MCacheMaxObjectSize 500000
Hinweis
Eine solche Anweisung würde dazu führen, dass nur Dokumente mit einer Größe
unter 500000 Bytes (ca. 0,5 MB) im Arbeitsspeicher bzw. RAM zwischengespeichert
werden. Größere Dokumente werden daher nicht lokal zwischengespeichert.
Der Wert der MCacheMaxObjectSize-Anweisung muss größer sein, als der der
MCacheMinObjectSize-Anweisung. Logisch, oder?
MCacheMaxStreamingBuffer
Bestimmt die maximale Datengröße von lokal zwischenspeicherbaren Informationen,
bevor eine Antwort als zu groß eingestuft wird.
Konfigurationsanweisung:
MCacheMaxStreamingBuffer
Syntax:
MCacheMaxStreamingBuffer Größe
Standardwerte (Default):
MCacheMaxStreamingBuffer 100000
Enthalten in Modul:
mod_mem_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Die MCacheMaxStreamingBuffer-Anweisung definiert das Verhalten des Apache,
wenn eine Datenquelle (z.B. CGI-Skript) Informationen nicht vollständig in einem
Rutsch übermittelt hat, die erhaltenen Informationen aber eventuell lokal zwischengespeichert werden sollen. Dabei wird durch die Anweisung die maximale Größe (in
Bytes) definiert, ab der eine Information als zu groß und damit als mehr lokal zwischenspeicherbar eingestuft wird. Ein Beispiel:
MCacheMaxStreamingBuffer 65536
426
5 Konfiguration
In diesem Beispiel wird eine Information, die nicht sofort vollständig verfügbar und
dessen Gesamtgröße, die durch den so genannten Content-Length-Header angegeben
wird, unbekannt ist, bis zu einer Größe von 64kb (=1024*64) lokal zwischengespeichert. Überschreitet eine Antwort eines entfernten Servers die maximale Größe, wird
der Versuch, diese zwischenzuspeichern, abgebrochen und die bis dahin erhaltenen
Daten werden verworfen.
MCacheMinObjectSize
Setzt die minimale Größe eines Dokumentes, welches im Cache zwischengespeichert
werden soll.
Konfigurationsanweisung:
MCacheMinObjectSize
Syntax:
MCacheMinObjectSize Größe
Standardwerte (Default):
MCacheMinObjectSize 0
Enthalten in Modul:
mod_mem_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Selbstverständlich können Sie auch die minimale Größe (in Bytes) eines Dokumentes
zu definieren, welches im Cache gespeichert werden soll. Ein Beispiel:
MCacheMinObjectSize 10000
Durch diese Anweisung werden nur Dokumente ab einer Gesamtgröße von 10000
Bytes lokal zwischengespeichert.
MCacheRemovalAlgorithm
Selektiert den Algorithmus, der zur Entfernung von Objekten aus dem Speicher verwendet wird.
Konfigurationsanweisung:
MCacheRemovalAlgorithm
Syntax:
MCacheRemovalAlgorithm LRU | GDSF
Standardwerte (Default):
MCacheRemovalAlgorithm GDSF
Enthalten in Modul:
mod_mem_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Damit neue Objekte zwischengespeichert werden können, muss der Speicher periodisch aufgeräumt und alte Objekte aus diesem entfernt werden. Mit Hilfe der MCacheRemovalAlgorithm-Anweisung können Sie dabei den Algorithmus definieren, den
der Apache benutzen soll, um nicht mehr benutzte Objekte aus dem Speicher zu entfernen. Dabei stehen die folgenden zwei Algorithmen zur Auswahl:
LRU
5.4 Sonstige Module
427
Der Algorithmus LRU (=Least recently used) löscht nur solche Objekte aus dem Speicher, die die längste Zeit nicht benutzt worden sind. Ein Beispiel:
MCacheRemovalAlgorithm LRU
GDSF
Basierend u.a. auf der Größe eines Objektes weist der GDSF (Gready Dual-Size)Algorithmus jedem Objekt eine bestimmte Priorität zu. Wenn Objekte aus dem Speicher entfernt werden müssen, werden zunächst die mit der niedrigsten Priorität entfernt. Ein Beispiel:
Hinweis
MCacheRemovalAlgorithm GDSF
Dieser Algorithmus stellt die Standardeinstellung der Konfigurationsanweisung dar.
MCacheSize
Definiert die Gesamtgröße des Cache.
Konfigurationsanweisung:
MCacheSize
Syntax:
MCacheSize Größe
Standardwerte (Default):
MCacheSize 100
Enthalten in Modul:
mod_mem_cache
Kontext:
Server-Kontext
Anweisung aktiv:
nein
Die Gesamtgröße des Cache (in Kilobytes) wird durch die MCacheSize-Anweisung
definiert:
MCacheSize 10000
Hinweis
Durch diese Anweisung würde ein Cache mit einer Gesamtgröße von 10000 Kilobytes
erstellt.
Der Wert der MCacheSize-Anweisung muss größer sein, als der Wert der
MCacheMaxObjectSize-Anweisung.
428
5.4.6
5 Konfiguration
Kontrolle über und Änderung von HTTP-Headern
(mod_headers)
Mit Hilfe des Moduls mod_headers ist die Kontrolle und Modifizierung der HTTPHeader für eingehende Anfragen und ausgehende (Server-) Antworten möglich.
Dabei können die einzelnen Header miteinander verschmolzen, ersetzt, verändert
oder komplett entfernt werden. Die Reihenfolge der Abarbeitung der durch
mod_headers bereitgestellten Konfigurationsanweisungen ist wichtig, da zunächst der
Hauptserver sowie die einzelnen virtuellen Server ausgewertet werden. Erst danach
erfolgt die Abarbeitung der durch mod_headers bereitgestellten Direktiven innerhalb
eines <Directory>-Containers, eines .htaccess-Kontextes sowie eines <Location>- bzw.
<Files>-Containers. Diese beiden Anweisungen werden durch mod_headers bereitgestellt:
Header
Header verändert die HTTP-Header einer (Server-) Antwort.
Konfigurationsanweisung:
Header
Syntax:
Header set | append | add | unset | echo Header [Wert]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_headers
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Diese Anweisung dient zur Ersetzung, Verschmelzung, Modifizierung und Entfernung von HTTP-Headern in (Server-) Antworten. Dabei werden die Header verändert, nachdem der Content-Handler sowie mögliche Ausgabefilter ihre Arbeit verrichtet haben. Als erstes Argument erwartet die Anweisung eine Aktion, die
durchgeführt werden soll, wobei folgende Aktionen zur Verfügung stehen:
set
Ein Header wird in einer Antwort explizit gesetzt. Sollten bereits gleichnamige Header vorhanden sein, werden diese überschrieben. Ein Beispiel:
Header set Serverid "17"
Durch diese Anweisung wird einer Server-Antwort der Header Serverid hinzugefügt,
der den Wert 17 enthält. Mit Hilfe einer derartigen Anweisung könnte man beispielsweise innerhalb eines Serverclusters herausfinden, welcher Server eine Anfrage wirklich bedient hat.
5.4 Sonstige Module
429
append
Sofern diese Aktion gewählt wird, wird der übergebene Wert an einen beliebigen,
bereits existierenden und gleichnamigen Header angehangen. Der alte und der neue
Wert eines Headers wird laut Definition durch ein Komma voneinander getrennt. Ein
Beispiel:
Header append Server "(was sonst)"
Diese Anweisung fügt zum HTTP-Header Server die Zeichenkette »(was sonst)«
hinzu, so dass diese etwa folgenden Wert enthält: Server: Apache/2.0.48 (Unix)
PHP/4.3.3 (was sonst)
add
Die Aktion fügt einen Header zu den bereits bestehenden Headern hinzu, ohne diesen an einen eventuell vorhandenen, gleichnamigen Header anzuhängen. Dadurch
können innerhalb einer (Server-) Antwort mehrere gleichnamige HTTP-Header entstehen, wodurch unvorhersehbare Konsequenzen auftreten können. Aus diesem
Grund sollten Sie die append-Aktion bevorzugen. Ein Beispiel:
Header add Server "Microsoft/IIS 5.0"
Sofern Sie den Benutzer leicht irritieren wollen, können Sie eine derartige Anweisung
verwenden, die neben dem bereits bestehenden HTTP-Header Server einen neuen
Header namens Server definiert, der den Wert Microsoft/IIS 5.0 enthält. Dennoch sollten Sie die add-Aktion mit Vorsicht verwenden, da diese bei wichtigeren HTTP-Headern durchaus zu Problemen führen kann, falls ein Header mehrfach vorhanden ist.
unset
Mit der Aktion entfernen Sie einen HTTP-Header komplett aus der Antwort eines
Servers, sofern dieser existiert. Sofern mehrere, gleichnamige Header vorhanden
sind, werden sie alle entfernt. Ein Beispiel:
Header unset Server
Der HTTP-Header Server wird durch diese Anweisung gelöscht. Sollte dieser mehrfach vorhanden sein, werden alle Einträge gelöscht.
echo
Wenn Sie die HTTP-Header einer Anfrage ungefiltert an den Client zurücksenden
möchten, können Sie diese Aktion wählen. Die Verwendung eines einfachen regulären Ausdrucks ist möglich. Ein abschließendes Beispiel:
Header echo Accept
Durch eine derartige Anweisung wird der Wert des durch den Client übermittelten
HTTP-Header Accept ungefiltert ausgegeben.
Als zweites Argument erwartet die Header-Anweisung die Angabe eines HTTP-Headers, auf den die gewählte Aktion angewendet werden soll, wobei die Groß- und
Kleinschreibung nicht beachtet wird. Einzig bei Verwendung der echo-Aktion wird
430
5 Konfiguration
diese beachtet. Außerdem kann als HTTP-Header ein regulärer Ausdruck verwendet
werden. Ein Beispiel:
Header unset Server
Die Aktion unset wird auf den HTTP-Header Server angewendet, wodurch dieser
gelöscht wird.
Zusätzlich ist für die Aktionen add, append und set die Angabe eines Wertes nötig.
Sofern dieser Leerzeichen enthält, müssen Sie diesen durch Anführungszeichen kennzeichnen. Innerhalb des Wertes sind zusätzlich folgende Formatangaben möglich:
%t
Enthält die exakte Zeit im UCT-Format (Universal Coordinated Time, in Mikrosekunden seit dem 01. Januar 1970), wann eine Anfrage eingegangen ist. Der Zeitangabe
wird automatisch das Kennzeichen t= vorangestellt.
%D
Enthält die Dauer, die der Server gebraucht hat, um eine Anfrage zu verarbeiten.
Dabei wird die Dauer ebenfalls in Mikrosekunden angegeben und durch ein vorangestelltes D= kenntlich gemacht.
%{Beispielvariable}e
Durch diese Formatangabe sind Sie in der Lage, den Wert einer beliebigen Umgebungsvariable (hier: Beispielvariable) auszugeben.
Ein Beispiel zur Angabe eines zusätzlichen Wertes für die add, append oder set-Aktion:
Header add X-Bearbeitungszeit "Bearbeitungszeit (%t): %D"
Diese Anweisung würde dazu führen, dass jede Antwort des Servers einen neuen
HTTP-Header namens X-Bearbeitungszeit enthalten würde, der den Zeitpunkt des
Eingangs sowie die Dauer der Verarbeitung einer Anfrage beinhalten würde. Dieser
HTTP-Header könnte beispielsweise folgenden Wert enthalten: X-Bearbeitungszeit
(t=1032988620): D=171103 ms
Schließlich können Sie für die add-, append- oder set-Aktion ein viertes Argument
angeben, welches eine Bedingung definiert, unter der eine Aktion ausgeführt wird.
Ein Beispiel:
SetEnvIf User-Agent "FreeBSD" Unix_Benutzer
Header add X-Kommentar "The power to serve" env=Unix_Benutzer
Der HTTP-Header X-Kommentar mit dem Wert »The power to serve« wird nur hinzugefügt, wenn die Umgebungsvariable Unix_Benutzer gesetzt ist. Diese Umgebungsvariable wird allerdings nur gesetzt, wenn der Browser des Benutzers die Zeichenkette
FreeBSD sendet und somit davon ausgegangen werden kann, dass der Benutzer dieses freie Unix-Derivat benutzt.
RequestHeader
RequestHeader verändert die HTTP-Header einer Clientanfrage.
5.4 Sonstige Module
431
Konfigurationsanweisung:
RequestHeader
Syntax:
RequestHeader set | append | add | unset | echo Header
[Wert]
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_headers
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Diese Anweisung ist syntaktisch mit der vorgestellten Header-Anweisung identisch
und dient zur Ersetzung, Verschmelzung, Modifizierung und Entfernung von HTTPHeadern in (Client-) Anfragen. Dabei werden die Header verändert, bevor der Content-Handler und nachdem mögliche Eingabefilter ihre Arbeit verrichtet haben. Als
erstes Argument erwartet die Anweisung eine Aktion, die durchgeführt werden soll,
wobei folgende Aktionen zur Verfügung stehen:
set
Ein Header wird in einer Anfrage explizit gesetzt. Sollten bereits gleichnamige Header vorhanden sein, werden diese überschrieben.
append
Sofern diese Aktion gewählt wird, wird der übergebene Wert an einen beliebigen,
bereits existierenden und gleichnamigen Header angehangen. Der alte und der neue
Wert eines Headers wird laut Definition durch ein Komma voneinander getrennt.
add
Die Aktion fügt einen Header zu den bereits bestehenden Headern hinzu, ohne diesen an einen eventuell vorhandenen, gleichnamigen Header anzuhängen. Dadurch
können innerhalb einer (Client-) Anfrage mehrere gleichnamige HTTP-Header entstehen, wodurch Probleme bei der Verarbeitung einer Anfrage durch den Server auftreten können.
unset
Mit der Aktion entfernen Sie einen HTTP-Header komplett aus der Anfrage eines
Clients, sofern dieser existiert. Sofern mehrere, gleichnamige Header vorhanden sind,
werden sie alle entfernt.
Als zweites Argument erwartet die RequestHeader-Anweisung die Angabe eines
HTTP-Headers, auf den die gewählte Aktion angewendet werden soll, wobei die
Groß- und Kleinschreibung nicht beachtet wird. Bei Verwendung der add, append oder
set-Aktion müssen Sie zusätzlich einen Wert als drittes Argument angeben. Sollte der
Wert Leerzeichen enthalten, müssen Sie diesen in Anführungszeichen einschließen.
Weitergehende Informationen und Beispiele finden Sie in den Ausführungen zur syntaktisch identischen Header-Anweisung.
432
5.4.7
5 Konfiguration
Steuerung der Aktualität von Inhalten
(mod_expires)
Mit mod_expires können Sie die Erzeugung des HTTP-Headers Expires in Serverantworten steuern, der die Dauer der Gültigkeit einer Information definiert. Dabei
kann die Gültigkeitsdauer entweder relativ zum letzten Änderungsdatum einer
Information oder zum letzten Zugriffszeitpunkt eines Clients definiert werden. Folgende drei Konfigurationsanweisungen sind mit mod_expires zusätzlich verfügbar:
ExpiresActive
ExpiresActive schaltet die Erzeugung des HTTP-Headers Expires ein oder aus.
Konfigurationsanweisung:
ExpiresActive
Syntax:
ExpiresActive On | Off
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_expires
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Diese Anweisung schaltet die Erzeugung des HTTP-Headers Expires ein (on) oder aus
(off). Ein Beispiel:
ExpiresActive On
Durch eine derartige Konfiguration kann jeder Antwort des Servers der HTTP-Header Expires hinzugefügt werden. Hinweis: Bitte beachten Sie, dass die Anweisung die
Erzeugung dieses HTTP-Headers nicht unbedingt erzwingt, da die durch die Anweisungen ExpiresByType bzw. ExpiresDefault aufgestellten Kriterien ebenfalls erfüllt sein
müssen, damit der Header erzeugt wird!
ExpiresByType
ExpiresByType definiert die Gültigkeit einer Information in Abhängigkeit von deren Typ.
Konfigurationsanweisung:
ExpiresByType
Syntax:
ExpiresByType MIME-Typ Startzeitpunkt Zeit
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_expires
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
5.4 Sonstige Module
433
Mit dieser Konfigurationsanweisung definieren Sie die Dauer der Gültigkeit einer
Information anhand ihres Typs. Als ersten Parameter erwartet die Anweisung die
Angabe eines MIME-Typen, für den die Gültigkeitsdauer gelten soll (z.B. text/html).
Der zweite Parameter definiert den Startzeitpunkt, ab dem eine Gültigkeitsbeschränkung aktiv werden soll (z.B. now, engl. sofort). Mögliche Werte für den zweiten Parameter sind das letzte Änderungsdatum einer Information (M, modification) sowie der
Zeitpunkt des Zugriffs eines Clients (A, Access auch now genannt). Zusätzlich können
Sie durch den dritten und letzten Parameter die maximale Gültigkeitsdauer (in
Sekunden) einer Information definieren, wobei zwischen dem zweiten und dritten
Parameter kein Leerzeichen stehen darf. Dazu folgendes Beispiel:
ExpiresByType text/html M604800
Diese Anweisung sorgt dafür, dass nach einer Änderung (M) an einer Datei vom Typ
text/html die Gültigkeit der geänderten Datei auf eine Woche (=604800 Sekunden)
begrenzt wird. Ein weiteres Beispiel:
ExpiresByType image/gif A2592000
Mit Hilfe dieser Anweisung wird die Gültigkeitsdauer aller Bilder vom Typ image/gif
auf eine Woche festgesetzt, nachdem ein Client diese aufgerufen hat. Der Unterschied
zwischen beiden Anweisungen ist fein: Wenn Sie als Startzeitpunkt das letzte Änderungsdatum einer Datei verwenden, endet die Gültigkeitsdauer einer Information für
alle Clients exakt zum gleichen Zeitpunkt, was beispielsweise für eine immer unter
derselben Adresse verfügbaren und wöchentlich aktualisierten Information sinnvoll
sein kann. Wenn Sie dagegen das Zugriffsdatum eines Clients als Startzeitpunkt für
die Gültigkeitsdauer einer Information verwenden, so endet die Gültigkeitsdauer
einer Information bei jedem Client individuell und unterschiedlich. Diese Einstellung
ist etwa für Inhalte gedacht, die sich nicht besonders häufig ändern (z.B. Bilder und
Grafiken).
Hinweis
Bitte beachten Sie, dass die mit dieser Konfigurationsanweisung vorgenommenen
Einstellungen nur aktiv werden, wenn die ExpiresActive-Anweisung vorhanden und
auf den Wert On gesetzt ist! Außerdem überschreibt diese Anweisung die durch die
Anweisung ExpiresDefault standardmäßig definierte Gültigkeitsdauer für einen definierten Datentyp (z.B. text/html).
Die Anweisungen ExpiresDefault und ExpiresByType können zusätzlich durch
eine etwas lesbarere Form angesprochen werden. Dabei ist die Anzahl der möglichen Parameter identisch, aber die einzelnen Werte können nahezu ausgeschrieben werden. Als Startzeitpunkt der Gültigkeitsdauer einer Information
können daher auch die Begriffe modification (anstatt M), now (identisch mit A)
oder access (anstatt A) dienen. Die Dauer der Gültigkeit lässt sich dadurch durch
die Angabe einer Ganzzahl sowie einer Zeitangabe (years, month, weeks, days,
hours, minutes oder seconds) ausdrücken, wobei die einzelnen Zeitangaben frei
miteinander kombiniert werden können. Folgende Beispielaufrufe bringen hoffentlich Licht ins Dunkle:
434
5 Konfiguration
ExpiresDefault "access plus 1 month"
ExpiresDefault "access plus 4 weeks"
ExpiresDefault "access plus 30 days"
Diese drei Beispiele sind funktional identisch und sorgen dafür, dass alle Informationen einen Monat nach deren Aufruf die Gültigkeit verlieren. Zwei weitere Beispiele:
ExpiresByType text/html "access plus 1 month 15 days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3 minutes"
Hinweis
Das erste Beispiel dient dazu, die Gültigkeitsdauer aller Dateien vom Typ text/html
nach dem Zugriff eines Clients auf einen Monat, 15 Tage und zwei Stunden zu
beschränken. Mit dem zweiten Beispiel beschränken Sie die Gültigkeit aller Bilder
vom Typ image/gif auf fünf Stunden und drei Minuten nach deren letzten Änderung.
Wenn Sie das Änderungsdatum einer Datei als Startzeitpunkt für die Gültigkeitsdauer benutzen, wird der HTTP-Header Expires nicht hinzugefügt, falls
eine Information nicht aus einer Datei des lokalen Dateisystems stammt, da für
derartige Inhalte keine Angaben über den Zeitpunkt der letzten Änderung vorliegen.
ExpiresDefault
ExpiresDefault definiert eine generelle Gültigkeitsdauer für alle Informationen.
Konfigurationsanweisung:
ExpiresDefault
Syntax:
ExpiresDefault Startzeitpunkt Zeit
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_expires
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Um eine generelle Gültigkeitsdauer für alle Informationen zu definieren, können Sie
die ExpiresDefault-Anweisung benutzen. Als einzigen Parameter erwartet die Anweisung die Angabe des Startzeitpunkts, ab dem eine Gültigkeitsbeschränkung aktiv
werden soll (z.B. now, engl. sofort) sowie die Dauer der Gültigkeit einer Information
(in Sekunden). Die beiden Parameter dürfen nicht durch ein Leerzeichen voneinander
getrennt werden und mögliche Werte für den ersten Parameter sind das letzte Änderungsdatum einer Information (M, modification) sowie der Zeitpunkt des Zugriffs
eines Clients (A, Access auch now genannt). Ein Beispiel:
ExpiresDefault A604800
5.4 Sonstige Module
435
Diese Anweisung sorgt dafür, dass alle Informationen nach einer Woche die Gültigkeit verlieren, nachdem ein Client diese abgerufen hat. Hinweis: Bitte beachten Sie,
dass die mit dieser Konfigurationsanweisung vorgenommenen Einstellungen nur
aktiv werden, wenn die ExpiresActive-Anweisung vorhanden und auf den Wert On
gesetzt ist! Weitere Informationen über die Verwendung einer alternativen Syntax
finden Sie in den Ausführungen zur ExpiresByType-Anweisung.
5.4.8
Serverseitige Unterstützung von Image-Maps
Mit Hilfe des Moduls mod_imap können Sie serverseitige Bildkarten, so genannte
Image-Maps, verwenden. Bei einer Bildkarte handelt es sich um ein interaktives Bild,
welches als eine Art Übersichtskarte fungiert und den Benutzer je nach gewähltem
Bereich (Koordinate) auf eine andere Adresse oder Information verweist. Das Modul
verarbeitet .map-Dateien, die eine serverseitige Bildkarte definieren und ersetzt damit
die Funktionalität des CGI-Skriptes imagemap. Dazu müssen Sie, sofern diese nicht
bereits vorhanden ist, folgende Anweisung in der Konfigurationsdatei des Apache
vornehmen:
AddHandler imap-file map
Diese Anweisung sorgt dafür, dass Dateien mit der Endung .map von mod_imap verarbeitet werden. Alternativ ist auch folgende Anweisung möglich, wobei diese in
Zukunft aufgrund der automatischen Dateitypbestimmung durch mod_mime_magic
entfernt werden soll:
AddType application/x-httpd-imap map
Die Verwendung von serverseitigen Image-Maps erfordert Berechnungen und die
zusätzliche Übertragung von Daten zwischen dem Client und dem Server. Es ist
daher generell ratsam, clientseitige Image-Maps zu benutzen, die einfach in das
jeweilige HTML-Dokument eingebunden werden können. Dennoch möchte ich kurz
auf die drei durch mod_imap bereitgestellten Anweisungen eingehen:
ImapBase
ImapBase definiert die Basisadresse für Bildkarten.
Konfigurationsanweisung:
ImapBase
Syntax:
ImapBase map | referer | URL
Standardwerte (Default):
ImapBase http://Servername/
Enthalten in Modul:
mod_imap
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
436
5 Konfiguration
Mit dieser Anweisung definieren Sie die Basisadresse einer Bildkarte. Ein Beispiel:
ImapBase http://www.beispiel.de
Sofern diese Adresse bereits durch eine base-Anweisung innerhalb einer .map-Datei
angegeben worden ist, hat die ImapBase-Anweisung keinerlei Bedeutung. Sollte überhaupt keine ImapBase-Anweisung vorhanden sein, wird als Basisadresse für alle Bildkarten die durch die ServerName-Anweisung definierte Adresse des Servers benutzt.
Weitere Informationen zu den ebenfalls möglichen Parametern map und referer finden
Sie in den Erklärungen zur ImapDefault-Anweisung.
ImapDefault
ImapDefault bestimmt eine Standardadresse für eine Bildkarte, falls für einen Bereich
keine Zieladresse definiert worden ist.
Konfigurationsanweisung:
ImapDefault
Syntax:
ImapDefault error | nocontent | map | referer | URL
Standardwerte (Default):
ImapDefault nocontent
Enthalten in Modul:
mod_imap
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Wenn ein Benutzer auf einen Bereich innerhalb einer Bildkarte klickt, dem keine Zieladresse bzw. -dokument zugeordnet ist, können Sie mit dieser Anweisung eine Meldung definieren, die dem Benutzer angezeigt werden soll. Alternativ ist auch die
direkte Umleitung auf eine andere Adresse möglich. Sofern innerhalb einer .mapDatei bereits eine default-Anweisung existiert, hat die ImapDefault-Anweisung keinerlei Bedeutung. Sollte überhaupt keine ImapDefault-Anweisung vorhanden sein, erhält
der Benutzer beim Auswählen eines nicht definierten Bereiches einer Bildkarte die
Meldung 204 No Content, die ihn auf die Ursprungsseite zurückbringen sollte. Folgende Parameter stehen für diese Anweisung zur Verfügung:
error
Falls ein Benutzer einen Bereich einer Bildkarte auswählt, der nicht definiert ist, erhält
dieser bei Verwendung des Parameters error eine Fehlermeldung (500, Server Error).
Ein Beispiel:
ImapDefault error
nocontent
Der Benutzer erhält beim Auswählen eines nicht definierten Bereiches einer Bildkarte
die Meldung 204 No Content, die ihn meistens auf die ursprüngliche Seite zurückbringt. Dies ist gleichzeitig die vorgegebene Standardeinstellung. Ein Beispiel:
ImapDefault nocontent
5.4 Sonstige Module
437
map
Dieser Parameter entspricht der URL der .map-Datei.
referer
Entspricht der Adresse des referenzierenden Dokumentes. Sollte kein Referer-Header
gesendet worden sein, entspricht dies der durch die ServerName-Anweisung definierten Adresse des Servers.
URL
Verwenden Sie diesen Parameter, wenn Sie den Benutzer auf eine bestimmte Adresse
umleiten wollen. Beispiel:
ImapDefault http://www.beispiel.de/fehler.html
Sollte ein Client einen nicht definierten Bereich einer Bildkarte auswählen, so wird
dieser durch eine derartige Anweisung auf die Adresse http://www.beispiel.de/fehler.
html umgeleitet.
ImapMenu
ImapMenu definiert eine Reaktion, falls eine Bildkarte ohne gültige Koordinaten aufgerufen worden ist.
Konfigurationsanweisung:
ImapMenu
Syntax:
ImapMenu none | formatted | semiformatted |
unformatted
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_imap
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Mit dieser Anweisung bestimmen Sie das Verhalten des Servers, falls eine Bildkarte
ohne gültige Koordinaten (beispielsweise durch einen textbasierten Browser) aufgerufen worden ist. Dabei stehen Ihnen die folgenden Verhaltensweisen als Parameter
zur Verfügung:
none
Bei Verwendung dieses Parameters wird kein Menü erzeugt und das durch die ImapDefault-Anweisung definierte Standardverhalten wird ausgelöst.
formatted
Dies ist die einfachste Form eines Menüs und die Verweise der Bildkarte werden ähnlich einem Verzeichnislisting aufgeführt. Kommentare innerhalb der Bildkarte werden komplett ignoriert.
438
5 Konfiguration
semiformatted
Diese Art der Darstellung des Menüs entspricht in weiten Teilen der Einstellung formatted, wobei Leerzeilen in HTML-kompatible Zeilenumbrüche umgewandelt werden. Außerdem werden Kommentare dort ausgegeben, wo sie innerhalb der Bildkarte auftauchen.
unformatted
Diese Einstellung bezieht die komplette Formatierung aus der Bildkarte, so dass diese
anstatt einfachen Textes HTML-kompatible Anweisungen enthalten muss.
5.4.9
Aufzeichnung des Userverhaltens mit Cookies
(mod_usertrack)
Mit Hilfe von mod_usertrack, welches bereits in früheren Version des Apache unter
dem Namen mod_cookies existierte, können Sie durch so genannte Cookies das Verhalten eines Benutzers in begrenztem Rahmen verfolgen und analysieren. Ein Cookie
(engl. Keks) ist eine kleine Textdatei, die auf dem Computer eines Benutzers angelegt
wird und die nahezu beliebige Informationen über den Benutzer oder dessen (Surf-)
Verhalten enthalten kann. Die Erzeugung eines solchen Cookies erfolgt nur unter
Zustimmung des Benutzers, da dieser die Annahme eines solchen Cookies verweigern und ablehnen kann. Aus diesem Grund halte ich die Analyse des Benutzerverhaltens anhand von Cookies für äußerst unzureichend, da das dauerhafte Vorhandensein eines Cookies nicht gewährleistet ist und von der Akzeptanz des Benutzers
gegenüber Cookies abhängt. Dennoch möchte ich die durch mod_usertrack bereitgestellten Konfigurationsanweisungen kurz vorstellen:
CookieDomain
CookieDomain gibt den Domainnamen an, auf den ein Cookie zutrifft.
Konfigurationsanweisung:
CookieDomain
Syntax:
CookieDomain Domainname
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_usertrack
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Mit dieser Anweisung können Sie einen Domainnamen definieren, auf den ein
Cookie zutrifft, wobei standardmäßig kein Domainname vorgegeben wird. Ein Beispiel:
CookieDomain .beispiel.de
5.4 Sonstige Module
439
Die Anweisung sorgt dafür, dass der Cookie zur Domain beispiel.de passt. Dabei muss
die Angabe eines Domainnamens immer mit einem Punkt beginnen und zusätzlich
mindestens einen weiteren Punkt enthalten (z.B. .beispiel.de).
CookieExpires
CookieExpires setzt die Gültigkeitsdauer eines Cookies.
Konfigurationsanweisung:
CookieExpires
Syntax:
CookieExpires Zeitpunkt
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_usertrack
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Sofern gewünscht, können Sie mit dieser Anweisung die Gültigkeitsdauer eines
Cookies festlegen. Dabei wird die maximale Gültigkeitsdauer als Kombination aus
den Schlüsselwörtern years (engl. Jahre), month (engl. Monate), weeks (engl. Wochen),
hours (engl. Stunden), minutes (engl. Minuten) und seconds (engl. Sekunden) sowie
einer Zahlenangabe gebildet. Drei Beispiele:
CookieExpires 240 minutes
CookieExpires 4 hours
CookieExpires 5 years 3 months 2 weeks
Das erste und zweite Beispiel definieren jeweils eine Gültigkeit von vier Stunden
(=240 Minuten) für einen Cookie. Das letzte Beispiel erzeugt eine Gültigkeitsdauer
von fünf Jahren, drei Monaten und zwei Wochen für einen Cookie. Hinweis: Wenn
eine Zahlenangabe nicht eine einfache Zahl enthält, müssen Sie diese in Anführungsstrichen einschließen. Wenn Sie keine Gültigkeitsdauer definieren, ist ein Cookie nur
für die aktuelle Sitzung gültig und wird unbrauchbar, sobald ein Client die Verbindung zum Server beendet und den Browser schließt.
CookieName
CookieName bestimmt den Namen eines Cookies.
Konfigurationsanweisung:
CookieName
Syntax:
CookieName Zeichenkette
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_usertrack
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
440
5 Konfiguration
Standardmäßig wird als Name eines Cookies das Wort Apache verwendet, wobei Sie
diese Einstellung mit der CookieName-Anweisung ändern können. Erlaubt innerhalb
eines solchen Namens sind Zahlen, Klein- und Großbuchstaben aller Art sowie
Binde- und Unterstriche. Ein Beispiel:
CookieName Leckerer_Keks
Hinweis
Durch eine derartige Konfiguration würde der Name eines Cookies Leckerer_Keks lauten.
In der Version 2.0.48 und 1.3.29 des Apache ist ein Fehler enthalten, der dazu
führen kann, dass bei Verwendung von mod_usertrack einzelne Kindprozesse
abstürzen, wenn die CookieName-Anweisung nicht aktiv ist. Um den Fehler zu
umgehen, sollten Sie die CookieName-Anweisung immer in Ihre Konfiguration
aufnehmen, sofern Sie das Modul mod_usertrack verwenden möchten. Dieser
bekannte Fehler wird in der Version 2.0.49 bzw. 1.3.30 des Apache behoben
sein.
CookieStyle
CookieStyle definiert den Aufbau eines Cookies.
Konfigurationsanweisung:
CookieStyle
Syntax:
CookieStyle Netscape | Cookie | Cookie2 | RFC2109 |
RFC2965
Standardwerte (Default):
CookieStyle Netscape
Enthalten in Modul:
mod_usertrack
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Durch die CookieStyle-Anweisung definieren Sie den Aufbau und das Format der
Cookies, wobei folgende Formate zur Verfügung stehen:
Netscape
Da Cookies ursprünglich durch die Firma Netscape entwickelt worden sind, unterstützt der Apache aus Kompatiblitätsgründen dieses Format, wobei es inzwischen
veraltet ist. Dennoch ist dies der Standardwert dieser Anweisung.
Cookie oder RFC2109
Dieses Format hat das ursprüngliche Netscape-Format abgelöst bzw. verdrängt und
wird mittlerweile von den meisten Browsern unterstützt.
Cookie2 oder RFC2965
Der neueste Aufbau eines Cookies, der ebenfalls von den aktuellen Browserversionen
unterstützt wird.
5.4 Sonstige Module
441
Der Browser eines Clients muss dabei nicht gezwungenermaßen alle möglichen Formate unterstützen und Sie sollten sich deshalb auf die Verwendung des neuesten Formates (Cookie2 oder RFC2965) beschränken.
CookieTracking
CookieTracking schaltet mod_usertrack ein oder aus.
Konfigurationsanweisung:
CookieTracking
Syntax:
CookieTracking on | off
Standardwerte (Default):
CookieTracking off
Enthalten in Modul:
mod_usertrack
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Standardmäßig werden die durch mod_usertrack bereitgestellten Funktionen nicht
aktiviert und müssen erst, sofern mod_usertrack überhaupt vorhanden ist, durch
diese Anweisung explizit aktiviert werden. Ein Beispiel:
CookieTracking on
Mit dieser Einstellung erzeugt der Apache bei jeder neuen Anfrage eines Clients
einen Cookie-Header, sofern der Client nicht bereits einen derartigen Header übermittelt hat. Hinweis: Aus Performancegründen sollten Sie diese Anweisung nur aktivieren, wenn Sie mod_usertrack wirklich brauchen und sollten die Verwendung auf
einen <Directory>- oder <Location>-Container (o.ä.) beschränken. Sofern Sie
mod_usertrack nicht aktivieren möchten, können Sie folgende Anweisung verwenden:
CookieTracking off
Bei Vorhandensein einer derartigen Anweisung werden alle anderen durch
mod_usertrack bereitgestellten Anweisungen ignoriert und die durch mod_usertrack
verfügbaren Funktionalitäten deaktiviert.
mod_usertrack und Protokollierung
In früheren Versionen von mod_usertrack (bzw. mod_cookies) protokollierte das Modul
in eine eigene Datei, die durch die CookieLog-Anweisung definiert werden konnte. In
den aktuellen Versionen des Apache 2 bzw. von mod_usertrack protokolliert das
Modul überhaupt nicht mehr, stattdessen kann die sehr flexible CustomLog-Anweisung benutzt werden, um auch die Protokollierung der durch mod_usertrack gesammelten Informationen zu übernehmen, wobei inzwischen sogar die Verwendung von
getrennten Logdateien mit Hilfe mehrerer CustomLog-Anweisungen möglich ist. Eine
entsprechende CustomLog-Anweisung, die die durch mod_usertrack gesammelten
442
5 Konfiguration
Informationen in einer Datei namens benutzerverhalten_log im Unterverzeichnis logs
der lokalen Apache-Installation speichert, könnte wie folgt aussehen:
Hinweis
CustomLog logs/benutzerverhalten_log "%{cookie}n %r %t"
Aus Kompatiblitätsgründen stellt das Modul die Konfigurationsanweisung
CookieLog weiterhin zur Verfügung, wobei diese Anweisung veraltet ist und
eventuell bald komplett entfernt wird. Die Benutzung der CustomLog-Anweisung ist deshalb ratsam.
5.4.10 Änderung des Zeichensatzes von Antwortseiten
(mod_charset_lite)
Der Apache 2 verfügt mit mod_charset_lite über ein Modul zur automatischen Zeichensatzkonvertierung in EBCDIC- und ASCII-basierten Umgebungen. Das Modul,
welches momentan (Februar 2004) als experimentell gekennzeichnet ist, erlaubt die
Definition eines Ausgangs- sowie Zielzeichensatzes und steuert die Konvertierung
von beliebigen Texten vom Ausgangs- in den Zielzeichensatz, bevor diese Daten an
den Client gesendet werden. Das Modul konvertiert die Daten nicht selbst, sondern
steuert den Konvertierungsvorgang, der durch den Apache übernommen wird. Folgende drei Konfigurationsanweisungen werden durch mod_charset_lite zur Verfügung gestellt:
CharsetDefault
CharsetDefault bestimmt den Zielzeichensatz, in den textbasierte Inhalte konvertiert
werden.
Konfigurationsanweisung:
CharsetDefault
Syntax:
CharsetDefault Zeichensatz
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_charset_lite
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Durch die CharsetDefault-Anweisung definieren Sie den Zielzeichensatz, in den textbasierte Inhalte durch den Apache konvertiert werden sollen. Ein Beispiel:
CharsetDefault ISO-8859-1
Mit Hilfe dieser Anweisung sorgen Sie dafür, dass die vorliegenden Texte in den ISO8859-1 Zeichensatz konvertiert werden, bevor diese an den Client gesendet werden.
Ich empfehle den Aufruf der CharsetDefault-Anweisung in einem beschränkenden
5.4 Sonstige Module
443
Container (z.B. <Directory>-Container), damit die Konvertierung wirklich nur auf
ein gewünschtes Verzeichnis angewendet wird:
<Directory "/usr/local/apache2/htdocs/informationen">
...
CharsetDefault ISO-8859-1
</Directory>
Hinweis
Dieser Container sorgt dafür, dass alle textbasierten Informationen im Verzeichnis
/usr/local/apache2/htdocs/informationen in den Zeichensatz ISO-8859-1 konvertiert werden. Die eventuell vorhandenen, weiteren Konfigurationsanweisungen habe ich
durch drei Punkte angedeutet.
Der Wert des Zielzeichensatzes muss dem Apache bekannt sein und stimmt in
großen Teilen mit dem unter Unix/Linux verfügbaren Programm iconv überein.
Durch folgenden Aufruf können Sie die Konvertierung unter Unix/Linux testen:
# iconv -f UTF-16BE -t ISO-8859-1
Dieser Programmaufruf testet die Konvertierung zwischen dem UTF-16BE und dem
ISO-8859-1 Zeichensatz. Allgemein lautet der Programmaufruf von iconv also wie
folgt:
# iconv -f Ausgangszeichensatz -t Zielzeichensatz
CharsetOptions
CharsetOptions bestimmt das Verhalten von mod_charset_lite.
Konfigurationsanweisung:
CharsetOptions
Syntax:
CharsetOptions Option
Standardwerte (Default):
CharsetOptions DebugLevel=0 NoImplicitAdd
Enthalten in Modul:
mod_charset_lite
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Das Verhalten des Moduls mod_charset_lite können Sie mit der CharsetOptionsAnweisung bestimmen. Als mögliche Parameter stehen folgende Optionen zur Verfügung:
DebugLevel=n
Mit Hilfe dieser Option definieren Sie die Detailtiefe der Protokollierung der (Fehler-)
Meldungen von mod_charset_lite, wobei standardmäßig keinerlei Meldungen erzeugt
werden (n=0). Falls es bei der Konvertierung von Zeichensätzen zu Problemen kommt,
444
5 Konfiguration
können Sie den Wert jeweils um eine Ganzzahl auf neun (n=9) erhöhen, um eine immer
feiner werdende Protokollierung zu erhalten. Die Einstellung n=9 erzeugt dabei ein
Maximum an Meldungen, wobei Sie diese Einstellung mit Vorsicht verwenden sollten,
denn durch die massive Erzeugung von Meldungen wird die Performance des Servers
deutlich verringert! Ein Beispiel:
CharsetOptions DebugLevel=1
Für mod_charset_lite wird durch diese Anweisung die gröbste Protokollierungsebene eingeschaltet, die eine minimale Anzahl an anfallenden (Fehler-) Meldungen
protokolliert.
ImplicitAdd
Dieser Parameter sorgt dafür, dass mod_charset_lite seine Ausgabefilter (XLATEIN
und XLATEOUT) explizit zur Konfiguration des Apache hinzufügen soll. Diese Einstellung macht Sinn, wenn Sie die CharsetDefault-Anweisung benutzen, um einen
Zielzeichensatz für Ihre Texte zu definieren, ohne zusätzlich durch eine AddOutputFilter-Anweisung die durch mod_charset_lite bereitgestellten Ausgabefilter eigens zu
aktivieren. Hinweis: Dieser Parameter ist die Alternative zu NoImplicitAdd und kann
nur stattdessen verwendet werden.
NoImplicitAdd
Wenn Sie die CharsetDefault-Anweisung zur Definition eines Zielzeichensatzes benutzen und durch eine AddOutputFilter-Anweisung die durch mod_charset_lite bereitgestellten Filter manuell aktivieren, können Sie die automatische Aktivierung der Filter
von mod_charset_lite mit dieser Option ausschalten. Hinweis: Auch dieser Parameter
dient als Alternative zu ImplicitAdd und kann nur stattdessen verwendet werden.
Die möglichen Parameter lassen sich beliebig miteinander kombinieren, wobei die
einzelnen Einstellungen durch ein Leerzeichen voneinander getrennt sein müssen:
CharsetOptions DebugLevel=4 ImplicitAdd
Diese Einstellung sorgt dafür, dass bei der Konvertierung von Zeichensätzen die
vierte Protokollierungsstufe durch mod_charset_lite verwendet wird. Zusätzlich werden die durch das Modul bereitgestellten Filter eigens aktiviert und somit eine
AddOutputFilter-Anweisung gespart.
CharsetSourceEnc
CharsetSourceEnc definiert den Ausgangszeichensatz, in dem textbasierte Informationen vorliegen.
Konfigurationsanweisung:
CharsetSourceEnc
Syntax:
CharsetSourceEnc Zeichensatz
Standardwerte (Default):
nicht vorhanden
Enthalten in Modul:
mod_charset_lite
5.4 Sonstige Module
445
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Damit die textbasierten Daten durch den Apache in einen Zielzeichensatz konvertiert
werden können, müssen Sie einen Ausgangszeichensatz definieren, in dem diese
Daten vorliegen. Ein Beispiel:
CharsetSourceEnc UTF-16BE
Diese Konfiguration definiert den Ausgangszeichensatz UTF16-BE und führt im
Zusammenspiel mit einer CharsetDefault-Anweisung dazu, dass die vorliegenden
Texte vom UTF16-BE in den ISO-8859-1 Zeichensatz konvertiert werden, bevor diese
an den Client gesendet werden. Ich empfehle den Aufruf der CharsetSourceEncAnweisung in einem beschränkenden Container (z.B. <Directory>-Container), damit
die Konvertierung wirklich nur auf ein gewünschtes Verzeichnis angewendet wird:
<Directory "/usr/local/apache2/htdocs/informationen">
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
...
</Directory>
Hinweis
Dieser Container sorgt dafür, dass alle textbasierten Informationen im Verzeichnis
/usr/local/apache2/htdocs/informationen vom UTF-16BE Zeichensatz in den ISO-8859-1
Zeichensatz konvertiert werden. Die eventuell vorhandenen, weiteren Konfigurationsanweisungen habe ich auch in diesem Beispiel durch drei Punkte angedeutet.
Der Wert des Zielzeichensatzes muss dem Apache bekannt sein und stimmt in
großen Teilen mit dem unter Unix/Linux verfügbaren Programm iconv überein.
Durch folgenden Aufruf können Sie die Konvertierung unter Unix/Linux testen:
# iconv -f UTF-16BE -t ISO-8859-1
Dieser Programmaufruf testet die Konvertierung zwischen dem UTF-16BE und dem
ISO-8859-1 Zeichensatz. Allgemein lautet der Programmaufruf von iconv also wie
folgt:
# iconv -f Ausgangszeichensatz -t Zielzeichensatz
5.4.11 Emulation der CERN HTTPD-Metdatei-Semantik
(mod_cern_meta)
Mit Hilfe des Moduls mod_cern_meta können Sie die Funktionalitäten der CERNMeta-Dateien des CERN-Webservers unter dem Apache emulieren. Solche Meta-
446
5 Konfiguration
Dateien sind HTTP-Header, die zusätzlich zu den normalen HTTP-Headern an den
Client gesendet werden können. Das Modul ist für Sie nur interessant, wenn Sie vom
CERN-Webserver auf den Apache umsteigen, andernfalls können Sie diesen Teil
getrost überspringen. Weitere Informationen zur Verwendung von CERN-MetaDateien finden Sie im Internet unter http://www.w3.org/pub/WWW/Daemon/User/
Config/General.html#MetaDir. Folgende drei Konfigurationsanweisungen werden
durch das Modul mod_cern_meta zur Verfügung gestellt:
MetaDir
MetaDir bestimmt ein Verzeichnis mit CERN-Meta-Dateien.
Konfigurationsanweisung:
MetaDir
Syntax:
MetaDir Verzeichnis
Standardwerte (Default):
MetaDir .web
Enthalten in Modul:
mod_cern_meta
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Diese Anweisung definiert den Namen eines Verzeichnisses, in dem der Apache die
CERN-Meta-Dateien findet. Normalerweise handelt es sich dabei um ein verstecktes
Unterverzeichnis, welches diese Informationen enthält:
MetaDir .web
Durch eine derartige Anweisung sucht der Apache im Unterverzeichnis .web nach
CERN-Meta-Dateien. Falls der Apache im aktuellen Verzeichnis nach solchen Dateien
suchen soll, können Sie auch folgende Anweisung verwenden:
MetaDir .
MetaFiles
MetaFiles aktiviert oder deaktiviert die Verarbeitung der CERN-Meta-Dateien.
Konfigurationsanweisung:
MetaFiles
Syntax:
MetaFiles on | off
Standardwerte (Default):
MetaFiles off
Enthalten in Modul:
mod_cern_meta
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
5.4 Sonstige Module
447
Mit Hilfe dieser Anweisung aktivieren (on) oder deaktivieren Sie die Verarbeitung
der CERN-Meta-Dateien auf Verzeichnisebene. Ein Beispiel:
MetaFiles on
Generell ist es ratsam, die Verarbeitung solcher Dateien auf bestimmte Verzeichnisse
zu beschränken, indem man einen beschränkenden <Directory>-Container verwendet.
MetaSuffix
MetaSuffix bestimmt eine Dateiendung für CERN-Meta-Dateien.
Konfigurationsanweisung:
MetaSuffix
Syntax:
MetaSuffix Dateiendung
Standardwerte (Default):
MetaSuffix .meta
Enthalten in Modul:
mod_cern_meta
Kontext:
Server-Kontext, VirtualHost-Kontext, <Directory>Container, <Location>-Container, <Files>-Container,
.htaccess-Kontext
Anweisung aktiv:
nein
Diese Anweisung dient zur Definition der Dateiendung für CERN-Meta-Dateien.
Standardmäßig wird die Dateiendung .meta verwendet, so dass eine Anfrage für die
Datei /usr/local/apache2/htdocs/index.html auf die Datei /usr/local/apache2/htdocs/.web/
index.html.meta verweist, um die in dieser Datei enthaltenen, zusätzlichen HTTP-Header zu erzeugen. Die entsprechende Anweisung würde deshalb so aussehen:
MetaSuffix .meta
Voraussetzung für diese Konfiguration ist allerdings, dass das Unterverzeichnis .web
durch die MetaDir-Anweisung als Basisverzeichnis für CERN-Meta-Dateien definiert
worden ist.
5.4.12 Multiprotokoll-Unterstützung:
Das echo-Beispiel-Modul (mod_echo)
Der Apache 2.0 verfügt über eine Art Server-Framework (engl. etwa Rahmensystem)
und bietet eine so genannte Multiprotokollunterstützung, d.h. der Server unterstützt
nicht mehr nur das HTTP-Protokoll, sondern auch eine (beliebige) Reihe andere Protokolle (z.B. POP3 oder FTP). Die Multiprotokollunterstützung steckt zwar momentan noch in den Kinderschuhen, aber ist sicherlich ein interessanter Ansatz. Als Beispiel dazu wurde mod_echo geschrieben, welches einen simplen Echo-Server
bereitstellt. Sofern Sie den Apache mit der Option --enable-echo übersetzt haben, können Sie in der Konfigurationsdatei httpd.conf des Apache folgende Einstellung vornehmen, um den Echo-Server zu aktivieren:
448
5 Konfiguration
ProtocolEcho
ProtocolEcho aktiviert oder deaktiviert einen simplen Echo-Server.
Konfigurationsanweisung:
ProtocolEcho
Syntax:
ProtocolEcho On | Off
Standardwerte (Default):
ProtocolEcho Off
Enthalten in Modul:
mod_echo
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Zur Veranschaulichung der Multiprotokollunterstützung des Apache 2.0 wurde das
Modul mod_echo entwickelt, welches mit der ProtocolEcho-Anweisung nur eine einzige
Konfigurationsanweisung bereitstellt, die den integrierten Echo-Server ein- (on) oder
ausschaltet (off). Ein Beispiel:
ProtocolEcho On
Das Modul ist, ebenso wie die gesamte Multiprotokollunterstützung, noch experimentell und sollte nicht in einer Produktivumgebung eingesetzt werden. Hinweis:
Wenn Sie ein bestimmtes Protokoll einschalten (z.B. Echo oder POP3), wird nur dieses Protokoll ausgeführt, d.h. der normale Webserver ist nicht mehr verfügbar!
Mit der Listen-Anweisung können Sie die Portnummer bestimmen, unter der der
Echo-Server erreichbar sein soll. Wenn der Echo-Server beispielsweise unter der Portnummer 1234 erreichbar sein soll, müssen Sie folgende Einstellung vornehmen:
Listen 1234
Speichern Sie die Konfigurationsdatei des Apache und starten Sie den Server neu.
Verbinden Sie sich nun mit dem Programm Telnet unter Angabe des Ports 1234 auf
Ihren Server:
# telnet localhost 1234
Die Ausgabe des Echo-Servers erscheint und Sie können munter Eingaben vornehmen, die durch den Echo-Server eins zu eins zurückgegeben werden:
Trying 127.0.0.1...
Connected to kingpin.
Escape character is '^]'.
Sobald Sie eine Zeichenkette eingeben (z.B: »Der Apache 2 ist toll!«), wird diese
zurückgegeben:
# Der Apache 2 ist toll!
Der Apache 2 ist toll!
5.4 Sonstige Module
449
Verlassen Sie die Konsole des Echo-Servers und beenden Sie damit die Einführung in
die Multiprotokollunterstützung. Momentan befinden sich zahlreiche Module für
den Apache 2 in der Entwicklung, die u.a. einen POP3- und einen FTP-Server bereitstellen sollen. Weitere Informationen zu diesen Projekten finden Sie unter
http://www.covalent.net!
5.4.13 Auslieferung einer Zufallsdatei mit mod_variety
Für den Aufbau einer Bildergalerie oder Ähnlichem kann das Senden einer Zufallsdatei an den Client ein gewünschtes Verhalten des Apache sein. Mit mod_variety
(http://www.pmade.org/software/mod_variety/), einem Modul, welches von Peter Jones,
dem Autor von mod_injection geschrieben worden ist, existiert für den Apache 2 eine
schnelle und flexible Lösung dieser Aufgabe. Dabei kann das Modul nicht nur
wahllos, sondern auch auf der Grundlage von regulären Ausdrücken und unter Einhaltung einer manuell definierbaren Systembelastung beliebige Dateien aus einem
Verzeichnis des lokalen Dateisystems an den Client schicken. Eine ausführliche Dokumentation von mod_variety (engl. variety, dt. Art, Sorte, Vielfalt) finden Sie unter
http://www.pmade.org/software/mod_variety/download/documentation/manual/sep-html/.
Installation
Um das Modul zu installieren, müssen Sie sich die aktuelle Version 0.2.1 von
http://www.pmade.org/software/mod_variety/download/mod_variety-0.2.1.tar.gz (13 KB)
herunterladen. Entpacken Sie das Modul durch Eingabe von
# tar xvzf mod_variety-0.2.1.tar.gz
Nachdem Sie in das neu entpackte Verzeichnis gewechselt haben (cd mod_variety0.2.1), können Sie die Software wie folgt kompilieren:
Hinweis
# make APXS=/usr/local/apache2/bin/apxs
Sie müssen diese Pfadangabe gegebenenfalls Ihren lokalen Gegebenheiten
anpassen.
Sobald dieser Vorgang abgeschlossen ist, können Sie die Installation der Software wie
folgt vornehmen:
# make install
Um das Modul in den Apache zu integrieren, müssen Sie in dessen Konfigurationsdatei /usr/local/apache2/conf/httpd.conf folgende Zeile eintragen:
LoadModule variety_module modules/mod_variety.so
Speichern Sie die Datei und schließen Sie damit die Installation ab.
450
5 Konfiguration
Konfiguration
Das Modul verfügt über insgesamt vier verschiedene Konfigurationsanweisungen,
die jeweils nur innerhalb eines <Location>- oder <Directory>-Containers aufgerufen
werden können.
Variety
Schaltet die Funktionalität von mod_variety ein oder aus.
Konfigurationsanweisung:
Variety
Syntax:
Variety On | Off
Standardwert (Default):
nicht definiert
Enthalten in Modul:
mod_variety
Kontext:
<Directory>-Container, <Location>-Container
Anweisung aktiv:
nein
Um das Modul mod_variety für ein bestimmtes Verzeichnis zu aktivieren, müssen Sie
die Variety-Anweisung benutzen. Ein Beispiel (Ausschnitt aus der Datei httpd.conf):
Alias /icons/ "/usr/local/apache-2.0.47/icons/"
<Directory "/usr/local/apache2/icons">
Options None
AllowOverride None
Order allow,deny
Allow from all
Variety On
</Directory>
Wenn Sie nach einem Neustart des Apache die Adresse http://localhost/icons/ aufrufen,
wird mod_variety immer eine andere Datei aus diesem Verzeichnis an den Client
senden. Dieses Verhalten können Sie testen, indem Sie in Ihrem Browser die Taste
Aktualisieren beziehungsweise Reload mehrfach betätigen. Falls Sie das Modul für ein
bestimmtes Verzeichnis nicht aktivieren möchten, können Sie folgende Anweisung
verwenden:
Variety Off
VarietyCookies
Bestimmt, ob mod_variety Cookies benutzen soll, um das mehrfache Ausliefern einund derselben Datei zu verhindern.
Konfigurationsanweisung:
VarietyCookies
Syntax:
VarietyCookies On | Off
Standardwert (Default):
nicht definiert
5.4 Sonstige Module
451
Enthalten in Modul:
mod_variety
Kontext:
<Directory>-Container, <Location>-Container
Anweisung aktiv:
nein
Das Modul mod_variety beinhaltet einen recht einfachen Mechanismus, um das
mehrfache Ausliefern derselben Datei an einen Client zu verhindern. Dazu existiert
die Anweisung VarietyCookies, die bestimmt, ob das Modul beim Ausliefern einer
Datei einen Cookie setzen soll oder nicht. Ist die Anweisung aktiv, überprüft
mod_variety vor dem Ausliefern einer Datei erst die Existenz eines entsprechenden
Cookies. Falls ein solcher Cookie vorhanden ist, wird die Datei aus der Liste der verfügbaren Dateien, die an den Client geschickt werden können, gestrichen, da diese
anscheinend bereits gesendet worden ist. Andernfalls wird diese wie gewohnt an den
Client ausgeliefert. Ein gekürztes Beispiel:
<Directory "/usr/local/apache2/icons">
...
Variety On
VarietyCookies On
...
</Directory>
Durch diese Konfiguration wird für jede Datei, die an den Client geschickt wird, ein
entsprechender Cookie gesetzt. Existiert ein solcher Cookie schon, da die entsprechende Datei bereits an den Client gesendet worden ist, wird die nächste Datei nach
dem Zufallsprinzip ausgewählt und die ursprünglich ausgewählte Datei wird aus der
Liste der noch nicht gesendeten Dateien entfernt. Voraussetzung für diese Vorgehensweise ist allerdings, dass der Client einen entsprechenden Cookie akzeptiert.
Standardmäßig ist die Anweisung nicht eingeschaltet und kann manuell deaktiviert
werden:
VarietyCookies Off
VarietyMatch
Sorgt dafür, dass mod_variety nur solche Dateien beachtet, die einem bestimmten
Muster entsprechen.
Konfigurationsanweisung:
VarietyMatch
Syntax:
VarietyMatch Ausdruck
Standardwert (Default):
nicht definiert
Enthalten in Modul:
mod_variety
Kontext:
<Directory>-Container, <Location>-Container
Anweisung aktiv:
nein
452
5 Konfiguration
Unter Umständen kann es sinnvoll sein, die Anzahl und Art der durch mod_variety
beachteten Dateien zu beschränken und beispielsweise nur Bilddateien eines
bestimmten Typs zu beachten. Dazu bietet das Modul mit VarietyMatch eine Anweisung, die auf der Grundlage von regulären Ausdrücken (siehe Anhang), eine selektive Auswahl der durch mod_variety akzeptierten Dateinamen beziehungsweise
Dateitypen vornimmt. Ein Beispiel:
Alias /bilder/ "/opt/stuff/bilder/"
<Directory "/opt/stuff/bilder">
Options None
AllowOverride None
Order allow,deny
Allow from all
Variety On
VarietyMatch [Jj][Pp][Gg]$
</Directory>
Mit dieser Konfiguration würden Sie dafür sorgen, dass mod_variety nur solche
Dateien beachtet, die die Dateiendung .jpg haben, wobei die Groß- und Kleinschreibung der Dateiendung nicht unterschieden wird.
VarietyExclude
Entfernt Dateien aus der Liste der durch mod_variety beachteten Dateien.
Konfigurationsanweisung:
VarietyExclude
Syntax:
VarietyExclude Ausdruck
Standardwert (Default):
nicht definiert
Enthalten in Modul:
mod_variety
Kontext:
<Directory>-Container, <Location>-Container
Anweisung aktiv:
nein
Die VarietyExclude-Anweisung ist das Gegenstück zur vorhergehenden Anweisung
und schließt Dateien mit Hilfe regulärer Ausdrücke aus der Liste der durch das
Modul beachteten Dateien aus. Ein abschließendes Beispiel (gekürzt):
Alias /defcon11/ "/opt/stuff/dfc11/"
<Directory "/opt/stuff/dfc11">
...
Variety On
VarietyExclude [g][i][f]$
...
</Directory>
Dadurch würden Dateien mit der Endung .gif aus der Liste der akzeptierten Dateitypen entfernt. Obgleich die hier vorgestellten Beispiele recht banal sind, ließe sich
durch eine Kombination der VarietyMatch- und VarietyExclude-Anweisung, eine komplexe Dateiauswahl realisieren.
6 Logging
6.1
Logdateien
Die ErrorLog-Datei des Servers, deren Name und Speicherort durch die Direktive
ErrorLog gesetzt wird, ist die wichtigste Logdatei des Apache. In ihr werden detaillierte Informationen über Probleme, Warnungen, Fehlkonfigurationen und Ursachen
von Fehlverhalten des Servers protokolliert. Sollte es während der Ausführung des
Servers zu einem Problem kommen, ist dies die erste Datei, die Sie auf der Suche nach
der Ursache betrachten sollten, da sie detaillierte Informationen und teilweise auch
Lösungen zu aufgetretenen Problemen enthält. Das ErrorLog wird normalerweise in
eine Datei geschrieben, namentlich error_log unter Unix/Linux und error.log unter
Windows. Unter Unix/Linux es ist jedoch auch möglich, den SysLog-Daemon zur
Protokollierung zu verwenden oder diese an ein externes Programm weiterzugeben.
Es enthält zudem auch Informationen, die zur Fehlersuche in CGI-Skripten verwendet werden können.
Das Format der Einträge in der Datei error_log ist relativ frei, es gibt jedoch Elemente,
die in den meisten Logdateien vorhanden sind. Eine typische Meldung kann beispielsweise so aussehen:
[Sun Jul 14 16:10:10 2002] [warn] pid file /usr/local/apache2/logs/httpd.pid
overwritten -- Unclean shutdown of previous Apache run?
Zuerst wird das Datum in der Form Wochentag, Monat, Tag, Stunde:Minute:Sekunde
und Jahr angegeben, danach folgt die Fehlerprotokollierungsebene für die dieser Fehler definiert ist (vgl. LogLevel). Der nächste Teil ist der Wichtigste, denn er enthält die
eigentliche Fehlermeldung:
pid file /usr/local/apache2/logs/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?
Der Server hat ein altes PidFile, d.h. die Datei, die beim Start des Servers mit der Prozess-ID des Servers gefüllt wird, gefunden und überschrieben. Das PidFile wird
eigentlich nach Beendigung des Servers automatisch gelöscht, es sei denn, wie der
Apache hier richtig vermutet hat, die vorherige Serverinstanz wurde unsauber bzw.
abrupt abgebrochen (Meldung: -- Unclean shutdown of previous Apache run). Ich hatte
kurz zuvor den Server bewusst zum Absturz gebracht und somit die oben dargestellte Fehlermeldung erzeugt.
Ein sehr interessanter Eintrag ist folgender, den ich vor einigen Tagen im Logfile
hatte:
[Mon Jul 15 17:59:14 2002] [error] [client 217.37.133.173] Client sent malformed Host
header
Dieser Eintrag bezieht sich auf einen Fehler im Apache, der vor einiger Zeit aufgetaucht ist (vgl. http://www.cert.org/advisories/CA-2002-17.html). Er führt dazu, dass ein
454
6 Logging
Angreifer unter Umständen willkürlichen Programmcode auf dem Server ausführen
kann und bezieht sich auf die Versionen 1.2.2 bis 1.3.24 und 2.0 bis 2.0.36 des Apache.
Ich benutze hier jedoch eine neue Version des Apache und bin insofern vor diesem
Problem gefeit, allerdings zeigt die große Anzahl an derartigen Einträgen im Logfile,
dass es im Internet automatisierte Skripte gibt, die die Webserver nach anfälligen Versionen absuchen und entsprechende Attacken starten.
Sehr oft bekommen die Administratoren eines mit dem Apache betriebenen Webservers Logfile-Einträge (error_log) wie:
[Sat Jun 29 17:04:06 2002] [error]
/usr/local/apache2/htdocs/c
[Sat Jun 29 17:04:06 2002] [error]
/usr/local/apache2/htdocs/d
[Sat Jun 29 17:04:07 2002] [error]
/usr/local/apache2/htdocs/scripts
[Sat Jun 29 17:04:08 2002] [error]
/usr/local/apache2/htdocs/_vti_bin
[Sat Jun 29 17:04:08 2002] [error]
/usr/local/apache2/htdocs/_mem_bin
[Sat Jun 29 17:04:09 2002] [error]
/usr/local/apache2/htdocs/msadc
[Sat Jun 29 18:07:41 2002] [error]
/usr/local/apache2/htdocs/scripts
[Sat Jun 29 18:07:42 2002] [error]
/usr/local/apache2/htdocs/MSADC
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
[client 217.82.6.34] File does not exist:
Oder solche Einträge, die auch sehr nervig sind (access_log):
217.82.115.215 - - [03/Jul/2002:22:57:38 +0200] "GET /d/winnt/system32/cmd.exe?/c+dir
HTTP/1.0" 404 779
217.82.115.215 - - [03/Jul/2002:22:57:43 +0200] "GET
/scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
217.82.115.215 - - [03/Jul/2002:22:57:44 +0200] "GET
/_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
779
217.82.115.215 - - [03/Jul/2002:22:57:46 +0200] "GET
/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
779
217.82.115.215 - - [03/Jul/2002:22:57:51 +0200] "GET
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cm
d.exe?/c+dir HTTP/1.0" 404 779
217.82.115.215 - - [03/Jul/2002:22:57:52 +0200] "GET
/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
217.82.115.215 - - [03/Jul/2002:22:58:03 +0200] "GET
/scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
217.82.115.215 - - [03/Jul/2002:22:58:05 +0200] "GET
/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
217.82.115.215 - - [03/Jul/2002:22:58:07 +0200] "GET
/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
6.1 Logdateien
455
217.82.115.215 - - [03/Jul/2002:23:04:05 +0200] "GET /scripts/root.exe?/c+dir
HTTP/1.0" 404 779
217.37.133.173 - - [15/Jul/2002:17:59:14 +0200] "GET
/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3
%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%
u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 400 342
Diese Einträge sind ärgerlich, jedoch für Sie ungefährlich, da sie sich auf in der Vergangenheit immer wieder aufgetretene Fehler und Probleme des Internet Information
Servers (IIS) der Firma Microsoft beziehen. Wie man an diesem Beispiel gut sehen
kann, handelt es sich größtenteils um ein und dieselbe IP-Adresse (217.82.6.34,
217.72.115.215 bzw. 217.37.133.173). Es ist daher davon auszugehen, dass es sich um
ein automatisiertes Skript handelt, welches das Internet nach anfälligen Servern
absucht und dann entsprechende Attacken ausführt.
Außerdem werden die Zugriffe der Clients auf den Server protokolliert. Den Speicherort dieser Logdateien bestimmt die Anweisung CustomLog, Format und Inhalt
werden durch die Anweisung LogFormat definiert. Natürlich ist neben der Speicherung der Zugriffe auf den Server auch die Analyse und Auswertung dieser Zugriffe
interessant und wichtig. Die Analyse der Logdateien wird in einem späteren Kapitel
besprochen.
In früheren Versionen des Apache gab es mehrere Module zur Protokollierung der
Zugriffe wie mod_log_referer, mod_log_agent und die Konfigurationsanweisung TransferLog. Inzwischen wurde deren Funktionalität jedoch durch die Option CustomLog
zusammengefasst. Hinweis: Die meisten der hier aufgeführten Erläuterungen wurden seit der ersten Auflage des Buches nicht erneuert, da sich keine wesentlichen
Änderungen ergeben haben und die vorhandenen Informationen weiterhin gültig
sind.
6.1.1
ErrorLog
Angabe einer Logdatei, in der diverse Fehlermeldungen des Servers gespeichert werden.
Konfigurationsanweisung:
ErrorLog
Syntax:
ErrorLog [ | ] Dateiname
ErrorLog syslog [:facility]
Standardwert (Default):
ErrorLog logs/error_log (Unix/Linux)
ErrorLog logs/error.log (Window u.a.)
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
456
6 Logging
In der durch diese Direktive gesetzten Datei protokolliert der Server Fehlermeldungen jeglicher Art. Dabei kann es sich z.B. um nicht gefundene Dateien und Verzeichnisse handeln, die durch einen Client angefordert wurden, oder um allgemeine Meldungen des Servers. Auch serverkritische Warnungen über Fehlverhalten des Apache
(z.B. Serverabsturz) werden in dieser Datei gespeichert. Standardmäßig schreibt der
unter der Kennung des root-Benutzers (nur Unix/Linux) laufende Prozess des Apache die Meldungen in eine Datei namens error_log (Unix/Linux) bzw. error.log, die im
Unterverzeichnis logs des Hauptinstallationsverzeichnisses gespeichert wird. Dies
zeigt die folgende Anweisung:
ErrorLog logs/error_log
Wie bei allen Anweisungen, denen kein absoluter Verzeichnispfad vorangeht, bezieht
sich der Pfad des mit dieser Anweisung angegebenen Dateinamens auf die Konfigurationsoption ServerRoot. Die Angabe der Logdatei logs/error_log entspricht in Wirklichkeit der Datei /usr/local/apache2/logs/error_log, sofern die Variable ServerRoot entsprechend auf /usr/local/apache2 verweist. Die Pfadangabe der Logdatei ist auch in
absoluter Form möglich, wie dieses Beispiel beweist:
ErrorLog "/var/log/error_log"
Sie müssen den Wert der Anweisung nicht zwingend in Anführungszeichen schreiben, es sei denn, er enthält Leerzeichen. Unter Windows könnte eine absolute Pfadangabe so aussehen:
ErrorLog "C:/error.log"
Bitte beachten Sie, dass bei allen Verzeichnis- und Dateiangaben unter DOS/Windows, die sonst üblichen Backslashes (»\«) durch Forwardslashes (»/«) ersetzt werden müssen! Ein Tipp: Unter Unix/Linux können Sie mit dem Befehl tail eine Datei
fortlaufend betrachten und die in dieser Datei protokollierten Werte auf dem Bildschirm mitlesen. Um sich den Inhalt des ErrorLog des Apache auf dem Bildschirm
fortlaufend anzeigen zu lassen, können Sie folgenden Befehl verwenden, wenn die
Datei error_log unter /usr/local/apache2/logs zu finden ist (ansonsten müssen Sie den
Pfad entsprechend ändern):
# tail –f /usr/local/apache2/logs/error_log
Wenn Sie keinerlei Informationen über Fehlverhalten des Servers speichern möchten,
können Sie (zumindest unter Unix/Linux) folgende Anweisung zur Deaktivierung
der Funktion nutzen:
ErrorLog /dev/null
Ich möchte jedoch eindringlich davor warnen, die Protokollierung von Fehlermeldungen des Servers auszuschalten, da in vielen Fällen nur mit den im ErrorLog
gespeicherten Informationen eine erfolgreiche Fehlersuche und -bereinigung möglich
ist. Ohne diese Informationen sind im Falle eines Fehlverhaltens des Servers keinerlei
Rückschlüsse auf die vermeidlichen Ursachen möglich und es beginnt ein munteres
Ratespiel.
6.1 Logdateien
457
Falls auf dem von Ihnen verwendeten System (z.B. Linux) ein Syslog-Daemon existiert, können Sie diesen verwenden, um Fehlermeldungen zu protokollieren. Dazu
müssen Sie die Anweisung ErrorLog wie folgt einstellen:
ErrorLog syslog
Sofern keine weiteren Parameter angegeben werden, wird die Syslog-Facility, d.h.
der Syslog-Typ, local7 verwendet, und falls kein entsprechender Eintrag in der Konfigurationsdatei des Syslog-Daemons (meist /etc/syslog.conf) vorhanden ist, wird in
die zentrale Logdatei des Systems (meist /var/log/messages) protokolliert. Die SyslogTypen local0 bis local7 sind auf einem frisch installierten System normalerweise nicht
vergeben und können vom Administrator für Subsysteme wie den Apache benutzt
werden.
Ein typischer Eintrag des Apache in der Datei /var/log/messages, die sich durch den
Befehl
# tail –f /var/log/messages
mitlesen lässt, könnte so aussehen:
Jul 15 11:16:55 kingpin httpd[659]: [notice] Apache/2.0.39 (Unix) configured -resuming normal operations
Jul 15 11:16:55 kingpin httpd[659]: [info] Server built: Jun 26 2002 11:15:30
Jul 15 11:17:09 kingpin httpd[659]: [info] removed PID file
/usr/local/apache2/logs/httpd.pid (pid=659)
Jul 15 11:17:09 kingpin httpd[659]: [notice] caught SIGTERM, shutting down
Anstatt in die Datei /var/log/messages zu protokollieren, die für wichtige Systemmeldungen genutzt wird, ist es sinnvoller, eine eigene Logdatei für den Apache in der
Konfigurationsdatei des Syslog-Daemons zu definieren. Auf dem von mir verwendeten Debian-3.0-System erreiche ich dies durch folgenden Eintrag in der Datei /etc/syslog.conf:
local7.* /var/log/error_log
Sobald Sie den Apache und den Syslog-Daemon neu starten, wird die Datei
/var/log/error_log durch den Syslog-Daemon zur Protokollierung der Meldungen des
Apache benutzt. Falls gewünscht, können Sie der Konfigurationsoption ErrorLog auch
direkt eine Syslog-Facility (z.B. daemon) übergeben, wie die folgende Zeile veranschaulicht:
ErrorLog syslog:daemon
Weitere Informationen über die Verwendung des Syslog-Daemons finden Sie im
Handbuch Ihres Betriebssystems oder in den jeweiligen Manpages (syslogd bzw. syslog.conf). Falls entsprechende Systeme existieren, könnte man die Meldungen des
Apache durch den Syslog-Daemon an einen externen Host weiterleiten und dort sammeln bzw. auswerten. Gerade in einer Umgebung mit einer großen Anzahl an Servern erscheint mir das sinnvoll.
458
6 Logging
Der Apache bietet neben der Erzeugung einer eigenen ErrorLog-Datei und der Protokollierung durch den Syslog-Daemon zusätzlich die Möglichkeit, die Meldungen des
ErrorLog an ein Programm oder Skript zu senden. Wenn die Meldungen des ErrorLog beispielsweise an ein Skript namens log.sh im Verzeichnis /usr/local weitergegeben werden sollen, sieht die entsprechende Anweisung in der Konfigurationsdatei
des Apache so aus:
ErrorLog |/usr/local/log.sh
Bitte beachten Sie, dass zwischen der Pipe (»|«), die die Fehlermeldungen an das Programm auf der rechten Seiten der Pipe weitergibt, und dem eigentlichen Programm,
welches die Meldungen verarbeitet, kein Leerzeichen stehen darf! Sollten Sie dennoch
ein Leerzeichen angegeben haben, erhalten Sie folgende Fehlermeldung und der Server startet nicht:
Syntax error on line 453 of /usr/local/apache2/conf/httpd.conf:
ErrorLog takes one argument, The filename of the error log
Ein sehr simples Programm, welches die Meldungen des Apache ungefiltert in eine
eigene Logdatei schreibt, zeigt dieses Beispiel eines Shellskripts:
#!/bin/sh
logdatei="/usr/local/apache.log"
cat >$logdatei
Falls es beispielsweise unerklärliche und in unregelmäßigen Abständen auftretende
Stabilitätsprobleme mit dem Apache gibt und der Server ab und zu abstürzt, könnte
man in ein solches Skript eine Funktion einbauen, die dem Administrator eine E-Mail
schickt, sobald der Server wieder abgeraucht ist. Dieser könnte sich nach dem Erhalt
der E-Mail mit dem System verbinden und so eventuell den Grund für den Absturz
des Servers finden.
6.1.2
LogLevel
Festlegung einer Wichtigkeitsstufe für die Protokollierung der Serverereignisse.
Konfigurationsanweisung:
LogLevel
Syntax:
LogLevel emerg | alert | crit | error | warn | notice | info
| debug
Standardwert (Default):
LogLevel debug
Enthalten in Modul:
mod_core (Kernmodul)
Kontext:
Server-Kontext
Anweisung aktiv:
ja
6.1 Logdateien
459
Mit dieser Konfigurationsoption kann die Stufe der Protokollierung des Apache festgelegt werden. Möglich sind folgende Protokollierungsstufen, die identisch sind mit
den gleichnamigen Stufen des Syslog-Daemon, geordnet nach absteigender Signifikanz:
emerg: Einen Absturz des Servers bzw. ein Ausfall des Dienstes kennzeichnet diese
Stufe. Es ist ein Notfall eingetreten, das System ist unbrauchbar.
Beispiel: Child cannot open lock file. Exiting
alert: Ein Eingriff des Systemadministrators ist dringend erforderlich.
Beispiel: getpwuid: couldn't determine user name from uid
crit: Kritische Situation, die den stabilen Betrieb des Servers beeinträchtigen kann
Beispiel: socket: Failed to get a socket, exiting child
error: Diese Stufe bezeichnet Fehlermeldungen, die nicht immer wichtig sind, jedoch
zuweilen Beachtung finden sollten. Gerade bei der Fehlersuche in selbst entwickelten Skripten und Programmen liefert diese Stufe oft wertvolle Informationen.
Beispiel: [client 217.82.6.34] File does not exist: /usr/local/apache2/htdocs/_vti_bin oder
Premature end of script headers
warn: Warnmeldungen, die von mittlerer Bedeutung sind, werden in dieser Stufe
vermerkt.
Beispiel: child process 1234 did not exit, sending another SIGHUP
notice: Normale (dennoch nicht unwichtige) Meldungen des Servers sowie die Meldungen über Start, Stopp und Neustart des Apache werden in dieser Stufe protokolliert. Diese Meldungen werden immer protokolliert, unabhängig vom
gewählten LogLevel.
Beispiel: httpd: caught SIGBUS, attempting to dump core in ...
info: Es werden nur reine Informationsmeldungen gespeichert, die keine Fehlersituation beschreiben.
Beispiel: Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)...
debug: Allgemeine Meldungen über Serverinterna, die zur Fehlersuche und -bereinigung genutzt werden können. Dies wird insbesondere von Modulentwicklern
benutzt und ist gleichzeitig die höchste Protokollierungsstufe.
Beispiel: Opening config file ...
Nach der Installation ist der LogLevel auf debug gesetzt, wie die folgende Anweisung
zeigt:
LogLevel debug
460
6 Logging
Die Protokollierung von Fehlern erfolgt automatisch für alle Stufen oberhalb der spezifizierten Stufe, d.h. wird als LogLevel der Parameter warn gesetzt, werden automatisch auch alle Fehler protokolliert, die für die Stufen error, crit, alert und emerg definiert sind.
Die Protokollierungsstufe sollte laut Handbuch des Apache mindestens auf die Stufe
crit gesetzt werden. Ich empfehle sogar, die Option auf den Wert error oder warn zu
setzen. Die Konfigurationsanweisung LogLevel sieht wie folgt aus:
LogLevel warn
6.1.3
CustomLog
Spezifiert den Namen und das Aussehen der Logdatei.
Konfigurationsanweisung:
CustomLog
Syntax:
CustomLog Datei | Pipe Format | Kurzname
[env=[!]Umgebungsvariable]
Standardwert (Default):
CustomLog logs/access_log common (Unix/Linux)
CustomLog logs/access.log common (Windows)
Enthalten in Modul:
mod_log_config
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Die Konfigurationsanweisung CustomLog wird dazu benutzt, die Zugriffe auf den
Server zu protokollieren und in einer Datei, einer so genannten Logdatei zu speichern. Format sowie Aussehen der Logdatei lassen sich sehr frei definieren und die
Protokollierung kann mit Hilfe vorhandener Umgebungsvariablen an bestimmte
Bedingungen gebunden werden.
Der erste Parameter der Anweisung CustomLog bestimmt Namen und Speicherort der
Logdatei, in der die Zugriffe auf den Server gespeichert werden sollen. Dabei gibt es
entweder die Möglichkeit, die Zugriffe in eine Datei zu schreiben, oder durch Angabe
einer so genannten Pipe (»|«) an ein externes Programm zu übergeben, welches die
Daten aus der Standardeingabe liest. Achtung: Sollten Sie dafür ein externes Programm verwenden, wird dieses unter der Kennung des den ursprünglichen Prozess
des Apache ausführenden Benutzers gestartet! In den meisten Fällen entspricht dies
dem root-Benutzer und Sie sollten darauf achten, ein vertrauenswürdiges und sicheres Programm zu verwenden, da es ansonsten möglich ist, auf sicherheitskritische
Bereiche des Servers (vgl. User und Group-Konfigurationsanweisung) zuzugreifen.
Wenn Sie die Zugriffe auf Ihren Server in einer Datei namens access_log (Unix/Linux)
bzw. access.log (Windows) speichern möchten, können Sie dies mit Hilfe der folgenden Konfigurationsanweisung erreichen (Unix/Linux):
CustomLog logs/access_log common
6.1 Logdateien
461
Unter Windows sieht diese Anweisung wie folgt aus:
CustomLog logs/access.log common
Wie immer werden die unter Windows üblichen Backslashes (»\«) durch Forwardslashes (»/«) ersetzt. Erfolgt wie in diesem Beispiel keine absolute Pfadangabe wie
z.B. /usr/local/apache2/logs/access_log, wird der Speicherort der Datei access_log bzw.
access.log relativ zu dem als ServerRoot gesetzten Verzeichnis interpretiert.
Der zweite Parameter der Anweisung CustomLog legt das Aussehen und den Inhalt
der Logdatei access_log (access.log) fest, wobei dies entweder durch eine vorher definierte LogFormat-Anweisung oder durch die direkte Angabe einer Formatierungsanweisung bestimmt wird. Falls eine bereits vorhandene LogFormat-Anweisung das
Aussehen und den Inhalt der Logdatei bestimmt, muss der Option CustomLog der
Kurz- bzw. Spitzname für diese Definition übergeben werden, der in der entsprechenden LogFormat Anweisung deklariert wird. Zur Verdeutlichung möchte ich das
folgende Beispiel für die Anweisung CustomLog vorstellen:
LogFormat "%h %t \"%r\" %>s %b" benutzerdefiniert
CustomLog logs/access_log benutzerdefiniert
Die LogFormat-Anweisung definiert ein bestimmtes Format, welches hier benutzerdefiniert genannt wird. Die CustomLog-Anweisung greift diese Definition auf und benutzt
damit das mit der Anweisung LogFormat vorgegebene Format zur Protokollierung
der Clientzugriffe auf den Server.
Alternativ kann die CustomLog-Anweisung neben dem Namen auch das Format und
den Inhalt der Logdatei definieren, die Benutzung der Anweisung LogFormat entfällt
in diesem Fall. Die folgende Anweisung ist demnach mit der bereits vorgestellten
Variante von LogFormat und CustomLog identisch:
CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
Weitere mögliche CustomLog-Anweisungen sind beispielsweise:
LogFormat
LogFormat
LogFormat
LogFormat
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
"%h %l %u %t \"%r\" %>s %b" common
"%{Referer}i -> %U" referer
"%{User-agent}i" agent
Weitere Hinweise über die Anpassung und die Individualisierung der in der Logdatei access_log gespeicherten Informationen erhalten Sie im Verlauf dieses Kapitels.
Der dritte und letzte Parameter der Konfigurationsoption CustomLog ist optional und
erlaubt die Protokollierung bestimmter Anfragen in Abhängigkeit von vorhandenen
oder nicht vorhandenen Umgebungsvariablen des Servers. Dabei kann diese
bedingte Protokollierung (conditional logging) für jede Clientanfrage definiert werden
und der Server protokolliert mit Hilfe der Module mod_setenvif und/oder
mod_rewrite bei Vorhandensein einer gültigen Anweisung den Zugriff.
462
6 Logging
Wenn Sie beispielsweise jeden Zugriff auf eine .php-Datei statt in Ihre Hauptlogdatei
in eine separate Logdatei schreiben möchten, können Sie folgende Anweisung verwenden:
SetEnvIf Request_URI \.php$ php-dateien
CustomLog php_anfragen.log common env=php-dateien
CustomLog logs/access_log common env=!php-dateien
Weitere Erläuterungen zur bedingten Protokollierung erhalten Sie im Laufe dieses
Buches. Hinweis: Durch das Modul mod_log_mysql (vgl. http://www.bitbrook.de/
software/mod_log_mysql/), welches von Sönke Tesch geschrieben worden ist, können Sie
erstmals die Zugriffe auf den Apache auch in einer MySQL-Datenbank speichern.
6.1.4
LogFormat
Gibt das Aussehen und den Inhalt der in der Logdatei gespeicherten Informationen
an.
Konfigurationsanweisung:
LogFormat
Syntax:
LogFormat Format | Kurzname [Kurzname]
Standardwerte (Default):
LogFormat »%h %l %u %t \"%r\« %>s %b \»%{Referer}i\« \»%{User-Agent}i\"« combined
LogFormat »%h %l %u %t \"%r\« %>s %b« common
LogFormat »%{Referer}i -> %U« referer
LogFormat »%{User-agent}i« agent
Enthalten in Modul:
mod_log_config
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
ja
Die LogFormat-Anweisung spezifiziert das Format und den Inhalt der Logdatei mit
den Zugriffen der Clients auf den Server. Die Logdatei wird entweder mit CustomLog
oder TransferLog gesetzt. Üblicherweise wird das so genannte Common Log Format
(CLF) verwendet, welches durch das World Wide Web Consortium (W3C,
http://www.w3.org/) vorgeschlagen wurde. Es sieht wie folgt aus und ist ein De-factoStandard, der auch von anderen Webservern unterstützt wird:
LogFormat "%h %l %u %t \"%r\" %>s %b" common
Sonderzeichen wie Anführungszeichen müssen mit Backslashes gekennzeichnet werden, optional können spezielle Kontrollangaben wie »\n« für eine neue Zeile und
»\t« für einen Tabulator benutzt werden.
Durch diese Definition sieht ein typischer Logfile-Eintrag beispielsweise wie folgt
aus, die einzelnen Werte sind durch Leerzeichen voneinander getrennt:
1.2.3.4 – – [01/Jul/2002:17:51:20 +0200] »GET /index.html HTTP/1.0« 200 4312
6.1 Logdateien
463
Der erste Wert (%h) ist die IP-Adresse des Clients, der auf den Server zugegriffen
hat. Ist die Konfigurationsoption HostnameLookups aktiviert, versucht der Server bei
jedem Zugriff statt der IP-Adresse eines Clients den vollständigen Hostnamen
herauszufinden und zu speichern. Diese Einstellung ist nicht zu empfehlen, da die
Geschwindigkeit des Servers durch die ständigen DNS-Abfragen merklich gedrosselt wird. Stattdessen sollten Sie ein Programm wie logresolve verwenden, welches
Ihnen im Nachhinein den korrekten Hostnamen zu einer IP-Adresse bestimmt. Bitte
beachten Sie außerdem, dass die IP-Adresse bzw. der Hostname des Clients nicht
unbedingt der wirklichen Adresse des Clients entsprechen muss, wenn dieser beispielsweise über einen zwischengeschalteten Proxy-Server (z.B. Squid o.ä.) und/oder
eine Firewall (Stichwort: IP-Masquerading bzw. Network Address Translation, NAT)
auf den Server zugreift. In diesem Fall wird in dem Logfile die IP-Adresse/der Hostname des Proxy-Servers oder der Firewall auftauchen. Welcher Client hinter diesem
zentralen Server auf Ihren Server zugegriffen hat, können Sie in diesem Fall nicht
eindeutig bestimmen.
Falls eine Information nicht eindeutig bestimmt werden kann, protokolliert der Server wie hier an der zweiten (%l) und dritten (%u) Stelle geschehen, einen Bindestrich
und symbolisiert damit den nicht gefundenen Wert. In diesem Fall kann der Server
die Identität des Clients anhand eines so genannten ident-lookups nicht bestimmen, da
auf den meisten Clients kein ident-Server (vgl. RFC 1413) läuft. Ein solcher Server ist
heutzutage absolut überflüssig und sowieso nur bei einer absoluten Minderheit der
Clients vorhanden. Der Apache versucht deshalb gar nicht erst, den ident-Namen
eines Clients herauszufinden, es sei denn, die Option IdentityCheck ist eingeschaltet.
Die zweite nicht vorhandene Information ist der Name des Benutzers, der anhand
einer HTTP-Authentifizierung bestimmt werden konnte. Da das vorliegende Dokument nicht passwortgeschützt ist, findet keine Authentifizierung statt und der Wert
für den Benutzernamen bleibt leer. Beide Werte können ohne weitere Konsequenzen
vernachlässigt werden!
Viel interessanter sind die weiteren Werte, die das Common Log Format bereitstellt.
Dazu gehört der Platzhalter %t, der das Ende der Bearbeitungszeit der Anfrage eines
Clients speichert. Ein typischer Zeiteintrag sieht derart aus:
[01/Jul/2002:17:51:20 +0200]
Das Zeitformat ist wie folgt definiert:
[Tag/Monat/Jahr:Stunde:Minute:Sekunde +-Zeitzone]
Der Tag, die Stunde, die Minute und die Sekunde müssen dabei in zweistelliger Form
als ganzzahlige Werte angegeben werden. Der Monat muss in dreistelliger Form als
Text erscheinen, das Jahr und die Zeitzone sind jeweils mit vierstelligen, ganzzahligen Werten zu definieren. Die Zeitzone muss außerdem ein Minus- oder Pluszeichen
enthalten. Die Trennung dieser Werte erfolgt wie dargestellt entweder mit Schrägstrichen »/«, Doppelpunkten oder Leerzeichen.
Der nächste Wert (\»%r\«), den der Server protokolliert, ist der vollständige Befehl,
den der Client an den Server gesendet hat. In diesem Befehl sind wertvolle Informa-
464
6 Logging
tionen gespeichert, die insbesondere bei der Entwicklung von CGI-Skripten und Programmen sehr wichtig sein können, wenn Sie Fehler suchen. In unserem Beispiel sendete der Client 1.2.3.4 folgenden Befehl an den Server:
"GET /index.html HTTP/1.0"
Zuerst wird die Methode, mit der der Client auf den Server zugegriffen hat (hier:
GET) gespeichert, gefolgt von der Datei, die der Client angefordert hat (hier:
index.html). Als dritte und letzte Information wird das Protokoll gespeichert, welches
der Client für die Verbindung benutzt hat.
Der vorletzte Wert (%>s), den das Common Log Format definiert, bestimmt den Statuscode, der an den Client gesendet wurde. Dieser Code ist sehr hilfreich, da er festhält,
ob eine gültige Antwort an den Client gesendet wurde (Statuscode beginnt mit 2),
eine Umleitung vorgenommen wurde (Statuscode beginnt mit 3), ein clientseitiger
Fehler (Statuscode beginnt mit 4) oder sogar ein interner Serverfehler aufgetreten ist
(Statuscode beginnt mit 5). Eine Übersicht der Statuscodes (inklusive Erläuterungen)
finden Sie im Anhang dieses Buches.
Der letzte Teil (%b) des Common Log Format gibt die Größe der Daten an, die ohne
HTTP-Header an den Client zurückgesendet worden sind.
Die LogFormat-Anweisung erlaubt außerdem die Definition eines Kurz- bzw. Spitznamens für einen bestimmten Aufbau des Logfiles. Durch Angabe dieses Spitznamens
als Parameter der Option CommonLog werden das Aussehen und der schematische
Aufbau des Logfiles definiert, sofern CommonLog nicht selbst den Aufbau des Logfiles
definiert. Diesen Umstand verdeutlicht das folgende Beispiel:
LogFormat "%h %t \"%r\" %>s %b" benutzerdefiniert
CustomLog logs/access_log benutzerdefiniert
Hier definiert der Befehl LogFormat das vorliegende Format des Logfiles als benutzerdefiniert, der Befehl CustomLog greift auf diesen Spitznamen zurück und protokolliert
die Zugriffe auf den Server entsprechend dem vorgegebenen Format.
6.1.5
TransferLog
Spezifiziert den Speicherort der Logdatei.
Konfigurationsanweisung:
TransferLog
Syntax:
TransferLog Datei | Pipe
Standardwerte (Default):
nicht verfügbar
Enthalten in Modul:
mod_log_config
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
6.1 Logdateien
465
Die Konfigurationsanweisung TransferLog ist mit der Option CustomLog in Funktion
und Syntax identisch, allerdings ist es mit der TransferLog-Anweisung nicht möglich,
dass Aussehen und den Inhalt der Logdatei zu spezifizieren. Stattdessen wird die
zuletzt vorhandene LogFormat-Anweisung benutzt, die jedoch im Gegensatz zur Verwendung mit CustomLog keinen Spitznamen für das jeweilige Logdatei-Format definiert. Falls kein anderes Format angegeben worden ist, wird das Common Log Format
benutzt. Eine gültige Nutzung von TransferLog sieht beispielsweise so aus:
LogFormat "%h %t \"%r\" %>s %b"
TransferLog logs/access_log
Generell ist die CustomLog-Anweisung der TransferLog-Anweisung vorzuziehen, da
diese auch die direkte Definierung eines speziellen Logdatei-Formats sowie die Verwendung von verschiedenen LogFormat-Optionen, die jeweils durch einen Spitzbzw. Kurznamen voneinander unterschieden werden können, erlaubt.
Dennoch möchte ich die Parameter der Option TransferLog kurz erläutern. Entweder
kann als Parameter eine Datei angegeben werden, in die die Zugriffe auf den Server
anhand des zuvor durch eine LogFormat-Anweisung definierten Formats protokolliert
werden, oder ein externes Programm kann die Protokollierung der Zugriffe übernehmen. Wird eine Datei verwendet, kann der Speicherort der Datei entweder in absoluter Form oder in relativer Form zum als ServerRoot definierten Verzeichnis angegeben
werden. Im Folgenden sehen Sie einige Beispiele dazu.
Absolute Pfadangabe:
LogFormat "%h %t \"%r\" %>s %b"
TransferLog /usr/local/apache2/logs/access_log
Relative Pfadangabe:
LogFormat "%h %t \"%r\" %>s %b"
TransferLog logs/access_log
Soll dagegen ein externes Programm die Zugriffe auf den Server speichern, muss dieses mit Hilfe einer so genannten Pipe (»|«) spezifiziert werden, wie das nachfolgende
Beispiel zeigt:
LogFormat "%h %t \"%r\" %>s %b"
TransferLog |/usr/local/apache2/bin/writelog.sh
Bitte beachten Sie wie bereits erwähnt, dass zwischen dem senkrechten Strich (Pipe)
und dem eigentlichen Befehl kein Leerzeichen stehen darf! Außerdem muss der
Dateiname eines externen Programms immer in absoluter Form, d.h. mit vollständiger Pfadangabe erfolgen.
In diesem Beispiel werden die Zugriffe auf den Server im Common Log Format an das
Skript /usr/local/apache2/bin/writelog.sh übergeben, welches die Protokollierung und
Speicherung der Daten übernimmt. Falls dieses Skript, welches die Daten aus der
Standardeingabe (stdin) lesen muss, abstürzt, wird es automatisch durch den Apache
466
6 Logging
neu gestartet. Allerdings laufen Sie gerade bei einer Fehlfunktion oder einem Programmfehler des externen Skriptes Gefahr, dass Logeinträge verloren gehen oder die
Stabilität und die Geschwindigkeit des Apache beeinträchtigt werden.
Sie können natürlich auch die Protokollierung der Zugriffe auf den Server komplett
deaktivieren, in dem Sie z.B. folgende Anweisung benutzen:
LogFormat "%h %t \"%r\" %>s %b"
TransferLog |>/dev/null
Dies würde jeden Zugriff auf den Server im Common Log Format an das unter Unix
und Linux vorhandene Gerät /dev/null, dem Datennirwana, weitergeben und somit
direkt löschen. Eine derartige Einstellung sollten Sie allerdings mit Bedacht wählen,
denn Sie verlieren die Übersicht über die Zugriffe auf den Server und die eventuell
aufgetretenen Fehler. Verwenden Sie deshalb diese Einstellung höchstens auf einem
Entwicklungssystem oder einem minimalen System für statische Inhalte (z.B. Intranetserver mit statischer Menükarte der Kantine).
6.1.6
CookieLog
Definiert den Dateinamen zur Speicherung von Cookies (veraltet).
Konfigurationsanweisung:
CookieLog
Syntax:
CookieLog Datei
Standardwerte (Default):
nicht verfügbar
Enthalten in Modul:
mod_log_config
Kontext:
Server-Kontext, VirtualHost-Kontext
Anweisung aktiv:
nein
Mit Cookies können Sie die Bewegung und die Aktionen eines Benutzers auf Ihrem
Server verfolgen und protokollieren. Die Anweisung CookieLog gibt die Datei an, in
der die Cookies gespeichert werden sollen, wobei die Angabe der Datei entweder in
absoluter Form oder in relativer Form zu dem als ServerRoot gesetzten Verzeichnis
möglich ist. Eine Beispielanweisung:
CookieLog logs/cookie_log
Früher wurde die Anweisung CookieLog durch das Modul mod_cookie, welches inzwischen mod_usertrack heißt, bereitgestellt, aber aus Kompatibilitätsgründen ist diese
Anweisungen ebenfalls im Modul mod_log_config vorhanden.
Alternativ können (und sollten) Sie den Cookie auch in die CustomLog-Anweisung
einbauen und sich dabei die CookieLog-Anweisung sparen, wie folgendes Beispiel
zeigt (sofern Sie an den Cookies überhaupt interessiert sind):
CustomLog logs/access_log "%h %l %u %{Cookie}n %t \"%r\" %>s %b"
6.2 Formatierung der Logdatei-Einträge
467
Natürlich können Sie auch hier das Zusammenspiel zwischen den Optionen CustomLog und LogFormat ausnutzen:
Hinweis
LogFormat "%h %l %u \"%{Cookie}n\" %t \"%r\" %>s %b" sebi
CustomLog logs/access_log sebi
Diese Konfigurationsanweisung ist in neueren Versionen des Apache 2 (z.B.
2.0.48) veraltet und nur noch aus Kompatibilitätsgründen enthalten.
6.2
Formatierung der Logdatei-Einträge
Die beiden Konfigurationsanweisungen CustomLog und LogFormat bestimmen den
Inhalt und das Aussehen der Logdatei des Apache. Die in dieser Datei (access_log
unter Unix/Linux, access.log unter Windows) protokollierten Informationen lassen
sich nach Belieben kombinieren und strukturieren. Es gibt zwar quasi Standardformatierungen wie das Common Log Format oder auch das Combined Log Format, doch
kann es durchaus sinnvoll sein, die Zugriffe auf den Server in einer benutzerdefinierten und damit individuellen Formatierung zu speichern. Neben den aufgeführten
Variablen stehen Ihnen außerdem die in der Programmiersprache C typischen Spezialanweisungen \n und \t zur Verfügung, die einen Zeilenumbruch sowie einen
Tabulator repräsentieren.
Die nachfolgenden Variablen können zum Aufbau und zur Formatierung des von
Ihnen gewünschten Logformates benutzt werden:
%a
Diese Variable enthält die IP-Adresse des auf den Server zugreifenden Rechners.
Steht dieser Rechner hinter einer Firewall oder einem Proxy-Server, erhalten Sie dessen IP-Adresse.
%A
Der Wert %A steht für die lokale IP-Adresse, an die die Anfrage gesendet wurde.
Falls IP-basierende virtuelle Server zum Einsatz kommen, liefert Ihnen die Variable
%A den lokalen Server, an den die Anfrage gegangen ist.
%b
Liefert die Größe der an den Client gesendeten Daten in Byte zurück, allerdings ohne
den HTTP-Header. Man bezeichnet diesen Wert auch als Content Length-Header der
Server-Antwort, da es sich um die Größe (engl. length) des an den Client durch den
Server zurückgesendeten Inhalts (engl. content) handelt. Werden an den Client bei der
Antwort keine Daten gesendet, wird in das Logfile ein Bindestrich (»-«) eingetragen.
%B
Die Variable %B ist identisch mit dem Wert %b, allerdings wird im Gegensatz zur
Variable %b in die Logdatei eine Null geschrieben, wenn der Client bei der Beantwortung seiner Anfrage keine Daten erhalten hat.
468
6 Logging
%{Beispielcookie}C
Gibt den Inhalt des Cookies Beispielcookie aus, der an den Server gesendet wurde.
%D
Enthält die Gesamtdauer in Mikrosekunden, die der Server benötigte, um die
Anfrage eines Clients zu bearbeiten.
%{Beispielvariable}e
Diese Anweisung steht für den Wert der Umgebungsvariablen Beispielvariable, wobei
nur solche Umgebungsvariablen protokolliert werden können, die dem Modul
mod_log_config bekannt sind. Dies sind in den meisten Fällen nicht die Standardumgebungsvariablen des Servers. Achtung: Die Anweisung ist case-sensitiv, d. h., sie achtet auf Groß- und Kleinschreibung der entsprechenden Umgebungsvariablen.
%f
Enthält den vollständigen Pfad der Datei, die ein Client angefordert hat. Ein Beispieleintrag könnte wie folgt aussehen:
/usr/local/apache2/htdocs/index.html
%h
Liefert den Hostnamen des Computers zurück, der auf den Server zugegriffen hat. Ist
die Konfigurationsanweisung HostnameLookups deaktiviert bzw. kann der Apache
den Hostnamen des entfernten Computers nicht bestimmen, wird die IP-Adresse des
zugreifenden Rechners protokolliert. Ist der zugreifende Rechner Teil eines größeren
(Firmen-)-Netzwerks und wird dieser beispielsweise durch eine Firewall und/oder
einen Proxy-Server vor dem bösen Internet geschützt, erhalten Sie die IP-Adresse des
Firewall- bzw. Proxy-Servers.
%H
Enthält das Protokoll (mit Versionsangabe), mit dem der Zugriff durch den Client
stattfand. Üblicherweise handelt es sich um HTTP/1.0 oder HTTP/1.1.
%{Header}i
Sie können den Wert eines bestimmten, durch geschweifte Klammern umschlossenen
HTTP-Header der Clientanfrage mit dieser Anweisung protokollieren. Wenn Sie beispielsweise die Browser-Version oder die Internetseite, von der der Benutzer
ursprünglich kommt (so genannter Referer) protokollieren möchten, können Sie in der
Logformat-Anweisung folgende Definition vornehmen:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog logs/access_log combined
In der Logdatei des Apache wird bei einem Zugriff von meinem Notebook
(192.168.0.2) auf meinen Entwicklungsserver (192.168.0.3) deshalb folgender Eintrag
protokolliert:
192.168.0.2 - - [22/Jul/2002:13:31:32 +0200] "GET / HTTP/1.1" 200 2326
"http://192.168.0.3/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
6.2 Formatierung der Logdatei-Einträge
469
%I
Seit Version 2.0.43 ist das Modul mod_logio in den Apache integriert. Es bietet die
Möglichkeit, durch die Variable %I die Anzahl der eingegangenen Daten (=Input)
einer Anfrage zu erhalten.
%l
Mit dieser Variablen erhalten Sie den so genannten remote logname, d.h. das eventuelle
Ergebnis einer ident-Abfrage an den entfernten Computer. Um eine derartige Abfrage
überhaupt zu starten, muss die Konfigurationsoption IdentityCheck eingeschaltet sein.
In den seltensten Fällen wird diese Abfrage jedoch einen gültigen Wert zurückliefern,
da ein ident-Server (vgl. RFC 1413) auf den meisten Clients nicht vorhanden ist. Falls
auf dem zugreifenden Client doch ein ident-Server vorhanden ist, sendet der Apache
eine Anfrage an den Server und dieser gibt Informationen über die Identität des
zugreifenden Benutzers zurück. Da diese Option selten zu brauchbaren Ergebnissen
führt, gilt sie als veraltet und wird kaum noch genutzt.
%m
Liefert die Zugriffsmethode (z.B. GET oder POST), mit der ein Client auf den Server
zugegriffen hat. Diese ist jedoch auch in der Variablen %r enthalten.
%{Note}n
Der Informationsaustausch zwischen dem Kern des Apache und den Modulen wird
über so genannte Notes realisiert. Gibt man den Namen einer Note in geschweiften
Klammern an, kann man deren Wert protokollieren.
%{Header}o
Neben den Inhalten der HTTP-Header der Clientanfragen lassen sich ebenso die
Inhalte der HTTP-Header der Serverantworten protokollieren. Ein gültiges Beispiel
wäre folgendes:
%{Content-Type}o
%{Last-Modified}o
%O
Seit Version 2.0.43 ist das Modul mod_logio in den Apache integriert und bietet die
Möglichkeit, durch die Variable %O die Anzahl der ausgegangenen Daten (=Output)
einer Anfrage zu erhalten.
%p
Diese Variable enthält den Serverport (TCP), auf den der Client zugegriffen hat (meist
Port 80).
%P
Steuert die Prozess-ID des (Kind-) Prozesses des Apache bei, der die Anfrage des Clients
bearbeitet hat.
470
6 Logging
%q
Enthält den Query-String, inklusive vorangestelltem Fragezeichen, den der Client an
den Server übermittelt hat. Ist kein Query-String übermittelt worden, wird eine leere
Zeichenkette gespeichert.
%r
Liefert die erste Zeile der Anfrage des Clients an den Server. Dieser Befehl ist Teil des
Common Log Format und macht sich im Logfile wie folgt bemerkbar:
"GET / HTTP/1.1"
%s
Enthält den HTTP-Statuscode (z.B. 404), den die Anfrage des Clients zurücklieferte.
Im Falle eines internen Redirect enthält dieser Wert den Status der Ursprungsanfrage.
Deshalb wird die Verwendung von %>s empfohlen, da diese den letzten Status
zurückliefert. Eine Übersicht der einzelnen HTTP-Statuscodes finden Sie im Anhang
dieses Buches.
%t
Gibt die Zeit der Anfrage eines Clients in einer in der englischen Sprachwelt üblichen
Formatierung aus. Diese Formatierung sieht laut Common Log Format so aus:
[Tag/Monat/Jahr:Stunde:Minute:Sekunde +-Zeitzone]
Sie können die Formatierung der Zeit auch ändern, in dem Sie das gewünschte Aussehen an die Variable %t übergeben:
%{%A, der %d. %B des Jahres %Y, um %H Uhr und %M Minuten}t
Die weiteren, möglichen Werte für die Formatierung der Zeit entnehmen Sie bitte
dem Anhang des Buches.
%T
Diese Variable ist identisch mit der Variablen %D und repräsentiert auch die Gesamtdauer, die der Server für die Bearbeitung der Anfrage des Clients gebraucht hat. Im
Gegensatz zu %D wird hier die Dauer jedoch nicht in Mikrosekunden, sondern in
Sekunden angegeben.
%u
Greift der Client auf einen durch eine Authentifizierung geschützten Bereich zu, enthält die Variable %u den durch den Client spezifizierten Benutzernamen. Achtung:
Auch wenn die Authentifizierung beispielsweise aufgrund der Eingabe eines falschen Kennworts fehlschlägt und der Client daraufhin die Statusmeldung 401 (unauthorized) erhält, enthält %u den spezifizierten Benutzernamen.
%U
Gibt den URL-Pfad zurück, auf den ein Client zugegriffen hat. Im Logfile sieht dieser
Wert z.B. folgendermaßen aus:
/index.html.var
6.2 Formatierung der Logdatei-Einträge
471
%v
Der konfigurierte Name eines virtuellen Servers ist durch diese Variable repräsentiert, auch wenn die Konfigurationsanweisung UseCanonicalName deaktiviert ist. Dies
kann unter Umständen sinnvoll sein, wenn Sie beispielsweise ein gemeinsames Logfile für alle virtuellen Server benutzen, jedoch bei der Auswertung wissen möchten,
an welchen Server die jeweilige Anfrage wirklich gerichtet war.
%V
Im Gegensatz zur Variablen %v enthält diese den Namen des virtuellen Servers
gemäß der Einstellung der Option UseCanonicalName. Sollten Benutzer die Mö