logrotate戦略を正しくオーバーライドする方法は?

logrotate戦略を正しくオーバーライドする方法は?

logrotateとを含むさまざまなDebianパッケージはrsyslog独自のログローテーション定義を持っています/etc/logrotate.d/

これらの定義をオーバーライドする正しい方法は何ですか?

ファイルを変更すると、システムが更新されるたびに警告が表示され、私(または他の人)が間違った答えを提供したり、私(または他の人)が手動でファイルをマージできない場合、変更が失われる可能性があります。 。新しいログファイルの新しいアップストリーム定義を取得できない可能性があります。この二つのことが、過去数年間で多く起こってきた。

00_*または、ファイルの定義をオーバーライドしようとしましたが、重複しzz_*たエラーが発生します。

error: zz_mail:1 duplicate log entry for /var/log/mail.log
error: found error in /var/log/mail.log , skipping

きれいな解決策はありますか?毎日定義ファイルに変更を再適用するには、cronスクリプトを作成する必要がありますか?


編集する:rsyslogより明確に言えば、理想的には、ログ回転定義の99%を維持し、APTを使用して自動的に更新したいと思います。単一の定義に加えて、/var/log/mail.log異なる循環戦略を適用する必要があります。

Logrotateが冗長定義を許可し、ファイルごとに最初または最後の定義のみを使用すると、私の問題は解決します。定義を意図的に以前の定義を上書きするようにマークするオプションがある場合、override問題も解決します。

/etc/logrotate.d/rsyslogしかし、残念ながら私のバージョンですべての内容を扱う必要があるようです。nginx

答え1

まず、次のツールを使用することをお勧めします。etckeeperファイルの変更を追跡し、/etcアップグレード中のデータの損失を防ぎます(他の利点も含みます)。

定義をオーバーライドする「正しい」方法はい設定ファイルを直接編集します。したがって、dpkg構成ファイルで何をすべきかがわかり、アップグレード時に変更が適用されるとメッセージが表示されます。残念ながら、あなたも知っているように、これは理想的ではありません。

特定の設定の問題を Debian に優しい方法で実際に解決するには、メール メッセージを実際に別のログ ファイルに記録して設定することをお勧めします。それ〜に横たわっているlogrotate

  • 新しいログファイルを/etc/rsyslog.d指す新しいログ設定ファイルをに追加します。mail.*例えば /var/log/ourmail.log(使用していると仮定rsyslog- 適切に変更)。
  • /var/log/ourmail.log新しい設定ファイルで設定しますlogrotate

これには新しい設定ファイルの追加のみが含まれるため、アップグレードの問題はありません。既存のログファイルはデフォルト設定を使用して生成され、循環されますが、ログファイルは設定に従います。

答え2

Debian でデプロイのデフォルトとは異なる設定/バイナリファイルのコピーを保持する 1 つの方法は、ファイルを「転送」することです。たとえば、debパッケージの新しいバージョンをインストール/更新するときに、パッケージマネージャに特定のファイルを別のディレクトリにインストールするように指示します。

dpkg-divert私はBINDとISC-DHCPのinit.d sys Vラッパーを保存するために長年この機能を使用してきました。このラッパーは DNS および DHCP 構成ファイルの整合性を確認し、サービスの再起動時に変更されたファイル領域を自動的に増やします。シリアル番号がバインドされます。

また、nfsenサーバーでこれを使用して、debパッケージのバージョンではなくバイナリバージョンをコンパイルしたままにします。

これにより、必要に応じて元の場所を変更できます。

おそらく私はあまりにも多くのシステムを好きなように管理し、ファイルシステム構成の標準的な場所を変更しました。したがって、より難解な構成でこの機能を使用するには、修正を破ることは望ましくありませんが、それでも可能であると思います。アップグレード特典でこれを使用してください。

Debian がデフォルトで転送するために使用するファイルが既に存在する場合があります。次のコマンドを使用してそのファイルを一覧表示します。

dpkg-divert --list

~からman dpkg-divert

はい

   To  divert  all  copies  of  a /usr/bin/example to /usr/bin/example.foo, i.e.
   directs  all  packages  providing   /usr/bin/example   to   install   it   as
   /usr/bin/example.foo, performing the rename if required:

   dpkg-divert --divert /usr/bin/example.foo --rename /usr/bin/example

   To remove that diversion:

   dpkg-divert --rename --remove /usr/bin/example

   To    divert    any   package   trying   to   install   /usr/bin/example   to
   /usr/bin/example.foo, except your own wibble package:

   dpkg-divert   --package   wibble   --divert   /usr/bin/example.foo   --rename
          /usr/bin/example

   To remove that diversion:

   dpkg-divert --package wibble --rename --remove /usr/bin/example

Debian-Administration.orgサイトも参照してください。dpkg-divertを使用したバイナリの交換

明らかに、このディレクティブは非常に便利ですが、乱用することはお勧めできません。

@Stephen Kittの住所は可能構成ファイルに問題があります。アップグレードが転送されたファイルに影響を与え、設定に大きな変更がある場合(たとえば、新しいDebianバージョンにアップグレードする可能性が高い場合など)、デーモンは起動せず、この状況を手動で解決する必要があります。また、公正に言うと、プロファイルを送信しなくてもこれが起こる可能性があります。

IMOこれは、他のLinuxディストリビューションと比較してdkpg-divertDebianパッケージマネージャの真の柔軟性を示す機能の1つです。

答え3

Stephenが言ったように、設定ファイルを直接編集する必要がありますが、それでもカスタムディレクティブをそこに置く必要があるわけではありません。

編集/etc/logrotate.d/rsyslog独自のオーバーライドディレクティブを含む別のファイルを使用して、既存のディレクティブの末尾に行を追加します。

/var/log/syslog
{
        ... existing directives ...

        include /etc/logrotate.d/override/rsyslog
}

次に、オーバーライドディレクティブのみを含むオーバーライドファイルを作成します。

/etc/logrotate.d/override/rsyslog

weekly
rotate 0

システムのアップグレード中はまだ注意が必要ですが、パッケージが提供する基本構成を再パッチすることは非常に簡単です。 1行だけ追加してください。

私にとって、これは少なくともシステム標準に準拠し、明確で理解しやすく保ちながら、システムをアップグレードするたびに違いを手動でマージする必要がないため、許容可能なトレードオフです。

答え4

また、プロフィールの変更に関する警告について考えてみましょう。なぜそれを得たのですか?これは良いことですか?

ほとんどの場合、Debian に付属のデフォルト設定ファイルは主に必要な作業を行います。 2つの方法で変更できます。つまり、管理者やパッケージャが変更します。どちらかは正常で予想されるものです。しかし、両方が真である場合、正しいアプローチは何ですか?理想的には、両方とも同じ変更を実行してマージできますが、これもやりにくく、これが発生したことを見たことがありません。ほとんどの場合、パッケージャの変更を記録し、それを1行ずつ受け入れ、マージ、または拒否する必要があります。これまでに限られた方法でこれを行う方法は1つだけです。つまり、簡単な方法で追加のコンテンツを追加できますが、変更または削除することはできず、まだ役に立たない部分のディレクトリを構成することです。重大な変更が発生した場合は、予想通りに警告を受け取り、真剣に受け入れ、時間をかけて変更を比較して正しいことをします。

つまり、特定の場合(マイナーな変更であるため)、問題のフラグメントを無効にし(すべての読み取り権限をキャンセル、転送、または名前を変更して)、別の名前で新しいフラグメントを作成します。バックアップが良いので、etckeeperを使用することをお勧めします。

関連情報