Accessing SUSE Updates in AWS. When do you need a private repository?

This article applies to customers running on-demand/PAYG instances in AWS deployed from AMIs published by SUSE.

The need to patch.

Patching is an important part of managing any OS infrastructure with updates providing security related enhancements along with stability improvements.  SUSE recommend patching your systems as soon as updates are available.  So where, and how can SUSE instances on the AWS Cloud consume patches?

On-demand customers have two choices, use SUSE’s Public Cloud Update Infrastructure (PCUI) or deploy their own private repository.

SUSE’s Public Cloud Update Infrastructure

The easiest and the default solution is to use the Public Cloud Update Infrastructure (PCUI).  This is a global fleet of update servers maintained by SUSE on the AWS Cloud which provides low latency access to patches from the on-demand instances.   Access to this update infrastructure is provided at no additional cost to the customer.

Customers have the option of connecting to the PCUI either via an internet gateway in a public subnet, nat gateway in a private subnet, or via a local data center.  The outbound firewall and network security need to allow this.

SUSE On-demand instances in AWS will automatically connect to the PCUI on boot.

The following blog [1] investigates the mechanics of this process in more detail.

When might you need to deploy a private repository server?

The second option is to deploy a private repository, this is a customer maintained SUSE solution residing in either the customer VPC on AWS or an “on premises” data center.

This may be needed in several scenarios:

• Add-ons.
  If a SUSE on-demand customer requires additional add-on products from SUSE (e.g. LTSS – Long Term Service Pack Support), where the updates are not provided via the Public Cloud Update Infrastructure.
  In depth detail can be found at the following blog [2]
• Connectivity/Security.
  This is the most common reason, in that the SUSE Instances which require patching have absolutely no outbound connectivity to the internet, by any route. In this example a Private Repository server is used as the proxy and is the only instance with outbound/internet connectivity.  The rest of the SUSE instances can consume patches from this repository.
• Staging.
  When mission critical production workloads need a fixed, curated and consistent set of patches deployed to them, it’s important to deploy a solution to support this.   Both the SCC and PCUI will see the repository manifest change as new updates are released which may lead to inconsistency across the production fleet.  By introducing a private repository that supports staging, production workloads can be kept in a consistent state.  New updates can be tested without impacting production environments.

Private Repository Options

Customers have two options available from SUSE.

SUSE Manager

The recommended option is SUSE Manager. This is more than a local ‘Repository’.  SUSE Manager [3] is a best-in-class Linux management solution designed for enterprise DevOps and IT operations teams. Providing the ability to patch, configure and audit your systems. It also supports staging.

Repository Management Tool (RMT)

RMT  [4] allows customers to build a simple private repository of SUSE Updates and acts as a proxy to the SUSE Customer Center, mirroring new content as it is released.

For customers interested in using AWS Server Manager (SSM), it is possible to use RMT as the patch repository behind this management tool.

How does the private repo mirror patches?

The private repository instance will mirror content from the SUSE Customer Center (SCC) or with the new functionality in SUSE Manager, the Public Cloud Update Infrastructure. Connectivity to the SCC (or Update Infrastructure Servers) can either be via an AWS Internet Gateway in a public subnet or traffic can flow via the customer data center.

It is worth noting that both these solutions connect directly to SUSE’s Customer Center, there are three key prerequisites in order for PAYG customers to be able to connect a private repo to the SCC.

• Outbound connectivity as illustrated above.
• An account in the SUSE Customer Center
• In the case of RMT, SUSE Subscription entitlement needs to exist in the SCC for the products that need to be patched. When needed, customers choose to buy this subscription entitlement and use a BYOS instance as the private repository.
  Exactly what subscriptions are required and how these are purchased depends on which versions of SUSE Linux are running (SLES or SLES for SAP) and which Private Repository Tool is used (SUSE Manager or RMT).
  Customers / partners are welcome to contact their local SUSE Sales Teams for assistance with this.

Connecting instances to the Private Repository.

Customers first need to prepare the on-demand instances for connection to a private Repo   This involves removing a small number of packages and configuration entries.

Remove packages that automate the configuration of the Amazon EC2 instance to connect to the SUSE Public Cloud Update Server.

zypper rm cloud-regionsrv-client

zypper rm regionServiceClientConfigEC2

Remove the /etc/hosts entry for smt-ec2.susecloud.net. The client automation software adds the host file entry for smt-ec2.susecloud.net which is the SUSE Public Cloud Update Server. Since a private repository server is being created, the entry will not be needed.

Remove the following directories before you register your Amazon EC2 instance to your private repository server.

rm /etc/SUSEConnect

rm /etc/zypp/credentials.d/*

rm /etc/zypp/services.d/*

rm /var/lib/cloudregister/*

The links to the documentation for each of the private repository options will document how to register the SUSE instance to the private repository of choice.

SUSE Manager Client Configuration

https://documentation.suse.com/suma/4.2/en/suse-manager/client-configuration/clients-pubcloud.html#_prepare_on_demand_images

RMT (SUSEConnect)

https://documentation.suse.com/sles/15-SP1/single-html/SLES-rmt/index.html#cha-rmt-mirroring

References

[1] https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

[2] https://www.suse.com/c/add-ons-in-the-public-cloud/

[3] https://www.suse.com/products/suse-manager/

[4] https://documentation.suse.com/sles/15-SP1/single-html/SLES-rmt/index.html