community-scripts no Proxmox: leia o script antes de rodar

Instalei Vaultwarden, Pi-hole, AdGuard, Docker e Home Assistant pelo community-scripts. Como ele funciona e o que conferir antes de rodar como root.

Publicado
Leitura
5 min
Testado em
Proxmox VE 9.2
Neste post

Muita gente no mundo Proxmox começa do mesmo jeito: abre o shell do host, cola uma linha de comando copiada de um site e, cinco minutos depois, tem um container LXC com o aplicativo instalado e rodando. Esse site é o community-scripts, a coleção de scripts da comunidade conhecida como Proxmox VE Helper-Scripts.

Eu uso até hoje. Foi por ele que instalei o meu primeiro Vaultwarden, e também o Pi-hole, o AdGuard, o Docker e o Home Assistant. Neste post conto o que ele faz, como funciona por dentro e o cuidado que eu acho obrigatório antes de rodar um script como root no host.

O que é o community-scripts #

O projeto se descreve como instalações de um comando só para serviços, containers e VMs no Proxmox VE. Ele nasceu do trabalho do tteck, que criou e manteve sozinho os scripts originais por anos. Depois que ele faleceu, a comunidade assumiu o projeto, que hoje é mantido no GitHub pela organização community-scripts e tem o site community-scripts.org como vitrine.

O funcionamento, segundo o próprio repositório:

  1. você procura o aplicativo no site;
  2. copia o comando de uma linha da página do script;
  3. cola no shell do host Proxmox;
  4. escolhe entre a instalação padrão e a avançada e segue as perguntas.

Pelo README, os scripts suportam Proxmox VE 8.4, 9.0, 9.1 e 9.2, precisam de acesso root no host e de internet durante a instalação. Eu uso no Proxmox VE 9.2.

Como é a linha de comando #

O formato é sempre o mesmo: baixar o script do GitHub com curl e executar com bash. Para o Technitium DNS, por exemplo:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/technitiumdns.sh)"

Os scripts de container ficam na pasta ct/ do repositório. Cada um define o básico do container logo no começo: CPU, memória, disco, sistema e se ele é unprivileged. O do Technitium, por exemplo, cria um container Debian 13 unprivileged com 1 núcleo, 512 MB de RAM e 2 GB de disco. Esses valores podem ser trocados no modo avançado.

Padrão ou avançado #

  • Padrão: usa valores razoáveis de CPU, memória e disco e faz o mínimo de perguntas. É o caminho mais rápido.
  • Avançado: deixa configurar o container, a rede, o storage e algumas opções do aplicativo antes de instalar.

Para um serviço que vai ficar de verdade, o avançado compensa. Definir um IP fixo e o storage certo na criação poupa trabalho depois, principalmente para coisas como DNS, que precisam de endereço estável.

Depois de instalado, cada container ganha um ajudante pós-instalação, que o README descreve como o caminho para atualizar o aplicativo, mudar configurações e resolver problemas básicos.

O cuidado que eu acho obrigatório: ler antes de rodar #

Aqui está o ponto que mais importa neste post. Aquele bash -c "$(curl ...)" baixa um código da internet e executa como root, no host do Proxmox, a máquina que segura todo o resto. É exatamente a camada em que eu não deixo nem a IA mexer.

O projeto é aberto, popular e revisado pela comunidade, e isso conta muito. Mas a prática que eu recomendo é simples: leia o script antes de executar. Não precisa entender cada linha; precisa saber o que ele vai fazer.

Dá para baixar e olhar sem executar nada:

curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/technitiumdns.sh -o technitiumdns.sh
less technitiumdns.sh

O que eu olho:

  • De onde ele baixa o resto. O script de ct/ carrega funções compartilhadas de outro arquivo do projeto e, dentro do container, roda um script de instalação. Confira se tudo vem dos repositórios do próprio community-scripts e do site oficial do aplicativo.
  • Os recursos e o tipo de container. Prefira unprivileged, que é o padrão da maioria dos scripts.
  • O que ele instala dentro do container. Pacotes, serviços do systemd, portas.

Ler o script também ensina. Dá para ver como um LXC é criado com pct, o que vai para a configuração do container e como o serviço do aplicativo é montado no systemd.

O que eu instalei e o que ficou #

Pelo community-scripts passaram por aqui:

  • Vaultwarden: o meu primeiro cofre de senhas veio de um script desses. Hoje o Vaultwarden é o cofre da família.
  • Pi-hole e AdGuard: os dois para bloqueio de anúncios e DNS. Hoje quem faz esse papel aqui é o Technitium DNS, assunto de um post desta semana.
  • Docker: instalei, mas ainda uso pouco. Quase tudo continua em LXC, pelos motivos que contei no post sobre LXC ou VM no Proxmox.
  • Home Assistant.

A lista completa do que roda hoje está no post sobre os apps self-hosted do meu homelab.

Antes de rodar o próximo script #

Depois de perder tudo uma vez, eu recomendo: antes de instalar qualquer coisa nova, confira se o backup da noite rodou. Script de instalação mexe no host, cria storage, altera configuração. Se algo der errado, quero poder voltar. Como faço o backup está no post sobre vzdump depois de perder tudo.

Resumindo #

  • O community-scripts cria containers LXC com aplicativos prontos em poucos minutos.
  • Copie o comando só da página oficial e confira a URL.
  • Leia o script antes de rodar: ele executa como root no host do Proxmox.
  • Use o modo avançado para serviços que vão ficar, com IP fixo e storage certo.
  • Tenha backup antes de instalar qualquer coisa no host.

Para mim, ele continua sendo o jeito mais rápido de testar um aplicativo novo no homelab. Só não abro mão de saber o que estou executando.

Fontes e documentação