Welcome to docs.opsview.com

Upgrading Opsview

This pages details the steps to perform when upgrading Opsview. While most actions are handled during the package installation, there maybe some pre-upgrade and post-upgrade steps that require manual intervention.

If you are using slaves and there is a risk that there may be a connectivity issue during the upgrade then you may encounter problems during the post-install script. We are currently addressing this, however in the meantime we would recommend the following upgrade process:

  1. Deactivate the slaves
  2. Perform the upgrade
  3. Re-enable slaves
  4. Push updated software to slaves by running this command as nagios: /usr/local/nagios/bin/send2slaves
  5. Reload configuration

Opsview Engineering, 26/11/2014

There is a known issue with the Puppet module where hosts will be continually updated and a reload initiated. This is due to changes in Opsview 4.6 for security wallet where Opsview no longer sends the SNMP community string, SNMP v3 authentication password or SNMP v3 privacy password in clear text. We are working on a fix in a new release of the Puppet module and will update this note when it is released.

Opsview Engineering, 08/12/2014

Pre upgrade

  • Verify your Opsview repo file is updated to reflect proper access methods. Please see following link. http://docs.opsview.com/doku.php?id=repositories
  • Verify that the Opsview configuration is committed. As part of the upgrade, an Opsview reload will be run
  • Verify all the Opsview slaves are contactable - as part of the upgrade, the updated software will be pushed to the slaves
  • Run the backup script if required: /usr/local/nagios/bin/rc.opsview backup. This will backup the whole of /usr/local/opsview-web, the important parts of /usr/local/nagios and the configuration parts of the databases. Check that the backup files have been created in $backup_dir (set in /usr/local/nagios/etc/opsview.conf)

You are now ready to upgrade Opsview, using your normal OS package methods.

Database schema changes

Default character sets

Check that the database's default character set is the same as when it was initially created. If you have changed from latin1 to utf8, it is possible that upgrades will fail with the error message similar to:

DBD::mysql::db do failed: Can't create table 'opsview.autodiscovery_scans' (errno: 150)

This is due to a mismatch of character sets between the tables. Check with:

mysql> show create database opsview;
+----------+--------------------------------------------------------------------+
| Database | Create Database                                                    |
+----------+--------------------------------------------------------------------+
| opsview  | CREATE DATABASE `opsview` /*!40100 DEFAULT CHARACTER SET latin1 */ |
+----------+--------------------------------------------------------------------+

ODW upgrades

ODW tables have shipped with InnoDB as default since Opsview 3.9. If you are upgrading from an earlier version of Opsview, ensure that all tables in ODW have been converted to InnoDB before upgrading.

Upgrade process

As part of the upgrade process, the database schema may change. Normal output looks like:

Mon Nov  9 17:47:00 2009: Starting for runtime-nagios
Mon Nov  9 17:47:01 2009: DB at version 3.3.0
Re-arranging configuration indexes
Updated database to version 3.3.1

It is possible to override some of the steps taken as part of the upgrade process.

The process to override the steps is:

  • Find the appropriate upgrade script. There is an upgrade script for each database, with the name upgradedb_{name}.pl, which you can find at https://secure.opsera.com/svn/opsview/trunk/opsview-core/installer/
  • Review the upgrade step that does not need to be run, noting the database name and the upgrade step number (runtime is split into runtime-nagios and runtime-opsview)
  • Create the directory /tmp/opsview_upgrade_override
  • Create a file with the name {db_name}-{upgrade_step_number}
  • Now, when the upgrade runs, the step number should be avoided

For example, the upgrade script upgradedb_runtime.pl has a step 3.0.1 for runtime-nagios which converts tables to InnoDB format. If you have already done this, then you do not need to run this step. Create a file to stop this step from running:

touch /tmp/opsview_upgrade_override/runtime-nagios-3.0.1

This upgrade step will now not run during the upgrade process.

Version specific

Ubuntu 12 to Ubuntu 14 OS upgrade

If you are performing the OS upgrade alongside upgrade to the latest Opsview 4.6 the recommended process is as follows:

  • Upgrade your OS first by following the Ubuntu documentation: https://help.ubuntu.com/community/UpgradeNotes. WARNING: This will disable Opsview repositories and may uninstall Opsview packages with its dependencies (eg. mysql-server)
  • Re-enable Opsview repositories
  • Refresh package repositories:
sudo apt-get update
  • Re-install opsview packages:
sudo apt-get install opsview libapache2-mod-auth-tkt-prefork-opsview
  • Due to the upgrade of Apache from 2.2 to 2.4 on Ubuntu 14, sites configuration files should now use .conf extension:
sudo mv -v /etc/apache2/sites-enabled/opsview /etc/apache2/sites-enabled/opsview.conf
  • Restart Apache
sudo /etc/init.d/apache2 restart

Now you system should be upgraded to Ubuntu 14 and using the latest Opsview 4.6

During upgrade

Upgrade your package using your normal OS package methods. Notes below are based on your package management system.

Note: If you have a distributed environment, please check the output from the package installation. We've discovered a case where a slave upgrade can fail if there are files that are not readable by the nagios user. This means that the files on the slave may not be in sync with the master.

