Administrar uma máquina Linux é uma sequência de SSH: systemctl para os serviços, journalctl para os logs, ferramentas de disco para o resto. O Cockpit reúne tudo isto numa página web na porta 9090, autenticada com as contas do próprio sistema, e o Fedora Server traz o painel de origem.

Este guia assenta na release 370 (22 de outubro de 2026): instalação por distro, primeiro acesso, operação no dia-a-dia, armadilhas e a comparação com Zabbix e Webmin.

Neste artigo

Porquê um painel além do SSH

O SSH (Secure Shell) é directo: o comando faz exactamente o que escreves, sem camadas entre ti e o sistema. O preço é a falta de vista geral — descobres o problema quando olhas para a carga, e cada máquina nova é uma sessão extra para vigiar.

Os painéis de monitorização resolvem a vista geral em grande: o Zabbix exige servidor central, base de dados e um agente em cada máquina — demais para duas ou três máquinas.

O Cockpit fica no meio: é um painel de operação, não de observação. Lê o sistema onde corre através do systemd, do journald e do D-Bus, por isso não adiciona nada à máquina. Abres o browser, entras com o teu utilizador de sistema e os serviços, os logs, os discos, a rede e um terminal ficam na mesma página. Para uma PME sem equipa de infra-estrutura, é o equilíbrio certo no dia-a-dia.

Instalar e activar o painel

No Debian e no Ubuntu, o Cockpit vive nos repositórios oficiais, e os backports trazem versões mais recentes — em Debian habilitam-se à mão, no Ubuntu LTS vêm activos.

sudo apt install cockpit
sudo systemctl enable --now cockpit.socket

No Fedora e no RHEL o instalador é o DNF, e o Fedora Server já traz o painel de origem:

sudo dnf install cockpit
sudo systemctl enable --now cockpit.socket
sudo firewall-cmd --add-service=cockpit
sudo firewall-cmd --add-service=cockpit --permanent

O passo comum a todas as distros é a activação do cockpit.socket. Com socket activation, o serviço web só arranca à primeira ligação e não gasta memória parado:

systemctl status cockpit.socket

O painel de base cobre serviços, logs, storage e rede. As apps extra instalam-se por pacote com o prefixo cockpit-: os contentores Podman levam a cockpit-podman.

sudo apt install cockpit-podman    # Debian e Ubuntu
sudo dnf install cockpit-podman # Fedora e RHEL

Primeiro acesso na porta 9090

Aponta o browser para https://ip-do-servidor:9090 e entra com a conta de sistema — o mesmo utilizador e password de que precisarias em SSH. O certificado da primeira visita é auto-assinado: avança o aviso do browser e segue.

A autenticação passa pelo PAM (Pluggable Authentication Modules): as restrições de conta do sistema valem para o painel como para o SSH. Para tarefas administrativas fundas, o Cockpit pede autorização sudo na mesma sessão.

Para retirar o painel de vez, o caminho é o mesmo socket: sudo systemctl disable --now cockpit.socket. Sem socket activo, não há porta aberta nem serviço a correr.

O que se faz no painel

Serviços e logs

A lista de serviços mostra as units do systemd com o estado ao minuto: recarregar, parar ou activar um serviço é um clique. Os logs chegam do journald com filtros por prioridade e por unidade, para saltar do erro ao registo exacto sem abrir terminal.

Storage

Na secção de storage, o Cockpit cria e redimensiona grupos e volumes LVM (Logical Volume Manager), monta arrays RAID (Redundant Array of Independent Disks) em mdadm e escreve a fstab, com a alteração à vista antes de a aplicar. A 370 passa a reconhecer slots de chave TPM2 (Trusted Platform Module) no módulo de storage e traz pontos de montagem UTF-8.

Rede

A rede fala com o NetworkManager: bonds, bridges e VLANs criam-se em formulário, sem editar ficheiros de configuração.

Containers Podman

Com a app cockpit-podman, os containers Podman entram no painel: imagens tiradas de um registry público, arranque e paragem, e o log de cada container legível no browser.

Terminal web

O terminal web corre sobre SSH: no selector de máquinas, o Cockpit liga por SSH a outros servidores e administra cada um numa aba própria — a frota alcança-se desde um browser, sem instalar nada nas máquinas.

Armadilhas do Cockpit

A porta 9090 precisa de regra na firewall. Nos Red Hat-like o serviço cockpit costuma estar aberto de fábrica — se não estiver, entram os comandos do bloco de instalação. Com ufw:

sudo ufw allow 9090/tcp

Restringe a abertura à rede interna: a 9090 é uma página de login. Num servidor com IP público, fecha a porta e acede por túnel.

O painel entra com a mesma password do SSH. Quem fecha o SSH a passwords deixa o painel a pedir password na mesma: troca por SSO (Single Sign-On) com Kerberos, restringe utilizadores em /etc/cockpit/disallowed-users ou usa um módulo PAM de segundo factor.

O Cockpit mantém a vista curta: com o pacote cockpit-pcp instalado, a página de Metrics mostra histórico, e continua sem alertas configuráveis. Quem precisa de avisos de madrugada instala monitorização — Zabbix para a frota, Beszel ou Monit para o caso leve.

O TLS auto-assinado incomoda todos os dias. Num servidor com domínio próprio, coloca o cockpit-ws atrás de um proxy reverso com Let's Encrypt — com hostname em vez de IP, o aviso do browser desaparece. O proxy tem de suportar WebSockets, e o /etc/cockpit/cockpit.conf precisa de Origins (e ProtocolHeader se o proxy fizer TLS) — sem isso o login falha sem explicar porquê.

Cockpit vs Zabbix vs Webmin

A leitura rápida: o Cockpit opera o estado do momento, o Zabbix observa padrões durante semanas e o Webmin configura o servidor a fundo, com superfície de ataque proporcional. Em equipa pequena, Cockpit no dia-a-dia e monitorização ao lado gasta menos horas.

Critério Cockpit 370 Zabbix Webmin
Função Operar uma máquina — serviços, logs, discos, containers Monitorizar e alertar sobre máquinas e serviços Configurar servidores a fundo pelo browser
Alertas Estado do momento, histórico com cockpit-pcp — sem alertas configuráveis Núcleo do produto — triggers, e-mail, webhooks Básicos — módulo System and Server Status
Origem dos dados Sem agente — systemd, journald e D-Bus directos Agente próprio em cada máquina monitorizada Módulos Perl no próprio servidor
Âmbito Uma máquina por sessão, outras por SSH Frotas inteiras a partir de um servidor central Uma máquina por instância
Instalação Um pacote e um socket, pronta em minutos Servidor central, base de dados, frontend e agentes Um pacote, superfície muito maior

Artigos Relacionados

Fontes Oficiais