Os cron jobs geralmente são considerados uma automação enfadonha para backups, rotação de logs e limpeza. Acredito firmemente que isso é inferior ao que eles são capazes, pois com um pouco de criatividade, o cron pode facilmente se tornar uma das partes mais pessoais e surpreendentemente divertidas do seu sistema. Eles são estranhos, práticos e geeks o suficiente para fazer seu homelab e seu fluxo de trabalho diário parecerem vivos em vez de invisíveis.
Rastreador de erros de digitação de comando
Não importa o quão geek você seja, todo mundo digita comandos errados, e tudo bem (nem sempre, mas você entende). O verdadeiro problema é que esquecemos esses erros de digitação e continuamos repetindo-os. Para resolver esse problema, esse cron job monitora seu histórico de shell, rastreia comandos com falha e cria um salão pessoal da vergonha que você pode revisar uma vez por semana.
Depois de alguns dias, você começará a notar certos padrões. Talvez você troque sinalizadores constantemente, digite caminhos longos incorretamente ou esqueça qual ferramenta pretendia usar. Depois de ver esses erros anotados e incluídos na lista do corredor da vergonha, você pode voltar e revisá-los ou usar apelidos simples (sim, isso é preguiçoso!)
A maneira como isso funciona é que o bash expõe o último comando e seu código de saída. Então, tudo o que precisamos fazer é nos conectar ao shell e registrar as falhas.
Crie um script chamado “log_failed_commands.sh”:
#!/usr/bin/env bash LOG="$HOME/command_typos.log" __prompt_command() { local status=$? local cmd="$BASH_COMMAND" if [[ $status -ne 0 && ! $cmd =~ ^(cd|exit|source|.|[|[[) ]]; then echo "$(date '+%F %T') | $cmd ($status)" >> "$LOG" fi } PROMPT_COMMAND="__prompt_command" Obtenha-o uma vez de .bashrc:
source “$HOME/log_failed_commands.sh” Você também pode verificar o log manualmente:
Agora crie um cron job semanal para enviar um e-mail ao salão da vergonha:
0 9 * * 1 mail -s "Hall of Shame: Command Typo Report" you@example.com < ~/.command_typos.log Monitor de rede (que fala com você)
Você provavelmente já está monitorando sua rede visualmente com dashboards e gráficos, e isso é legal, mas esse cron job vai na direção oposta e torna sua rede audível. Cada vez que um novo dispositivo aparece, seu sistema o anuncia em voz alta usando conversão de texto em voz.
Parece estranho até a primeira vez que um dispositivo desconhecido entra na sua rede e seu computador o chama casualmente do outro lado da sala. O script verifica a sub-rede local, compara os resultados com a execução anterior e fala quando detecta um novo IP. Estou usando ip neigh para simplificar, mas você pode modificá-lo e usar arp ou até mesmo nmap.
Crie "network_watch.sh":
#!/usr/bin/env bash STATE="$HOME/.net_known" SEEN="$HOME/.net_seen" LOG="$HOME/network_monitor.log" TTS="/usr/bin/espeak" command -v ip >/dev/null || exit 1 command -v espeak >/dev/null || TTS="" ip neigh show | awk '{print $1, $5}' | sort > "$SEEN" if [ ! -f "$STATE" ]; then cp "$SEEN" "$STATE" exit 0 fi NEW=$(comm -13 "$STATE" "$SEEN") for LINE in $NEW; do IP=$(echo "$LINE" | awk '{print $1}') MAC=$(echo "$LINE" | awk '{print $2}') echo "$(date) New device detected: IP=$IP, MAC=$MAC" >> "$LOG" if [ -n "$TTS" ]; then espeak "New device detected" >/dev/null 2>&1 fi done mv "$SEEN" "$STATE" Adicione uma entrada cron para ser executada a cada trinta minutos:
*/30 * * * * $HOME/network_watch.shHomelab Ping Pong
Se o seu homelab tem muitos contêineres como o meu, você sabe que a latência é importante e muito importante. Esse cron job faz ping em todos os contêineres em execução, registra seus tempos de resposta e cria uma lista classificada com base na velocidade, o que ajuda a detectar problemas dias antes de algo realmente falhar.
Esse pingue-pongue específico funciona porque o Docker expõe IPs de contêineres, então tudo que você precisa fazer é executar ping em cada contêiner uma vez e registrar o resultado.
Crie "container_latency.sh":
#!/usr/bin/env bash OUT="$HOME/container_latency.log" LOCK="$HOME/.container_latency.lock" exec 9>"$LOCK" || exit 1 flock -n 9 || exit 0 echo "Run $(date)" > "$OUT" docker ps --format '{{.ID}}' | while read -r ID; do IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$ID") [ -z "$IP" ] && continue AVG=$(ping -c 5 -q "$IP" 2>/dev/null | awk -F'/' 'END{print $5}') [ -n "$AVG" ] && echo "$IP $AVG" >> "$OUT" done sort -k2 -n "$OUT" -o "$OUT" Em seguida, agende a cada hora:
0 * * * * $HOME/container_latency.shSeu log ficaria mais ou menos assim:
Backups autoconscientes
Backups que nunca são testados são apenas backups teóricos, e a maioria de nós aprendeu essa lição da maneira mais difícil. Este cron job (ao contrário de nós) não assume nada e verifica tudo restaurando uma pequena amostra após cada execução.
Em vez de confiar facilmente nos registros que dizem “concluído com sucesso”, obtemos provas de que nossos dados podem realmente ser lidos e restaurados.
Crie "verify_backup.sh":
#!/usr/bin/env bash BACKUP="$HOME/backups/latest.tar.gz" LOG="$HOME/backup_verify.log" TMP=$(mktemp -d) [ -f "$BACKUP" ] || { echo "$(date) Backup missing" >> "$LOG"; exit 1; } tar -tzf "$BACKUP" >/dev/null || { echo "$(date) Corrupt archive" >> "$LOG"; exit 1; } FILES=$(tar -tzf "$BACKUP" | shuf -n 10) for F in $FILES; do tar -xzf "$BACKUP" "$F" -C "$TMP" || { echo "$(date) Restore failed for $F" >> "$LOG" rm -rf "$TMP" exit 1 } done echo "$(date) Backup '$BACKUP' successfully verified." >> "$LOG" rm -rf "$TMP" Execute-o logo após sua tarefa de backup:
30 2 * * * $HOME/verify_backup.shAqui está meu registro de backup:
Lembrete de sequência do GitHub
Manter a consistência é mais difícil do que a produtividade, e é por isso que existe esse cron job, para proteger o impulso. Ele verifica sua atividade no GitHub e lembra se você está prestes a perder a sequência do dia.
Ele usa a API GitHub, que expõe eventos recentes e verifica commits diários e notifica se nenhum for encontrado.
Criar "github_streak.sh":
#!/usr/bin/env bash USER="Your Username" TOKEN_FILE="$HOME/.github_token" LOG="$HOME/github_streak.log" LOCK="$HOME/.github_streak.lock" exec 9>"$LOCK" || exit 1 flock -n 9 || exit 0 TODAY=$(date -u '+%Y-%m-%d') AUTH_HEADER="" if [ -f "$TOKEN_FILE" ]; then AUTH_HEADER="-H Authorization: token $(cat "$TOKEN_FILE")" fi RESP=$(curl -s $AUTH_HEADER "https://api.github.com/users/$USER/events/public") [ -z "$RESP" ] && exit 0 if echo "$RESP" | grep -q ""created_at": "$TODAY"; then exit 0 fi echo "$(date) No GitHub activity detected for today" >> "$LOG" Agende para o final da tarde:
0 16 * * * $HOME/github_streak.shEsta é a aparência da minha atividade. Normalmente não relaxo, foi a temporada de férias que encerrou minha seqüência:
A maioria das tarefas que mencionei não são necessidades absolutas, mas cada uma é útil no sentido de que removem o atrito ou acrescentam consciência, ao mesmo tempo que são divertidas. Depois de começar a pensar no cron como uma ferramenta criativa, você encontrará centenas dessas pequenas tarefas que valem a pena automatizar, resultando em um sistema que parece atento e vivo.
