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.

Installation als Debian-Paket #

Zunächst muss ein Java JDK installiert sein. Das geht mit 

  apt-get install j2sdk1.4

wie auf Seite JavaUnterDebian beschrieben.

Weiter geht's mit 

  apt-get install tomcat4

oder mit 

  apt-get install tomcat4 tomcat4-admin tomcat4-webapps

Die Webapps sind nur einige Beispiele, allerdings läuft die Debian-Konfiguration nicht ohne dieses Paket. Das admin-Paket installiert eine Manager und eine Admin-Applikation im Tomcat. Hiermit kann man erstmal testen, ob der Tomcat läuft und sich ein bisschen bekannt machen.

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/tomcat4 die Variable TOMCAT4_SECURITY auf "no" setzen und den Tomcat mit 

  /etc/init.d/tomcat4 restart

neu starten.

Um den Security Manager auf die richtige Art undWeise zu besänftigen, muss man Zugriffrechte setzen. Dazu schreibt man in die Datei /etc/tomcat4/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/tomcat4 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).

Ich habe in /var/lib/tomcat4/conf/tomcat-users.xml die Rolle "manager" und einen User mit dieser Rolle eingetragen, um Tomcat per Manager-Webschnittstelle managen zu können (wenn man das tomcat4-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!

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.

Tips und Tricks #

Kategorien
KategorieJava, KategorieTomcat
This particular version was published on 16-Dec-2006 23:35 by PeterHormanns.  Top