Esta página foi traduzida pela API Cloud Translation.

Resolução de problemas de registo de pagamento conforme o uso do SLES

Linux

Este documento descreve como resolver problemas que pode encontrar quando liga instâncias de máquinas virtuais (VM) do Compute Engine com pagamento conforme o uso (PAYG) do SUSE Linux Enterprise Server (SLES) ao repositório da ferramenta de gestão de subscrições (SMT) da SUSE.

Antes de começar

Certifique-se de que a VM tem uma conta de serviço associada.
Certifique-se de que a API Service Metadata está acessível a partir da VM.
Certifique-se de que existe conetividade de rede da VM para os respetivos servidores de região e servidores SMT
Use a ferramenta sc-repocheck para resolver automaticamente os problemas.
Consulte os passos descritos no guia de resolução de problemas de SUSE PAYG.
Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-se no Compute Engine selecionando uma das seguintes opções:
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. Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando:
  gcloud init
  Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.
  
  Nota: se instalou a CLI gcloud anteriormente, certifique-se de que tem a versão mais recente executando gcloud components update.
2. Set a default region and zone.

Problemas de rede

Nome de domínio não resolvível

Pode encontrar os seguintes problemas se a VM não conseguir estabelecer ligação ao servidor SMT:smt-gce.susecloud.net

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

ping: unknown host smt-gce.susecloud.net

Geralmente, estes problemas devem-se a uma resolução incorreta do nome de domínio do servidor SMTP smt-gce.susecloud.net. Este domínio não é resolvível globalmente, pelo que tem de definir o respetivo endereço IP de acordo com a região da VM da seguinte forma:

Verifique o ficheiro /etc/hosts para se certificar de que contém uma entrada com o domínio smt-gce.susecloud.net.

cat /etc/hosts | grep -i smt

O resultado é semelhante ao seguinte, mas o endereço IP pode ser diferente:

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

Se o ficheiro /etc/hosts não contiver as mesmas linhas que o exemplo anterior, faça o seguinte:

Encontre um endereço IP que corresponda à região da sua VM na lista de endereços IP do SUSE SMT.
Edite o ficheiro para adicionar o endereço IP do SUSE SMT e quaisquer outras informações em falta.

Indisponibilidade da rede

Pode encontrar os seguintes erros devido à indisponibilidade da rede, mesmo que a VM consiga resolver o nome do domínio do servidor de atualizações do 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.

Seguem-se alguns exemplos de erros que pode encontrar no ficheiro de registo /var/log/cloudregister durante a investigação:

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

Para saber mais sobre a causa do problema, faça um teste de conetividade de rede. O exemplo seguinte mostra como testar uma ligação HTTPS através do cURL:

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

A saída do comando contém um código de resposta HTTP ou uma mensagem de erro. Seguem-se as respostas e os erros comuns:

Resposta com êxito:
```
Response code (>0 is OK): 200
```

Erro de tempo limite de pedido:

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

Erro de domínio não resolvível:

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

Em determinados cenários, como regras de firewall de anfitrião rigorosas, o endereço IP predefinido associado ao domínio smt-gce.susecloud.net pode não estar disponível. Para garantir que o problema não está apenas relacionado com o endereço IP atual, teste a conetividade de rede para servidores regionais alternativos. Apresente a lista de servidores regionais:

Aceda à SUSE WebUI para obter a lista de servidores de atualização regionais.

Use a ferramenta pint para obter a lista de servidores de atualização regionais através da CLI.

Instale o pacote necessário

sudo zypper install python3-susepubliccloudinfo

Use o seguinte comando com uma região específica
```
pint google servers --region us-central1
```

Um resultado bem-sucedido contém uma lista de entradas no formato 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>

Para encontrar a lista completa de IPs do servidor SUSE para Google Cloud, consulte os seguintes documentos:

Uma configuração incorreta da VM pode causar a indisponibilidade da rede. Se tiver problemas, faça diagnósticos de rede para identificar a causa principal.

