‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות ברישום ל-SLES בתשלום לפי שימוש

Linux

במאמר הזה מוסבר איך לפתור בעיות שעלולות להתרחש כשמתחברים למכונות וירטואליות (VM) של Compute Engine שמריצות SUSE Linux Enterprise Server ‏(SLES) עם תשלום לפי שימוש (PAYG) למאגר SUSE Subscription Management Tool ‏ (SMT).

לפני שמתחילים

מוודאים שלמכונה הווירטואלית משויך חשבון שירות.
מוודאים שאפשר לגשת אל Service Metadata API מהמכונה הווירטואלית.
מוודאים שיש קישוריות ברשת מהמכונה הווירטואלית אל השרתים האזוריים ושרתי ה-SMTP המתאימים
אפשר להשתמש בכלי sc-repocheck כדי לפתור את הבעיות באופן אוטומטי.
כדאי לעיין בשלבים שמפורטים במדריך פתרון בעיות ב-SUSE PAYG.
אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:
צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:
המסוף

כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud
gcloud
1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:
  gcloud init
  אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
  
  הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם מותקנת הגרסה העדכנית.
הגדרת אזור ותחום כברירת מחדל

בעיות ברשת

שם הדומיין לא ניתן לפתרון

יכול להיות שתיתקלו בבעיות הבאות אם המכונה הווירטואלית לא מצליחה להתחבר לשרת ה-SMTP‏ smt-gce.susecloud.net:

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

ping: unknown host smt-gce.susecloud.net

הסיבה לבעיות האלה היא בדרך כלל רזולוציה שגויה של שם הדומיין של שרת ה-SMTP‏ smt-gce.susecloud.net. אי אפשר לפתור את הבעיה בדומיין הזה באופן גלובלי, ולכן צריך להגדיר את כתובת ה-IP שלו בהתאם לאזור של המכונה הווירטואלית. לשם כך, צריך לבצע את הפעולות הבאות:

בודקים את הקובץ /etc/hosts ומוודאים שהוא מכיל רשומה עם הדומיין smt-gce.susecloud.net.

cat /etc/hosts | grep -i smt

הפלט אמור להיראות כך, אבל כתובת ה-IP עשויה להיות שונה:

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

אם הקובץ /etc/hosts לא מכיל את אותן שורות כמו בדוגמה הקודמת, צריך לבצע את הפעולות הבאות:

מחפשים כתובת IP שמתאימה לאזור של מכונת ה-VM ברשימת כתובות ה-IP של SUSE SMT.
עורכים את הקובץ כדי להוסיף את כתובת ה-IP של SUSE SMT וכל מידע אחר שחסר.

הרשת לא זמינה

יכול להיות שתיתקלו בשגיאות הבאות בגלל שהרשת לא זמינה, גם אם המכונה הוירטואלית יכולה לפתור את שם הדומיין של שרת העדכון של Compute Engine:

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.

ריכזנו כאן כמה דוגמאות לשגיאות שאולי יופיעו בקובץ היומן /var/log/cloudregister במהלך הבדיקה:

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)]

כדי לקבל מידע נוסף על הגורם לבעיה, מבצעים בדיקה של קישוריות הרשת. בדוגמה הבאה מוצג אופן הבדיקה של חיבור HTTPS באמצעות cURL:

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

הפלט של הפקודה מכיל קוד תגובת HTTP או הודעת שגיאה. אלה תשובות ושגיאות נפוצות:

תגובה מוצלחת:
```
Response code (>0 is OK): 200
```

שגיאה – הזמן הקצוב לתפוגת הבקשה הסתיים:

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

שגיאה בדומיין שלא ניתן לפתור:

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

בתרחישים מסוימים, כמו כללים מחמירים של חומת אש במארח, יכול להיות שכתובת ה-IP שמוגדרת כברירת מחדל ומשויכת לדומיין smt-gce.susecloud.net לא תהיה זמינה. כדי לוודא שהבעיה לא קשורה רק לכתובת ה-IP הנוכחית, צריך לבדוק את קישוריות הרשת לשרתים אזוריים חלופיים. אחזור רשימת השרתים האזוריים:

