Patching Options In Public Cloud – PART 1

How do I patch or upgrade my SUSE instances in the public cloud? How do I keep all my instances at the same patch level in the public cloud? What options are available in the public cloud? Part 1 of this post will try to address some of these questions. Additional options available will be discussed in Part 2.

First, let’s discuss what is available for PAYG instances but not BYOS instances. Included with PAYG instances is access to a highly available and low latency managed software update infrastructure, which allows for high data transfer rates to patch your instance. This comes enabled and ready at instance launch, so you can be assured that the latest packages can be updated or installed. The only part you play in this is to ensure security rules, firewalls, or proxies allow the proper communication from your instance to the public cloud update infrastructure. There’s a blog post that can get you up to speed [1].

For BYOS instances in the public cloud, the SCC (scc.suse.com) is available. The SCC is also a managed software update infrastructure. With a SUSE subscription in hand, you can connect your BYOS instance to the SCC with SUSEConnect [2] to access patches.

Alongside these infrastructures, SUSE also provides the DMS or Distribution Migration System, available for PAYG and BYOS instances, strictly to perform major distribution upgrades from SLE 12 to SLE 15. For details on how to upgrade SLE service packs or perform a major distribution upgrade for public cloud instances, there’s already a blog post for this [3].

The previously discussed managed infrastructures may be perfectly suited to your needs. There’s nothing you need to do except run zypper to install or update packages. But what if you want a little more functionality and flexibility to control which patches are applied based on the date the patch was issued? This is the most common question asked by public cloud customers, and the reaction of surprise to the answer is just as expected. This is absolutely possible with the zypper command.

To demonstrate this functionality, I’ll use a SLES SAP PAYG image. As an example, let’s assume that you will patch all your instances quarterly, with the first being the development environment. The next patch date for development is scheduled for the first week of October, with a patch freeze date of 2020-09-30. This means that all your instances should install patches released up to and including 2020-09-30. Before patching, let’s get an idea of what will be patched. You can find this information by running the command:

zypper lp --date 2020-10-01

Note that the --date will list patches issued up to, but not including the specified date.

The output from this command is:

Repository                         | Name                                       | Category    | Severity  | Interactive | Status   | Summary
-----------------------------------+--------------------------------------------+-------------+-----------+-------------+----------+--------------------------------------------------------------------------------------
SLE-HA12-SP4-Updates               | SUSE-SLE-HA-12-SP4-2020-2642               | recommended | important | ---         | needed   | Recommended update for crmsh
SLE-HA12-SP4-Updates               | SUSE-SLE-HA-12-SP4-2020-2696               | recommended | moderate  | ---         | needed   | Recommended update for crmsh
SLE-HA12-SP4-Updates               | SUSE-SLE-HA-12-SP4-2020-2721               | security    | important | ---         | needed   | Security update for samba
SLE-HA12-SP4-Updates               | SUSE-SLE-HA-12-SP4-2020-2755               | recommended | moderate  | ---         | needed   | Recommended update for pacemaker, sbd
SLE-HA12-SP4-Updates               | SUSE-SLE-HA-12-SP4-2020-2810               | recommended | moderate  | ---         | needed   | Recommended update for lvm2
SLE-Module-Containers12-Updates    | SUSE-SLE-Module-Containers-12-2020-2135    | optional    | low       | ---         | optional | Optional update for python-setuptools
SLE-Module-Public-Cloud12-Updates  | SUSE-SLE-Module-Public-Cloud-12-2020-2135  | optional    | low       | ---         | optional | Optional update for python-setuptools
SLE-Module-Public-Cloud12-Updates  | SUSE-SLE-Module-Public-Cloud-12-2020-2193  | optional    | low       | ---         | optional | Optional update for python-setuptools
SLE-Module-Public-Cloud12-Updates  | SUSE-SLE-Module-Public-Cloud-12-2020-2656  | recommended | moderate  | ---         | needed   | Recommended update for google-guest-agent, google-guest-configs, google-guest-oslogin
SLE-Module-Web-Scripting12-Updates | SUSE-SLE-Module-Web-Scripting-12-2020-2699 | security    | important | ---         | needed   | Security update for python3
SLE-12-SP4-SAP-Updates             | SUSE-SLE-SAP-12-SP4-2020-2699              | security    | important | ---         | needed   | Security update for python3
SLE-12-SP4-SAP-Updates             | SUSE-SLE-SAP-12-SP4-2020-2721              | security    | important | ---         | needed   | Security update for samba
SLE-12-SP4-SAP-Updates             | SUSE-SLE-SAP-12-SP4-2020-2751              | security    | important | ---         | needed   | Security update for libqt5-qtbase
SLE-12-SP4-SAP-Updates             | SUSE-SLE-SAP-12-SP4-2020-2802              | recommended | moderate  | ---         | needed   | Recommended update for mozilla-nss

Considering 14 out of 78 applicable patches:
3 patches optional                                                                                                                                                                                         (use '--with-optional' to include optional patches)
11 patches needed (5 security patches)

This command outputs a patch summary, the patch name, the patch’s category, the severity, interactive, and status of each patch for that instance. This shows that when you do patch, eleven patches will be applied, five security and six recommended patches. The output above shows “3 patches optional”. By default, optional patches with severity level “low” will not be applied unless the –with-optional flag is specified. For this example, we will patch ALL, including optional.

You’re now ready to patch instances. Since you did your homework, you’re prepared for what’s to come. You can expect 14 patches to be applied, and there is no reboot required. If a kernel update was being applied, the “Interactive” field from zypper lp --date 2020-10-01 would show reboot as in this example:

Repository                        | Name                                      | Category    | Severity  | Interactive | Status   | Summary
----------------------------------+-------------------------------------------+-------------+-----------+-------------+----------+-----------------------------------------------
SLE-HA12-SP4-Updates              | SUSE-SLE-HA-12-SP4-2020-2623              | security    | important | reboot      | needed   | Security update for the Linux Kernel

Kick off the patching of the instance:

zypper patch --date 2020-10-01 --with-optional

After patching, nothing else is required except validating the patches didn’t cause any unexpected consequences, which is the whole reason for patching development first. You can even run zypper lp --date 2020-10-01 again to confirm, and it should return that 0 patches are needed.

For more details on the --date and other zypper options, consult the zypper manpage [4].

This post is getting lengthy. So in part 2, I will discuss limitations you should be aware of when performing a SLE 12 to SLE 15 upgrade with the SUSE managed infrastructure approach. I’ll also describe the additional patching options in the public cloud, including hosting your own update infrastructure and SUSE Manager.

[1] https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/
[2] https://www.suse.com/support/kb/doc/?id=000018564
[3] https://www.suse.com/c/upgrading-suse-linux-enterprise-in-the-public-cloud/
[4] man zypper