忍者ブログ

mshencity

私が誓う、奇妙だが便利な 5 つの cron ジョブ

Cron ジョブは通常、バックアップ、ログ ローテーション、クリーンアップなどの退屈な自動化であると考えられています。少し創造性を発揮すれば、cron はシステムの中で最も個人的で驚くほど楽しい部分の 1 つになることが簡単にできるため、私はその機能が過小評価されていると強く信じています。これらは奇妙で実用的で、ホームラボや毎日のワークフローを目に見えないものではなく生き生きと感じさせるのに十分なほどマニアックです。



コマンドタイプミストラッカー

あなたがどれほどのオタクであっても、誰もがコマンドをタイプミスすることはあります。それは問題ありません (常にではありませんが、それはわかります)。本当の問題は、私たちがそれらのタイプミスを忘れて、それを繰り返し続けることです。この問題を解決するために、この cron ジョブはシェル履歴を監視し、失敗したコマンドを追跡し、週に 1 回確認できる個人的な恥の殿堂を構築します。

数日後、特定のパターンに気づき始めるでしょう。頻繁にフラグを交換したり、長いパスをミスタイプしたり、使用するつもりだったツールを忘れたりすることがあるかもしれません。それらの間違いが書き留められ、恥の殿堂のリストに掲載されているのを確認したら、戻って見直したり、単純なエイリアスを使用したりできます (そう、それは怠惰です!)。

これがどのように機能するかというと、bash は最後のコマンドとその終了コードを公開します。したがって、私たちがしなければならないのは、シェルにフックして失敗をログに記録することだけです。

「log_failed_commands.sh」という名前のスクリプトを作成します。


#!/usr/bin/env bash

LOG="$HOME/command_typos.log"

__prompt_command() $cmd ($status)" >> "$LOG"
fi


PROMPT_COMMAND="__prompt_command"


から一度調達してください .bashrc:


source “$HOME/log_failed_commands.sh”


ログを手動で確認することもできます。
























コマンドタイプミススクリプトのログ




次に、毎週 cron ジョブを作成して恥の殿堂にメールを送信します。


0 9 * * 1 mail -s "Hall of Shame: Command Typo Report" you@example.com < ~/.command_typos.log




ネットワーク モニター (話しかける)

おそらく、すでにダッシュボードやグラフを使用してネットワークを視覚的に監視しているでしょう。それは素晴らしいことですが、この cron ジョブは逆の方向に進み、ネットワークを音声で聞こえるようにします。新しいデバイスが登場するたびに、システムはテキスト読み上げを使用してそれを大声でアナウンスします。

見慣れないデバイスが初めてネットワークに参加し、コンピュータが部屋の向こうから何気なくそのデバイスを呼び出すまでは、奇妙に聞こえます。このスクリプトはローカル サブネットをスキャンし、結果を前回の実行と比較し、新しい IP を検出すると音声を発します。簡単にするために ip neigh を使用していますが、これを変更して arp や nmap を使用することもできます。

「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"


30 分ごとに実行する cron エントリを追加します。


*/30 * * * * $HOME/network_watch.sh




ホームラボ ピンポン

あなたのホームラボが私のようにコンテナを大量に使用している場合は、レイテンシが重要であり、それが非常に重要であることをご存知でしょう。この cron ジョブは、実行中のすべてのコンテナーに ping を実行し、その応答時間を記録し、速度に基づいて並べ替えられたリストを作成します。これは、実際に何かが失敗する数日前に問題を特定するのに役立ちます。

この特定のピンポンが機能するのは、Docker がコンテナー IP を公開しているためです。そのため、各コンテナーに 1 回 ping を実行して、結果を記録するだけで済みます。

「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"


次に、1 時間ごとにスケジュールを設定します。


0 * * * * $HOME/container_latency.sh


そのログは次のようになります。
























コンテナーの遅延をチェックする ping pong cron ジョブのログ






自己認識型バックアップ

テストされていないバックアップは単なる理論上のバックアップであり、私たちのほとんどはこの教訓を苦労して学んでいます。この cron ジョブは (私たちとは異なり) 何も想定せず、実行のたびに小さなサンプルを復元することですべてを検証します。

「正常に完了した」というログを簡単に信頼するのではなく、データを実際に読み取って復元できるという証拠を得ることができます。

「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"


バックアップ ジョブの直後に実行します。


30 2 * * * $HOME/verify_backup.sh


私のバックアップログは次のとおりです。
























バックアップ検証スクリプトのログ






GitHub ストリーク リマインダー

一貫性を維持することは生産性よりも難しいため、勢いを守るためにこの cron ジョブが存在します。 GitHub アクティビティをチェックし、その日の連続記録が失われそうになっているかどうかを通知します。







GitHub API を使用して、最近のイベントを公開し、毎日のコミットをチェックして、見つからない場合は通知します。

作成する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 \r
"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"


午後遅くにスケジュールを設定します。


0 16 * * * $HOME/github_streak.sh


私の活動はこんな感じです。普段はサボらないのですが、その連続記録が止まったのはホリデーシーズンでした。
























github streak notifier のログ





私が言及したタスクのほとんどは絶対に必要なものではありませんが、それぞれの作業は、楽しみながら摩擦を取り除いたり意識を高めたりするという意味で役に立ちます。 cron を創造的なツールとして考え始めると、自動化する価値のあるこのような小さなタスクが何百もあることがわかり、その結果、気配りが行き届いていて生きていると感じられるシステムが得られます。

PR

コメント

プロフィール

HN:
No Name Ninja
性別:
非公開

P R