unattended-upgrades nos containers: segurança no automático

Quase tudo no meu homelab roda em containers LXC, como contei no post LXC ou VM no Proxmox. São vários containers, cada um com o seu serviço, e cada um precisa receber as correções de segurança. Entrar em um por um para rodar apt upgrade é o tipo de tarefa que a gente esquece.

O Debian tem uma ferramenta própria para isso: o unattended-upgrades. Neste post explico o que ele faz, como configurar num container Debian e onde eu não usaria.

O que ele faz #

O unattended-upgrades instala atualizações sozinho, sem ninguém digitar nada. Pela wiki do Debian, a configuração padrão instala as atualizações de segurança, mas não novidades. Na prática, ele corrige falhas sem mudar versões de programas de uma hora para outra.

O arquivo de configuração padrão libera estas origens:

• o repositório principal do Debian da sua versão;
• o repositório de segurança (Debian-Security).

Repositórios de terceiros ficam de fora, a menos que você adicione.

Já está instalado? #

Antes de instalar, vale conferir. Dependendo do template usado para criar o container, o pacote pode já estar lá:

apt list --installed unattended-upgrades

Se aparecer na lista, falta só confirmar que está ligado, com o dpkg-reconfigure do próximo passo. Se não aparecer, instale.

Instalando num container #

Dentro do container, como root:

apt update
apt install unattended-upgrades apt-listchanges
dpkg-reconfigure unattended-upgrades

O último comando pergunta se você quer baixar e instalar as atualizações estáveis automaticamente. A wiki do Debian recomenda responder sim.

Quem dispara a rotina são os timers do próprio apt. Para conferir quando rodam:

systemctl list-timers 'apt-daily*'

Ajustando a configuração #

A wiki do Debian recomenda não editar o arquivo original. Copie para um arquivo seu e edite a cópia:

cp /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/52unattended-upgrades-local

As opções que mais importam num homelab:

• Unattended-Upgrade::Origins-Pattern: de onde vêm as atualizações. Descomente uma linha para incluir mais uma origem.
• Unattended-Upgrade::Mail: o e-mail que recebe o relatório. Vem vazio, então nada é enviado. A wiki avisa que precisa de um servidor de e-mail local configurado no container.
• Unattended-Upgrade::Automatic-Reboot: reinicia sozinho quando uma atualização pede. Vem como false.
• Unattended-Upgrade::Remove-Unused-Dependencies: remove dependências que sobraram. Também vem como false.

Num container LXC, o reinício automático pesa menos do que numa VM ou num servidor físico. Containers usam o kernel do host, como diz a documentação do Proxmox. Atualização de kernel dentro do container não existe: quem atualiza o kernel é o host.

Testando #

Para ver o que ele faria, com a saída detalhada:

unattended-upgrade -d

Os registros ficam em:

• /var/log/unattended-upgrades/, com o que a ferramenta decidiu e instalou;
• /var/log/dpkg.log, com cada pacote instalado.

Um checklist por container #

Para não esquecer nenhum, este é o roteiro que eu seguiria em cada container:

1. O container está no backup da noite? Se não, resolva isso primeiro.
2. O app vem do apt? Se vem de script, binário ou imagem Docker, a atualização automática não alcança o app, só o sistema.
3. Dá para ficar alguns minutos fora do ar? Uma atualização pode reiniciar o serviço. Para o DNS da casa, por exemplo, isso significa internet parada para todo mundo.
4. Instalar, rodar o unattended-upgrade -d e ler a saída.
5. Olhar os logs na semana seguinte para ver o que foi instalado.

Quem cuida do DNS sabe: quando ele cai, a família percebe antes de você. Conto como o meu funciona no post sobre o Technitium DNS.

Onde eu não usaria #

No host Proxmox. A documentação do Proxmox orienta atualizar o host com apt full-upgrade, não com apt upgrade. O motivo: o Proxmox é uma distribuição contínua sobre o Debian, e o upgrade não remove pacotes para resolver dependências, o que pode deixar o sistema atualizado pela metade. Atualização do host eu faço olhando, e com backup antes.

Em app com versão fixa. Se um container roda um app que quebra com atualização de biblioteca, a atualização automática vira um risco. Aí prefiro atualizar à mão, depois de ler as notas da versão.

Em app instalado fora do apt. O unattended-upgrades só cuida dos pacotes do apt. App instalado por script, binário baixado ou imagem Docker tem que ser atualizado do jeito dele.

E se uma atualização quebrar algo #

É para isso que serve o backup da noite. Aqui, o vzdump salva todos os containers às 21h, e eu já restaurei containers por ele sem problema. Conto a rotina no post sobre backup com vzdump.

Resumindo #

• unattended-upgrades instala só as atualizações de segurança por padrão, sem trocar versões.
• Configuração numa cópia: 52unattended-upgrades-local.
• E-mail e reinício automático vêm desligados. O e-mail precisa de servidor de e-mail local.
• Containers LXC usam o kernel do host, então reiniciar o container quase nunca é preciso.
• No host Proxmox, não: lá é apt full-upgrade, olhando.
• Backup antes de qualquer automação.

Correção de segurança que fica parada esperando eu lembrar é falha aberta. Automatizar a parte chata deixa o meu tempo para o que precisa de atenção.

Tags: debian, atualizacoes, seguranca, lxc