web-dev-qa-db-ja.com

バージョンを使用してBINDサーバーのクエリログを構成する必要があります

私はBINDサーバーのクエリログを機能させようとしており、それぞれ最大100MBの3つのバージョンを作成しています。システムはSUSESLES 11です。Web上で記事を書く方法をたくさん見つけましたが、DNSサーバーを壊す以外に何もしていません。マシンはvirtualboxゲストであるため、クエリログを実行しない動作中のBINDサーバーの変更されていないスナップショットに戻ることができます。

ロギングステートメントをnamed.confに手動で追加すると、namedはロードされなくなります。メッセージには、「isc_stdio_open」と言ったものは何でも「失敗しました：ファイルが見つかりません」と表示されます。 chown named.namedログファイルは、動作を助けたり変更したりすることはありません。 apparmorプロファイルファイルを変更せずに保存するだけで、apparmorプロファイルファイルを直接操作すると、apparmorがそのプロファイルを再度ロードすることはありません。すでにプロファイルがあると表示されます。

スナップショットを復元する->変更を加えていない状態に戻す

gUIツールを使用して、DNSサーバーのロギングを構成します。 namesedはbcを開始しません。それでも権限がないか、ログファイルが見つかりません。 chownnamed.namedログファイルは役に立ちません。 GUIツールを使用してapparmorを構成します。これは少なくともapparmorプロファイルを殺すことはありませんが、状況に関係なく状況を改善することはありません。

私はこれを2つの異なるVMで試しました。どちらもSLES11で、どちらも基本的なものであり、すべてのデフォルトのインストールを使用しており、まだ本番環境にはありません。

私は、GUIツールの使用と構成ファイルの手動変更のいくつかの異なる組み合わせを試しました。/var/log/querylog、/ var/log/querylogs/querylog、/ root/queriesなど、ログファイルのさまざまな場所を試しました。 touchを使用してログファイルを作成し、named.namedにchownしてみました。 GUIを使用してファイル/ディレクトリを作成し、アクセス許可を設定してみました。

SLES 11 BINDサーバーで3つのファイルをローテーションしてDNSクエリログを取得する方法を知っている人はいますか？これほど面倒なことの近くにあるべきではないようです。

編集

現在、named.confのロギングセクションは次のようになっています。

ロギング{チャネルlog_file {ファイル "/var/log/query_log.log"バージョン3サイズ100M; };カテゴリのデフォルト{log_file; }; };

/ var/log/messagesで報告されるのは次のとおりです。

作業ディレクトリは書き込み可能ではありません。
isc_stdio_open '/ var/log/named/query_log.log'が失敗しました：ファイルが見つかりません>ログの構成：ファイルが見つかりませんでした（致命的なエラーのため）

したがって、何らかのアクセス許可の問題があるようです。そのディレクトリを作成し、query_log.logという名前の空のファイルをそのディレクトリに配置しました。私は所有者に名前を付け、/ var/log/namedですべての人に読み取り、書き込み、実行を許可し、/ var/log/named /query_log.logですべての人に読み取りと書き込みを許可しました

/ var/log/namedのls-l

-rwxrwxrwxl名前付き04月26日08：43query_log.log

ls-/var/logの

//さまざまなファイルとディレクトリ
drwxr-xr-x2という名前の40934月26日09:26という名前

編集2

バインドサーバーを起動するには、rcnamed startを使用します。名前を付けて開始できるようにロギングセクションを削除すると、ps aux |を実行します。 grep namedは、/ usr/sbin/namedがnamedユーザーとして実行されていることを示します。

これまでのご協力ありがとうございます。これを機能させるには何をする必要がありますか？

bindslesapparmor
1
GC78

SLES 11 BINDサーバーで3つのファイルをローテーションしてDNSクエリログを取得する方法を知っている人はいますか？これほど面倒なことの近くにあるべきではないようです。

面倒なことではありません。構文は単純でよく実行されています（数千、数千のネームサーバー管理者が使用しています）。理論的には可能ですが、新しいバグが見つかる可能性はほとんどありません。より可能性の高い原因を見てみましょう。

最初に構文を確認しても問題はありません。BIND管理者リファレンスマニュアル（別名「ARM」）で説明されているように、BINDバージョンに適したARMのコピーがBINDソースに含まれています。 ISCのWebサイトにあります）6.2.10、最初にチャネルを定義する必要があります。例：

channel example_query_channel { 
   file "bind_query.log" versions 3 size 20m; 
   print-time yes;
   print-category yes;
};

次に、ロギングに関心のあるカテゴリ（つまり「クエリ」）をそのチャネルに転送します。

category queries {
   example_query_channel; 
};

BINDを使用して再起動する前に、BINDに付属のnamed-checkconfユーティリティを使用して、構成ファイルの構文にエラーがないかどうかを確認できます。

それがうまくいかない場合は、ある種のファイルシステムのパーミッションの問題があり、特にBINDの問題はありません。 BINDは、適切なディレクトリで指定したファイルへの書き込みが何らかの理由で妨げられています。 root以外のユーザーとして実行する権限を削除していて、そのユーザーがファイルシステムのルートから書き込み中のディレクトリへのパス内のすべてのディレクトリをトラバースするための-x権限を持っていないか、または持っていない可能性があります-そのディレクトリにファイルを書き込むためのwperms。あるいは、問題をさらに複雑にしている別のセキュリティレイヤー（AppArmorについて言及している）があるかもしれません。

1
Michael McNally