Falha ao registar

Pode encontrar o seguinte erro se tiver VMs com um endereço IP privado no 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'.

Para resolver este problema, reveja a configuração do Cloud NAT e verifique se definiu o parâmetro minimum ports per VM instance para, pelo menos, 256.

Para mais informações, consulte o Boletim de apoio técnico da SUSE: falha no registo e no zypper para instâncias do Compute Engine atrás do Cloud NAT.

Sem resposta

Se a sua VM tiver problemas de comunicação com os servidores de atualização e de região, pode ver os seguintes erros:

Erro SUSEConnect:

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

Erro zypper:

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

Estes erros podem ocorrer quando os servidores de atualização e de região não respondem. Para verificar se é este o caso, consulte os registos /var/log/cloudregister para ver conteúdo semelhante:

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

Para resolver este problema, experimente uma ou mais das seguintes opções:

Confirme se a VM tem um endereço IP externo ou se a sub-rede da nuvem privada virtual usa um NAT (Cloud NAT ou solução personalizada).
Se modificou as regras de encaminhamento de rede predefinidas, como limitar o acesso público à Internet ou encaminhar tráfego através de uma rede no local, adicione rotas manualmente para IPs SMT através do gateway do Compute Engine predefinido, fazendo o seguinte:
1. Aceda à página Rotas na Google Cloud consola.
  
  Aceda à página Rotas
2. No separador Gestão de trajetos, procure um trajeto que inclua os endereços IP do SUSE SMT e verifique se tem o gateway predefinido do Compute Engine como o próximo salto.
3. Se a rota estiver em falta, adicione-a clicando em Criar rota e introduzindo as informações necessárias.
Se estiver a usar um balanceador de carga de passagem interno, por exemplo, com software de rede intermediário adicional (como firewalls ou NATs personalizados), certifique-se de que o balanceador de carga é o salto seguinte para o tráfego de VMs, fazendo o seguinte:
1. Aceda à página Instâncias de VM na Google Cloud consola.
  
  Aceda à página de instâncias de VM
2. Clique no nome da VM que quer verificar. É apresentada a página Detalhes da VM.
3. Na secção Interfaces de rede, clique em Ver detalhes.
4. Na secção Detalhes da firewall e das rotas, localize a rota que define o caminho para o intervalo de endereços IP selecionado.
5. Clique no nome da rota e confirme que o Network Load Balancer de transferência interna ou o respetivo endereço IP é o salto seguinte.
Se não existir um trajeto que defina o caminho para o intervalo de endereços IP selecionado ou se o próximo salto do trajeto for diferente do Network Load Balancer de passagem interno, configure o Network Load Balancer de passagem interno como o próximo salto.
Se estiver a usar um Network Load Balancer de encaminhamento interno, confirme que está localizado na mesma região que a VM.
1. Aceda à página Instâncias de VM na Google Cloud consola.
  
  Aceda à página de instâncias de VM
2. Localize a VM que quer verificar e anote a respetiva região.
3. Aceda à página Equilíbrio de carga na Google Cloud consola.
  
  Aceda à página Balanceamento de carga
4. Localize o Network Load Balancer de encaminhamento interno usado e verifique se está na mesma região que a VM.
5. Se a VM e o Network Load Balancer de passagem interno não estiverem na mesma região, ative o acesso global.

Registo através de proxies

Pode encontrar um problema se as suas VMs usarem proxies não transparentes ou outro software que execute a inspeção de pessoa no meio (PITM) (por exemplo, Barracuda CloudGen Firewall, Palo Alto). O exemplo seguinte demonstra uma tentativa de registar o SLES através de um 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"

A SUSE não suporta oficialmente o registo do SLES atrás de proxies de pessoa no meio (PITM) e não transparentes no Compute Engine. As configurações de proxy PITM falham durante o registo devido à fixação de certificados.

