2

私は Bacula サーバーを実行していますが、これは喜んでバックアップします。現在、リモート クライアントをスタンドアロンのファイル デーモンに接続していますが、TCP ラッパーに問題があります。接続 (telnet/nc などを使用) は接続されますが、すぐに閉じられます (これは典型的な TCP ラッパーの動作です) が、syslog またはファイル デーモンのログ (デバッグ ログがオンになっている場合) には何も記録されません。

/etc/hosts.allow と hosts.deny のさまざまな順列を試しました。現在、私はこれらを持っています：

ホスト.許可:

bacula-fd: 1.2.3.4

hosts.deny:

ALL: ALL

/etc/services には、次のようなエントリが含まれています。

bacula-fd    9102/tcp

Baculaのドキュメントでもこれを見つけました：

各デーモン構成ファイルにある Name ディレクティブと同じになるように名前を調整する必要があります。一般に、これらはバイナリ デーモン名と同じではありません。複数のデーモンが同じマシン上で異なる構成で実行されている可能性があるため、デーモン名を使用することはできません。

「bacula-fd」の代わりにさまざまな名前を試しましたが、まだわかりません。これを機能させるために何を変更する必要があるかについてのアイデアはありますか?

4

1 に答える 1

2

これで数時間行き詰まった後、解決策を見つけました。

高度な TCP ラッパーは、hosts.allow/deny および services ファイルを使用するだけではありません。ラッパーが保護する実際のバイナリも、一部の構成に追加できます。Bacula は、私が故意にこれを実行することに初めて遭遇したため、混乱しています。

「デーモン」名 (hosts.allow/deny の最初の列) は、実際には /etc/bacula/bacula-fd.conf で定義されています。これは、構成内の「FileDaemon Name」です。例えば：

FileDaemon {                          # this is me
  Name = bacula-fd
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /var/spool/bacula
  Pid Directory = /var/run
  Maximum Concurrent Jobs = 20
}

...「bacula-fd」という TCP Wrappers デーモン名を持ちます。bacula-fd.conf を次のように変更します。

FileDaemon {                          # this is me
  Name = gribblechops
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /var/spool/bacula
  Pid Directory = /var/run
  Maximum Concurrent Jobs = 20
}

...そして、次のような hosts.allow が必要になります。

gribblechops: 1.2.3.4

実際には使用されない (xinetd を介して FD を実行しない限り) /etc/services の (おそらく OS ベンダーが提供する?) エントリとは少し反対であるため、これはやや混乱します。

ありがたいことに、Bacula Director に関する限り、クライアント構成の「名前」が何であるかは問題ではないようです。Director は、クライアント自体の構成ではなく、独自の構成によってクライアントを認識します。クライアント構成がほとんどの人にとってかなり「デフォルト」である可能性があるため、これはおそらく良いニュースです（複数のクライアントインスタンスを実行する場合にのみ、実際に逸脱する必要があります）。

于 2016-05-10T16:23:58.250 に答える