Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[apache] do not trust SNMP WWW Service Index value during vhost upgrade|
|Product:||[Other] RHQ Project||Reporter:||Lukas Krejci <lkrejci>|
|Component:||Plugins||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-02 03:25:15 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||694476|
Description Lukas Krejci 2011-05-16 07:04:32 EDT
Description of problem: The apache vhost upgrade blindly trusts the value of the "SNMP WWW Service Index" property from the plugin configuration of the vhost being upgraded. This value can be stale or tampered with by the user which makes the upgrade not behave perfectly in those cases. It would be better to try the upgrade using the resource key matching algorithm and fail the upgrade if that method fails than to blindly trust the SNMP WWW Service Index value and end up with vhosts that would suddenly represent wrong configuration. Note that in this scenario, the vhosts are misconfigured in the inventory before the upgrade takes place in a sense that they configure different vhost than they monitor. The upgrade on the other hand has a chance to detect and corret that situation which it currently doesn't take advantage of. Steps to Reproduce: 1. Have an apache discovered using the latest code from release-3.0.1 branch (RHQ 3.0.1 release is old) 2. Modify the SNMP WWW Service Index value in the connection settings of vhosts or mix the order of the vhosts in the configuration files 3. During installation of RHQ release-4.0.0 ask to upgrade the database 4. Wait for the agents to update themselves, restart and upgrade the resource keys of the vhosts alternatively: 1. Have apache discovered by RHQ 1.3.x (JBoss ON 2.3.x) 2. Mix the order of vhost entries in the apache configuration files 3. During the installation of RHQ release-4.0.0 branch ask to upgrade the database 4. Wait for the agents to update themselves, restart and upgrade the resource keys of the vhosts Actual results: Alternative 1: the vhosts start to configure the entries corresponding to the monitoring, which is different to what they were configuring when originally discovered. Alternative 2: Before the upgrade the vhost's resource key didn't correspond to what it actually monitored. After the upgrade the situation is corrected to correspond to what it actually monitored at the expense of disregarding the original resource key as any indicator of what the vhost *should* have monitored/configured. Expected results: The plugin should prefer the resource key over the SNMP WWW Service Index as an indicator of what a vhost should be configuring/monitoring. Additional info:
Comment 1 Lukas Krejci 2011-05-16 07:31:45 EDT
Fixed in master (NOT in release-4.0.0) by commits: commit dfce189ee21ec257b9e01a089b8fdb15ba9054fd Author: Lukas Krejci <firstname.lastname@example.org> Date: Mon May 16 13:13:25 2011 +0200 BZ 705004 - Made the vhost upgrade method just throw an exception on failed upgrade to better follow the upgrade workflow and to make recovery from that condition possible in some ca commit e265710deb2fa6abb4516ad8191c6257e3a17afb Author: Lukas Krejci <email@example.com> Date: Mon May 16 13:12:29 2011 +0200 BZ 705004 - hardened the vhost upgrade process by: a) doing a cross-check that the SNMP WWW Service Index value actually corresponds to the resource we're upgrading and if not fall back to resource key matching. b) Use the actual code from RHQ 3 codebase to determine the possible legacy resource keys. This is to reduce the number of possible collisions.
Comment 2 Sunil Kondkar 2011-07-15 06:38:31 EDT
Configured SNMP module for Apache server. Installed jon231GA build and discovered Apache server with two vhosts. Verified that the two vhosts are collecting metrics. Mixed the order of vhost entries in the Apache configuration file and upgraded to the master build#188. Verified that the resource keys of both the vhosts are changed and they are collecting metrics correctly. Marking as verified.
Comment 3 Heiko W. Rupp 2013-09-02 03:25:15 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.