Cómo configurar un servidor SUSE RMT local (sustituto de SMT)

Si va a configurar un servidor local para sistemas SUSE Linux Enterprise actuales, utilice la Herramienta de duplicación de repositorios (RMT), no una nueva instalación de SMT. SUSE reemplazó la Herramienta de administración de suscripciones (SMT) por RMT a partir de SLE 15. RMT sincroniza la información de productos y repositorios desde SUSE Customer Center (SCC), duplica paquetes seleccionados y permite que los clientes compatibles se registren a través de su servidor local. Esta guía se basa en la documentación de RMT para SUSE Linux Enterprise Server 15 SP7, revisada el 6 de octubre de 2026. Los comandos y la disponibilidad de paquetes pueden variar en otras versiones, por lo que debe usar la guía correspondiente a la versión exacta del servidor que implemente.

¿Deberías usar RMT o seguir usando SMT?

Elija RMT para un nuevo servicio local de registro y actualización para clientes SLES 12 y versiones posteriores. RMT viene incluido con SLES a partir de la versión 15 y puede replicar repositorios SUSE y repositorios personalizados. Reduce las descargas repetidas y evita que las máquinas cliente se conecten directamente a SCC.

SMT sigue siendo relevante para entornos antiguos, pero SUSE identifica SLE 12 como la última versión compatible. RMT no es compatible con clientes SLE 11 ni versiones anteriores, y SUSE advierte que no se trata de un reemplazo completo en cuanto a funcionalidades: por ejemplo, su guía de migración enumera los repositorios de preparación, la administración de clientes SMT y los informes como capacidades que no se transfieren de la misma manera. Si su entorno incluye SLE 11 o depende de flujos de trabajo exclusivamente SMT, no dé por sentado que es posible un reemplazo directo. Revise la guía de migración y las opciones de soporte de SUSE antes de cambiar el servicio.

RMT también se diferencia de un repositorio de paquetes aislado. Un servidor RMT estándar necesita acceso saliente a los servicios de actualización de SCC y SUSE para sincronizar metadatos y paquetes. Una implementación sin conexión requiere un proceso independiente de exportación/importación o de replicación sin conexión.

¿Qué debe preparar antes de la instalación?

• Host compatible: Planifique un servidor SLES 15 para el servicio RMT. Para la migración desde SMT, SUSE recomienda utilizar un host SLES 15 recién instalado.
• Credenciales de la organización SCC: RMT utiliza las credenciales de replicación de la organización, no un código de registro de cliente normal. En SCC, seleccione la organización correcta y abra Proxies para encontrarla.
• Un nombre DNS estable y un plan TLS: Elija el nombre de dominio completo (FQDN) que usarán los clientes, como por ejemplo rmt.example.com. Asegúrese de que se resuelva desde las redes de los clientes y que coincida con el nombre del certificado HTTPS.
• Almacenamiento del repositorio: Tamaño del almacenamiento para los productos, módulos, versiones y arquitecturas que pretende replicar. SUSE proporciona aproximadamente 1,5 veces el tamaño total del repositorio habilitado como guía general de planificación y señala que esto equivale aproximadamente a 200 GB por versión SLE, incluidas las extensiones. Las necesidades reales varían; supervise el espacio libre, especialmente el espacio temporal en /tmp.
• Acceso a la red: Permita que el host RMT acceda a los puntos finales de SUSE requeridos por su versión. La guía de SLES 15 SP7 enumera scc.suse.com, updates.suse.com, y installer-updates.suse.coma través de los puertos 80 y 443. Limite el acceso de los clientes al servicio RMT a las redes que lo necesiten.

No combine la función RMT con la función de servidor de instalación SLES en la misma máquina sin comprobar la advertencia de SUSE: las dos configuraciones utilizan servidores web diferentes en el puerto 80 y no están diseñadas para habilitarse juntas.

¿Cómo se instala y configura RMT?

1. Instale el paquete RMT.

En un host SLES 15 existente con los repositorios necesarios disponibles, instale el paquete del servidor y aplique las actualizaciones de mantenimiento actuales:

sudo zypper in rmt-server
sudo zypper patch

