Bug 1018213 - rhqctl install puts hard-coded absolute paths into configuration and property files
rhqctl install puts hard-coded absolute paths into configuration and property...
Product: JBoss Operations Network
Classification: JBoss
Component: Installer, Launch Scripts (Show other bugs)
JON 3.2
Unspecified Unspecified
urgent Severity urgent
: ER07
: JON 3.2.0
Assigned To: Stefan Negrea
Mike Foley
: Documentation
Depends On:
Blocks: 1012435 1027133
  Show dependency treegraph
Reported: 2013-10-11 09:23 EDT by Larry O'Leary
Modified: 2014-01-02 15:33 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-02 15:33:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
windows_jonpath.log (6.34 KB, text/x-log)
2013-12-03 09:47 EST, Armine Hovsepyan
no flags Details
windows_service-jon3 (97.21 KB, image/png)
2013-12-03 09:47 EST, Armine Hovsepyan
no flags Details
windows_service-jon4 (97.47 KB, image/png)
2013-12-03 09:47 EST, Armine Hovsepyan
no flags Details
linux_jonpath.log (241.63 KB, text/x-log)
2013-12-03 10:24 EST, Armine Hovsepyan
no flags Details

  None (edit)
Description Larry O'Leary 2013-10-11 09:23:01 EDT
Description of problem:
After executing rhqctl install the resulting installation becomes unusable in a shared or networked environment when application bootstrapping or templates are used.

This is because the file system paths becomes absolute and are hard-coded into the actual configuration and property files.

This is inconsistent to JBoss product layouts and will prevent users from building out their base installation template (provisioning) a JBoss ON server due to the hard-coded file-system paths. The expectation is that paths should be relative to JON_HOME or RHQ_SERVER_HOME or RHQ_AGENT_HOME using environment variables and/or JVM system properties. 

This issue appears to affect the following files:


Version-Release number of selected component (if applicable):
JBoss ON 3.2.0.ER3 - Build: c0742ed:cbad264

How reproducible:

Steps to Reproduce:
1. Prepare database for JON installation.
2. Extract JON server archive to test location such as /tmp/jon.
3. Set jboss.bind.address in rhq-server.properties
4. Execute rhqctl install
5. Once install completes, relocate the base directory /tmp/jon to /tmp/jon-new.
6. Execute rhqctl start

Actual results:
Storage node and agent will not get started.

Expected results:
Storage node and agent should be running.
Comment 1 John Mazzitelli 2013-10-11 09:51:57 EDT
> 5. Once install completes, relocate the base directory /tmp/jon to /tmp/jon-new.

I can say it was never in the design or expectation that we support the usecase that once you install JON, that you can then move that JON installation to a new location.
Comment 2 Larry O'Leary 2013-10-11 10:05:42 EDT
It may not have been intentional but the fact that we supported the externalization of RHQ_SERVER_HOME and RHQ_AGENT_HOME as configurable environment variables and still provide these in the environment scripts would lead me to believe that perhaps this was the intended design.

In either case, this is what customers are doing today and is what JBoss supports.
Comment 4 Simeon Pinder 2013-10-24 00:16:29 EDT
Moving to ER05 as missed the cutoff for ER04.
Comment 8 Mike Foley 2013-11-04 17:27:02 EST
flagging this as high risk.  if this is implemented, recommending a full round of installation testing ... all platforms ... windows, RHEL, Solaris ... as well as more testing around testcases as yet to be defined ... 

Possible testcases:
1) network drive letter changes on windows
2) mount point changes on Linux
3) moving storage node to a new directory and changing environmental variables
4) some puppet specific zip and unzip thing ?
5) requalification of windows, solaris, and RHEL
6) other??? 

when the GUI install was removed ... the install has been changing and changing and changing ... and there haven't been requirements or testcase development around "install".  

recommendation:  this would need to go thru the "virtuous QE cycle", as follows:

