Soluciona problemas de registro de pago por uso de SLES

Linux

En este documento, se describe cómo resolver problemas que puedes encontrar cuando conectas instancias de máquina virtual (VM) de Compute Engine que ejecutan SUSE Linux Enterprise Server (SLES) de pago por uso (PAYG) al repositorio de la herramienta de administración de suscripciones (SMT) de SUSE.

Antes de comenzar

• Asegúrate de que la VM tenga una cuenta de servicio asociada.
• Asegúrate de que la API de Service Metadata sea accesible desde la VM.
• Asegúrate de que haya conectividad de red desde la VM a los respectivos servidores de regiones y servidores SMT.
• Usa la herramienta sc-repocheck para solucionar los problemas automáticamente.
• Consulta los pasos descritos en la guía Solución de problemas de PAYG de SUSE.
• Si aún no lo hiciste, configura la autenticación. La autenticación verifica tu identidad para acceder a los servicios y las APIs de Google Cloud . Para ejecutar código o muestras desde un entorno de desarrollo local, puedes autenticarte en Compute Engine seleccionando una de las siguientes opciones:

  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. Instala Google Cloud CLI. Después de instalarla, inicializa Google Cloud CLI ejecutando el siguiente comando:

     gcloud init

     Si usas un proveedor de identidad (IdP) externo, primero debes Acceder a gcloud CLI con tu identidad federada.

     Nota: Si ya instalaste gcloud CLI, asegúrate de tener la última versión ejecutando gcloud components update.
  2. Set a default region and zone.

Problemas de red

Nombre de dominio que no se puede resolver

Es posible que encuentres los siguientes problemas si la VM no se puede conectar al servidor SMT smt-gce.susecloud.net:

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

ping: unknown host smt-gce.susecloud.net

Por lo general, estos problemas se deben a una resolución incorrecta del nombre de dominio del servidor de SMT smt-gce.susecloud.net. Este dominio no se puede resolver de forma global, por lo que debes configurar su dirección IP según la región de la VM con estos pasos:

Verifica el archivo /etc/hosts para asegurarte de que contiene una entrada con el dominio smt-gce.susecloud.net.

cat /etc/hosts | grep -i smt

El resultado es similar al siguiente, pero la dirección IP puede ser diferentes:

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

Si el archivo /etc/hosts no contiene las mismas líneas que en el ejemplo anterior, haz lo siguiente:

1. Busca una dirección IP que corresponda a la región de la VM de la lista de direcciones IP de SMT de SUSE.

2. cambia el archivo para agregar la dirección IP de SMT de SUSE y cualquier otra información que falte.

Si bien puedes modificar el archivo `/etc/hosts` para solucionar problemas, es importante saber que la herramienta `registercloudguest` podría reemplazar tus cambios.

No hay disponibilidad de red

Es posible que encuentres los siguientes errores debido a que la red no está disponible, incluso si la VM puede resolver el nombre de dominio del servidor de actualización de 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.

Estos son algunos ejemplos de errores que podrías encontrar en el archivo de registro de /var/log/cloudregister durante la investigación:

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 obtener más información sobre la causa del problema, realiza una prueba de conectividad de red. En este ejemplo, se muestra cómo probar una conexión HTTPS con cURL:

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

El resultado del comando contiene un código de respuesta HTTP o un mensaje de error. Los siguientes son errores y respuestas comunes:

• Respuesta correcta:

  Response code (>0 is OK): 200
  

• Error de tiempo de espera de la solicitud:

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

• Error de dominio que no se puede resolver:

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

Cualquier código de respuesta superior a "0" es una respuesta positiva porque la VM estableció una conexión con el servidor, incluso si la respuesta contiene un código de respuesta de error del servidor o del cliente.

En algunos casos, como reglas estrictas de firewall del host, es posible que la dirección IP predeterminada asociada con el dominio smt-gce.susecloud.net no esté disponible. Para garantizar que el problema no se relacione solo con la dirección IP actual, sino que se hace una prueba de conectividad de red para servidores regionales alternativos. Recupera la lista de servidores regionales:

Ve a IU web de SUSE para obtener la lista de servidores de actualización regionales.

Usa la herramienta pint para obtener la lista de servidores de actualización regionales a través de la CLI.

