>On Fri, 7 Dec 2001, GOMEZ Henri wrote: > >> Caution, caution with security. >> >> On many sites, the web-server is located on a DMZ so subject >> to be hacked, while the Tomcats are behind firewall. Having >> webapp (program) could raise many problems. > >Hmm... I hope sandboxing is used for tomcat in this case...
The problem is not sandboxing but really that a web-server is often in a low-security zone and should be considered as possibly compromized. You could have the static part of a webapp there since it's a low risk of application discovery but the dynamic part, jsp/servlet/struts's/velocity's/... should be located elsewhere and ideally behind a firewall accepting only ajp communication between web-server and tomcat's. >> INTERNET ---> FW ---> APACHE HTTP -> FW (only ajp13) -> TOMCAT's >> >> Why not imagine that Apache will ask to Tomcat, may be to a >> tomcat tagged a master repository, to be send all the WEBAPPS >> infs ? > >As I said in a previous mail, startup sequence is one big problem. The idea of having one tomcat on a farm of tomcat as the master repository of webapp will even ease the deployment of application. - Put new or updated webapps in master repository - Apache discover updates or creation and update URL mapping accordingly. - Apache could then ask to the master repository to have a copy (may be a .war) of updated/created webapp - Apache then 'upload' the webapp to other tomcats. To enforce security, WEBAPP wars should be encrypted using a key known only by tomcats, that way even if the webserver is compromized, hacker couldn't decrypt the webapp. >The other - I believe it's simpler. Apps must be deployed on apache as >well, or at least the static content ( and with my proposal >WEB-INF/jk.properties ). That's ok for me... >> >mod_jk will use the same logic as tomcat to find all subdirs, >> >and automatically add the contexts. ( using 'global' mappings ) >> >> Why not, I'll be more than happy to remove workers.properties and >> have it included in httpd.conf. Good things will be to map >> VirtualHost to remote Virtual on Tomcat. > >Well... I already added code to allow use of httpd.conf instead of >workers.properties ( I use it for development, so I don't have >to change 2 >files ). Good, did the IIS/iPlanet port could use the same mecanism ? >Virtual hosts are a problem I'm trying to resolve - the current mapper >doesn't seem to have that, not sure how it works on IIS/iPlanet. Do you means that a VirtualHost entry on Apache should ask only for revelant VirtualHost webapps in tomcat ? In ajp14 the virtual host id was the key of autoconf requests. >Regarding my proposal, we can either use 3.3 non-flat webapps/ >( i.e webapps/virtual.host/app ) or have a webapp dir per virtual host, >specified with either > JkWebapps /webapps1 whost1.com > >or inside a <Virtual> directive. >> >- no need to have tomcat running ( or running on >> >the server machine ) >> >> For security reason, i'd like to avoid having webapp code >> (servlet/jsp) on the web-server. And if tomcat is not >> running (locally or remotly), did there is a need to >> do a collect of webapp ? > >For servlets - you can remove them from apache if you want. For jsps - >they could be removed, but ( when I'll have time... ) I want to try >sending the static content of the jsp using apache. It may >work or not - >but I think it's worth trying, and if it works the way I >expect it should >have a good performance benefit. Static part handled by Apache and dynamic by tomcat, and having Apache mix the both before sending back to users ? A great performance gain... >> Could we discuss about a Tomcat 3.3 running as a webapp >> repositories manager ? > >Or in general a config server ? I.e. a server ( tomcatX, >apache, OpenLDAP, >database ) where all configs are stored and the workers >get it automatically ? configs and webapps, a common place for webapps stuff. >Yes, that would be nice - but I think it's more dream-level at this >moment, most people have problems with configuring the simple case. Not sure it will be much difficult by using tomcat in autoconf. ajp14 added URL/webapp discovery, we should add the webapp download (tomcat->apache) and then webapp uploading (apache->tomcats) to make the dream a reality. The sofisticated ORB model you're developp in jk2 should make it more easy and we should reserve these capacity in ajp14 protocol... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
