Tips and tricks for OS registration & patching maintenance on SUSE Linux Enterprise Server for SAP

Google Cloud supports various operating systems for your SAP workloads as long as they are certified by SAP.

Depending on the SAP certified OS/DB platform you select, you can run your SAP applications, SAP HANA Database or certified “anyDB” database options on SUSE Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL), Windows Server operating systems and yes, even an IBM AIX OS running on IBM Power CPUs using Google Cloud Power4GCP service.

SLES license types on Google Cloud

If your selected operating system is SLES, there are three different licensing options on Google Cloud. These licensing options are ;

• Pay-As-You-Go (PAYG)
• Bring Your Own Subscription (BYOS)
• Bring Your Own Image (BYOI)

OS Registration

If you are creating new SAP instances on Google Cloud Compute Engine for a green-grass SAP implementation and selecting PAYG method,

OR

If you migrated your current SAP instance images from any different platform (like different cloud provider or your on-premise ) and attached a PAYG license to them ;

Congratulations! Your OS registration should already done and you can check that using these commands below to double check :

You can execute below command using cloud-shell ;

$ gcloud compute instances describe <VM_INSTANCE_NAME> \
 - project <PROJECT_ID> \
 - zone <ZONE_NAME> \
 - format="flattened(disks[].licenses[])"

Example output

Then, execute the SUSEConnect command from your VM instance ;

$ sudo SUSEConnect --status-text

Example output

However, if you decided to proceed with “BYOS” options and bring your own subscription to the Google Cloud, then you will likely see something like below :

Example output

So, you can register your OS either using “yast2” tool and following “Software” → “Software Repositories” with your SUSE registered email and your registration code or executing the below command ;

# SUSEConnect -r <REGISTRATION_CODE> -e <REGISTERED_EMAIL>

Diagnose & Re-Registration

When you are having any kind of problem while registering your SLES operating system, first thing you should be aware of, is this a connectivity or a registration issue?

Connectivity Check

First things first, we need to make sure we don’t have any kind of network connectivity barrier while we are registering or patching our SLES operating system.

Before checking this connectivity, we are going to check this link and find the correct SUSE Subscription Management Tool (SMT) IP addresses for the region that our VM instances are running on.

Then we need to add one of the suitable IP addresses into our /etc/hosts file.

Example output

Now we can check the SSL connectivity to SUSE SMT servers using the command below :

# openssl s_client -connect smt-gce.susecloud.net:443

Example output

However, If you are having issues during the diagnostic actions and want to be sure everything is OK, you can use the susecloud-repocheck script developed by SUSE engineers Rich Paredes and Adam Kaminski.

If you have an outgoing internet connection from your VM instance (with an internet gateway, a Cloud NAT or a private NAT instance) you can directly execute these python script below :

# python3 <(curl -sL https://raw.githubusercontent.com/rfparedes/susecloud-repocheck/main/sc-repocheck.py)

Or, you can download the script itself from the link below and transfer it to your VM instance located into your private subnet.

# wget https://raw.githubusercontent.com/rfparedes/susecloud-repocheck/main/sc-repocheck.py

Then execute the command below where you downloaded the script :

# python3 sc-repocheck.py

This susecloud-repocheck script will check all the connectivity configurations and issues and fix it automatically if needed (For example, if you forget to add SUSE SMT server IP address into the /etc/hosts file, this script can add it automatically).

This script requires an internet connection somehow. You can find more details here.

Troubleshooting for registration and patching issues

General Registration issues

If you are facing any kind of issues like zypper problems, patching problems or you have difficulties while activating an OS module, you can always try to re-register your instance following the steps below :

# registercloudguest –clean
# rm /etc/SUSEConnect
# rm -f /etc/zypp/{repos,services,credentials}.d/*
# rm -f /usr/lib/zypp/plugins/services/*
# sed -i '/^# Added by SMT reg/,+1d' /etc/hosts
# /usr/sbin/registercloudguest --force-new
# zypper ref

You can check the new status of the modules with the command:

# SUSEConnect --status-text –debug

Troubleshooting for networking issues

The compute instances behind the GCP Firewall

There are a couple of options to establish the connection through SUSE SMT servers

• You can “allow” port number 443 from Google Cloud Firewall configuration, if your VM instance has a public IP address. You can use the gcloud command below as an example or take a look at Google Cloud SDK guideline :

# gcloud compute firewall-rules create tcp-rule --allow=tcp:443 \
--source-ranges="<SMT_SERVER_IP>" --description="HTTPS traffic"

• You can use Cloud NAT (Which is highly recommended)
• You can create and configure your own NAT instance.

When your VM Instances use another VM instance as a Virtual DMZ firewall or Virtual Firewall Appliance

