Hi Jeff,
I normally use the console as the sample application because it is the easiest application to test
and everybody knows where it is. I personally do not believe that anybody will be interested in
having the console exposed :) but for the "just in case", I added a couple of *WARNINGS* in red to
catch the readers attention there ;) ..btw, thanks for the feedback..
I am planning to add an article to discuss different topologies for implementing Geronimo, discuss
the pros and cons of each topology (security, performance, high availability, etc). I think it would
be good to have a few different topologies described (solution oriented) where you could see the
different nodes (remote http, app server, db, ldap, etc.), likelyhood of firewalls and the
connectivity requirements between the nodes.
It would be great to have a few extra hands for working on this topic,
volunteers welcome :)
Cheers!
Hernan
Jeff Genender wrote:
Hernan,
Great article. One thing you may wish to add is discussion of the
security consequences of exposing /console. This will usually be a URL
that is not exposed to the public via a front ended httpd setup...as it
would be considered a security risk. Typically, a front ended web
server will be used for production, so this may be a good tip to add.
Perhaps in your examples you could expose one of the example
applications, or show how to expose the whole server, but offer an
example of where you can deny access to the console for security
purposes. Its just a small hint for security conscious folks.
Jeff
Hernan Cunico wrote:
Hi All,
I just updated the documentation. The following article covers how to
configure the Apache HTTPd to forward client requests to Geronimo in two
different ways, either as a reverse proxy or using the Jakarta Tomcat
Connector.
http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Remote+HTTPd+Server
Cheers!
Hernan
