KINGAI OS Server | Edição servidor

Versão e status

Versão atual 0.1.0-dev, lançada em 2026-10-06, arquitetura amd64, sem ambiente desktop. É uma prévia para desenvolvedores de servidor, sem certificação para produção; não a implante em um servidor que esteja rodando serviços em operação.

O que está incluído

• Instalação headless mínima (conforme as notas de lançamento)
• Login remoto OpenSSH
• Runtime de contêineres Podman
• Inicialização com cloud-init
• Fail2ban e Chrony

Posicionamento: a máquina sem desktop, entregue às ferramentas

O Server é voltado a servidores headless, máquinas virtuais e ambientes de contêineres: não há ambiente desktop, e depois de instalado o que você tem diante de si é a linha de comando acessada por login SSH. Seu lugar na família de produtos é dar a quem «quer controlar um servidor por conta própria» um ponto de partida limpo — o sistema traz apenas o necessário para rodar serviços, e os serviços e runtimes de agente escolhidos pelo usuário são instalados por cima, com limites de permissão definidos pelo próprio usuário.

Como o Desktop, ele compartilha a mesma base Linux e o mesmo mecanismo de configuração por edição; a diferença está no conteúdo da configuração: o Server instala o conjunto headless mínimo. Para a operação, isso significa que comportamentos da camada base validados na edição desktop valem igualmente para a edição servidor, sem tropeçar duas vezes no mesmo problema.

Componentes centrais, explicados um a um

OpenSSH

A porta de entrada do login remoto. O gerenciamento diário da edição servidor começa basicamente por ele: login por chave, execução remota de comandos, transferência de arquivos. A documentação de instalação inclui expressamente o item «login SSH por chave» em sua lista de verificação de aceite, o que mostra que é uma direção que o fornecedor pretende validar a sério — mas a prévia atual ainda não apresentou uma conclusão de aceite.

Podman

Runtime de contêineres cuja característica é não ter daemon e poder rodar contêineres em modo rootless por padrão — um usuário comum já consegue iniciar seus próprios contêineres, sem entregar privilégios de root a um serviço residente. Ao implantar serviços auto-hospedados com ele, a conta das permissões fica muito mais fácil de fechar.

cloud-init

A ferramenta de inicialização na primeira inicialização da máquina: definir o nome do host, gravar chaves públicas SSH, criar usuários e rodar scripts de primeira inicialização — tudo pode ser definido em um único arquivo de configuração antes de ligar a máquina. Tanto em máquinas virtuais de provedores de nuvem quanto em plataformas de virtualização próprias, ele é o elo que transforma «configurar cada máquina manualmente» em «configuração como implantação».

Fail2ban

Uma ferramenta de guarda que observa os logs de login: se o mesmo endereço tenta repetidamente senhas por SSH, ele bloqueia esse endereço por um período. Para um servidor exposto à rede, é a camada de proteção contra força bruta de menor custo.

Chrony

Serviço de sincronização de relógio. Carimbos de data e hora dos logs, validação de certificados e tarefas agendadas em um servidor dependem todos de o relógio do sistema estar certo, e o Chrony cuida disso silenciosamente. Ele não chama atenção, mas, se o relógio desviar, todos os logs vão induzi-lo ao erro na hora de investigar um problema.

Para começar, use assim

• Ambiente de experimentação: monte, em uma máquina virtual, um servidor de testes que fique ligado por muito tempo; pratique implantação e reversão, e, se estragar, restaure o snapshot
• Operação experimental de serviços auto-hospedados: rode primeiro projetos pessoais e ferramentas internas pequenas em contêineres, valide a estabilidade e só depois discuta se vai para produção
• Campo de testes de contêineres: experimente novas combinações de serviços com o Podman rootless, sem tocar em nada da máquina principal

Antes de implantar de verdade, passe por esta lista

• Verificações somente de leitura primeiro: cat /etc/os-release e uname -a para identificar o sistema, systemctl --failed para ver se algum serviço falhou ao iniciar, journalctl -p err -b para passar os registros de erro da inicialização atual
• Deixe uma saída para operações remotas: antes de atualizações ou mudanças grandes, confirme que o console fora de banda funciona, que os snapshots foram feitos e que a janela de reversão é suficiente — é um princípio obrigatório escrito na documentação de instalação
• Faça backup externo e criptografado dos dados importantes e mantenha à mão uma mídia de recuperação inicializável
• Identifique o disco antes de agir: o instalador pode formatar o disco de destino; opere apenas sobre o disco que você autorizou expressamente

O que está no roteiro e o que não existe agora

O roteiro que a documentação do produto lista para o Server inclui: console gráfico Cockpit (instalado apenas por opção expressa e obrigatoriamente com autenticação, não instalado por padrão), serviços rootless gerenciados por Quadlet, backups gerenciados, janelas de patches, trilhas de auditoria, modelos de firewall por política, resumos de vulnerabilidades, registro de frotas com confiança zero e recuperação remota segura. Tudo isso são metas; nenhum item foi entregue na 0.1.0-dev. Também é preciso deixar claro: a prévia atual não tem certificação para produção e não se pode afirmar que ela tenha endurecimento (hardening) de nível de produção por padrão; a imagem não é assinada; e o status da certificação de instalação é o mesmo da edição desktop: não aprovada.

Ver a documentação de instalação → Ir para a central de downloads → Ler antes a página de segurança → Relatar problemas (GitHub Issues) →