Hello,
Thanks for rewriting your patch. As Eric has pointed out, there are ways to
handle these problems within the OS. However, I think that your patch adds a
lot of convenience for the user and so given the resolution to some questions
I have (see below), I see no problem applying it to Bacula.
We are just about to release version 3.0, so I am holding all patches that add
new features. About the only question I have about the patch is whether or
not it is portable -- i.e. will it build on all currently supported Unix
systems (there are some odd ones such as AIX, HP/UX, SGI, ...), and will it
build on Win32/64?
If you do not hear from us within 2 weeks after the release of 3.0, please
ping me about the status of this patch.
Thanks for your interest and contribution to Bacula.
Best regards,
Kern
PS: Please see www.bacula.org -> FSFE License about the paper work we need :-(
before actually accepting important patches such as yours ...
On Friday 27 March 2009 17:45:50 Steve Polyack wrote:
> Steve Polyack wrote:
> > Back to the drawing board.
>
> I redid this patch to utilize two new config options: FDSourceAddress
> (bacula-fd.conf) and DirSourceAddress (bacula-dir.conf). When either of
> these are not set, the connection behavior does not change; bind(2) is
> not called and the kernel chooses the outgoing address. If you specify
> a source address Bacula will now choose that address to source
> connections from.
>
> Here's an example for the Director and SD of where this becomes useful:
> You have a Bacula director with several IP addresses available.
> 10.0.0.100 is a management address (firewall lets authorized users/IPs
> ssh to the server at this address), and 10.0.0.200 is the backup VIP. I
> have a storage daemon on anothermachine listening on a VIP 10.0.0.250.
> Previously, since 10.0.0.100 is the first address on the interface, when
> the Bacula director tries to connect, (whether it's to a storage daemon
> or file daemon) this connection will come from 10.0.0.100. This makes
> writing firewall rules in "default deny" environment unintuitive.
> Instead of just using the address the storage daemon and director are
> listening on ("bound" to) and writing firewall rules like:
> allow $clients to $director on port 9102
> allow $director to $storageDaemon on port 9103
>
> I have to make exceptions to account for bacula connecting *from* the
> management address.
> allow $clients to $director on port 9102
> allow $director-Mgmt to $storageDaemon on port 9103
>
> But now, I can tell the director to source it's connections from the
> same VIP it is listening on:
> DirAddress = 10.0.0.200
> DirSourceAddress 10.0.0.200
> and corresponding "rules":
> allow $clients to $director on port 9102
> allow $director to $storageDaemon on port 9103
> This preserves a 1:1 mapping of the Bacula services to the Bacula VIP.
>
> Let me know if you need any further clarifications. The patch is attached.
------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
