Cree un servidor de actualización local de SUSE con RMT en SLES 15.

Para una nueva suscripción local de SUSE y un servidor de actualizaciones, instale la Herramienta de duplicación de repositorios (RMT) en un host SLES 15 compatible, configúrela con YaST, habilite los productos que usa su organización y duplique sus repositorios. Registre un cliente de prueba a través de la URL HTTPS del servidor antes de dirigir los sistemas de producción a él. RMT reemplaza a SMT para SLES 15; una instalación antigua de SMT no es el punto de partida adecuado para una nueva implementación.

Este diseño se adapta a un entorno donde un servidor se conecta al Centro de Clientes de SUSE (SCC) y otros sistemas SUSE reciben el registro y los paquetes a través de un punto final local. Puede reducir las descargas externas repetidas, pero no proporciona derechos de suscripción: aún se requieren suscripciones válidas de la organización y credenciales de replicación del SCC.

Confirma la plataforma y planifica el servidor.

La guía de la herramienta de replicación de repositorios (RMT) de SLES 15 SP7 indica que RMT es compatible con clientes SLES 12 y posteriores, pero no con SLES 11 ni versiones anteriores. RMT también se diferencia de SMT en funciones como la preparación y la generación de informes. Considere la migración como un cambio de servicio, no como una actualización de paquete in situ; SUSE recomienda instalar RMT en un nuevo host SLES 15 al migrar desde SMT.

Asigne un nombre de dominio completo (FQDN) estable, como rmt.example.com, y una dirección IP estática. Asegúrese de que la resolución DNS sea consistente y de que el host pueda acceder a los servicios de actualización de SCC y SUSE a través de los puertos de salida 80 y 443. Los clientes necesitan acceso a la red para el servicio RMT mediante HTTPS. Utilice el mismo FQDN en la URL del cliente y en el certificado del servidor.

Planifique el almacenamiento en función de las versiones, arquitecturas, productos y repositorios que replicará. La guía SP7 de SUSE proporciona una estimación general de aproximadamente 1,5 veces el tamaño total de los repositorios habilitados, unos 200 GB por versión de SLES, incluidas las extensiones. Esta es una estimación, no una garantía de capacidad; compruebe el tamaño actual de los repositorios y deje espacio para el crecimiento. RMT también escribe archivos temporales grandes en /tmp, así que asegúrese de que el sistema de archivos tenga suficiente espacio libre. No configure el mismo host que un servidor de instalación de SLES: RMT configura NGINX en el puerto 80, mientras que el rol de servidor de instalación configura Apache en ese puerto.

Instale el paquete RMT y configure YaST.

En un servidor SLES 15 actualizado y registrado, instale RMT:

sudo zypper patch
sudo zypper in rmt-server

Revise los cambios del paquete y complete la instalación. Inicie la configuración inicial:

sudo yast2 rmt

Introduzca las credenciales de la organización SCC que se utilizan para la replicación del repositorio. Se trata de las credenciales de proxy de la organización en SUSE Customer Center, no de un código de registro de cliente. Cree la base de datos MariaDB y el usuario que solicita el asistente. Establezca el nombre común del certificado con el FQDN del servidor y añada cualquier otro nombre que los clientes vayan a utilizar como nombres alternativos. Si firewalld está habilitado, seleccione las reglas RMT necesarias y, cuando sea posible, aplíquelas a la interfaz de red correspondiente del servidor. Finalice el asistente; YaST habilita e inicia los servicios y temporizadores necesarios.

YaST almacena el certificado de CA RMT en /etc/rmt/ssl/rmt-ca.crty el certificado y la clave del servidor en /etc/rmt/ssl/. Proteja la clave privada. Distribuya la confianza para la CA utilizando su proceso aprobado. Un servidor que responde a través de HTTPS aún puede fallar en el registro del cliente si el nombre de su certificado no coincide con el nombre de host solicitado o si su CA no es de confianza.

