Antes de rodar um script da comunidade no seu host Proxmox: cinco coisas para ler

Scripts da comunidade são realmente bons. Carregam conhecimento que alguém pagou com noites perdidas, tratam os casos chatos em que você esbarraria à meia-noite, e para muitas tarefas o script é melhor que o que você escreveria. Este texto não é um argumento contra eles.

É sobre uma lacuna específica. Uma instalação por pacote e um script colado em uma linha parecem igualmente corriqueiros na tela, e não são nem de longe a mesma coisa.

O que um pacote dá e uma linha colada não

Uma assinatura. Pacotes são assinados e a assinatura é conferida. Um endereço só é conferido contra a sua suposição de que o endereço está certo.

Uma versão. Você consegue dizer qual versão tem, e quem te ajuda também. "O script do readme, umas semanas atrás" não é versão.

Um caminho de desinstalação. Pacotes registram o que colocaram e sabem remover. Um script muitas vezes coloca arquivos em seis lugares e não se lembra disso.

Uma relação com um mantenedor. Quando um pacote muda de comportamento existe um registro de mudanças. Um script pode mudar sob o mesmo endereço sem deixar nada para ler.

Nada disso torna scripts ruins. Torna-os um tipo diferente de coisa, que merece um hábito diferente.

As cinco coisas para ler

Não o script inteiro, e não linha por linha. Essas cinco respostas costumam aparecer numa passada.

① O que ele toca fora da própria pasta? Um script que só escreve na própria pasta é fácil de abarcar. Um que edita arquivos em diretórios de configuração do sistema está fazendo mudanças que vão sobreviver a ele.

② Ele adiciona um repositório ou uma chave? É a linha de maior consequência na maioria dos scripts e passa num segundo. Adicionar uma fonte de pacotes significa que toda atualização futura naquela máquina passa a confiar numa parte nova. Isso pode ser perfeitamente razoável e deveria ser uma decisão, não um efeito colateral.

③ Ele mexe em boot, kernel ou rede? São os três que podem deixar um host inalcançável ou sem iniciar, e num hipervisor isso quer dizer que tudo em cima vai junto. Um script que instala uma aplicação web não tem o que fazer na configuração do carregador de boot, e se mexe vale entender antes de rodar.

④ Existe caminho de volta? Procure uma rotina de desinstalação ou, na falta, uma lista do que ele criou. Se não existe nenhum dos dois, seu caminho de volta é um instantâneo tirado antes, o que significa que você precisa tirar.

⑤ O que acontece se rodar duas vezes? Muitos scripts são escritos para máquina limpa, e uma segunda passada duplica entradas, zera configuração que você editou, ou falha no meio deixando um estado pela metade. Você vai rodar duas vezes uma hora, geralmente porque a primeira pareceu falhar.

A linha colada, especificamente

O padrão de baixar um script e mandar direto para o shell tem uma propriedade que merece ser nomeada: você não consegue ler o que executou. Não "você não leu", você não consegue, porque aquilo nunca foi um arquivo.

Existe também uma versão mais sutil. Ler o script no navegador e rodar o comando baixar-e-canalizar são duas requisições distintas. Nada garante que devolveram os mesmos bytes.

A correção custa um passo a mais. Baixe o arquivo, olhe, depois rode a cópia local. Agora você sabe o que rodou, pode rodar o idêntico depois, e se algo quebrar você tem o texto de verdade em vez da lembrança de uma página web.

Um hipervisor não é lugar de experimentar

É isso que separa um host Proxmox de um notebook. Todo o resto da máquina está abaixo dele. Um script que deixa um notebook num estado estranho custa uma noite; o mesmo script num host leva junto todas as máquinas virtuais.

Dois hábitos deixam quase tudo isso seguro:

Rode primeiro numa máquina virtual, se plausivelmente der. A maioria dos scripts que instalam um serviço não precisa estar no host. Isso não é gambiarra, geralmente é o lugar certo.

Se realmente precisa rodar no host, instantâneo antes. Não porque o script seja suspeito, mas porque "vou só testar" é exatamente a frase que precede precisar de um caminho de volta.

O que este texto não é

Não é motivo para desconfiar da comunidade. Os scripts compartilhados são uma das melhores coisas deste ecossistema, e quem os escreve costuma ser mais cuidadoso que quem os roda.

Não é motivo para ler cada linha. Cinco perguntas numa passada bastam para pegar o tipo de surpresa que realmente machuca.

O que o Atlas faz

O Atlas tira um instantâneo antes de operações que mudam o estado do host, então o caminho de volta existe sem você precisar lembrar de criar. Isso cobre o passo quatro da lista acima, que é justamente o pulado.

O registro de auditoria anota quem rodou o quê, quando, sobre o quê e com qual resultado, o que transforma "alguma coisa mudou terça passada" numa resposta legível em vez de uma investigação.

A cadeia de recursos ajuda mais depois do que na hora de decidir: se algo se comporta diferente após uma instalação, o mapa mostra como a máquina realmente está agora, dos convidados até os discos físicos.

E onde o Atlas instala software por conta própria, pelo catálogo de aplicações, a versão é fixada, a fonte é fixa e um ponto de restauração é tirado antes de começar. É um caminho deliberadamente estreito e curado, e não substitui scripts da comunidade. São simplesmente as mesmas cinco perguntas, respondidas de antemão para as aplicações que ele carrega.