RE: tomcat 4.0 remote shutdown question ...

[HAVENS,PETER (HP-Cupertino,ex3)]

Wow!  What a quick response.  Thank you for your information.

-Peter

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, July 27, 2002 3:41 PM
To: Tomcat Developers List
Subject: Re: tomcat 4.0 remote shutdown question ...



On Sat, 27 Jul 2002, HAVENS,PETER (HP-Cupertino,ex3) wrote:

> Date: Sat, 27 Jul 2002 18:35:23 -0400
> From: "HAVENS,PETER (HP-Cupertino,ex3)" <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: tomcat 4.0 remote shutdown question ...
>
> I have found that I cannot connect to the tomcat shutdown port remotely.
> Using code highly leveraged from the tomcat source, I wrote a simple java
> app to issue the shutdown command to a given server and port #.  It only
> seems to work if I use "localhost" as the server name.  If I try to use
the
> hostname or the fully qualified host name (even of the local system) it
will
> fail.  I have tried using this to stop Tomcat on linux and Windows XP with
> the same results.  I have included the output I get when I run it and the
> source code.  Any help understanding this would be greatly appreciated.
>

Tomcat deliberately accepts connections to the shutdown port only from
localhost as a security precaution.  After all, you really don't want
anyone on the Internet to be able to shut down your Tomcat instance.

To change this behavior, you'd need to change the Tomcat source code for
the logic that opens the shutdown port's socket.  It's not configurable.

Craig


> -Sample output
> Attempting to shut down the tomcat server on ovwpc574/15.27.245.212 using
> port 8085
>
> tomcat_stop: java.net.ConnectException: Connection refused
> java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:295)
> at
> java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:161)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:148)
> at java.net.Socket.connect(Socket.java:425)
> at java.net.Socket.connect(Socket.java:375)
> at java.net.Socket.(Socket.java:290)
> at java.net.Socket.(Socket.java:146)
> at tomcat_stop.main(tomcat_stop.java:40)
> -End of Sample
> output
>
> -Source Code
> import java.io.*;
> import java.io.IOException;
> import java.net.Socket;
> import java.net.InetAddress;
>
>
> class tomcat_stop
> {
>
> public static void main( String [] args )
> {
> int port_number;
> InetAddress server_address=null;
> Socket socket;
>
> if (args.length != 2)
> usage();
>
> port_number = Integer.parseInt(args[1]);
>
> try
> {
> server_address =
> InetAddress.getByName(args[0]);
> }
> catch (IOException e)
> {
> System.out.println("");
> System.out.println("Unable to get
> InetAddress using getByName on " +
> args[0]);
> System.out.println(":tomcat_stop " +
e);
> e.printStackTrace(System.out);
> System.exit(1);
> }
>
> // Stop the existing server
> try {
> System.out.println("\n\nAttempting to
> shut down the tomcat server on " +
> server_address + " using
> port " + port_number + "\n\n");
>
> socket = new Socket(server_address,
> port_number);
> OutputStream stream =
> socket.getOutputStream();
> String shutdown = "SHUTDOWN";
> for (int i = 0; i < shutdown.length();
> i++)
>
> stream.write(shutdown.charAt(i));
> stream.flush();
> stream.close();
> socket.close();
> }
> catch (IOException e)
> {
> System.out.println("tomcat_stop: " +
e);
> e.printStackTrace(System.out);
> System.exit(1);
>  

Re: tomcat 4.0 remote shutdown question ...

[Craig R. McClanahan]

On Sat, 27 Jul 2002, HAVENS,PETER (HP-Cupertino,ex3) wrote:

> Date: Sat, 27 Jul 2002 18:35:23 -0400
> From: "HAVENS,PETER (HP-Cupertino,ex3)" <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: tomcat 4.0 remote shutdown question ...
>
> I have found that I cannot connect to the tomcat shutdown port remotely.
> Using code highly leveraged from the tomcat source, I wrote a simple java
> app to issue the shutdown command to a given server and port #.  It only
> seems to work if I use "localhost" as the server name.  If I try to use the
> hostname or the fully qualified host name (even of the local system) it will
> fail.  I have tried using this to stop Tomcat on linux and Windows XP with
> the same results.  I have included the output I get when I run it and the
> source code.  Any help understanding this would be greatly appreciated.
>

Tomcat deliberately accepts connections to the shutdown port only from
localhost as a security precaution.  After all, you really don't want
anyone on the Internet to be able to shut down your Tomcat instance.

To change this behavior, you'd need to change the Tomcat source code for
the logic that opens the shutdown port's socket.  It's not configurable.

Craig


> -Sample output
> Attempting to shut down the tomcat server on ovwpc574/15.27.245.212 using
> port 8085
>
> tomcat_stop: java.net.ConnectException: Connection refused
> java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:295)
> at
> java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:161)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:148)
> at java.net.Socket.connect(Socket.java:425)
> at java.net.Socket.connect(Socket.java:375)
> at java.net.Socket.(Socket.java:290)
> at java.net.Socket.(Socket.java:146)
> at tomcat_stop.main(tomcat_stop.java:40)
> -End of Sample
> output
>
> -Source Code
> import java.io.*;
> import java.io.IOException;
> import java.net.Socket;
> import java.net.InetAddress;
>
>
> class tomcat_stop
> {
>
> public static void main( String [] args )
> {
> int port_number;
> InetAddress server_address=null;
> Socket socket;
>
> if (args.length != 2)
> usage();
>
> port_number = Integer.parseInt(args[1]);
>
> try
> {
> server_address =
> InetAddress.getByName(args[0]);
> }
> catch (IOException e)
> {
> System.out.println("");
> System.out.println("Unable to get
> InetAddress using getByName on " +
> args[0]);
> System.out.println(":tomcat_stop " + e);
> e.printStackTrace(System.out);
> System.exit(1);
> }
>
> // Stop the existing server
> try {
> System.out.println("\n\nAttempting to
> shut down the tomcat server on " +
> server_address + " using
> port " + port_number + "\n\n");
>
> socket = new Socket(server_address,
> port_number);
> OutputStream stream =
> socket.getOutputStream();
> String shutdown = "SHUTDOWN";
> for (int i = 0; i < shutdown.length();
> i++)
>
> stream.write(shutdown.charAt(i));
> stream.flush();
> stream.close();
> socket.close();
> }
> catch (IOException e)
> {
> System.out.println("tomcat_stop: " + e);
> e.printStackTrace(System.out);
> System.exit(1);
> }
> }
>
> public static void usage()
> {
> System.out.println("\nUsage:\n\ttomcat_stop  name> \n\n");
> System.exit(1);
> }
> }
>
>
>


--
To unsubscribe, e-mail:   

tomcat 4.0 remote shutdown question ...

[HAVENS,PETER (HP-Cupertino,ex3)]

I have found that I cannot connect to the tomcat shutdown port remotely.
Using code highly leveraged from the tomcat source, I wrote a simple java
app to issue the shutdown command to a given server and port #.  It only
seems to work if I use "localhost" as the server name.  If I try to use the
hostname or the fully qualified host name (even of the local system) it will
fail.  I have tried using this to stop Tomcat on linux and Windows XP with
the same results.  I have included the output I get when I run it and the
source code.  Any help understanding this would be greatly appreciated.
 
-Sample output
Attempting to shut down the tomcat server on ovwpc574/15.27.245.212 using
port 8085
 
tomcat_stop: java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:295)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:161)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:148)
at java.net.Socket.connect(Socket.java:425)
at java.net.Socket.connect(Socket.java:375)
at java.net.Socket.(Socket.java:290)
at java.net.Socket.(Socket.java:146)
at tomcat_stop.main(tomcat_stop.java:40)
-End of Sample
output
 
