Claude para sysadmins: tarefas comuns em servidores

Claude para administradores de sistemas: primeiro aconselhamento, depois execução

O Claude funciona melhor como revisor para administradores de sistemas. Cole um excerto de log, um ficheiro de configuração, um comando que não reconhece ou uma mensagem de erro. Receberá uma explicação que pode verificar antes de alterar qualquer coisa no servidor. Uma resposta errada não causa danos até ser executada. Por isso, manter o modelo no lado do aconselhamento é a base de segurança.

Todas as semanas surgem seis tarefas num Linux VPS (servidor privado virtual) arrendado. Para cada uma, apresentamos um padrão de prompt que funciona, o comando que comprova a resposta e o modo de falha esperado. Nenhuma requer que o modelo tenha acesso ao seu servidor.

A ordem é importante num servidor de produção: leia a explicação, execute a verificação por sua conta e só depois decida. A autonomia é aceitável numa VM de teste. No servidor que atende os seus clientes, a revisão é a opção mais segura, porque o modelo não consegue ver o estado sobre o qual está a fazer suposições.

O que nunca deve colar

Tudo o que é incluído no prompt sai do seu servidor. Quatro categorias devem permanecer no servidor:

• Chaves privadas: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key e qualquer chave TLS (transport layer security) em /etc/letsencrypt/live/.
• Ficheiros de credenciais: .env, ~/.aws/credentials, /root/.docker/config.json e palavras-passe de bases de dados em qualquer ficheiro ou linha de log.
• Dados de contas: /etc/shadow e /etc/gshadow. Nenhuma pergunta de administração de sistemas precisa de um hash de palavra-passe para ser respondida.
• Qualquer conteúdo pertencente aos seus utilizadores: endereços de email, linhas de pedidos, logs de pedidos que contenham cookies de sessão ou PII (personally identifiable information).

As chaves públicas podem ser coladas sem risco. As chaves privadas não podem. Os dois ficheiros parecem semelhantes à primeira vista, por isso leia a primeira linha antes de copiar: um ficheiro cuja primeira linha contenha BEGIN OPENSSH PRIVATE KEY nunca deve ser incluído num prompt. Manter os ficheiros de chaves SSH bem identificados merece dez minutos por si só.

Faça a redação antes de colar, em vez de confiar na sua capacidade de detetar um token no meio de 200 linhas:

sudo journalctl -u myapp -n 200 --no-pager | sed -E 's/(token|secret|password|api[_-]?key)[=:][^[:space:]]+/\1=REDACTED/gI'

Existe uma armadilha específica do Docker. docker compose config interpola os valores de .env no resultado que imprime, por isso esse resultado é um segredo, mesmo que o ficheiro no disco não fosse. Use docker compose config -q, que valida e não imprime nada. Para conhecer a política geral sobre o que um agente pode ver, manter os segredos fora dos agentes de IA aborda o controlo do ambiente.

Tarefa 1: por que este serviço falhou?

Comece pelos dois comandos que contêm a resposta:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b -n 100 --no-pager -o short-iso

Cole ambos, juntamente com o contexto que o modelo não pode adivinhar: a distribuição e a versão, o que alterou por último, se alguma vez funcionou e há quanto tempo deixou de funcionar. Peça primeiro o mecanismo.

Ubuntu 24.04. myapp.service funcionava até eu editar a unidade há uma hora. Aqui estão systemctl status e as últimas 100 linhas do journal. Qual é a primeira linha que indica um erro real e o que significa? Ainda não apresente uma correção.

A frase "Ainda não apresente uma correção" tem uma função importante nesse prompt. Os logs ocultam a primeira falha por baixo das tentativas de reinício que ela provocou, por isso um modelo ao qual se pede uma correção explicará a última linha que encontrou. A linha relevante costuma estar vinte linhas acima do ruído.

O resultado pode ser uma linha como Main PID: 1841 (code=exited, status=203/EXEC). O status de saída 203/EXEC significa que o kernel não conseguiu executar o ficheiro indicado em ExecStart: o caminho pode não existir ou o ficheiro pode existir sem ser executável. Uma linha #! que indique um interpretador não instalado produz o mesmo status. Tudo isso pode ser testado com ls -l e head -1.

