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

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

Linux

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

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

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

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

בעיות ברשת

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

אם המכונה הווירטואלית לא מצליחה להתחבר לשרת SMT של 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 שמתאימה לאזור של המכונה הווירטואלית ברשימת כתובות ה-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. אם המסלול חסר, מוסיפים אותו בלחיצה על Create Route ומזינים את המידע הנדרש.
אם אתם משתמשים במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, למשל עם תוכנת רשת נוספת של צד שלישי (כמו חומות אש או NAT בהתאמה אישית), אתם צריכים לוודא שמאזן העומסים הוא הצעד הבא בתעבורה של מכונות וירטואליות. כדי לעשות זאת:
1. נכנסים לדף VM instances במסוף Google Cloud .
  
  לדף VM instances
2. לוחצים על שם המכונה הווירטואלית שרוצים לבדוק. הדף VM details ייפתח.
3. בקטע Network interfaces (ממשקי רשת), לוחצים על View details (הצגת פרטים).
4. בקטע Firewall and routes details, מאתרים את המסלול שמגדיר את הנתיב לטווח כתובות ה-IP שנבחר.
5. לוחצים על שם המסלול ומוודאים שמאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי או כתובת ה-IP שלו הם הצעד הבא.
אם אין מסלול שמגדיר את הנתיב לטווח כתובות ה-IP שנבחר, או אם הצעד הבא של המסלול שונה ממאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי, מגדירים את מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי בתור הצעד הבא.
אם אתם משתמשים במאזן עומסי רשת פנימי ב-Passthrough, ודאו שהוא נמצא באותו אזור כמו ה-VM.
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. הכשל הזה יכול להיגרם מהפרות של תעבורת נתונים נכנסת (ingress) או תעבורת נתונים יוצאת (egress) אם לא הגדרתם חריגים ל-SUSE Update Infrastructure במדיניות שלכם ב-VPC-SC.

כדי לפתור את הבעיה, צריך להוסיף את הרכיבים הבאים לרשימת ההיתרים במדיניות VPC-SC, כדי לאפשר למכונה הווירטואלית לתקשר עם 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.