-Source Code
import java.io.*;
import java.io.IOException;
import java.net.Socket;
import java.net.InetAddress;
 
 
class tomcat_stop
{
 
public static void main( String [] args ) 
{
int port_number;
InetAddress server_address=null;
Socket socket;
 
if (args.length != 2)
usage();

port_number = Integer.parseInt(args[1]);
 
try
{
server_address =
InetAddress.getByName(args[0]);
}
catch (IOException e)
{
System.out.println("");
System.out.println("Unable to get
InetAddress using getByName on " + 
args[0]);
System.out.println(":tomcat_stop " + e);
e.printStackTrace(System.out);
System.exit(1);  
}
 
// Stop the existing server
try {
System.out.println("\n\nAttempting to
shut down the tomcat server on " + 
server_address + " using
port " + port_number + "\n\n");
 
socket = new Socket(server_address,
port_number);
OutputStream stream =
socket.getOutputStream();
String shutdown = "SHUTDOWN";
for (int i = 0; i < shutdown.length();
i++)
 
stream.write(shutdown.charAt(i));
stream.flush();
stream.close();
socket.close();
}
catch (IOException e)
{
System.out.println("tomcat_stop: " + e);
e.printStackTrace(System.out);
System.exit(1);
}
}
 
public static void usage()
{
System.out.println("\nUsage:\n\ttomcat_stop  \n\n");
System.exit(1);
}
}
 
 

Re: IIS ISAPI / TOMCAT 4.0.2 Problem on Win XP

[George Hester]

I succeeded. Windows 2000 SP2 and Tomcat 4.0.1.  But this is not a true
Application Mapping.  If it were it would appear in IIS Manager | Default Web |
Properties | Home Directory | Configuration... | Application Mappings.  It
doesn't.  It appears and is used as an ISAPI.  This is not the same thing.  Also
it redirects folder requests not file type requests.

Consider the difference of how Application Mappings are used by Perl, Python,
PHP with Tomcat's redirector to see the difference.

We need something conmparable AND as unobtrusive to files that IIS can handle
but I have yet to find it.

--
George Hester
_
"Landanger Pierre-Yves" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi all,
>
> I try to link IIS and Tomcat.
>
> It work properly with  Win 2k SP2, TOMCAT 3.
> But after hours of test, noway to make it work with WinXP, neither TOMCAT 3
> & 4
>
> Mapping is working, Workers 12&13 are listening, and no log error...
>
> "[Fri Jul 26 15:24:57 2002]  [jk_uri_worker_map.c (464)]: Attempting to map
> URI '/examples/jsp/dates/date.jsp'
> [Fri Jul 26 15:24:57 2002]  [jk_uri_worker_map.c (529)]:
> jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match ajp13 -> *.jsp
> [Fri Jul 26 15:24:57 2002]  [jk_uri_worker_map.c (529)]:
> jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match ajp13 -> *.jsp
> [Fri Jul 26 15:24:57 2002]  [jk_isapi_plugin.c (721)]: HttpFilterProc
> [/examples/jsp/dates/date.jsp] is a servlet url - should redirect to ajp13
> [Fri Jul 26 15:24:57 2002]  [jk_isapi_plugin.c (784)]: HttpFilterProc check
> if [/examples/jsp/dates/date.jsp] is points to the web-inf directory"
>
> Did anyone already succeed ?
> Thks
>
> Landanger Pierre-Yves





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH]: format of code generated for useBean action

