Sowohl der Webserver Apache als auch der Servlet-Container Tomcat werden von der Apache Software Foundation gepflegt. Ein perfektes Zusammenspiel scheint daher selbstverständlich. Doch die Realität sieht anders aus. Dieser Coffee-Shop zeigt Ansätze für eine Lösung.

Verschiedene Entwicklungslinien, viele, aber veraltete Howtos: Die korrekte Konfiguration von Tomcat im Zusammenspiel mit Apache ist ein Abenteuer und für jede Distribution anders zu lösen. Der vor einiger Zeit erschienene Coffee-Shop zum Thema Tomcat[1] hat eine kleine Lawine von Mails ausgelöst. Insbesondere die mit Hinweis auf die ausführliche Dokumentation gemachte Aussage, dass “das Zusammenspiel mit dem Apache in der Version 4 deutlich einfacher zu konfigurieren ist als früher” stimmt so leider nicht.

Diese Folge beleuchtet deshalb zwei Fragestellungen, die in typischen Tomcat-Einführungen zu kurz kommen. Zum einen ist dies die gemeinsame Konfiguration von Tomcat und Apache, zum anderen die SSL-Konfiguration von Tomcat. Die Verbindung beider Themen, also Apache mit »mod_ssl« als Frontend und Tomcat als Servlet/JSP-Backend ist zwar ein realistisches Szenario, würde den Umfang dieser Folge aber bei weitem sprengen.

Mehrweg-Kommunikation

Im Prinzip ist die Zusammenarbeit eines Webservers mit einem dahinter liegenden Servlet-Container einfach. Der Webserver arbeitet gewissermaßen als Proxy und leitet die für den Servlet-Container gedachten Requests an diesen weiter, um dessen Antwort an den anfragenden Client zurückzuschicken.

Ein echter Proxy weiß allerdings wegen der angefragten Webadresse, an welchen Server er sich wenden soll. Beim Apache-Tomcat-Gespann funktioniert das nicht. Der Webserver muss selber wissen, welche Requests er direkt beantwortet und welche er an die Servlet-Engine weiterleitet. Selber wissen bedeutet also, dass entsprechende Einträge in der Apache-Konfigurationsdatei vorhanden sein müssen.

Die Kommunikation zwischen Apache und Tomcat kann unterschiedlich ablaufen. Naheliegend sind normale Netzwerkverbindungen, als Alternative stehen für den Fall, dass Apache und Tomcat auf derselben Maschine laufen, Unix-Sockets oder In-Process-Kommunikation bereit. Bei der letzten Variante startet Apache den Tomcat-Server im eigenen Adressraum (über das Java Native Interface), eine Architektur, die neben dem Vorteil schneller Kommunikation zwei wesentliche Nachteile besitzt: Diese Lösung ist nicht nur weniger robust, sie ist auch nicht skalierbar.

Die Kommunikationsarchitektur zwischen den Servern besteht aus zwei Elementen auf der Apache-Seite und einem Element bei Tomcat. Ein Apache-Modul kann Client-Requests an Tomcat weiterleiten. Das Modul bedient sich hierzu als zweitem Element eines Kommunikationsprotokolls. Das dritte Element ist ein Konnektor auf Tomcat-Seite, er muss – genauso wie das Apache-Modul – das Kommunikationsprotokoll verstehen und verarbeiten können.

Die erfolgreiche Konfiguration des Apache-Tomcat-Tandems besteht also aus drei Schritten: Auswahl des geeigneten Protokolls, Installation und Konfiguration des Apache-Moduls sowie Aktivierung und Konfiguration des entsprechenden Tomcat-Konnecktors.

Entwicklungslinien

Im Laufe der Jahre entstand eine ganze Reihe von Protokollen und entsprechenden Apache-Modulen für die Kommunikation zwischen Apache und Tomcat. Der erste Tomcat-Artikel im Linux-Magazin[2] beschreibt das JServ-Modul, das das so genannte AJP12-Protokoll verwendet hat. Beide – Modul und Protokoll – sind veraltet und sollten nicht mehr verwendet werden. Als Nachfolger hat sich das AJP13-Protokoll etabliert, für ein AJP14-Protokoll liegt ein Diskussionsvorschlag vor

