Bug 1246083
| Summary: | CLI operations don't work when Native Local Authentication is enabled and Native management API host is set to 0.0.0.0 | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Filip Brychta <fbrychta> |
| Component: | Plugin -- JBoss EAP 6 | Assignee: | Thomas Segismont <tsegismo> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Filip Brychta <fbrychta> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | JON 3.3.3 | CC: | loleary, miburman, rhatlapa, spinder, theute |
| Target Milestone: | DR02 | Keywords: | Triaged |
| Target Release: | One-off release | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-06 18:56:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1314853, 1326838, 1326845, 1326846, 1326898, 1326907, 1326908, 1326910, 1326911, 1326912 | ||
|
Description
Filip Brychta
2015-07-23 12:39:10 UTC
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 |