On Tuesday 21 August 2007 06:49:27 pm Kenny Dail wrote:
> > > I use the client's hosts file to take care of directing the client to
> > > the right address.
> >
> > This does not work for SD. There is no way to tell file client on which
> > host SD resides. There is no such configuration option for FD. It gets
> > this information from director and I can't configure director and SD on
> > the server to only listen on internal interface because the majority of
> > clients are on external network and they won't be able to reach SD in
> > that case. If you think it works for you then grab tcpdump and check for
> > yourself - it does not. FD indeed will connect via configured interface
> > but then it will also connect to SD on whatever hostname/interface *SD*
> > has in its configuration file and will proceed sending all file data and
> > attributes via this interface, not the first one. Only commands exchange
> > protocol between FD and the director will be carried over the
> > FD-configured interface.
> >
> > The only way to prevent this behavior as I see it is to add static routes
> > on both internal network client and DIR/SD server to route all traffic
> > to/from external interface to internal one transparently for bacula
> > services. For this to work I would also need to enable routing on both
> > machines and reconfigure firewall on DIR/SD server. Not an elegant
> > solution by any means...
>
> The Director tells the FD the hostname of the SD. You put the hostname
> of the SD into the hosts file of the computer the FD is running on. When
> the client computer resolves the hostname of the SD it will check the
> hosts file first to see which address to connect to.

Now I got it ;-). This may work if I edit hosts files on all of my dual-NIC 
clients as well as on bacula server by substituting external IP address with 
internal one for machines' own hostnames. This however will screw up hosts 
resolution for all network applications and no doubt will have implications. 
For one, mailing system will fail to work since it uses institutional mail 
gateway on external network which is set up with strict security and will 
hence reject messages from hostnames not registered in our DNS. There may be 
other problems as well (OSCAR is rather picky about host name resolution). It 
is most possible to work around these problems but I'd rather stick with the 
static cross-routing for now. Sure, it will consume some CPU cycles to route 
all traffic between two interfaces but at least it is as transparent as 
possible solution.

Thanks for the advice however and for being persistent with it! I admit my 
brains have started to fail after two weeks of struggle with bacula ;-). If 
static routing won't work as expected I may still give your suggestion a try.

--Ivan


The information transmitted in this electronic communication is intended only 
for the person or entity to whom it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
information in error, please contact the Compliance HelpLine at 800-856-1983 
and properly dispose of this information.

-------------------------------------------------------------------------
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

Reply via email to