Patch Management
Swisscom carries out automatic patching of the Operating System according to the customer-defined patching windows.
New minor releases and security fixes are automatically installed on the VMs during patching.
On Managed RHEL VMs, all packages from the official Red Hat and Swisscom repositories will be updated to the latest available version.
Automated installation of regular hotfixes is carried out after the patches have been assessed internally by Swisscom. Swisscom restarts the VM following installation.
Patching Suspension
Linux patching is explained specifically below. With the Day-2 Suspension function in the Day-2 action Manage Patching Extension, one can suspend the automated patching for up to 120 days, measured from the last time the Operating System was patched. If the last patch installation was longer than 60/120 days ago, it is not possible to suspend the automated patching process without patching the Operating System first. You can use the function On demand patching in the Day-2 action Manage Patching Extension to immediately patch the Operating System. This action can be executed in all states of the VM.
Release Process
| Week | Action |
|---|---|
| Week 0 | Week 0 means the last week of the current patching month/patch cycle. In this week, Swisscom evaluates the latest patches and releases them. These patches are installed on a few dedicated internal VMs to perform functional tests of the patch installation of these patches |
| Week 1 | This is the first patching window you can select on your Managed RHEL VM. Typically, development and test systems are patched in this first window. |
| Week 2 | This is the second patching window you can select on your Managed RHEL VM. It is up to you which VM shall be patched within this window |
| Week 3 | This is the third patching window you can select on your Managed RHEL VM. It is up to you which VM shall be patched within this window |
| Week 4 | This is the fourth patching window you can select on your Managed RHEL VM. It is up to you which VM shall be patched within this window |
With this mechanism, you are free to patch after your individual and specific schedule.
Actions
| Action | Description |
|---|---|
| Patching Window | The desired patching window can be changed with this action. |
| On demand patching | Can be used to patch a Managed RHEL VM immediately. Not possible if the VM has a patching suspension set. |
| Suspension | Can be used to suspend the automated patching process for up to 60 days (measured from the last time the VM was patched). If a VM is currently in patching suspension, the action can be used to disable the suspension. |
Functions/Configuration options
| Properties | Description |
|---|---|
| Patching Window | You define a time window during which the Managed RHEL VM will be patched, e.g "2nd Week Wednesday 02:00 - 04:00": The VM will be patched every month on the second Wednesday of the month between 02:00 - 04:00 (UTC). It is possible to choose between 36 different patching windows. The maintenance window will be kept as short as possible. |
| Emergency Patches | The process for applying emergency patches is performed manually. Emergency patches are installed on the VM outside the maintenance window. We will contact you to define the specifics. But be aware that emergency patches need to be applied within 10 days. In case the 10 days delay can't be kept, the SLAs will be suspended. If the next maintenance window falls within this timeframe, the emergency patch can also be installed during the maintenance window. |
| Server state during patching | During the patching, the Managed RHEL VM will be restarted if necessary. If multiple VMs have the same patching window configured, no guarantee can be given at present as to the sequence in which they will be restarted. |
| Restrictions | Hotfixes may not be installed manually via Internet. The removal of already installed hotfixes is not automated. |
Additional information for Managed RHEL
Swisscom utilizes the Red Hat system management tool Red Hat Satellite to manage patching of Managed RHEL VMs.
The errata from the vendor Red Hat will be synchronized by Swisscom on a weekly basis. Also, the relevant child channels are synchronized (however, updates only concern child channels to a very limited degree)
On the first day of the month, a monthly snapshot of all channels is made, including the child channels. After the internal testing, the snapshot is available for the VMs on the 28th of the month.
At the defined patching window, the available patches will be installed automatically.
The patching will install updates from preconfigured official Red Hat and Swisscom repositories.
The repositories are:
RHEL 7:
Repo Name Repo ID Type Red Hat Enterprise Linux 7 Server (RPMs) rhel-7-server-rpms Official Red Hat repository Red Hat Enterprise Linux 7 Server - Optional (RPMs) rhel-7-server-optional-rpms Official Red Hat repository Red Hat Enterprise Linux 7 Server - Extras (RPMs) rhel-7-server-extras-rpms Official Red Hat repository Red Hat Enterprise Linux 7 Server - Supplementary (RPMs) rhel-7-server-supplementary-rpms Official Red Hat repository Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server rhel-server-rhscl-7-rpms Official Red Hat repository Managed OS Agents RHEL 7 sc-managed-os_esc_managed_os_tools_rhel7 Swisscom repository
RHEL 8:
Repo Name Repo ID Type Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) rhel-8-for-x86_64-baseos-rpms Official Red Hat repository Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) rhel-8-for-x86_64-appstream-rpms Official Red Hat repository Red Hat CodeReady Linux Builder for RHEL 8 x86_64 (RPMs) codeready-builder-for-rhel-8-x86_64-rpms Official Red Hat repository Managed OS Agents RHEL 8 sc-managed-os_esc_managed_os_tools_rhel8 Swisscom repository
RHEL 9:
Repo Name Repo ID Type Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) rhel-9-for-x86_64-baseos-rpms Official Red Hat repository Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) rhel-9-for-x86_64-appstream-rpms Official Red Hat repository Red Hat CodeReady Linux Builder for RHEL 9 x86_64 (RPMs) codeready-builder-for-rhel-9-x86_64-rpms Official Red Hat repository Managed OS Agents RHEL 9 sc-managed-os_esc_managed_os_tools_rhel9 Swisscom repository
Remark: Any packages from other repositories than the one listed above are not automatically patched and must be updated by you (e.g., sc-managed-os_epel_rhel8)
Swisscom recommends that services or applications run by you, are automatically started after a reboot. This can be achieved by using systemd, which is a system and service manager for Linux Operating Systems.
Emergency Patching
The following section describes the handling of so-called "Emergency Patches" in the context of automatic patching of Managed RHEL service. The process for emergency patching is semi-automated in consultation with you.
Definition of emergency patches:
The software vendor defines a severity level for each patch. Emergency patches are those which are judged by the vendor to have the highest severity level.
(https://access.redhat.com/security/updates/classification)
| Severity classification | Description |
|---|---|
| Critical impact | This assessment is for errors that can easily be exploited by a remote, non-authenticated attacker and can affect the Operating System (arbitrary code execution) without requiring interaction with the user. These types of vulnerabilities can be exploited by a worm. Errors that require an authenticated user, a local user, or unlikely configuration are not considered critical. |
Service Management Process:
As soon as the vendor Red Hat publishes an emergency patch, Swisscom will be informed on the corresponding channels. Swisscom in return informs you (about the existing service management processes) that an emergency patch is available and must be installed. The decision when to install an emergency patch is also made via the service management process in consultation with you. The period of time where you can delay the installation of an emergency patch is contractually regulated.