Recomendamos que use uma configuração do Cloud NAT ou configure um servidor SMTP personalizado.

Violação dos VPC Service Controls

Se a sua organização usar os VPC Service Controls (VPC-SC), o registo pode falhar e pode ver uma mensagem de erro Request is prohibited by organization's policy. Esta falha pode ser causada por violações de entrada ou saída se não tiver configurado exceções para a infraestrutura de atualização do SUSE na sua política de VPC-SC.

Para resolver este problema, adicione os seguintes componentes a uma lista de autorizações na sua política de VPC-SC para permitir que a VM comunique com a infraestrutura de atualização da SUSE:

Atualização do projeto de infraestrutura: Suse-gce-smt (número do projeto: 778092048372)
Conta de serviço: 778092048372@project.gserviceaccount.com
Método obrigatório: compute.alpha.InstancesService.GetLicenses

Problemas de configuração do SO

Estado de registo desconhecido

Se não souber se o seu SUSE Linux Enterprise Server (SLES) de pagamento conforme o uso (PAYG) está registado, execute o seguinte comando:

sudo SUSEConnect --status-text

O resultado contém a versão e o estado de registo dos produtos SUSE, incluindo o SUSE Linux Enterprise Server.

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

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

  Registered

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

Se o estado for Not Registered, volte a registar a VM para corrigir o problema:

sudo registercloudguest --force-new

Link simbólico do produto base incorreto

Pode deparar-se com os seguintes erros se o link do produto base apontar para um ficheiro de produto incorreto:

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.

Este erro ocorre quando o link simbólico /etc/products.d/baseproduct aponta para um ficheiro de produto incorreto (por exemplo, sle-module-toolchain.prod).

Para resolver este problema, atualize a ligação simbólica em /etc/products.d/baseproduct para apontar para o ficheiro do produto base adequado:

Navegue para o diretório /etc/products.d
```
  cd /etc/products.d
```
Execute o seguinte comando substituindo SLES.prod por SLES_SAP.prod se tiver instalado o SLES para SAP:
```
  sudo ln -sf SLES.prod baseproduct
```

Indisponibilidade das informações de identidade da instância

Pode encontrar os seguintes erros se as informações de identidade da instância não estiverem disponíveis para a VM. Este problema pode ocorrer se não existir uma conta de serviço anexada à instância ou se a conta de serviço anexada tiver sido desativada.

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

Para aceder aos metadados da instância para tokens de identidade, todas as VMs têm de ter uma conta de serviço associada.

Para mais informações, leia o artigo Atualização da infraestrutura da nuvem pública.

Para verificar o estado da conta de serviço da VM, execute o seguinte comando na VM:

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

Exemplo de uma resposta bem-sucedida com um token de identidade:

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

Se a VM não for afetada, recebe um token. Se a VM for afetada, os metadados devolvidos são uma mensagem de erro semelhante à seguinte:

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

Para corrigir este problema, siga estes passos:

Parar a VM:
```
gcloud compute instances stop VM_NAME
```
Adicione uma conta de serviço à VM:
```
gcloud compute instances set-service-account VM_NAME \
  --service account SERVICE_ACCOUNT \
  --no-scopes
```
Nota: a flag --no-scopes remove todos os âmbitos da VM. Se não especificar uma flag para o âmbito de acesso, o sistema atribui âmbitos predefinidos à conta de serviço da instância de computação ou a conta de serviço mantém os respetivos âmbitos atuais.
Inicie a VM:
```
gcloud compute instances start VM_NAME
```
Depois de adicionar a conta de serviço em falta, execute o seguinte comando a partir da VM para voltar a registar o SLES:
```
sudo registercloudguest --force-new
```

Pacotes obrigatórios em falta

O registo pode falhar se a sua VM não tiver pacotes essenciais, como cloud-regionsrv-client, regionServiceClientConfigGCE, cloud-netconfig-gce ou suseconnect-ng.

