Josh Fisher wrote: > Kern Sibbald wrote: > >> On Thursday 26 March 2009 21:23:51 Steve Polyack wrote: >> >> >>> Eric Bollengier wrote: >>> >>> >>>> + /* Deduce the source IP address from our list of daemon addresses */ >>>> + src_ipaddr = (IPADDR *) src_addr_list->first(); >>>> >>>> Why did you take the first address from this list ? Don't you think that >>>> it can create an asymetric routing configuration when using multiple >>>> network card or when using direct network attachment (with vlan) >>>> >>>> src_addr = (10.0.0.1, 192.168.1.1) (eth0, eth1) >>>> src_ipaddr = 10.0.0.1 >>>> >>>> incomming_addr = 192.168.1.1 >>>> >>>> It will give a socket with this configuration : >>>> src_ipaddr = 10.0.0.1 >>>> dst_addr = 192.168.1.1 >>>> >>>> Packets will use eth1 to go, and will be back by eth0... >>>> >>>> Does it make sens ? >>>> >>>> >>> Yes, it makes sense. This is a valid concern. I'm beginning to much >>> prefer the addition of an additional Director and FileD configuration >>> resource. I could add DirSourceAddress and FDSourceAddress options and >>> use the default (non-binding) socket behavior if these are not present. >>> This way this would affect no users who do not explicitly choose to use >>> the feature. >>> >>> >> Yes, even if it means adding extra directives, which we are trying to avoid, >> it would be much better not to change existing behavior without the user >> explicitly choosing to do so. That fits much better with how we normally >> add >> new features to Bacula. >> >> > > Why not require the use of DirAddresses, FDAddresses, etc. directives if > source binding is desired? Since the addresses can be specified in any > desired order, there should then be nothing wrong with arbitrarily > choosing the first one. Something like the following behavior (using Dir > as an example): > - If DirAddresses is specified, then Dir would listen on the given > addresses and bind to the first address specified when making outgoing > connections. > - If DirAddress is specified, then Dir would listen on the single > specified address and not do a bind when making outgoing connections. > - If neither is specified, then Dir would listen on all interfaces > and not do a bind when making outgoing connections. > > That still leaves the case where DirAddresses is used to specify > multiple particular listen addresses, but the listen addresses are on > disjoint networks with no routing between them, AND there are other > interfaces on the machine that Bacula must not listen on. > As far as I'm concerned this presents the same problem. If someone with two interfaces as described above explicitly specifies to listen on two addresses, one on 192.168.1.0/24, and one on 10.0.0.0/24, the director chooses the first address and is left unable to contact clients on the 10.0.0.0/24 network. Now, with adequate documentation this is avoidable by not specifying the DirAddresses statement, causing the director to listen on everything and not explicity bind to one address for outgoing connections. I can only see this leading to user confusion, not to mention requiring existing users to change how Bacula is configured because they specified addresses to listened on.
I think the separate config directives, DirSourceAddress and FDSourceAddress present a much more elegant solution. I have a patch ready that I'm finishing testing on and plan to submit later today. Thanks again for the comments and interest. -Steve Polyack ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