Sincroniza los metadatos, habilita los productos y crea una copia espejo.

Actualiza el catálogo local desde SCC e inspecciona los productos disponibles:

sudo rmt-cli sync
sudo rmt-cli products list --all

Habilite un producto mediante su ID o cadena de producto que se muestra en esa salida. Las cadenas de producto varían según la versión y la arquitectura, así que utilice un valor de su propio servidor en lugar de copiar un identificador adivinado:

sudo rmt-cli products enable PRODUCT_STRING
sudo rmt-cli products list

Al habilitar un producto, se seleccionan sus repositorios asociados. Limite la selección a los sistemas que desea admitir: cada versión y arquitectura adicional consume espacio de almacenamiento y genera trabajo de sincronización. Inicie la descarga inicial del paquete con:

sudo rmt-cli mirror

La replicación inicial puede tardar bastante tiempo. RMT normalmente programa la sincronización de metadatos y la replicación del repositorio con temporizadores de systemd. Compruebe que ambas programaciones estén activas:

systemctl status rmt-server-sync.timer
systemctl status rmt-server-mirror.timer

Utilice rmt-cli products listy rmt-cli repos listpara confirmar que las entradas previstas estén habilitadas y muestren la actividad reciente de los espejos. Si faltan repositorios, compruebe las credenciales de SCC, los derechos de suscripción, la conectividad saliente, el espacio en disco (incluido /tmp) y la salida del comando antes de reiniciar los servicios repetidamente.

Regístrese como cliente de prueba y verifique las actualizaciones.

En un sistema de prueba SLES 12 o posterior, configure SUSEConnect para que apunte al servidor RMT:

sudo SUSEConnect --url https://rmt.example.com

Sustituya su FQDN real y asegúrese de que esté incluido en el certificado. Si el cliente solicita confiar en la CA RMT, verifique el certificado a través del canal aprobado por su organización antes de aceptarlo. No solucione una discrepancia de nombre desactivando las comprobaciones de certificados. A continuación, inspeccione los repositorios configurados y actualice los metadatos.

sudo zypper lr -u
sudo zypper refresh

Un resultado satisfactorio muestra que los repositorios compatibles con RMT están habilitados y que la actualización de metadatos se ha completado. En el servidor, confirme que el cliente aparece en sudo rmt-cli systems list. Si el registro falla, compruebe el DNS y el enrutamiento, la accesibilidad HTTPS, la confianza del certificado y la coincidencia del nombre de host, el ámbito del firewall y si el producto está habilitado y replicado. Revise la salida de los comandos y los registros del servicio antes de modificar la configuración compartida.

Instale el paquete RMT en el host SLES 15 preparado.

Revise la configuración del SCC, la base de datos, el certificado FQDN y el firewall antes de aplicar la configuración de YaST.

Actualice el catálogo de productos e inspeccione las cadenas de productos disponibles para la replicación.

Inicie la replicación del repositorio y registre un cliente de prueba con el nombre de host HTTPS del servidor.

Conozca los límites y elija otro camino cuando sea necesario.

Utilice SUSE Multi-Linux Manager u otro servicio de gestión del ciclo de vida compatible si necesita funcionalidades que RMT no ofrece, como una gestión de clientes más amplia, generación de informes o flujos de trabajo de contenido por etapas. Mantenga SMT solo cuando los clientes SLES 11 heredados o el comportamiento específico de SMT sigan siendo requisitos, y pruebe la migración por separado. Una red aislada requiere un flujo de trabajo de transferencia de datos: SUSE documenta los comandos de exportación e importación de RMT para mover datos y metadatos del repositorio mediante almacenamiento extraíble. RMT solo puede replicar productos disponibles para las suscripciones de la organización.

Documentación oficial para SLES 15 SP7: Instalación y configuración de RMT ; Guía de la herramienta de duplicación de repositorios ; Migración de SMT a RMT .