Tomcat#

Tomcat 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 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