Modo de falha: uma causa inventada. Cole pouco conteúdo e o modelo preencherá a lacuna com algo genérico, como "a porta já está em uso". A correção é fazer uma pergunta de seguimento: "que linha do conteúdo que forneci sustenta essa afirmação?" Uma causa que ninguém consegue indicar no texto é apenas uma suposição.

Tarefa 2: elaborar uma unidade systemd ou uma entrada cron

Forneça os dados de que um ficheiro de unidade precisa: o comando exato, o utilizador com que é executado, o diretório de trabalho, se tem de aguardar pela rede e o que deve acontecer quando termina com um código diferente de zero. Depois, verifique o resultado antes de ativar o serviço.

sudo systemd-analyze verify /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl start myapp.service
systemctl status myapp.service --no-pager

systemd-analyze verify analisa o ficheiro da mesma forma que o systemd, detetando erros que podem passar despercebidos numa revisão manual. Uma diretiva escrita incorretamente gera /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Um binário em falta gera Command /usr/local/bin/myapp is not executable: No such file or directory. Ambos permanecem silenciosos durante daemon-reload. Por isso, uma unidade pode ser carregada sem erros e ainda assim falhar quando é executada.

Dois erros de elaboração surgem repetidamente. O primeiro é After=network.target, que apenas significa que a pilha de rede está configurada, não que já exista um endereço. Um serviço que se associa a um IP específico falha então no arranque com bind: Cannot assign requested address. A correção é Wants=network-online.target juntamente com After=network-online.target. O segundo é Type=simple num programa que se transforma num daemon: o systemd trata o primeiro processo como o serviço, o processo-pai termina imediatamente e a unidade é marcada como terminada, enquanto o processo real continua a executar-se sem gestão.

Para uma agenda, valide-a em vez de a interpretar manualmente:

systemd-analyze calendar 'Mon *-*-* 04:00:00'

Isto apresenta a forma normalizada e a próxima hora em que a expressão será executada. Assim, elimina qualquer dúvida sobre o seu significado. Se estiver a escolher entre um timer e um crontab, serviços e timers systemd numa VPS explica as diferenças.

O cron tem uma armadilha que nenhum modelo irá indicar sem que seja solicitado. O cron executa tarefas com um ambiente mínimo. Por isso, PATH é aproximadamente /usr/bin:/bin e o perfil da shell nunca é lido. Uma tarefa que funciona quando é colada no terminal falha no cron com /bin/sh: 1: docker: not found, porque esse binário está em /usr/local/bin. Utilize caminhos absolutos nos crontabs.

Job 3: rever um ficheiro nginx ou Compose antes de o colocar em produção

Este trabalho oferece o melhor retorno. Cole o ficheiro, explique o que ele deve fazer e peça uma descrição linha a linha do que ele realmente faz.

Este vhost deve servir example.com por HTTPS e encaminhar /api para um serviço local na porta 8080. Leia a configuração e indique tudo o que não corresponder a essa descrição.

Em seguida, execute a ferramenta que conhece a gramática:

sudo nginx -t
docker compose config -q

nginx -t apresenta nginx: configuration file /etc/nginx/nginx.conf test is successful ou indica o ficheiro e a linha, como em nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. docker compose config -q não apresenta nada quando o ficheiro é analisado corretamente. Quando a indentação está errada, apresenta algo direto como yaml: line 7: did not find expected key.

Nenhuma das ferramentas verifica a intenção. Uma configuração que passa nginx -t ainda pode encaminhar para a porta errada ou escutar em 0.0.0.0 quando o objetivo era 127.0.0.1. Essa diferença é onde o modelo é útil, mas também é onde falha: quando lhe pedem para corrigir uma diretiva, muitas vezes devolve o ficheiro inteiro reescrito e remove silenciosamente duas das suas diretivas. Peça as linhas alteradas e o motivo de cada alteração. Depois, edite manualmente.

Confirme o que está efetivamente exposto:

sudo ss -tulpn

Sem sudo, pode ver os sockets em escuta, mas não os processos que os possuem. Se esse resultado for inesperado, o que são portas e como o Linux faz o binding é uma leitura mais curta.

Tarefa 4: explique um comando desconhecido antes de o executar

