設定ファイル破損のパニック
パフォーマンスを最適化するために、/etc/nginx/nginx.confの1行を書き換えたとします。ファイルを保存し、サービスをリロードした瞬間、すべてがオフラインに. ログは難解で、サービスは起動を拒否し、元の構文がどうだったか思い出せなくなります。ダウンタイムの1秒1秒が、まるで1時間のように感じられるはずです。
重要な環境において、推測は戦略ではありません。50台以上のDebianサーバーを数年間管理してきた経験から、プレッシャーがかかる場面で真っ先に失敗するのは手動バックアップであることを学びました。バックアップを取り忘れたときでも機能するセーフティネットが必要です。それこそがEtckeeperの役割です。
標準的なバックアップが失敗する理由
セットアップに入る前に、なぜ従来の手法がシステム管理者を失望させることが多いのかを見てみましょう。
「.bak」コピー戦略
私たちは皆、cp sshd_config sshd_config.bakを実行したことがあります。ちょっとした編集には十分ですが、OSのメジャーアップグレード時には破綻します。パッケージの更新によって3つのディレクトリにまたがる5つのファイルが変更された場合、手動のコピーでは連鎖的な変更を追跡できません。「誰が、何を、いつ」変更したのかという情報が失われてしまうのです。
素のGitを使う際の問題点
/etc内でgit initを実行するのは賢い方法に思えますが、ファイルを復元しようとすると問題に直面します。標準のGitは、ファイルのメタデータの追跡が苦手です。Linux特有のパーミッション（秘密鍵の0600など）や所有権（rootかサービスユーザーか）をネイティブに保存しません。誤ったパーミッションで設定ファイルを復元すると、サーバーから締め出されたり、重大なセキュリティホールを招いたりする可能性があります。
Etckeeperの利点
Etckeeperは、Linuxのシステムディレクトリ特有の挙動に合わせて調整されたGitのラッパーとして機能します。ファイルのパーミッションを特別なメタデータファイルに記録し、さらに重要な点として、パッケージマネージャーと連携します。apt、dnf、pacmanのいずれを使用していても、Etckeeperはソフトウェアのインストール前後に自動的に変更をコミットします。
メリットとデメリット：現実的な評価
メリット
- ゼロタッチ自動化:
apt upgrade中など、見落としがちな変更を自動でキャプチャします。 - 監査証跡:
git logを使用して、どのジュニア管理者（または自動スクリプト）がファイアウォールルールを変更したかを正確に把握できます。 - 即時復旧: 壊滅的な変更の取り消しは、オフサイトバックアップから復元するのではなく、数秒で完了します。
- メタデータの認識: システムの安定性に不可欠な
root:rootの所有権や制限的なパーミッションを保持します。
デメリット（トレードオフ）
- ストレージの増大: Gitの履歴が蓄積されるにつれ、20MBの
/etcディレクトリが2年で200MB以上に膨らむことがあります。定期的な監視が必要です。 - 機密データ: Gitの履歴には、すべての設定ファイルの全バージョンが含まれます。誤って平文のパスワードをコミットした後に削除しても、そのパスワードは
.gitの履歴内に残り続けます。 - Rootアクセス: これらのコマンドは
sudoで実行する必要があり、ワークフローにわずかな手間が加わります。
本番環境向けの設定
信頼性の高い本番環境のために、以下の「設定したらあとはお任せ」の構成を推奨します：
- VCSの選択: Gitを使いましょう。コミュニティのサポートとスクリプトの統合が最も充実しています。
- デイリースナップショット: デイリーの自動コミットを有効にしておきます。これにより、午前2時に行った「ちょっとした修正」の記録漏れを防げます。
- プライベートリモート: 履歴をプライベートでセルフホストされたGitLabインスタンスや、制限されたGitHubリポジトリにプッシュします。いかなる状況でも、
/etcをパブリックリポジトリにプッシュしてはいけません。
ステップ・バイ・ステップの導入手順
UbuntuまたはDebianシステムでEtckeeperを動かしてみましょう。RHELベースのディストリビューションでもロジックは同じです。
1. インストール
パッケージをインストールします。Gitがまだシステムにない場合は、自動的にインストールされます。
sudo apt update && sudo apt install etckeeper2. 設定の確認
/etc/etckeeper/etckeeper.confで設定を確認します。VCS変数が"git"に設定されていることを確認してください。
sudo nano /etc/etckeeper/etckeeper.confデフォルトでは、AVOID_DAILY_AUTOCOMMITS=1は通常コメントアウトされており、デイリーコミットが有効になっています。そのままの設定を維持してください。
3. リポジトリの初期化
ディレクトリを準備し、最初のベースラインコミットを行います。これにより、隠しフォルダ.gitと、パーミッションを追跡するための.metadataファイルが作成されます。
sudo etckeeper init
sudo etckeeper commit "/etcの初期ベースライン"4. 手動変更の追跡
SSHの設定を変更したとします。ファイルを保存した後、コミット前に差分を確認します：
sudo etckeeper vcs diff変更内容が正しければ、履歴に保存します：
sudo etckeeper commit "セキュリティのためSSHポートを2222に変更"5. パッケージマネージャー連携のテスト
curlやhtopのような小さなパッケージをインストールしてみてください。ターミナルの出力を確認すると、インストールが始まる前にEtckeeperが静かに変更をコミットしているのがわかります。これにより、新しいパッケージが設定を壊した場合でも、「インストール前」の状態に戻せることが保証されます。
6. ミスのロールバック
設定の変更によってサービスが壊れた場合、ログを使用して最後の安定した状態を見つけます：
sudo git -C /etc log --oneline --limit 10問題の原因となっている特定のファイルを復元します：
sudo git -C /etc checkout [commit_hash] /etc/nginx/nginx.conf
sudo systemctl restart nginx履歴の保護
/etcには/etc/shadowのような機密ファイルが含まれているため、セキュリティは最優先事項です。Etckeeperは自動的に/etc/.gitディレクトリへのアクセスをrootユーザーに制限します。このパーミッションを緩めないでください。リモートサーバーにプッシュする場合は、強力なパスフレーズで保護されたSSHキーを使用してください。また、会社のポリシーでバージョン管理が禁止されている高機密ファイルがある場合は、.gitignoreに追加するのが賢明です。
最後に
Etckeeperは、/etcを「壊れやすいテキストファイルの集まり」から「回復力のあるバージョン管理されたデータベース」へと変貌させます。「何を変更したっけ？」という不安を解消し、チームに明確な監査証跡を提供します。まずは今日、ステージングサーバーに導入してみてください。次にルーチンアップデートがうまくいかなくなったとき、未来の自分はあなたに感謝することでしょう。
