!!!Tomcat

[Tomcat|http://tomcat.apache.org/] ist eine "Servlet Engine", d.h.
eine Art Webserver für Java-Klassen, der es enorm erleichtert,
Webservices aufzusetzen und allgemein zugängliche Dienste unter
Java anzubieten. In seiner Funktion ist er z.B. vergleichbar mit
einem mod_perl unter Apache (ohne dabei die Funktionsvielfalt und
Performance des Apache im Bereich des reinen Webservers erreichen
zu wollen).

Die Entwicklung von eigenen Applikationen haben wir auf der Seite
WebAnwendungenMitEclipse zusammengefasst.


!!Tomcat 5.5 mit Debian Etch

Wenn man Applikationen einspielen möchte, die mit einer neueren JVM von Sun erzeugt wurden (die also z.B. Java 5 oder 6 benutzen), rate ich dazu, den Tomcat auch mit derselben JVM laufen zu lassen. In meinem Falle die von Sun:

 aptitude install sun-java5-jdk
 aptitude install tomcat5.5 tomcat5.5-admin

Nach dem Abschalten des Security Managers und dem Eintragen von Usern konnte ich dann auch auf die Manager- und Admin-Applikation zugreifen.

!!!Konfiguration des Debian-Paketes

!Security Manager

Das war einfach. Nun ist Debian eine besonders sichere
Distribution. Der Tomcat läuft per default mit eingeschaltetem
Security-Manager. Er darf fast nichts. Auf meinem Rechner im
lokalen Netz schalte ich den Security-Manager also zunächst mal
aus:

In der Datei /etc/default/tomcat5.5 die Variable TOMCAT5_SECURITY auf
"no" setzen und den Tomcat mit

 /etc/init.d/tomcat5.5 restart

neu starten.

Um den Security Manager auf die richtige Art und Weise zu
besänftigen, muss man Zugriffrechte setzen. Dazu schreibt man in
die Datei /etc/tomcat5.5/policy.d/50myapplication.policy sowas wie
dieses:


 grant {
    permission java.security.AllPermission;
    // permission java.net.SocketPermission "localhost", "connect";
 };


Dieses Beispiel schaltet jetzt ebenfalls die Sicherheit komplett
aus, ist aber als Ausgangspunkt für dediziertere Freigaben besser
geeignet. Prinzipiell kann man jeder einzelnen Klasse seines
Projektes eigene Fähigkeiten geben. So kann man z.B. Zugriffe auf
das normale Filesystem nur einer besonderen Zugriffsklasse
gewähren, die man dann besonders durch Sicherheitsabfragen
absichert.

!welches Java Runtime Environment?

Man sollte übrigens - je nachdem, wie man Java installiert hat -
unbedingt in /etc/default/tomcat5.5 das '''$JAVA_HOME''' auf das
gleiche setzen, das man auch bei der Entwicklung bzw. mit der
EclipseIDE benutzt, sonst können diffizile Unterschiede zwischen
den VMs oder den Bibliotheken auftreten (spätestens beim
Debugging). Unter Debian Etch wird das im Prinzip automatisch gemacht,
wenn man nicht mehrere JVMs parallel installiert hat.

Ich habe in /var/lib/tomcat5.5/conf/tomcat-users.xml die Rollen
"manager" und "admin" und einen User mit diesen Rollen eingetragen, um Tomcat
per '''Manager'''-Webschnittstelle managen zu können (wenn man das
tomcat5.5-admin-Paket mitinstalliert hat). Interessant ist das auch,
da es damit auch möglich ist, Applikationen per Ant-Kommandos zu
installieren.


!!Tomcat pro User (Installation ohne Debian-Paket)

Zur Zeit (August 2006) ist es so, daß der aktuelle Tomcat 5.5 als
Debian-Paket nicht zur Verfügung steht, also sollte man diese Form
der Installation erwägen. Normalerweise bin ich ein grosser Feind
davon, irgendwas in mein System zu lassen, was kein Debian-Paket
ist. Bei Java-Programmen sieht das jedoch sehr oft anders aus. Hier
zeigt sich, daß die Entwickler der Sprache mitgedacht haben. Der
Tomcat besteht aus einem einzelnen Verzeichnis und hat keine
weiteren externen Abhängigkeiten. Man entpackt also das von der
[http://tomcat.apache.org Tomcat Website] herunterladene Archiv in
ein Verzeichnis (z.B. in seinem eigenen Userverzeichnis) und
fertig! Keine Abhängigkeiten, keine Probleme mit Bibliotheken,
keine Schwierigkeit, das Ding wieder zu löschen.

Man kann den Tomcat nun starten, indem man in das Verzeichnis geht
und dann die ''startup.sh'' und ''shutdown.sh''-Skripte in
''bin/'' benutzt. Man kann aber auch ein besonderes
Konfigurationsverzeichnis erstellen:

Einen dermassen in ein Verzeichnis installierten Tomcat kann man
dann z.B. auch von der EclipseIDE aus benutzen (starten, stoppen,
Anwendungen installieren, etc.), wenn man WebAnwendungenMitEclipse
entwickelt.

Für einen Benutzer kann man leicht einen eigenen Tomcat
konfigurieren, indem man dem Benutzer folgende Verzeichnisstruktur
anlegt:


 tomcat
  +-bin--catalina.sh (Start-/Stop-Skript)
  +-conf
  |  +-server.xml (Server-Konfiguration)
  |  +-web.xml    (Server-Konfiguration, Standard-Servlets, z.B. JSP-Servlet)
  +-logs  (Hier landen die Log-Files)
  +-webapps
  |  +-ROOT
  |     +-WEB-INF
  |     |  +-web.xml (Konfiguration für die "Root-Applikation")
  |     |  +-classes
  |     |     +-TestServlet.class (Beispiel-Servlet)
  |     +-index.jsp (Beispiel-JSP)
  +-temp (Temp-Verzeichnis des Tomcat, bei mir bisher immer leer, aber in catalina.sh
  |       konfiguriert, deshalb habe ich es angelegt)
  +-work (Arbeitsverzeichnis für den Tomcat, hier landen z.B. die kompilierten JSPs)


Wichtig ist, dass in der server.xml jeweils eigene Ports
konfiguriert sind!

Das Start-Skript catalina.sh könnte etwas so aussehen:

 #!/bin/sh
 export CATALINA_HOME=/usr/share/tomcat5.5
 export CATALINA_BASE=/home/meinuser/tomcat
 export CATALINA_PID=/home/meinuser/tomcat/tomcat.pid
 export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
 export JAVA_OPTS="-Xmx512m $JAVA_OPTS"
 /usr/share/tomcat5.5/bin/catalina.sh $1 $2


Wenn man pro User-Tomcat auch ein eigenes common/classes und common/lib-Verzeichnis benötigt, kann man den Classloader über eine Datei "catalina.properties" konfigurieren:

 -Dcatalina.config=file:../conf/catalina.properties

in den JAVA_OPTS ergänzen und etwa das Folgende in die catalina.properties schreiben:
 package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
 package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.org.apache.tomcat.,org.apache.jasper.
 common.loader=${catalina.base}/common/lib/*.jar,${catalina.home}/common/classes,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar
 server.loader=${catalina.base}/server/lib/*.jar;${catalina.home}/server/classes,${catalina.home}/server/lib/*.jar
 shared.loader=${catalina.base}/shared/lib/*.jar



!!Die Manager-Applikation

Normalerweise installiere ich die Manager- und die
Admin-Applikationen bei einem produktiven Tomcat nicht. Warum soll
man sich potentielle Sicherheitlücken einhandeln? Aber bei einem
Entwickler-Tomcat macht es durchaus Sinn, über die
Manager-Applikationen Anwendungen zu installieren und zu
rekonfigurieren.

!!Tomcat-Benutzer

Wenn man das Paket '''tomcat4-admin''' mitinstalliert hat, kann man
sich über die Weboberfläche als Admin einloggen und dann einige
Dinge machen wie z.B. Applikationen de-/installieren. Hierzu muss
man die Benutzerdatenbank einrichten. In der Standardinstallation
ist diese eine einfache Textdatei in
'''/var/lib/tomcat4/conf/tomcat-users.xml'''. Dort muss man eine
Rolle "manager" und einen User (z.B. admin) einfügen, der diese
Rolle ausfüllt.

!!Tipps und Tricks

*Man kann Datenbankverbindungen per JNDI zentral im Tomcat statt in den einzelnen Servlets verwalten: TomcatJNDI.
*TomcatServletTutorial - kurze Einführung in eigene Servlets
*TomcatSSL Zertifikat erzeugen
*WebAnwendungenMitEclipse - eigene Applikationen erzeugen


=== Notiz ===
Den Tomcat mit einem anderem encoding nutzen. dazu in der /etc/defaults/tomcat folgendes eintragen.

CATALINA_OPTS="-Djava.awt.headless=true -Xmx128M -server -Dfile.encoding=ISO-8859-15


[{Tag Java Tomcat Debian}]