El conjunto exacto de paquetes puede variar según las imágenes mínimas y los métodos de implementación. Siga la sección de instalación correspondiente a la versión de SLES que haya elegido, en lugar de copiar un comando de otra plataforma.

2. Ejecutar la configuración de YaST RMT

Inicie el módulo de configuración:

sudo yast2 rmt

Introduzca el nombre de usuario y la contraseña de la organización SCC cuando se le solicite. YaST también le pedirá una base de datos y un usuario de MariaDB, así como un nombre común para el certificado. Utilice el FQDN del servidor RMT visible para el cliente como nombre común. Añada cualquier otro nombre o dirección IP que los clientes vayan a utilizar como nombres alternativos en el certificado. Un cliente que se conecte mediante un nombre no incluido en la lista puede informar de una discrepancia en el certificado, incluso si el servicio es accesible.

Si firewalldestá habilitada, utilice la opción YaST para abrir los puertos RMT necesarios. Siempre que sea posible, limite el acceso a la interfaz de red o zona correcta. Complete el asistente y revise su resumen; SUSE indica que YaST habilita e inicia los servicios y temporizadores de systemd necesarios.

3. Confirme el nombre del servidor, el certificado y el servicio.

Desde la red del cliente, confirme que el FQDN elegido se resuelve en el host RMT y que HTTPS presenta un certificado de confianza para el cliente. El certificado CA generado por RMT se almacena en /etc/rmt/ssl/rmt-ca.crt; el certificado y la clave del servidor se almacenan en /etc/rmt/ssl/rmt-server.crty /etc/rmt/ssl/rmt-server.key. Proteja la clave privada y mantenga el certificado CA disponible para los clientes que necesiten confiar en él. Utilice el mismo FQDN para el registro que aparece en el certificado del servidor.

¿Cómo se seleccionan y replican únicamente los repositorios necesarios?

4. Sincronizar los metadatos del producto y del repositorio.

Tras la configuración, sincronice la base de datos RMT local con SCC:

sudo rmt-cli sync

Esto actualiza la información del producto y del repositorio disponible para RMT; no significa que todos los paquetes ya se hayan descargado. La sincronización automática de metadatos la gestiona rmt-server-sync.timer. Compruebe su estado con:

systemctl status rmt-server-sync.timer

5. Encuentre los identificadores de producto para su propiedad.

Enumera los productos y repositorios disponibles antes de habilitar cualquier función:

sudo rmt-cli products list --all
sudo rmt-cli repos list --all

Utilice los identificadores o cadenas de producto que le proporcione su propio servidor. Los identificadores en los ejemplos en línea pueden variar, ya que la disponibilidad depende de las suscripciones, las versiones del producto, la arquitectura y los metadatos que devuelve SCC.

6. Habilitar los productos necesarios

Habilite los productos que los clientes realmente utilizan. Por ejemplo, después de confirmar que la cadena del producto está presente en su resultado, podría ejecutar:

sudo rmt-cli products enable SLES/15/x86_64

Al habilitar un producto, también se habilitan sus repositorios asociados, como los de grupos y actualizaciones. Si sus sistemas utilizan módulos o extensiones adicionales, verifique que estén disponibles y habilite los necesarios. Evite replicar todos los productos «por si acaso»: esto consume espacio de almacenamiento y aumenta el tiempo de sincronización.

7. Refleje los paquetes e inspeccione el resultado.

Inicie el espejo inicial manualmente para poder observar su finalización y solucionar problemas antes de confiar en la programación:

sudo rmt-cli mirror

RMT almacena el contenido duplicado /var/lib/rmt/public/repode forma predeterminada. Compruebe el espacio en disco disponible y revise la salida del comando. La programación diaria de la duplicación se gestiona mediante rmt-server-mirror.timer; inspeccione su estado con:

systemctl status rmt-server-mirror.timer

Una sincronización exitosa de metadatos por sí sola no garantiza que los clientes puedan instalar actualizaciones. Es necesario que los repositorios seleccionados estén sincronizados, que el cliente pueda acceder al servidor y que el acceso al producto sea válido para la organización.

¿Cómo se registra un cliente en el servidor local?

