Xinux Wiki - Benutzerbeiträge [de]

https://www.xinux.net/api.php?action=feedcontributions&feedformat=atom&user=192.168.254.27 Xinux Wiki - Benutzerbeiträge [de] 2026-06-11T14:37:01Z Benutzerbeiträge MediaWiki 1.35.1 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=763 Tomcat 5.5 2009-08-05T14:05:00Z

<p>192.168.254.27: /* Apache und Tomcat verbinden */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile="/etc/tomcate5.5/.keystore"<br /> keystorePass="geheim" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> JkWorkersFile /etc/libapache2-mod-jk/workers.properties<br /> JkLogFile /var/log/apache2/mod_jk.log<br /> JkLogLevel info<br /> <br /> JkMount /*.jsp ajp13_worker<br /> JkMount /*/servlet/ ajp13_worker<br /> JkMount /manager ajp13_worker<br /> JkMount /manager/* ajp13_worker<br /> JkMount /jsp-examples ajp13_worker<br /> JkMount /jsp-examples/* ajp13_worker<br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties wird automatisch unter /etc/libapache2-mod-jk/ angelegt.<br /> <br /> In der Datei workers.properties darauf achten, dass folgende Zeilen korrekt sind (Tomcat Homeverzeichnis und Java Homeverzeichnis):<br /> ...<br /> workers.tomcat_home=/var/lib/tomcat5.5<br /> workers.java_home=/usr/lib/jvm/java-6-sun<br /> <br /> Danach müssen apache Webserver und Tomcat neu gestartet werden (zuerst Tomcat, dann apache neu starten).</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=761 Tomcat 5.5 2009-08-05T13:21:05Z

<p>192.168.254.27: /* Apache und Tomcat verbinden */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile="/etc/tomcate5.5/.keystore"<br /> keystorePass="geheim" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> JkWorkersFile /etc/libapache2-mod-jk/workers.properties<br /> JkLogFile /var/log/apache2/mod_jk.log<br /> JkLogLevel info<br /> <br /> JkMount /*.jsp ajp13_worker<br /> JkMount /*/servlet/ ajp13_worker<br /> JkMount /manager ajp13_worker<br /> JkMount /manager/* ajp13_worker<br /> JkMount /jsp-examples ajp13_worker<br /> JkMount /jsp-examples/* ajp13_worker<br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties wird automatisch unter /etc/libapache2-mod-jk/ angelegt.<br /> <br /> In der Datei workers.properties darauf achten, dass folgende Zeilen korrekt sind (Tomcat Homeverzeichnis und Java Homeverzeichnis):<br /> ...<br /> workers.tomcat_home=/usr/share/tomcat5.5<br /> workers.java_home=/usr/lib/jvm/java-6-sun<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=760 Tomcat 5.5 2009-08-05T12:59:15Z

<p>192.168.254.27: /* Apache und Tomcat verbinden */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile="/etc/tomcate5.5/.keystore"<br /> keystorePass="geheim" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> JkWorkersFile /etc/libapache2-mod-jk/workers.properties<br /> JkLogFile /var/log/apache2/mod_jk.log<br /> JkLogLevel info<br /> <br /> JkMount /*.jsp ajp13_worker<br /> JkMount /*/servlet/ ajp13_worker<br /> JkMount /manager ajp13_worker<br /> JkMount /manager/* ajp13_worker<br /> JkMount /jsp-examples ajp13_worker<br /> JkMount /jsp-examples/* ajp13_worker<br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties wird automatisch unter /etc/libapache2-mod-jk/ angelegt.<br /> <br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=757 Tomcat 5.5 2009-08-05T12:15:17Z

<p>192.168.254.27: /* Apache und Tomcat verbinden */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile="/etc/tomcate5.5/.keystore"<br /> keystorePass="geheim" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=756 Tomcat 5.5 2009-08-05T12:14:07Z

<p>192.168.254.27: /* Apache und Tomcat verbinden */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile="/etc/tomcate5.5/.keystore"<br /> keystorePass="geheim" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Logdatei für mod_jk anlegen:<br /> touch /var/log/apache2/mod_jk.log<br /> <br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=755 Tomcat 5.5 2009-08-05T12:07:04Z

<p>192.168.254.27: /* Tomcat SSL */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile="/etc/tomcate5.5/.keystore"<br /> keystorePass="geheim" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=754 Tomcat 5.5 2009-08-05T12:01:33Z

<p>192.168.254.27: /* Tomcat SSL */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=753 Tomcat 5.5 2009-08-05T12:00:25Z

<p>192.168.254.27: /* Tomcat SSL */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS" keystoreType="JKS"<br /> truststoreType="JKS" algorithm="SunX509" clientAuth="false"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=752 Tomcat 5.5 2009-08-05T11:49:43Z

<p>192.168.254.27: /* Tomcat SSL */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um die Einträge keystoreFile="/pfad/zur/keystoredatei/dateiname" keystorePass="<gewähltes Passwort>" ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=751 Tomcat 5.5 2009-08-05T11:47:48Z

<p>192.168.254.27: /* Tomcat SSL */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis :<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=750 Tomcat 5.5 2009-08-05T11:46:10Z

<p>192.168.254.27: /* Tomcat SSL */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-6-sun/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=749 Tomcat 5.5 2009-08-05T11:33:00Z

<p>192.168.254.27: /* Tomcat Server */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> '''Tomcat Server'''<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=748 Tomcat 5.5 2009-08-05T11:32:30Z

<p>192.168.254.27: /* Realms, Roles und User */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=747 Tomcat 5.5 2009-08-05T11:32:16Z

<p>192.168.254.27: /* Konfigurationsdateien */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> <br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=746 Tomcat 5.5 2009-08-05T11:31:57Z

<p>192.168.254.27: /* web.xml */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> <br /> <br /> <br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=745 Tomcat 5.5 2009-08-05T11:31:46Z

<p>192.168.254.27: /* server.xml */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> <br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=744 Tomcat 5.5 2009-08-05T11:31:18Z

<p>192.168.254.27: /* Komponenten */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> <br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=743 Tomcat 5.5 2009-08-05T11:29:19Z

<p>192.168.254.27: /* Verwalten der Anwendungen - Manager Anwendung */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=742 Tomcat 5.5 2009-08-05T11:28:00Z

<p>192.168.254.27: /* Verwalten der Anwendungen - Manager Anwendung */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps (/usr/share/tomcat5.5/webapps/)<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.Sie finden die vollständige Befehlsliste unter<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=741 Tomcat 5.5 2009-08-05T11:22:14Z

