From 6.0, 6.1 or 6.2 to 6.3

Overview

This document describes the steps required to upgrade an existing Opsview Monitor 6.0, 6.1 or 6.2 system running on either a single server instance or a distributed Opsview environment (with a remote database and slaves) to version 6.3 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.

Summary of process

Back-up your Opsview data
Run deployment process
Verify processes started
Upgrade Opspacks
Apply changes in Opsview Monitor

Limitations

(None)

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:

# mysqldump -u root -p --add-drop-database --extended-insert --opt --all-databases | gzip -c > /tmp/databases.sql.gz

The MySQL root user password may be found in /opt/opsview/deploy/etc/user_secrets.yml.

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

#
#  This will...
#   * Configure the Opsview Monitor 6.3 package repository
#   * Upgrade opsview-deploy to the corresponding version
#
curl -sLo- https://deploy.opsview.com/6.3 | sudo bash -s -- --only repository,bootstrap

#
#  This will execute opsview-deploy to validate and upgrade Opsview
#
root:~# cd /opt/opsview/deploy
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/check-deploy.yml
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/setup-everything.yml

Once completed, continue with the Post-upgrade Process

Upgrading: Manual

Amend your Opsview repository configuration to point to the 6.3 release rather than 6.0/6.1/6.2

CentOS/RHEL/OL

Check the contents of /etc/yum.repos.d/opsview.repo matches the following, paying special attention to the version number specified within the baseurl line:

[opsview]
name    = Opsview Monitor
baseurl = https://downloads.opsview.com/opsview-commercial/6.3/yum/rhel/$releasever/$basearch
enabled = yes
gpgkey  = https://downloads.opsview.com/OPSVIEW-RPM-KEY.asc

Debian/Ubuntu

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).

deb https://downloads.opsview.com/opsview-commercial/6.3/apt xenial main

Update Opsview Deploy

CentOS/RHEL/OL

yum makecache fast
yum install opsview-deploy

Debian/Ubuntu

apt-get update
apt-get install opsview-deploy

Pre-Deployment Checks

Before running opsview-deploy, we recommend Opsview users to check the following list of items:

Manual Checks

What	Where	Why
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):

---
orchestrator_hosts:
  # Use an FQDN here
  my-host.net.local:
    # Ensure that an IP address is specified
    ip: 10.2.0.1
    # Set the remote user for SSH (if not default of 'root')
    ssh_user: cloud-user
    # Set the remote port for SSH (if not default of port 22)
    ssh_port: 9022
    # Additional host-specific vars
    vars:
      # Path to SSH private key
      ansible_ssh_private_key_file: /path/to/ssh/private/key

Automated Checks

Opsview Deploy can also look for (and fix some) issues automatically. Before executing 'setup-hosts.yml' or 'setup-everything.yml', run:

root:~# cd /opt/opsview/deploy
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/check-deploy.yml

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 `/bin/bash -l`	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:

Level	Meaning
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 user_vars.yml:

# Actions at this severity or higher will result in a failure at the end of the role.
# HIGH | MEDIUM | LOW | NONE
check_action_fail_severity: MEDIUM

The following example shows the 2 MEDIUM severity issues generated after executing check-deploy playbook

REQUIRED ACTION RECAP **************************************************************************************************************************************************************************************************************************
 
[MEDIUM -> my-host] Deprecated variable: opsview_domain
  | To set the host's domain, configure an FQDN in opsview_deploy.yml.
  |
  | For example:
  |
  | >>  opsview-host.my-domain.com:
  | >>    ip: 1.2.3.4
  |
  | Alternatively, you can set the domain globally by adding opsview_host_domain to your user_*.yml:
  |
  | >>  opsview_host_domain: my-domain.com
 
[MEDIUM -> my-host] Deprecated variable: opsview_manage_etc_hosts
  | To configure /etc/hosts, add opsview_host_update_etc_hosts to your user_*.yml:
  |
  | >>  opsview_host_update_etc_hosts: true
  |
  | The options are:
  | - true   Add all hosts to /etc/hosts
  | - auto   Add any hosts which cannot be resolved to /etc/hosts
  | - false  Do not update /etc/hosts
 
 
Thursday 21 February 2019  17:27:31 +0000 (0:00:01.060)       0:00:01.181 *****
===============================================================================
check_deploy : Check deprecated vars in user configuration ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 1.06s
check_deploy : Check for 'become: yes' -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 0.03s
 
*** [PLAYBOOK EXECUTION SUCCESS] **********

Run Opsview Deploy

root:~# cd /opt/opsview/deploy
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/check-deploy.yml
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/setup-everything.yml

Post-upgrade process

Run Post-upgrade tasks

#
#  This will...
#   * Execute setup-monitoring to perform post-upgrade tasks
#
root:~# cd /opt/opsview/deploy
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/setup-monitoring.yml

Verify processes started

To verify that all Opsview processes are running, run:

/opt/opsview/watchdog/bin/opsview-monit summary -B

If the opsview-agent process is not running after deployment, run:

/etc/init.d/opsview-agent stop
/etc/init.d/opsview-agent start
/opt/opsview/watchdog/bin/opsview-monit start opsview-agent

If watchdog is not running after deployment run:

/opt/opsview/watchdog/bin/opsview-monit

Upgrade Opspacks

Run the following as the "opsview" user:

/opt/opsview/coreutils/bin/install_all_opspacks -f -d /opt/opsview/monitoringscripts/opspacks

This may take a moment to run.

Syncing all Plugins to Collectors

This step will copy all updated plugins on the Master Server to each of the Collectors and should be run as the root user:

#
#  This will distribute plugins from Master to Collectors
#
root:~# cd /opt/opsview/deploy
root:/opt/opsview/deploy# ./bin/opsview-deploy lib/playbooks/sync_monitoringscripts.yml

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.

Upgrade to Opsview Monitor 6.4

Once you have upgraded to Opsview Monitor 6.3, you can perform an In-place to Opsview Monitor 6.4, for more information go to Upgrade from Opsview Monitor 6.3