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