<p>192.168.254.27: /* Verwalten der Anwendungen - Manager Anwendung */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> '''Deployen eines bestehenden Web Archives'''<br><br /> Als erstes wollen wir ein bestehendes Web Archiv installieren. Das WAR-File enthält alle nötigen Dateien wie Servlets, sonstige Java-Klassen, JSP und HTML-Seiten, JAR-Archive. Dies geschieht in zwei Schritten (ein Beispiel für ein WAR-Archiv kann man unter der folgenden URL finden: http://www.hccfl.edu/pollock/AJava/WAR/myServletWAR.war):<br /> #Kopieren Sie das WAR Archiv ins Verzeichnis $CATALINA_HOME/webapps<br /> #Starten Sie Tomcat neu:<br><br /> Tomcat entpackt das Web Archiv Anschliessend können Sie die Datei *.war löschen, da die darin enthaltenen Dateien sich nun in den Subverzeichnissen befinden.<br /> <br /> Testen mit der URL „http://localhost:8180/<Name des WAR-Archivs ohne Suffix>“ <br /> <br /> '''Deployen von nicht archivierten Dateien'''<br><br /> Falls Sie kein Web Archiv haben, können Sie die Dateien auch direkt ins WebApps Verzeichnis kopieren.Diese Methode ist sehr einfach und Tomcat generiert aufgrund Ihrer Verzeichnisstruktur beim Neustart den passenden Kontexteintrag in server.xml.<br /> <br /> '''Deployen mithilfe der Tomcat Administration'''<br><br /> Sie können auch Applikationen mithilfe der Tomcat Manager Befehle deployen oder auflisten oder entfernen.Sie finden die vollständige Befehlsliste unter<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=740 Tomcat 5.5 2009-08-05T11:16:52Z

<p>192.168.254.27: /* Tomcat Server */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> Optionen zur Server-Konfiguration:<br /> {|border=1 cellpadding=2<br /> |Name<br /> |Bedeutung<br /> |-<br /> |EnableDNSLookups<br /> |Durchführen von Nameserverabfragen<br /> |-<br /> |URI Encoding<br /> |Encoding, das für den URI String benutzt wird. ISO-8859-1, wenn nicht angegeben.<br /> |-<br /> |IP Address<br /> |Für Server mit mehr als einer IP Adresse.<br /> |-<br /> |Secure<br /> |SSL Support einschalten.<br /> |-<br /> |Accept Count<br /> |Max. Warteschlangenlänge für Anfragen, wenn alle Prozess Threads ausgelastet sind.<br /> |-<br /> |Compression<br /> |Schaltet Kompression ein / aus.<br /> |-<br /> |Connection Timeout<br /> |Timeout<br /> |-<br /> |Max KeepAlive Requests<br /> |Maximale Anfragen während einer Verbindung; 1 -> Ausschalten von KeepAlive, -1 -> unlimitierte Anzahl an Anfragen<br /> |-<br /> |Max Spare Threads<br /> |Maximale Anzahl unbenutzter Prozesse.<br /> |-<br /> |Max Threads<br /> |Maximale Anzahl der Prozesse.<br /> |-<br /> |Min Spare Threads<br /> |Anzahl Prozesse, die beim Starten gestartet werden.<br /> |-<br /> |Port Number<br /> |Port, auf dem der Server erreichbar ist.<br /> |-<br /> |Redirect Port Number<br /> |Bei SSL Anfragen wird an diesen Port weitergeleitet.<br /> |}<br /> <br /> <br /> =Verwalten der Anwendungen - Manager Anwendung=<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=731 Tomcat 5.5 2009-08-05T09:05:51Z

<p>192.168.254.27: /* Tomcat Server */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> Unterhalb von Host kann man die einzelnen Webanwendungen konfigurieren.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=730 Tomcat 5.5 2009-08-05T09:04:12Z

<p>192.168.254.27: /* Tomcate Server */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcat Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=729 Tomcat 5.5 2009-08-05T09:04:04Z

<p>192.168.254.27: /* Konfiguration des Tomcat Servers (Admin-Anwendung) */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung sieht amn 3 Hauptbereiche:<br /> <br /> '''Tomcat Server'''<br><br /> Hier erfolgt die Konfiguration des eigentlichen Servers und der auf dem Server vorhandenen Webanwendungen.<br /> <br /> '''Resources'''<br><br /> Definition von Resourcen, die den Webanwendungen zur Verfügung stehen. Dies können zum Beispiel Datenbankanbindungen, Maildienste, etc. sein.<br /> <br /> '''User Definition'''<br><br /> Hier können Benutzer, Gruppen und Rollen verwaltet werden.<br /> <br /> ==Tomcate Server==<br /> <br /> *Service<br /> 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. <br /> **Connector<br /> 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. <br /> **Host<br /> 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.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=726 Tomcat 5.5 2009-08-05T08:47:31Z

<p>192.168.254.27: /* Konfiguration des Tomcat Servers (Admin-Anwendung) */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> Es empfiehlt sich, die Konfiguration soweit möglich über die graphische Oberfläche vorzunehmen.<br /> <br /> Nach dem Anmelden an der Admin Anwendung<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=725 Tomcat 5.5 2009-08-05T08:43:01Z

<p>192.168.254.27: /* Die "manager"- und die "admin"-Anwendungen */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Konfiguration des Tomcat Servers (Admin-Anwendung)=<br /> Hauptkonfigurationsdatei:<br /> /etc/tomcate5.5/server.xml<br /> Die Konfigurationsdateien der einzelnen Anwendungen auf dem System befinden sich als .xml Dateien im jeweiligen DocumentRoot.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=723 Tomcat 5.5 2009-08-05T08:28:50Z

<p>192.168.254.27: /* Die "manager"- und die "admin"-Anwendungen */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> ...<br /> <user username="admin" password="geheim" roles="admin", manager/><br /> ...<br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=722 Tomcat 5.5 2009-08-05T08:27:25Z

<p>192.168.254.27: /* Installation und Dateien */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> In der Datei /etc/default/tomcat5.5 eventuelle folgende Zeilen anpassen:<br /> JAVA_HOME=/usr/lib/jvm/<zu_benutzende_java_version><br /> <br /> <br /> <br /> <br /> *Konfigurationsdateien: /etc/tomcat5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcat5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="admin" password="geheim" roles="admin", manager/><br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=719 Tomcat 5.5 2009-08-04T16:12:51Z

<p>192.168.254.27: /* Die "manager"- und die "admin"-Anwendungen */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien: /etc/tomcate5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen:<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="admin" password="geheim" roles="admin", manager/><br /> </tomcat-users><br /> <br /> Danach muss tomcat neu gestartet werden.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=718 Tomcat 5.5 2009-08-04T16:11:34Z

<p>192.168.254.27: /* Die "manager"- und die "admin"-Anwendungen */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien: /etc/tomcate5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> Bevor man beide Anwendungen benutzen kann, muss man einen Benutzer mit den entsprechenden Rechten erstellen.<br /> cat /etc/tomcat5.5/tomcat-users.xml<br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="admin" password="geheim" roles="admin", manager/><br /> </tomcat-users><br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=717 Tomcat 5.5 2009-08-04T16:07:25Z

<p>192.168.254.27: /* Komponenten */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien: /etc/tomcate5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=716 Tomcat 5.5 2009-08-04T16:07:14Z

<p>192.168.254.27: /* Die "manager"- und die "admin"-Anwendungen */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien: /etc/tomcate5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> <br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=715 Tomcat 5.5 2009-08-04T16:06:54Z

<p>192.168.254.27: /* Komponenten */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien: /etc/tomcate5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> <br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=714 Tomcat 5.5 2009-08-04T16:03:32Z

<p>192.168.254.27: /* Installation und Dateien */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien: /etc/tomcate5.5/<br /> *Logdateien: /var/log/tomcat5.5/<br /> *Programmdateien: /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung: /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen: /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=713 Tomcat 5.5 2009-08-04T16:03:11Z

<p>192.168.254.27: /* Installation und Dateien */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien /etc/tomcate5.5/<br /> *Logdateien /var/log/tomcat5.5/<br /> *Programmdateien /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=712 Tomcat 5.5 2009-08-04T16:02:35Z

<p>192.168.254.27: /* Verzeichnisstruktur */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> *Konfigurationsdateien<br /> /etc/tomcate5.5/<br /> *Logdateien<br /> /var/log/tomcat5.5/<br /> *Programmdateien<br /> /usr/share/tomcate5.5/bin/ <br /> *Admin und Manager Anwendung<br /> /var/lib/tomcat5.5/webapps/server/webapps<br /> *Beispielanwendungen<br /> /usr/share/tomcat5.5-webapps/<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=711 Tomcat 5.5 2009-08-04T15:55:56Z

<p>192.168.254.27: /* Installation */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation und Dateien=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> =Verzeichnisstruktur=<br /> /usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien<br /> <br /> /usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können<br /> <br /> /usr/share/tomcat5.5/conf – Server-Konfigurationsdateien<br><br /> - server.xml -- Zentrale Einstellungsdatei<br><br /> - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen<br /> <br /> /usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs<br /> <br /> /usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken<br /> <br /> /usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden<br /> <br /> /usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen<br /> <br /> /usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=710 Tomcat 5.5 2009-08-04T15:55:42Z

<p>192.168.254.27: /* Verzeichnisstruktur */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> =Verzeichnisstruktur=<br /> /usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien<br /> <br /> /usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können<br /> <br /> /usr/share/tomcat5.5/conf – Server-Konfigurationsdateien<br><br /> - server.xml -- Zentrale Einstellungsdatei<br><br /> - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen<br /> <br /> /usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs<br /> <br /> /usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken<br /> <br /> /usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden<br /> <br /> /usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen<br /> <br /> /usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=709 Tomcat 5.5 2009-08-04T15:54:33Z

<p>192.168.254.27: /* Installation */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> =Verzeichnisstruktur=<br /> /usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien<br /> <br /> /usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können<br /> <br /> /usr/share/tomcat5.5/conf – Server-Konfigurationsdateien<br /> - server.xml -- Zentrale Einstellungsdatei <br /> - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen<br /> <br /> /usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs<br /> <br /> /usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken<br /> <br /> /usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden<br /> <br /> /usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen<br /> <br /> /usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=708 Tomcat 5.5 2009-08-04T15:24:46Z

<p>192.168.254.27: /* Installation */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> /ect/default/tomcat5.5<br /> <br /> <br /> update-alternatives --config java<br /> update-alternatives --config javac<br /> <br /> <br /> /etc/bash.bash.rc um folgende Zeile erweitern:<br /> export JAVA_HOME=/usr/lib/jvm/java-6-sun/<br /> danach neu anmelden.<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> =Verzeichnisstruktur=<br /> /usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien<br /> <br /> /usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können<br /> <br /> /usr/share/tomcat5.5/conf – Server-Konfigurationsdateien<br /> - server.xml -- Zentrale Einstellungsdatei <br /> - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen<br /> <br /> /usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs<br /> <br /> /usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken<br /> <br /> /usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden<br /> <br /> /usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen<br /> <br /> /usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=707 Tomcat 5.5 2009-08-04T14:50:22Z

<p>192.168.254.27: /* Installation */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation=<br /> <br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> update-alternatives --config java<br /> update-alternatives --config javac<br /> <br /> /etc/bash.bash.rc um folgende Zeile erweitern:<br /> export JAVA_HOME=/usr/lib/jvm/java-6-sun/<br /> <br /> Tomcat installieren<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> =Verzeichnisstruktur=<br /> /usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien<br /> <br /> /usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können<br /> <br /> /usr/share/tomcat5.5/conf – Server-Konfigurationsdateien<br /> - server.xml -- Zentrale Einstellungsdatei <br /> - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen<br /> <br /> /usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs<br /> <br /> /usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken<br /> <br /> /usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden<br /> <br /> /usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen<br /> <br /> /usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Tomcat_5.5&diff=706 Tomcat 5.5 2009-08-04T14:36:48Z

<p>192.168.254.27: /* Installation */</p> <hr /> <div>=Einleitung=<br /> Apache Tomcat ist eine OpenSource Implementierung der Java Servlet und der Java Server Pages Technologien.<br /> 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.<br /> <br /> =Installation=<br /> <br /> root@zero:~# apt-get install tomcat5.5<br /> root@zero:~# apt-get install sun-java6-jdk<br /> <br /> <br /> Admin und Manager Web Interfaces:<br /> root@zero:~# apt-get install tomcat5.5-admin <br /> <br /> Dokumentation und Beispiel Webanwendungen:<br /> root@zero:~# apt-get install tomcat5.5-webapps<br /> <br /> update-alternatives --config java<br /> update-alternatives --config javac<br /> <br /> =Verzeichnisstruktur=<br /> /usr/share/tomcat5.5/bin - startup, shutdown und andere Skripte und ausführbare Dateien<br /> <br /> /usr/share/tomcat5.5/common - Allgemeine Klassen, die von Catalina und anderen Webapplikationen benutzt werden können<br /> <br /> /usr/share/tomcat5.5/conf – Server-Konfigurationsdateien<br /> - server.xml -- Zentrale Einstellungsdatei <br /> - tomcat-users.xml -- Datei für die Nutzer und deren Rollen und Berechtigungen<br /> <br /> /usr/share/tomcat5.5/logs - Catalina- und Anwendungs-Logs<br /> <br /> /usr/share/tomcat5.5/server - Klassen, die nur von Catalina verwendet werden; Tomcat Bibliotheken<br /> <br /> /usr/share/tomcat5.5/shared - Klassen, die von allen Webapplikationen verwendet werden<br /> <br /> /usr/share/tomcat5.5/webapps - Verzeichnis der Webapplikationen<br /> <br /> /usr/share/tomcat5.5/work - temporäre Aufbewahrung von Dateien und Verzeichnissen<br /> <br /> =Startscript=<br /> <br /> root@zero:~# /etc/init.d/tomcat5.5 stop<br /> root@zero:~# /etc/init.d/tomcat5.5 start<br /> <br /> Mit: <br /> root@zero:~# netstat -lntp | grep 8180<br /> tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN 8763/jsvc <br /> kann verifiziert werden, ob der Server läuft.<br /> <br /> =Komponenten=<br /> ==Server==<br /> 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.<br /> 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.<br /> Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.<br /> ==Service==<br /> 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.<br /> ==Connector==<br /> 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.<br /> 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.<br /> ==Engine==<br /> 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.<br /> ==Host==<br /> 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.<br /> 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.<br /> ==Context==<br /> 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.<br /> Ein Context beantwortet alle Anfragen an eine speziell Webapplikation.<br /> ==Standardklassen==<br /> 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.<br /> <br /> =Konfigurationsdateien=<br /> ./server.xml<br /> <br /> 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.<br /> <br /> ./server-minimal.xml<br /> <br /> Die minimalistische Variante von der server.xml, welche als Vorlage dienen kann.<br /> <br /> ./web.xml<br /> <br /> Die Datei web.xml definiert Standardwerte für alle Webapplikationen die in diese Instanz von Tomcat geladen wurden. <br /> <br /> ./context.xml<br /> <br /> Die Inhalte dieser Datei werden für jede Webapplikation geladen.<br /> <br /> ./tomcat-users.xml<br /> <br /> Zentrale Datei zur Verwaltung von Benutzer und Zuweisung der Benutzerrechte.<br /> <br /> ./catalina.policy<br /> <br /> Ansammlung von Sicherheitsrichtlinien, welche angewandt werden, wenn Tomcat mit dem Attribut „-security“ aufgerufen wird.<br /> <br /> ./catalina.properties<br /> <br /> Datei die es ermöglicht Zugriffsbeschänkungen auf Java-Basis vorzunehmen.<br /> <br /> ./logging.properties<br /> <br /> Diese Datei legt die Standardparameter für das Loggin fest.<br /> <br /> ./Catalina/localhost/host-manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Host-Manager Webapplicationen ändern.<br /> <br /> ./Catalina/localhost/manager.xml<br /> <br /> Mittels ihr lässt sich der Inhalt der Tomcat Manager Webapplicationen ändern.<br /> <br /> ==server.xml==<br /> <br /> Server<br /> <br /> Oberstes Element in der Datei server.xml: definiert einen Server mit seinen Services und sorgt für dessen Konstruktion<br /> <br /> Attribute:<br /> <br /> port: Port für Shutdown auf der IP-Adresse 127.0.0.1<br /> <br /> shutdown: Schlüsselwort für Shutdown (Herunterfahren)<br /> <br /> <br /> Service<br /> <br /> Gruppiert Container für Servlet-Verarbeitung (etwa Engine) mit dessen Konnektoren<br /> <br /> Attribute:<br /> <br /> name : Name dieses Services<br /> <br /> <br /> Connector<br /> <br /> Konfiguration der Verbindung zwischen Client und Server - Verarbeitung von Request- und Response-Objekten<br /> <br /> Attribute:<br /> <br /> port : TCP-Port, auf dem der Server-Socket horcht<br /> <br /> maxHttpHeaderSize : Größe der Header-Informationen in Bytes <br /> <br /> maxThreads : Maximale Anzahl von parallelen Anfragen die dieser Connector erzeugt<br /> <br /> maxSpareThreads : Maximale Anzahl von Request-verarbeitenden Threads, die im ThreadPool verbleiben<br /> <br /> minSpareThreads : Minimale Anzahl an wartenden Threads für die Anfragebearbeitung<br /> <br /> enableLookups : führe DNS-Anfrage durch<br /> <br /> redirectPort : Umleitung auf einen Port<br /> <br /> acceptCount : Größe der Socket-Warteschlange für eingehende Verbindungsanfragen<br /> <br /> connectionTimeout : Zeit in ms, die bis auf die Antwort einer Anfrage gewartet wird<br /> <br /> disableUploadTimeout : Erlaubt dem Konnektor eine Unterdrückung des Connection-Timeout bei Upload-Anfragen.<br /> <br /> <br /> Engine<br /> <br /> Container auf oberster Ebene zur Verarbeitung von Servlet-Anfragen.<br /> <br /> Attribute:<br /> <br /> baseDir : Basisverzeichnis dieser Engine.<br /> <br /> defaultHost :Vorbelegung des Hostnamens<br /> <br /> name : Logischer Name dieser Engine<br /> <br /> <br /> Host<br /> <br /> Virtueller Host mit eigenen Web-Anwendungen<br /> <br /> Attribute:<br /> <br /> appBase : Wurzel für eigeneWeb-Anwendungen<br /> <br /> name : Vollqualifizierter Hostname (mit Domain)<br /> <br /> unpackWARs : entpacke alle WAR's in das Verzeichnis <appBase>, bevor die Anwendungen aktiv wird<br /> <br /> autoDeploy : automatisches Deployment eigener Anwendungen im Verzeichnis <appBase><br /> <br /> xmlNamespaceAware : web.xml auf korrekte Verwendung von XML Namespaces prüfen<br /> <br /> mlValidation : web.xml auf Gültigkeit überprüfen<br /> <br /> <br /> Context<br /> <br /> Konfiguration des Containers für eine Web-Anwendung auf einem virtuellen Host.<br /> <br /> Attribute:<br /> <br /> path : Pfad zu dieser Web-Anwendung (URI-Anteil)<br /> <br /> <br /> Deployer<br /> <br /> Clusterweites Deployment von War-Archiven.<br /> <br /> <br /> Environment<br /> <br /> definiert einen Umgebungseintrag (<env-entry>)<br /> <br /> <br /> Logger / Filelogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) in eine Datei<br /> <br /> <br /> ErrorLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdErr<br /> <br /> <br /> OutLogger<br /> <br /> Ausgabe für Logging-, Debugging- und Fehlermeldungen (inkl. stack traces) nach StdOut<br /> <br /> ==web.xml==<br /> 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ß.<br /> <br /> ==catalina.policy==<br /> 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<br /> mittels entsprechender Regeln wieder frei und ermöglichen so, dass die entsprechende Klasse einwandfrei arbeiten kann. <br /> <br /> Bsp.:<br /> grant codeBase "file:${java.home}/lib/-"<br /> { permission java.security.AllPermission;<br /> };<br /> 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:<br /> 1. „-“ (Bindestrich) für alle Dateien und Unterverzeichnisse rekursiv,<br /> 2. ,,*" nur für alle Dateien in dem angegebenen Verzeichnis.<br /> <br /> =Realms, Roles und User=<br /> <br /> 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. <br /> Ein Realm kann auf den Engine, Host oder Context Containern konfiguriert werden. <br /> <br /> 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.<br /> 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:<br /> <br /> <?xml version='1.0' encoding='utf-8'?><br /> <tomcat-users><br /> <role rolename="tomcat"/><br /> <role rolename="role1"/><br /> <role rolename="manager"/><br /> <role rolename="admin"/><br /> <user username="tomcat" password="tomcat" roles="tomcat"/><br /> <user username="both" password="tomcat" roles="tomcat,role1"/><br /> <user username="role1" password="tomcat" roles="role1"/><br /> <user username="xinux" password="xinux" roles="tomcat,admin,manager,role1"/><br /> </tomcat-users><br /> <br /> 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. <br /> <br /> 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.ä.<br /> <br /> =Tomcat SSL=<br /> Zertifikat erstellen:<br /> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/keytool -genkey -alias tomcat -keyalg RSA<br /> <br /> Nach Eingabe eines keystore-Passwortes und der gewünschten Daten, wird eine Datei ".keystore" im Homeverzeichnis des aufrufenden Benutzers erstellt.<br /> <br /> Verschieben der Datei ins tomcat Konfigurations Verzeichnis (falls nicht dort erstellt):<br /> <br /> mv .keystore /etc/tomcat5.5/<br /> <br /> Anpassung der server.xml:<br /> Bei folgendem Eintrag Kommentarzeichen enfernen und um den Eintrag keystorePass=“<gewähltes Passwort>“ ergänzen. <br /> <br /> <br /> <Connector port="8443" maxHttpHeaderSize="8192"<br /> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"<br /> enableLookups="false" disableUploadTimeout="true"<br /> acceptCount="100" scheme="https" secure="true"<br /> clientAuth="false" sslProtocol="TLS"<br /> keystoreFile=“/usr/local/tomcat/conf/.keystore“<br /> keystorePass="xinuxer" /><br /> <br /> Anschließend Tomcat neu starten und mit „netstat -lntp“ überprüfen ob Port 8443 freigeschaltet ist.<br /> Danach sollte ein Zugriff auf den Tomcat mit der URL „https://localhost:8443“ möglich sein.<br /> <br /> =Die "manager"- und die "admin"-Anwendungen=<br /> 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. <br /> 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.<br /> <br /> 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. <br /> Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer vorzunehmen als über die Konfigurationsdateien.<br /> <br /> =Apache und Tomcat verbinden=<br /> 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... <br /> $apache2 -l<br /> Compiled in modules:<br /> core.c<br /> prefork.c<br /> http_core.c<br /> mod_so.c<br /> <br /> <br /> Apache JK Connector installieren:<br /> root@zero:~# apt-get install libapache2-mod-jk<br /> <br /> Datei jk.conf in /etc/apache2/mods_available/ anlegen:<br /> <IfModule mod_jk.c><br /> JkWorkersFile /etc/apache2/workers.properties<br /> JkLogFile /var/logs/apache2/mod_jk.log<br /> JkLogLevel info<br /> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /> JkRequestLogFormat "%w %V %T"<br /> JkMount /TomcatContext/* myworker<br /> JkMount /manager/* myworker<br /> </IfModule><br /> <br /> Nach mods_enabled verlinken:<br /> root@zero:/etc/apache2/mods-enabled# ln -s ../mods-available/jk.conf<br /> <br /> Datei workers.properties unter /etc/apache2/ anlegen:<br /> workers.list=myworker<br /> workers.myworker.type=ajp13<br /> workers.myworker.host=localhost<br /> workers.myworker.port=8009<br /> workers.myworker.cachesize=10<br /> workers.myworker.socket_keepalive=1<br /> workers.myworker.recycle_timeout=300<br /> <br /> Danach muss der apache Webserver neu gestartet werden.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Apache2_Aufgaben&diff=656 Apache2 Aufgaben 2009-08-04T08:40:05Z

<p>192.168.254.27: Die Seite wurde neu angelegt: 1. Wie heisst das eigentliche Binary (unter linux )das den Apache Webserver darstellt ? 2. Auf welchem Protokoll basiert der Apache ? Was bedeuten folgende Eintr...</p> <hr /> <div>1. Wie heisst das eigentliche Binary (unter linux )das den Apache Webserver darstellt ?<br /> <br /> <br /> 2. Auf welchem Protokoll basiert der Apache ?<br /> <br /> <br /> <br /> Was bedeuten folgende Einträge in der httpd.conf ? <br /> <br /> <br /> 3. ServerType inetd<br /> <br /> 4. Port 80<br /> <br /> 5. ServerRoot /usr/local/apache<br /> <br /> 6. TranferLog logs/acces.log<br /> <br /> 7. StartServers 10 <br /> <br /> 8. ServerName www.xinux.de<br /> <br /> 9. <Directory /usr/local/apache/htdocs/suxers><br /> order deny allow <br /> deny from all<br /> allow from 10.0.0.0/255.0.0.0<br /> </Directory><br /> <br /> 10. <Location /musiker/jimi.html ><br /> order allow deny <br /> allow from all<br /> deny from 192.168.1.21<br /> </Location><br /> <br /> 11. MaxKeepAliveRequests 100<br /> <br /> 12. KeepAliveTimeout 15<br /> <br /> 13. MinSpareServers 5<br /> <br /> 14. MaxSpareServers 10<br /> <br /> 15. StartServers 5<br /> <br /> 16. MaxClients 150<br /> <br /> 17. Group nogroup<br /> <br /> 18. ServerAdmin root@luxana.alpha.quadrant<br /> <br /> <br /> 19. DocumentRoot "/usr/local/apache/htdocs"<br /> <br /> <br /> 20. Tragen Sie die URL's www.guckemo.de und www.aweiaba.de auf Ihrem Nameserver so ein so das sie auf die selbe IP NUMMER antworten.<br /> (Revererse Zone nicht vergessen !)<br /> <br /> <br /> <br /> <br /> a. Das Dokumentroot sollte die Konvention /var/www/URL haben<br /> <br /> <br /> <br /> b. Geloggt (Error und Tranfer) wird in /var/www/URL/logs <br /> <br /> <br /> <br /> c. Die Email des admin lautet für beide Sites webmaster@xux.de <br /> <br /> <br /> <br /> d. Für beide Sites soll das Folgen von Symbolischen Links aktiviert sein.<br /> <br /> <br /> <br /> e. Auf der url von gueckemo soll eine Unterverzeichnis /privat existieren<br /> der authorisierte USER heinz und dem PASSWORD lesen darf <br /> <br /> <br /> <br /> <br /> e. Auf die URL www.aweiaba.de soll nur von Ihrem Netz zugriffen werden dürfen <br /> <br /> <br /> <br /> <br /> <br /> f. Das cgi Verzeichnis sollte unter /var/www/cgi-bin fuer bei URLs liegen</div>

192.168.254.27 https://www.xinux.net/index.php?title=Aufgaben&diff=655 Aufgaben 2009-08-04T08:39:50Z

<p>192.168.254.27: </p> <hr /> <div>* [[Linux Grundlagen-Augaben|Linux Grundlagen-Augaben]]<br /> * [[Linux Misc]]<br /> * [[Administration Aufgaben]]<br /> * [[Netzwerkkonfiguration Aufgaben]]<br /> * [[LVM Aufgaben]]<br /> * [[RAID Aufgaben]]<br /> * [[NTP Aufgaben]]<br /> * [[APT Aufgaben]]<br /> * [[Aptitude Aufgaben]]<br /> * [[dpkg Aufgaben]]<br /> * [[tar Aufgaben]]<br /> * [[Module]]<br /> * [[Cron Aufgaben]]<br /> * [[Apache2 Aufgaben]]</div>

192.168.254.27 https://www.xinux.net/index.php?title=Aufgaben&diff=644 Aufgaben 2009-07-31T11:03:42Z

<p>192.168.254.27: </p> <hr /> <div>* [[Linux Grundlagen-Augaben|Linux Grundlagen-Augaben]]<br /> * [[Linux Misc]]<br /> * [[Administration Aufgaben]]<br /> * [[Netzwerkkonfiguration Aufgaben]]<br /> * [[LVM Aufgaben]]<br /> * [[RAID Aufgaben]]<br /> * [[NTP Aufgaben]]<br /> * [[APT Aufgaben]]<br /> * [[Aptitude Aufgaben]]<br /> * [[dpkg Aufgaben]]<br /> * [[tar Aufgaben]]<br /> * [[Module]]<br /> * [[Cron Aufgaben]]</div>

192.168.254.27 https://www.xinux.net/index.php?title=Aufgaben&diff=643 Aufgaben 2009-07-31T11:03:28Z

<p>192.168.254.27: </p> <hr /> <div>* [[Linux Grundlagen-Augaben|Linux Grundlagen-Augaben]]<br /> * [[Linux Misc]]<br /> * [[Administration Aufgaben]]<br /> * [[Netzwerkkonfiguration Aufgaben]]<br /> * [[LVM Aufgaben]]<br /> * [[RAID Aufgaben]]<br /> * [[NTP Aufgaben]]<br /> * [[APT Aufgaben]]<br /> * [[Aptitude Aufgaben]]<br /> * [[dpkg Aufgaben]]<br /> * [[tar Aufgaben]]<br /> * [[Module]]<br /> * [[Cron]]</div>

192.168.254.27 https://www.xinux.net/index.php?title=Cron&diff=642 Cron 2009-07-31T10:56:52Z

<p>192.168.254.27: /* Aufbau einer Crontab Datei */</p> <hr /> <div>Der '''cron'''-Daemon ist eine Jobsteuerung von Unix bzw. unixartigen Betriebssystemen wie Linux, BSD oder Mac OS X, die wiederkehrende Aufgaben ''(cronjobs)'' automatisch zu einer bestimmten Zeit ausführen kann.<br /> <br /> Häufig führt der Cron-Daemon wichtige Programme für die Instandhaltung des Systems aus, wie zum Beispiel Dienste für das regelmäßige Archivieren und Löschen von Logdateien.<br /> <br /> Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen. Diese Anweisungen werden Cron-Tabellen oder eben crontabs genannt. <br /> Cron läd beim Start all die Dateien und Verzeichnisse, die er überwacht in den Arbeitsspeicher und überprüft jede Minute einmal, ob darin Jobs enthalten sind, die in der aktuellen Minute ausgeführt werden sollen. Wenn ja, so führt er sie aus. Außerdem überprüft cron jede Minute, ob sich an den Dateien oder Verzeichnissen etwas geändert hat und - falls ja - übernimmt er diese Änderungen im Speicher. <br /> Es gibt also mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> Es gibt mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> '''User-Crontabs'''<br /> <br /> Jeder User des Systems kann eine eigene Crontab (also eine Datei mit Anweisungen für Cron) erstellen und bearbeiten. Die Jobs, die darin aufgeführt sind werden von Cron unter der Userkennung des Users ausgeführt, um dessen Crontab-Datei es sich handelt. Die User-Crontabs werden nicht direkt mit einem Editor verändert, sondern mit dem Befehl crontab(1). <br /> <br /> '''Systemweite Crontab-Datei'''<br /> <br /> Im Verzeichnis /etc existiert eine Datei crontab, die ebenfalls Cronjobs definiert. Das Format dieser Datei unterscheidet sich etwas von dem der Usercrontabs - siehe weiter unten... <br /> <br /> '''cron.d Verzeichnis'''<br /> <br /> Im Verzeichnis /etc kann ein Verzeichnis cron.d existieren, das Dateien im selben Format wie /etc/crontab enthalten darf. Auch diese Dateien werden von cron überwacht und darin enthaltene Befehle werden ausgeführt. <br /> '''cron.{hourly,daily,weekly,monthly} Verzeichnisse'''<br /> Ebenfalls im /etc/verzeichnis können Verzeichnisse der Namen cron.hourly, cron.daily, cron.weekly und cron.monthly existieren. Diese Verzeichnisse enthalten nicht crontabs, sondern Shellscripts, die entsprechend stündlich, täglich, wöchentlich oder monatlich ausgeführt werden. <br /> <br /> <br /> = Aufbau einer Crontab Datei=<br /> <br /> Die auszuführenden Befehle werden in einer benutzereigenen Tabelle gespeichert, der sogenannten ''crontab''. Jeder Benutzer kann eine crontab erstellen. <br /> Crontab-Einträge sind entweder Definitionen von Shellvariablen oder zeitgesteuerte Cron-Befehle. Leere Zeilen oder Zeilen, die mit einem # beginnen werden ignoriert.<br /> <br /> Normalerweise schickt cron alle Ausgaben von ausgeführten Kommandos per Mail an den User, der das Cron-Kommando ausführen liess. Die Variable MAILTO kann diese Eigenschaft verändern. Wenn sie den Namen eines Users enthält, so werden ihm und nicht dem ursprünglichen Cron-User die Mail geschickt. Ist die Variable MAILTO definiert, aber leer, so wird gar keine Mail verschickt. <br /> <br /> Diese zeitgesteuerten Cron-Befehle bestehen aus sechs Spalten; die ersten fünf dienen der Zeitangabe (Minute, Stunde, Tag, Monat, Wochentag), alle weiteren Zeichen bis zum Zeilenumbruch werden als der auszuführende Befehl aufgefasst. Die einzelnen Spalten werden durch Leerzeichen oder Tabulatoren getrennt.<br /> <br /> Beispiel einer ''Crontab'':<br /> SHELL=/bin/bash<br /> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin<br /> MAILTO=""<br /> <br /> #M S T M W Befehl<br /> 5 * * * * /usr/bin/message.sh<br /> */5 * * * * /usr/bin/message.sh<br /> 59 23 * * 0 cp /var/log/messages /log/backup/messages<br /> 0 0 * * * cp /var/log/syslog /log/backup/syslog<br /> 20,30 1 * * 1-5 /usr/bin/work.sh<br /> <br /> Der erste Befehl (beginnend mit <tt>5…</tt>) wird fünf Minuten nach jeder vollen Stunde, der zweite alle 5 Minuten (die Schrittweite wird durch <tt>*/Schrittweite</tt> angegeben), der dritte einmal pro Woche sonntags um 23:59 Uhr, der vierte täglich um 00:00 Uhr und der fünfte montags bis freitags jeweils um 01:20 und 01:30 ausgeführt.<br /> <br /> Die Struktur der Befehlszeile ist wie folgt zu verstehen:<br /> <br /> * * * * * auszuführender Befehl<br /> ┬ ┬ ┬ ┬ ┬<br /> │ │ │ │ │<br /> │ │ │ │ └──── Wochentag (0-7 oder Sun, Mon, Tue,etc) (Sonntag =0 oder =7)<br /> │ │ │ └────── Monat (1-12 oder Jan, Feb, etc)<br /> │ │ └──────── Tag (1-31)<br /> │ └────────── Stunde (0-23)<br /> └──────────── Minute (0-59)<br /> <br /> <br /> Ein Feld für eine Zeitangab kann dabei mehrere Angaben enthalten:<br /> <br /> {|border=1 cellpadding=2<br /> |<br /> |Syntax<br /> |Beispiel<br /> |-<br /> |Voller Bereich<br /> |*<br /> |Bei Minute: 0,1,2,3,...,59<br /> |-<br /> |Ausgweählter Bereich<br /> |1-5<br /> |entspricht 1,2,3,4,5<br /> |-<br /> |Liste<br /> |1,5,10<br /> |nur an den angegebenen Werten<br /> |-<br /> |Kombination<br /> |2,5,30-40<br /> |Kombination aus Liste und Bereich<br /> |-<br /> |Schritte<br /> |*/5<br /> |bei Minute: alle 5 Minuten<br /> |-<br /> |Kombination<br /> |2-47/5<br /> |alle 5 Minten im Bereich 2-47 (2,7,12,...)<br /> |}<br /> <br /> Werden in einem Feld Namen benutzt, so sind Bereiche und Listen nicht erlaubt.<br /> <br /> Statt der ersten 5 Felder zur Zeitangabe können auch folgende speziellen Angaben erfolgen:<br /> <br /> {|border=1 cellpadding=2<br /> |Angabe<br /> |Bedeutung<br /> |-<br /> |@reboot<br /> |Läuft einmal bei einem Reboot<br /> |-<br /> |@yearly <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@annually <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@monthly<br /> |Läuft einmal im Monat (0 0 1 * *)<br /> |-<br /> |@weekly<br /> |Läuft einmal wöchentlich (0 0 * * 0)<br /> |-<br /> |@daily<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@midnight<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@hourly<br /> |Läuft einmal stündlich (* * * *)<br /> |}<br /> <br /> =Verwalten von User Crontabs=<br /> '''Ansehen der aktuellen Crontab'''<br /> root@nazgul:~# crontab -l<br /> '''Erstellen / Bearbeiten der Crontab'''<br /> root@nazgul:~# crontab -e<br /> '''Löschen der Crontab'''<br /> root@nazgul:~# crontab -r<br /> '''Inhalt von vorhandener Datei als Crontab setzen'''<br /> root@nazgul:~# crontab dateiname<br /> '''Ansehen der Crontab eines anderen Benutzers (nur root)'''<br /> root@nazgul:~# crontab -lu tina<br /> <br /> =System Crontab(s)=<br /> <br /> Im Unterschied zu User Crontabs gibt es ein zusätzliches Feld das angibt, unter welchem Benutzer der aufzurufende Befehl ausgeführt werden soll.<br /> M S T M WT User Befehl<br /> 2 0,5,10,15,20 * * 1-6 root if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --analyze >/dev/null; fi<br /> <br /> <br /> Neben der Datei /etc/crontab und dem Verzeichnis /etc/cron.d existieren in vielen Linux-Distributionen (RedHat, Debian, SuSE,...) auch noch die Verzeichnisse <br /> /etc/cron.hourly<br /> /etc/cron.daily<br /> /etc/cron.weekly<br /> /etc/cron.monthly<br /> <br /> Diese Verzeichnisse enthalten keine Crontabs, sondern Programme, die entsprechend stündlich, täglich, wöchentlich oder monatlich einmal ausgeführt werden sollen. In der Regel handelt es sich bei diesen Programmen um Shellscripts, die dann wiederum bestimmte Programme aufrufen. <br /> Die Ausführung dieser Programme steuert cron mit Hilfe der Datei '''/etc/crontab''' .<br /> <br /> Im Verzeichnis '''/etc/cron.d''' befinden sich Systemweit gültige Crontabs.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Cron&diff=641 Cron 2009-07-31T10:56:35Z

<p>192.168.254.27: /* Aufbau einer Crontab Datei */</p> <hr /> <div>Der '''cron'''-Daemon ist eine Jobsteuerung von Unix bzw. unixartigen Betriebssystemen wie Linux, BSD oder Mac OS X, die wiederkehrende Aufgaben ''(cronjobs)'' automatisch zu einer bestimmten Zeit ausführen kann.<br /> <br /> Häufig führt der Cron-Daemon wichtige Programme für die Instandhaltung des Systems aus, wie zum Beispiel Dienste für das regelmäßige Archivieren und Löschen von Logdateien.<br /> <br /> Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen. Diese Anweisungen werden Cron-Tabellen oder eben crontabs genannt. <br /> Cron läd beim Start all die Dateien und Verzeichnisse, die er überwacht in den Arbeitsspeicher und überprüft jede Minute einmal, ob darin Jobs enthalten sind, die in der aktuellen Minute ausgeführt werden sollen. Wenn ja, so führt er sie aus. Außerdem überprüft cron jede Minute, ob sich an den Dateien oder Verzeichnissen etwas geändert hat und - falls ja - übernimmt er diese Änderungen im Speicher. <br /> Es gibt also mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> Es gibt mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> '''User-Crontabs'''<br /> <br /> Jeder User des Systems kann eine eigene Crontab (also eine Datei mit Anweisungen für Cron) erstellen und bearbeiten. Die Jobs, die darin aufgeführt sind werden von Cron unter der Userkennung des Users ausgeführt, um dessen Crontab-Datei es sich handelt. Die User-Crontabs werden nicht direkt mit einem Editor verändert, sondern mit dem Befehl crontab(1). <br /> <br /> '''Systemweite Crontab-Datei'''<br /> <br /> Im Verzeichnis /etc existiert eine Datei crontab, die ebenfalls Cronjobs definiert. Das Format dieser Datei unterscheidet sich etwas von dem der Usercrontabs - siehe weiter unten... <br /> <br /> '''cron.d Verzeichnis'''<br /> <br /> Im Verzeichnis /etc kann ein Verzeichnis cron.d existieren, das Dateien im selben Format wie /etc/crontab enthalten darf. Auch diese Dateien werden von cron überwacht und darin enthaltene Befehle werden ausgeführt. <br /> '''cron.{hourly,daily,weekly,monthly} Verzeichnisse'''<br /> Ebenfalls im /etc/verzeichnis können Verzeichnisse der Namen cron.hourly, cron.daily, cron.weekly und cron.monthly existieren. Diese Verzeichnisse enthalten nicht crontabs, sondern Shellscripts, die entsprechend stündlich, täglich, wöchentlich oder monatlich ausgeführt werden. <br /> <br /> <br /> = Aufbau einer Crontab Datei=<br /> <br /> Die auszuführenden Befehle werden in einer benutzereigenen Tabelle gespeichert, der sogenannten ''crontab''. Jeder Benutzer kann eine crontab erstellen. <br /> Crontab-Einträge sind entweder Definitionen von Shellvariablen oder zeitgesteuerte Cron-Befehle. Leere Zeilen oder Zeilen, die mit einem # beginnen werden ignoriert.<br /> <br /> Normalerweise schickt cron alle Ausgaben von ausgeführten Kommandos per Mail an den User, der das Cron-Kommando ausführen liess. Die Variable MAILTO kann diese Eigenschaft verändern. Wenn sie den Namen eines Users enthält, so werden ihm und nicht dem ursprünglichen Cron-User die Mail geschickt. Ist die Variable MAILTO definiert, aber leer, so wird gar keine Mail verschickt. <br /> <br /> Diese zeitgesteuerten Cron-Befehle bestehen aus sechs Spalten; die ersten fünf dienen der Zeitangabe (Minute, Stunde, Tag, Monat, Wochentag), alle weiteren Zeichen bis zum Zeilenumbruch werden als der auszuführende Befehl aufgefasst. Die einzelnen Spalten werden durch Leerzeichen oder Tabulatoren getrennt.<br /> <br /> Beispiel einer ''Crontab'':<br /> SHELL=/bin/bash<br /> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin<br /> MAILTO=""<br /> <br /> #M S T M W Befehl<br /> 5 * * * * /usr/bin/message.sh<br /> */5 * * * * /usr/bin/message.sh<br /> 59 23 * * 0 cp /var/log/messages /log/backup/messages<br /> 0 0 * * * cp /var/log/syslog /log/backup/syslog<br /> 20,30 1 * * 1-5 /usr/bin/work.sh<br /> <br /> Der erste Befehl (beginnend mit <tt>5…</tt>) wird fünf Minuten nach jeder vollen Stunde, der zweite alle 5 Minuten (die Schrittweite wird durch <tt>*/Schrittweite</tt> angegeben), der dritte einmal pro Woche sonntags um 23:59 Uhr, der vierte täglich um 00:00 Uhr und der fünfte montags bis freitags jeweils um 01:20 und 01:30 ausgeführt.<br /> <br /> Die Struktur der Befehlszeile ist wie folgt zu verstehen:<br /> <br /> * * * * * auszuführender Befehl<br /> ┬ ┬ ┬ ┬ ┬<br /> │ │ │ │ │<br /> │ │ │ │ └──── Wochentag (0-7 oder Sun, Mon, Tue,etc) (Sonntag =0 oder =7)<br /> │ │ │ └────── Monat (1-12 oder Jan, Feb, etc)<br /> │ │ └──────── Tag (1-31)<br /> │ └────────── Stunde (0-23)<br /> └──────────── Minute (0-59)<br /> <br /> <br /> Ein Feld für eine Zeitangab kann dabei mehrere Angaben enthalten:<br /> <br /> {|border=1 cellpadding=2<br /> |<br /> |Syntax<br /> |Beispiel<br /> |-<br /> |Voller Bereich<br /> |*<br /> |Bei Minute: 0,1,2,3,...,59<br /> |-<br /> |Ausgweählter Bereich<br /> |1-5<br /> |entspricht 1,2,3,4,5<br /> |-<br /> |Liste<br /> |1,5,10<br /> |nur an den angegebenen Werten<br /> |-<br /> |Kombination<br /> |2,5,30-40<br /> |Kombination aus Liste und Bereich<br /> |-<br /> |Schritte<br /> |*/5<br /> |bei Minute: alle 5 Minuten<br /> |-<br /> |Kombination<br /> |2-47/5<br /> |alle 5 Minten im Bereich 2-47 (2,7,12,...)<br /> |}<br /> <br /> Werden in einem Feld Namen benutzt, so sind Bereiche und Listen nicht erlaubt.<br /> <br /> Statt der ersten 5 Felder zur Zeitangabe können auch folgende speziellen Angaben erfolgen:<br /> <br /> {|border=1 cellpadding=2<br /> |Angabe<br /> |Bedeutung<br /> |-<br /> |@reboot<br /> |Läuft einma bei einem Reboot<br /> |-<br /> |@yearly <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@annually <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@monthly<br /> |Läuft einmal im Monat (0 0 1 * *)<br /> |-<br /> |@weekly<br /> |Läuft einmal wöchentlich (0 0 * * 0)<br /> |-<br /> |@daily<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@midnight<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@hourly<br /> |Läuft einmal stündlich (* * * *)<br /> |}<br /> <br /> =Verwalten von User Crontabs=<br /> '''Ansehen der aktuellen Crontab'''<br /> root@nazgul:~# crontab -l<br /> '''Erstellen / Bearbeiten der Crontab'''<br /> root@nazgul:~# crontab -e<br /> '''Löschen der Crontab'''<br /> root@nazgul:~# crontab -r<br /> '''Inhalt von vorhandener Datei als Crontab setzen'''<br /> root@nazgul:~# crontab dateiname<br /> '''Ansehen der Crontab eines anderen Benutzers (nur root)'''<br /> root@nazgul:~# crontab -lu tina<br /> <br /> =System Crontab(s)=<br /> <br /> Im Unterschied zu User Crontabs gibt es ein zusätzliches Feld das angibt, unter welchem Benutzer der aufzurufende Befehl ausgeführt werden soll.<br /> M S T M WT User Befehl<br /> 2 0,5,10,15,20 * * 1-6 root if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --analyze >/dev/null; fi<br /> <br /> <br /> Neben der Datei /etc/crontab und dem Verzeichnis /etc/cron.d existieren in vielen Linux-Distributionen (RedHat, Debian, SuSE,...) auch noch die Verzeichnisse <br /> /etc/cron.hourly<br /> /etc/cron.daily<br /> /etc/cron.weekly<br /> /etc/cron.monthly<br /> <br /> Diese Verzeichnisse enthalten keine Crontabs, sondern Programme, die entsprechend stündlich, täglich, wöchentlich oder monatlich einmal ausgeführt werden sollen. In der Regel handelt es sich bei diesen Programmen um Shellscripts, die dann wiederum bestimmte Programme aufrufen. <br /> Die Ausführung dieser Programme steuert cron mit Hilfe der Datei '''/etc/crontab''' .<br /> <br /> Im Verzeichnis '''/etc/cron.d''' befinden sich Systemweit gültige Crontabs.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Cron&diff=640 Cron 2009-07-31T10:56:26Z

<p>192.168.254.27: /* Aufbau einer Crontab Datei */</p> <hr /> <div>Der '''cron'''-Daemon ist eine Jobsteuerung von Unix bzw. unixartigen Betriebssystemen wie Linux, BSD oder Mac OS X, die wiederkehrende Aufgaben ''(cronjobs)'' automatisch zu einer bestimmten Zeit ausführen kann.<br /> <br /> Häufig führt der Cron-Daemon wichtige Programme für die Instandhaltung des Systems aus, wie zum Beispiel Dienste für das regelmäßige Archivieren und Löschen von Logdateien.<br /> <br /> Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen. Diese Anweisungen werden Cron-Tabellen oder eben crontabs genannt. <br /> Cron läd beim Start all die Dateien und Verzeichnisse, die er überwacht in den Arbeitsspeicher und überprüft jede Minute einmal, ob darin Jobs enthalten sind, die in der aktuellen Minute ausgeführt werden sollen. Wenn ja, so führt er sie aus. Außerdem überprüft cron jede Minute, ob sich an den Dateien oder Verzeichnissen etwas geändert hat und - falls ja - übernimmt er diese Änderungen im Speicher. <br /> Es gibt also mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> Es gibt mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> '''User-Crontabs'''<br /> <br /> Jeder User des Systems kann eine eigene Crontab (also eine Datei mit Anweisungen für Cron) erstellen und bearbeiten. Die Jobs, die darin aufgeführt sind werden von Cron unter der Userkennung des Users ausgeführt, um dessen Crontab-Datei es sich handelt. Die User-Crontabs werden nicht direkt mit einem Editor verändert, sondern mit dem Befehl crontab(1). <br /> <br /> '''Systemweite Crontab-Datei'''<br /> <br /> Im Verzeichnis /etc existiert eine Datei crontab, die ebenfalls Cronjobs definiert. Das Format dieser Datei unterscheidet sich etwas von dem der Usercrontabs - siehe weiter unten... <br /> <br /> '''cron.d Verzeichnis'''<br /> <br /> Im Verzeichnis /etc kann ein Verzeichnis cron.d existieren, das Dateien im selben Format wie /etc/crontab enthalten darf. Auch diese Dateien werden von cron überwacht und darin enthaltene Befehle werden ausgeführt. <br /> '''cron.{hourly,daily,weekly,monthly} Verzeichnisse'''<br /> Ebenfalls im /etc/verzeichnis können Verzeichnisse der Namen cron.hourly, cron.daily, cron.weekly und cron.monthly existieren. Diese Verzeichnisse enthalten nicht crontabs, sondern Shellscripts, die entsprechend stündlich, täglich, wöchentlich oder monatlich ausgeführt werden. <br /> <br /> <br /> = Aufbau einer Crontab Datei=<br /> <br /> Die auszuführenden Befehle werden in einer benutzereigenen Tabelle gespeichert, der sogenannten ''crontab''. Jeder Benutzer kann eine crontab erstellen. <br /> Crontab-Einträge sind entweder Definitionen von Shellvariablen oder zeitgesteuerte Cron-Befehle. Leere Zeilen oder Zeilen, die mit einem # beginnen werden ignoriert.<br /> <br /> Normalerweise schickt cron alle Ausgaben von ausgeführten Kommandos per Mail an den User, der das Cron-Kommando ausführen liess. Die Variable MAILTO kann diese Eigenschaft verändern. Wenn sie den Namen eines Users enthält, so werden ihm und nicht dem ursprünglichen Cron-User die Mail geschickt. Ist die Variable MAILTO definiert, aber leer, so wird gar keine Mail verschickt. <br /> <br /> Diese zeitgesteuerten Cron-Befehle bestehen aus sechs Spalten; die ersten fünf dienen der Zeitangabe (Minute, Stunde, Tag, Monat, Wochentag), alle weiteren Zeichen bis zum Zeilenumbruch werden als der auszuführende Befehl aufgefasst. Die einzelnen Spalten werden durch Leerzeichen oder Tabulatoren getrennt.<br /> <br /> Beispiel einer ''Crontab'':<br /> SHELL=/bin/bash<br /> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin<br /> MAILTO=""<br /> <br /> #M S T M W Befehl<br /> 5 * * * * /usr/bin/message.sh<br /> */5 * * * * /usr/bin/message.sh<br /> 59 23 * * 0 cp /var/log/messages /log/backup/messages<br /> 0 0 * * * cp /var/log/syslog /log/backup/syslog<br /> 20,30 1 * * 1-5 /usr/bin/work.sh<br /> <br /> Der erste Befehl (beginnend mit <tt>5…</tt>) wird fünf Minuten nach jeder vollen Stunde, der zweite alle 5 Minuten (die Schrittweite wird durch <tt>*/Schrittweite</tt> angegeben), der dritte einmal pro Woche sonntags um 23:59 Uhr, der vierte täglich um 00:00 Uhr und der fünfte montags bis freitags jeweils um 01:20 und 01:30 ausgeführt.<br /> <br /> Die Struktur der Befehlszeile ist wie folgt zu verstehen:<br /> <br /> * * * * * auszuführender Befehl<br /> ┬ ┬ ┬ ┬ ┬<br /> │ │ │ │ │<br /> │ │ │ │ └──── Wochentag (0-7 oder Sun, Mon, Tue,etc) (Sonntag =0 oder =7)<br /> │ │ │ └────── Monat (1-12 oder Jan, Feb, etc)<br /> │ │ └──────── Tag (1-31)<br /> │ └────────── Stunde (0-23)<br /> └──────────── Minute (0-59)<br /> <br /> <br /> Ein Feld für eine Zeitangab kann dabei mehrere Angaben enthalten:<br /> <br /> {|border=1 cellpadding=2<br /> <br /> |Syntax<br /> |Beispiel<br /> |-<br /> |Voller Bereich<br /> |*<br /> |Bei Minute: 0,1,2,3,...,59<br /> |-<br /> |Ausgweählter Bereich<br /> |1-5<br /> |entspricht 1,2,3,4,5<br /> |-<br /> |Liste<br /> |1,5,10<br /> |nur an den angegebenen Werten<br /> |-<br /> |Kombination<br /> |2,5,30-40<br /> |Kombination aus Liste und Bereich<br /> |-<br /> |Schritte<br /> |*/5<br /> |bei Minute: alle 5 Minuten<br /> |-<br /> |Kombination<br /> |2-47/5<br /> |alle 5 Minten im Bereich 2-47 (2,7,12,...)<br /> |}<br /> <br /> Werden in einem Feld Namen benutzt, so sind Bereiche und Listen nicht erlaubt.<br /> <br /> Statt der ersten 5 Felder zur Zeitangabe können auch folgende speziellen Angaben erfolgen:<br /> <br /> {|border=1 cellpadding=2<br /> |Angabe<br /> |Bedeutung<br /> |-<br /> |@reboot<br /> |Läuft einma bei einem Reboot<br /> |-<br /> |@yearly <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@annually <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@monthly<br /> |Läuft einmal im Monat (0 0 1 * *)<br /> |-<br /> |@weekly<br /> |Läuft einmal wöchentlich (0 0 * * 0)<br /> |-<br /> |@daily<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@midnight<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@hourly<br /> |Läuft einmal stündlich (* * * *)<br /> |}<br /> <br /> =Verwalten von User Crontabs=<br /> '''Ansehen der aktuellen Crontab'''<br /> root@nazgul:~# crontab -l<br /> '''Erstellen / Bearbeiten der Crontab'''<br /> root@nazgul:~# crontab -e<br /> '''Löschen der Crontab'''<br /> root@nazgul:~# crontab -r<br /> '''Inhalt von vorhandener Datei als Crontab setzen'''<br /> root@nazgul:~# crontab dateiname<br /> '''Ansehen der Crontab eines anderen Benutzers (nur root)'''<br /> root@nazgul:~# crontab -lu tina<br /> <br /> =System Crontab(s)=<br /> <br /> Im Unterschied zu User Crontabs gibt es ein zusätzliches Feld das angibt, unter welchem Benutzer der aufzurufende Befehl ausgeführt werden soll.<br /> M S T M WT User Befehl<br /> 2 0,5,10,15,20 * * 1-6 root if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --analyze >/dev/null; fi<br /> <br /> <br /> Neben der Datei /etc/crontab und dem Verzeichnis /etc/cron.d existieren in vielen Linux-Distributionen (RedHat, Debian, SuSE,...) auch noch die Verzeichnisse <br /> /etc/cron.hourly<br /> /etc/cron.daily<br /> /etc/cron.weekly<br /> /etc/cron.monthly<br /> <br /> Diese Verzeichnisse enthalten keine Crontabs, sondern Programme, die entsprechend stündlich, täglich, wöchentlich oder monatlich einmal ausgeführt werden sollen. In der Regel handelt es sich bei diesen Programmen um Shellscripts, die dann wiederum bestimmte Programme aufrufen. <br /> Die Ausführung dieser Programme steuert cron mit Hilfe der Datei '''/etc/crontab''' .<br /> <br /> Im Verzeichnis '''/etc/cron.d''' befinden sich Systemweit gültige Crontabs.</div>

192.168.254.27 https://www.xinux.net/index.php?title=Cron&diff=639 Cron 2009-07-31T10:56:00Z

<p>192.168.254.27: /* Aufbau einer Crontab Datei */</p> <hr /> <div>Der '''cron'''-Daemon ist eine Jobsteuerung von Unix bzw. unixartigen Betriebssystemen wie Linux, BSD oder Mac OS X, die wiederkehrende Aufgaben ''(cronjobs)'' automatisch zu einer bestimmten Zeit ausführen kann.<br /> <br /> Häufig führt der Cron-Daemon wichtige Programme für die Instandhaltung des Systems aus, wie zum Beispiel Dienste für das regelmäßige Archivieren und Löschen von Logdateien.<br /> <br /> Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen. Diese Anweisungen werden Cron-Tabellen oder eben crontabs genannt. <br /> Cron läd beim Start all die Dateien und Verzeichnisse, die er überwacht in den Arbeitsspeicher und überprüft jede Minute einmal, ob darin Jobs enthalten sind, die in der aktuellen Minute ausgeführt werden sollen. Wenn ja, so führt er sie aus. Außerdem überprüft cron jede Minute, ob sich an den Dateien oder Verzeichnissen etwas geändert hat und - falls ja - übernimmt er diese Änderungen im Speicher. <br /> Es gibt also mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> Es gibt mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind: <br /> <br /> '''User-Crontabs'''<br /> <br /> Jeder User des Systems kann eine eigene Crontab (also eine Datei mit Anweisungen für Cron) erstellen und bearbeiten. Die Jobs, die darin aufgeführt sind werden von Cron unter der Userkennung des Users ausgeführt, um dessen Crontab-Datei es sich handelt. Die User-Crontabs werden nicht direkt mit einem Editor verändert, sondern mit dem Befehl crontab(1). <br /> <br /> '''Systemweite Crontab-Datei'''<br /> <br /> Im Verzeichnis /etc existiert eine Datei crontab, die ebenfalls Cronjobs definiert. Das Format dieser Datei unterscheidet sich etwas von dem der Usercrontabs - siehe weiter unten... <br /> <br /> '''cron.d Verzeichnis'''<br /> <br /> Im Verzeichnis /etc kann ein Verzeichnis cron.d existieren, das Dateien im selben Format wie /etc/crontab enthalten darf. Auch diese Dateien werden von cron überwacht und darin enthaltene Befehle werden ausgeführt. <br /> '''cron.{hourly,daily,weekly,monthly} Verzeichnisse'''<br /> Ebenfalls im /etc/verzeichnis können Verzeichnisse der Namen cron.hourly, cron.daily, cron.weekly und cron.monthly existieren. Diese Verzeichnisse enthalten nicht crontabs, sondern Shellscripts, die entsprechend stündlich, täglich, wöchentlich oder monatlich ausgeführt werden. <br /> <br /> <br /> = Aufbau einer Crontab Datei=<br /> <br /> Die auszuführenden Befehle werden in einer benutzereigenen Tabelle gespeichert, der sogenannten ''crontab''. Jeder Benutzer kann eine crontab erstellen. <br /> Crontab-Einträge sind entweder Definitionen von Shellvariablen oder zeitgesteuerte Cron-Befehle. Leere Zeilen oder Zeilen, die mit einem # beginnen werden ignoriert.<br /> <br /> Normalerweise schickt cron alle Ausgaben von ausgeführten Kommandos per Mail an den User, der das Cron-Kommando ausführen liess. Die Variable MAILTO kann diese Eigenschaft verändern. Wenn sie den Namen eines Users enthält, so werden ihm und nicht dem ursprünglichen Cron-User die Mail geschickt. Ist die Variable MAILTO definiert, aber leer, so wird gar keine Mail verschickt. <br /> <br /> Diese zeitgesteuerten Cron-Befehle bestehen aus sechs Spalten; die ersten fünf dienen der Zeitangabe (Minute, Stunde, Tag, Monat, Wochentag), alle weiteren Zeichen bis zum Zeilenumbruch werden als der auszuführende Befehl aufgefasst. Die einzelnen Spalten werden durch Leerzeichen oder Tabulatoren getrennt.<br /> <br /> Beispiel einer ''Crontab'':<br /> SHELL=/bin/bash<br /> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin<br /> MAILTO=""<br /> <br /> #M S T M W Befehl<br /> 5 * * * * /usr/bin/message.sh<br /> */5 * * * * /usr/bin/message.sh<br /> 59 23 * * 0 cp /var/log/messages /log/backup/messages<br /> 0 0 * * * cp /var/log/syslog /log/backup/syslog<br /> 20,30 1 * * 1-5 /usr/bin/work.sh<br /> <br /> Der erste Befehl (beginnend mit <tt>5…</tt>) wird fünf Minuten nach jeder vollen Stunde, der zweite alle 5 Minuten (die Schrittweite wird durch <tt>*/Schrittweite</tt> angegeben), der dritte einmal pro Woche sonntags um 23:59 Uhr, der vierte täglich um 00:00 Uhr und der fünfte montags bis freitags jeweils um 01:20 und 01:30 ausgeführt.<br /> <br /> Die Struktur der Befehlszeile ist wie folgt zu verstehen:<br /> <br /> * * * * * auszuführender Befehl<br /> ┬ ┬ ┬ ┬ ┬<br /> │ │ │ │ │<br /> │ │ │ │ └──── Wochentag (0-7 oder Sun, Mon, Tue,etc) (Sonntag =0 oder =7)<br /> │ │ │ └────── Monat (1-12 oder Jan, Feb, etc)<br /> │ │ └──────── Tag (1-31)<br /> │ └────────── Stunde (0-23)<br /> └──────────── Minute (0-59)<br /> <br /> <br /> Ein Feld für eine Zeitangab kann dabei mehrere Angaben enthalten:<br /> <br /> {|border=1 cellpadding=2<br /> |Syntax<br /> |Beispiel<br /> |-<br /> |Voller Bereich<br /> |*<br /> |Bei Minute: 0,1,2,3,...,59<br /> |-<br /> |Ausgweählter Bereich<br /> |1-5<br /> |entspricht 1,2,3,4,5<br /> |-<br /> |Liste<br /> |1,5,10<br /> |nur an den angegebenen Werten<br /> |-<br /> |Kombination<br /> |2,5,30-40<br /> |Kombination aus Liste und Bereich<br /> |-<br /> |Schritte<br /> |*/5<br /> |bei Minute: alle 5 Minuten<br /> |-<br /> |Kombination<br /> |2-47/5<br /> |alle 5 Minten im Bereich 2-47 (2,7,12,...)<br /> |}<br /> <br /> Werden in einem Feld Namen benutzt, so sind Bereiche und Listen nicht erlaubt.<br /> <br /> Statt der ersten 5 Felder zur Zeitangabe können auch folgende speziellen Angaben erfolgen:<br /> {|vorder=1 cellpadding=2<br /> |Angabe<br /> |Bedeutung<br /> |-<br /> |@reboot<br /> |Läuft einma bei einem Reboot<br /> |-<br /> |@yearly <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@annually <br /> |Läuft einmal im Jahr (0 0 1 1 *)<br /> |-<br /> |@monthly<br /> |Läuft einmal im Monat (0 0 1 * *)<br /> |-<br /> |@weekly<br /> |Läuft einmal wöchentlich (0 0 * * 0)<br /> |-<br /> |@daily<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@midnight<br /> |Läuft einmal täglich (0 0 * * *)<br /> |-<br /> |@hourly<br /> |Läuft einmal stündlich (* * * *)<br /> |}<br /> <br /> =Verwalten von User Crontabs=<br /> '''Ansehen der aktuellen Crontab'''<br /> root@nazgul:~# crontab -l<br /> '''Erstellen / Bearbeiten der Crontab'''<br /> root@nazgul:~# crontab -e<br /> '''Löschen der Crontab'''<br /> root@nazgul:~# crontab -r<br /> '''Inhalt von vorhandener Datei als Crontab setzen'''<br /> root@nazgul:~# crontab dateiname<br /> '''Ansehen der Crontab eines anderen Benutzers (nur root)'''<br /> root@nazgul:~# crontab -lu tina<br /> <br /> =System Crontab(s)=<br /> <br /> Im Unterschied zu User Crontabs gibt es ein zusätzliches Feld das angibt, unter welchem Benutzer der aufzurufende Befehl ausgeführt werden soll.<br /> M S T M WT User Befehl<br /> 2 0,5,10,15,20 * * 1-6 root if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --analyze >/dev/null; fi<br /> <br /> <br /> Neben der Datei /etc/crontab und dem Verzeichnis /etc/cron.d existieren in vielen Linux-Distributionen (RedHat, Debian, SuSE,...) auch noch die Verzeichnisse <br /> /etc/cron.hourly<br /> /etc/cron.daily<br /> /etc/cron.weekly<br /> /etc/cron.monthly<br /> <br /> Diese Verzeichnisse enthalten keine Crontabs, sondern Programme, die entsprechend stündlich, täglich, wöchentlich oder monatlich einmal ausgeführt werden sollen. In der Regel handelt es sich bei diesen Programmen um Shellscripts, die dann wiederum bestimmte Programme aufrufen. <br /> Die Ausführung dieser Programme steuert cron mit Hilfe der Datei '''/etc/crontab''' .<br /> <br /> Im Verzeichnis '''/etc/cron.d''' befinden sich Systemweit gültige Crontabs.</div>

192.168.254.27