BaculaでTCP Wrappersを使用するには？

Question

私はBaculaサーバを稼働させています。私は現在、スタンドアロンのファイルデーモンとリモートクライアントを接続し、TCPラッパーに問題があります。私は接続（telnet/ncなど）は接続しているが、すぐに閉じられる（通常のTCP Wrappersの動作です）が、syslogやファイルデーモンのログ（デバッグログがオンの場合）には何も記録されません。

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

のhosts.allow：

bacula-fd: 1.2.3.4 

がhosts.denyの：

ALL: ALL 

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

bacula-fd 9102/tcp 

をIまた、Baculaのドキュメントでこれが見つかりました：

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

私は 'bacula-fd'の代わりにさまざまな名前を試しましたが、それはまだ分かりません。私はこの作品を作るために何を変える必要がありますか？

Answer 1

これで何時間も悩んだ後、私は解決策を見つけました。

高度なTCPラッパーは、単にhosts.allow/denyとservicesファイルを使用するだけではありません。ラッパーが保護する実際のバイナリは、いくつかの設定で追加することもできます。 Baculaは私が故意にこれをやって来た最初のものなので、私の混乱。

実際には、 'daemon'という名前（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ラッパーデーモン名を持ちます。

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のが必要になります：これまでのbacula-fd.confを変更

gribblechops: 1.2.3.4 

それがわずかに反しますので、これはやや紛らわしいですxinetdからFDを実行しない限り、実際には使用されていない/ etc/servicesに（おそらくOSベンダ提供の？）エントリがあります。

ありがたいことに、Bacula Directorが行っている限り、クライアント設定の「名前」が何であるかは関係ありません。ディレクターはクライアント自体の設定ではなく、クライアント自体の設定でクライアントを認識します。これはおそらく良いニュースです。なぜなら、クライアントのconfigsは、ほとんどの人にとってかなり「デフォルト」になることができるということです（複数のクライアントインスタンスを実行する場合は、本当に逸脱する必要があります）。