[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] bacula feature request: better client firewall and timeout handling


Hello,

Unless I am missing something, this is not a Feature Request that would be 
accepted for the following reasons:

1. Part A can be tested by a script as you mentioned, but more importantly, 
the feature you request already exists. You just need to set the timeout 
value to your convenience.

2. Part B. Bacula is notified by the OS when the line is dropped, and thus it 
is not something that Bacula can speed up.  You can modify your OS (I don't 
recommend doing so) so that it will inform Bacula faster.

Best regards,

Kern



On Tuesday 29 January 2008 18.58:23 Bob Hetzel wrote:
> Item  45?:  Improve how bacula handles tcpip connections when they drop
> (or are just not answered) unexpectedly both at the beginning and in the
> middle of a backup.
>    Date:   January 29, 2008
>    Origin: Bob Hetzel beh@xxxxxxxx
>    Status: New
>
>    What:   Part A: Currently, when a bacula client has a firewall on it
> that isn't set up properly to allow the server to connect in (or is just
> down), it takes bacula a long time to figure that out.  Part B: When a
> client goes away in the middle of a backup (i.e. shut down or just taken
> off the network due to being a laptop on the move) bacula takes a long
> time to figure that out and terminate the backup.
>
>    Why:    Workarounds have been suggested such as creating a "before
> job" that pings the client.  That is only a partial resolution to
> part A and is no resolution to part B, because it tests general
> connectivity to the client without specific bacula connectivity
> (i.e. response to a ping is not the same as response to a connection
> on port 9102).  In addition, that doesn't resolve the problems created
> when backing up a laptop or other computer that gets shut off or moved
> in the middle of a backup.  Also, many IT shops have created policies to
> turn off ping responses due security situations they can create, for
> instance under Microsoft Windows.
>
>    Notes:  It seems rather obvious to me that implementing part A is
> substantially easier than part B, but both seem rather related and could
> share code.  Part A would be really nice even without part B. though.
> This would also allow the code to give a better message to the server
> which currently just suggests a password problem or bacula not running.
>   Having a way to check if the director connected at all to the bacula
> client would allow for a more specific error message.  I also understand
> that this might require a change in the FD code--thus making older
> clients incompatible with the newer bacula server daemons, so perhaps a
> way to turn it on or off would be helpful too.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.