Tomcat Ports und Virtual Hosts

[Standardweiche]

Hallo Forum,

Hätte eine Frage zu den Ports von Tomcat.

Beim Tomcat 6_0_18 sind in conf/server.xml nun 3 Ports eingetragen (Früher waren es glaub mehr)

Server port shutdown = 8005
Connector port http: 8080, redireceted Port: 8443
Connector port ajp: 8009, redirected port: 8443


1. Für was wäre eigentlich der shutdown und redirected port in verständlichen worten?
ajp port wäre wahrscheinlich der Port, wenn man den Tomcat über Apache verbindet. Connector port http wäre klar.
D.h., ein zweiter Tomcat würde dann wie folgt rennen:
Server port shutdown = 8005
Connector port http: 8081, redireceted Port: 8443
Connector port ajp: 8010 redirected port: 8443
shutdown und redirected Port auch erhöhen?

2. Welche Möglichkeiten gibt es, wenn man mehrere Kunden auf einem Server JSP/Java auf Port 80 zur verfügung stellen will?
2a) mod_proxy wahrscheinlich, der dann demenstprechend die Anfrage an den richtigen Tomcat (Welches auf irgendeinem Port läuft) weiterleitet?
2b) Den Tomcat standalone laufen lassen, da er mittlerweile wahrscheinlich auch vhost unterstützt.
Gäbe es da noch andere alternativen, bzw. welche wäre vorzuziehen?

(Ne Dumme frage. Was wäre eigentlich wenn man im vhost "DocumentRoot" anstatt nen normalen Pfad den Pfad des Tomcat eintragen würde?)


Grüße
Michi

 

[Roger Wilco]

1. Für was wäre eigentlich der shutdown und redirected port in verständlichen worten?

Nicht deutsch, aber verständlich unter Apache Tomcat Configuration Reference - The Server Component und Apache Tomcat Configuration Reference - The HTTP Connector zu finden.

2. Welche Möglichkeiten gibt es, wenn man mehrere Kunden auf einem Server JSP/Java auf Port 80 zur verfügung stellen will?

Kommt darauf an, was du konkret erreichen willst und wie sehr du deinen Kunden vertraust. Wenn du die VirtualHosting-Funktion von Tomcat benutzt, laufen eben alle Java-Anwendungen von allen Benutzern in der gleichen JVM und im gleichen Systembenutzerkontext (dem des Tomcat eben). Das bedeutet, das alle Benutzer prinzipiell (ohne entsprechend eingerichteten SecurityManager) auf alle Dateien der anderen Benutzer im gleichen Tomcat zugreifen können. Im Zweifel könnte ein "böser" Benutzer auch den Tomcat abschießen und ihn so für die anderen Benutzer unbrauchbar machen.

Das kannst du mit mehreren Tomcat-Instanzen hinter einem Reverse Proxy (z. B. einem Apache httpd mit mod_jk oder mod_proxy_html) vermeiden. Dafür benötigst du mehr Hardware-Ressourcen und hast einen erhöhten Administrationsaufwand.

(Ne Dumme frage. Was wäre eigentlich wenn man im vhost "DocumentRoot" anstatt nen normalen Pfad den Pfad des Tomcat eintragen würde?)

Dann kann man, entsprechende Dateiberechtigungen vorausgesetzt, alle Dateien des Tomcat über deinen Webserver auslesen. Nicht zu empfehlen.

 

[Standardweiche]

Nicht deutsch, aber verständlich unter Apache Tomcat Configuration Reference - The Server Component und Apache Tomcat Configuration Reference - The HTTP Connector zu finden.

Danke, shutdown habe ich dann verstanden. Auf dem Port wartet Tomcat auf den Befehl um Tomcat runterzufahren.
Bei redirected:
Ich glaub ich hab das so verstanden: Wenn tomcat kein SSL unterstützt aber dennoch jemand so eine Anfrage sendet, dann leitet das Catalina automatisch auf den genannten Port um.

D.h., wenn der erste Tomcat wie folgt default wäre:
Shutdown-Port: 8005
Connector-Port http: 8080 - Redirected 8443
Connector-Port ajp: 8009 - Redirected 8443

müsste ich dann für den zweiten Tomcat vermutlich diese Ports nehmen:
Shutdown-Port: 8006
Connector-Port http: 8081 - Redirected 8443
Connector-Port ajp: 8010 - Redirected 8443

8443 dürfte ich womöglich bei beiden gleich lassen. (Also nicht 9443)

Kommt darauf an, was du konkret erreichen willst und wie sehr du deinen Kunden vertraust. Wenn du die VirtualHosting-Funktion von Tomcat benutzt, laufen eben alle Java-Anwendungen von allen Benutzern in der gleichen JVM und im gleichen Systembenutzerkontext (dem des Tomcat eben). Das bedeutet, das alle Benutzer prinzipiell (ohne entsprechend eingerichteten SecurityManager) auf alle Dateien der anderen Benutzer im gleichen Tomcat zugreifen können. Im Zweifel könnte ein "böser" Benutzer auch den Tomcat abschießen und ihn so für die anderen Benutzer unbrauchbar machen.

