Fehlerbehebung bei der SLES-Pay as you go-Registrierung

In diesem Dokument wird beschrieben, wie Sie Probleme beheben, die auftreten können, wenn Sie Compute Engine-VM-Instanzen mit Pay as you go-SUSE Linux Enterprise Server (PAYG-SLES) mit dem SUSE Subscription Management Tool-Repository (SMT-Repository) verbinden.

Hinweis

  • Prüfen Sie, ob die VM mit einem Dienstkonto verknüpft ist.
  • Achten Sie darauf, dass die Service Metadata API über die VM zugänglich ist.
  • Stellen Sie eine Netzwerkverbindung von der VM zu den jeweiligen Region Servers und SMT Servers her
  • Verwenden Sie das Tool sc-repocheck, um die Probleme automatisch zu beheben.
  • Klicken Sie auf die Schritte, die im Leitfaden zur Fehlerbehebung bei SUSE PAYG beschrieben werden.
  • Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Dienste und APIs von Google Cloud überprüft. Zum Ausführen von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich über die Auswahl einer der folgenden Optionen bei Compute Engine authentifizieren:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Installieren Sie die Google Cloud CLI. Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl: 

      gcloud init

      Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

    2. Set a default region and zone.

Netzwerkprobleme

Nicht aufgelöster Domainname

Die folgenden Probleme können auftreten, wenn die VM keine Verbindung zum SMT-Server smt-gce.susecloud.net herstellen kann:

SUSEConnect error: SocketError: getaddrinfo: Name or service not known

ping: unknown host smt-gce.susecloud.net

Die Ursache dieser Probleme ist in der Regel eine falsche Auflösung des SMT-Server-Domainnamens smt-gce.susecloud.net. Diese Domain kann nicht global aufgelöst werden. Daher müssen Sie die IP-Adresse gemäß der VM-Region festlegen. Gehen Sie dazu so vor:

Prüfen Sie, ob die Datei /etc/hosts einen Eintrag mit der Domain smt-gce.susecloud.net enthält.

cat /etc/hosts | grep -i smt

Die Ausgabe sieht dann ungefähr so aus, aber die IP-Adresse kann abweichen:

# Added by SMT registration do not remove, retain comment as well
108.59.80.221   smt-gce.susecloud.net   smt-gce

Wenn die Datei /etc/hosts nicht dieselben Zeilen wie im vorherigen Beispiel enthält, gehen Sie so vor:

  1. Suchen Sie in der Liste der SUSE SMT-IP-Adressen eine IP-Adresse, die der Region Ihrer VM entspricht.

  2. Bearbeiten Sie die Datei, um die SUSE-SMT-IP-Adresse und alle fehlenden Informationen hinzuzufügen.

Netzwerk nicht verfügbar

Die folgenden Fehler können aufgrund der Nichtverfügbarkeit des Netzwerks auftreten, auch wenn die VM den Domainnamen des Compute Engine Update-Server auflösen kann:

Unexpected exception.
Not ready to read within timeout.

Repository 'SLE-Module-Adv-Systems-Management12-Pool' is invalid.
Repository 'SLE-Module-Adv-Systems-Management12-Updates' is invalid.

Im Folgenden finden Sie einige Beispiele für Fehler, die während der Untersuchung in der Logdatei /var/log/cloudregister auftreten können:

