CODEWITHSUNDEEP
bacula
Ralph Bolton
Ralph Bolton

Reputation: 854

How to use TCP Wrappers with Bacula?

I have a Bacula server running, which happily backs itself up. I'm now connecting up remote clients with standalone File Daemons and having trouble with TCP Wrappers. I'm finding that the connection (with telnet/nc etc) connects but is immediately closed (which is typical TCP Wrappers behaviour), but nothing is logged in syslog, or in the File Daemon's log (if debug logging is switched on).

I've tried various permutations of /etc/hosts.allow and hosts.deny. At present I have these:

hosts.allow:

bacula-fd: 1.2.3.4

hosts.deny:

ALL: ALL

/etc/services contains an entry like this:

bacula-fd    9102/tcp

I also found this in the Bacula documentation:

You must adjust the names to be the same as the Name directives found in each of the daemon configuration files. They are, in general, not the same as the binary daemon names. It is not possible to use the daemon names because multiple daemons may be running on the same machine but with different configurations.

I've tried various names in place of 'bacula-fd', but still can't figure it out. Any ideas what I need to change to make this work?

Upvotes: 2

Views: 454

Answers (1)

Ralph Bolton
Ralph Bolton

Reputation: 854

After a few hours of getting bogged down with this, I've found the solution.

Advanced TCP Wrappers can do more than just use hosts.allow/deny and services files. The actual binary the wrappers protect can also add in some config. Bacula is the first I've knowingly come across that does this, hence my confusion.

The 'daemon' name (in hosts.allow/deny's first column) is actually defined in /etc/bacula/bacula-fd.conf. It's the 'FileDaemon Name' in the config. For example:

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
}

...will have a TCP Wrappers daemon name of 'bacula-fd'. Change the bacula-fd.conf to this:

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
}

...and you'll need a hosts.allow that looks like this:

gribblechops: 1.2.3.4

This is somewhat confusing because it's slightly contrary to the (possibly OS vendor supplied?) entries in /etc/services which aren't actually used (unless you run the FD through xinetd).

Thankfully, as far as Bacula Director goes, it doesn't seem to matter what the client config's 'Name' is. The Director knows the client by it's own configs, not those on the client itself. That's possibly good news because it means the client configs can be pretty 'default' for most people (and only really needs to deviate if you run multiple client instances).

Upvotes: 2

Related Questions