たまたま crontab 関連で検索していたところ、こんなタイトルの記事が目に留まりました。
例えば root ユーザーで crontab -e すると、/var/spool/cron/root が書き換えられるわけですが、visudo が /etc/sudoers を直接触らないのと同じく、crontab -e で編集すること自体は別に悪いことではないんじゃないの？って思いました。
気になって記事の中身を読んでみると、キーボードの e と r が隣り合わせだから危険ってことでした。なるほど、そういった意味での使ってはいけないってことだったのですね。確かに、このオプション危ないなって思ったことはありますが、仕事ではサーバ上で直接 crontab を触らないようにしてきたので、そこまで意識したことはありませんでした。
crontabの内容はどこで管理してる？
というのも、私が初めて crontab を仕事で使った時、既に定義する内容が crontab.txt として CVS で管理されていたのですよね。CVS って言っても伝わりにくい時代かもしれませんが、今でいう Git や Subversion のようなソース管理システムです。
この文化があったおかげで、crontab で設定している内容が消えても短時間で復旧可能でしたし、サーバ上で直接書き換えることはなく、必ずデプロイの過程で crontab に最新の crontab.txt の内容が反映されるようになっていました。
1 | $ crontab crontab.txt |
運用を意識すると必然的に安全策を考える
プライベートでは、サーバ上でちょこちょこっと触って、後からソース管理上のファイルを修正するみたいな横着をすることもありますが、とにかく若い頃に携わったプロジェクトのおかげで、仕事では運用時のことを見据えた開発ができるようになった気がします。
まあ、これは Web アプリだけでなく、サーバインフラなども担当していたからこその経験かもしれませんが。
サーバの構成や、設定内容、バッチの手順、エラーログに対する調査手順などなど、心配性だったからかもしれませんが、すべて Wiki に書いて運用に備えていました。
最近でも、周りから Jenkins が壊れたからバックアップはないけどジョブを復活させておいてって、プロジェクトの内容もわからない人が頼まれていたという話を聞きましたが、最初にジョブを作った人がせめて何か残しておいてくれたらね・・・。
できる人は、すべて頭の中にあるから、また作り直せる自信があるのでしょうが、やはり長く運用していくプロジェクトについては少しでも手掛かりを残せるように仕組みを考えるのも必要ですね。
最後に、crontab -r してしまったけど、バックアップがない時の対処法として、以下の記事も紹介されていました。少し古いですが、少しは何かの手掛かりになるかもしれませんね。
あっ、ついでに Jenkins のバックアップシェルも紹介しておきます。
