4.10 Install Changes (more changes, please read)

Jay Shaughnessy jshaughn at redhat.com
Tue Sep 24 15:20:29 UTC 2013


There is currently an issue for dev builds trying to install more than 
one storage node.  Until further notice, don't override 
rhq.storage.num-nodes (defaults to 1) for your dev container builds.

On 9/24/2013 10:26 AM, Jay Shaughnessy wrote:
>
> In an effort to further simplify installation more changes have just 
> been pushed to master.   When performing 'rhqctl install' the 
> --server-config and --storage-config options have been removed.
>
> The --server-config option really didn't make a lot of sense.  We are 
> driving off the expected rhq-server.properties file for install, 
> runtime etc.  An install time override of the values in 
> rhq-server.properties was unnecessary and confusing.
>
> The --storage-config option was confusing in that people (users and 
> devs) didn't know whether rhq-storage.properties should always exist, 
> sometimes exist, could be named something else, etc...  The 
> rhq-storage.properties file will now always exist and be processed 
> when installing a storage node.  Analogous to the server properties 
> file, it will be provided and fully commented in the distribution. It 
> will be preset with dev settings for dev builds. It differs from the 
> server properties file in that it is used for install only,  not at 
> runtime.   Note that it has no production defaults, but is still fully 
> commented and easy to edit by the installing user, if desired.
>
> I'll be updating the wikis now...
>
>
> On 9/19/2013 1:13 PM, Jay Shaughnessy wrote:
>>
>> In an effort to simplify 4.10 installation we're removing the need 
>> for the user to explicitly encode and set passwords for 
>> rhq.storage.password and rhq.server.management.password, in 
>> rhq-server.properties.
>>
>> The changes are now in master.  These values, as well as 
>> rhq.storage.username, will now be generated at install time and will 
>> be set in rhq-server.properties automatically.  This reduces the 
>> complexity of install to some degree, relieving the user of having to 
>> think about passwords that are not really relevant to him, and 
>> reducing the chance of error.  It's also been set up such that the 
>> RHQ Server resources should, upon discovery, be updated with the 
>> correct creds and therefore should connect seamlessly and begin 
>> monitoring.
>>
>> The 4.10 wiki pages have been updated: 
>> https://docs.jboss.org/author/display/RHQ/User+Documentation.
>>
>> Along with these changes the storage credentials are now also stored 
>> in the DB as part of the system config.  This allows for HA installs 
>> to use the existing creds for the storage cluster. The added support 
>> added a DB schema change, so a dbsetup or dbsetup-upgrade will be 
>> required.
>>
>> Let me know if you see any issues.  Thanks,
>>
>> Jay
>>
>>
>> On 9/6/2013 5:07 PM, Jay Shaughnessy wrote:
>>>
>>> Devels,
>>>
>>> There is a recent commit that applies some security-related changes 
>>> we've been asked to apply.  In particular, you will now see changes 
>>> in rhq-server.properties instructing you to set two new properties 
>>> prior to installation.
>>>
>>> Note that when building -Pdev your dev container will have already 
>>> had these values set, as in the past, so there is no required 
>>> action.  But for non-dev-container installs they will need to be 
>>> set.  The two properties are:
>>>
>>>   jboss.bind.address
>>>   rhq.server.management.password
>>>
>>> jboss.bind.address is no longer set automatically to 0.0.0.0. It 
>>> must now be explicitly set, as desired.  It can be set to 0.0.0.0 to 
>>> simply maintain the previous behavior.
>>>
>>> rhq.server.management.password holds an obfuscated value for the RHQ 
>>> Server's 'rhqadmin' management user.  It must be set to a valid 
>>> management user password.  It can be easily set to the previous 
>>> default by uncommenting the line in rhq-server.properties.
>>>
>>> *** Currently the previous default must be used ***
>>>
>>> This is due to the fact that we don't yet have a password generator 
>>> in place for this value.  The algorithm is different than for the 
>>> obfuscation used for the db and storage node passwords, because it 
>>> is AS generated.  When set to a non-default value the discovered 
>>> rhq-server resource will not be able to connect, as it uses the 
>>> default value.  So, non-default values will also need to be applied 
>>> to rhq-server resource connection properties to get the plugin to 
>>> connect to the server.
>>>
>>> Upgrades do not need to worry about setting these, the upgrade will 
>>> take care of it.
>>>
>>> I'll update you as soon as we have a mechanism for generating the 
>>> management user password values.
>>>
>>> Jay
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list