Anforderungsdefinition

Diese Dokument ist gedacht als Diskussionsgrundlage und Sammlung aller relevanten Tomcat/HS-Informationen.

Allgemein

HS Mitglieder sollen Tomcat als Teil ihres HS-Pakets nutzen koennen. Die Administration soll so weit als moeglich skriptbasiert ablaufen.

Dieses Dokument beschreibt einen ersten Entwurf, wie die Tomcat-Installation bei HS aussehen kann. Kein Anspruch auf Vollständigkeit oder technische Perfektion, sondern eine erster Vorschlag, was in einem vertretbaren Zeitrahmen machbar ist.

Mitgewirkt an diesem Dokument haben Purodha Blissenbach, Andreas Harth, Peter Hormanns, Michael Hönnig, Jörg Rathlev.

Shared vs Paket-eigener Tomcat

shared Tomcat mit Security-Manager
        - komplexer zu konfigurieren
        - weniger Freiheiten
        + weniger Speicherverbrauch

Paket-eigener Tomcat ohne Security-Manager
        + einfacher zu konfigurieren
        + mehr Features
        - mehr Speicherverbrauch
      

Geplant sind zwei Pakete, ein shared Tomcat mit Security Manager sowie ein paket-eigener Tomcat ohne Security Manager. Für's erste wird es einen paket-eigenen Tomcat geben. Im folgenden wird auch nur der paket-eigene Tomcat beschrieben.

Verzeichnisstruktur

Für jedes Paket wird (analog zur Apache-Konfiguration) ein virtual Host im Tomcat eingerichtet. Die einzelnen Domains im Paket als Aliase. Die JkMount-Direktiven, die das Mitglied wünscht, werden im virtual Host des Paktes in der httpd.conf eingetragen.

Die Verzeichnisstruktur kann folgendermassen aussehen:

  tomcat
   +---bin
   |    +---catalina.sh   das Startskript
   +---conf
   |    +---server.xml    die Tomcat-Konfiguration
   |    +---web.xml
   +---logs               für Log-Dateien
   +---webapps            für die Applikationen
   +---work               Arbeitsverzeichnis des Tomcats
      

Das tomcat/-Verzeichnis liegt unter dem Homeverzeichnis des Paket-Admins. NOCH ZU KLAEREN.

Die server.xml enthält Definitionen, die der Paket-Admin nicht ändern sollte: Ports für den Shutdown des Tomcat, den HTTP-Connector und den AJP-Connector. Dazu die (virtuellen) Hosts.

Mit dem Skript catalina.sh kann der Paket-Admin seinen Tomcat Starten und Stoppen. Dazu muss die Shell-Variable CATALINA_BASE auf sein /home/pacs/.../tomcat zeigen. CATALINA_HOME zeigt dagegen auf die Tomcat-Installation /usr/share/tomcat4.

Security Manager

Der Security Manager ermoeglicht es, Applikationen nur bestimmte Rechte einzuraeumen, z.B. limitierter Zugriff auf Variable wie OS Version, Java Version, Zugriffe auf Dateien etc. Aufgrund noch nicht geloester Probleme in verschiedenen Web-Applikationen wird der Security-Manager erstmal aus bleiben.

Die direkte Programmausfuehrung muesste beim Paket-individuellen Tomcat nicht beschränkt werden, weil der Tomcat mit den Rechten und der uid.gid des PaketAdmin laufen wird.

Installation einer Web-Applikation

Grundsätzlich ist eine Web-Applikation eine ZIP-Datei mit der Datei-Endung ".war", in der alle zugehörigen Objekte enthalten sind (JSPs, kompilierte Java-Klassen (insbesondere Servlets), und Bibliotheken, die nicht bereits im Tomcat vorhanden sind). Diese .war-Datei wir ein Verzeichnis -- meist webapps/ -- kopiert. Danach muss der Tomcat neu gestartet werden. Oder einem laufenden Tomcat wird über den Aufruf einer URL mitgeteilt, dass und wo es eine neue Applikation gibt.

Integration mit Apache

Integration mit Apache laeuft über mod_jk. Es wird von Tomcat-Seite nur http als Protokoll unterstuetzt. https-Verschluesselung kann evtl. durch den Apache uebernommen werden.

Damit ich über den Apache auf den Tomcat zugreifen kann, muss dann noch in der httpd.conf eingetragen werden, welche URIs über das mod_jk an den Tomcat weitergeleitet werden sollen. Dazu kommt in die Konfiguration des virtual Host die Zeile:

	JkMount /myapp/* apj13
      

Dabei ist myapp eine freigewählte URI und apj13 ein Worker, der in der workers.properties Datei des mod_jk definiert wurde.

Tomcat wird so konfiguriert, dass nur das ajp13-Protokoll unterstützt wird. Tomcat hat keinen eigenen http-Listener, kommuniziert mit dem Apache httpd also nur per ajp13. Die Web-Applikation wird zum Beipiel als /webappl im virtual Host des Users eingetragen.

Skripte

Wir brauchen also vier Skripte:

1. Kopieren ins Webapps-Verzeichnis des Tomcat und Auspacken meiner .war-Datei
2. Löschen meiner .war-Datei und des entpackten Verzeichnis im Tomcat.
3. Eintrag der JkMount-Direktiven in der httpd.conf
4. Löschen einer JkMount-Direktive

Bei einem eigenen Tomcat im Paket könnten 1. und 2. natürlich auch von Hand ohne Skript gemacht werden.

Offene Punkte

• Preisgestaltung?
• Verbrauch von Rechenleistung/Arbeitsspeicher beim Einsatz von Tomcat?

Vertagt: Shared Tomcat

• Wie restriktiv werden policy-Dateien gehandhabt wenn der SecurityManager eingesetzt wird?
• Zugriff auf Logfiles fuer den shared Tomcat?
• Mountpoint/Context in der Tomcat-Config

1. Apache-Teil wie bisher
2. Paketeigener Tomcat loggt ins ~/var/ des Paketes.
3. Shared Tomcat Log wird naechtlich gesplitted, in der gleichen Weise, wie derzeit das Apache Log.
4. Shared Tomcat Error Log - Fuer mich unklar: Falls moeglich, werden Errors separat geloggt und diese Logs pro Domain gefuehrt, wie wir's jetzt mit dem Apachen haben. Alternativ koennte man jedem Domain-Admin ein setuid script zur Verfuegung stellen, das das globale Log lesen darf und eine Art `grep domain tomcat-log | tail $1` oder lieber `tail $1 | grep "domain" tomcat-log` macht oder auch `awk "/startzeit/,[/endezeit/]" tomcat.log | grep domain` (schematisch gesprochen, versteht sich)

Quellen

http://server.cybernd.at/main/howto/tomcat.html, Technik-Mailingliste Hostsharing