1. Instala el paquete obligatorio

   sudo zypper install python3-susepubliccloudinfo

2. Usa este comando con una región específica

   pint google servers --region us-central1

3. El resultado correcto contiene una lista de entradas en 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 la lista completa de las IPs del servidor de SUSE para Google Cloud, consulta los siguientes documentos:

• Servidores regionales
• Servidores SMT

Una configuración incorrecta de la VM puede causar que la red no esté disponible. Si tienes problemas, realiza un diagnóstico de red para identificar la causa raíz.

Registro fallido

Es posible que encuentres el siguiente error si tienes VMs con una dirección IP privada en 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, revisa la configuración de Cloud NAT y verifica que hayas establecido el parámetro puertos mínimos por instancia de VM en al menos 256.

Si quieres obtener más información, consulta el boletín de asistencia de SUSE Registro y zypper con errores para instancias de Compute Engine detrás de Cloud NAT.

No respondió

Si tu VM tiene problemas para comunicarse con los servidores de actualización y región, es posible que observes los siguientes errores:

• Error SUSEConnect:

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

• Error zypper:

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

Estos errores pueden ocurrir cuando los servidores de actualización y región no responden. Para verificar si este es el caso, revisa los registros /var/log/cloudregister para buscar contenido similar:

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, prueba una o más de las siguientes opciones:

• Confirma que la VM tenga una dirección IP externa o que la subred de la nube privada virtual use una NAT (ya sea Cloud NAT o una solución personalizada).

• Si modificaste las reglas de enrutamiento de red predeterminadas, como limitar el acceso público a Internet o enrutar el tráfico a través de una red local, agrega rutas de forma manual para las IPs de SMT a través de la puerta de enlace predeterminada de Compute Engine, de la siguiente manera:

  1. Ve a la página Rutas en la consola de Google Cloud .

     Ir a la página Rutas

  2. En la pestaña Administración de rutas, busca una ruta que incluya las direcciones IP de SMT de SUSE y verifica que tenga la puerta de enlace predeterminada de Compute Engine como el siguiente salto.

  3. Si falta la ruta, agrégala haciendo clic en Crear ruta y, luego, ingresando la información necesaria.

• Si usas un balanceador de cargas de red de transferencia interno, por ejemplo, con software de red intermediario adicional (como firewalls o NAT personalizadas), asegúrate de que el balanceador de cargas sea el próximo salto para el tráfico de VM. Para ello, haz lo siguiente:

  1. Ve a la página Instancias de VM en la Google Cloud consola.

     Ir a la página Instancias de VM

  2. Haz clic en el nombre de la VM que deseas cambiar. Se abrirá la página de detalles de la VM.

  3. En la sección Interfaces de red, haz clic en Ver detalles.

  4. En la sección Detalles de firewall y rutas, busca la ruta que define el acceso al rango de direcciones IP seleccionado.

  5. Haz clic en el nombre de la ruta y confirma que el balanceador de cargas de red de transferencia interno o su dirección IP sea el próximo salto.

  Si no hay una ruta que defina la ruta de acceso al rango de direcciones IP seleccionado o si el siguiente salto de la ruta es diferente del balanceador de cargas de red de transferencia interno, configura el balanceador de cargas de red de transferencia interno como el siguiente salto.

• Si usas un balanceador de cargas de red de transferencia interno, confirma que se encuentre en la misma región que la VM.

  1. Ve a la página Instancias de VM en la Google Cloud consola.

     Ir a la página Instancias de VM

  2. Ubica la VM que quieras verificar y anota su región.

  3. Ve a la página Balanceo de cargas en la consola de Google Cloud .

     Ir a la página Balanceo de cargas

  4. Ubica el balanceador de cargas de red de transferencia interno que se usó y verifica si está en la misma región que la VM.

  5. Si la VM y el balanceador de cargas de red de transferencia interno no están en la misma región, habilita el acceso global.

Registro detrás de los proxies

Es posible que surja un problema si tus VMs usan proxies no transparentes o algún otro software que realice una inspección de intermediario (PITM) (por ejemplo, Barracuda CloudGen Firewall o Palo Alto). En el siguiente ejemplo, se muestra un intento de registrar SLES a través de un 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 no admite oficialmente el registro de SLES detrás de proxies de intermediarios (PITM) y no transparentes en Compute Engine. Las configuraciones del proxy de PITM fallan durante el registro debido a la fijación de certificados.

