【WordPress - Bitnami】logrotateの設定について

2022年5月13日 2022年5月13日

hakutatsu

先日、運用しているHPでクロスサイトスクリプティング攻撃が観測され、サイトがたまにリダイレクトされてしまう被害に遭いました。

その後復旧作業を実施し、今は経過観察中ですが、本当に心臓に悪い。。
ファイルが削除できなくされていたり、.htaccessファイルが書き換えられていて編集できなくなっていたりと、相当めんどくさかったです。
というか再構築する羽目になりました。

それらの経験から、セキュリティ周りはもちろん、各種設定を見直したりしていました。
今回はその中でもlogrotateの設定について確認します。

logrotateとは

logrotateとは、Linuxベースのコマンドです。
実態はcronとコマンドで、設定された内容に基づいてcronを組んでくれてログを管理してくれます。

結構便利、というか運用する上では必須だと思うのですが、仕事ではログ周りは別の方に任せていたりとか、今回紹介するBitnamiもデフォルトで有効化されてはいますので、あまり触る機会がありませんでした。

それこそ、Linucの勉強で触れた以来ですね。

一般的な使い方としては、manを日本語翻訳してくださった方が居て助かりました。
今回は元々設定したい内容の目処がついていたのでさっと調べるだけにしていますが、業務用件とかあれば公式ドキュメントをご参照ください。

今回はBitnamiのイメージで作られたWordpressでの設定変更を見ていきます。

Bitnamiでの設定

ドキュメント

前述の通り、Bitnamiでは大体の場合でデフォルト有効化されています。
今回はAWSのLightsailを使って構築したイメージです。

基本的にはドキュメントに従って設定を探ろうとした、のですが。。

アプローチ、どっちの環境？

現在、Bitnamiはファイル構造がバージョン？によって混在しているようです。
実際、いくつかのイメージを持っていますが確かに異なるイメージがありました。

それを確認するコマンドがドキュメントであるのですが、

test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation."

なぜか今回の環境では実行結果が帰ってこない（空行）で、どっちのアプローチか判別がつきませんでした。

ということでコマンドを分解して手動で確認することに。

test ! -f "/opt/bitnami/common/bin/openssl"

-fを使ってファイルを指定しますが、!がついているので否定形。
つまり、「/opt/bitnami/common/bin/openssl」というファイルが存在しなかった場合、という意味ですね。

&& echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation."

その結果を受け、後続では
ファイルが存在しない→アプローチA
それ以外（ファイルが存在する）→アプローチB
という分岐をさせているように見えます。

ということで、手動で確認する場合はとりあえず上述のファイルがあるかどうかを確認すれば良さそうです。

そして、今回の環境では/opensslの「ディレクトリ」は存在したものの、ファイルは無かったのでアプローチBということが判明しました。

（追記）
ちなみに、記事執筆中に確認したところコマンドちゃんと通りました。
落ち着いてもう一回試すのは大事ですね。

設定内容

ようやくアプローチが分かりましたので、本題に移ります。

このバージョンだとlogrotateの設定内容は以下で確認できるようです。

sudo logrotate -d /etc/logrotate.d/bitnami.conf

今回は設定変更も実施したかったのですが、上記はシンボリックリンクのようです。
リンク先から大本のファイルをたどります。

私の環境だと以下にそれぞれのconfファイルがありました。

/opt/bitnami/config/logrotate/logrotate.d

この中にapache、mysql、php-fpmの各confファイルがありました。

試しにapacheの中身を見てみます。

"#"以降のコメントは勝手につけてます。
それ以外はデフォルトです。

/opt/bitnami/apache2/logs/*_log {
  weekly # 週次
  rotate 150  #150世代保管
  dateext # YYYYMMDD
  compress # 圧縮(gzip)
  copytruncate # コピー作成後、元のログファイルを空に
  missingok # 存在しなくても処理続行
  postrotate # 以下のシェルを処理後に実行
    /opt/bitnami/apache2/bin/apachectl graceful 2>/dev/null || true
  endscript

}

基本的には良いかなー、という感じなんですが、個人規模のHPでアクセスログ、エラーログ共に150世代保管だと結構多いな、という印象ですね。。

週次150世代ということは1050日、約3年ですもんね。
アクセス多いところだと圧縮されてもログ量が数百MBに達していたのと、そもそも見てない。。ということで保管世代数はもう少し減らそうかなと。

あと気になったあたりはcopytruncateは便利なんですが、ログのロストは発生する可能性があるみたいなので、厳密な保管が必要な要件では外したほうがよさそうですね。

（そもそもbitnamiなんて使わない気もしますが）