Para resolver este problema, instale os pacotes necessários, limpe os ficheiros de registo e registe novamente a VM.

Instale os pacotes em falta.
```
sudo zypper install PACKAGE_NAME
```
Substitua PACKAGE_NAME pelo nome do pacote em falta.

Limpe ficheiros de registo antigos:

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

Volte a registar a VM:
```
sudo registercloudguest --force-new
```

Link simbólico python3 incorreto

Se executar registercloudguest e vir o erro ModuleNotFoundError: No module named 'requests', é possível que a causa seja um link simbólico /usr/bin/python3 incorreto, por exemplo, se o tiver substituído manualmente.

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

Para resolver este problema, recrie o link simbólico para apontar para a versão correta do Python.

Confirme a versão do Python instalada na instância:
```
sudo zypper info python3
```
Verifique o link simbólico python3:
```
ls -ll /usr/bin | grep -i python3
```
Se o link estiver incorreto, remova-o e crie um novo link que aponte para a versão correta do Python (por exemplo, python3.6):
```
sudo rm /usr/bin/python3
sudo ln -sf /usr/bin/python3.6 /usr/bin/python3
```

Falha na validação do certificado SSL

Se faltarem ficheiros de certificado no diretório /etc/pki/trust/anchors, pode ver erros como Curl error 60 ou ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]. Segue-se um exemplo mais detalhado de um erro que pode ver em /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)

Pode confirmar que faltam ficheiros de certificado executando o seguinte comando e vendo um resultado vazio:

ls -lart /etc/pki/trust/anchors

O resultado deve estar vazio se faltarem certificados:

total 0

Para resolver este problema, experimente uma das seguintes opções:

Opção 1: limpe e volte a registar

Limpe todos os ficheiros associados ao registo e, em seguida, force um novo registo. O processo de registo transfere os certificados necessários dos servidores da região.

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

Opção 2: copie certificados de uma instância em funcionamento

Se a limpeza e o novo registo não resolverem o problema, pode copiar os ficheiros de certificado de uma instância em funcionamento através do comando gcloud compute scp ou anexando o disco de arranque de uma instância em funcionamento à instância com falhas.

Se anexar e montar o disco de uma instância funcional em MOUNT_PATH, execute os seguintes comandos:
```
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
```

Incompatibilidade de pacotes libzypp

Uma VM SUSE de pagamento conforme o uso com SLES para SAP 15 pode não conseguir registar-se com um erro semelhante ao seguinte:

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

Este problema pode ocorrer quando uma atualização do pacote libzypp deixa uma versão incompatível do pacote libcurl4. Quando o libzypp tenta atualizar-se automaticamente, deixa de poder usar o libcurl4 para fazer pedidos a localizações de pacotes.

Para resolver este problema, atualize manualmente o pacote libzypp. O comando seguinte é um exemplo e pode ter de ajustar o número da versão:

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

Versão do SO não compatível ou pacotes desatualizados

Se estiver a executar uma versão do SO fora do respetivo período de suporte geral, por exemplo, o SLES 12 SP4, cujo suporte geral terminou a 30 de junho de 2020, o registo pode falhar. Esta falha pode ocorrer porque os pacotes desatualizados na VM não conseguem comunicar com a infraestrutura de atualização do SUSE. Pode ver erros sobre IPs inacessíveis no ficheiro de registo /var/log/cloudregister, mesmo que a conetividade de rede pareça parcialmente bem-sucedida (por exemplo, se usar telnet para servidores SMT devolver um erro 403 Forbidden).

Para verificar se os pacotes estão desatualizados, pode ver as respetivas datas de instalação. Os pacotes que não são atualizados há mais de um ano podem estar desatualizados. Para verificar a hora da última atualização de um pacote, use o seguinte comando:

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

Para resolver este problema, atualize para uma versão do SLES suportada. Também pode ter de atualizar pacotes específicos, conforme descrito nos documentos de informações técnicas (TIDs) da SUSE.