Apt

Upgrade your Opsview install:

apt-get update && apt-get install opsview

Note: This will automatically run database credential changes using the debian-sys-maint user.

YUM

Due to the dependency logic not working correctly, you need to tell yum to install each package individually:

yum install opsview opsview-core opsview-base opsview-perl opsview-web mod_auth_tkt_opsview

This will upgrade Opsview and upgrade the database schemas (if appropriate).

RPMs

If you do not access to use yum and need to install RPMs locally, you must install all the dependencies and first, followed by Opsview's packages:

rpm -U opsview-perl opsview-base opsview-core opsview-web opsview

Ensure you review the output of the RPM installation to verify that the install was successful.

To reinstall a failed package, you have to remove it first. For instance, if you were attempting to install opsview-core-3.0.2.2276 and this failed, you would have to run:

rpm -e --nodeps opsview-core-3.0.2.2276

to delete the old package before trying to reinstall it again.

SLES

You have to update the zypper repository metadata, and then do the upgrade:

zypper refresh
zypper update

Erroneous Message of "Packages are Not Supported By Vendor"

When running zypper update, you could get output like:

Loading repository data...
Reading installed packages...

The following packages are going to be upgraded:
  opsview opsview-base opsview-core opsview-perl opsview-web 

The following packages are not supported by their vendor:
  opsview opsview-base opsview-core opsview-perl opsview-web 

Although it says that the packages are not supported by their vendor, Opsview Limited will continue to support these packages.

This appears to be a configuration setting within SLES' zypper repositories.

Packages Cannot Be Upgraded Individually

Although zypper update and zypper list-updates displays Opsview packages that can be upgraded, running zypper update opsview-perl says that there is Nothing to do.

The only solution appears to be to run zypper update, though this is not ideal if there is a large number of packages that need to be upgraded.

This is tracked as a bug at https://secure.opsview.com/jira/browse/OPS-1785.

Vendor Change

If you are upgrading Opsview using zypper from a version before March 2012, you may get a message such as:

The following package update will NOT be installed:
  opsview-perl opsview-base opsview-web opsview-core 

This is likely to be because of changes to the vendor specification in the RPM package files from Opsera Limited to Opsview Limited.

To workaround this, we recommend that you change the zypper configuration to allow vendor changes temporarily. You will need to edit /etc/zypp/zypp.conf and uncomment:

solver.allowVendorChange = true

If you now run zypper update, the packages will be allowed to upgrade.

You will only need to do this once.

Post upgrade

Apache proxy

If you are using the Apache proxy (which we recommend for all installs), check the sample configuration file at /usr/local/nagios/installer/apache_proxy.conf for any changes.

Version specific

Modules

As all Opsview Modules are contained within the same repository, you should also upgrade all modules that you have currently installed.

See documentation for each module:

Opsview Agent (NRPE)

There may have been changes made to the Agent's nrpe.cfg file. This file exists on masters and slaves. When Opsview is upgraded, or when a reload happens, this file does not change on slaves. This is so that any local changes won't disappear. However, it does mean that, if we have made changes to the distributed version of this file on the master, they will need to be applied to the copies on any slaves. Compare the nrpe.cfg file on the master with the ones on slaves, and make any necessary changes.

Troubleshooting

Errors during upgrade

Ensure you review the output of the upgrade to verify that it was successful. If there was an error, the upgrade may halt and further steps will need to be manually performed. These are the steps run by the postinstall as the root user:

su - nagios -c '/usr/local/nagios/installer/upgradedb.pl'
su - nagios -c '/usr/local/nagios/bin/send2slaves'
su - nagios -c '/usr/local/nagios/bin/populate_db.pl'
su - nagios -c 'OPSVIEW_NOSTART=true /usr/local/nagios/bin/rc.opsview gen_config'
/usr/local/nagios/installer/postinstall_root
su - nagios -c '/usr/local/nagios/installer/postinstall'
/sbin/chkconfig --add opsview  # For Redhat, CentOS, SLES
/etc/init.d/opsview start
rm -f /usr/local/nagios/var/upgrade.lock

Reloads fail following an upgrade

After an upgrade, a reload will automatically take place.

In a distributed environment, if there is a problem where the newly upgraded files have not been sent to the slaves, then new configurations created by Opsview may not pass validation, so you may see errors like:

Reading configuration data...
Error in configuration file '/usr/local/nagios/tmp/nagios.27520/nagios.cfg' - Line 635 (UNKNOWN VARIABLE)

This usually means that the slave servers do not have the latest software.

To force sending the new binaries to the slave systems, run:

su - nagios
/usr/local/nagios/bin/send2slaves {slavename}

There may be permission errors which mean that the sending to slaves did not work correctly during the upgrade.

Database errors after an upgrade

If you are encountering database errors after an upgrade, it maybe that the database upgrade scripts didn't run properly. All database upgrades are handled automatically and will continue from when the last database state was.

To invoke the database changes, run as the nagios user:

/usr/local/nagios/installer/upgradedb.pl

This is not destructive (it will only make changes that are required), but you should only run it if you have problems.

Navigation
Print/export
Toolbox