4.10 Install Changes (more changes, please read)

Jay Shaughnessy jshaughn at redhat.com
Thu Oct 3 15:52:41 UTC 2013


And the hits keep coming...  As per 
https://bugzilla.redhat.com/show_bug.cgi?id=1006352 changes have been 
pushed:

New behavior in place.  The rhqctl install and upgrade commands no longer
leave the installed or upgraded services running, by default. In other
words, they perform only an install or upgrade.

Each now supports a --start option which will ensure the installed or upgraded
services are running when the install or upgrade completes.

Note that for the install command this applies only to services actually
installed by that command invocation (i.e. install can not substitute for
start).

Note that for upgrade the storage service will always be left running after
upgrade if the migrate-data option is specified, to support the migration.

Note that the --agent-auto-start option has been removed from both commands
since they are superseded by the --start option.


Don't get fooled :)  You now need to specify --start to get the old 
behavior, otherwise perform rhqctl start after install or upgrade, to 
actually get things running.


On 10/1/2013 11:59 AM, Jay Shaughnessy wrote:
>
> More changes to 'rhqctl install':
>
> There is now more up-front validation of rhq-server.properties and 
> rhq-storage.properties when executing 'rhqctl install'.   Issues with 
> property settings should cause rhqctl to exit before actually 
> attempting to install anything.  Furthermore, it will now prompt for 
> jboss.bind.address and rhq.server.database.password if it is unset in 
> rhq-server.properties file.
>
> Please let me know if you encounter any issues with the validation or 
> interactive setting of properties.
>
> One more thing.  There is now (well, now=shortly) a 
> bin/rhq-encode-password.sh|bat script for encoding the db password. No 
> longer do you use rhq-installer --encodepassword, because that script 
> has been moved to bin/internal.
>
>
> On 9/26/2013 10:28 AM, Jay Shaughnessy wrote:
>>
>> 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 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
>>>>
>>>> _______________________________________________
>>>> 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