Back to Opsview FAQ

Internal documentation only

This page has been marked as draft.

Collector CentOS 7 to Oracle Linux 8 in-place upgrade

CentOS 7 (ct7) is End Of Life on June 2024, which means there will be no further security updates or support. To keep your Collector(s) supported, you need to change them to a different OS.

This article covers migrating Collectors in-place to Oracle Linux 8 (ol8), This configuration may be used to migrate to RHEL8 using the equivalent settings.

You should apply downtime to the Collector(s) being upgraded. The process may stop if you do not have sufficient disk space to complete the upgrade.

Note: Either upgrade each Collector Node within a Cluster one at a time (complete one before moving onto the next) or upgrade all Collector Nodes within the Cluster at the same time

1. Open a terminal session to the Collector server to be upgraded and switch to root.

2. Ensure CentOS 7 is fully up to date:

   yum update -y
   

3. The server must be rebooted to ensure it is running on the latest kernel. To do this, stop all Opsview processes gracefully (this assumes using a bash shell):

   source /opt/opsview/lib/monit.sh
   list_services
   stop_services "${!SERVICES[@]}"
   

4. Confirm all Opsview process are all stopped:

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

5. Reboot the server:

   reboot
   

6. Take a snapshot or full backup of the collector

7. Reopen a terminal session to the server,sudo to root and install ELevate, leapp and the Oracle Linux data package:

   sudo -i
   yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
   yum install -y leapp-upgrade leapp-data-oraclelinux
   

8. If you use Postfix, amend its configuration as it is known to be affected by CT7 to OL8 upgrades:

   postconf -e compatibility_level=0
   

9. Set a response to standard known questions in the leapp answerfile:

   cat >> /var/log/leapp/answerfile <<EOF
   [remove_pam_pkcs11_module_check]
   confirm = True
   [authselect_check]
   confirm = False
   EOF
   

10. Add additional repositories to /etc/leapp/files/leapp_upgrade_repositories.repo Make sure that <VERSION> in Opsview repository baseurl line is replaced to match the version from /etc/yum.repos.d/opsview.repo from the Orchestrator (you may also see this same file on the Collector to confirm the configuration). NOTE: do not use $releasever in the opsview-6.8 baseurl setting - set it explicitly to 8, for example: baseurl = https://downloads.opsview.com/opsview-commercial/6.8.9.202312051712/yum/rhel/8/$basearch/

    [opsview-6.8]
    async = 1
    baseurl = https://downloads.opsview.com/opsview-commercial/<VERSION>/yum/rhel/8/$basearch/
    enabled = 1
    gpgcheck = 1
    gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Opsview
    name = Opsview
    
    [ol8_developer_EPEL]
    name=Oracle Linux $releasever EPEL Packages for Development ($basearch)
    baseurl=https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/$basearch/
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
    gpgcheck=1
    enabled=1
    
    [ol8_developer_EPEL_modular]
    name=Oracle Linux $releasever EPEL Modular Packages for Development ($basearch)
    baseurl=https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/modular/$basearch/
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
    gpgcheck=1
    enabled=1
    

11. Remove opsview and epel repositories from the yum configuration directories

    mv /etc/yum.repos.d/opsview.repo /etc/yum.repos.d/epel.repo /var/tmp/
    

12. Run the preupgrade checks (takes a while):

    leapp preupgrade
    

13. Check the resulting file for any issues that may need further answers or changes to system configuration:

    view /var/log/leapp/leapp-report.txt
    

14. If any additional steps were performed, or errors where reported by the preupgrade step, rerun and confirm all issues have been solved

15. Proceed with the initial upgrade step:

    leapp upgrade
    

16. When the command completes, stop all Opsview processes to reboot the server and start the conversion:

    source /opt/opsview/lib/monit.sh
    list_services
    stop_services "${!SERVICES[@]}"
    

17. Confirm all Opsview process are all stopped:

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

18. Reboot the server:

    reboot
    

    This reboot will take some time due to performing the OS migration process. You may be able to watch progress on the system console, depending on what virtualisation software or physical hardware you are using

19. When the migration process is complete and the server is available on the network again, reopen a terminal session to the server,sudo to root and disable the firewall (as the upgrade will re-enable it):

    systemctl stop firewalld
    systemctl disable firewalld
    

20. Fix the python configuration:

    alternatives --install /usr/bin/python python /usr/bin/python3 50
    

21. Ensure all Opsview processes are started correctly

    /opt/opsview/watchdog/bin/opsview-monit start all
    

22. Confirm all Opsview process are all started:

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

23. Perform an Apply Changes in the UI to copy all required plugins from the orchestrator to the collector

At this point, the Opsview UI should show all checks on the Collector are either running or recovering. If there are further issues, perform a Collector upgrade:

1. If it is remotely managed Collector, start the Collector upgrade from the UI (“Menu => Configuration => Collector Management”)

2. If it is centrally managed Collector, use opsview-deploy from the Orchestrator

   /opt/opsview/deploy/bin/opsview-deploy -l <collector hostname> /opt/opsview/deploy/lib/playbooks/setup-everything.yml