Cole o comando e faça quatro perguntas sobre ele: o que faz cada opção, o que escreve, o que elimina e o que acontece se o executar duas vezes. A última pergunta deteta mais danos do que as outras.

Considere find /var/log -name '*.gz' -mtime +7 -delete. Uma boa resposta explica que -mtime +7 conta períodos completos de 24 horas e descarta a fração restante. Por isso, corresponde a ficheiros com pelo menos oito dias, e não sete. Também explica que find avalia a expressão da esquerda para a direita. Assim, colocar -delete antes de -name elimina tudo dentro do caminho inicial. Este segundo ponto aparece como aviso na página de manual de find e já custou a algumas pessoas o seu /var/log.

Considere também rsync -a --delete /srv/app/ /backup/app/. A barra final na origem significa "o conteúdo deste diretório". Se a remover, obtém /backup/app/app/. Se adicionar --delete, tudo o que existir no destino mas estiver ausente na origem será removido. Isto é correto para um espelho e causa um desastre quando o caminho de origem está errado.

Verifique com a ferramenta, e não com o modelo:

rsync -a --delete --dry-run /srv/app/ /backup/app/ | head -20
find /var/log -name '*.gz' -mtime +7

Execute find sem -delete para obter uma lista em vez de sofrer uma perda.

Modo de falha: alucinação de opções. O modelo é fiável com ferramentas que têm trinta anos de documentação, mas é muito menos fiável com CLIs de fornecedores (interfaces de linha de comandos) e subcomandos recentes. Nesses casos, pode produzir uma opção que parece correta, mas que não existe. --help confirma isso num segundo. As aspas são o outro ponto fraco. Por isso, quando um comando inclui uma expressão $(...), leia como a substituição de comandos é expandida antes da execução do comando em vez de confiar na explicação.

Job 5: transforme o histórico do shell num runbook

Passou duas horas a fazer algo funcionar. Esse conhecimento está no seu scrollback e desaparecerá no próximo mês.

history 200 > /tmp/session.txt

Leia esse ficheiro e elimine todas as linhas que contenham uma password, um token ou um identificador de cliente antes de o partilhar. O histórico do shell é um dos locais mais fiáveis para encontrar um segredo num sistema Linux, porque toda a gente introduz pelo menos um inline uma vez. Defina HISTCONTROL=ignorespace no seu ~/.bashrc e um comando introduzido com um espaço inicial nunca será escrito no histórico.

O prompt que produz um runbook utilizável pede verificações, não apenas passos:

Esta é uma sessão do shell que levou uma instalação Debian 13 nova a uma instalação funcional do Postgres. Documente-a como um runbook numerado. Use um comando por passo. Depois de cada passo, indique o comando que comprova que funcionou e descreva o aspeto de uma saída saudável. Assinale todos os passos que dependeram do meu host específico.

Modo de falha: uma narrativa organizada. A sua sessão teve um passo que executou incorretamente duas vezes antes de o corrigir, e esse é o passo que o modelo simplifica, porque a transcrição fica mais limpa sem ele. Compare o runbook com o seu histórico e volte a incluir a correção. O modelo também inventa comandos de verificação plausíveis, por isso execute todas as verificações que ele escrever antes de guardar o ficheiro. Se o runbook abranger o primeiro arranque, compare-o com os primeiros dez minutos num VPS novo para não documentar uma versão pior de um problema já resolvido.

Tarefa 6: transformar uma mensagem de erro numa correção

Cole a string exata, o comando que a produziu e a única alteração feita antes de ela aparecer. Peça as causas ordenadas por probabilidade, com um comando de diagnóstico para cada uma. Isso obriga a resposta a ser testável.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). Ordene as causas prováveis e forneça um comando por causa que a confirme ou descarte.

Neste erro, o mecanismo não é ambíguo: outro processo já está a usar a porta 80, e sudo ss -tulpn | grep ':80 ' identifica-o. Muitas vezes, trata-se de um segundo processo master do nginx deixado para trás por um reload falhado. Também pode ser o Apache, iniciado como dependência pelo próprio pacote.