Bei den Modulen und Konnektoren gibt es zurzeit zwei aktive Entwicklungslinien: JK beziehungsweise JK2. Die Konnektoren werden im Coyote-Teilprojekt entwickelt, daher heißen sie auch Coyote-Konnektoren. Beide arbeiten mit dem AJP13-Protokoll. Der JK2-Konnektor wurde explizit in Hinblick auf Apache 2 entwickelt, funktioniert laut Dokumentation aber auch mit dem Apache 1.3 und anderen Webservern wie IIS, IPLanet und Lotus-Domino. Ebenso soll der JK-Konnektor auch mit dem Apache 2 funktionieren.

Damit ergeben sich für Apache mit Tomcat vier Kombinationsmöglichkeiten. Die Dokumentation empfiehlt für den JK2-Konnektor aber explizit Apache 2. Deshalb behandelt dieser Coffee-Shop JK2 nur in der Kombination mit Apache 2. Eine weitere Entwicklungslinie wurde durch »mod_webapp« mit dem so genannten WARP-Protokoll begonnen, das aber explizit die Apache Portable Library voraussetzt. Damit ist der Einsatzbereich dieser Kommunikationsalternative ebenfalls auf Apache 2 beschränkt.

Never change a running system

Kaum ein Admin ist bereit, vom millionenfach bewährten Apache 1.3 auf Apache 2 zu wechseln, nur um Tomcat einfacher anzubinden. Das ist zum Glück auch nicht nötig. Mit »mod_jk«, dem JK-Konnektor und dem AJP13-Protokoll ist eine einfach zu konfigurierende Lösung vorhanden. Apache teilt man dazu durch wenige Zeilen in der »httpd.conf« (an den richtigen Stellen!) mit, dass ein zusätzliches Modul zu laden ist, siehe Listing 1.

Apache-üblich ist je eine »LoadModule«- und »AddModule«-Anweisung notwendig. Die Konfiguration des JK-Moduls ist besser in einer eigenen Datei aufgehoben (hier: »mod_jk.conf«), die »httpd .conf« ist schon lang genug. Es ist Geschmackssache, ob diese Datei im selben Verzeichnis wie »httpd.conf« oder wie in Listing 1 im entsprechenden Tomcat-Verzeichnis liegen sollte. Für die zweite Variante spricht die Abhängigkeit von den definierten Webapplikationen.

Wegweiser zu Tomcat

Das Listing 2 zeigt die Modulkonfiguration. Die erste Zeile verweist auf die Konfiguration der so genannten Tomcat-Worker, die weiter unten näher erläutert werden. Die Zeilen 2 und 3 konfigurieren das Logging. Die Zeilen 47 bis 64 sind im Prinzip für jede Webanwendung zu wiederholen. Zuerst definiert man einen Apache-Alias für eine Webanwendung. Die »JkMount«-Direktiven sorgen dafür, dass eine entsprechende Anfrage von Apache über den definierten Worker (in Zeile 55 der Worker mit dem Namen »roundrobin« und in Zeile 56 mit dem Worker »worker1«) an den Tomcat-Server weitergeleitet wird.

Die Konfiguration gewährleistet, dass Apache den statischen Inhalt selbst ausliefert. Die Zeilen 61 bis 64 sorgen dabei dafür, dass das »WEB-INF«-Verzeichnis geschützt bleibt, wie dies die Servlet-Spezifikation fordert.

Worker übernehmen das Loadbalancing

Jeder Worker ist eine logische Verbindung zu einem Tomcat-Server. Die Auslagerung der Worker-Definitionen in eine eigene Datei (siehe Listing 3) sorgt für die Trennung der Dokument-Sicht (»mod_jk.conf«) von der Transport-Sicht (»workers.properties«).

Auch wenn es sich um eine klassische Java-Properties-Datei handelt: Ein in C geschriebenes Apache-Modul muss sie verarbeiten. In der Datei können beliebig viele Worker mit unterschiedlichen Eigenschaften definiert sein. Die beiden Attribute »port« und »host« sprechen für sich, »type« gibt das Kommunikationsprotokoll an (»ajp13«, »ajp12« oder »jni«). Ein Spezialfall ist der Typ »lb«, der einen Loadbalancer definiert. Dieser verteilt Anfragen auf nachgelagerte Worker gemäß den Gewichten in den »lbfactor«-Attributen.