8. Prueba primero con un cliente.

En un cliente SLES compatible, regístrelo con el nombre de host RMT. SUSE documenta esta forma de comando:

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

Sustituya el host de ejemplo por el FQDN cubierto por su certificado. Los clientes normalmente no necesitan las credenciales de duplicación SCC; el host RMT utiliza dichas credenciales para sincronizar en nombre de la organización. Para los sistemas que necesiten ayuda para importar la CA RMT, SUSE proporciona un rmt-client-setupscript desde el servidor. Consulte la guía del cliente actual y verifique la huella digital del certificado o la cadena de confianza antes de aceptarlo.

También puede configurar el registro durante la instalación mediante el regurl=https://rmt.example.comparámetro de arranque, o usar el módulo de registro de productos de YaST y seleccionar el servidor de registro local. Para instalaciones automatizadas, SUSE documenta la opción AutoYaST. Elija el método que mejor se adapte a la configuración de sus sistemas.

9. Verificar el registro y el acceso al paquete.

En el cliente, confirme que el registro se completa, que aparecen los productos y repositorios esperados y que se pueden actualizar los metadatos del repositorio. Por ejemplo, inspeccione las definiciones del repositorio con zypper lry actualícelas con sudo zypper refresh. A continuación, pruebe una consulta o actualización de paquetes en una ventana de mantenimiento. Si falta un módulo, compruebe si está habilitado y replicado en RMT antes de modificar los archivos del repositorio del cliente.

Pruebe una ruta de actualización estándar en un cliente representativo antes de redirigir a un gran número de usuarios. Una vez que la prueba sea exitosa, actualice los perfiles de aprovisionamiento, los parámetros de arranque de la instalación o la gestión de la configuración para que los sistemas nuevos y reconstruidos utilicen la misma URL RMT.

¿Qué debes comprobar cuando algo falla?

¿Qué cambios se producen al migrar desde SMT?

Trate la migración como un cambio de datos y flujo de trabajo, no como una actualización de paquete in situ. SUSE recomienda un nuevo host SLES 15. Su proceso documentado de exportación/importación se utiliza smt-data-exporten SMT y rmt-data-importen el nuevo servidor después de que RMT se haya sincronizado con SCC. La configuración del repositorio provisional no se exporta; solo se transfieren los repositorios marcados para replicación y los productos caducados no están disponibles en RMT. Los trabajos del cliente SMT y el estado de los parches no se exportan. Planifique recrear los procesos operativos que dependían de estas características y valide los registros de registro antes de redirigir a los clientes de producción.

Mantenga el servicio anterior disponible durante una transición controlada si sus políticas de soporte y seguridad lo permiten. Migre un pequeño grupo de clientes, confirme el registro, los repositorios, la confianza de certificados y el comportamiento de actualización, y luego amplíe la migración. No retire el host SMT hasta que los clientes heredados y los flujos de trabajo no compatibles tengan un destino explícito.

¿Cómo sabes que la configuración está lista?

• El FQDN de RMT se resuelve correctamente y HTTPS utiliza un certificado de confianza para los clientes.
• El host RMT sincroniza los metadatos SCC actuales y replica todos los repositorios de productos que requieren los clientes piloto.
• Un cliente compatible se registra en la URL local y ve los repositorios de productos previstos.
• Un cliente puede actualizar los metadatos del repositorio y completar una operación de paquete controlada.
• La capacidad del disco, el espacio temporal, los temporizadores, los registros, las copias de seguridad y la renovación de certificados tienen un propietario y un plan de supervisión.

RMT centraliza el registro y la entrega de paquetes, pero no elimina la necesidad de gestionar las suscripciones, la selección de productos, el ciclo de vida del cliente, la confianza en los certificados, las copias de seguridad y las pruebas de actualización. Para conocer los procedimientos exactos y las diferencias específicas de cada versión, consulte la Guía de la herramienta de duplicación de repositorio SLES 15 SP7 de SUSE , el capítulo sobre la migración de SMT a RMT , el capítulo sobre la configuración del cliente RMT y el capítulo sobre la duplicación de repositorio de SUSE .