Guter Aspekt. An sowas hatte ich nicht gedacht, da ich den Server nur zu Eigenzwecken bisher genutzt hatte. (Es sollen auch nur 1-2 heer vertraute Personen darauf zugreifen, was aber nicht heißt, dass ich mich dennoch darüber informieren sollte, was zu beachten ist)
Mit vHost bin ich davon ausgegangen, dass es so konfiguriert ist, dass man die Dateien von anderen nicht einsehen kann. (Wie beim Apache, indem man die Ordnerrechte richtig setzt)
Könntest mir in 1-2 Sätzen erklären, worum es beim SecurityManager geht.

Das kannst du mit mehreren Tomcat-Instanzen hinter einem Reverse Proxy (z. B. einem Apache httpd mit mod_jk oder mod_proxy_html) vermeiden. Dafür benötigst du mehr Hardware-Ressourcen und hast einen erhöhten Administrationsaufwand.
Dann kann man, entsprechende Dateiberechtigungen vorausgesetzt, alle Dateien des Tomcat über deinen Webserver auslesen. Nicht zu empfehlen.

mod_proxy hat unser Prof. auch empfohlen gehabt, indem jeder dann seinen eigenen Tomcat hat.

Dann kann man, entsprechende Dateiberechtigungen vorausgesetzt, alle Dateien des Tomcat über deinen Webserver auslesen. Nicht zu empfehlen.

Schuldigung. Aber dies habe ich nicht verstanden?

 

[Roger Wilco]

Ich glaub ich hab das so verstanden: Wenn tomcat kein SSL unterstützt aber dennoch jemand so eine Anfrage sendet, dann leitet das Catalina automatisch auf den genannten Port um.

Nein.

If this Connector is supporting non-SSL requests, and a request is received for which a matching <security-constraint> requires SSL transport, Catalina will automatically redirect the request to the port number specified here.

Wenn der Connector nicht-SSL-Verbindungen erlaubt und gerade solch eine verwendet, aber ein security-constraint (siehe Specifying a Security Constraint (The Java EE 5 Tutorial) - Sun Microsystems) definiert wurde, der die Benutzung einer SSL-gesicherten Verbindung voraussetzt, wird der Client auf den in redirectPort angegebenen Port weitergeleitet, auf dem dann idealerweise eine SSL-gesicherte Verbindung hergestellt wird.

Bei einem Proxy-Setup würde ich den redirectPort überhaupt nicht angeben und die Verbindungsverschlüsselung ausschließlich im Proxy durchführen. Eine SSL-gesicherte Verbindung von localhost nach localhost ist Blödsinn.

Könntest mir in 1-2 Sätzen erklären, worum es beim SecurityManager geht.

Der SecurityManager bestimmt, was ein Programm in der JVM darf und was nicht.

JDK 6 Security-related APIs & Developer Guides -- from Sun Microsystems

Schuldigung. Aber dies habe ich nicht verstanden?

Was hast du denn gedacht was passiert, wenn du das Tomcat-Verzeichnis als DocumentRoot im Apache httpd angibst?

 

[Standardweiche]

Was hast du denn gedacht was passiert, wenn du das Tomcat-Verzeichnis als DocumentRoot im Apache httpd angibst?

Gedacht hab ich mir noch nichts, weil ich noch in diesem Gebiet der Anfänger bin. Sehe seit 2 Wochen leider auch nicht unseren Webengineer-Prof nicht, damit ich ihn ausfragen konnte, bzw. mir nen Überblick über diese Thematik zu schaffen

Mich interessierte es gerade nur, wie so eine Auslesung aussieht:

[..] alle Dateien des Tomcat über deinen Webserver auslesen. Nicht zu empfehlen.

Grüße

 

[Roger Wilco]

Mich interessierte es gerade nur, wie so eine Auslesung aussieht:

Der Apache httpd liefert dann eben alle Dateien aus, auf die er Zugriff hat, inklusive den Quelltext der JSP-Dateien und der web.xml oder context.xml, die eventuell vertrauliche Daten enthalten.

 

[Standardweiche]

Ach, so meinst du das.
Wenn ich die Datei dann über den Browser aufrufe, dass die Antwort nicht über Tomcat ausgegeben wird, sondern der Apache (da er JSP nicht verarbeiten kann), dann einfach die Datei, bzw. deren Inhalt einfach ausgibt.

Gut, jetzt wird es mir klar.

Und, unter "Dateiberechtigung vorrausgesetzt" meinst du wahrscheinlich, dass Apache (oder wer auch immer) die Dateirechte ("OTHER") hat, um die Datei aufzurufen.

Grüße