Oracle Linux 7 was released in 2014 and the system is close to its sunset. The premier support for the system will be wrapped up by July 2024 and it is time to think about moving forward. All the new systems, as I can see, are using version 8 and some even version 9. So it is time for an upgrade. And when we speak about upgrading we usually have two options – in-place and out-of-place. The in-place upgrade modifies the system on the same box keeping all the users data intact and the second approach is more like a migration when you move all your app stack and data to a new box with a new version of the OS. So, how difficult is the in-place upgrade and when it makes sense?
The upgrade process is not challenging and requires minimum steps from the user. Oracle 7 and Oracle 8 are using the leapp utility which runs all the upgrade steps. Here is the upgrade process for a Linux 7.9 on ARM.
All the steps are perfectly described in the documentation including some issues you might hit.
The first step was a full backup of the OS to make sure I can roll back in case of any issues. If you are in the cloud it is really easy – you just get boot volume backup. Before proceeding, let’s have a look at what we have before the upgrade.
[opc@arm-gleb-ca ~]# cat /etc/oracle-release Oracle Linux Server release 7.9 [root@arm-gleb-ca ~]#uname -r 5.4.17-2102.201.3.el7uek.aarch64 #I have also PHP and HTTP server [opc@arm-gleb-ca ~]$ php -v PHP 7.3.11 (cli) (built: Jan 31 2020 14:02:52) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies [opc@arm-gleb-ca ~]$ /opt/rh/httpd24/root/sbin/httpd -v Server version: Apache/2.4.34 (Oracle) Server built: Sep 14 2020 10:04:40 [opc@arm-gleb-ca ~]$
Then I ran the preparation steps. Most of the work was done by the leap utility. What we needed was to get the leap utility and run the pre-upgrade check.
[opc@arm-gleb-ca ~]$ sudo yum install -y leapp --enablerepo=ol7_leapp,ol7_latest ... Installed: leapp.noarch 0:0.13.0-1.el7_9 ... Complete! [opc@arm-gleb-ca ~]$ sudo leapp preupgrade --oci A report has been generated at /var/log/leapp/leapp-report.json A report has been generated at /var/log/leapp/leapp-report.txt ============================================================ END OF REPORT ============================================================ Answerfile has been generated at /var/log/leapp/answerfile [opc@blog-gleb-ca ~]$
The tool would provide two reports and an answer file located in the /var/log/leapp directory. The result depends on your set of packages and settings but in all my cases I should fix just a couple of problems before the upgrade.
The first one was related to my sshd configuration where the PermitRootLogin in /ets/ssh/sshd_config was set to default (yes) and should be switched to “no”.
[opc@arm-gleb-ca ~]$ sudo vi /etc/ssh/sshd_config ... #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6 ... [opc@arm-gleb-ca ~]$ sudo systemctl restart sshd.service
The second one was related to the module pam_pkcs11 which was no longer available in OL 8 and removal should be confirmed in the answer file. It can be done either manually or by running a command.
[opc@arm-gleb-ca ~]$ sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
The command modifies the /var/log/leapp/answerfile confirming removal of the pam_pkcs11.
The rest of the preparation was standard and, since my box was on OCI, included disabling the OS Management Service Agent. It can be done either through the web console or using a modified json file for the ‘agent-config’ property for the instance where the ‘desired-state’ for “OS Management Service Agent” is switched to ‘DISABLED’. Then you run the command “oci compute instance update …” with your json file.
The upgrade itself required only one command to be executed.
[opc@arm-gleb-ca ~]$ sudo leapp upgrade --oci ....
It took some time to get all the packages and run the preparation scripts. Then it produced a message signalling that everything is ready for reboot to execute the final part of the upgrade.
... A reboot is required to continue. Please reboot your system. Debug output written to /var/log/leapp/leapp-upgrade.log ...
After reboot don’t be surprised that the instance is not coming back immediately – the upgrade is still running. Eventually it will be back and running the latest version of software and kernel.
And the final step is to run all recommended post upgrade steps listed in the documentation. Don’t postpone it or you might get some surprises in the future. In most cases the upgrade was easy. That was the “Good”. Let’s discuss the “Bad”.
The first issue is related to your installed package and software. It depends on what you have installed on the system but don’t be too surprised when you don’t find your mysql, apache, php and other packages in the system if they were not deployed using standard repositories. You might need to install some of them again. In one of my cases I essentially did full installation of all software set after the upgrade.
The second one might relate to your firewall. The firewalld in Oracle Linux 8 uses by default nftables instead of iptables. You can read about it here. It might not be a problem on a bare metal local box but on Oracle Cloud Infrastructure it can create problems for load balancer backend or general access to some ports. The nftables backend somehow doesn’t work for http and you might need to switch back to iptables. It is not difficult and requires only one setting in the configuration file. You need either replace “FirewallBackend=nftables” to “FirewallBackend=iptables” or, if you don’t have the setting in the file, you add it in the end by adding “FirewallBackend=nftables” and restarting the service.
And finally – the “Cloud”. Let’s ask ourselves if it makes sense to run the in-place upgrade if you are in the cloud. Apart from the issues with firewalls you still need to do a lot of configuration and installation of different rpm after upgrade and you might hit some other issues. From the effort point of view it doesn’t provide too many benefits. If you are using a more or less modern approach and your servers are behind a load balancer , then out of place upgrade might be better suited for the purpose and provide an almost zero-downtime migration. It could be much better to deploy a new stack, copy all your apps to a new host with OL 8 (or the 9 one if you feel adventurous) and then switch connection to the new environment. It will be less impactful for the end users, more reliable and you are not going to get an instance with cloud metadata for OL 7 running OL 8.