Mastering Azure Update Manager – Part 3
In Part 2 we saw how we can onboard machines at scale to Azure Update Manager by using Azure Policy. Further we saw how we can create alerts for the update process.
In this part I will focus on how to updating SUSE Linux Enterprise by using the Azure Update Manager.
- How Azure SLES VMs access the Public Cloud Update Infrastructure
- Determine configured repositories on SUSE Linux Enterprise Server (SLES)
- Disable Bring Your Own Subscription (BYOS) for SLES Azure VMs
- Determine Updates on SUSE Linux Enterprise Server (SLES)
- Zypper Locks
- Reset Repositories and SUSEConnect
- Links
How Azure SLES VMs access the Public Cloud Update Infrastructure
SUSE provides public cloud customers with PAYG (Pay-As-You-Go) images on AWS, Azure, and GCP.
Instances created from these images and Bring Your Own Subscription (BYOS) is disabled as shown below connect to a managed update infrastructure.
So if you need to update your instances with the latest software updates or install that needed package using zypper, usually you can be assured that the underlying repositories are there with no further hassles.
There are exceptions, though. Instances configured to utilize a proxy server or traverse firewalls, NAT gateways, proxies, security rules, Zscalar, or other security and network devices may run into problems.
The update infrastructure is a collection of “servers” accessible over the public internet which provide information or software repositories for SLE (SUSE Linux Enterprise) PAYG instances.
At least three update servers serve a given region per cloud provider for high availability and low latency with high data transfer rates.
To properly configure your environment to access the update infrastructure, it’s important to understand what happens during the instance’s initial registration.
First, the instance needs to find out what update servers to use. It does this by contacting a region server over port 443 (HTTPS).
It only needs to successfully query one of the region servers listed in the regionsrv parameter in /etc/regionserverclnt.cfg.
To see this process I was starting a new capture by using tshark.
In my case the virtual machine SLES15-SP5-VM01 was contacting the first public IP address 23.100.36.229 and the 191.237.254.253 listed in /etc/regionserverclnt.cfg as region server as shown in the WireShark capture when triggering an assessment in Azure Update Manager.
About how to capture traffic on SLES by using WireShark resp. tshark, you will find in my following post.
Assuming the instance successfully communicated with one of the region servers, it now knows the three update server IPs for its region.
The next step in the registration process is to connect to the update servers over port 443 (HTTPS).
As long as the /etc/regionserverclnt.cfg contains parameter httpsOnly = true the client communicates over port 443 (HTTPS). If this parameter is not present or not set to true, communication will occur over port 80 (HTTP). Update to latest cloud-regionsrv-client for httpsOnly functionality.
The update server that responds first is selected, and a host record added to /etc/hosts resolving smt-<PROVIDER>.susecloud.net to the selected update server’s IP address.
SMT ==> Subscription Management Tool
This record is added locally because it will not be publicly resolvable. This is an important point because some proxy, firewall, or other devices expect to be able to resolve this hostname publicly to an IP address.
After the host record is added, the instance will import the certificate from the update server into /usr/share/pki/trust/anchors and then run update-ca-certificates. This certificate will then be used to create an encrypted session between the instance and the update server.
This is when customers run into problems with a MITM proxy or similar device. The certificate from the update servers cannot be intercepted and replaced or the session will fail.
Finally, if all communication passes and there are no unexpected issues, the registration completes with all repositories being made available to the instance. Be aware that the registration process all depends on the metadata server at 169.254.169.254 being available.
This address should be excluded from being proxied.
The IP address 169.254.169.254 is a well-known, non-routable metadata service endpoint used by many cloud providers to provide instance metadata to virtual machines (VMs) and services running in the cloud.
The Azure Instance Metadata Service (IMDS) provides information about currently running virtual machine instances. You can use it to manage and configure your virtual machines. This information includes the SKU, storage, network configurations, and upcoming maintenance events. For a complete list of the data available, see the Endpoint Categories Summary.
IMDS is a REST API that’s available at a well-known, non-routable IP address (169.254.169.254). You can only access it from within the VM. Communication between the VM and IMDS never leaves the host. Have your HTTP clients bypass web proxies within the VM when querying IMDS.
Source: https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=windows
The log file /var/log/cloudregister can also be consulted to ascertain what IP addresses the instance is attempting to communicate with.
In case you run into issues where your instance cannot establish a connection to the Public Cloud Update Infrastructure, you will find more information under the following link.
Source: https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/
When we have enabled Bring Your Own Subscription (BYOS) for our SLES OS as shown here,
we need to move from the cloud update infrastructure to one of three options that provide software updates and patches to those virtual machines:
- SUSE Manager
- SUSE Repository Mirroring Tool
- SUSE Customer Center
Below I was registering the virtual machine to the SUSE Customer Center (SCC).
Therefore the required endpoints to update the OS are different than when using the PAYG (Pay-As-You-Go) licenses from Azure and shown further above.
This just to keep in mind to allow traffic to any endpoints required to update your SLES OS.
Determine configured repositories on SUSE Linux Enterprise Server (SLES)
The VM below is registered by Azure to the SUSE Customer Center (SCC) which is the default behavior when BYOS is disabled for the virtual machine in Azure.
The SUSE Customer Center (SCC) is a web-based portal provided by SUSE for managing software subscriptions, system registrations, updates, and support. It serves as a central hub for organizations to manage their SUSE Linux Enterprise systems and related services.
Repositories are added to SLES automatically when a system is registered to the SUSE Customer Center (SCC), SUSE Manager, or SMT/RMT.
To determine the registration status we can use the following command.
# SUSEConnect --status-text
When the VM is registered by Azure (BYOS is disabled) to the SCC, the repository URL is always plugin:/susecloud?……….
plugin:/susecloud is a dynamic mechanism in SUSE Linux that helps configure cloud-specific repositories or modules based on the deployment environment. It simplifies the integration of SUSE systems with public cloud platforms like Azure, AWS, or Google Cloud.
plugin:/susecloud is likely a placeholder repository URL that automatically adjusts to the cloud provider (e.g., AWS, Azure, Google Cloud).
Below the SLES15-SP5-VM1 which was registered by hand to the SCC and BYOS was enabled during provisioning in Azure.
# SUSEConnect --status-text
More about how to register manually the OS and your subscription to the SUSE Customer Center (SCC), you will find in my following post.
Disable Bring Your Own Subscription (BYOS) for SLES Azure VMs
We can change the licensing for our SLES virtual machines below under Settings -> Operating system.
When disabling BYOS for SLES, we also need to execute the following commands below to enable
Register a SUSE Linux Enterprise instance with the closest, in most cases region local, SUSE operated update infrastructure. The client will reach out to a so called region server to obtain information about the closest update servers.
The information about how to find any one of the region servers running in a given cloud framework is built into the image that contains the registercloudguest executable.
The information of the update servers is cached to aid with HA fail-over if one of the update servers is
unreachable. The system is registered with the first responsive update server.Source: https://github.com/SUSE-Enceladus/cloud-regionsrv-client/blob/master/man/man1/registercloudguest.1
# SUSEConnect --cleanup # registercloudguest --force-new # zypper refresh
The defined repositories will change immediately to the plugin:/susecloud?…… URLs.
Determine Updates on SUSE Linux Enterprise Server (SLES)
To determine installed updates on our SLES OS we can use the zypper command.
Zypper is a command-line package manager for installing, updating and removing packages. It can also be used to manage repositories.
Further above we already used the zypper lr command to list the available repositories on SLES. We can also display the priority of the repository by executing.
SLES will prefer to install packages from the repository with the highest priority.
# zypper lr -P
By using the following command we will get a detailed log of all package installations, updates, and removals.
# more /var/log/zypp/history
To determine if new updates are available we can use the zypper update command but finally not continue to install them by enter n.
# zypper update
More about the zypper command you will also find in my following post.
Zypper Locks
The message “The following items are locked and will not be changed by any action” when executing the zypper update command indicates that some packages have been locked (held) to prevent updates, downgrades, or removal. This is typically done to maintain stability, avoid unwanted updates, or for troubleshooting purposes.
To see which packages are locked, run:
# zypper locks
Plymouth is a graphical boot system and logger for Red Hat Enterprise Linux 7, which makes use of the kernel-based mode setting (KMS) and Direct Rendering Manager (DRM).
Plymouth
also handles user interaction during boot.
If you want to remove the lock on specific packages so they can be updated, use:
# zypper removelock <package_name>
If you want to prevent specific packages from being updated (for example, to lock them again after unlocking), use:
# zypper addlock <package_name>
Reset Repositories and SUSEConnect
When switching from PAYG (pay-as-you-go subscription models) to BYOS aka Azure Hybrid Benefit (AHB)
BYOS virtual machines needs to use move the cloud update infrastructure to one of three options that provide software updates and patches to those virtual machines:
- SUSE Repository Mirroring Tool
- SUSE Customer Center
- SUSE Manager
# zypper removerepo -all # zypper refresh --services # SUSEConnect --cleanup
When switching from BYOS aka Azure Hybrid Benefit (AHB) to PAYG (pay-as-you-go subscription models)
When disabling BYOS for SLES, we also need to execute the following commands below.
# SUSEConnect --cleanup # registercloudguest --force-new # zypper refresh
Remove specific Repo
# zypper removerepo <repo_alias_or_number> # zypper removerepo 56
Links
Managing Software with Command Line Tools
https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-sw-cl.htmlTroubleshoot connectivity and registration issues for SUSE Linux Enterprise Server VMs
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/suse-public-cloud-connectivity-registration-issuesAccessing the Public Cloud Update Infrastructure via a Proxy
https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/SUSE Manager Server 5.0
https://www.suse.com/releasenotes/x86_64/SUSE-MANAGER/5.0/index.html