Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 25 Apr 2008 15:34:59 +0200
From: John Embretsen <John.Embretsen@Sun.COM>
Subject: Re: Problem with MBean user/ password example on Wiki page (non-JRMP
 server at remote endpoint)
In-reply-to: <4810AE27.4090105@Sun.COM>
Sender: John.Embretsen@Sun.COM
To: derby-dev@db.apache.org
Reply-to: derby-dev@db.apache.org
Message-id: <4811DE03.8030504@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <480F707D.9040807@sbcglobal.net> <480F9257.4090105@sun.com>
 <480FB674.7030204@sbcglobal.net> <4810AE27.4090105@Sun.COM>
User-Agent: Thunderbird 2.0.0.12 (X11/20080228)

John Embretsen wrote:
> Kathey Marsden wrote:
>> John H. Embretsen wrote:
>>> Hmm, I don't see anything obviously wrong. If it works with JConsole
>>> and the exact same server configuration, it is certainly strange.
>>> Perhaps some of the troubleshooting tips (JMX logging, security debug
>>> traces) described on the wiki might reveal more hints? If you're using
>>> e.g. IBM's JVM that may have something to do with it as well.
>>>
>> For this part I am testing with the Sun JDK 1.6 just to remove that as a
>> variable.  Turning on logging, and running without security manager
>> seemed to have no effect.  I think I'll leave it alone for a while and
>> come back to it as I am pretty stuck.
> 
> For what it's worth, I am able to reproduce it using your command lines. So far
> it seems like it has to do with how the server is started/configured, and not
> the client. The strange thing is I have a script with (seemingly) the same
> options, only in slightly different order and using different classpath etc,
> which works with your client code. I'll try to take a closer look tomorrow.

OK, I have found the issue and corrected the wiki (I apologize for luring you
into this kind of trouble, Kathey). It turns out that the SSL protection of the
RMI registry (com.sun.management.jmxremote.registry.ssl=true) on the server side
requires the JMX client to explicitly specify an RMI client socket factory which
supports SSL, e.g. like this:

env.put("com.sun.jndi.rmi.factory.socket", new SslRMIClientSocketFactory());

Apparently, JConsole does this automatically or something, but I don't have the
details on that.

There was a bug in the script I used for testing this particular scenario, which
resulted in my using a different JVM version than I thought I was using. With
(JVM) 1.5 that specific property is not supported, and it is apparently just
ignored - hence no changes are required on the client side. With JDK 6 it is
another deal, as you have noticed. Not sure if JVMs from other vendors behave
the same way or even support this kind of SSL protection out of the box.

I wasn't able to find much information about this in official documentation, but
these blog entries lead me to a solution:

http://blogs.sun.com/lmalventosa/entry/secure_management_agent
http://blogs.sun.com/lmalventosa/entry/using_the_ssl_tls_based1

Again, thanks for trying out this stuff!


-- 
John