כדי לקבל את רשימת השרתים האזוריים לעדכונים, עוברים אל SUSE WebUI.

משתמשים בכלי pint כדי לקבל את רשימת שרתי העדכון האזוריים באמצעות CLI.

התקנת החבילה הנדרשת

sudo zypper install python3-susepubliccloudinfo

משתמשים בפקודה הבאה עם אזור ספציפי
```
pint google servers --region us-central1
```

פלט מוצלח מכיל רשימה של רשומות בפורמט XML

<?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>

כדי למצוא את הרשימה המלאה של כתובות ה-IP של שרתי SUSE עבור Google Cloud, אפשר לעיין במסמכים הבאים:

הגדרה שגויה של מכונה וירטואלית עלולה לגרום לכך שהרשת לא תהיה זמינה. אם נתקלתם בבעיות, כדאי לבצע אבחון רשת כדי לזהות את שורש הבעיה.

הרישום נכשל

יכול להיות שתיתקלו בשגיאה הבאה אם יש לכם מכונות וירטואליות עם כתובת IP פרטית ב-Cloud NAT:

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'.

כדי לפתור את הבעיה, צריך לבדוק את ההגדרה של Cloud NAT ולוודא שהפרמטר minimum ports per VM instance מוגדר לערך של 256 לפחות.

מידע נוסף זמין בעדכון התמיכה של SUSE בנושא ההרשמה ו-zypper נכשלו במופעים של Compute Engine מאחורי Cloud NAT.

אין תשובה

אם יש בעיות בתקשורת של מכונת ה-VM עם שרתי העדכון והאזור, יכול להיות שיופיעו השגיאות הבאות:

שגיאה בתהליך SUSEConnect:

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

שגיאה בתהליך zypper:

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

השגיאות האלה יכולות להתרחש כששרתי העדכון והאזור לא מגיבים. כדי לבדוק אם זה המצב, צריך לעיין ביומנים של /var/log/cloudregister ולחפש תוכן דומה:

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

כדי לפתור את הבעיה, אפשר לנסות אחד או יותר מהפתרונות הבאים:

מוודאים שלמכונה הווירטואלית יש כתובת IP חיצונית או שרשת המשנה של הענן הווירטואלי הפרטי (VPC) משתמשת ב-NAT (או Cloud NAT או פתרון בהתאמה אישית).
אם שיניתם את כללי הניתוב של הרשת שמוגדרים כברירת מחדל, למשל הגבלת הגישה לאינטרנט הציבורי או ניתוב התנועה דרך רשת מקומית, צריך להוסיף מסלולים באופן ידני לכתובות ה-IP של SMT דרך שער ברירת המחדל של Compute Engine, באופן הבא:
1. נכנסים לדף Routes במסוף Google Cloud .
  
  כניסה לדף Routes
2. בכרטיסייה Route Management (ניהול נתיבים), מחפשים נתיב שכולל את כתובות ה-IP של SUSE SMT ומוודאים ששער ברירת המחדל של Compute Engine מוגדר כנקודת הניתוב הבאה.
3. אם המסלול חסר, מוסיפים אותו על ידי לחיצה על יצירת מסלול והזנת המידע הנדרש.
אם אתם משתמשים במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, למשל עם תוכנת רשת נוספת של צד שלישי (כמו חומות אש או NAT בהתאמה אישית), אתם צריכים לוודא שמאזן העומסים הוא הצעד הבא בתעבורה של מכונות וירטואליות. כדי לעשות זאת:
1. נכנסים לדף VM instances במסוף Google Cloud .
  
  לדף VM instances