WARNING:Unable to remove client registration from server
WARNING:HTTPSConnectionPool(host='smt-gce.susecloud.net', port=443): Max retries exceeded with url: /connect/systems (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',))

INFO:Region server arguments: ?regionHint=europe-central2
ERROR:No response from: [('34.118.112.80', None), ('34.116.251.218', None), ('34.116.224.144', None)]

Führen Sie einen Netzwerkverbindungstest durch, um mehr über die Ursache des Problems zu erfahren. Das folgende Beispiel zeigt, wie Sie eine HTTPS-Verbindung mit cURL testen:

curl -sSI -m 5 -o /dev/null \
  -w 'Response code (>0 is OK): %{http_code}\n' \
  'https://smt-gce.susecloud.net'

Die Ausgabe des Befehls enthält einen HTTP-Antwortcode oder eine Fehlermeldung. Folgende Antworten und Fehler treten häufig auf:

  • Erfolgreiche Antwort:

    Response code (>0 is OK): 200

  • Zeitüberschreitungsfehler bei Anfrage:

    Response code (>0 is OK): 000
curl: (28) Connection timed out after 5001 milliseconds

  • Nicht lösbarer Domainfehler:

    Response code (>0 is OK): 000
curl: (6) Could not resolve host: smt-gce.susecloud.net

In bestimmten Szenarien, z. B. bei strengen Host-Firewallregeln, ist die mit der Domain smt-gce.susecloud.net verknüpfte Standard-IP-Adresse möglicherweise nicht verfügbar. Führen Sie Netzwerkverbindungstests für alternative regionale Server aus, damit das Problem nicht nur mit der aktuellen IP-Adresse zusammenhängt. So rufen Sie die Liste der regionalen Server ab:

Rufen Sie SUSE WebUI auf, um die Liste der regionalen Updateserver abzurufen.

Verwenden Sie das Tool pint, um die Liste der regionalen Updateserver über die Befehlszeile abzurufen.

  1. Erforderliches Paket installieren

    sudo zypper install python3-susepubliccloudinfo

  2. Verwenden Sie den folgenden Befehl für eine bestimmte Region.

    pint google servers --region us-central1

  3. Eine erfolgreiche Ausgabe enthält eine Liste von Einträgen im XML-Format.

    <?xml version='1.0' encoding='UTF-8'?>
    <servers>
      <server ip="146.148.73.14" name="" region="us-central1" type="regionserver-sles"/>
      <server ip="162.222.182.90" name="" region="us-central1" type="regionserver-sap"/>
      <server ip="108.59.80.221" name="smt-gce.susecloud.net" region="us-central1" type="smt"/>
      <server ip="108.59.85.41" name="smt-gce.susecloud.net" region="us-central1" type="smt"/>
      <server ip="108.59.80.58" name="smt-gce.susecloud.net" region="us-central1" type="smt"/>
    </servers>

Eine vollständige Liste der SUSE-Server-IP-Adressen für Google Cloudfinden Sie in den folgenden Dokumenten:

Eine falsche VM-Konfiguration kann zu einer Nichtverfügbarkeit des Netzwerks führen. Bei Problemen ist es erforderlich, eine Netzwerkdiagnose durchzuführen, um die Ursache zu ermitteln.

Fehler bei der Registrierung

Der folgende Fehler kann auftreten, wenn Sie VMs mit einer privaten IP-Adresse in Cloud NAT haben:

ERROR:  Registration failed: Registering system to registration proxy https://smt-gce.susecloud.net
command '/usr/bin/zypper --non-interactive refs Python_3_Module_x86_64' failed
Error: zypper returned 4 with 'Problem retrieving the repository index file for service 'Python_3_Module_x86_64':
Timeout exceeded when accessing 'https://smt-gce.susecloud.net/services/2045/repo/repoindex.xml?credentials=Python_3_Module_x86_64'.

Prüfen Sie zur Behebung dieses Problems Ihre Cloud NAT-Konfiguration und vergewissern Sie sich, dass Sie den Parameter Mindestanzahl an Ports pro VM-Instanz auf mindestens 256 festgelegt haben.

Weitere Informationen finden Sie im SUSE Support-Bulletin Registrierung und Zypper fehlgeschlagen für Compute Engine-Instanzen hinter Cloud NAT.

Keine Antwort

Wenn Ihre VM Probleme bei der Kommunikation mit den Update- und Regionsservern hat, können die folgenden Fehler auftreten:

  • SUSEConnect-Fehler:

    SUSEConnect error: Errno::ETIMEDOUT: Connection timed out - connect(2) for "smt-gce.susecloud.net" port 443

  • zypper-Fehler:

    Error retrieving metadata for 'SLE-Module-Adv-Systems-Management12-Pool':
Not ready to read within timeout.
...

Diese Fehler können auftreten, wenn Update- und Regionsserver nicht reagieren. Um festzustellen, ob dies der Fall ist, prüfen Sie die Logs /var/log/cloudregister auf ähnliche Inhalte:

INFO:Region server arguments: ?regionHint=europe-central2
INFO:Using API: regionInfo
INFO:Region server arguments: ?regionHint=europe-central2
INFO:Getting update server information, attempt 1
INFO:   Using region server: 130.211.242.136
ERROR:  No response from: 130.211.242.136
INFO:   Using region server: 35.187.193.56
ERROR:  No response from: 35.187.193.56
INFO:   Using region server: 162.222.182.90
ERROR:  No response from: 162.222.182.90
INFO:   Using region server: 130.211.88.88
ERROR:  No response from: 130.211.88.88
ERROR:  None of the servers responded
ERROR:  Attempted: [IPv4Address('130.211.242.136'), IPv4Address('35.187.193.56'), IPv4Address('162.222.182.90'), IPv4Address('130.211.88.88')]
...
...
...
ERROR:Request not answered by any server after 3 attempts
ERROR:Exiting without registration

Versuchen Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

  • Prüfen Sie, ob die VM eine externe IP-Adresse hat oder ob das Virtual Private Cloud-Subnetz eine NAT verwendet (entweder Cloud NAT oder benutzerdefinierte Lösung).

  • Wenn Sie die Standardregeln für das Netzwerkrouting geändert haben, z B. den Zugriff auf den öffentlichen Internetzugriff beschränken oder Traffic über ein lokales Netzwerk weiterleiten, fügen Sie Routen für SMT-IP-Adressen manuell über das Standardgateway von Compute Engine hinzu. Gehen Sie dazu so vor:

    1. Rufen Sie in der Google Cloud Console- die Seite „Routen” auf.

      Zur Seite „Routen”

    2. Suchen Sie im Tab Routenverwaltung nach einer Route, die die SUSE-SMT-IP-Adressen enthält, und prüfen Sie, ob das Compute Engine-Standardgateway als nächster Hop festgelegt ist.

    3. Wenn die Route fehlt, können Sie sie hinzufügen. Klicken Sie dazu auf Route erstellen und geben Sie die erforderlichen Informationen ein.

  • Wenn Sie einen internen Passthrough-Network Load Balancer verwenden, z. B. mit zusätzlicher zwischengeschalteter Netzwerksoftware (z. B. Firewalls oder benutzerdefinierte NATs), muss der Load Balancer als nächster Hop für VM-Traffic verwendet werden. Gehen Sie dazu so vor:

    1. Rufen Sie in der Google Cloud -Console die Seite VM-Instanzen auf.

      Zur Seite „VM-Instanzen”

    2. Klicken Sie auf den Namen der VM, den Sie prüfen möchten. Die Seite mit den VM-Details wird geöffnet.

    3. Klicken Sie im Bereich Netzwerkschnittstellen auf Details ansehen.

    4. Suchen Sie im Abschnitt Firewall- und Routendetails die Route, die den Pfad zum ausgewählten IP-Adressbereich definiert.

    5. Klicken Sie auf den Namen der Route und prüfen Sie, ob der interne Passthrough-Network Load Balancer oder seine IP-Adresse der nächste Hop ist.

    Wenn es keine Route gibt, die den Pfad zum ausgewählten IP-Adressbereich definiert, oder wenn der nächste Hop der Route ein anderer ist als der interne Passthrough-Network Load Balancer, dann richten Sie den internen Passthrough-Network Load Balancer als nächsten Hop ein.

  • Wenn Sie einen internen Passthrough-Network Load Balancer verwenden, prüfen Sie, ob er sich in derselben Region wie die VM befindet.

    1. Rufen Sie in der Google Cloud -Console die Seite VM-Instanzen auf.

      Zur Seite „VM-Instanzen”

    2. Suchen Sie die VM, die Sie prüfen möchten, und notieren Sie sich die Region.

    3. Öffnen Sie in der Google Cloud -Console die Seite Load-Balancing.

      Zur Seite „Load-Balancing“

    4. Suchen Sie den verwendeten internen Passthrough-Network Load Balancer und prüfen Sie, ob er sich in derselben Region wie die VM befindet.

    5. Wenn sich die VM und der interne Passthrough-Network Load Balancer nicht in derselben Region befinden, aktivieren Sie den globalen Zugriff.

Registrierung hinter Proxys

Es kann zu Problemen kommen, wenn Ihre VMs nicht transparente Proxys oder andere Software verwenden, die eine Man-in-the-Middle-Prüfung (PITM) durchführt, z. B. Barracuda CloudGen Firewall oder Palo Alto. Das folgende Beispiel zeigt einen Versuch, SLES über einen HTTP-Proxy zu registrieren.

ERROR: Baseproduct registration failed
ERROR: Registering system to registration proxy https://smt-gce.susecloud.net

Announcing system to https://smt-gce.susecloud.net ...
SUSEConnect error: Net::HTTPFatalError: 503 "Service Unavailable"

SUSE unterstützt die SLES-Registrierung hinter PITM-Proxys (Person-in-the-Middle) und nicht transparenten Proxys in Compute Engine nicht offiziell. PITM-Proxykonfigurationen schlagen während der Registrierung aufgrund von Certificate Pinning fehl.

Wir empfehlen, eine Cloud NAT-Konfiguration zu verwenden oder einen benutzerdefinierten SMTP-Server einzurichten.

Verstoß gegen VPC Service Controls

Wenn Ihre Organisation VPC Service Controls (VPC-SC) verwendet, schlägt die Registrierung möglicherweise fehl und Sie sehen möglicherweise eine Request is prohibited by organization's policy-Fehlermeldung. Dieser Fehler kann durch Verstöße bei eingehendem oder ausgehendem Traffic verursacht werden, wenn Sie in Ihrer VPC-SC-Richtlinie keine Ausnahmen für die SUSE Update Infrastructure konfiguriert haben.

Fügen Sie die folgenden Komponenten einer Zulassungsliste in Ihrer VPC-SC-Richtlinie hinzu, damit die VM mit der SUSE Update Infrastructure kommunizieren kann, um dieses Problem zu beheben:

  • Infrastrukturprojekt aktualisieren: Suse-gce-smt (Projektnummer: 778092048372)
  • Dienstkonto: 778092048372@project.gserviceaccount.com
  • Erforderliche Methode: compute.alpha.InstancesService.GetLicenses

Probleme mit der Betriebssystemkonfiguration

Unbekannter Registrierungsstatus

Wenn Sie nicht wissen, ob Ihr PAYG-SUSE Linux Enterprise Server (SLES) registriert ist, führen Sie den folgenden Befehl aus:

sudo SUSEConnect --status-text

Die Ausgabe enthält den Versions- und Registrierungsstatus der SUSE-Produkte, einschließlich SUSE Linux Enterprise Server.

Installed Products:
------------------------------------------

  SUSE Linux Enterprise Server 12 SP5
  (SLES/12.5/x86_64)

  Registered

------------------------------------------
...

Wenn der Status Not Registered lautet, registrieren Sie die VM neu, um das Problem zu beheben:

sudo registercloudguest --force-new

Wenn die Produktverknüpfung auf eine falsche Produktdatei verweist, können die folgenden Fehler auftreten:

2020-06-17 12:03:56,124 ERROR:Unable to obtain product information from server "108.59.85.41,None"
        Unprocessable Entity
        {"type":"error","error":"Unmet product dependencies, activate one of these products first: SUSE Linux Enterprise Server 12 x86_64, SUSE Linux Enterprise Server for SAP Applications 12 x86_64, SUSE Linux Enterprise Server 12 SP1 x86_64, ...","localized_error":"..."}
Unable to register modules, exiting.

Dieser Fehler tritt auf, wenn der symbolische Link /etc/products.d/baseproduct auf eine falsche Produktdatei (z. B. sle-module-toolchain.prod) verweist.

Aktualisieren Sie zum Beheben dieses Problems den Symlink unter /etc/products.d/baseproduct so, dass er auf die entsprechende Basisproduktdatei verweist:

  1. Rufen Sie das Verzeichnis /etc/products.d auf:

      cd /etc/products.d

  2. Führen Sie den folgenden Befehl aus und ersetzen Sie dabei SLES.prod durch SLES_SAP.prod, wenn Sie SLES für SAP installiert haben:

      sudo ln -sf SLES.prod baseproduct

Nicht verfügbare Informationen zur Instanzidentität

Wenn für die VM keine Informationen zur Instanzidentität verfügbar sind, können die folgenden Fehler auftreten. Dieses Problem kann auftreten, wenn kein Dienstkonto an die Instanz angehängt ist oder das angehängte Dienstkonto deaktiviert wurde.

ERROR:Data collected from stderr for instance data collection "b'Unable to access instance identity information\n'"

Für den Zugriff auf die Instanzmetadaten für Identitätstokens müssen alle VMs ein zugehöriges Dienstkonto haben.

Weitere Informationen finden Sie unter Public Cloud Infrastructure-Update.

Führen Sie den folgenden Befehl auf der VM aus, um den Status des Dienstkontos der VM zu prüfen:

curl -s -H 'Metadata-Flavor: Google' \
  'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=test'

Beispiel für eine erfolgreiche Antwort mit einem Identitätstoken:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjkzOTd0MDQxSHQ2NDNxNzkzUjY1MDIwNzEyMjZPNnppaTdqNTl3eTciLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJ0ZXN0IiwiYXpwIjoiMjY1MDIwMDUyMzgzMjYyNTk0ODU2IiwiZXhwIjoxNjgzNzEyNTQzLCJpYXQiOjE2ODM3MTI4NjQsImlzcyI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbSIsInN1YiI6IjQ1NjA2MzQ5MDg5Mzc0Njg3ODI5NyJ9.EpzQ3NZ8mKStdpH10fL34qsKG0rjQEflzvLJLm2tVNX4xBJAkMhi8lcs5InUEY-QMK3njgbzdzNtD1fXoIfKoeWsqkA8vG3NkBz5zqRrtaB2STcO14H5tjIdTBsrCtET447tRXlGG5cvgMcWnRDZG92-jUZEpWki_Ri4T69X5-bBWkfE2Thm3oSUW4fScdeVOEmOgWnzD2jeVqQ_2YniywvpkT-rLzKfN-5AgN66zgBfXqJVTC90KFMebfiaOoL7z6ZSM9AjZGf45QEMZjxjd-Xzyee6ZWK8s0RE3hJlytb3zYcLt3tJwQ1WhnrC2ToJ-ZmKxxK3xKDLCvCQ6Ny5to

Wenn die VM nicht betroffen ist, erhalten Sie ein Token. Wenn die VM betroffen ist, sind die zurückgegebenen Metadaten eine Fehlermeldung wie die folgende:

{
  "error": "invalid_request",
  "error_description": "Service account not enabled on this instance"
}

So beheben Sie das Problem:

  1. Beenden Sie die VM:

    gcloud compute instances stop VM_NAME

  2. Fügen Sie der VM ein Dienstkonto hinzu:

    gcloud compute instances set-service-account VM_NAME \
  --service account SERVICE_ACCOUNT \
  --no-scopes

  3. Starten Sie die VM:

    gcloud compute instances start VM_NAME

  4. Führen Sie nach dem Hinzufügen des fehlenden Dienstkontos den folgenden Befehl über die VM aus, um SLES noch einmal zu registrieren:

    sudo registercloudguest --force-new

Erforderliche Pakete fehlen

Die Registrierung kann fehlschlagen, wenn auf Ihrer VM wichtige Pakete wie cloud-regionsrv-client, regionServiceClientConfigGCE, cloud-netconfig-gce oder suseconnect-ng fehlen.

Installieren Sie die erforderlichen Pakete, bereinigen Sie die Registrierungsdateien und registrieren Sie die VM neu, um dieses Problem zu beheben.

  1. Installieren Sie alle fehlenden Pakete.

    sudo zypper install PACKAGE_NAME

    Ersetzen Sie PACKAGE_NAME durch den Namen des fehlenden Pakets.

  2. Bereinigen Sie alte Registrierungsdateien:

    sudo registercloudguest --clean
sudo SUSEConnect --cleanup
sudo rm -f /etc/zypp/credentials.d/*
sudo rm -f /etc/zypp/repos.d/*
sudo rm -f /etc/zypp/services.d/*

  3. Registrieren Sie die VM neu:

    sudo registercloudguest --force-new

Wenn Sie registercloudguest ausführen und der Fehler ModuleNotFoundError: No module named 'requests' angezeigt wird, kann ein falscher symbolischer Link /usr/bin/python3 die Ursache sein, z. B. wenn Sie ihn manuell überschrieben haben.

Traceback (most recent call last):
File "/usr/sbin/registercloudguest", line 34, in <module>
import requests
ModuleNotFoundError: No module named 'requests'

Um dieses Problem zu beheben, erstellen Sie den symbolischen Link neu, damit er auf die richtige Python-Version verweist.

  1. Prüfen Sie die installierte Python-Version auf der Instanz:

    sudo zypper info python3

  2. Prüfen Sie den symbolischen Link python3:

    ls -ll /usr/bin | grep -i python3

  3. Wenn der Link falsch ist, entfernen Sie ihn und erstellen Sie einen neuen Link, der auf die richtige Python-Version verweist (z. B. python3.6):

    sudo rm /usr/bin/python3
sudo ln -sf /usr/bin/python3.6 /usr/bin/python3

Überprüfung des SSL-Zertifikats fehlgeschlagen

Wenn Zertifikatsdateien im Verzeichnis /etc/pki/trust/anchors fehlen, werden möglicherweise Fehler wie Curl error 60 oder ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] angezeigt. Hier ein detaillierteres Beispiel für einen Fehler, der in /var/log/cloudregister angezeigt werden kann:

Traceback (most recent call last):
 File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 677, in urlopen
 ...
 File "/usr/lib64/python3.6/ssl.py", line 689, in do_handshake
 self._sslobj.do_handshake()
 ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)

Mit dem folgenden Befehl können Sie prüfen, ob Zertifikatsdateien fehlen. Wenn die Ausgabe leer ist, fehlen die Dateien:

ls -lart /etc/pki/trust/anchors

Die Ausgabe sollte leer sein, wenn Zertifikate fehlen:

total 0

Führen Sie einen der folgenden Optionen aus, um dieses Problem zu beheben:

  • Option 1: Bereinigen und neu registrieren

    Entfernen Sie alle Dateien, die mit der Registrierung verknüpft sind, und erzwingen Sie dann eine neue Registrierung. Beim Registrierungsprozess werden die erforderlichen Zertifikate von den regionalen Servern heruntergeladen.

    sudo registercloudguest --clean && \
  sudo SUSEConnect --cleanup && \
  sudo rm -f /etc/zypp/credentials.d/* && \
  sudo rm -f /etc/zypp/repos.d/* && \
  sudo rm -f /etc/zypp/services.d/* && \
  sudo rm -f /etc/pki/trust/anchors/* && \
  sudo sed -i '/^# Added by SMT reg/,+1d' /etc/hosts && \
  sudo registercloudguest --force-new

  • Option 2: Zertifikate aus einer funktionierenden Instanz kopieren

    Wenn das Problem durch Bereinigen und erneutes Registrieren nicht behoben wird, können Sie die Zertifikatsdateien von einer funktionierenden Instanz mit gcloud compute scp kopieren oder das Bootlaufwerk einer funktionierenden Instanz an die fehlerhafte Instanz anhängen.

    Wenn Sie das Laufwerk einer funktionierenden Instanz unter MOUNT_PATH anhängen und bereitstellen, führen Sie die folgenden Befehle aus:

    sudo cp MOUNT_PATH/etc/pki/trust/anchors/* /etc/pki/trust/anchors/
sudo update-ca-certificates
sudo cp -pr MOUNT_PATH/usr/lib/regionService /usr/lib/regionService
sudo registercloudguest --force-new

Inkompatibilität von libzypp-Paketen

Die Registrierung einer PAYG-SUSE-VM mit SLES für SAP 15 schlägt möglicherweise mit einem Fehler ähnlich dem folgenden fehl:

ERROR:Baseproduct registration failed
Registering system to registration proxy https://smt-gce.susecloud.net
...
command '/usr/bin/zypper --non-interactive refs SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64' failed
Error: zypper returned 1 with 'Error occurred while setting download (curl) options for 'https://smt-gce.susecloud.net/services/2294?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64':
Unexpected exception.
Unknown error reading from 'plugin:/susecloud?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64&path=/services/2294'
...
- Error occurred while setting download (curl) options for 'https://smt-gce.susecloud.net/services/2294?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64':

Dieses Problem kann auftreten, wenn durch ein Update des libzypp-Pakets eine inkompatible Version des libcurl4-Pakets zurückbleibt. Wenn libzypp versucht, sich selbst zu aktualisieren, kann es libcurl4 nicht mehr verwenden, um Anfragen an Paketstandorte zu senden.

Aktualisieren Sie das libzypp-Paket manuell, um dieses Problem zu beheben. Der folgende Befehl ist ein Beispiel. Möglicherweise müssen Sie die Versionsnummer anpassen:

sudo rpm -i libzypp-17.31.31-150400.3.52.2.x86_64.rpm

Nicht unterstützte Betriebssystemversion oder veraltete Pakete

Wenn Sie eine Betriebssystemversion verwenden, die nicht mehr im allgemeinen Supportzeitraum liegt, z. B. SLES 12 SP4, für die der allgemeine Support am 30. Juni 2020 endete, kann die Registrierung fehlschlagen. Dieser Fehler kann auftreten, weil veraltete Pakete auf der VM nicht mit der SUSE-Updateinfrastruktur kommunizieren können. Möglicherweise werden in der Logdatei /var/log/cloudregister Fehler zu nicht erreichbaren IP-Adressen angezeigt, auch wenn die Netzwerkverbindung teilweise erfolgreich zu sein scheint (z. B. wenn die Verwendung von telnet für SMT-Server einen 403 Forbidden-Fehler zurückgibt).

Wenn Sie prüfen möchten, ob Pakete veraltet sind, können Sie sich die Installationsdaten ansehen. Pakete, die seit über einem Jahr nicht aktualisiert wurden, sind möglicherweise veraltet. Mit dem folgenden Befehl können Sie die letzte Aktualisierungszeit für ein Paket prüfen:

rpm -qa --qf '%{NAME}-%{VERSION} : %{INSTALLTIME:date}\n' | grep PACKAGE_NAME

Führen Sie ein Upgrade auf eine unterstützte SLES-Version durch, um dieses Problem zu beheben. Möglicherweise müssen Sie auch bestimmte Pakete aktualisieren, wie in den SUSE Technical Information Documents (TIDs) beschrieben.