Como registrar uma máquina SLES 15 no SUSE Manager offline

Uma máquina SLES 15 não precisa de acesso direto à Internet para se tornar um cliente gerenciado do SUSE Manager. O que ela precisa é de acesso de rede confiável ao servidor ou proxy interno do SUSE Manager, além dos canais de produto SLES corretos, repositório de inicialização, chave de ativação e material de confiança já disponíveis nesse ambiente.

Essa distinção é importante. "Registro de cliente offline" geralmente significa que o host SLES não consegue acessar o SUSE Customer Center ou repositórios públicos, mas consegue acessar um sistema SUSE Manager interno. Uma implementação do SUSE Manager totalmente isolada da internet representa um problema de arquitetura maior: o conteúdo do repositório precisa ser importado para o ambiente desconectado usando métodos de espelhamento compatíveis. A SUSE documenta isso separadamente em seu guia de Configuração Desconectada .

O objetivo deste procedimento não é apenas fazer o cliente aparecer na lista de Sistemas. Um bom resultado apresenta quatro sinais visíveis: o host está registrado com a chave de ativação e o canal base corretos, o cliente Salt está em execução e se comunicando com o gerenciador, os metadados dos pacotes vêm do SUSE Manager em vez de repositórios públicos e uma ação de gerenciamento simples, como uma atualização ou verificação de estado, é concluída com sucesso.

O que significa “offline” antes de começar.

Para este guia, o cliente SLES 15 não tem acesso direto à Internet. Ele pode resolver e alcançar o servidor SUSE Manager interno ou o Proxy por FQDN através da rede. O gerenciador já possui o conteúdo necessário do SLES 15 sincronizado. Se o seu servidor SUSE Manager estiver desconectado da Internet, prepare e sincronize esse conteúdo primeiro usando o fluxo de trabalho para ambientes desconectados documentado pela SUSE antes de tentar a integração do cliente.

A documentação atual do cliente da SUSE também observa que o SLE 15 usa Python 3 por padrão e que os scripts de inicialização criados para Python 2 devem ser regenerados. Após uma atualização ou migração do SUSE Manager, também é recomendável regenerar os scripts de inicialização antes de integrar novos sistemas. Consulte Registrar clientes com um script de inicialização .

Etapa 1: Verifique se os canais SLES corretos estão sincronizados.

Antes de acessar o cliente, confirme se o SUSE Manager possui a versão exata do SLES, o pacote de serviços, a arquitetura e os módulos necessários para essa máquina. Por exemplo, um host SLES 15 SP7 x86_64 não deve ser inicializado com conteúdo destinado a um pacote de serviços ou arquitetura diferente.

Na interface web do SUSE Manager, verifique os canais do produto e o estado de sincronização. Os nomes específicos dos canais variam de acordo com a versão e os módulos habilitados; portanto, não copie o rótulo de um canal de outro ambiente sem verificá-lo.

Exemplo ilustrativo de visualização do canal: confirme se a família de produtos SLES 15 e os módulos necessários estão sincronizados antes de criar o repositório de inicialização.

Verificação de qualidade: o produto base e todos os canais necessários para a sua chave de ativação estão totalmente sincronizados. Se a sincronização estiver incompleta, pare aqui. O registro pode funcionar parcialmente e falhar caso os pacotes de cliente necessários não possam ser baixados.

Etapa 2: Confirme ou gere o repositório de inicialização.

Todo cliente precisa ter acesso a um repositório de inicialização contendo os pacotes usados ​​para a integração inicial. O SUSE Manager normalmente cria e regenera repositórios de inicialização automaticamente após a sincronização dos canais de produto necessários, mas você também pode gerar um manualmente.

Em um servidor SUSE Manager 5.x conteinerizado, primeiro acesse o contêiner do servidor:

mgrctl term

Em seguida, liste os destinos de repositório de inicialização disponíveis:

mgr-create-bootstrap-repo -l

Use a lista de repositórios para identificar o destino que corresponde à versão e à arquitetura do SLES que você está integrando.

Crie o repositório de inicialização correspondente, caso ele esteja ausente ou precise ser regenerado:

mgr-create-bootstrap-repo -c SLE-version-x86_64

A SUSE documenta a localização do repositório de inicialização em /srv/www/htdocs/pub/repositories/. Se vários produtos compartilharem uma base de código, a ferramenta poderá solicitar que você especifique o canal pai correto. O procedimento atual está documentado em Repositório de inicialização .