2. לוחצים על שם המכונה הווירטואלית שרוצים לבדוק. ייפתח הדף VM details (פרטי המכונה הווירטואלית).
3. בקטע ממשקי רשת, לוחצים על הצגת הפרטים.
4. בקטע Firewall and routes details, מאתרים את המסלול שמגדיר את הנתיב לטווח כתובות ה-IP שנבחר.
5. לוחצים על השם של המסלול ומוודאים שמאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי או כתובת ה-IP שלו הם הניתוב הבא.
אם אין מסלול שמגדיר את הנתיב לטווח כתובות ה-IP שנבחר, או אם הצעד הבא במסלול שונה ממאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, צריך להגדיר את מאזן העומסים הפנימי להעברת סיגנל ללא שינוי כצעד הבא.
אם אתם משתמשים במאזן עומסים פנימי מסוג Network Load Balancer, ודאו שהוא נמצא באותו אזור כמו המכונה הווירטואלית.
1. נכנסים לדף VM instances במסוף Google Cloud .
  
  לדף VM instances
2. מאתרים את המכונה הווירטואלית שרוצים לבדוק ורושמים את האזור שלה.
3. נכנסים לדף Load balancing במסוף Google Cloud .
  
  לדף Load balancing
4. מאתרים את מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי שבו נעשה שימוש ובודקים אם הוא נמצא באותו אזור כמו המכונה הווירטואלית.
5. אם המכונה הווירטואלית ומאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי לא נמצאים באותו אזור, צריך להפעיל גישה גלובלית.

הרשמה מאחורי שרתי Proxy

יכול להיות שתיתקלו בבעיה אם המכונות הווירטואליות שלכם משתמשות בשרתי proxy לא שקופים או בתוכנות אחרות שמבצעות בדיקה של אדם באמצע (PITM) (לדוגמה, Barracuda CloudGen Firewall, ‏ Palo Alto). בדוגמה הבאה מוצג ניסיון לרשום את SLES באמצעות שרת proxy מסוג HTTP.

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 לא תומכת רשמית ברישום של SLES מאחורי שרתי proxy מסוג person-in-the-middle ‏ (PITM) ושרתי proxy לא שקופים ב-Compute Engine. הגדרות של שרת proxy מסוג PITM נכשלות במהלך הרישום בגלל הצמדת אישורים.

מומלץ להשתמש בהגדרת Cloud NAT או להגדיר שרת SMTP בהתאמה אישית.

הפרה של VPC Service Controls

אם בארגון שלכם משתמשים ב-VPC Service Controls (VPC-SC), יכול להיות שההרשמה תיכשל ותוצג לכם הודעת השגיאה Request is prohibited by organization's policy. הכשל הזה יכול להיגרם מהפרות של תעבורת נכנסת או יוצאת אם לא הגדרתם חריגים ל-SUSE Update Infrastructure במדיניות שלכם בנושא VPC-SC.

כדי לפתור את הבעיה, צריך להוסיף את הרכיבים הבאים לרשימת ההיתרים במדיניות של VPC-SC כדי לאפשר למכונת ה-VM לתקשר עם SUSE Update Infrastructure:

עדכון פרויקט תשתית: Suse-gce-smt (מספר פרויקט: 778092048372)
חשבון שירות: 778092048372@project.gserviceaccount.com
שיטה נדרשת: compute.alpha.InstancesService.GetLicenses

בעיות בהגדרת מערכת ההפעלה

סטטוס הרישום לא ידוע

אם אתם לא יודעים אם שרת SUSE Linux Enterprise Server‏ (SLES) בתשלום לפי שימוש (PAYG) שלכם רשום, מריצים את הפקודה הבאה:

sudo SUSEConnect --status-text

הפלט מכיל את הגרסה ואת סטטוס הרישום של מוצרי SUSE, כולל SUSE Linux Enterprise Server.

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

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

  Registered

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

אם הסטטוס הוא Not Registered, צריך לרשום מחדש את המכונה הווירטואלית כדי לפתור את הבעיה:

sudo registercloudguest --force-new

קישור סמלי שגוי למוצר הבסיס

יכול להיות שתיתקלו בשגיאות הבאות אם הקישור למוצר הבסיס מצביע על קובץ מוצר שגוי:

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.

