Guia de operação da nuvem

Este guia é para quem opera uma nuvem StrongLinux já implantada com o strongctl (edição Servidor). A instalação está no guia de instalação, e a atualização de versões, no guia de atualização.

Todos os comandos rodam como root no host onde o strongctl foi inicializado (o primeiro controller). A configuração da nuvem fica em /etc/strongctl/.

1. Comandos do dia a dia

Para usar o cliente openstack como administrador:

source /root/admin-openrc.sh
openstack server list --all-projects

2. Saúde da nuvem

strongctl verify confere, nó a nó:

• as units do systemd de cada papel;
• as portas das APIs e o certificado TLS de cada uma;
• emissão de token e catálogo;
• serviços de compute, agentes de rede, serviços de volume e de orquestração;
• um ciclo de segredo no Barbican (gravar, ler, apagar);
• com alta disponibilidade, o Galera (Synced), os nós do RabbitMQ, os servidores do RAFT do OVN e o VIP em exatamente um controller.

Rode o verify depois de qualquer mudança e antes de um upgrade (que exige o verify verde).

APIs publicadas

O HAProxy publica as APIs com TLS no endereço do controller (ou no VIP, com HA):

Atrás do HAProxy, cada API escuta só no endereço interno (127.0.0.1 no all-in-one). O metadata do Nova (8775) e o console noVNC (6080) são internos.

Logs

3. Credenciais e segredos

• O cofre /etc/strongctl/passwords.yml é cifrado com ansible-vault. A senha dele está em /etc/strongctl/.vault-pass (modo 0600).
• strongctl secrets show <nome> mostra um segredo. Se o nome não existir, o comando lista os nomes válidos.
• Senhas importantes: keystone_admin (usuário admin), barbican_kek (chave mestra dos segredos do Barbican), strongstack_secret_key.
• Guarde uma cópia de /etc/strongctl/ fora da nuvem (seção 5). Sem a barbican_kek, os segredos guardados no Barbican não podem ser recuperados.

4. Adicionar e manter nós

Adicionar um nó de computação ou de armazenamento

1. Instale o nó com a ISO (opção Compute ou Storage) ou com a imagem stronglinux-1.0-openstack-cloud-amd64.qcow2.
2. Autorize a chave SSH do root do controller no novo nó (/root/.ssh/authorized_keys).
3. Inclua o nó em /etc/strongctl/inventory.yml: o endereço em all.hosts e o nome no grupo do papel.

   all:
     hosts:
       cmp3: {ansible_host: 10.0.0.23, mgmt_ip: 10.0.0.23}
     children:
       compute:
         hosts:
           cmp3:

4. Prepare a base e implante:

   strongctl bootstrap
   strongctl deploy
   strongctl verify

Use o deploy completo, sem --role: ele só muda o nó novo, mas também roda o registro do compute no Nova (nova-manage cell_v2 discover_hosts), que fica no primeiro controller e não roda com --role compute.

Tirar um compute de serviço para manutenção

openstack compute service set --disable --disable-reason "manutenção" <host> nova-compute
openstack server list --all-projects --host <host>
openstack server migrate --live-migration <vm>     # ou desligue as VMs do host

Depois da manutenção: openstack compute service set --enable <host> nova-compute.

Reinício de um controller com alta disponibilidade

Reinicie um controller de cada vez e confira com strongctl verify antes de passar ao próximo. O Galera, o RabbitMQ e o OVN voltam ao cluster sozinhos. Se os três caíram ao mesmo tempo, siga a recuperação do Galera no guia de alta disponibilidade.

5. Cópia de segurança

O strongctl não faz backup automático. Guarde, fora da nuvem:

Os arquivos de configuração dos serviços (/etc/<serviço>/) não precisam de cópia: o strongctl deploy gera todos de novo a partir de /etc/strongctl/.

Para restaurar num controller novo: instale o sistema, restaure /etc/strongctl/ e as chaves do Keystone, rode strongctl bootstrap, importe os bancos (zcat bancos.sql.gz | mariadb) e rode strongctl deploy e strongctl verify.

6. Rotação das chaves de token (fernet)

Os tokens do Keystone são cifrados com chaves fernet em /etc/keystone/fernet-keys/. Gire as chaves periodicamente, por exemplo uma vez por semana. No primeiro controller:

runuser -u keystone -- keystone-manage fernet_rotate --keystone-user keystone --keystone-group keystone
strongctl deploy --role controller      # com HA: copia as chaves novas para os outros controllers

O Keystone mantém 3 chaves ativas, então os tokens já emitidos continuam valendo. Com um só controller, basta o primeiro comando.

7. Certificados TLS

• O certificado das APIs vale 825 dias e a CA interna, 10 anos. Para ver a validade:

  openssl x509 -enddate -noout -in /etc/strongctl/tls/api.crt

• Renovar o certificado interno: apague /etc/strongctl/tls/api.crt e rode strongctl deploy.
• Usar um certificado próprio: coloque api.crt (cadeia completa), api.key e ca.crt em /etc/strongctl/tls/, sem ca.key, e rode strongctl deploy.
• Nomes extras no certificado (por exemplo um nome DNS público): api_tls_names no globals.yml.

8. Segurança no dia a dia

• Atualizações: o unattended-upgrades aplica as correções de segurança do Ubuntu. As da StrongLinux chegam pelo canal stronglinux-1.0-security; numa nuvem, aplique com strongctl upgrade.
• AppArmor: os daemons do OpenStack rodam confinados (modo enforce). Para ver o que foi negado:

  journalctl -k | grep 'apparmor="DENIED"'

  Ajustes locais vão em /etc/apparmor.d/local/stronglinux.<unit>, seguidos de apparmor_parser -r /etc/apparmor.d/stronglinux.<unit>. Para diagnosticar, apparmor_mode: complain no globals.yml e strongctl deploy (só registra, não bloqueia).

• Integridade (AIDE): compara os arquivos todo dia; a base é renovada a cada strongctl deploy. Para conferir na hora: aide --check -c /etc/aide/aide.conf.
• Conta bloqueada depois de 5 senhas erradas (15 min): faillock --user <nome> --reset.
• SSH: depois de instalar as chaves, deixe PasswordAuthentication no.

9. Problemas comuns

Se o problema continuar, abra uma issue com a saída do strongctl verify e os logs do serviço (sem senhas). Veja a página de suporte.