jmx-dev JDK-8031753: JMXServiceURL should not use getLocalHost or its usage should be enhanced
Maryan Bagnyuk (aka Maryan Bahnyuk)
marbuga at gmail.com
Wed Feb 5 11:50:51 PST 2014
Dear Jaroslav
Thank you for the prompt answer.
> The only quick solution for this, IMO, would be to honor
> "com.sun.management.jmxremote.host" property to start agent on a
> specified IP. In general, the JMX code should be reevaluated and made
> more resilient to these kinds of misconfiguration. But relying on the
> implementation specific behaviour ("localhost" properly resolved even
> without an entry in /etc/hosts) is just not the way to go.
>
Ok. Let's move this way (i.e. use "com.sun.management.jmxremote.host").
As I understand "com.sun.management.jmxremote.host" can't be a mandatory
variable (otherwise agent will not start after jdk update).
And backward compatibility is also preferred/expected (i.e. everything
should work the same way before and after
"com.sun.management.jmxremote.host" usage implementation).
So am I correct assuming that the following sequence of
checks/validations is correct/suitable?
1) if "com.sun.management.jmxremote.host" is defined then goto 1.1
(otherwise goto 2)
1.1) validate it's value
1.2) if value is valid then use it and 'return' (otherwise goto 2)
2) if getLocalHost() returns a value without exception then use this
value and 'return' (otherwise goto 3)
3) if getByName("localhost") returns without exception then use it and
'return' (otherwise goto 4)
4) throw exception
Question 1: Should step 3 be leaved as-is or deprecated? (IMHO it will
make JMX more resilient but it will be more useful to ensure that you agree)
Question 2: Should 127.0.0.1 or :::1 (depending on the used protocol
version) be used instead of 4-th step or such kind of resilience (i.e.
"exception is not thrown") will make everything more complex?
Sincerely, Maryan
P.S. I also use Ubuntu (indeed Ubuntu Desktop, not Ubuntu Server) on my
PCs but I don't have a time/wish/need to support it.
If I had had to resolve the described issues (with X.org, Pulse, etc)
then I'd probably send the appropriate bug report if investigation
showed that hostname had not been needed at all.
P.P.S. I have had a practice of using Ubuntu Desktop as 'server OS' for
a small company. But in most cases my previous/present coworkers and I
use 'server OSs' without X.org, Pulse, etc.
And the used services (in most cases) ignore hostname resolving. But
it's a long story and a subject of a separate discussion.
P.P.P.S. Thanks again for moving current discussion forward. Have a nice
day.
On 02/05/2014 01:33 PM, Jaroslav Bachorik wrote:
> Hi Maryan,
>
> On 5.2.2014 08:32, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote:
>> Hello
>>
>> I'd like to note that fixing hostname requires additional development
>> (as a separate module/script/program) or support (by system
>> administrator, support staff, etc.).
>
> I've gone the length of misconfiguring my system to either use a
> hostname that can't be resolved against /etc/hosts or is resolved to a
> bogus IP. I can tell you that my system (Ubuntu) complains a lot -
> actually when I restarted networking after I used the unresolvable
> host name my X server just died on me.
>
> This, IMO, contradicts the saying that it is ok to have corrupted
> hostname related entries. It is not. Other services tend to complain a
> lot and then fall back to the loopback addres - 127.0.0.1.
>
> As for JMX - using a hostname which is resolved to a foreign IP will
> make it possible to start the management agent (there is no way to
> tell that an IP is 'mine' short of looping over all the listed network
> interfaces and checking their assigned IPs) but it is as far as you
> get. Once you try to create a JMX connection to that application you
> will see it fail - the RMI stub will use the incorrect IP and it will
> not be possible for the server and the client to talk to each other.
>
>>
>> Making the suggested (from my side) fix of JMXServiceURL.java file
>> should resolve current issue is the
>> fastest/easiest/most_clear/most_correct way (indeed IMHO).
>
> I don't think so. You can as easily mess up the /etc/hosts not to list
> "localhost" either. Even though "localhost" gets resolved to the
> loopback interface IP on a particular version of a particular OS I am
> not convinced that it is a required behavior (if you can provide some
> resources stating otherwise I'm ready to change my position).
>
> When the system is properly configured you should get virtually the
> same result for calling getLocalHost() and getByName("localhost").
>
>>
>> I am ready to prepare the needed patch and tests (for 7, 8, 9 versions
>> of jdk).
>>
>> Could you please let me know if you are ready to accept following this
>> way (replace getLocalHost by getByName) or are you not interested in
>> such approach and everyone have to fix hostname?
>
> The only quick solution for this, IMO, would be to honor
> "com.sun.management.jmxremote.host" property to start agent on a
> specified IP. In general, the JMX code should be reevaluated and made
> more resilient to these kinds of misconfiguration. But relying on the
> implementation specific behaviour ("localhost" properly resolved even
> without an entry in /etc/hosts) is just not the way to go.
>
> I have some more comments, please see further down inlined.
>
>>
>> Thanks
>>
>> P.S. Or should I send the patch and you'll make a decision after
>> reviewing it?
>>
>> On 02/04/2014 09:20 PM, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote:
>>> Hello.
>>>
>>> Do I understand correctly that my conclusions regarding "fixing the
>>> hostname is not an option" are incorrect?
>>>
>>> Or may/should it be fixed in the following way:
>>>
>>> try {
>>> - local = InetAddress.getLocalHost();
>>> + local = InetAddress.getByName("localhost");
>>> } catch (UnknownHostException e) {
>>>
>>> Sincerely, Maryan
>>>
>>> P.S. Sorry if my previous message was impolite or jokes were too plain
>>>
>>> On 01/28/2014 02:50 AM, Rob McKenna wrote:
>>>> Hi Maryan,
>>>>
>>>> I'm cc'ing the jmx-dev folks. (and bcc'ing the jdk7u-dev alias)
>>>> Hopefully they'll help move this conversation forward.
>>>>
>>>> -Rob
>>>>
>>>> On 27/01/14 20:42, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote:
>>>>> Hello
>>>>>
>>>>> As a reporter of JI-9009639 / JDK-8031753
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8031753> bug I'd like to
>>>>> inform you about the following.
>>>>>
>>>>>
>>>>> Jaroslav Bachorík
>>>>> <https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=jbachorik>added
>>>>>
>>>>> a comment -2014-01-22 04:32
>>>>> Not a regression.
>>>>>
>>>>> Oops. Sorry. Indeed I should have left this field blank.
>>>>> I'd understood the meaning of 'Regression' field incorrectly and had
>>>>> filled it in bug report by mistake. :(
>>>>>
>>>>>
>>>>> Jaroslav Bachorík
>>>>> <https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=jbachorik>added
>>>>>
>>>>> a comment -2014-01-22 04:32
>>>>> If you insist on this issue being a regression, please, provide the
>>>>> exact version where the behavior was as expected.
>>>>>
>>>>> As I see all branches have this code for ages...
>>>>>
>>>>> [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
>>>>> ./src/share/classes/javax/management/remote/JMXServiceURL.java |
>>>>> grep 'local = InetAddress.getLocalHost();'
>>>>> /home/marbug/cpp/jab/tmp/jdk6/jdk
>>>>> ohair 9 2d585507a41b Fri Jan 30 16:27:33 2009 -0800
>>>>> src/share/classes/javax/management/remote/JMXServiceURL.java: local
>>>>> = InetAddress.getLocalHost();
>>>>> [marbug at server1 jdk]$ pwd && hg annotate -r 0 -f -a -u -d -n -c
>>>>> ./src/share/classes/javax/management/remote/JMXServiceURL.java |
>>>>> grep 'local = InetAddress.getLocalHost();'
>>>>> /home/marbug/cpp/jab/tmp/jdk6/jdk
>>>>> duke 0 0c738a3e5791 Fri Jan 30 16:00:53 2009 -0800
>>>>> src/share/classes/javax/management/remote/JMXServiceURL.java: local
>>>>> = InetAddress.getLocalHost();
>>>>> [marbug at server1 jdk]$ cd ../../jdk7u/jdk/
>>>>> [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
>>>>> ./src/share/classes/javax/management/remote/JMXServiceURL.java |
>>>>> grep 'local = InetAddress.getLocalHost();'
>>>>> /home/marbug/cpp/jab/tmp/jdk7u/jdk
>>>>> duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000
>>>>> src/share/classes/javax/management/remote/JMXServiceURL.java: local
>>>>> = InetAddress.getLocalHost();
>>>>> [marbug at server1 jdk]$ cd ../../jdk8/jdk/
>>>>> [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
>>>>> ./src/share/classes/javax/management/remote/JMXServiceURL.java |
>>>>> grep 'local = InetAddress.getLocalHost();'
>>>>> /home/marbug/cpp/jab/tmp/jdk8/jdk
>>>>> duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000
>>>>> src/share/classes/javax/management/remote/JMXServiceURL.java: local
>>>>> = InetAddress.getLocalHost();
>>>>> [marbug at server1 jdk]$ cd ../../jdk9/jdk/
>>>>> [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
>>>>> ./src/share/classes/javax/management/remote/JMXServiceURL.java |
>>>>> grep 'local = InetAddress.getLocalHost();'
>>>>> /home/marbug/cpp/jab/tmp/jdk9/jdk
>>>>> duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000
>>>>> src/share/classes/javax/management/remote/JMXServiceURL.java: local
>>>>> = InetAddress.getLocalHost();
>>>>>
>>>>> So the expected behaviour is just my conslusion/suggestion.
>>>>>
>>>>>
>>>>> Jaroslav Bachorík
>>>>> <https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=jbachorik>added
>>>>>
>>>>> a comment -2014-01-22 04:32
>>>>> I would argue that workaround should be L - it is easy to fix the
>>>>> hostname and the solution is persistent. If the reporter can
>>>>> describe a situation where fixing the hostname is not an option the
>>>>> workaround should stay at M.
>>>>>
>>>>> As I understand you suggest to fix hostname and/or an appropriate
>>>>> record in /etc/hosts (under Linux).
>>>>> Everyone suggest this in 'google search'... :( But IMHO it's not an
>>>>> option because:
>>>>>
>>>>> 1) As far as I know no one must have root access to run programs
>>>>> with JMX agent.
>>>>> 1.1) With this suggestion everyone must have root access (because
>>>>> only root or sudo-ed user may change hostname and/or /etc/hosts)
>>>>> 1.1.1) What if someone do not have root access to his PC (some
>>>>> companies do not allow to install additional software without their
>>>>> permissions)?
>>>>> 1.1.2) Will you add the appropriate note to the 'Install' section in
>>>>> Java manual/documentation? Or should everyone just google this
>>>>> exception to find the fix of this issue? :)
>
> I would say that configuring /etc/hostname and /etc/hosts consistently
> should be required. Not everybody needs to have root access - the
> sysadmin should take care of it once and for all. This is all just
> working around an improperly configured system.
>
>>>>>
>>>>> 2) Indeed Agent does not use hostname or it's IP to run JMX server
>>>>> (please take a look at my original post)
>>>>> 2.1) If Agent does not use it (i.e. hostname/IP) then why should it
>>>>> depend on it?
>
> Because it gets imprinted into the RMI stubs used. The agents will use
> this address to connect back to the agent once the RMI connection is
> established. This is how RMI works.
>
>>>>>
>>>>> 3) Why should I change hostname if other services work correctly
>>>>> without it?
>>>>> 3.1) OS ignores that hostname can't be resolved to some IP and is
>>>>> started successfully
>>>>> 3.2) Apache does so too (because it listens on 0.0.0.0 in IPv4)
>>>>> 3.3) SSH server as well ...
>>>>> 3.4) etc., etc., etc.
>>>>> 3.5) but java throws an exception
>>>>> IMHO this does not follow the 'general' scheme ;)
>
> No, they don't. As I mentioned earlier, they usually complain a lot
> (X.org, Pulse ...) or plainly die. At the end (eg. after a restart)
> they decide they would fall back to loopback instead. I wouldn't call
> this a 'general' scheme.
>
>>>>>
>>>>> 4) How about JMX client (i.e. "Connecting to the JMX Agent
>>>>> Programmatically ")?
>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdevg
>>>>>
>>>>>
>>>>> STR:
>>>>> 4.1) server1 is behind NAT (example 1: on my VM, example 2: in
>>>>> Amazon Cloud)
>>>>> 4.2) port mapping is configured from external IP to the local one
>>>>> (i.e. there is only local network IP on interface)
>>>>> 4.3) I have associated my hostname (for instance,
>>>>> server1.customer22.example.com) with 127.0.0.1 ( Is it a good idea
>>>>> to do this in Amazon Cloud? IMHO no. ;) )
>>>>> 4.4) I start a program (Cassandra, Program4STR, etc.) via Agent
>>>>> 4.5) if someone will change a record for
>>>>> server1.customer22.example.com to the correct external IP then why
>>>>> should agent connect to external IP instead of local one? :)
>>>>> 4.5.1) if I run client on server1 then it's enough to connect to
>>>>> localhost instead of external IP. Isn't it?
>>>>> 4.5.2) if I start client on another PC then in any case I'll pass
>>>>> the needed value in 'host' parameter to JMXServiceURL(...)
>
> ... and when the host you use on the client doesn't match with the
> host used on the server you won't be able to connect. RMI again.
>
>>>>>
>>>>> 5) etc., etc., etc. (see examples from my original post and imagine
>>>>> how client will connect to JMX server in each case)
>>>>>
>>>>>
>>>>> Indeed the decision is 'up to you' but IMHO making the suggested
>>>>> change will simplify everything, save time of many people (they will
>>>>> not need to change hostname and/or /etc/hosts), google will
>>>>> deprecate search of ' Error: Exception thrown by the agent :
>>>>> java.net.MalformedURLException: Local host name unknown:' string and
>>>>> at least several developers and system administrators will be happy
>>>>> not to take care about hostname ... At least for Java and programs
>>>>> which use Agent ;)
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>
>>
>
> -JB-
>
--
Sincerely,
Maryan Bagnyuk (aka Maryan Bahnyuk)
More information about the jmx-dev
mailing list