השגיאה הזו מתרחשת כשהקישור הסמלי /etc/products.d/baseproduct מצביע על קובץ מוצר שגוי (לדוגמה, sle-module-toolchain.prod).

כדי לפתור את הבעיה, צריך לעדכן את הקישור הסמלי בנתיב /etc/products.d/baseproduct כך שיצביע על קובץ המוצר הבסיסי המתאים:

מנווטים לספרייה /etc/products.d
```
  cd /etc/products.d
```
אם התקנתם SLES for SAP, מריצים את הפקודה הבאה ומחליפים את SLES.prod ב-SLES_SAP.prod:
```
  sudo ln -sf SLES.prod baseproduct
```

המידע על זהות המופע לא זמין

יכול להיות שתיתקלו בשגיאות הבאות אם פרטי הזהות של המופע לא זמינים למכונה הווירטואלית. הבעיה הזו יכולה לקרות אם חשבון שירות לא מצורף למופע, או אם חשבון השירות המצורף הושבת.

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

כדי לגשת למטא-נתונים של המכונה בשביל אסימוני זהות, לכל המכונות הווירטואליות צריך להיות משויך חשבון שירות.

מידע נוסף זמין במאמר עדכון בנושא תשתית ענן ציבורי.

כדי לבדוק את הסטטוס של חשבון השירות של המכונה הווירטואלית, מריצים את הפקודה הבאה במכונה הווירטואלית:

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

דוגמה לתגובה מוצלחת עם אסימון זהות:

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

אם המכונה הווירטואלית לא מושפעת, תקבלו אסימון. אם המכונה הווירטואלית מושפעת, המטא-נתונים שמוחזרים הם הודעת שגיאה שדומה להודעה הבאה:

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

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

מפסיקים את ה-VM:
```
gcloud compute instances stop VM_NAME
```
מוסיפים חשבון שירות למכונה הווירטואלית:
```
gcloud compute instances set-service-account VM_NAME \
  --service account SERVICE_ACCOUNT \
  --no-scopes
```
הערה: הדגל --no-scopes מסיר את כל ההיקפים מהמכונה הווירטואלית. אם לא מציינים דגל להיקף הגישה, המערכת מקצה היקפים שמוגדרים כברירת מחדל לחשבון השירות של מופע Compute, או שחשבון השירות שומר על ההיקפים הנוכחיים שלו.
מפעילים את ה-VM:
```
gcloud compute instances start VM_NAME
```
אחרי שמוסיפים את חשבון השירות החסר, מריצים את הפקודה הבאה מהמכונה הווירטואלית כדי לרשום מחדש את SLES:
```
sudo registercloudguest --force-new
```

חסרות חבילות נדרשות

הרישום עלול להיכשל אם במכונה הווירטואלית חסרים חבילות חיוניות כמו cloud-regionsrv-client, regionServiceClientConfigGCE, cloud-netconfig-gce או suseconnect-ng.

כדי לפתור את הבעיה, צריך להתקין את החבילות הנדרשות, לנקות את קובצי הרישום ולרשום מחדש את מכונת ה-VM.

מתקינים את החבילות החסרות.
```
sudo zypper install PACKAGE_NAME
```
מחליפים את PACKAGE_NAME בשם החבילה החסרה.

