趣味と実益を兼ねたVPS運用。その核となる心構えについての個人的なメモを、具体例を交えつつ方法論(メソドロジー)について記しています。
- Linuxの基本的な知識はあると思う
- Linuxサーバを個人で運用したい
- チューニング、設定変更、パッケージ管理のコツを知りたい
- 管理者は自分一人を想定している
方の参考になれば幸いです。
壊れる前の切り戻しの準備。
これが基本かつ重要な心構えです。
- プログラム1つの更新
- 設定ファイルの修正
- コマンドミス
などで、サーバは瓦解します。しかも、自分の指先一つで壊れるのですから、何があっても
誰かのせいにしたいが自分の顔しか思い浮かばない
I'm casting around in my head for someone to blame and it's just me, keeps coming back at me.
という状況です。筆者が手順メモで
sudo cp -pi /etc/something/imporotant/config.file /path/to/backup/config.file.$(date +%Y%m%d)
とバックアップを取り、
diff -u /path/to/backup/config.file.$(date +%Y%m%d) /etc/something/imporotant/config.file
と、diff
で差分を取るのは「何を変更しても(戻せる範囲で)切り戻せる」を体でたたき込んでいるからです。
バージョンアップ時にmysqldump
でDBのバックアップを取ったり、ディレクトリごと/サーバのイメージごとバックアップを取るなどもその表れです。
「何を」実行するのではなく「どこで」実行するか?
ふわっとしていますが、以下の状況を考えましょう。
/tmp
ディレクトリで
sudo rm -rf *
を実行するのと、
/etc/apache2/sites-available
ディレクトリで
sudo rm -rf *
を実行するのでは、その後のサーバの状況(というよりも惨劇)がまるで違います。
「このコマンドを実行するのか」以上に「どのディレクトリでこれを実行するのか」を念頭に置いて、
cd /var/log && pwd
(cd /var/log ; pwd
でも可)
を実行する習慣は極めて大事です。或いは、
/etc/profile.d/pwd.sh
等のシェルスクリプトを作り、
#!/bin/bash
# カスタムcd関数を定義
cd() {
# ビルトインcdコマンドの実行
builtin cd "$@" || return
を登録しておけば、
cd /var/log
と実行するだけで、
cd /var/log && pwd
と同じ効果が得られます。
それ以上に大切な「いつ実行したか?」
「いつ」実行したかは「何を」よりも「どこで」実行したかよりも大事な証拠となり得ます。
設定がおかしくなった、または復旧したかのトリガーは
「いつ、何かをやったか」に、history
コマンドに明確に現れています。
また、これが、上述したバックアップしたときに
sudo cp -pi /etc/something/imporotant/config.file /path/to/backup/config.file.$(date +%Y%m%d)
と、$(date +%Y%m%d)
変数をつけてまでファイルの変更管理を行うのは、その表れです。
チューニング時、「どの数値まで耐えられたか?」を記録するための多いな助けになります。
手順化するときは1コマンド1行。
復旧手順、慣れている作業ほど陥りやすいミスです。
こちらはサーバの証明書の整合性を確認するためのコマンドメモですが
- 期限が延びていることを確認
openssl x509 -noout -dates -subject -in example.com.crt.$(date +%Y%m)
- 証明書から公開鍵を取得
openssl x509 -pubkey -in example.com.$(date +%Y%m) -noout | openssl md5
- 秘密鍵から公開鍵を取得
openssl pkey -pubout -in example.com.$(date +%Y%m) | openssl md5
と、1行に書くことで、視認性や意図が明確になります。これが
# 期限が延びていることを確認
openssl x509 -noout -dates -subject -in example.com.crt.$(date +%Y%m)
# 証明書から公開鍵を取得
openssl x509 -pubkey -in example.com.$(date +%Y%m) -noout | openssl md5
# 秘密鍵から公開鍵を取得
openssl pkey -pubout -in example.com.$(date +%Y%m) | openssl md5
と書かれていたら、1行ずつコピーする羽目になり、作業時の手間と効率化がまるで違います。
特に:サーバのバックアップ、復旧、切り戻しといった緊急と正確さが要求される状況下では、手順作成時のちょっとした手間がストレスを大きく軽減します。
最後に「記憶に頼るな、ログを信じろ」
- 何かおかしい
- 突然サーバが止まった
- 誰かが攻撃している?
などのほぼ全ての証跡はログに残されています。ログに残っていなければその途絶えたところが証拠です。(いわゆる『吠えなかった犬の推理』)
例えば、先日、Nextcloudのレスポンスが悪い、という時の決定的な証拠は/var/log
配下のphp8.3-fpm.log
に現れていました。
[04-Oct-2025 17:32:36] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 18:45:55] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 21:28:57] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
これにより、PHP-FPMのプールの設定値に問題があったと特定できたのです。
何か怪しいと思ったら自分の設定値と同時に/var/log
配下の関連しそうなところを確認しましょう。
そして、ログをそのままググり、どこかで誰かがエラーを元に解決策を残しているという期待もしましょう。
まとめ
と、わりとさっくりとした言い方ではありますが、
- 切り戻せる姿勢
- バックアップの大切さ
- 手順の明確さ
- タイムスタンプ
という4本の柱をメインにすれば、まず問題は無いかと思います。
『むこうぶち』の中にも
「船が陸にたどり着く寸前に生憎の嵐…… どうすればいいと思います?
いったん沖に引き返すんですよ
船ってのは水に浮かぶようにできているんです
無闇に上陸を焦って座礁する事が一番怖い」
は、サーバ運用にも通じるアナロジーとなっています。