Se você estiver configurando um servidor local para sistemas SUSE Linux Enterprise atuais, use a Ferramenta de Espelhamento de Repositório (RMT), e não uma nova instalação do SMT. A SUSE substituiu a Ferramenta de Gerenciamento de Assinaturas (SMT) pela RMT a partir do SLE 15. A RMT sincroniza informações de produtos e repositórios do SUSE Customer Center (SCC), espelha pacotes selecionados e permite que clientes compatíveis se registrem por meio do seu servidor local. Este guia segue a documentação da RMT do SUSE Linux Enterprise Server 15 SP7, verificada em 6 de outubro de 2026. Os comandos e a disponibilidade de pacotes podem variar em outras versões; portanto, use o guia específico para a versão do servidor que você implantar.
Você deve usar RMT ou manter o SMT?
Escolha o RMT para um novo serviço local de registro e atualização para clientes SLES 12 e versões mais recentes. O RMT está incluído no SLES a partir da versão 15 e pode espelhar repositórios SUSE e repositórios personalizados. Ele reduz downloads repetidos e pode impedir que as máquinas cliente se conectem diretamente ao SCC.
O SMT continua relevante para ambientes mais antigos, mas a SUSE identifica o SLE 12 como o último fluxo de código para SMT. O RMT não oferece suporte a clientes SLE 11 e anteriores, e a SUSE alerta que o RMT não é um substituto completo, recurso por recurso: por exemplo, seu guia de migração lista repositórios em etapas, gerenciamento de clientes SMT e geração de relatórios como funcionalidades que não são transferidas da mesma forma. Se o seu ambiente inclui o SLE 11 ou depende de fluxos de trabalho exclusivos do SMT, não presuma que uma substituição direta seja possível. Consulte o guia de migração e as opções de suporte da SUSE antes de alterar o serviço.
O RMT também difere de um repositório de pacotes isolado da internet. Um servidor RMT padrão precisa de acesso externo aos serviços de atualização do SCC e do SUSE para sincronizar metadados e pacotes. Uma implementação desconectada requer um processo separado de exportação/importação ou espelhamento offline.
O que você deve preparar antes da instalação?
- Um host compatível: Planeje um servidor SLES 15 para o serviço RMT. Para migração do SMT, a SUSE recomenda o uso de um host SLES 15 recém-instalado.
- Credenciais da organização SCC: O RMT usa as credenciais de espelhamento da organização, não um código de registro de cliente normal. No SCC, escolha a organização correta e abra "Proxies" para encontrá-la.
- Um nome DNS estável e um plano TLS: Escolha o nome de domínio totalmente qualificado (FQDN) que os clientes usarão, como
rmt.example.com. Certifique-se de que ele seja resolvido a partir das redes dos clientes e corresponda ao nome no certificado HTTPS.
- Armazenamento do repositório: dimensione o armazenamento para os produtos, módulos, versões e arquiteturas que você pretende espelhar. A SUSE recomenda cerca de 1,5 vezes o tamanho total do repositório habilitado como guia geral de planejamento e observa que isso corresponde a aproximadamente 200 GB por versão do SLE, incluindo extensões. As necessidades reais variam; monitore o espaço livre, especialmente o espaço temporário em
/tmp.
- Acesso à rede: Permita que o host RMT acesse os endpoints SUSE exigidos pela sua versão. O guia do SLES 15 SP7 lista
scc.suse.comos updates.suse.comendpoints installer-updates.suse.com80 e 443. Limite o acesso do cliente ao serviço RMT às redes que realmente precisam dele.
Não combine a função RMT com a função de servidor de instalação do SLES na mesma máquina sem verificar o aviso da SUSE: as duas configurações usam servidores web diferentes na porta 80 e não foram projetadas para serem ativadas juntas.
Como instalar e configurar o RMT?
1. Instale o pacote RMT
Em um host SLES 15 existente com os repositórios necessários disponíveis, instale o pacote do servidor e aplique as atualizações de manutenção mais recentes:
sudo zypper in rmt-server
sudo zypper patch
O conjunto exato de pacotes pode variar dependendo das imagens mínimas e dos métodos de implantação. Siga as instruções da seção de instalação da versão do SLES escolhida, em vez de copiar um comando de outra plataforma.
2. Execute a configuração RMT do YaST.
Inicie o módulo de configuração:
sudo yast2 rmt
Insira o nome de usuário e a senha de espelhamento da organização SCC quando solicitado. O YaST também solicita um banco de dados e um usuário do MariaDB, além de um nome comum para o certificado. Use o FQDN (Nome de Domínio Totalmente Qualificado) do servidor RMT voltado para o cliente como nome comum. Adicione quaisquer outros nomes ou endereços IP que os clientes realmente usarão como nomes alternativos no certificado. Um cliente que se conecta por um nome não listado pode relatar uma incompatibilidade de certificado, mesmo que o serviço esteja acessível.
Se firewalldestiver habilitado, use a opção do YaST para abrir as portas RMT necessárias. Sempre que possível, restrinja o acesso à interface de rede ou zona correta. Conclua o assistente e revise o resumo; a SUSE afirma que o YaST habilita e inicia os serviços e temporizadores do systemd necessários.
3. Confirme o nome do servidor, o certificado e o serviço.
A partir de uma rede cliente, confirme se o FQDN escolhido resolve para o host RMT e se o HTTPS apresenta um certificado confiável para o cliente. O certificado da CA gerado pela RMT está armazenado em /etc/rmt/ssl/rmt-ca.crt; o certificado e a chave do servidor estão armazenados em /etc/rmt/ssl/rmt-server.crte /etc/rmt/ssl/rmt-server.key. Proteja a chave privada e mantenha o certificado da CA disponível para clientes que precisam confiar nele. Use o mesmo FQDN para registro que aparece no certificado do servidor.
Como selecionar e espelhar apenas os repositórios necessários?
4. Sincronizar metadados de produto e repositório
Após a configuração, sincronize o banco de dados RMT local com o SCC:
sudo rmt-cli sync
Isso atualiza as informações do produto e do repositório disponíveis para o RMT; não significa que todos os pacotes já foram baixados. A sincronização automática de metadados é gerenciada por [nome do serviço/ferramenta] rmt-server-sync.timer. Verifique o estado com:
systemctl status rmt-server-sync.timer
5. Encontre os identificadores de produto para o seu patrimônio.
Liste os produtos e repositórios disponíveis antes de habilitar qualquer coisa:
sudo rmt-cli products list --all
sudo rmt-cli repos list --all
Utilize os IDs ou as strings de produto relatadas pelo seu próprio servidor. Os IDs nos exemplos online podem ser diferentes, pois a disponibilidade depende de assinaturas, versões de produto, arquiteturas e dos metadados retornados pelo SCC.
6. Ative os produtos necessários
Habilite os produtos que os clientes realmente usam. Por exemplo, após confirmar que a string do produto está presente na sua saída, você pode executar o seguinte comando:
sudo rmt-cli products enable SLES/15/x86_64
Habilitar um produto também habilita seus repositórios associados, como repositórios de pool e de atualização. Se seus sistemas utilizam módulos ou extensões adicionais, verifique se esses produtos estão disponíveis e habilite apenas os necessários. Evite espelhar todos os produtos "por precaução": isso consome espaço de armazenamento e aumenta o tempo de sincronização.
7. Espelhe os pacotes e inspecione o resultado.
Inicie o espelhamento inicial manualmente para que você possa observar a conclusão e solucionar problemas antes de confiar no agendamento:
sudo rmt-cli mirror
O RMT armazena o conteúdo espelhado em um diretório específico /var/lib/rmt/public/repopor padrão. Verifique o espaço em disco disponível e revise a saída do comando. O agendamento diário de espelhamento é gerenciado por [nome do serviço/método rmt-server-mirror.timer]; verifique seu status com: [comando].
systemctl status rmt-server-mirror.timer
Uma sincronização de metadados bem-sucedida por si só não comprova que os clientes podem instalar atualizações. Os repositórios selecionados precisam ser espelhados, o cliente precisa conseguir acessar o servidor e o acesso ao produto precisa ser válido para a organização.
Como faço para registrar um cliente no servidor local?
8. Faça o teste primeiro com um cliente.
Em um cliente SLES compatível, registre-o no nome de host RMT. A SUSE documenta este comando da seguinte forma:
sudo SUSEConnect --url https://rmt.example.com
Substitua o host de exemplo pelo FQDN coberto pelo seu certificado. Normalmente, os clientes não precisam das credenciais de espelhamento do SCC; o host RMT usa essas credenciais para sincronizar em nome da organização. Para sistemas que precisam de ajuda para importar a CA do RMT, a SUSE fornece um rmt-client-setupscript no servidor. Consulte o guia do cliente atual e verifique a impressão digital do certificado ou a cadeia de confiança antes de aceitar um certificado.
Você também pode configurar o registro durante a instalação com o regurl=https://rmt.example.comparâmetro de inicialização ou usar o módulo de Registro de Produto do YaST e escolher o servidor de registro local. Para instalações automatizadas, a SUSE documenta uma opção AutoYaST. Escolha um método que se adapte à forma como seus sistemas são provisionados.
9. Verifique o registro e o acesso ao pacote.
No cliente, confirme se o registro foi concluído, se os produtos e repositórios esperados aparecem e se os metadados do repositório podem ser atualizados. Por exemplo, inspecione as definições do repositório com `git log` zypper lre atualize com ` sudo zypper refreshgit repository`. Em seguida, teste uma consulta ou atualização de pacote em uma janela de manutenção. Se um módulo estiver faltando, verifique se ele está habilitado e espelhado no RMT antes de alterar os arquivos do repositório no lado do cliente.
Teste um caminho de atualização padrão em um cliente representativo antes de redirecionar uma grande frota. Após o sucesso desse teste, atualize os perfis de provisionamento, os parâmetros de inicialização da instalação ou o gerenciamento de configuração para que os sistemas novos e reconstruídos usem a mesma URL do RMT.
O que você deve verificar quando algo dá errado?
| Sintoma | Primeiras verificações |
| O cliente não consegue acessar o servidor de registro. | Verifique o DNS, o roteamento, as regras do firewall e se o serviço web RMT está escutando na interface e porta esperadas. |
| Aviso de certificado HTTPS | Utilize o FQDN do servidor na URL; confirme se ele corresponde ao certificado e se o cliente confia no certificado da CA da RMT. |
| O cadastro funciona, mas o repositório está indisponível. | Execute o comando rmt-cli sync, confirme se o produto está disponível para a organização SCC, habilite o repositório e, em seguida, execute o comando novamente rmt-cli mirror. |
| O espelhamento para ou o disco fica cheio. | Verifique o armazenamento e /tmpa capacidade do repositório. O RMT pode precisar de um espaço temporário considerável durante o download de metadados grandes do repositório. |
| Apenas os sistemas SLE mais antigos falham. | Verifique os limites de suporte. A RMT não registra clientes SLE 11 e versões anteriores; planeje uma estratégia legada com suporte ou um caminho de atualização. |
O que muda se você estiver migrando do SMT?
Considere a migração como uma alteração de dados e fluxo de trabalho, não como uma simples atualização de pacote. A SUSE recomenda um novo host SLES 15. O processo documentado de exportação/importação é utilizado smt-data-exportno SMT e rmt-data-importno novo servidor após a sincronização do RMT com o SCC. As configurações de repositórios em fase de preparação não são exportadas; apenas os repositórios marcados para espelhamento são transferidos, e os produtos expirados não ficam disponíveis no RMT. Os jobs do cliente SMT e o status dos patches não são exportados. Planeje recriar os processos operacionais que dependiam desses recursos e valide os registros de cadastro antes de redirecionar os clientes de produção.
Mantenha o serviço antigo disponível durante uma transição controlada, caso suas políticas de suporte e segurança permitam. Migre um pequeno grupo de clientes, confirme o registro, os repositórios, a confiança nos certificados e atualize o comportamento, e então expanda. Não desative o host SMT até que os clientes legados e quaisquer fluxos de trabalho não suportados tenham um destino explícito.
Como saber se a configuração está pronta?
- O FQDN do RMT é resolvido corretamente e o HTTPS usa um certificado confiável pelos clientes.
- O host RMT sincroniza os metadados SCC atuais e espelha todos os repositórios de produtos exigidos pelos clientes do projeto piloto.
- Um cliente compatível se registra no URL local e visualiza os repositórios de produtos desejados.
- Um cliente pode atualizar os metadados do repositório e concluir uma operação de pacote controlada.
- A capacidade do disco, o espaço temporário, os temporizadores, os registros, o backup e a renovação de certificados têm um proprietário e um plano de monitoramento.
O RMT centraliza o registro e a entrega de pacotes, mas não elimina a necessidade de gerenciar assinaturas, seleção de produtos, ciclo de vida do cliente, confiança em certificados, backups e testes de atualização. Para obter os procedimentos exatos e as diferenças específicas de cada versão, consulte o Guia da Ferramenta de Espelhamento de Repositório do SLES 15 SP7 da SUSE , o capítulo sobre migração de SMT para RMT , o capítulo sobre configuração do cliente RMT e o capítulo sobre espelhamento de repositório da SUSE .