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

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:


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

Source: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/suse-public-cloud-connectivity-registration-issues#action-4-force-registration


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.

Source: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/plymouth


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:


# 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.html

Troubleshoot 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-issues

Accessing 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