Modo de falha: uma correção que funciona ocultando a causa. chmod 777, --privileged, desativar o SELinux e executar o serviço como root fazem o erro desaparecer. Recuse qualquer correção que amplie as permissões até que o modelo explique por que razão a permissão restrita falhou. Essa explicação é a resposta efetiva. Uma solução alternativa apenas silencia o erro.

O que ele erra de forma consistente

• Ele não consegue ver o seu servidor. Cada resposta depende do que você colou, e ele não informará que o trecho era demasiado curto.
• Ele se confunde com as versões. Os nomes dos pacotes e as flags padrão mudam entre distribuições e versões, e o modelo faz uma média entre todas elas.
• Ele é fluente quando está errado. Um mecanismo inventado parece exatamente correto. Por isso, cada causa acima vem acompanhada de um comando que a testa.
• Ele perde o contexto em sessões longas. Os factos do início de uma conversa de duas horas deixam de influenciar as respostas no final.

Este último ponto é mais um problema operacional do que um problema do modelo. gerir o contexto numa sessão longa do Claude Code é a solução prática: sessões mais curtas, uma tarefa por sessão.

Colocar o agente no próprio servidor

Tudo o que foi apresentado até aqui consiste em copiar e colar, por isso o modelo nunca interage com a sua máquina. Quando é executado no servidor, com acesso para ler ficheiros e executar comandos, o perfil de risco muda: um comando incorreto pode agora interromper um serviço. Crie um utilizador sem privilégios próprios para ele, em vez de usar root, mantenha-o fora do servidor de produção enquanto aprende o seu comportamento e crie primeiro um snapshot. Executar o Claude Code com segurança numa VPS explica o isolamento e o modelo de permissões. Executar o Claude Code dentro do tmux resolve a outra parte, porque uma sessão SSH (secure shell) interrompida termina um agente em primeiro plano a meio do trabalho. Crie a conta como criaria qualquer conta de serviço; utilizadores com privilégios mínimos numa VPS explica esse processo.

FAQ

O Claude consegue ler diretamente os logs do meu servidor?

Não por si só. A interface de chat só vê o texto que cola nela. O Claude Code, executado no servidor como uma ferramenta de linha de comandos, pode ler ficheiros e executar comandos com as permissões do utilizador que o iniciou, o que envolve uma decisão de confiança mais ampla. Para uma pergunta de suporte comum, colar um excerto anonimizado de 100 linhas é mais rápido e seguro do que dar acesso à shell a um agente.

O que nunca devo colar a partir de um servidor?

Chaves privadas, ficheiros .env e outros armazenamentos de credenciais, /etc/shadow, e quaisquer dados pertencentes aos seus utilizadores. Remova os tokens dos excertos de log antes de os enviar para o prompt. Um caso menos óbvio: a saída de docker compose config inclui nela os valores .env interpolados. Por isso, use docker compose config -q, que valida o ficheiro e não imprime nada.

É seguro deixar o Claude executar comandos num VPS de produção?

Trate-o como um novo administrador sem contexto: é aceitável para leitura, mas a escrita requer revisão. Em produção, peça a explicação e execute o comando por si próprio. Se quiser mesmo que um agente execute comandos, atribua-lhe uma conta dedicada sem privilégios, sem acesso sudo abrangente, e comece num servidor de staging, onde um erro lhe custe uma reinstalação em vez de uma indisponibilidade.

Porque é que o Claude sugere uma flag que não existe?

Porque prevê texto plausível, e uma flag plausível tem o mesmo aspeto que uma flag real. Isto acontece sobretudo com CLIs de fornecedores e subcomandos mais recentes, cuja documentação disponível para o modelo é limitada ou entretanto mudou. --help e man são a referência definitiva, e qualquer comando que elimine ou substitua dados merece primeiro uma execução em modo dry run.

Como verifico uma unidade systemd antes de a ativar?

Execute sudo systemd-analyze verify /etc/systemd/system/myapp.service. O comando analisa o ficheiro com o parser do próprio systemd, comunica as diretivas desconhecidas com os respetivos números de linha e assinala um binário ExecStart em falta ou sem permissão de execução. Depois execute daemon-reload, start e leia systemctl status antes de enable a unidade, porque uma unidade que é carregada sem erros ainda pode falhar na primeira execução.