Hi,
30.09.2009 15:07, baculalist AT encambio DOT com wrote:
> On mer., sept 30, 2009, Arno LEHMANN wrote:
>> 30.09.2009 13:38, baculalist AT encambio DOT com wrote:
>>> Problem:
>>> A single storage daemon listens on 64.12.34.56 AND 192.168.1.2,
>>> and provides a certificate (myhost.domain.com corresponding to
>>> 64.12.34.56) to incoming connections from directors and file
>>> daemons. Incoming connections to 192.168.1.2 fail, because
>>> mycert.domain.com only resolves to the first of the two IP
>>> addresses. The configuration keyword TLS Require is set to
>>> 'yes' (as it should be.)
>> Definitely challenging :-)
>>
> Yes, but it shouldn't be. It's safe to assume that people use
> Bacula, TLS, and have a host is behind a NAT router. That's not
> exotic or challenging in itself.
Well... it is not as common as a plain network setup. Which is
probably the reason that nobody stumbled over it yet.
>>> Tested solution:
>>> I've tried running two almost identical storage daemons. In this
>>> case there are two configuration files, only differening in the
>>> listening IP address and having two different certificates. Although
>>> this should work, running 'bacula-sd <options> -c second-sd.conf'
>>> fails silently and no new bacula-sd process is created.
>> Have you set a different Name, Working Directory and, most important,
>> a different SDPort in the configuration?
>>
> Yes, the name 'Storage { Name = myhost(int|ext)-sd' is different.
Good.
> Making a new working directory for each instance of a running daemon
> makes administration more difficult, so I've not done that.
>
> I think setting a different SDPort might work, as I believe the
> storage daemon tries to write a pid file bacula-sd.<port>.pid,
> being the same as the first running daemon. In practice however,
> this is a hack because the same port number can be used on different
> IP addresses.
Right, but I tried to cover most possible reasons with my suggestion.
>
> I do understand your point. I'll either do one of these hacks or
> change the source code to write a properly different .pid file (if
> that's what is causing the silent failure.)
>
>>> What is the proper way to go about listening on two subnets while
>>> presenting the proper certificate to incoming TLS connections?
>> I guess the Bacula TLS implementation would need some work. Apart from
>> that, different host names with their "own" certificates might be
>> required.
>>
>> I guess this might become a feature request...
>>
> That's my thought as well, so let's make a suggestion.
>
> Feature request:
> Introduce a way to associate a server certificate for TLS
> connections in the '(Dir|FD|SD)Addresses' block, so that clients
> receive the correct certificate (corresponding to the IP address
> in question.)
>
> Reason:
> To allow Bacula users TLS connections even when having a mixed
> network landscape of hosts with private and public IP addresses.
> One host might be behind a NAT router for example, and so the
> user would like to serve Bacula requests over a plain internal
> IP address 192.168.1.2, as well as a tunneled one (bypassing the
> NAT.)
>
> Details:
> As shown on 'Storage_Daemon_Configuratio.html', the following
> structure allows a storage daemon to listen on multiple addresses.
> This feature request describes missing logic as marked with '**'
> in the altered structure below.
>
> SDAddresses = {
> ipv4 = {
> addr = public.host.tld;
> port = 9103;
> **TLS Enable = (yes|no)**
> **TLS Require = (yes|no)**
> **TLS Verify Peer = (yes|no)**
> **TLS Allowed CN = "third.party.host.tld"**
> **TLS CA Certificate File = <path>**
> **TLS Certificate = <path>**
> **TLS Key = <path>**
> **TLS DH File = <path>**
> }
> ipv4 = {
> addr = privat.host.tld;
> port = 9103;
> }
> }
>
> Is there some policy or special procedure for making feature
> requests?
Just as described on the web site... Your feature request is almost in
the right shape - I recommend to send it in an extra mail, with
"Feature Request" in the subject, formatted like in the examples, so
the developers will more easily pick it up.
Arno
> Regards,
> Eduard
>
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