Uma compilação bem-sucedida do repositório significa que os pacotes iniciais do Salt e de registro podem ser disponibilizados dentro da rede gerenciada.

Quando mudar de abordagem: se o repositório não puder ser gerado porque os canais obrigatórios estão ausentes, não tente contornar a falha copiando RPMs aleatórios para o cliente. Corrija primeiro a sincronização do produto ou a importação de conteúdo desconectado.

Etapa 3: Crie uma chave de ativação com a atribuição de canal desejada.

Uma chave de ativação é mais do que um token de registro. Ela determina comportamentos importantes de integração, incluindo os canais e grupos de software atribuídos ao cliente. Crie uma chave específica para a versão e função do SLES que você está registrando.

Na interface web, abra a configuração da chave de ativação e verifique se o canal base e os canais filhos correspondem à máquina SLES de destino. Evite reutilizar uma chave criada para um pacote de serviços diferente apenas porque o registro em si foi bem-sucedido.

A chave de ativação deve mapear o novo host SLES 15 para os canais internos exatos que você pretende que ele utilize.

Verificação de qualidade: a chave de ativação resolve para um canal base inequívoco para o sistema operacional e a arquitetura do cliente. Se vários canais pai tornarem o mapeamento confuso, corrija isso antes de executar o script de inicialização.

Passo 4: Gere um novo script Bootstrap

A SUSE recomenda o uso mgr-bootstrappara criar um script de registro. No SUSE Multi-Linux Manager 5.1, os dois argumentos obrigatórios são --activation-keyse --script.

mgrctl term
mgr-bootstrap --activation-keys=<ACTIVATION_KEY> --script=bootstrap-sles15-offline.sh

O script gerado também pode ser criado na interface web em Administração > Configuração do Gerenciador > Script de Inicialização . Para um design baseado em proxy, gere o script para o FQDN do proxy em vez de editar silenciosamente as referências do servidor posteriormente.

Gere um novo script vinculado à chave de ativação e ao servidor ou proxy que o cliente offline possa efetivamente acessar.

Mantenha o SSL ativado. A SUSE adverte explicitamente contra a desativação do SSL na configuração de inicialização. Em uma rede isolada, a confiança no certificado ainda é importante, pois o cliente precisa verificar se está se comunicando com o sistema de gerenciamento correto.

Etapa 5: Teste a resolução de nomes, o roteamento e a acessibilidade do certificado a partir do cliente.

Antes de executar o script, teste o caminho interno do SLES 15 para o SUSE Manager. As verificações exatas dependem da sua topologia, mas, no mínimo, verifique a resolução de DNS e a acessibilidade HTTPS para o FQDN do gerenciador ou proxy usado pelo script.

getent hosts suma.example.com
curl -I https://suma.example.com/pub/

Se o ambiente usar o método de contato Salt padrão, o cliente também deverá ser capaz de estabelecer a conexão Salt necessária com o gerenciador. A documentação de registro de linha de comando do SUSE identifica as portas 4505 e 4506 para comunicação com o Salt. Consulte Registrar clientes na linha de comando .

A etapa de transferência deve usar o gerenciador interno ou o endereço do Proxy; o acesso direto à Internet não é necessário para o cliente.

Verificação de qualidade: o cliente resolve o mesmo FQDN incorporado no script de inicialização e consegue acessá-lo sem recorrer a uma rota pública. Se isso falhar, corrija o DNS, o firewall, o roteamento do proxy ou a confiança da CA antes de continuar.

Etapa 6: Copie o script de inicialização para a rede isolada.

Se o cliente puder acessar o serviço web do SUSE Manager diretamente, baixe o script de inicialização do gerenciador. Se o cliente estiver em um segmento mais restrito, transfira o arquivo por um mecanismo interno aprovado, como SCP, através de um servidor intermediário ou mídia removível. O script em si não elimina a necessidade de conectividade contínua com o gerenciador interno; ele apenas lida com a configuração inicial.

curl -O https://suma.example.com/pub/bootstrap/bootstrap-sles15-offline.sh
chmod 700 bootstrap-sles15-offline.sh

Quando a transferência HTTP direta for proibida, verifique o checksum do script após movê-lo pelo seu processo de transferência controlado. Isso é especialmente útil em ambientes isolados da internet ou de alta segurança.

Passo 7: Execute o script de inicialização como root e fique atento a falhas no repositório ou no certificado.

Execute o script localmente no cliente SLES:

sudo ./bootstrap-sles15-offline.sh

O script instala os componentes Salt necessários, adiciona o material de confiança, aplica a chave de ativação e inicia o processo de integração. Os nomes exatos dos pacotes podem variar de acordo com o SUSE Manager e a versão do SLES. A documentação atual do SUSE utiliza cada vez mais o pacote Salt, venv-salt-minionenquanto alguns caminhos de inicialização do SLES 15 podem começar com salt-minione depois fazer a transição durante a integração.

Observe a saída do bootstrap em busca de erros de certificado, pacotes indisponíveis, incompatibilidades de repositório ou problemas com a chave de ativação, em vez de julgar o sucesso apenas pela última linha.

Verificação de qualidade: não há erros de resolução de pacotes, falhas de confiança TLS ou referências a repositórios públicos inacessíveis ao cliente offline. Se o script tentar usar repositórios incorretos, revise os passos de 1 a 4 em vez de executá-lo repetidamente.

Etapa 8: Verifique o cliente no SUSE Manager e teste o tráfego de gerenciamento.

Após a conclusão do processo de integração, abra o Gerenciador de Sistemas e localize o novo cliente. Verifique o nome do host, o canal base, o grupo do sistema e o status atual. Um sistema listado é um ponto de verificação necessário, mas não constitui o teste de aceitação completo.

O registro só é concluído quando o sistema exibe a atribuição de canal esperada e o cliente Salt permanece ativo.

No cliente, verifique o nome do serviço que corresponde à pilha Salt instalada:

systemctl status venv-salt-minion
# or, where applicable:
systemctl status salt-minion

Em seguida, execute uma ação de gerenciamento de baixo risco a partir do SUSE Manager, como atualizar os dados do pacote ou executar um estado/consulta inofensiva. Confirme se a ação foi concluída e se o cliente se conectou novamente em seguida.

Como avaliar se o cadastro offline é realmente bom?

Padrões de falha comuns e o que eles geralmente significam

O script não consegue baixar um pacote.

Primeiro, compare o repositório de inicialização e o mapeamento do canal da chave de ativação com a versão exata do SLES do cliente. A SUSE alerta que as informações do repositório devem corresponder ao canal base; caso contrário, o processo de inicialização não poderá recuperar os pacotes corretos.

O cliente se registra, mas as operações de empacotamento falham.

Verifique se os repositórios locais sobreviveram de uma configuração anterior. O processo de inicialização do Salt do SUSE foi projetado em torno de repositórios servidos pelo SUSE Manager, e repositórios atribuídos localmente podem interferir no gerenciamento consistente de canais. Em um ambiente offline, quaisquer referências remanescentes a repositórios públicos têm alta probabilidade de falhar.

O serviço Salt inicia, mas o sistema permanece inativo.

Valide o DNS, a política de firewall e o método de contato. Se a conectividade Salt padrão não for possível através do limite da rede, a SUSE documenta o SSH Push como uma alternativa para clientes em zonas protegidas por firewall ou desconectadas. Esta é uma alteração de projeto, não um pequeno ajuste de inicialização, portanto, use-a somente quando o modelo de rede realmente exigir.

Um script de inicialização copiado funcionava antes da atualização, mas agora não funciona mais.

Recompile-o. A SUSE recomenda recriar os scripts de inicialização após migrações e ao integrar sistemas SLE 15 que, de outra forma, poderiam herdar suposições antigas do Python.

Limitações deste método

Este procedimento não faz com que o conteúdo do SUSE Manager apareça magicamente em um ambiente isolado (air gap). Se o gerenciador não conseguir acessar o SUSE Customer Center, você ainda precisará de um fluxo de trabalho de conteúdo desconectado compatível, como espelhamento assistido por RMT/SMT ou outro design de sincronização documentado. O script de inicialização também não substitui o acesso à rede entre o cliente e seu Gerenciador ou Proxy interno após o registro.

Por fim, os comandos e nomes de serviços podem variar entre as gerações do SUSE Manager e os pacotes de serviços do SLES. Este artigo utiliza o fluxo de trabalho de inicialização atual do SUSE 5.x como ponto de referência, mas você deve seguir o procedimento de acordo com a documentação da versão exata instalada em seu ambiente.

Referências oficiais

• SUSE: Registre clientes com um script Bootstrap
• SUSE: Repositório de inicialização
• SUSE: Registrar clientes na linha de comando
• SUSE: Configuração desconectada