Claude para sysadmins: tarefas diárias no servidor

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 confirmar antes de alterar qualquer coisa no servidor. Uma resposta errada não causa danos enquanto não a executar. Por isso, manter o modelo no lado do aconselhamento é todo o modelo de segurança.

Há seis tarefas recorrentes todas as semanas num Linux VPS (virtual private server) alugado. Cada uma inclui abaixo um padrão de prompt que funciona, o comando que comprova a resposta e o modo de falha esperado. Nenhuma exige que o modelo tenha acesso ao servidor. Pode colar o conteúdo a partir de um separador do browser ou de uma janela no seu próprio desktop, porque o Claude funciona nativamente em Linux como aplicação desktop e CLI.

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 disponibiliza os seus serviços aos clientes, a revisão é preferível, 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 está 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 sysadmin precisa de um hash de palavra-passe para ser respondida.
• Tudo o que pertença 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. 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 colocado num prompt. Manter as chaves SSH organizadas vale, por si só, dez minutos.

Faça a redação antes de colar, em vez de confiar na sua capacidade de detetar um token em 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 apresenta, por isso esse resultado é um segredo, mesmo que o ficheiro no disco não fosse. Use docker compose config -q, que valida sem apresentar nada. Para consultar a política geral sobre o que um agente pode ver, manter os segredos fora dos agentes de IA aborda o lado do ambiente.

Job 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 os dois comandos, 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 falhou. 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 linha é o primeiro erro real e o que significa? Ainda não apresente uma correção.

"Still no fix yet" desempenha uma função importante nesse prompt. Os logs escondem a primeira falha sob as tentativas de reinício que ela causou, por isso um modelo ao qual se pede uma correção explicará a última linha que viu. 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 não existe ou o ficheiro existe, mas não é 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 resposta é fazer uma pergunta de controlo: "qual linha do que forneci sustenta essa conclusão?" Uma causa que ninguém consegue indicar no texto é apenas um palpite.

Tarefa 2: criar uma unidade systemd ou uma entrada cron

Forneça os dados de que o ficheiro da 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 qualquer coisa.

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 inexistente 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 falhar no momento em que é executada.

Dois erros de elaboração aparecem 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 para um programa que passa para segundo plano: o systemd trata o primeiro processo como o serviço, o processo-pai termina imediatamente e a unidade é marcada como inativa enquanto o processo real continua a executar-se sem gestão. É o erro que um modelo tem maior probabilidade de lhe fornecer, porque não consegue saber pelo comando se o binário cria um processo filho. Por isso, é importante conhecer o que cada valor de Type= garante ao systemd antes de aceitar o rascunho.

Para uma agenda, valide-a em vez de a ler:

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, fica claro o que a expressão significa. Se estiver a escolher entre um timer e um crontab, os serviços e timers systemd num VPS explicam os compromissos envolvidos.

O Cron tem uma armadilha que nenhum modelo lhe indicará sem que pergunte. O cron executa os trabalhos com um ambiente mínimo. Por isso, PATH corresponde aproximadamente a /usr/bin:/bin e o perfil da shell nunca é lido. Um trabalho que funciona quando é colado no terminal falha no cron com /bin/sh: 1: docker: not found, porque esse binário está em /usr/local/bin. Use caminhos absolutos nos crontabs. Se a exigência de um ficheiro de unidade em indicar explicitamente o utilizador, o ambiente e as dependências parecer excessiva comparada com uma única linha de crontab, os problemas que o systemd foi criado para resolver explicam a origem dessa verbosidade.

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

Esta tarefa 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 de volta e indique tudo o que não corresponder a essa descrição.

Depois, 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 e apresenta algo direto, como yaml: line 7: did not find expected key, quando a indentação está incorreta.

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

Confirme o que ficou efetivamente exposto:

sudo ss -tulpn

Sem sudo, pode ver os sockets em escuta, mas não os processos que os possuem. Se o resultado for inesperado, o que são portas e como o Linux as associa é 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 flag, 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, 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, mover -delete para antes de -name elimina tudo dentro do caminho inicial. Esse 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 faltar na origem será removido. Isto é correto para um mirror e causa um desastre quando o caminho de origem está errado.

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

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