Mit Hilfe der Worker ist also eine Skalierung auf sehr einfache Weise möglich. Am Anfang stehen ein Tomcat und eine Worker-Definition für alle Webanwendungen. Mit steigender Last bedient ein Apache-Server mehrere Tomcat-Server auf getrennten Rechnern. Dabei können die Tomcat-Server dedizierte Webanwendungen bedienen oder mittels Loadbalancing arbeiten.

Damit wäre die Apache-Seite fertig konfiguriert. Auf der Tomcat-Seite muss jetzt für jeden echten Worker ein entsprechender Konnektor in der Datei »server .xml« eingerichtet sein. Das zugehörige Listing 4 zeigt den relevanten Ausschnitt. Die »server.xml« enthält auskommentiert schon die notwendigen XML-Fragmente, hier ist also nur noch wenig Arbeit notwendig.

Für »mod_jk« können beide AJP13-Konnektoren (Zeilen 111 bis 126 oder 131 bis 140) verwendet werden, im ersten Fall gibt es eventuell eine Fehlermeldung wegen einer fehlenden Datei namens »jk2.properties«, die aber ignoriert werden kann. Wenn alles geklappt hat, sollte nach einem Neustart von Apache und Tomcat ein Aufruf der Seite »http:// localhost/examples/jsp/index.html« eine Übersicht über die JSP-Beispiele zeigen (Abbildung 1).

Insgesamt vier Dateien sind also von Änderungen für das Zusammenspiel von Tomcat mit Apache betroffen: die Apache-Konfiguration »httpd.conf«, die Tomcat-Server-Konfiguration »server.xml« sowie die beiden Dateien »worker.properties« und »mod_jk.conf«. Die ersten drei Dateien müssen einmalig geändert beziehungsweise erstellt werden, letztere Datei muss man bei jeder neuen Webanwendung ergänzen.

Im Standardfall – eine kleine Site mit jeweils einem Apache und Tomcat auf einem Rechner – geht es auch einfacher. Es gibt nämlich einen Listener, der die »mod_jk.conf« bei jedem Neustart von Tomcat automatisch erzeugt. Eine gute Anleitung hierzu gibt es in[3].

0002: ## httpd.conf -- Apache HTTP server configuration file
0004:
0005: ...
0271:
0272: LoadModule jk_module /usr/lib/apache/mod_jk.so
0273:
0274: ...
0278: ClearModuleList
0279: ...
0329: AddModule mod_jk.c
0330: Include /usr/local/tomcat/conf/mod_jk.conf

