Logrotateは、非root所有権のためにシンボリックリンク設定ファイルを読み取らなくなりました。


15

私たちは現在、Ruby on RailsアプリケーションサーバーでUbuntu 12.04 LTSから14.04 LTSにアップグレードしていますが、ログファイルが回転しなくなっていることに気付きました。

両方のマシンにファイルがあります /var/app-name/config/logrotate 私達のunixユーザーが所有しています deployer 次のような有効なlogrotateファイルが含まれています。

/var/app-name/log/*.log {
  daily
  rotate 365
  delaycompress
  compress
  dateext
  dateformat -%Y%m%d
  missingok
  copytruncate
}

これは次にシンボリックリンクされます。 /etc/logrotate.d/ ディレクトリ app-name

私たちのUbuntu 12.04サーバーには、logrotate 3.7.8があり、これは問題なく動作します。それはに入ります var/app-name/log/ ディレクトリとすべてのログファイルをローテーションする

しかし、Ubuntu 14.04サーバーではlogrotate 3.8.7があり、アプリケーションのログファイルは回転しません。

私がこれをデバッグするとき sudo logrotate -d -f /etc/logrotate/.conf 次のような出力が得られます。

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

これをコードで追いかけていくと、この変更は3.8.xリリースストリームに追加されたようです。 https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

シンボリックリンクファイルの所有権をに変更した場合 /var/app-name/config/logrotateroot それからそれは再び働き始めます。しかし、このファイルは私のアプリケーションの一部であり、この状態で使用するcapistranoデプロイメントフレームワークによって作成されたものであるため、以前は問題なく動作していた場合は所有権を変更する必要はありません。

それでは、シンボリックリンク設定ファイルはlogrotateで推奨/サポートされていますか?

もしそうなら、それは私のファイルを使用することを拒否すべきです deployer これはにシンボリックリンクされています /etc/logrotate.d ディレクトリ、バグと見なされる?

それとも、アプリケーション固有のログローテーションのための別の推奨アプローチはありますか?

(また尋ねた unix StackExchange


良い質問!あったようです いくつかの議論 後でuid == 0の代わりにユーザー名 "root"と照合することについてのチェックについては後で説明しますが、それはなぜroot所有権が必要なのかという疑問を引き起こしませんでした。
agtoever

回答:


6

問題は、logrotate設定ファイルが実行できることです。 どれか rootとしてのコマンド(prerotate / postrotateスタンザを使用)。したがって、あなたは事実上あなたの deployer ファイルへの書き込みアクセス権を与えることで、ユーザーroot権限 /etc/logrotate.d/。いいえ、それはバグではありません。

あなたがあなたのdeployerユーザーを信頼しているなら、私はあなたにそれにファイルをコピーするsudo権限を与えることによって問題を解決できると思います /etc/logrotate.d/。もちろん、デプロイヤーユーザーはWebアプリケーションを実行しているのと同じユーザーではないと想定します。


私たちのアプローチは常に、アプリケーションの外部のディレクトリからアプリケーションファイルへのシンボリックリンクを好むようにしていました。その結果、デプロイするたびに新しいアプリケーションだけでなく、設定ファイルの変更もプッシュされます。デプロイ担当者にアプリケーションディレクトリの外部にコードをデプロイする権限を与えたとしても、このアプローチに違反します。ただし、デプロイ後にアプリケーションファイルをroot所有にする必要があることも同様に悪いことです。そのため、おそらくオリジナルのアプローチではlogrotate 3.8.0以降ではうまく機能しなくなる可能性があります。
phantomwhale

2
@phantomwhaleあなたのオリジナルのアプローチはあなたのデプロイヤーユーザーに完全なroot権限を暗黙のうちに与えました。 logrotate 3.8ではこれは新しいことではありません。それでも設定の更新を許可しながらデプロイヤの権限を制限したい場合は、logrotate以外のものを使用する必要があると思います。
pelle

2

パーティーにはちょっと遅れているようですが、私は同様の問題を抱えていたので、自分の解決策を共有すると思いました。

私の問題はいつ始まった logrotate 私が書いた設定を読めないでしょう。 deployユーザーにrootアクセス権を与えたくないため、新しい設定をrootが所有するフォルダに配備したくありません 何でも

最初は走ろうとした logrotate デプロイユーザとして、しかし状態ファイルにアクセスすることについて不平を言った /var/lib/logrotate/state。それから私はmanページを読みました。以下の状態ファイルを指定できます。 logrotate 使う!それで、実行するために毎日のcronを設定することは私にとってより良い解決策のようでした logrotate カスタム状態ファイルを持つデプロイユーザーとして。この方法では、デプロイユーザーまたはアプリケーションによるrootアクセスは不要です。

状態ファイルを指定する方法は次のとおりです。

logrotate --state /path/to/status /path/to/custom_logrotate.conf

logrotateを好きなユーザーおよび設定所有者として実行できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.