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

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

Verzeichnisstruktur

/usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien

/usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können

/usr/share/tomcat5.5/conf – Server-Konfigurationsdateien

           - server.xml -- Zentrale Einstellungsdatei 
           - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen

/usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs

/usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken

/usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden

/usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen

/usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen

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.

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.

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.

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.