1) developer demo ... including a discussion and brainstorm of testcases.  gss to be present at this demo and provide input into the testcases
2) structured TCMS testcase development on what the testcases are here
3) TCMS testcase execution ... on windows, solaris, and RHEL

possible GA slip on this ...
Comment 9 Mike Foley 2013-11-04 17:45:15 EST
For QE:

Primary testcase:

Install JBoss ON in /opt/jboss/jon
Rename /opt/jboss/jon to /opt/jboss/jboss-on
Restart JON, should fail.
Rename environmental variables, should work.

Do same/similar on Windows.
Comment 10 Mike Foley 2013-11-04 17:45:59 EST
adding DOCUMENTATION keyword, and doc person ... to review JON documentation in this area.
Comment 14 John Mazzitelli 2013-11-06 10:45:21 EST
This is why standalone-full.xml has absolute paths for the key/truststores:

        // https://issues.jboss.org/browse/WFLY-1177 - we need to resolve the paths right now. the user won't be able
        // to change these again in the future unless they go directly into standalone.xml and change it manually
        String truststoreFileString = connector.getSslConfiguration().getCaCertificateFile();
        truststoreFileString = resolveExpression(mcc, truststoreFileString);

        String keystoreFileString = connector.getSslConfiguration().getCertificateKeyFile();
        keystoreFileString = resolveExpression(mcc, keystoreFileString);

I'll have to investigate if that bug was fixed in our version of EAP. If so, we can avoid putting in hardcoded absolute paths. If that bug still exists, we'll have to figure out what we can do here (perhaps use relative paths as opposed to ${} notation).
Comment 15 Larry O'Leary 2013-11-06 11:29:29 EST
If it isn't fixed then relative paths -- if they work out to where we expect these files to exist by default -- will be fine.

Otherwise we will need to figure out how to replace these during startup as we do not support user modifications to standalone-full.xml at this time.
Comment 16 John Mazzitelli 2013-11-06 15:26:22 EST
git commit to master:


git commit to release/jon3.2.x:

Comment 17 Stefan Negrea 2013-11-07 15:07:17 EST
All the files mentioned above have been fixed to allow relative paths or the paths are automatically updated by the container. The commits above noted in comment #16 and the commits mentioned in this comment resolve the reported issue.

Additional release/jon3.2.x commits:



Comment 19 Simeon Pinder 2013-11-19 10:48:21 EST
Moving to ON_QA as available for testing with new brew build.
Comment 20 Simeon Pinder 2013-11-22 00:13:49 EST
Mass moving all of these from ER6 to target milestone ER07 since the ER6 build was bad and QE was halted for the same reason.
Comment 21 Armine Hovsepyan 2013-12-03 09:46:36 EST
verified in windows with er7
steps taken:
1. install jon server, sorage and agent in "jon3" direcotry
2. start services -> started, GUI accessible
3. stop services (rhqctl stop)
4. remove windows services (they have hard-coded paths to executables ) (rhqctl remove)
6. move jon from "jon3" to "jon4"
7. re-install services (rhqctl install)
8. re-start services (rhqctl start) -> all 3 services re-started correct, data from previous start visible 

screen-shots and steps in console attached
Comment 22 Armine Hovsepyan 2013-12-03 09:47:05 EST
Created attachment 832134 [details]
Comment 23 Armine Hovsepyan 2013-12-03 09:47:30 EST
Created attachment 832135 [details]
Comment 24 Armine Hovsepyan 2013-12-03 09:47:58 EST
Created attachment 832136 [details]
Comment 25 Armine Hovsepyan 2013-12-03 10:20:13 EST
verified on rhel6 with er7
steps taken:
1. install jon server, storage and agent in "jon" directory
2. rename "jon" to "jon2"
3. change RHQ_SERVER/STORAGE/AGENT_HOME properties
4. start server, storage and agent -> started without issues, no hard-coded full path
Comment 26 Armine Hovsepyan 2013-12-03 10:24:33 EST
Created attachment 832149 [details]

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