Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Date: Mon, 7 May 2001 17:06:28 -0400
From: Andrey Kartashov <andrey.kartashov@sonatainc.com>
To: tomcat-dev@jakarta.apache.org
Subject: Re: Tomcat 3.2.2 beta 4 (insecure default settings)
Message-ID: <20010507170628.A11076@linux.thethinkingmedia.com>
References: <361024C34A6DD2118689006097AE2B4D0102CE14@css4.cs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <361024C34A6DD2118689006097AE2B4D0102CE14@css4.cs>;
 from hgomez@slib.fr on Mon, May 07, 2001 at 02:11:35PM +0200

On Mon, May 07, 2001 at 02:11:35PM +0200, GOMEZ Henri wrote:
> You're right. TC still use ajp12 at its default connector so it
> listen all interface (which I agree could rise problem). I'm
> using in my prod systems, ajp13 to connect webservers and
> ajp12 only for the shutdown purpose (and listen only on localhost)
> 
> >Here is the same test but with slightly modified server.xml:
> ><Connector className="org.apache.tomcat.service.PoolTcpConnector">
> >	<Parameter name="handler"
> value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
> >	<Parameter name="port" value="8007"/>
> >	<Parameter name="inet" value="127.0.0.1"/>
> ></Connector>
> 
> Thanks to mention this one. The "inet" is not a well know and used param.
> 
> >Please note that port 8007 is bound to 127.0.0.1 interface _ONLY_.
> 
> The secure way.

Should it become default? I hope the answer is yes:)

It also has another value: "inet" is not a well-known
parameter. Having it in default server.xml along with a little comment about
what it does may compensate for the lack of proper documentation:)


> I understand your valid requirement, but why not just developp a 
> servlet in admin which use ajp12 to send (to localhost), the ajp12
> shutdown command.
> 
> >Hope this helps :)
> 
> Yes, and I hope you'll take a look at the ajp14 proposal.......
I did.
I don't really understand why Ajp protocol should handle shutdown command
at all. I agree that there may be a need for some kind of servlet that 
handles this operation but WHY THROUGH Ajp protocol???
It almost sounds like merging two things that serve totally different purpose
together. What if you want to add more commands in the future? Would you 
really want to add these commands into ALL versions of protocol? And how do
you handle these commands if you don't?

IMHO there are few related but different things one wants to do with TC:
1)Serve requests - handled by Ajp protocol.
2)Configure&administrate - this one is a bit more complex.

	Some people (including myself) like doing configuration manually in
	command line interface. Hence there needs to be well defined set of config
	files and scripts one needs to care about. One of my personal challenges
	while setting up TC for the first time was to find out what config files
	are actually necessary. There is whole bunch of files in config directory
	for ALL the possible platforms/servers, etc. 

	Some people would prefer to use some UI tool to configure the server and
	issue commands - here is your idea of extending functionality of "admin"
	application, add shutdown/restart commands to it as well as may be some 
	other options like configuring "connectors", including configuration of 
	ports, interfaces,  etc. There may even be some applet for monitoring
	the log files (like in Sun's JavaWebServer).
	I think good example is configuration as it is done in "Enhydra".
	This kind of tool doesn't need any "middle man" in the form of Ajp or any
	other protocol. It can have hooks directly into server API. The advantage
	of this is that Ajp protocols remain "plugguble" unlike Ajp12 that you
	"need to have" to issue simple "shutdown" command and configuration
	may evolve without any weird dependencies on any particular protocol.

	Some people MIGHT want to set up distributed environment (read load
	balancing here) where the same application is physically distributed 
	across multiple machines but configuration MUST be changed synchronously.
	This may be handled just by some *NIX scripts, etc but in this case 
	having some "administration" protocol might be usable to build "centralized"
	configuration where all the changes are made in one place and communicated
	to all the balanced servers using some protocol. There are lots of 
	complicated issues here but this is the place where IMHO some protocol
	might be NECESSERY. And even than I wouldn't add this features into 
	any Ajp?? protocols. I'd much rather define another one that again may
	evolve differently from Ajp protocols but might use Ajp protocol as a
	transport layer.


Here is the list of modifications that I've done to TC so far:
1) changed defaults to bind to 127.0.0.1 interface in server.xml.
2) changed shutdown code to make it work correctly if "inet" parameter is 
   used.
3) modified mod_jk logger function to print timestamps in Apache Web server
   style.
4) modified tomcat.sh file in "bin" to redirect stdout&stderr to a log file
   (people complained about not seeing System.out.println() stuff)
5) modified default load balancing behavior to make use of wireless device's 
   "global id" (I'm not giving details on this one because it's specific to 
   what we are doing and probably useless for others. But I'm not hiding it:)
   I can describe it if anyone is interested).

Sorry for the long E-Mail:) Hope you've read it:)

-- 
oo Andrey
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less."
           -- http://www.mutt.org/  Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo