Corrigir problema de conexão do console web do Cockpit no servidor SUSE Linux Enterprise.

Se o Console Web do Cockpit não se conectar a um host SUSE Linux Enterprise Server (SLES), primeiro tente acessar o endereço IP do Cockpit e https://SERVER_IP:9090, em seguida, verifique se o serviço cockpit.socketestá em execução e se o firewall permite o serviço na zona usada pela interface de rede do servidor. Em uma instalação padrão, essas verificações resolvem as causas mais comuns: URL ou porta incorreta, socket inativo, pacotes do Cockpit ausentes ou conexão de entrada bloqueada.

Este guia aplica-se a sistemas SLES que utilizam systemd e têm o Cockpit disponível nos seus repositórios de produtos configurados. O guia atual do Cockpit para SLES 16 da SUSE documenta os comandos de instalação e ativação de sockets descritos abaixo. A disponibilidade e os nomes dos pacotes podem variar de acordo com o pacote de serviços, módulo e nível de suporte do SLES. Portanto, em um host SLES 15 mais antigo, confirme se o Cockpit é oferecido pelos repositórios SUSE habilitados antes de tratar um erro de instalação como uma falha de serviço.

Comece pelo sintoma.

Use a mensagem de erro no navegador para identificar a causa. Um erro de tempo limite ou "o site não pode ser acessado" geralmente indica problemas de roteamento, regras de firewall ou um serviço de escuta inativo. Uma conexão recusada geralmente significa que nenhum serviço está aceitando conexões no endereço e porta selecionados. Uma página de login do Cockpit indica que o serviço web está acessível; um erro de autenticação posterior indica um problema separado de conta ou política. Um aviso de certificado significa que a negociação HTTPS foi bem-sucedida com o servidor, mas o navegador não confia no certificado ou em seu nome.

Por exemplo, suponha que um administrador não consiga abrir um servidor cujo endereço seja 192.0.2.25. Faça o teste https://192.0.2.25:9090a partir de uma máquina que deveria ter permissão para administrá-lo. O Cockpit normalmente usa HTTPS na porta 9090. Digitar apenas o endereço IP pode abrir um serviço diferente, e usar http://pode levar a um redirecionamento ou a um aviso do navegador em vez da tela de login esperada.

1. Verifique o URL e a acessibilidade.

Confirme o endereço atual do servidor no console do SLES ou em um inventário confiável e inclua a porta explicitamente:

https://192.0.2.25:9090

A partir do cliente, teste se a porta TCP 9090 está acessível. Em uma estação de trabalho administrativa Linux com o netcat instalado, execute:

nc -vz 192.0.2.25 9090

Uma conexão TCP bem-sucedida comprova apenas que a porta está acessível; não comprova que o login funcionará. Um tempo limite excedido sugere a verificação da zona de firewall ativa do servidor, de qualquer firewall de rede upstream, do roteamento e do acesso à VPN. Uma recusa sugere a verificação do listener no host SLES. Se o netcat não estiver disponível, teste a partir de um navegador ou use outra ferramenta de conectividade TCP aprovada, em vez de instalar um utilitário não aprovado em um host de produção.

2. Confirme se o Cockpit está instalado e se o seu socket está ativo.

Conecte-se via SSH ou console local e inspecione o socket. O Cockpit normalmente usa a ativação de socket do systemd: o systemd fica à escuta de uma conexão de entrada em nome do Cockpit e inicia o serviço web sob demanda. Por isso, a unidade principal a ser inspecionada geralmente é o `cockpit.socket` cockpit.socket, e não um serviço em execução contínua cockpit.service.

sudo systemctl status cockpit.socket
sudo ss -ltnp | grep ':9090'

Procure por um socket ativo/em escuta e um listener vinculado à porta 9090. Se a unidade estiver ausente, o Cockpit pode não estar instalado. Em uma versão do SLES cujos repositórios habilitados fornecem o padrão Cockpit, a SUSE documenta a instalação com:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Se o Zypper informar que o padrão não foi encontrado, verifique o produto, o pacote de serviços, os módulos habilitados, o status do repositório e o direito de suporte com o administrador do SUSE. Não adicione um repositório de terceiros não relacionado apenas para que o comando seja bem-sucedido. Após confirmar que o Cockpit está instalado, habilite e inicie seu socket:

sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket

Essa --nowopção inicia o socket imediatamente e o habilita para inicializações futuras. Se o systemd reportar uma unidade com falha, verifique o erro exato antes de reiniciá-lo repetidamente:

sudo journalctl -u cockpit.socket -b --no-pager
sudo journalctl -u cockpit.service -b --no-pager

3. Permita que o Cockpit acesse a zona de firewall ativa.

Um ouvinte ativo ainda pode estar inacessível se o firewall do host derrubar a conexão. O SLES usa o firewalld para gerenciamento de firewall nas versões atuais. Primeiro, identifique a zona ativa e a interface atribuída a ela:

sudo firewall-cmd --get-active-zones

Em seguida, adicione o serviço Cockpit nomeado à zona que contém a interface de gerenciamento. Substitua ` public<zona>` pela zona real relatada em seu host:

sudo firewall-cmd --zone=public --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=cockpit

O comando final deve retornar o resultado yes. Se a interface de rede estiver em uma zona diferente, abrir o serviço publicnão corrigirá as regras dessa interface. A documentação do Cockpit da SUSE usa o cockpitserviço firewalld; abrir o serviço especificado é preferível a liberar todo o tráfego ou desativar o firewall. Verifique também os grupos de segurança da nuvem, firewalls de perímetro, políticas de VPN e ACLs de rede se a regra do host estiver correta, mas o cliente ainda apresentar timeout.

Se a sua imagem SLES utiliza uma configuração de gerenciamento de firewall diferente, siga a política desse sistema em vez de aplicar comandos firewalld indiscriminadamente. Não limpe as regras do firewall nem desative o firewall em um servidor de produção administrado remotamente: isso pode expor serviços e interromper seu fluxo de gerenciamento atual.

4. Distinga uma falha de conexão de um problema de certificado ou de login.

Assim que a página de login carregar, o caminho de rede para o Cockpit estará funcionando. O Cockpit normalmente espera que as conexões do navegador usem HTTPS e apresenta um certificado TLS. Um aviso para um certificado autoassinado ou uma incompatibilidade de nome não significa que o socket esteja inativo. Para um host de laboratório, verifique a impressão digital por meio de um canal confiável antes de aceitar o aviso. Para sistemas gerenciados, instale um certificado cujo nome do sujeito corresponda ao nome do host usado pelos administradores e cuja cadeia seja confiável pelos navegadores deles.

Se a página de login for exibida, mas as credenciais forem rejeitadas, verifique o nome de usuário, a senha, o estado da conta e a política de autenticação do servidor. O Cockpit geralmente autentica usando contas do sistema; não se trata de um banco de dados de usuários separado. Não insira senhas em comandos ou logs durante a solução de problemas. Se a página carregar, mas a interface permanecer em branco ou desconectar após o login, verifique o console do desenvolvedor do navegador e os logs recentes do Cockpit. Um proxy reverso também pode causar falhas se não suportar conexões WebSocket ou encaminhar o protocolo ou as informações do host incorretamente.

5. Analise os registros e as configurações de proxy quando as configurações básicas forem aprovadas.

Capture um breve trecho do log durante uma nova tentativa de conexão:

sudo journalctl -u cockpit.socket -u cockpit.service --since "10 minutes ago" --no-pager

Procure por erros de vinculação, erros de permissão ou de certificado e mensagens que coincidam com o horário do teste. Se o servidor estiver escutando localmente, mas um cliente remoto não conseguir se conectar, investigue o caminho de rede e a zona do firewalld antes de alterar a configuração do Cockpit. Se o acesso direto funcionar, mas o acesso por meio de um proxy falhar, compare temporariamente por meio de uma rota direta permitida e, em seguida, verifique o suporte à atualização do WebSocket do proxy e os cabeçalhos encaminhados. Evite alterar as configurações de origem ou TLS do Cockpit como primeiro passo; configurações incorretas de confiança do proxy podem comprometer a segurança.

Verifique o reparo

Após fazer uma alteração de cada vez, verifique os seguintes resultados:

• systemctl status cockpit.socketMostra a conexão ativa e em modo de escuta.
• O host SLES possui um serviço de escuta na porta esperada, normalmente TCP 9090.
• A regra de firewall está presente na zona atribuída à interface de gerenciamento.
• O cliente consegue acessar o servidor https://SERVER_IP:9090e visualiza a página de login do Cockpit.
• Após a autenticação, a página permanece conectada e o registro recente não contém nenhum erro de inicialização ou conexão correspondente.

Se o socket estiver ativo e as verificações locais forem bem-sucedidas, mas os testes TCP remotos ainda apresentarem tempo limite, a falha restante provavelmente está fora do Cockpit, como um firewall upstream, rota de rede, registro DNS ou regra de VPN. Se o serviço falhar em um sistema SLES que, de outra forma, é compatível, salve o status da unidade e a saída do journal e verifique a documentação da SUSE ou o canal de suporte para obter a configuração exata do service pack, em vez de aplicar correções destinadas a outra distribuição.

Referências oficiais

• SUSE: Administrando o SUSE Linux Enterprise Server usando o Cockpit
• Projeto Cockpit: Inicialização e ativação de sockets do systemd
• Projeto Cockpit: porta e endereço TCP
• Projeto Cockpit: HTTPS e certificados
• Projeto Cockpit: Perguntas frequentes sobre solução de problemas
• SUSE: Configuração do firewall e zonas do firewalld no SLES 15 SP5