פינוי קובצי רישום ישנים:

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/*

רושמים מחדש את ה-VM:
```
sudo registercloudguest --force-new
```

קישור סימבולי שגוי של python3

אם מריצים את הפקודה registercloudguest ומופיעה השגיאה ModuleNotFoundError: No module named 'requests', יכול להיות שהגורם לכך הוא /usr/bin/python3 קישור סמלי שגוי, למשל אם החלפתם אותו באופן ידני.

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

כדי לפתור את הבעיה, צריך ליצור מחדש את הקישור הסמלי כך שיצביע על גרסת Python הנכונה.

מאשרים את גרסת Python שמותקנת במופע:
```
sudo zypper info python3
```
בודקים את הקישור הסימבולי python3:
```
ls -ll /usr/bin | grep -i python3
```
אם הקישור שגוי, מסירים אותו ויוצרים קישור חדש שמפנה לגרסת Python הנכונה (לדוגמה, python3.6):
```
sudo rm /usr/bin/python3
sudo ln -sf /usr/bin/python3.6 /usr/bin/python3
```

האימות של אישור ה-SSL נכשל

אם חסרים קבצים של אישורים בספרייה /etc/pki/trust/anchors, יכול להיות שיוצגו שגיאות כמו Curl error 60 או ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]. הנה דוגמה מפורטת יותר לשגיאה שמופיעה ב-/var/log/cloudregister:

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)

כדי לוודא שחסרים קובצי אישורים, מריצים את הפקודה הבאה ומוודאים שהפלט ריק:

ls -lart /etc/pki/trust/anchors

הפלט צריך להיות ריק אם חסרים אישורים:

total 0

כדי לפתור את הבעיה, אפשר לנסות אחת מהאפשרויות הבאות:

אפשרות 1: ניקוי והרשמה מחדש

מפנים את כל הקבצים שמשויכים להרשמה, ואז מבצעים הרשמה חדשה. במהלך תהליך ההרשמה, המערכת מורידה את האישורים הנדרשים משרתי האזור.

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

אפשרות 2: העתקת אישורים ממופע פעיל

אם ניקוי ורישום מחדש לא פותרים את הבעיה, אפשר להעתיק את קובצי האישורים ממופע תקין באמצעות gcloud compute scp או על ידי צירוף דיסק האתחול של מופע תקין למופע שנכשל.

אם מצרפים וטוענים את הדיסק של מופע פעיל ב-MOUNT_PATH, מריצים את הפקודות הבאות:
```
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
```

חוסר תאימות לחבילת libzypp

יכול להיות שמכונה וירטואלית של SUSE בתשלום לפי שימוש עם SLES for SAP 15 לא תירשם ותציג שגיאה דומה לזו שמופיעה בהמשך:

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':

הבעיה הזו יכולה לקרות כשעדכון לחבילת libzypp משאיר גרסה לא תואמת של חבילת libcurl4. כש-libzypp מנסה לעדכן את עצמו, הוא כבר לא יכול להשתמש ב-libcurl4 כדי לשלוח בקשות למיקומי חבילות.

כדי לפתור את הבעיה, צריך לעדכן ידנית את חבילת libzypp. הפקודה הבאה היא דוגמה, ויכול להיות שתצטרכו לשנות את מספר הגרסה:

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

גרסת מערכת הפעלה לא נתמכת או חבילות מיושנות

אם אתם מריצים גרסה של מערכת הפעלה שנמצאת מחוץ לתקופת התמיכה הכללית שלה – לדוגמה, SLES 12 SP4, שהתמיכה הכללית בה הסתיימה ב-30 ביוני 2020 – יכול להיות שההרשמה תיכשל. הכשל הזה יכול לקרות כי חבילות לא עדכניות במכונה הווירטואלית לא יכולות לתקשר עם תשתית העדכון של SUSE. יכול להיות שתראו שגיאות לגבי כתובות IP שלא ניתן להגיע אליהן בקובץ היומן /var/log/cloudregister, גם אם נראה שקישוריות הרשת הצליחה באופן חלקי (לדוגמה, אם שימוש ב-telnet בשרתי SMTP מחזיר שגיאה 403 Forbidden).

כדי לבדוק אם חבילות הן מיושנות, אפשר לראות את תאריכי ההתקנה שלהן. יכול להיות שחבילות שלא עודכנו במשך יותר משנה לא מעודכנות. כדי לבדוק את זמן העדכון האחרון של חבילה, משתמשים בפקודה הבאה:

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

כדי לפתור את הבעיה, צריך לשדרג לגרסת SLES נתמכת. יכול להיות שתצטרכו גם לעדכן חבילות ספציפיות כמו שמתואר במסמכי מידע טכני (TID) של SUSE.