Tomcat 5.5
Einleitung
Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien. Zudem ist ein kompletter HTTP Server enthalten. In Produktivumgebungen läuft Tomcat meist in Kombination mit Apache, so dass Anfragen an Java Servlets bzw. JavaServer Pages vom Apache über einen Connector- Plugin an Tomcat weitergeleitet werden.
Installation und Dateien
root@zero:~# apt-get install sun-java6-jdk
Tomcat installieren
root@zero:~# apt-get install tomcat5.5
Admin und Manager Web Interfaces:
root@zero:~# apt-get install tomcat5.5-admin
Dokumentation und Beispiel Webanwendungen:
root@zero:~# apt-get install tomcat5.5-webapps
In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:
JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version>
- Konfigurationsdateien: /etc/tomcat5.5/
- Logdateien: /var/log/tomcat5.5/
- Programmdateien: /usr/share/tomcat5.5/bin/
- Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps
- Beispielanwendungen: /usr/share/tomcat5.5-webapps/
Startscript
root@zero:~# /etc/init.d/tomcat5.5 stop root@zero:~# /etc/init.d/tomcat5.5 start
Mit:
root@zero:~# netstat -lntp | grep 8180 tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc
kann verifiziert werden, ob der Server läuft.
Die "manager"- und die "admin"-Anwendungen
Tomcat liefert von Haus aus einige Web-Anwendungen mit. Die Anwendungen "jsp-examples" und "servlets-examples" dienen Einsteigern als mögliche Startpunkte und Beispiele für erste Schritte mit den jeweiligen Technologien. Wichtig ist natürlich auch die Anwendung "tomcat-docs", die die vollständige Doku enthält. Vor allem aber zwei Anwendungen verdienen Beachtung: Die "manager"- und die "admin"-Anwendungen. Die "manager"-Anwendung ermöglicht es, gezielt einzelne Anwendungen zu löschen, neu zu starten, zu stoppen oder auch neue WAR-Dateien aufzuspielen. Zum Hochladen einer neuen Anwendung wird einfach die war-Datei einer Anwendung mittels "Browse" aus dem Dateisystem ausgewählt und dann durch Absenden des Formulars installiert.
Die obige Auflistung der Möglichkeiten der "manager"-Anwendung macht deutlich, dass der Zugriff auf die "manager"-Anwendung gut geschützt werden muss. Ansonsten kann man von "remote" aus den Container komplett lahm legen oder einfach neue Apps aufspielen. Wenn die "manager"-Anwendung überhaupt (außerhalb des eigenen Netzwerkes) sichtbar sein soll, sollte unbedingt sicher gestellt sein, dass die Anwendung nur über eine gesicherte HTTPS-Verbindung genutzt werden kann und dass bei Produktiv-Umgebungen gescheite Passwörter verwendet werden. Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.
Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:
cat /etc/tomcat5.5/tomcat-users.xml <tomcat-users> ... <user username="admin" password="geheim" roles="admin", manager/> ... </tomcat-users>
Danach muss tomcat neu gestartet werden.
Konfiguration des Tomcat Servers (Admin-Anwendung)
Hauptkonfigurationsdatei:
/etc/tomcate5.5/server.xml
Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.
Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.
Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:
Tomcat Server
Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.
Resources
Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.
User Definition
Hier können Benutzer, Gruppen und Rollen verwaltet werden.
Tomcat Server
- Service
Unter einem Service werden alle Connectoren zusammengefaßt, die auf dem gleichen Container arbeiten. So ermöglicht ein Service, dass ein Container über mehrere verschiedene Connectoren erreichbar ist.
- Connector
Ein Connector verbindet Tomcat mit der Außenwelt. Er ist dafür verantwortlich, daß Requests von Clients empfangen und Responses an diese zurückgeschickt werden. Dazu ist er an einen bestimmten Port gebunden.
- Host
Damit mehrere Websites auf dem gleichen Webserver betrieben werden können, wurde das Konzept der " Hosts" entwickelt. In Tomcat werden virtuelle Hosts durch die Schnittstelle Host abgebildet. Sie muß anhand des Requests entscheiden, an welchen Context das Request-Response-Objektpaar weiterzuleiten ist. Jeder Host hat einen Namen und eine (möglicherweise leere) Menge von Aliasnamen. Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.
Optionen zur Server-Konfiguration:
| Name | Bedeutung |
| EnableDNSLookups | Durchführen von Nameserverabfragen |
| URI Encoding | Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben. |
| IP Address | Für Server mit mehr als einer IP Adresse. |
| Secure | SSL Support einschalten. |
| Accept Count | Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind. |
| Compression | Schaltet Kompression ein / aus. |
| Connection Timeout | Timeout |
| Max KeepAlive Requests | Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen |
| Max Spare Threads | Maximale Anzahl unbenutzter Prozesse. |
| Max Threads | Maximale Anzahl der Prozesse. |
| Min Spare Threads | Anzahl Prozesse, die beim Starten gestartet werden. |
| Port Number | Port, auf dem der Server erreichbar ist. |
| Redirect Port Number | Bei SSL Anfragen wird an diesen Port weitergeleitet. |
Verwalten der Anwendungen - Manager Anwendung
Deployen eines bestehenden Web Archives
Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):
- Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps
- Starten Sie Tomcat neu:
Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.
Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“
Deployen von nicht archivierten Dateien
Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.
Deployen mithilfe der Tomcat Administration
Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.Sie finden die vollständige Befehlsliste unter
Komponenten
Server
Server ist der Repräsentant für die JVM-Instanz, in der Tomcat läuft. In jeder Tomcat-Konfiguration existiert daher nur genau ein Server, was auch durch das Root-Element <server> in der "server.xml" deutlich wird. Server ist für den Shutdown-Vorgang von Tomcat verantwortlich, der dadurch ausgelöst wird, daß ein bestimmtes Shutdown-Kommando (standardmäßig "SHUTDOWN") an einen bestimmten Shutdown-Port (standardmäßig 8005) gesendet wird. In Server sind daher Zugriffsmethoden für Shutdown-Kommando und -Port deklariert. Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.
Service
Unter einem Service werden alle Connectoren zusammengefaßt, die auf dem gleichen Container arbeiten. So ermöglicht ein Service, dass ein Container über mehrere verschiedene Connectoren erreichbar ist.
Connector
Ein Connector verbindet Tomcat mit der Außenwelt. Er ist dafür verantwortlich, daß Requests von Clients empfangen und Responses an diese zurückgeschickt werden. Dazu ist er an einen bestimmten Port gebunden. Weiter besteht seine Aufgabe darin, aus dem eingehenden Datenstrom ein passendes Request-Objekt sowie ein leeres Response-Objekt zu erzeugen und dieses Objektpaar dann an den richtigen Container (typischerweise einer Engine) weiterzuleiten. Nachdem dieser seine Arbeit erledigt hat, muß der Connector schließlich das Response-Objekt bzw. im Fehlerfall eine geeignete Fehler-Response an den Client zurücksenden.
Engine
Engine stellt die Catalina-Servlet-Engine und damit die oberste Ebene der Requestverarbeitung dar. Sie entscheidet anhand der Details aus dem Request-Objekt, an welchen der ihr untergeordneten Container (typischerweise Hosts) das Request-Response-Objektpaar weitergeleitet wird.
Host
Damit mehrere Websites auf dem gleichen Webserver betrieben werden können, wurde das Konzept der " Hosts" entwickelt. In Tomcat werden virtuelle Hosts durch die Schnittstelle Host abgebildet. Sie muß anhand des Requests entscheiden, an welchen Context das Request-Response-Objektpaar weiterzuleiten ist. Jeder Host hat einen Namen und eine (möglicherweise leere) Menge von Aliasnamen. Sofern die Tomcat-Konfiguration eine Engine enthält, muß mindestens ein (Default-)Host definiert sein. Fehlt die Engine (weil Tomcat als Add-on betrieben wird), wird auch kein Host benötigt, weil die Context-Zuordnung bereits durch den zugrundliegenden Webserver geleistet wird.
Context
Die Schnittstelle Context repräsentiert die Schnittstelle javax.servlet.ServletContext aus der Java Servlet API gemäß der pro Web-Application genau ein ServletContext festgelegt ist. Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.
Standardklassen
Die verschiedenen Schnittstellen der Catalina-Basisarchitektur werden durch entsprechende Standardklassen implementiert, die im Paket org.apache.catalina.core zusammengefaßt sind. Ihre Namen richten sich nach dem Namen der implementierten Schnittstelle: StandardServer, StandardService, StandardEngine, StandardHost, StandardContext. Die letzten drei erben zusätzlich von der abstrakten Klasse ContainerBase, in der für fast alle Methoden von Container eine die Default-Implementierung vorgenommen wurde.
Konfigurationsdateien
./server.xml
Hauptkonfigurationsdatei des Servers (legt unter anderem auch den Port fest auf dem der Server läuft) Mit den Angaben der server.xml wird der Aufbau des Tomcat-Server beschrieben. Die Tomcat Komponenten können dabei auf verschiedene Weise miteinander kombiniert werden.
./server-minimal.xml
Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.
./web.xml
Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden.
./context.xml
Die Inhalte dieser Datei werden für jede Webapplikation geladen.
./tomcat-users.xml
Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.
./catalina.policy
Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.
./catalina.properties
Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.
./logging.properties
Diese Datei legt die Standardparameter für das Loggin fest.
./Catalina/localhost/host-manager.xml
Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.
./Catalina/localhost/manager.xml
Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.
server.xml
Server
Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion
Attribute:
port: Port für Shutdown auf der IP-Adresse 127.0.0.1
shutdown: Schlüsselwort für Shutdown (Herunterfahren)
Service
Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren
Attribute:
name : Name dieses Services
Connector
Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten
Attribute:
port : TCP-Port, auf dem der Server-Socket horcht
maxHttpHeaderSize : Größe der Header-Informationen in Bytes
maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt
maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben
minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung
enableLookups : führe DNS-Anfrage durch
redirectPort : Umleitung auf einen Port
acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen
connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird
disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.
Engine
Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.
Attribute:
baseDir : Basisverzeichnis dieser Engine.
defaultHost :Vorbelegung des Hostnamens
name : Logischer Name dieser Engine
Host
Virtueller Host mit eigenen Web-Anwendungen
Attribute:
appBase : Wurzel für eigeneWeb-Anwendungen
name : Vollqualifizierter Hostname (mit Domain)
unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird
autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase>
xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen
mlValidation : web.xml auf Gültigkeit überprüfen
Context
Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.
Attribute:
path : Pfad zu dieser Web-Anwendung (URI-Anteil)
Deployer
Clusterweites Deployment von War-Archiven.
Environment
definiert einen Umgebungseintrag (<env-entry>)
Logger / Filelogger
Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei
ErrorLogger
Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr
OutLogger
Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut
web.xml
Während in der server.xml festgelegt wird, wie der Tomcat-Servers konkret aufgebaut sein soll, stehen in der web.xml Angaben zu Standard-Servlets, u.a. dem JSP-Servlet sowie weitere Angaben zu den Einstellungen von Session Timeout und MIME-Typ-Zuweisungen. Es handelt sich dabei um Standardeinstellungen, die für jede Web-Application ergänzt oder überschrieben werden können. Dazu dient eine weitere web.xml, die für jede Web-Application existieren muß.
catalina.policy
Sobald der Security Manager aktiviert ist, darf eine Java-Klasse erst einmal gar nichts mehr. Alle Aktionen wie z.B. das Lesen/ Schreiben von Properties, Dateisystemzugriffe, Socket-Zugriffe sind per se verboten.Mit einer Policy-Datei geben wir nun jede notwendige und von uns gewollte Aktion mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann.
Bsp.: grant codeBase "file:${java.home}/lib/-" { permission java.security.AllPermission; }; Die Regel im ersten Beispiel gibt den JARs (Java Archiv) im Verzeichnis lib der Standard-Java-Installation alle Rechte. Bei den Angaben von Ressourcen im Dateisystem können Platzhalter verwendet werden: 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv, 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.
Realms, Roles und User
Die Benutzerdatenbank von Tomcat wird als Realm bezeichnet. Jeder Datensatz enthält die Attribute Username, Password und Role. Die Role ist mit einer Gruppe in der Benutzerverwaltung des Betriebssystems zu vergleichen. Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden.
In der Standardinstallation sind die Tomcat-Applikationen Admin und Manager so vorkonfiguriert, dass die Benutzer in einem Memory Realm gespeichert sind. Die XML-Datei zur Speicherung der Benutzer ist relativ einfach aufgebaut. Innerhalb des Tags tomcat-users (in der Datei $CATALINA_HOME/conf/tomcat-user.xml) werden die Rollen mit einem role Tag definiert. Jeder Benutzer wird mit einem user Tag definiert. Dieses Tag hat die Attribute name, password und roles. Die Roles, denen der User zugeordnet ist, werden als kommaseparierte Liste im roles Tag festgelegt. Eine Beispiel tomcat-user.xml könnte also wie folgt aussehen:
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <role rolename="manager"/> <role rolename="admin"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="role1" password="tomcat" roles="role1"/> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/> </tomcat-users>
ede Reihe welche mit „<user“ beginnt spezifiziert einen Tomcat User und seine Rolle (den Dienst welchen er ausführen darf). Die vorletzte Zeile legte eine Benutzer namens „xinux“ mit dem Passwort „xinux“ an, welcher auch administrative Rechte besitzen soll, sprich ggf. Tomcat über die Weboberfläche administrieren darf.
Der Unterschied zwischen dem „admin“ und der „manager“ Role besteht darin, dass man als „admin“ unter anderem Services, Host, Connectors, usw. erstellen kann. Ausserdem erhält man Zugriff auf die Benutzer- und Gruppenverwaltung. Als „manager“ hingegen kann man z. B. Applikationen starten, neu starten bzw. stoppen, sich den Serverstatus anzeigen lassen u.ä.
Tomcat SSL
Zertifikat erstellen:
/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA
Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.
Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):
mv .keystore /etc/tomcat5.5/
Anpassung der server.xml: Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen.
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile=“/usr/local/tomcat/conf/.keystore“
keystorePass="xinuxer" />
Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist. Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.
Apache und Tomcat verbinden
mod_jk ist ein Tomcat-Apache Plug-In, das für die Kommunikation zwischen Apache und Tomcat zuständig ist. Die erste Voraussetzung, damit dieser Connector eingesetzt werden kann, ist die DSO Unterstützung von Apache. Diese muss dem Web-Server einkompiliert worden sein. Wenn das folgende Kommando unter anderem "mod_so.c" zurück gibt, ist alles okay - ansonsten muss Apache mit DSO-Unterstützung neu kompiliert werden...
$apache2 -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
Apache JK Connector installieren:
root@zero:~# apt-get install libapache2-mod-jk
Datei jk.conf in /etc/apache2/mods_available/ anlegen:
<IfModule mod_jk.c> JkWorkersFile /etc/apache2/workers.properties JkLogFile /var/logs/apache2/mod_jk.log JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat "%w %V %T" JkMount /TomcatContext/* myworker JkMount /manager/* myworker </IfModule>
Nach mods_enabled verlinken:
root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf
Datei workers.properties unter /etc/apache2/ anlegen:
workers.list=myworker workers.myworker.type=ajp13 workers.myworker.host=localhost workers.myworker.port=8009 workers.myworker.cachesize=10 workers.myworker.socket_keepalive=1 workers.myworker.recycle_timeout=300
Danach muss der apache Webserver neu gestartet werden.