Execute o find sem -delete e obterá uma lista em vez de uma perda.

Modo de falha: alucinação de flags. 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 flag que parece correta, mas não existe. --help esclarece a questão em um segundo. As aspas são outro ponto fraco. Por isso, quando um comando contém uma expressão $(...), leia como a substituição de comandos é expandida antes de o comando ser executado em vez de confiar na explicação.

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

Acabou de passar duas horas a pôr algo a funcionar. Esse conhecimento está no scrollback e desaparecerá no próximo mês.

history 200 > /tmp/session.txt

Leia esse ficheiro e elimine todas as linhas que contenham uma palavra-passe, um token ou um identificador de cliente antes de o ficheiro ser enviado para qualquer lado. O histórico do shell é um dos locais mais fiáveis para encontrar um segredo num sistema Linux, porque toda a gente escreve um segredo diretamente na linha de comandos pelo menos uma vez. Defina HISTCONTROL=ignorespace no seu ~/.bashrc. Assim, um comando escrito com um espaço inicial nunca é gravado no histórico.

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

Esta é uma sessão de shell que levou uma máquina Debian 13 recém-instalada 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 demasiado organizada. A sua sessão teve um passo que executou incorretamente duas vezes antes de o corrigir. Esse é o passo que o modelo elimina, porque a transcrição parece mais limpa sem ele. Compare o runbook com o seu histórico e reintroduza 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 coisa que alterou antes de ela aparecer. Peça as causas por ordem de probabilidade, com um comando de distinção 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á ocupa a porta 80, e sudo ss -tulpn | grep ':80 ' identifica-o. Muitas vezes, trata-se de um segundo processo master do nginx deixado por um reload falhado, ou do Apache iniciado pela própria package como dependência.

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é o modelo explicar por que motivo 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 previsível

• Ele não consegue ver o seu sistema. Cada resposta depende do que você colou, e ele não informa quando o trecho é curto demais.
• Ele perde a precisão entre versões. Os nomes dos pacotes e as flags padrão mudam entre distribuições e releases, e o modelo faz uma média entre todas elas.
• Ele é fluente mesmo 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 fatos do início de uma conversa de duas horas deixam de influenciar as respostas no final.

Esse ú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 é feito por copiar e colar, por isso o modelo nunca interage com a sua máquina. Quando é executado no servidor, onde lê ficheiros e executa comandos, o risco muda: um comando incorreto pode agora deixar um serviço indisponível. Dê-lhe um utilizador próprio sem privilégios em vez de root, mantenha-o fora do servidor de produção enquanto avalia o seu comportamento e crie primeiro um snapshot. Executar o Claude Code com segurança numa VPS aborda o sandboxing e o modelo de permissões. Controlar 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 procedimento.

FAQ

O Claude pode 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 representa uma decisão de confiança mais abrangente. Para uma questão de suporte normal, colar um excerto redigido de 100 linhas é mais rápido e seguro do que dar acesso de shell a um agente.

O que nunca devo colar de um servidor?

Chaves privadas, ficheiros .env e outros repositórios de credenciais, /etc/shadow e quaisquer dados pertencentes aos seus utilizadores. Remova os tokens dos excertos de logs antes de os enviar para o prompt. Um caso menos óbvio: a saída de docker compose config contém 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 numa VPS de produção?

Trate-o como um administrador novo e sem contexto: é aceitável para leitura, mas a escrita requer revisão. Em produção, peça a explicação e execute o comando manualmente. Se quiser mesmo que um agente execute comandos, atribua-lhe uma conta dedicada sem privilégios, sem acesso sudo abrangente, e comece numa máquina de staging, onde um erro lhe custe uma reconstruçã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 a seco.

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 próprio parser do systemd, indica 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. Em seguida, execute daemon-reload, start e leia systemctl status antes de executar enable, porque uma unidade que carrega sem erros ainda pode falhar na primeira execução.