Condividi tramite

Risolvere i problemi di connettività e registrazione per le macchine virtuali SUSE Linux Enterprise Server

Si applica a: ✔️ macchine virtuali Linux

Questo articolo illustra un problema in cui viene configurata una macchina virtuale (VM) di Microsoft Azure usando un'immagine SUSE Linux Enterprise Server (SLES), ma la macchina virtuale non può connettersi al repository SMT (SUBSCRIPTION Management Tool) SUSE. Questo articolo fornisce alcuni passaggi di base per la risoluzione dei problemi e le azioni da eseguire per scenari specifici, ad esempio gli errori nello strumento da riga di comando di Zypper per la gestione dei pacchetti in SUSE. Gli specialisti Linux di Microsoft hanno assemblato queste informazioni in base all'esperienza di supporto e alla documentazione di SUSE.

È importante leggere l'output di ogni comando per altri indizi. È consigliabile salvare i risultati e i messaggi per ulteriori operazioni di risoluzione dei problemi.

Prerequisiti

Nota

Se la macchina virtuale SLES si trova dietro un server proxy, è consigliabile esaminare le considerazioni tecniche illustrate in Accesso all'infrastruttura di aggiornamento del cloud pubblico tramite un proxy. Per le macchine virtuali SLES in Azure, si applicano le condizioni seguenti:

  • La connessione ai server di aggiornamento da una macchina virtuale SLES si basa sulla risoluzione del nome host che non può essere risolta dai server DNS pubblici. Di conseguenza, alcune implementazioni del server proxy Linux/Unix potrebbero richiedere di inserire manualmente un record in /etc/hosts sul lato server proxy in modo che il nome "smt-azure" possa essere risolto.

    Ecco un record di esempio:

    52.165.88.13 smt-azure.susecloud.net smt-azure

    Gli indirizzi IP disponibili variano in base all'area di Azure. Per altre informazioni, vedere l'elenco di indirizzi IP in questo file XML smt.

  • Gli indirizzi IP 168.63.129.16 e 169.254.169.254 usati dal servizio metadati dell'istanza (IMDS) devono ignorare l'accesso proxy. Non è possibile accedere a questi indirizzi IP speciali tramite un server proxy e le macchine virtuali SLES necessitano di informazioni da IMDS per riconoscere l'ambiente cloud in cui sono in esecuzione e per trovare un server di aggiornamento SUSE appropriato.

    Ad esempio, la NO_PROXY variabile in /etc/sysconfig/proxy deve essere configurata in macchine virtuali SLES, ad esempio:

    NO_PROXY="localhost, 127.0.0.1, 168.63.129.16, 169.254.169.254"

Elenco di controllo per la risoluzione dei problemi

Passaggio 1: Eseguire uno script di diagnostica del repository

Eseguire lo script di controllo del repository SUSEcloud fornito da Rich Paredes, un tecnico SUSE. Questo script Python esegue le attività seguenti:

  1. Verificare la connettività ai repository del cloud pubblico SUSE.

  2. Provare a risolvere eventuali problemi esistenti.

  3. Creare un archivio di log nella /var/log/ directory e denominarlo sc-repocheck_<YYMMDD_hhmmss>.tar.xzq. Questo log può essere utile se i problemi di connessione o registrazione persistono.

Per avviare lo script, eseguire il comando seguente per trasferire lo script dal relativo percorso GitHub all'interprete Python:

