Bug 754849 - as7: connections fail, as auth is now enabled by default
as7: connections fail, as auth is now enabled by default
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
Unspecified Unspecified
high Severity unspecified (vote)
: ---
: ---
Assigned To: Libor Zoubek
Mike Foley
: 708306 (view as bug list)
Depends On:
Blocks: as7-plugin
  Show dependency treegraph
Reported: 2011-11-17 16:43 EST by Heiko W. Rupp
Modified: 2015-11-01 19:42 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-01 15:19:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Heiko W. Rupp 2011-11-17 16:43:04 EST
In current versions of as7.1, the management ports are now
a) protected by the need to authenticate

            <security-realm name="ManagementRealm">
                    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
            <native-interface security-realm="ManagementRealm">
                <socket-binding native="management-native"/>
            <http-interface security-realm="ManagementRealm">
                <socket-binding http="management-http"/>

The plugin does already look for the (hardcoded) file mgmt.users.properties - but this needs now be determined from the above xml

b) the actual password is no longer in clear text, but hashed, as described in the mgmt-users.properties file

# By default the properties realm expects the entries to be in the format: -
# username=HEX( MD5( username ':' realm ':' password))

so it needs to be determined what to exactly send to the server.

workaround is to remove the security-realm attribute on the management port definitions above.
Comment 1 Heiko W. Rupp 2011-12-20 07:23:20 EST
19097edb5d591dae5ae6fdf7565b682cd5b1506c in master

the as server resource now has an operation "installRhqUser" that installs a user with password into as7 that meets the requirements of the authentication defaults.

Of course, the user can also just enable the admin user in as7 by any other means and then go to the connection properties and and give the new credentials there.
Comment 2 Libor Zoubek 2011-12-21 08:29:01 EST
verified on Version: 4.3.0-SNAPSHOT, Build Number: 74fe0df, EAP6 DR8. New Operation works as expected, plugin connects to both secured and non-secured EAP.
Comment 3 Libor Zoubek 2011-12-21 09:27:19 EST
I do not know what I did (just reinstalled server and agents, having same version), but now installRHQUser does not work anymore.

This is what I get as an operation status

java.lang.Exception: / (Is a directory)
	at org.rhq.core.pc.operation.OperationInvocation.run(OperationInvocation.java:278)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:636)
Comment 4 Libor Zoubek 2011-12-22 13:47:46 EST

exception from comment #3 is raised only when EAP is unsecured, i. e. configuration looks like: 

<socket-binding native="management-native"/>
<socket-binding http="management-http"/>

I know, when EAP is unsecured this way, we do not know which security realm should be used. I am not sure whether EAP team will produce more zips like it was before eap-XXX.zip and eap-XXX-noauth.zip. If they will, we should support both.

Or .. once we switch to DMR, there is no need to deal with credentials anymore. EAP server is able to detect whether client is local process and has read access to EAP6 home dir.
Comment 5 Heiko W. Rupp 2012-01-13 06:16:22 EST
Did you try that in domain mode?
Comment 6 Heiko W. Rupp 2012-01-25 07:18:00 EST
Please try again with the latest code base.
Comment 7 Heiko W. Rupp 2012-02-09 07:09:20 EST
*** Bug 708306 has been marked as a duplicate of this bug. ***
Comment 8 Heiko W. Rupp 2012-02-14 12:17:26 EST
Works for me,can not reproduce
Comment 9 Heiko W. Rupp 2013-09-01 15:19:36 EDT
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.

Note You need to log in before you can comment on or make changes to this bug.