You can prefer to use a virtual firewall appliance like Check Point, Fortigate etc.

However, there are few steps you need to consider additionally.

This situation creates an additional DMZ area for your network and all the networking configurations should be double checked carefully before proceeding.

it’s possible to get different errors like below, if you have limited internet access (or your instance located in a private VLAN) on your SLES VM instance and your connection rules are not set correctly.

Error output

So, if you want to register your OS or update the necessary packages, you need to ensure the following configuration has been set :

1. Set the required IP addresses or Ports “allowed” on the Google Cloud Firewall and make sure the connections are flowing successfully through your Virtual Firewall instance before applying additional rules on it.
2. You need to set INGRESS port 443 as ”allowed” for the regional SUSE SMT server IP addresses in your virtual firewall/security appliance.
3. Check your instance /etc/hosts file for the correct SUSE SMT server IP address.

Possible Issues :

No server certificate / No SSL session established

In this case the “# openssl s_client -connect SUSE_SMT_IP:443” command does not show the server certificate or SSL session.

This issue can occur often if communication flows through a virtual security appliance that does the transparent SSL packet inspection.

During this inspection the virtual security appliance or your virtual firewall instance injects its own SSL certificate into the encrypted session.

As a best practice, SLES uses certificate pinning, hence another injected SSL certificate can break the pinning process and If pinning is broken, the SUSE SMT server denies the connection.

It’s also possible to see an SSL error like below during OS registration :

Error output

Solution :

You need to check :

• Is communication allowed through SUSE SMT server IP addresses
• Do SSL packet inspection on the secure connection for the SUSE SMT server IP addresses and add your virtual DMZ firewall appliance’s SSL certificate into your SLES operating system.

ERROR : Self Signed Certificate in Certificate Chain

The below SUSEConnect command can indicate that your SLES OS is not connected to the SUSE SMT Servers :

# SUSEConnect - status-text

Error output

It was intercepted by your virtual security appliance or a transparent proxy where the SSL server side certificate is “CN=decrypt-untrust”.

SUSEConnect is actually an HTTPS client and it does not use client certificates for connecting to the destination server “smt-gce.susecloud.net:443”.

It only uses HTTP basic authentication via the http header “Authorization” and the credentials (username & password) are supplied by the file /etc/zypp/credentials.d/SCCcredentials .

The SSL handshake in that case only requires the client to trust the SSL server certificate. The SUSE SMT server root certificate should be maintained in the PEM bundle file /var/lib/ca-certificates/ca-bundle.pem and you can use the following command to find if the root certificate from SUSE is maintained there:

# certtool -i < /var/lib/ca-certificates/ca-bundle.pem | grep suse-public-cloud@susecloud.net

Possible output

In this situation, SUSE was not a trusted cert authority on your VM and therefore this would not have worked.

Solution :

• You need to allow SUSE as an authority and also add the root certificate for the SMT Server.
• You need to add the root certificate of the SUSE SMT on the virtual firewall/security appliance.
• The SUSE SMT server root certificate should be maintained in the PEM bundle file /var/lib/ca-certificates/ca-bundle.pem and you need to maintain this file accordingly if the correct root certificate is not there.

Unofficial or Non-HTTPS repo check

For any kind of reason you or another system responsible may add non official repositories into the operating system. This might even be inevitable for your environment standards.

And you can oversee these non-HTTPS (mostly HTTP or FTP) repositories while you are managing your security tools or operating systems.

All the patching and OS registration communication between your VM instance and SUSE SMT servers are encrypted and protected by SSL. So, your instance will be safe as long as you use HTTPS/SSL based repositories.

However, if an HTTP or FTP repository is added into your OS repository list you could forget that.

In this kind of situation, you can check the repo-list but you may also want to open this HTTP or FTP connection through a specific public IP address, which may belong to an HTTP/FTP repo server.

There are lots of different possibilities for the repository management and you may want to sniff your compute instance network traffic and understand which IP address need to be whitelisted.

You can use the “tcpdump” utility for this purpose which is already pre-installed on SLES.

If you execute the below command just before “SUSEConnect” commands, it can provide you very useful outputs about the communication with SUSE SMT servers.

# tcpdump -i any -nn "src <LOCAL_IP> and (port 443 or port 80)"

Example output

Here are the explanation :

Source IP (Our beloved SLES OS) sends a SYN or [S] flag to SUSE SMT Servers and waits for the response. SUSE SMT Server sends a response to source IP with an ACK or [.] flag then the data push process starts and is flagged as PUSH or [P].

So, if you see only SYN flags but no ACK flags, that means your Virtual Firewall Appliance or Firewall VM instance somehow blocks this communication and you need to check INGRESS and EGRESS rules and routes.