Ivan Adzhubey wrote:
> Hi Martin,
>
> On Friday 17 August 2007 04:46:24 pm you wrote:
>>> where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
>>> server's external address; 192.168.0.{253,200} are the corresponding
>>> private addresses. As you can see, while fd daemon on client has indeed
>>> been bound to the private address, it still uses external one for
>>> communicating with sd daemon on the remote bacula server. I've been
>>> through all configuration options to no avail. Unfortunately, binding sd
>>> on the server to private net only is not an option since it also has
>>> numerous other clients configured, that are only accessible via external
>>> net (desktop boxes all around the building, etc). Is there any solution?
>>> I am running bacula 1.36.1.
>> The FD is told to connect to the "Address" from the Director's Storage
>> resource, so maybe you can set that to something that resolves to the
>> internal network on the dual-NIC clients?
>
> AFAIK, in this case SD will always attempt to connect via internal network
> upon request from any clients and that won't work for (the majority of) my
> clients that are on external network. I am assuming there is no way to
> specify multiple aliases for the same Storage resource in bacula-dir.conf,
> but with different Addresses. Anyway, such setting clearly belongs to
> client's configuration, so I consider it a bug. FD should ensure that all of
> its communications with other daemons go exclusively through the network
> address specified in its conf file (if any). But I have no clue how to
> implement this since current bacula networking model obviously contradicts.
>
IMO, I dont think it counts as a Bacula bug.
You've bound the FD to the internal network, but are telling to to talk
to an address on the external one.
It's the networking on the FDs host that is deciding to go out the
external interface, as that's the only way it knows to reach the
external SD address.
I'm not sure the FD has any control over this behavior at all. Even if
it does, the default behaviour of 'reach the sd regardless so we get
this critical backup completed' is desirable in a backup solution.
You could try setting up 2 SDs on the one box, one internal, one
external, but if you are using tapes for backups you'll have to resolve
resource conflicts possibly.
Anyone know if having 2 Storage resources in the directors conf, point
to one actual SD has a chance of working?
It's not something I've tried, so I have no idea personally.
Only other suggestion I have is hostname based resolution. Use
'Address=StorageDaemonHostName' and have entries in the host files on
your 'internal clients' that map this to the internal address. Have your
DNS map it by default to the external address for your external clients
use, and see how it goes.
Just a thought,
Cheers,
Troy.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
