Description of problem: When the 'Native Host' property in Inventory->Connection Settings is set to 0.0.0.0 which is auto-discovered this way when you have EAP management ports bind to 0.0.0.0 and Native Local Authentication is enabled then the CLI operations don't work. Version-Release number of selected component (if applicable): JON3.3.3 with jon33-eap-update01 How reproducible: Always Steps to Reproduce: 1. start your EAP with management ports bind to 0.0.0.0 2. discover it and import it 3. go to Inventory->Connection Settings and enable Native Local Authentication 4. go to Operations and schedule Execute CLI commands operation Actual results: It fails: Authenticating against security realm: ManagementRealm Username: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:299) at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:265) at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.modules.Module.run(Module.java:312) at org.jboss.modules.Main.main(Main.java:473) Caused by: org.jboss.as.cli.CommandLineException: Unable to authenticate against controller at 0.0.0.0:10099 at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1044) at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:887) at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:863) at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:297) ... 8 more Caused by: javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChan Expected results: 'Native Host' property should not contain 0.0.0.0 but real IP of the host. Auto-discovery process should take care of this. Additional info: With 'Native Host' property set to real IP the CLI operation works.
I think it is not possible to fulfill expected results. if EAP is configured to listen on 0.0.0.0 plugin should not discover anything but that value. Maybe we should try to be smart and in case we discover 0.0.0.0 we replace it with 127.0.0.1 or some random network interface IP. I am not sure, if *every os have to have* local interface 127.0.0.1. If we chose random IP from server's interfaces at discovery time (and this IP later changes once server recieves another IP) we fail to talk to EAP. So the only way to fix this is to "discover" 127.0.0.1 in case we in fact discovered 0.0.0.0. Maybe a better fix could be done in operation code, which could catch above situation (0.0.0.0 + enabled Native Local Authentication) and fail the operation and explain, that you cannot be authenticated using local method if you talk to server using 0.0.0.0 - because the stack trace does not tell it clearly. And .. I think binding management interface to 0.0.0.0 is not common case in production systems.
I suggest we update the discovery process to use 'localhost' instead of '0.0.0.0' when management is bound to all interfaces. The agent would log a message at INFO level in that case. The operation implementation would also check that the 'Native Host' property is a valid remote host. Fine with you Larry?
Essentially, yes. But use 127.0.0.1 instead of "localhost" when the address is discovered as 0.0.0.0. This will ensure we are using loopback rather then being routed to an undesired address if localhost is set to something unexpected. The only drawback to this method is that if loopback is not installed or is not using the standard 127.0.0.1 address. We will call that an edge case and simply not support it.
Pull request sent https://github.com/rhq-project/rhq/pull/219 Removed nativeHost and nativePort settings from EAP7 servers config, as the CLI now connects to the HTTP management port. Updated discovery classes so that when '0.0.0.0' is discovered, '127.0.0.1' is used Updated component classes to log a warning if native/management host is set to '0.0.0.0' Changed defaults from 'localhost' to '127.0.0.1' in HostConfiguration classes to avoid troubles when localhost is configured to something else than loopback address Note that, with these changes, new servers bound to '0.0.0.0' will no longer have this address in the resource name, but '127.0.0.1' instead. Resource keys are not impacted. Already inventoried EAP6 resources are left untouched.
(In reply to Thomas Segismont from comment #5) > Pull request sent https://github.com/rhq-project/rhq/pull/219 This pull request has been close and I will create a new one, with the fix for EAP6 plugin. EAP7 plugin concerns are already tracked by Bug 1311094
New pull request sent https://github.com/rhq-project/rhq/pull/224
There is one test scenario which is now failing because of this change. 1 - eap is started with -bmanagement=0.0.0.0 2 - it's discovered and imported 3 - expected name is EAP (0.0.0.0:10090) After this commit the resource name is displayed as EAP (127.0.0.1:10090) I believe it's taken from hostname property in plugin config. So question is if this change is fine or the change should only apply to 'Native Host' property (to fix this bz) and 'Hostname' should follow original logic (keep there 0.0.0.0)
(In reply to Filip Brychta from comment #11) > So question is if this change is fine or the change should only apply to > 'Native Host' property (to fix this bz) and 'Hostname' should follow > original logic (keep there 0.0.0.0) To me, 'hostname' should be set to 127.0.0.1 just as 'nativeHost', because 0.0.0.0 is not a valid remote IP. But we can keep 0.0.0.0 in the resource name if it is preferred. In that case, we should probably do the same for EAP7 plugin.
I agree with Thomas. Set hostname to 127.0.0.1 but keep the name with 0.0.0.0.
Pull request sent https://github.com/rhq-project/rhq/pull/226
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions