'Re: 4.10 Install Changes (more changes, please read)'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-devel
Subject:    Re: 4.10 Install Changes (more changes, please read)
From:       Jay Shaughnessy <jshaughn () redhat ! com>
Date:       2013-09-26 14:28:08
Message-ID: 52444478.2080103 () redhat ! com
[Download RAW message or body]

Master commit 8a5c8c38a145d0521d019360e3f2526f7604b1fa normalizes 
property names for storage to be prefixed with "rhq.storage.". This 
should reduce complexity by eliminating multiple names for the same 
logical value, and make things more analogous to rhq-server.properties.

==> To best deal with the resulting changes it is recommended to rebuild 
dev environments completely after your next git pull.

On 9/25/2013 10:02 AM, Jay Shaughnessy wrote:
>
> Installation/rhqctl wiki pages have been updated.  Please let me know 
> if you see any issues.
>
> https://docs.jboss.org/author/display/RHQ/RHQ+Server+Installation
>
> On 9/24/2013 12:01 PM, Jay Shaughnessy wrote:
>>
>> 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@lists.fedorahosted.org
>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>>>
>>>>> _______________________________________________
>>>>> rhq-devel mailing list
>>>>> rhq-devel@lists.fedorahosted.org
>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>>
>>>> _______________________________________________
>>>> rhq-devel mailing list
>>>> rhq-devel@lists.fedorahosted.org
>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel@lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel@lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

[prev in list] [next in list] [prev in thread] [next in thread] 