This document describes the steps required to upgrade an existing Opsview Monitor 6.x system running on either a single server instance or a distributed Opsview environment (with a remote database and slaves) to the current version of Opsview Monitor.
Depending on the size and complexity of your current Opsview Monitor system, this process may take between a few hours to a full day.
If you are running Opsview Monitor 6.0-EA (Early Adopters), we recommend that you first upgrade to 6.0 AU (Autumn Update); please follow the steps on the [Upgrading from Opsview Monitor 6.0 Early Adopter](🔗) page, and then follow the steps on this page.
### Summary of process
Back-up your Opsview data
Run deployment process
Verify processes started
Apply changes in Opsview Monitor
## Upgrade process
### Minor upgrades
Minor upgrade information
When performing any upgrade it is advisable to take a backup of your system and therefore this is why the minor upgrade steps mirror that of the main upgrade steps
once your system is backed up, the process would be as per the ["Upgrading: Automated"](🔗) Steps below
To see what has changed throughout the versions you may navigate to ["Fixed Defects"](🔗)
### Activation Key
Ensure you have your activation key for your system - contact Opsview Support if you have any issues.
### Backup your Opsview data/system
Please refer to [Common Tasks](🔗) for more information.
Run the below command as root which will back up all database on the server:
The MySQL root user password may be found in `
Ensure you copy your database dump (`
/tmp/databases.sql.gz` in the above command) to a safe place.
### Opsview Deploy
Upgrading to a new version of Opsview Monitor requires the following steps:
Add the package repository for the new version of Opsview Monitor
Install the latest Opsview Deploy (opsview-deploy) package
Install the latest Opsview Python (opsview-python) package
Re-run the installation playbooks to upgrade to the new version
Once the upgrade has completed, all hosts managed by Opsview Deploy will have been upgraded to the latest version of Opsview Monitor.
#### Upgrading: Automated
#### Optional SHA256 checksum verification
You can also verify the script before running it by comparing the checksum you get with
Ensure the returned string matches the following:
You can then run the installation as before:
#### Upgrading: Manual
Amend your Opsview repository configuration to point to the 6.3 release rather than 6.0/6.1/6.2
Check the contents of `
/etc/yum.repos.d/opsview.repo` matches the following, paying special attention to the version number specified within the `
Check the contents of `
/etc/apt/sources.list.d/opsview.list` matches the following, paying special attention to the version number specified within the url. NOTE: replace 'xenial' with your OS name (as per other files within the same directory).
#### Update Opsview Deploy
### Pre-Deployment Checks
Before running opsview-deploy, we recommend Opsview users to check the following list of items:
#### Manual Checks
|All YAML files follow correct YAML format||opsview\_deploy.yml, user\_*.yml||Each YAML file is parsed each time opsview-deploy runs|
|All hostnames are FQDNs||opsview_deploy.yml||If Opsview Deploy can't detect the host's domain, the fallback domain 'opsview.local' will be used instead|
|SSH user and SSH port have been set on each host||opsview_deploy.yml||If these aren't specified, the default SSH client configuration will be used instead|
|Any host-specific vars are applied in the host's "vars" in opsview_deploy.yml||opsview\_deploy.yml, user\_*.yml||Configuration in user_*.yml is applied to all hosts|
|An IP address has been set on each host||opsview_deploy.yml||If no IP address is specified, the deployment host will try to resolve each host every time|
|All necessary ports are allowed on local and remote firewalls||All hosts||Opsview requires various ports for inter-process communication. See: [Ports](🔗)|
|If you have rehoming||user_upgrade_vars.yml||Deploy now configures rehoming automatically. See [Rehoming](🔗)|
|If you have Ignore IP in Authentication Cookie enabled||user_upgrade_vars.yml||Ignore IP in Authentication Cookie is now controlled in Deploy. See [Rehoming](🔗)|
|Webserver HTTP/HTTPS preference declared||user_vars.yml||In Opsview 6, HTTPS is enabled by default, to enforce HTTP-only then you need to set opsview_webserver_use_ssl: False. See [opsview-web-app](🔗)|
For example (opsview_deploy.yml):
#### Automated Checks
Opsview Deploy can also look for (and fix some) issues automatically. Before executing 'setup-hosts.yml' or 'setup-everything.yml', run:
If any potential issues are detected, a "REQUIRED ACTION RECAP" will be added to the output when the play finishes.
The automatic checks look for:
|Check||Notes or Limitations||Severity|
|Deprecated variables||Checks for: opsview_domain, opsview_manage_etc_hosts||MEDIUM|
|Connectivity to EMS server||No automatic detection of EMS URL in opsview.conf overrides||HIGH|
|Connectivity to Opsview repository||No automatic detection of overridden repository URL(s)||HIGH|
|Connectivity between remote hosts||Only includes LoadBalancer ports. Erlang distribution ports, for example, are not checked||MEDIUM|
|FIPS crypto enabled||Checks value of /proc/sys/crypto/fips_enabled||HIGH|
|SELinux enabled||SELinux will be set to permissive mode later on in the process by setup-hosts.yml, if necessary||LOW|
|Unexpected umask||Checks umask in /bin/bash for 'root' and 'nobody' users. Expects either 0022 or 0002||LOW|
|Unexpected STDOUT starting shells||Checks for any data on STDOUT when running `||LOW|
|Availability of SUDO||Checks whether Ansible can escalate permissions (using sudo)||HIGH|
When a check is failed, an 'Action' is generated. Each of these actions is formatted and displayed when the play finishes and, at the end of the output, sorted by their severity.
The severity levels are:
|HIGH||Will certainly prevent Opsview from installing or operating correctly|
|MEDIUM||May prevent Opsview from installing or operating correctly|
|LOW||Unlikely to cause issues but may contain useful information|
By default, the check_deploy role will fail if any actions are generated MEDIUM or HIGH severity. To modify this behaviour, set the following in `
The following example shows the 2 MEDIUM severity issues generated after executing check-deploy playbook
### Run Opsview Deploy
### Verify processes started
To verify that all Opsview processes are running, run:
If the opsview-agent process is not running after deployment, run:
If watchdog is not running after deployment run:
### Upgrade Opspacks
Run the following as the "opsview" user:
This may take a moment to run.
### Apply Changes in Opsview
In the Opsview application UI, navigate to "Configuration" - "Apply Changes", and run "Apply Changes".
### Reporting Email Configuration
As part of the upgrade to this Opsview Monitor release, the JasperReports Server part of the Reporting Module has been upgraded from 5.1.1 to 7.1.1. With this upgrade, the file `
js.quartz.properties` will be replaced, overwriting any contents in it. This file is used to configure the emailing capabilities of the Reporting Module and will need reconfiguring if it was previously configured.
To edit this file, open `
/opt/opsview/jasper/apache-tomcat/webapps/jasperserver/WEB-INF/js.quartz.properties` in a text editor and edit the default "report.scheduler.mail.sender." values to match your requirements. See [Reports - optional module](🔗) for more details.