[Bacula-users] TLS negotiation handshake errors
Hello List, Bacula 2.4.4 and OpenSSL 0.9.8k on Solaris x86 11 (nv-b91), everything is hand compiled but nothing special. Director hostname back1.host.com: Solaris x86 11 (nv-b91) File daemon hostname back1.host.com: Solaris x86 11 (nv-b91) Errors seen on the director: 08-Apr 09:36 bacsrv-dir JobId 40: Start Backup JobId 40, Job=Debut.2009-04-08_09.36.52.03 08-Apr 09:36 bacsrv-dir JobId 40: Using Device "FileStorage" 08-Apr 09:37 bacsrv-dir JobId 0: Error: openssl.c:86 Connect failure: ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number 08-Apr 09:37 bacsrv-dir JobId 40: Fatal error: TLS negotiation failed with FD at "back1.host.com:9102". If I try: back1$ /pfx/bin/openssl s_client -connect back1.host.com:9102 CONNECTED(0004) 10511:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: If I try: back1# /pfx/bin/openssl s_server -accept 1080 -cert bacula-crt.pem -key bacula-key.pem -CAfile certauth.pem back1$ /pfx/bin/openssl s_client -connect back1.host.com:1080 ...everything works and TLS negotiation succeeds without errors. By the way, an identical (same versions and config files) setup with two other hosts Ubuntu 8.04 server AMD64 and OpenSUSE 11 AMD64 succeeds. My question is, 'have you seen this (SSL3_GET_RECORD:wrong version number) or similar errors appearing in bacula? Any idea how to rid the daemons of this problem? Where is the openssl code which is responsible for the TLS negotiation and handshake - src/lib/openssl.c? Thanks, Eduard -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] TLS negotiation handshake errors
Hello Dan and Ryan, On mer., avr 08, 2009, Dan LANGILLE wrote: >baculal...@encambio.com wrote: >> Bacula 2.4.4 and OpenSSL 0.9.8k on Solaris x86 11 (nv-b91), >> everything is hand compiled but nothing special. >> >> Director hostname back1.host.com: Solaris x86 11 (nv-b91) >> File daemon hostname back1.host.com: Solaris x86 11 (nv-b91) >> >> Errors seen on the director: >> 08-Apr 09:36 bacsrv-dir JobId 40: Start Backup JobId 40, >> Job=Debut.2009-04-08_09.36.52.03 >> 08-Apr 09:36 bacsrv-dir JobId 40: Using Device "FileStorage" >> 08-Apr 09:37 bacsrv-dir JobId 0: Error: openssl.c:86 Connect failure: >> ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number >> 08-Apr 09:37 bacsrv-dir JobId 40: Fatal error: TLS negotiation failed with >> FD at "back1.host.com:9102". >> >> If I try: >> >> back1$ /pfx/bin/openssl s_client -connect back1.host.com:9102 >> CONNECTED(0004) >> 10511:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake >> failure:s23_lib.c:188: >> >> If I try: >> >> back1# /pfx/bin/openssl s_server -accept 1080 -cert bacula-crt.pem -key >> bacula-key.pem -CAfile certauth.pem >> back1$ /pfx/bin/openssl s_client -connect back1.host.com:1080 >> >> ...everything works and TLS negotiation succeeds without errors. >> >> By the way, an identical (same versions and config files) setup >> with two other hosts Ubuntu 8.04 server AMD64 and OpenSUSE 11 >> AMD64 succeeds. >> >> My question is, 'have you seen this (SSL3_GET_RECORD:wrong version >> number) or similar errors appearing in bacula? Any idea how to rid >> the daemons of this problem? >> >> >I Googled. I found: > >http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg04842.html > >Does that help? > Very little. I've checked that my certs are correct (permissions, CN=, etc.) In the bacula config files I've added hostnames (matching CN=) with 'TLS Allowed CN' in every possible place (according to th '-t' option to check config files.) As I wrote before, the identical configs taken to another machine don't lead to this failure. That's why I'm not convinced that it's a configuration problem as the post you found suggests. I'll keep trying more things in the meantime, but if anybody has another idea I'd love to hear it. Until this is fixed, bacula is useless to me. -- Eduard -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] TLS negotiation handshake errors
Hello Ryan,
On jeu., avr 09, 2009, Ryan NOVOSIELSKI wrote:
>baculal...@encambio.com wrote:
>> On mer., avr 08, 2009, Dan LANGILLE wrote:
>>> baculal...@encambio.com wrote:
Director hostname back1.host.com: Solaris x86 11 (nv-b91)
File daemon hostname back1.host.com: Solaris x86 11 (nv-b91)
Errors seen on the director:
08-Apr 09:36 bacsrv-dir JobId 40: Start Backup JobId 40,
Job=Debut.2009-04-08_09.36.52.03
08-Apr 09:36 bacsrv-dir JobId 40: Using Device "FileStorage"
08-Apr 09:37 bacsrv-dir JobId 0: Error: openssl.c:86 Connect failure:
ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
08-Apr 09:37 bacsrv-dir JobId 40: Fatal error: TLS negotiation failed
with FD at "back1.host.com:9102".
>>> I Googled. I found:
>>>
>>> http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg04842.html
>>>
>>> Does that help?
>>>
>> Very little. I've checked that my certs are correct (permissions,
>> CN=, etc.) In the bacula config files I've added hostnames (matching
>> CN=) with 'TLS Allowed CN' in every possible place (according to th
>> '-t' option to check config files.)
>>
>>
>What documentation have you used to set up Bacula with TLS? I seem to
>recall, actually, that there was one source of documentation that
>mentioned one step that wasn't in another (I believe the best one was
>written by Landon Fuller -- I forget where I found it). Perhaps you
>might want to search the list archives for discussions I had on this
>subject maybe 6-9 months ago as I believe I was pointed in the right
>direction.
>
>
Good ideas, I did see some configuarion advice from Landon. His
http://www.bacula.org/en/rel-manual/Bacula_TLS_Communication.html
does help, as does http://www.devco.net/pubwiki/Bacula/TLS/ from
R.I.Pienaar.
I trussed(1) the bacula-fd process and debugged the code to find
that the SSL logic reads(2) from a blocked socket (the same one
which the director CRAM-MD5 authorized with.) Because lib/tls.c
had set this socket to be nonblocking, the read(2) returns with
the error EAGAIN (errno 11.) The method openssl_bsock_session_start
in lib/tls.c is where this all happens, and finally returns false
(Socket Error Occured.) That is why the connection is rejected.
The trace:
$ truss /pfx/sbin/bacula-fd -f ...
[...]
/3: read(6, "\0\0\0 ", 4) = 4
/3: read(6, " H e l l o D i r e c t".., 32) = 32
/3: read(6, " a u t h c r a m - m d".., 52) = 52
/3: read(6, " 1 0 0 0 O K a u t h".., 13) = 13
[...]
/3: fcntl(6, F_GETFL) = 2
/3: fcntl(6, F_SETFL, FWRITE|FNONBLOCK) = 0
/3: time() = 1239322002
/3: time() = 1239322002
/3: time() = 1239322002
/3: brk(0x081EE990) = 0
/3: brk(0x081F4990) = 0
/3: brk(0x081F4990) = 0
/3: brk(0x081F8990) = 0
/3: brk(0x081F8990) = 0
/3: brk(0x081FC990) = 0
/3: brk(0x081FC990) = 0
/3: brk(0x081FE990) = 0
/3: read(6, 0x081F34A0, 5) Err#11 EAGAIN
[...]
The code (in src/lib/tls.c):
static inline bool openssl_bsock_session_start(BSOCK *bsock, bool server)
{
TLS_CONNECTION *tls = bsock->tls;
[...]
/* Ensure that socket is non-blocking */
flags = bsock->set_nonblocking();
[...]
for (;;) {
if (server) {
err = SSL_accept(tls->openssl);
[...]
/* Handle errors */
switch (SSL_get_error(tls->openssl, err)) {
case SSL_ERROR_NONE:
stat = true;
goto cleanup;
[...]
default:
/* Socket Error Occured */
openssl_post_errors(M_ERROR, _("Connect failure"));
stat = false;
goto cleanup;
}
[...]
cleanup:
/* Restore saved flags */
bsock->restore_blocking(flags);
/* Clear timer */
bsock->timer_start = 0;
return stat;
}
If I remove the fnctl(2) where the socket is set to nonblocking,
things go further but in the end the client is unable to read
anything and the director reports 'Fatal error: FD gave bad response
to JobId command: No data available.'
Anybody familiar with the logic around openssl_bsock_session_start,
or have an idea of what might be going on? Is anybody besides me
using Solaris? Remember that Solaris has its own not the BSD
variant) socket API.
--
Eduard
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
h
Re: [Bacula-users] Bacula version 3.0.0 released to Source Forge
Hello List, An ven., avr 10, 2009, Ralf GROSS schrieb: >Kern Sibbald schrieb: >> This is to inform you that we have uploaded the Bacula version 3.0.0 source >> tar files and the Win32/64 installer files to the Bacula Source Forge >> download location. >> >> >Thanks for your (and all contributors) work on bacula! > Yes, congratulations. Very good work. -- Eduard -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] TLS negotiation handshake errors (Solved)
Hello list, On ven., avr 10, 2009, baculal...@encambio.com wrote: On mer., avr 8, 2009, baculal...@encambio.com wrote: > Director hostname back1.host.com: Solaris x86 11 (nv-b91) > File daemon hostname back1.host.com: Solaris x86 11 (nv-b91) > > Errors seen on the director: > 08-Apr 09:36 bacsrv-dir JobId 40: Start Backup JobId 40, > Job=Debut.2009-04-08_09.36.52.03 > 08-Apr 09:36 bacsrv-dir JobId 40: Using Device "FileStorage" > 08-Apr 09:37 bacsrv-dir JobId 0: Error: openssl.c:86 Connect failure: > ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number > 08-Apr 09:37 bacsrv-dir JobId 40: Fatal error: TLS negotiation failed > with FD at "back1.host.com:9102". > > >I trussed(1) the bacula-fd process and debugged the code to find >that the SSL logic reads(2) from a blocked socket [...] > >[...] > >If I remove the fnctl(2) where the socket is set to nonblocking, >things go further but in the end the client is unable to read >anything and the director reports 'Fatal error: FD gave bad response >to JobId command: No data available.' > >Anybody familiar with the logic around openssl_bsock_session_start, >or have an idea of what might be going on? Is anybody besides me >using Solaris? Remember that Solaris has its own not the BSD >variant) socket API. > Okay several months later I've solved the problem best described as: 'connecting a Linux Bacula director to a Solaris Bacula file daemon and receiving the error: Error: openssl.c:86 Connect failure: ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number' The failure appears on Bacula 3.0.2 (as it did on 2.4.4 as well.) This fatal error went away after OpenSSL on the Solaris host was recompiled with multithreading support like this: $ ./config --prefix= --openssldir= threads $ make The Linux hosts don't fail with the above error even when OpenSSL multithreading isn't compiled, so the change is not needed there. This means that now 'TLS Enable', 'TLS Require', and 'TLS Verify Peer' are turned on everywhere and the backups are finally working. The page [1] describing Bacula requirements doesn't mention anything about TLS requiring a multithreaded OpenSSL on some platforms (or even that TLS requires OpenSSL at all.) I couldn't find the TeX source in 'git://[...]/docs/manuals/', so somebody else will have to correct the requirements (if they want to.) [1] http://www.bacula.org/en/dev-manual/System_Requirements.html Regards, Eduard -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Daemon listening on two subnets, requires TLS
Hello List, Although there's some information on 'Dealing_with_Firewalls.html' about this, it seems to not describe the solution to this problem. 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.) This seems to be a design problem in any daemon that can listen on multiple addresses. Because Kern just today said that he puts emphasis on design, I'm wondering what is wrong with this picture. The OSs involved are Solaris IA32 and Linux X86_64, while all Bacula versions are 3.0.2. Should I post a bacula-sd.conf? 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 -c second-sd.conf' fails silently and no new bacula-sd process is created. What is the proper way to go about listening on two subnets while presenting the proper certificate to incoming TLS connections? Regards, Eduard -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Daemon listening on two subnets, requires TLS
On mer., sept 30, 2009, Arno LEHMANN wrote:
>30.09.2009 13:38, baculal...@encambio.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.
>> 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 -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.
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..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.
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 = **
**TLS Certificate = **
**TLS Key = **
**TLS DH File = **
}
ipv4 = {
addr = privat.host.tld;
port = 9103;
}
}
Is there some policy or special procedure for making feature
requests?
Regards,
Eduard
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Daemon listening on two subnets, requires TLS
Hello Frank, On mer., sept 30, 2009, Frank SWEETSER wrote: > On 9/30/2009 7:38 AM, baculal...@encambio.com wrote: >> What is the proper way to go about listening on two subnets while >> presenting the proper certificate to incoming TLS connections? > > There are two general solutions. > > The first is to set up split DNS views, such that all clients use the > same hostname, and get directed to the correct IP address. > Yes, this was mentioned in 'Dealing_with_Firewalls.html'. Here's the error: 29-Sep 16:55 host-dir JobId 0: Fatal error: TLS negotiation failed with SD at "host.name.tld:9103" 29-Sep 16:55 host-dir JobId 0: Fatal error: bnet.c:307 TLS host certificate verification failed. Host name "host.name.tld" did not match presented certificate It seems to me that by changing the client's /etc/hosts for host.name.tld to a different address than what the storage daemon is listening on, two things happen. First, the above error would not appear. Second, the client would not be able to connect with the storage daemon, which is not listening on the address in the client's /etc/hosts. > The second option is to create a list of alternate subject names in the > certificate, so that all of the hostnames are considered valid for that > cert. > This could be it. As long as we make our own certificates, then putting multiple hostnames into the 'CN' field could solve the problem. I didn't try that, because I didn't know that it was possible to have more than one hostname in the 'CN' field. Regards, Eduard -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Daemon listening on two subnets, requires TLS
Hello Thomas,
An mer., sept 30, 2009, Thomas MUELLER schrieb:
>> this is IMHO an known problem to TLS/SSL certificates. on http servers
>> you can get around with setting the subjectAltName of the certificate to
>> the other dns names. Don't know if this works too for bacula and don't
>> know if this is a standard or just "best practice".
>>
As both you and Frank SWEETSER mentioned, this kind of problem is
often solved by using the 'subjectAltName' field of a X.509 cert:
commonName = canonical.host.tld
subjectAltName = DNS.1:alias1.host.tld,DNS.2:alias2.host.tld
>> clearly i would say this is not a task that needs to be fixed in bacula,
>
Well, you said it best yourself 'This is a known problem with Bacula
TLS certificate logic'. Clearly, we should fix problems if possible.
Using subjectAltName is not the solution, because most CAs refuse to
copy those credentials into certificates.
>ok, maybe bacula needs to support subjectAltName if the ssl lib doesn't
>do this "alone". :)
>
The good news is that there's no need to change Bacula. Either it
or OpenSSL 0.9.8k already recognizes that TLS connections are valid
according to the subjectAltName field (and CN as well of course.) I
just finished testing this myself by using a single X.509
certificate with one CN and one subjectAltName corresponding to
the two addresses specified in:
SDAddresses = {ipv4 = {addr = public.host.tld; port = 9103;}
ipv4 = {addr = privat.host.tld; port = 9103;}}
After restarting, Bacula sucessfully connected over TLS using either
storage daemon address.
Regards,
Eduard
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Daemon listening on two subnets, requires TLS
Hello Arno, On mer., sept 30, 2009, Arno LEHMANN wrote: >30.09.2009 15:07, baculal...@encambio.com wrote: >> On mer., sept 30, 2009, Arno LEHMANN wrote: >>> 30.09.2009 13:38, baculal...@encambio.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 [...] >>> >>> 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. > ...or the particular OS has an obscure defect (like all do) which appears only in certain combinations. That would be hard to test. >> I think setting a different SDPort might work, as I believe the >> storage daemon tries to write a pid file bacula-sd..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. > Yep, thanks. >>> I guess this might become a feature request... >>> >> That's my thought as well, so let's make a suggestion. >> >> Feature request: >> >> [...] >> >> 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. > Okay, I'll try that. Thanks for the advise. Regards, Eduard -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Locating a network connection failure
Hello list, Problem 1 (See director log below): Network error 'Connection reset by peer'. Solution 1 (as documented): Using the 'Heartbeat Interval' configuration parameter throughout the director, storage daemon, and file daemon config files. Problem 2: Setting keepalives (Heartbeat Interval) everywhere is not good. Exactly in which block of which config keepalives are needed is not easy to understand. Question 2: ...Please advise in which block of which config 'Heartbeat Interval is really required to solve the network failure. Thanks! My guess 2: I'm guessing that the director->filedaemon connection is breaking off, causing the network failure. If that's true, I assume that setting 'Heartbeat Interval' only in the 'Director' block of bacula-dir.conf will solve the problem. Can I really remove all mention of 'Heartbeat Interval' in the other configs, including the 'Storage' block of bacula-dir.conf? Unfortunately, I can't test my guess because of traffic limits. bacula-dir.log: 30-Sep 20:06 host1-sd JobId 8: Wrote label to prelabeled Volume "bacvol-01" on device "FileStorage" (/backups/bacula) 30-Sep 22:06 host1-dir JobId 8: Fatal error: Network error with FD during Backup: ERR=Connection reset by peer 30-Sep 22:06 host1-dir JobId 8: Fatal error: No Job status returned from FD. 30-Sep 22:06 host1-dir JobId 8: Error: Bacula host1-dir 3.0.2 (18Jul09): 30-Sep-2009 22:06:31 Build OS: x86_64-unknown-linux-gnu ubuntu 8.04 JobId: 8 Job:Host2.2009-09-30_20.06.14_03 Backup Level: Full (upgraded from Incremental) Client: "host2-fd" 3.0.2 (18Jul09) i386-pc-solaris2.11,solaris,5.11 FileSet:"ProductionSet" 2009-09-29 17:31:52 Pool: "LongtermPool" (From Job resource) Catalog:"MyCatalog" (From Client resource) Storage:"TunnelStore" (From Job resource) Scheduled time: 30-Sep-2009 20:06:12 Start time: 30-Sep-2009 20:06:24 End time: 30-Sep-2009 22:06:31 Elapsed time: 2 hours 7 secs Priority: 50 FD Files Written: 0 SD Files Written: 0 FD Bytes Written: 0 (0 B) SD Bytes Written: 0 (0 B) Rate: 0.0 KB/s Software Compression: None VSS:no Encryption: no Accurate: no Volume name(s): bacvol-01 Volume Session Id: 1 Volume Session Time:1254333910 Last Volume Bytes: 4,999,679,774 (4.999 GB) Non-fatal FD errors:0 SD Errors: 0 FD termination status: Error SD termination status: Running Termination:*** Backup Error *** Regards, Eduard -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