001: JkWorkersFile /usr/local/tomcat/conf/workers.properties
002: JkLogFile     /usr/local/tomcat/logs/mod_jk.log
003: JkLogLevel error
004: ...
047: Alias /examples "/usr/local/jakarta-tomcat-4.1.12/webapps/examples"
048: <Directory "/usr/local/jakarta-tomcat-4.1.12/ webapps/examples">
049:     Options Indexes FollowSymLinks
050: </Directory>
051:
055: JkMount /examples/servlet/* roundrobin
056: JkMount /examples/jsp/*.jsp worker1
057:
061: <Location "/examples/WEB-INF/">
062:     AllowOverride None
063:     deny from all
064: </Location>

068: worker.list=worker1,worker2
101:
101: worker.worker1.port=8009
102: worker.worker1.host=localhost
103: worker.worker1.type=ajp13
110: worker.worker1.lbfactor=1
111:
112: worker.worker2.port=8010
113: worker.worker2.host=localhost
114: worker.worker2.type=ajp13
115: worker.worker2.lbfactor=2
127:
128: worker.roundrobin.type=lb
129: worker.roundrobin.balanced_workers=worker1,worker2

Neue Wege mit Apache und JK2 …

Einer der Gründe, die für Apache 2 sprechen, ist die bessere Unterstützung von Multithreading. Davon profitiert der Apache unter Windows-Betriebssystemen sicherlich mehr als unter Linux. Tomcat ist jedenfalls von diesen Architekturänderungen nur in einem Spezialfall betroffen: Falls es innerhalb des Apache-Adressraums läuft, ist Multithreading-Support notwendig, da Java von seiner Architektur her Thread- und nicht Prozess-zentriert ist. Tomcat innerhalb von Apache starten bietet zwar Vorteile bei der Performance, ist aber insgesamt weniger robust, denn wenn sich der Tomcat aufhängt, ist auch der Webserver neu zu starten.

Indirekt profitiert Tomcat aber auch vom Apache 2, nämlich in Form des neu implementierten »mod_jk2«. JK2 trennt das logische Kommunikationsprotokoll (AJP13) sauber vom physischen Kommunikationsprotokoll und erlaubt deshalb neben der normalen Netzwerkkommunikation auch die Kommunikation mittels Unix-Sockets oder Shared Memory. Das hat Performancevorteile, falls Apache und Tomcat auf demselben Server laufen. Darüber hinaus ist die Implementation neuer Protokolle (wie des schon erwähnten AJP14) einfacher.

Mit der neuen Architektur kamen auch neue Formate für die Konfigurationsdateien. Was bleibt, sind die Aktivierung der AJP13-Konnektoren in der »server .xml« und das Laden des »mod_jk2«-Moduls in der »httpd.conf«. Im Gegensatz zum »mod_jk« wird aber die »mod_jk2«-Konfiguration nicht über eine Include-Direktive in die »httpd.conf« eingefügt (wie dies bei »mod_jk« üblich ist, siehe Zeile 330 in Listing 1). Vielmehr sucht »mod_jk2« seine Konfigurationsdatei an einem festen Ort.

Abbildung 1: Einstiegsseite: JSP-Beispiele über Apache (Browser: W3m).

Abbildung 2: Status-Info über »mod_jk2« (Browser: W3m).

Abbildung 3: Warnung des Konqueror bei selbst signierten Zertifikaten.

111:     <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009/10 -->
112:
113:     <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
114:         port="8009" minProcessors="5" maxProcessors="75"
115:         enableLookups="true" redirectPort="8443"
116:         acceptCount="10" debug="0" connectionTimeout="20000"
117:         useURIValidationHack="false"
118:         protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
120:
121:     <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
122:         port="8010" minProcessors="5" maxProcessors="75"
123:         enableLookups="true" redirectPort="8443"
124:         acceptCount="10" debug="0" connectionTimeout="20000"
125:         useURIValidationHack="false"
126:         protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
128:
129:     <!-- Define an AJP 1.3 Connector on port 8009 -->
130:     <!--
131:     <Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
132:         port="8009" minProcessors="5" maxProcessors="75"
133:         acceptCount="10" debug="0"/>
134:     -->
135:     <!-- Define an AJP 1.3 Connector on port 8010 -->
136:     <!--
137:     <Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
138:         port="8010" minProcessors="5" maxProcessors="75"
139:         acceptCount="10" debug="0"/>
140:     -->

… und neue Config-Dateien

Das ist der erste Stolperstein, denn im Gegensatz zum JK-Modul hat die JK2-Konfigurationsdatei den festen Namen »workers2.properties« und liegt stets im » ServerRoot/conf«-Verzeichnis. » ServerRoot« ist in der »httpd.conf« definiert, normalerweise als »/usr/local/httpd« oder FHS-konform als »/srv/www«. Das Listing 5 zeigt eine solche »workers2 .properties«, die in etwa der »mod _jk«-Konfiguration aus Listing 2 entspricht, das heißt, dass sie die Kommunikation über normale Netzwerk-verbindungen abhandelt.

Status-Informationen zum JK2-Modul sind über die URI »http:/localhost/jkstatus/« zu erhalten (Abbildung 2), hier erfolgt die Kommunikation mit Hilfe von Shared Memory. Das JK2-Modul verhindert selbstständig den Zugriff auf ein »WEB-INF«-Verzeichnis, eine entsprechende Konfiguration wie beim JK-Modul (Listing 2, Zeilen 61 bis 64) ist nicht notwendig.

Der Standard-AJP13-Konnektor öffnet einen Serversocket und wartet auf eingehende Requests. Mit JK2 ist dies allerdings nicht mehr so einfach, denn schließlich könnte das Modul beispielsweise auch Unix-Sockets nutzen. Um hier Ordnung zu schaffen, ist auf der Tomcat-Seite etwas mehr Aufwand erforderlich.

01: [logger]
02: level=DEBUG
03:
04: [config:]
05: file=${serverRoot}/conf/workers2.properties
06: debug=0
07: debugEnv=0
08:
09: [shm:]
10: info=Scoreboard. Required for reconfig/status
11: file=${serverRoot}/logs/shm.file
12: size=1000000
13: debug=0
14: disabled=0
15:
16: [workerEnv:]
17: info=Global server options
18: timing=1
19: debug=0
20:
21: [channel.socket:worker1]
22: port=8009
23: host=localhost
24: lbfactor=1
25:
26: [ajp13:worker1]
27: channel=channel.socket:worker1
28:
29: [uri:/examples/*]
30: worker=ajp13:worker1
31:
32: [status:jk2info]
33:
34: [uri:/jkstatus/*]
35: worker=status:jk2info

Konnektor-Konfiguration

Der Tomcat-JK2-Konnektor (Zeilen 111 bis 126 in Listing 4) liest zusätzlich die Datei »jk2.properties« (Listing 6) im »conf«-Verzeichnis von Tomcat ein. Sie muss der »workers2.properties« entsprechen. Auch wenn das alles kompliziert klingt, ist die Konfiguration doch schnell durchgeführt, insbesondere bei funktionierenden Vorlagen. Die Konfigurationsdateien sind kurz und übersichtlich. Schwieriger ist dagegen die Installation: Bei ihr beginnt das klassische Distributionenroulett.

Den Apache liefert heute jede Distribution mit, meist sogar in beiden Versionen, Tomcat ist jedoch nicht immer dabei. In Debian Woody ist es enthalten (in den Versionen 3.3a und 4.0.3, neuere Versionen gibt es wie üblich bei Debian in den aktuellen Zweigen), ebenso in der neuen SuSE 8.2 Professional. Red-Hat-Distributionen haben Tomcat überhaupt nicht an Bord.

SuSE, Red Hat & Co.

Bei den Modulen stellt SuSE seit 8.2 alle drei (JK, JK2 und Webapp) zur Verfügung: die Versionen für Apache 1.3 im Tomcat-RPM, die Versionen für Apache 2 als eigenes RPM. Debian Woody enthält Packages für »mod_jk« und »mod _webapp«.

Besitzer von Distribution, die hierfür keine fertigen Pakete bieten, müssen oftmals selbst zum Compiler greifen, denn unterschiedliche Libc-Versionen und Apache-Optionen (zum Beispiel mit beziehungsweise ohne DSO) verhindern die Nutzung der auf der Apache-Website verfügbaren Binärpakete. Ganz zu schweigen von den dort verfügbaren RPMs: Die Pfade der Module passen selbst beim weit verbreiteten Red Hat nicht notwendigerweise zu den Pfaden, in denen das Apache-RPM der Distribution die Module ablegt.

Aus Sicherheitsgesichtspunkten sind aber selbst kompilierte Versionen recht kritisch, denn damit ist es nicht mehr möglich, einfach die Security-Updates des Distributors einzuspielen – der Betreuungsaufwand der Installation steigt entsprechend an.

SuSE ist mit der Tomcat-Einbindung in Version 8.2 auf dem richtigen Weg, aber noch nicht ganz angekommen. Die sauber ins Boot-Konzept eingefügten Start-/Stop-Skripte überzeugen. Auch ist es ein deutlicher Fortschritt, dass die Module überhaupt verfügbar sind. Für »mod_jk« gibt es eine beinahe out of the box einsetzbare Konfigurationen. Für »mod_webapp« wird dagegen eine Konfiguration mitgeliefert, die Syntaxfehler enthält, und für das moderne »mod_jk2« fehlt sie ganz.

Tomcat und SSL

Ein Randthema im Vergleich zur Tomcat-Apache-Integration, doch trotzdem sehr wichtig ist die SSL-Konfiguration von Tomcat. Tomcat bietet für SSL-Kommunikation einen eigenen Konnektor, er ist in der Konfigurationsdatei »conf/server.xml« enthalten, aber auskommentiert. Eine weitere Voraussetzung sind die Java Secure Socket Extensions (JSSE), die im Coffee-Shop[4] beschrieben wurden. Wer nicht das JDK/JRE 1.4 im Einsatz hat (es enthält schon die JSSE), lädt sie als Zusatzpaket von[5] herunter. Die entsprechenden Jar-Dateien sind anschließend nach »$JAVA_HOME/jre /lib/ext« zu kopieren.

Die Authentifizierung bei SSL-Verbindungen erfolgt über Zertifikate. Für Java speichert man die Zertifikate in einer als Keystore bezeichneten Datei. Um ein Zertifikat in diese Datei zu importieren, gibt es das »keytool«-Programm. Für Test- und Entwicklungszwecke ist ein selbst signiertes Zertifikat die einfachste Lösung. Das Kommando

keytool -genkey -alias tomcat -keyalg RSA

erzeugt das Zertifikat samt Keystore-Datei. Wichtig dabei ist, dass das Passwort für das Zertifikat und den »keystore« jeweils »changeit« lautet. Der Keystore findet sich im Homeverzeichnis des Benutzers in der Datei ».keystore«. Läuft Tomcat unter einem eigenen Account, muss die Datei im Homeverzeichnis dieses Accounts liegen.

Auch ein anderes Passwort als »changeit« ist möglich, es muss nur in die »conf/server.xml« eingetragen werden. Wer mehr Sicherheit haben will oder muss, kommt um ein Patchen des Quellcodes und die Neukompilierung von Tomcat nicht herum.

001: # Set the desired handler list
002: handler.list=channelSocket
003:
004: # Override the default port for the socketChannel
005: channelSocket.port=8009
006: channelSocket.maxPort=8010
007: channelSocket.address=127.0.0.1
008:
009: # apr.jniModeSo=/usr/lib/apache2/mod_jk2.so

001: <?xml version="1.0" encoding="ISO-8859-1"?>
002:
003: <!DOCTYPE web-app
004:     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
005:     "http://java.sun.com/dtd/web-app_2_3.dtd">
006:
007: <web-app>
009:     <display-name>Tomcat Examples</display-name>
010:     ...
206:     <security-constraint>
208:       <web-resource-collection>
209:          <web-resource-name>Protected Area</ web-resource-name>
211:          <url-pattern>/jsp/security/protected/*</url-pattern>
212:          ...
217:       </web-resource-collection>
218:       ...
223:       <user-data-constraint>
224:         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
225:       </user-data-constraint>
226:     </security-constraint>
227:     ...
300: </web-app>01 <html>

Umleiten auf SSL-geschützte Seiten

Nach Aktivierung des SSL-Konnektors und Erzeugung des Keystores genügt ein Neustart von Tomcat. Der SSL-Konnektor lauscht auf Port 8443. Ein kurzer Test mit der Webadresse »https://localhost :8443/« sollte dann die Tomcat-Hauptseite über HTTPS anzeigen. Ein korrekt konfigurierter Browser warnt bei einem selbst signierten Zertifikat (Abbildung 3). Bei Problemen empfiehlt sich ein Blick in die Datei »logs/catalina.out«, in der die protokollierten Exceptions abgelegt werden.

Läuft Tomcat mit SSL-Unterstützung, bleibt als letzter Schritt die Konfiguration der Webanwendungen. In der Datei »web.xml« der Anwendung konfiguriert man dazu einen Security-Constraint, genauer eine »transport-guarantee« innerhalb eines »user-data-constraint« (siehe Listing 7). Ruft man jetzt »http://localhost:8080/examples/jsp/security/pro- tected/index.jsp« auf, wird man automatisch auf »https://localhost:8443/…« umgeleitet. Die drei zusätzlichen Zeilen 223 bis 225 reichen also aus, um die im Security-Constraint definierten Seiten zu schützen.

finally{}

Konfigurations- und Installationsprobleme: Die Apache-Tomcat-Integration bietet alles an Herausforderungen, was Sysadmins und Systemintegratoren für ihren Job brauchen. Natürlich wäre das Leben einfacher, wenn Softwarehersteller und Distributoren bessere Dokumentationen und Beispiele lieferten. Andererseits hat Software, die zu einer tief greifenden Auseinandersetzung zwingt, auch Vorteile. Der Administrator versteht die Architektur und eigens erstellte Konfigurationen sorgen für mehr Performance und weniger Overhead als Default-Konfigurationen, die für alle Situationen etwas mitbringen müssen.

Dass unreflektiert übernommene Standardkonfigurationen Sicherheitslücken bieten, zeigen viele Windows-Server und leider auch frühere Versionen von Linux-Installationen. (uwo)