Google Cloud no brinda asistencia para el proceso de registro cuando usas software de proxy de terceros.

Te recomendamos que uses una configuración de Cloud NAT o que configures un servidor SMTP personalizado.

Incumplimiento de los Controles del servicio de VPC

Si tu organización usa los Controles del servicio de VPC (VPC-SC), es posible que falle el registro y que veas un mensaje de error Request is prohibited by organization's policy. Este error puede deberse a incumplimientos de entrada o salida si no configuraste excepciones para la infraestructura de actualización de SUSE en tu política del VPC-SC.

Para resolver este problema, agrega los siguientes componentes a una lista de entidades permitidas en tu política de VPC-SC para permitir que la VM se comunique con la infraestructura de actualización de SUSE:

• Actualización del proyecto de infraestructura: Suse-gce-smt (número de proyecto: 778092048372)
• Cuenta de servicio: [e-mail]
• Método obligatorio: compute.alpha.InstancesService.GetLicenses

Problemas de configuración del SO

Estado de registro desconocido

Si no sabes si se registró tu SUSE Linux Enterprise Server (SLES) de pago por uso (PAYG), ejecuta el siguiente comando:

sudo SUSEConnect --status-text

El resultado contiene el estado de la versión y de registro de los productos SUSE, incluido SUSE Linux Enterprise Server.

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

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

  Registered

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

Si el estado es Not Registered, vuelve a registrar la VM para solucionar el problema:

sudo registercloudguest --force-new

El symlink del producto base es incorrecto

Es posible que encuentres los siguientes errores si el vínculo del producto base apunta a un archivo de producto incorrecto:

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 error se produce cuando el vínculo simbólico /etc/products.d/baseproduct apunta a un archivo de producto incorrecto (por ejemplo, sle-module-toolchain.prod).

Para resolver este problema, actualiza el symlink en /etc/products.d/baseproduct para que apunte al archivo de producto base apropiado:

1. Navega al directorio de /etc/products.d

     cd /etc/products.d

2. Ejecuta el siguiente comando y reemplaza SLES.prod por SLES_SAP.prod si instalaste SLES para SAP:

     sudo ln -sf SLES.prod baseproduct

Nota: Si falta el archivo de producto SLES.prod o SLES_SAP.prod, puedes crear una instancia de VM nueva con la misma imagen de disco de arranque y copiar el archivo correcto desde allí al directorio /etc/products.d.

No está disponible la información de identidad de las instancias

Es posible que encuentres los siguientes errores si la información de identidad de la instancia no está disponible para la VM. Este problema puede ocurrir si no hay una cuenta de servicio conectada a la instancia o si se desactivó la cuenta de servicio conectada.

Nota: Existe un problema conocido en el que borrar y volver a crear una cuenta de servicio con el mismo nombre puede hacer que la información de identidad de la instancia deje de estar disponible.

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

Para acceder a los metadatos de la instancia relacionados con los tokens de identidad, todas las VMs deben tener una cuenta de servicio asociada.

Para obtener más información, lee la Actualización de la infraestructura de nube pública.

Para verificar el estado de la cuenta de servicio de tu VM, ejecuta el siguiente comando en la VM:

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

Ejemplo de una respuesta exitosa con un token de identidad:

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

Si la VM no se ve afectada, recibirás un token. Si la VM se ve afectada, los metadatos que se muestran son un mensaje de error similar al siguiente:

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

Para solucionar este problema, sigue estos pasos:

1. Detén la VM:

   gcloud compute instances stop VM_NAME

2. Agrega una cuenta de servicio a la VM:

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

   Nota: La marca --no-scopes quita todos los permisos de la VM. Si no especificas una marca para el permiso de acceso, el sistema asigna permisos predeterminados a la cuenta de servicio de la instancia de procesamiento, o la cuenta de servicio conserva sus permisos actuales.

3. Inicia la VM:

   gcloud compute instances start VM_NAME

