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: <JON_HOME>/jon-server/bin/rhqctl.properties <JON_HOME>/jon-server/jbossas/standalone/configuration/logging.properties <JON_HOME>/jon-server/jbossas/standalone/configuration/standalone-full.xml <JON_HOME>/jon-server/rhq-storage/conf/cassandra.yaml <JON_HOME>/jon-server/rhq-storage/conf/log4j-server.properties Version-Release number of selected component (if applicable): JBoss ON 3.2.0.ER3 - Build: c0742ed:cbad264 How reproducible: Always 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.
> 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.
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.
Moving to ER05 as missed the cutoff for ER04.
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 ...
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.
adding DOCUMENTATION keyword, and doc person ... to review JON documentation in this area.
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); connector.getSslConfiguration().setCaCertificateFile(truststoreFileString); String keystoreFileString = connector.getSslConfiguration().getCertificateKeyFile(); keystoreFileString = resolveExpression(mcc, keystoreFileString); connector.getSslConfiguration().setCertificateKeyFile(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).
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.
git commit to master: 0ed021e037a00ab1c0c89664093f5d9ca6626dad 0738e579f8f40e7d703fd5e98a54d35d75a04520 git commit to release/jon3.2.x: adebf5ff232dbf418418753716a9aaec99797782 7da9fa1358efec9d0bdd26962ca60f3d479d3b2e
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: https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=770f2cdb935066501bd57db72466fb5226a0cc71 https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=23df184ff3b7c8d988985c13f8c887906f65507f https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=6e09ef87a476b15c7853a7f7837374ddab7344b7
Additional release/jon3.2.x commit: https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=76437304bb569767cfe2fcb19eb9fc9ea2942d54
Moving to ON_QA as available for testing with new brew build.
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.
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) 5. set RHQ_SERVER/STORAGE/AGENT_HOME env. vars 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
Created attachment 832134 [details] windows_jonpath.log
Created attachment 832135 [details] windows_service-jon3
Created attachment 832136 [details] windows_service-jon4
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
Created attachment 832149 [details] linux_jonpath.log