[George Hester]

Can you explain how where to install it?  I am new to this and so what may seem
obvious to you is not to me but I'm hoping after a little expereince using this
newsgroup I will be able to answer questions such as this.  Thanks.

--
George Hester
_
"Doug Kearns" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hello all,
>
> This mini-patch provides a minor improvement to the formatting of the
> code generated for the useBean action.
>
> Whilst hardly earth shattering, it has been bugging me :-)
>
> Patch against Tomcat 4.0.4.
>
> Regards,
> Doug
>





> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Patch for security problem

[John Holman]

Bug 11210 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210) is a 
security problem which could have serious effects for people using 
JNDIRealm with the Netscape/iPlanet JNDI LDAP provider 
 (com.netscape.jndi.ldap.LdapContextFactory). The default provider 
(com.sun.jndi.ldap.LdapCtxFactory) works OK.

I believe the problem is due to a failure of the Netscape/iPlanet 
provider to conform to the JNDI 1.2 specification - see the bugzilla 
report for details. However, getting that fixed is likely to take a 
while. The bug report includes a patch to JNDIRealm which avoids the 
problem. Could someone please have a look at it and hopefully commit it? 
(Remy has been committing my JNDIRealm patches but now that he's on 
holiday/has left Sun I'm not sure how things stand).

Thanks, John



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11210] - JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210

JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server





--- Additional Comments From [EMAIL PROTECTED]  2002-07-27 15:08 ---
I downloaded the iPlanet/Netscape/Mozilla Directory SDK 4.1 from Sun and
replicated the problem, which is due to a failure of this LDAP provider
(com.netscape.jndi.ldap.LdapContextFactory) to conform to the JNDI specification.

Section 6.6.2 of the JNDI 1.2 spec on the timeliness of modifications to the
context environment says that changes to an environment property should be
effective the next time an operation using that property is envoked. JNDIRealm
relies on this to authenticate by binding as the user - it changes the principal
and password properties and then carries out a search operation with the new
environment. This all works as expected when using the default LDAP provider
from Sun.

The iPlanet implementation, on the other hand, seems to ignore any change to
environment properties when the changed property pertains to the connection.
(This discrepancy is hinted at in the section on JNDI Environmental Properties
in the Netscape documentation). Thus it never even attempts to rebind as the user.

This should really be fixed by whoever is now maintaining the Netscape provider,
but I have a feeling that may not be trivial. So I've just attached a patch to
JNDIRealm to work around the problem. This invokes reconnect() on the context to
force an immediate rebind both when switching from administrator to user
credentials for authentication and when switching from user to administrator
credentials to search for user entries and role information. 

One, perhaps slight, downside is that the context must now be an LdapContext
instead of the more generic DirectoryContext. On the other hand the realm is
slightly more efficient than before when using the Sun LDAP provider. With the
Netscape provider, it works correctly, but is rather inefficient since this
provider closes the LDAP connection and creates a new one when reconnect() is
invoked instead of keeping the same connection and rebinding with the new
credentials.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11210] - JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210

JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server





--- Additional Comments From [EMAIL PROTECTED]  2002-07-27 15:07 ---
Created an attachment (id=2506)
JNDIRealm patch to support  iPlanet/Netscape LDAP provider

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11210] - JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210

JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server





--- Additional Comments From [EMAIL PROTECTED]  2002-07-27 10:43 ---
I suspect this is an issue with using the Netscape LDAP provider
(com.netscape.jndi.ldap.LdapContextFactory) rather than with the type of
directory server. Could you try again using the Sun provider? Also detailed logs
from the iPlanet directory server for both providers would help.

I'll try to get hold of the Netscape provider and see if I can replicate against
OpenLDAP.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[GUMP] Build Failure - jakarta-tomcat-4.0

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

deploy-prepare:

deploy-static:

deploy:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo]