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