Welcome to docs.opsview.com

Upgrading Opsview

This page 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 upgrading from Opsview Community 3.20120424 or any earlier versions (including 3.13), please check the special upgrade instructions.

If you are upgrading from Opsview 3.20120925 or earlier, due to changes to Nagios Core 4, service checks that contain a backslash (“\”) in the argument field are likely to need to be changed. See the documentation for more information.

Pre upgrade

Please be aware of the following:

  • The Opsview server will be made offline during the upgrade

Actions to do before an upgrade:

  • Verify that the Opsview configuration is committed. As part of the upgrade, an Opsview reload will be run
  • 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)

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 */ |

Upgrade process

As part of the upgrade process, the database schema may be upgraded. 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

From Opsview 3.4.0, 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

These are some steps that should be checked before upgrading to a specific level.

You should follow instructions through all the versions that you will upgrade through. Note that some versions are based on dates - these are the dates that the code was committed, not release versions

Version Steps required
3.1.0 Host group hierarchy constraint
3.3.0 ODW table index change
3.3.1 Conversion to BIGINT for two tables in Runtime
3.3.2 Nagios® Core instances in Runtime database
3.7.2 Runtime database index changes, Service checks expected on your system
2012-05-09 Upgrading to Opsview Core
2012-06-13 Acknowledgement and downtime data included in Runtime's statehistory table
2012-10-22 Conversion to BIGINT for two tables in Runtime (cont.)

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. This is tracked as a bug OPS-896.

APT for Debian and Ubuntu

Upgrade by running as root user:

apt-get update
apt-get install opsview

Note: If you have changed your mysql root password, you will need to have it ready as you may be prompted for it.

YUM for CentOS and RHEL

Upgrade by running as root:

yum clean all
yum makecache
yum install opsview opsview-core opsview-base opsview-perl opsview-web opsview-compatibility-check

Due to the dependency logic not working correctly, you need to tell yum to install each package individually. This is tracked in OPS-1593.


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-compatibility-check 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- and this failed, you would have to run:

rpm -e --nodeps opsview-core-

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


Due to limitations in zypper, you cannot upgrade Opsview - you have to remove the previous version and install the newer versions. Because of this, you will also need to run the post upgrade tasks manually:

zypper remove opsview opsview-web opsview-core opsview-base opsview-perl
zypper refresh
zypper install opsview
su - nagios
/etc/init.d/opsview start
/etc/init.d/opsview-web start

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. This is tracked as a bug in https://secure.opsview.com/jira/browse/OPS-1784.

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.

Solaris PKGs

Download the packages from http://downloads.opsview.com/opsview-core/latest/solaris/sol10n

The normal method of upgrading Solaris packages is to remove all the current packages and then install the new ones.

The correct order to remove the packages is:

  1. ALTovweb (or opsview-web, from March 2012 onwards)
  2. ALTovcore (or opsview-core)
  3. ALTovbase (or opsview-base)
  4. ALTovperl (or opsview-perl)
  5. apache2-modauthtkt-opsview


pkgrm opsview-web

Note: Please positively acknowledge all on screen prompts asking you to confirm the removal of the packages.

The correct order of installing the new packages, using pkgadd, is:

  1. apache2-modauthtkt-opsview
  2. opsview-perl
  3. opsview-base
  4. opsview-core
  5. opsview-web

Note: It will be necessary to unzip the packages first with gunzip.


pkgadd -d /path/to/package/apache2-modauthtkt-opsview-2.0.4rc3-sol10-i386_32.pkg

Note: Please enter 'all' when prompted to select the packages to process, then positively acknowledge all on screen prompts asking you to confirm the installation of the packages.

Upgrade all databases. Run as the nagios user:


Post upgrade

Upgrade Bug on Solaris

Due to a bug in the Solaris packages, the nagios user's crontab may not have Opsview generated entries. Also, the opsview-agent will not be running.

This affects existing Solaris system where you have upgraded to a version beyond 3.5.1 or higher.

Check the nagios user's crontab:

crontab -l nagios | grep OPSVIEW-START

If this returns with no lines, then you need to execute:

su - nagios

This will replace the crontab entries.

You will also need to start the agent:

/etc/init.d/opsview-agent start


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


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/populate_db.pl'
su - nagios -c 'OPSVIEW_NOSTART=true /usr/local/nagios/bin/rc.opsview gen_config'
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

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:


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