4. Después de agregar la cuenta de servicio que falta, ejecuta el siguiente comando desde la VM para volver a registrar SLES:

   sudo registercloudguest --force-new

Faltan paquetes obligatorios

El registro puede fallar si a tu VM le faltan paquetes esenciales, como cloud-regionsrv-client, regionServiceClientConfigGCE, cloud-netconfig-gce o suseconnect-ng.

Para resolver este problema, instala los paquetes necesarios, limpia los archivos de registro y vuelve a registrar la VM.

1. Instala los paquetes faltantes.

   sudo zypper install PACKAGE_NAME

   Reemplaza PACKAGE_NAME por el nombre del paquete faltante.

2. Limpia los archivos de registro antiguos:

   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. Vuelve a registrar la VM:

   sudo registercloudguest --force-new

Vínculo simbólico de python3 incorrecto

Si ejecutas registercloudguest y ves el error ModuleNotFoundError: No module named 'requests', es posible que la causa sea un vínculo simbólico /usr/bin/python3 incorrecto, por ejemplo, si lo reemplazaste 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, vuelve a crear el vínculo simbólico para que apunte a la versión correcta de Python.

1. Confirma la versión de Python instalada en la instancia:

   sudo zypper info python3

2. Verifica el vínculo simbólico python3:

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

3. Si el vínculo es incorrecto, quítalo y crea uno nuevo que apunte a la versión correcta de Python (por ejemplo, python3.6):

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

No se pudo verificar el certificado SSL

Si faltan archivos de certificado en el directorio /etc/pki/trust/anchors, es posible que veas errores como Curl error 60 o ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]. A continuación, se muestra un ejemplo más detallado de un error que podrías ver en /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)

Para confirmar que faltan los archivos de certificado, ejecuta el siguiente comando y observa el resultado vacío:

ls -lart /etc/pki/trust/anchors

El resultado debería estar vacío si faltan certificados:

total 0

Para resolver este problema, prueba una de las siguientes opciones:

• Opción 1: Limpia y vuelve a registrar

  Borra todos los archivos asociados con el registro y, luego, fuerza un nuevo registro. El proceso de registro descarga los certificados necesarios de los servidores regionales.

  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

• Opción 2: Copia certificados de una instancia en funcionamiento

  Si la limpieza y el nuevo registro no resuelven el problema, puedes copiar los archivos de certificado de una instancia en funcionamiento con gcloud compute scp o adjuntando el disco de arranque de una instancia en funcionamiento a la instancia con errores.

  Si conectas y activas el disco de una instancia en funcionamiento en MOUNT_PATH, ejecuta los siguientes 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

Incompatibilidad del paquete libzypp

Es posible que una VM de SUSE de pago por uso con SLES para SAP 15 no se registre y muestre un error similar al siguiente:

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 puede ocurrir cuando una actualización del paquete libzypp deja una versión incompatible del paquete libcurl4. Cuando libzypp intenta actualizarse por sí mismo, ya no puede usar libcurl4 para hacer solicitudes a ubicaciones de paquetes.

Para resolver este problema, actualiza manualmente el paquete libzypp. El siguiente comando es un ejemplo, y es posible que debas ajustar el número de versión:

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

Versión del SO no compatible o paquetes desactualizados

Si ejecutas una versión del SO que está fuera de su período de asistencia general (por ejemplo, SLES 12 SP4, cuya asistencia general finalizó el 30 de junio de 2020), es posible que falle el registro. Este error puede ocurrir porque los paquetes desactualizados en la VM no pueden comunicarse con la infraestructura de actualización de SUSE. Es posible que veas errores sobre IPs inaccesibles en el archivo de registro /var/log/cloudregister, incluso si la conectividad de red parece tener éxito parcialmente (por ejemplo, si el uso de telnet para los servidores SMT devuelve un error 403 Forbidden).

Para verificar si los paquetes están desactualizados, puedes consultar sus fechas de instalación. Es posible que los paquetes que no se actualizaron en más de un año estén desactualizados. Para verificar la hora de la última actualización de un paquete, usa el siguiente comando:

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

Para resolver este problema, actualiza a una versión compatible de SLES. Es posible que también debas actualizar paquetes específicos, como se describe en los Documentos de información técnica (TID) de SUSE.