sudo python3 <(curl --location --silent https://raw.githubusercontent.com/rfparedes/susecloud-repocheck/main/sc-repocheck.py)

Per eseguire correttamente, il comando richiede l'accesso a Internet dalla macchina virtuale. In caso contrario, è necessario scaricare prima lo script e quindi modificare il comando in modo che venga eseguito.

Passaggio 2: Controllare la connettività agli indirizzi IP del server sulla porta 443

La macchina virtuale deve essere in grado di aprire una connessione TCP sulla porta 443 al server smt-azure.susecloud.net di repository SUSE (in base all'area in cui si trova la macchina virtuale) insieme ai server di area. L'elenco di indirizzi IP per il server repository e i server di area sono disponibili nelle posizioni seguenti.

Tipo di indirizzo IP URL contenente l'elenco di indirizzi IP
Indirizzi IP del server SMT per tutte le aree https://susepubliccloudinfo.suse.com/v1/microsoft/servers/smt.xml
Indirizzi IP del server di area https://susepubliccloudinfo.suse.com/v1/microsoft/servers/regionserver.xml

Per controllare le connessioni del server del repository e del server di area per l'area, usare il comando OpenSSL s_client per i client Secure Sockets Layer (SSL) e Transport Layer Security (TLS). Inserire l'indirizzo IP appropriato per il segnaposto nella sintassi seguente:

sudo openssl s_client -connect <IP address>:443

Dopo aver eseguito questo comando, viene visualizzato il certificato del server. Il comando avvia anche una connessione SSL appropriata.

L'esempio seguente mostra l'output del comando riuscito per il server di repository SUSE nell'area Stati Uniti orientali 2 (codice percorso: eastus2, indirizzo IP: 20.186.112.116):

$ echo "" | openssl s_client -connect 20.186.112.116:443

CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 C = DE, ST = Bavaria, L = Nuremberg, O = SUSE, OU = CSM, CN = SUSE, emailAddress = suse-public-cloud@susecloud.net
verify return:1
depth=0 C = DE, ST = Bavaria, L = Nuremberg, O = SUSE, OU = Public Cloud, CN = Update server certificate (smt-azure.susecloud.net), emailAddress = suse-public-cloud@susecloud.net
verify return:1
---
Certificate chain
 0 s:C = DE, ST = Bavaria, L = Nuremberg, O = SUSE, OU = Public Cloud, CN = Update server certificate (smt-azure.susecloud.net), emailAddress = suse-public-cloud@susecloud.net
   i:C = DE, ST = Bavaria, L = Nuremberg, O = SUSE, OU = CSM, CN = SUSE, emailAddress = suse-public-cloud@susecloud.net
---
Server certificate
-----BEGIN CERTIFICATE-----
<64-character lines of printable ASCII characters>
    .
    .
    .
-----END CERTIFICATE-----
subject=C = DE, ST = Bavaria, L = Nuremberg, O = SUSE, OU = Public Cloud, CN = Update server certificate (smt-azure.susecloud.net), emailAddress = suse-public-cloud@susecloud.net

issuer=C = DE, ST = Bavaria, L = Nuremberg, O = SUSE, OU = CSM, CN = SUSE, emailAddress = suse-public-cloud@susecloud.net

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2538 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

Nota

Per esaminare l'ambito di supporto di diverse versioni di SUSE, vedere SUSE Lifeycle.

Scenario 1: non viene visualizzato alcun certificato server o sessione SSL

L'output non mostra il certificato server o la sessione SSL.

Causa

Questo scenario si verifica in genere quando il comando attraversa un'appliance virtuale di rete (NVA) che esegue l'ispezione dei pacchetti SSL. Questa ispezione fa sì che l'appliance virtuale di rete inserisca il proprio certificato SSL nella sessione crittografata.

Poiché SUSE usa l'aggiunta di certificati, un altro certificato SSL inserito può interrompere l'operazione di aggiunta. Se l'associazione è interrotta, il repository SUSE nega la connessione.

Risoluzione

Assicurarsi che l'appliance virtuale di rete non eseeseguono le operazioni seguenti:

  • Bloccare l'accesso agli indirizzi IP del repository SUSE
  • Eseguire l'ispezione dei pacchetti SSL sulla connessione sicura ai repository SUSE
  • Inserire il certificato SSL dell'appliance virtuale di rete nel server

Scenario 2: Problemi del client cloud-regionsrv-client e errori di registrazione

Per diagnosticare questo scenario, controllare lo stato del pacchetto installato dalla cronologia cloud-regionsrv-client di Zypper o dall'elenco dei pacchetti RPM installati:

  • Dalla cronologia di Zypper:

    sudo grep cloud-region /var/log/zypp/history

    2021-07-12 08:20:49 cloud-regionsrv-client.rpm installed ok

  • Dall'elenco dei pacchetti RPM installati:

    sudo rpm -qa | grep cloud-region

    cloud-regionsrv-client-9.1.5-6.43.1.noarch
cloud-regionsrv-client-plugin-azure-1.0.1-6.43.1.noarch

Il pacchetto client principale deve essere almeno la versione 10.x.

Come illustrato nell'esempio, se si ritenta la registrazione manuale o si usa il controllo repository nel passaggio 1, l'output seguente viene visualizzato in /var/log/cloudregister:

sudo tail /var/log/cloudregister

2025-01-29 20:20:05,876 INFO:Using API: regionInfo
2025-01-29 20:20:05,981 INFO:Region server arguments: ?regionHint=northcentralus
2025-01-29 20:20:05,981 INFO:Getting update server information, attempt 1
2025-01-29 20:20:05,981 INFO:   Using region server: 104.45.31.195
2025-01-29 20:20:06,184 ERROR:  No response from: 104.45.31.195
2025-01-29 20:20:06,184 INFO:   Using region server: 23.100.36.229
2025-01-29 20:20:06,286 ERROR:  No response from: 23.100.36.229
2025-01-29 20:20:06,286 INFO:   Using region server: 52.187.53.250
2025-01-29 20:20:06,915 INFO:No current registration server set.
2025-01-29 20:20:06,917 ERROR:No response from: [('23.101.171.119', '2603:1030:603::2e9'), ('23.101.164.199', '2603:1030:603::625'), ('23.96.231.74', '2603:1030:603::2e6')]

L'output indica che esiste un errore di connettività. Tuttavia, questa indicazione non è vera. Si verifica perché il processo di gestione degli errori negli script di registrazione non mostra gli errori del certificato dalle librerie precedenti.

L'output dello script potrebbe anche indicare erroneamente che non è possibile trovare un certificato per uno degli indirizzi IP SMT visualizzati nell'output del sudo tail /var/log/cloudregister comando. Questo problema è anche un problema di libreria, ma non influisce sull'elenco CA nella macchina virtuale.

Causa

Se le istanze non vengono aggiornate regolarmente, possono diventare incompatibili con l'API dell'infrastruttura di aggiornamento. Questa situazione causa un errore dei repository necessari per aggiornare un'istanza di .

Risoluzione

  1. Creare una istanza PAYG usando lo stesso sistema operativo come quello con i repository interrotti.

  2. Creare una directory temporanea:

    sudo mkdir -p /root/packages/rpms

  3. Scaricare i pacchetti seguenti in base alle versioni SLES della macchina virtuale interessata:

    SLES 12

    sudo zypper --pkg-cache-dir /root/packages/ download cloud-regionsrv-client cloud-regionsrv-client-plugin-azure regionServiceClientConfigAzure python3-azuremetadata python3-cssselect python3-lxml python3-M2Crypto python3-zypp-plugin python3-dnspython suseconnect-ruby-bindings suseconnect-ng

    SLES 15

    sudo zypper --pkg-cache-dir /root/packages/ download cloud-regionsrv-client cloud-regionsrv-client-plugin-azure regionServiceClientConfigAzure python3-azuremetadata suseconnect-ng python3-cssselect python3-toml python3-lxml python3-M2Crypto python3-zypp-plugin python3-dnspython libsuseconnect suseconnect-ruby-bindings docker docker-bash-completion runc containerd libcontainers-common bash-completion

  4. Eseguire i comandi seguenti:

    sudo find /root/packages/ -type f -name "*.rpm" -exec cp {} /root/packages/rpms/ \;
sudo cd /root/packages
sudo tar -czvf suse-public-registration.tgz rpms

  5. Trasferimento suse-public-registration.tgz all'istanza interrotta:

    sudo scp /root/packages/suse-public-registration.tgz user@targetip:/tmp

    Nota

    Sostituire user e targetip in base alle esigenze.

  6. Accedere all'istanza interrotta per estrarre e installare i pacchetti:

    sudo cd tmp
sudo tar xvfz suse-public-registration.tgz
sudo cd rpms
sudo zypper --no-refresh --no-remote --non-interactive install --force *.rpm

  7. Registrare di nuovo la macchina virtuale:

    sudo registercloudguest --force-new

Per altre informazioni, vedere Repository dell'istanza cloud non riuscita a causa di pacchetti obsoleti.

Scenario 3: Problemi generali di registrazione

Causa

La macchina virtuale ha credenziali non aggiornate per l'accesso al repository o si ricevono messaggi che indicano che il sistema non viene registrato dopo aver tentato di eseguire aggiornamenti o installazioni.

Risoluzione

Per risolvere la maggior parte dei problemi di registrazione, specificare la combinazione del comando di pulizia SUSEConnect e del comando registercloudguest usando il force-new parametro :

sudo SUSEConnect --cleanup
sudo registercloudguest --force-new

Nota

Se la macchina virtuale è SLES SAP, è anche possibile eseguire il comando usando il nome del prodotto SAP SLES:

  1. Eseguire il SUSEConnect comando per ottenere lo stato di registrazione corrente, incluso il nome del prodotto SAP SLES: 
    sudo SUSEConnect --url https://smt-azure.susecloud.net --status-text
  2. Eseguire il SUSEConnect comando usando il nome del prodotto per attivare il prodotto: 
    sudo SUSEConnect --url https://smt-azure.susecloud.net --product <SLES-SAP-product-name>

Se questi comandi hanno esito negativo, pulire tutte le informazioni sul repository e quindi provare a registrare la macchina virtuale. Tutti i messaggi di errore correlati ai certificati e ad altri componenti dovrebbero scomparire. Eseguire i comandi seguenti:

sudo SUSEConnect --cleanup
sudo rm /etc/zypp/{credentials,services,repos}.d/*
sudo rm --force --recursive /var/cache/zypp/*
sudo rm /var/lib/cloudregister/*
sudo registercloudguest --force-new

Infine, verificare lo stato di registrazione della macchina virtuale eseguendo di nuovo SUSEConnect:

sudo SUSEConnect --status

Nell'output del comando JSON cercare una "status":"Registered" voce.

Scenario 4: Nessun dato attestato fornito (422)

Dopo aver eseguito lo script di diagnostica del repository, è possibile che venga visualizzata la voce di errore seguente quando lo script tenta di risolvere i problemi che influiscono su zypper update:

Error: Activating SLES_SAP 12.5 x86_64 ... Error: Registration server returned 'Instance verification failed: No attested data supplied' (422)

Causa

Le macchine virtuali non possono connettersi ai repository SUSE a causa di pacchetti cloud pubblici SUSE obsoleti.

Risoluzione

  1. Eseguire di nuovo lo script di diagnostica del repository.

  2. Se l'errore "422" persiste, modificare il /etc/regionserverclnt.cfg file di configurazione in modo che corrisponda al testo seguente:

    [server]
api = regionInfo
certLocation = /var/lib/regionService/certs
regionsrv = 23.100.36.229,40.121.202.140,52.187.53.250,104.45.31.195,191.237.254.253

[instance]
dataProvider = /usr/bin/azuremetadata --api latest --subscriptionId --billingTag --attestedData --signature --xml
instanceArgs = msftazure
httpsOnly = true

  3. Registrare nuovamente la macchina virtuale:

    sudo registercloudguest --force-new

Scenario 5: errori per determinati moduli durante il tentativo di registrazione nei repository SUSE

Quando si tenta di registrare la macchina virtuale nei repository SUSE, vengono visualizzate le voci di errore seguenti in /var/log/cloudregister:

2024-01-31 19:22:44,947 INFO:Registration: /usr/sbin/SUSEConnect --url https://smt-azure.susecloud.net --product sle-module-legacy/12/x86_64 --instance-data /var/cache/cloudregister/0fc8a276-273c-4bd9-838d-6a2a41a637b0
2024-01-31 19:22:45,492 ERROR:  Registration failed: SUSEConnect error: Downloading https://smt-azure.susecloud.net/repo/SUSE/Products/SLE-Module-Legacy/12/x86_64/product.license/directory.yast failed (code: 401): <html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.21.5</center>
</body>
</html>

Causa

Il problema è causato da un bug nella versione 1.4.0 del suseconnect-ng pacchetto.

Questi errori si verificano solo nei moduli seguenti:

  • sle-module-legacy
  • sle-module-web-scripting
  • sle-module-hpc
  • sle-sdk

Risoluzione

  1. Spostare i file seguenti dalla /etc/products.d cartella alla /tmp cartella :

    • sle-module-hpc.prod
    • sle-module-legacy.prod
    • sle-module-web-scripting.prod
    • sle-sdk.prod
    sudo cd /etc/products.d 
sudo mv sle-module-hpc.prod sle-module-legacy.prod sle-module-web-scripting.prod sle-sdk.prod /tmp

  2. Registrare la macchina virtuale nei repository SUSE:

    sudo registercloudguest --force-new

    Registration should now be successful.

  3. Aggiornare la cache del repository:

    sudo zypper ref -s

  4. Aggiornare il suseconnect-ng pacchetto alla versione 1.6.0 o successiva, se necessario:

    Nota

    Per verificare la versione di suseconnect-ng, eseguire il comando seguente:

    sudo  rpm -q suseconnect-ng

     suseconnect-ng-1.4.0~git0.b0f7c25bfdfa-3.3.8.x86_64

    sudo zypper up suseconnect-ng

  5. Dopo suseconnect-ng l'aggiornamento, ripristinare i file di definizione del modulo in /etc/products.d:

    sudo cd /tmp  
sudo mv sle-module-hpc.prod sle-module-legacy.prod sle-module-web-scripting.prod sle-sdk.prod /etc/products.d

  6. Rieseguire la registrazione nei repository:

    sudo registercloudguest --force-new

    Registration Successful

Scenario 6: La registrazione ha esito negativo e viene visualizzato l'errore "WARNING:Found unknown entry in credentials file "system_token="" (Avviso:Trovato voce sconosciuta nel file di credenziali "system_token=""

Un messaggio di avviso "Trovato voce sconosciuta nel file di credenziali 'system_token='" viene registrato nel log e la macchina virtuale non può eseguire la /var/log/cloudregister registrazione nei repository cloud pubblici SUSE:

2023-10-24 17:50:58,140 DEBUG:Starting new HTTPS connection (1): smt-azure.susecloud.net:443
2023-10-24 17:50:58,243 ERROR:Registration with ('52.237.80.2', None) failed. Trying ('52.139.216.51', None)
2023-10-24 17:50:58,244 WARNING:Found unknown entry in credentials file "system_token=
"
2023-10-24 17:50:58,244 INFO:No current registration server set.
2023-10-24 17:50:58,247 INFO:Modified /etc/hosts, added: 52.139.216.51 smt-azure.susecloud.net smt-azure
2023-10-24 17:53:34,841 WARNING:Found unknown entry in credentials file "system_token=
"

Causa

Il problema si verifica a causa di un bundle di certificati temporaneo errato, ca-bundle.pem.tmp.

Risoluzione

  1. Rimuovere il file e aggiornare :ca-certificates

    sudo registercloudguest --clean
sudo rm /var/lib/ca-certificates/ca-bundle.pem.tmp

  2. Aggiornare i certificati:

    sudo update-ca-certificates

  3. Registrare correttamente la macchina virtuale:

    sudo registercloudguest --force-new

Scenario 7: la macchina virtuale non si connette a SMT a causa di un errore azuremetadata

Quando /var/log/cloudregister viene selezionato, viene visualizzato il seguente messaggio di errore azuremetadata:

sudo tail -10 /var/log/cloudregister

2020-10-30 22:47:43,200 INFO:No current registration server set.
2020-10-30 22:47:43,222 INFO:Modified /etc/hosts, added: 52.147.176.11 smt-azure.susecloud.net smt-azure

2020-10-30 22:48:03,358 ERROR:Data collected from stderr for instance data collection "b'An error occurred when fetching metadata:\ntimed out\nAn error occurred when fetching metadata:\ntimed out\nusage: azuremetadata [-h] [-x] [-j] [-o OUTPUT] [-a API] [--device [DEVICE]]\n [--attestedData [ATTESTEDDATA]]\n [--billingTag [BILLINGTAG]]\nazuremetadata: error: unrecognized arguments: --subscriptionId\n'"
2020-10-30 22:48:04,519 INFO:Writing SMT rootCA: /usr/share/pki/trust/anchors
2020-10-30 22:48:04,526 INFO:Updating CA certificates: update-ca-certificates
2020-10-30 22:48:06,569 INFO:No credentials entry for "*smt-azure_susecloud_net"
2020-10-30 22:48:06,608 ERROR:Unable to obtain product information from server "52.147.176.11,None"
Unprocessable Entity
{"type":"error","error":"The requested product 'SUSE Linux Enterprise Server for SAP Applications 15 SP2 x86_64' is not activated on this system.","localized_error":"The requested product 'SUSE Linux Enterprise Server for SAP Applications 15 SP2 x86_64' is not activated on this system."}
Unable to register modules, exiting.

A causa dell'errore azuremetadata, la macchina virtuale non può connettersi al repository cloud SUSE di Azure, come illustrato nell'output seguente:

sudo  SUSEConnect -s

Error: Invalid system credentials, probably because the registered system was deleted in SUSE Customer Center. Check https://scc.suse.com whether your system appears there. If it does not, please call SUSEConnect --cleanup and re-register this system.

sudo zypper repos

Warning: There are no enabled repositories defined. Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories.

Causa 1

La --subscriptionId voce è presente nel file /etc/regionserverclnt.cfgdi configurazione . In questo modo viene generato un errore nel azuremetadata comando :

sudo cat /etc/regionserverclnt.cfg

[server]
api = regionInfo

certLocation = /var/lib/regionService/certs
regionsrv = 23.100.36.229,40.121.202.140,52.187.53.250,104.45.31.195,191.237.254.253

[instance]
dataProvider = /usr/bin/azuremetadata --api 2019-08-15 --subscriptionId --billingTag --xml
instanceArgs = msftazure

Risoluzione 1

  1. Rimuovere --subscriptionId nel file /etc/regionserverclnt.cfgdi configurazione :

    sudo sed -i "s/--subscriptionId //" regionserverclnt.cfg

  2. Registrare nuovamente la macchina virtuale:

    sudo SUSEConnect --cleanup
sudo rm -f /etc/SUSEConnect
sudo rm -rf /etc/zypp/credentials.d/\*
sudo rm /var/lib/cloudregister/*
sudo rm /var/cache/zypp/*
sudo sed -i '/^# Added by SMT reg/,+1d' /etc/hosts
sudo registercloudguest --force-new

Causa 2

Quando si registra il server SUSE nel repository usando il /usr/sbin/registercloudguest --force-new comando , si verifica un errore. L'output del comando non indica che la registrazione è riuscita perché il /etc/zypp/credentials.d/SCCcredentials file è danneggiato.

Risoluzione 2

  1. Spostare la /etc/zypp/credentials.d cartella in una cartella temporanea:

    sudo mv /etc/zypp/credentials.d /tmp

  2. Registrare nuovamente la macchina virtuale:

    sudo SUSEConnect --cleanup
sudo rm -f /etc/SUSEConnect
sudo rm -rf /etc/zypp/credentials.d/\*
sudo rm /var/lib/cloudregister/*
sudo rm /var/cache/zypp/*
sudo sed -i '/^# Added by SMT reg/,+1d' /etc/hosts
sudo registercloudguest --force-new

Scenario 8: la registrazione SUSE non riesce a causa di problemi di compatibilità con Python 3.11 in SLES 15 SP5

Quando si esegue lo script di controllo del repository SUSE, screpocheck.py viene visualizzato un ModuleNotFoundError: No module named 'cloudregister' messaggio di errore:

sudo python3 sc-repocheck.py

2024-08-07 13:53:29,261 INFO:sc-repocheck 1.3.1 
2024-08-07 13:53:29,291 INFO: Checking package versions. 2024-08-07 13:53:29,307 INFO: Package versions OK. 2024-08-07 13:53:29,312 INFO: Checking baseproduct.
2024-08-07 13:53:29,316 INFO: SLES baseproduct OK.
2024-08-07 13:53:29,321 INFO: Checking /etc/hosts for multiple records. 2024-08-07 13:53:29,325 WARNING: No rmt records exist.
2024-08-07 13:53:29,325 INFO: Checking metadata access.
2024-08-07 13:53:29,360 INFO: Metadata OK.
2024-08-07 13:53:29,364 INFO: Checking regionserver access.
2024-08-07 13:53:31,160 INFO: Region server access OK.
2024-08-07 13:53:31,165 INFO: Checking RMT server entry is for correct region.
2024-08-07 13:53:31,241 ERROR: Cannot get IP of RMT server entry.
2024-08-07 13:53:31,252 INFO: http check unnecessary.
2024-08-07 13:53:31,246 INFO: Checking http port access to RMT servers.
2024-08-07 13:53:31,257 INFO: Checking https port access to RMT servers.
2024-08-07 13:53:31,337 INFO: https access OK.
2024-08-07 13:53:31,342 INFO: Checking https access using RMT certs.
2024-08-07 13:53:31,442 INFO: An exception of type ConnectionError occurred. Disregarding.
2024-08-07 13:53:31,449 INFO: EVERYTHING OK.
2024-08-07 13:53:31,453 INFO: Collecting debug data. Please wait 1-2 minutes maybe longer, depending on machine type. Traceback (most recent call last):
File "/usr/bin/azuremetadata", line 11, in <module>
from azuremetadata import azuremetadatautils, azuremetadata
ModuleNotFoundError: No module named 'azuremetadata'
2024-08-07 13:53:31,565 ERROR: PROBLEM: Issue with azuremetadata output. Check metadata access. Traceback (most recent call last):
File "/usr/sbin/registercloudguest", line 43, in <module>
import cloudregister.registerutils as utils
ModuleNotFoundError: No module named 'cloudregister'
2024-08-07 13:53:34,656 INFO: Check repositories. An attempt was made to fix.
2024-08-07 13:53:34,659 INFO: Debug data location: /var/log/sc-repocheck_240807_135331.tar.xz
2024-08-07 13:53:34,671 INFO: Report bugs to https://github.com/SUSE/susecloud-repocheck/issues

Causa

Nessun modulo supportato è disponibile insieme a Python 3.11.

Soluzione

In base a SUSE, il pacchetto non supporta ancora Python 3.11 in SLES15 SP5. Non usare Python 3.11 come interprete predefinito python3 nei sistemi SLES esistenti perché attualmente non è supportato in tutti i sistemi SLES.

Per altre informazioni, vedere incompatible-changes-ahead-for-public-cloud-sdks.

Per risolvere il problema, impostare la macchina virtuale per usare la versione predefinita di Python 3.6:

  1. Puntare la versione di Python a 3.6.x:

    sudo unlink /usr/bin/python3
sudo ln -s /usr/bin/python3.6 /usr/bin/python3

  2. Verificare la python3 versione nella macchina virtuale:

    sudo python3 --version

    Python 3.6.15

  3. Registrare nuovamente la macchina virtuale:

    sudo /usr/sbin/registercloudguest --force-new

    Registration succeeded

  4. Verificare che la macchina virtuale sia stata registrata correttamente:

    sudo SUSEConnect -s 

    [{"identifier":"SLES", "version":"15.5","arch":"x86_64","status":"Registered"},{"identifier": "sle-module-basesystem", "version":"15.5","arch":"x86_6
,"status":"Registered"},{"identifier": "sle-module-containers", "version":"15.5","arch":"x86 64","status":"Registered"},{"identifier": "sle-module-de top-applications","version":"15.5","arch":"x86 64","status":"Registered"},{"identifier": "sle-module-development-tools","version":"15.5"," 64","status":"Registered"},{"identifier":"sle-module-public-cloud", "version":"15.5","arch":"x86 64","status":"Registered"},{"identifier": "sle-modu -python3","version":"15.5","arch":"x86 64","status":"Registered"},{"identifier": "sle-module-server-applications","version":"15.5","arch":"x86 64",
tatus":"Registered"}, {"identifier": "sle-module-web-scripting", "version":"15.5","arch":"x86 64","status":"Registered"}]

Passaggi successivi

Se il problema non viene risolto, creare una richiesta di supporto e allegare una copia del sc-repocheck_\<YYMMDD_hhmmss>.tar.xzq log per altre operazioni di risoluzione dei problemi.

Ulteriori informazioni

Per altre informazioni sulle distribuzioni Linux approvate e sulle tecnologie open source in Azure, vedere Supporto per Linux e tecnologia open source in Azure.

Informazioni sulla dichiarazione di non responsabilità di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Dichiarazione di non responsabilità sulle informazioni di contatto di terze parti

Microsoft fornisce informazioni di contatto di terze parti per aiutarti a trovare ulteriori informazioni su questo argomento. Queste informazioni di contatto sono soggette a modifica senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni di contatto di terze parti.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.