4.10 Install Changes (more changes, please read)

Jay Shaughnessy jshaughn at redhat.com
Tue Sep 24 16:01:06 UTC 2013


OK, the rhq.storage.num-nodes issue is resolved.   Note that, as in the 
past, only single nodes are supported on Windows.

On 9/24/2013 11:20 AM, Jay Shaughnessy wrote:
>
> 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
>
> _______________________________________________
> 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