(sorry saw I wasn’t replying to the entire list)
Ok the problem remains,
A client that’s connected using client initiated connection is still dropping
off when I try to query it
08-Oct-19 10:16 54 1 mills-feldman-fd
====
You have messages.
*status client=mills-feldman-fd
Connecting to Client mills-feldman-fd at <snip>
Handshake: Immediate TLS, Encryption: PSK-AES256-CBC-SHA
*
As you can see when I do status on it it just drops right away doesn’t hang,
and doesn’t provide the usual expected feedback and now the client will be
missing from the connection.
Should I try lowering the heartbeat?
Client {
Name = mills-feldman-fd
FDport = 9102
Address = <snip>
Catalog = myth_catalog
Password = “<snip>"
File Retention = 3 months
Job Retention = 6 months
AutoPrune = yes
Connection From Client To Director = yes
Connection From Director To Client = no
Heartbeat Interval = 60
}
> On Oct 5, 2019, at 12:07 PM, Brock Palen <[email protected]> wrote:
>
>
>> On Oct 4, 2019, at 6:47 AM, Jörg Steffens <[email protected]> wrote:
>>
>> On 03.10.19 at 16:15 wrote Brock Palen:
>>> I am running into issues where roaming clients using client initiated
>>> connections are un-reliable. They worked very well for a number of months
>>> but now I find that clients that we know are online, and the director
>>> reports as connected something as simple as
>>>
>>> status client=<client>
>>>
>>> Will just drop the connection,
>>
>> So, will (1) the status command get executed, you receive an answer and
>> the connection is lost after this, or will (2) the connection close
>> immediately?
>
> Drops immediately,
>
> it prints:
>
> *status client=sch-hp-desktop-fd
> Connecting to Client sch-hp-desktop-fd at 192.168.67.99:9102
> Handshake: Immediate TLS, Encryption: PSK-AES256-CBC-SHA
>
> and then nothing, if I kill the console, the client is not listed in client
> initiated connections, but will eventually come back.
>
>>
>>> eventually the client comes back, but it causes a lot of backup failures
>>> and unreliable reporting.
>>>
>>> All clients are windows 10.
>>>
>>> Has anyone started seeing this? Should we try tuning some timeouts? Right
>>> now they are defaults.
>>
>> On 1:
>> Well, it works a designed.
>> A connection is only used for one task/job.
>
> Yep most the time it works.
>
>>
>> On Client Initiated Connection the FD opens up a connection to the
>> Director. When the Director uses this connection, either by running a
>> job or running a status command, the FD opens up another connection, so
>> the Director has a spare one available.
>> The connection used by the Director will be closed after the task/job.
>>
>> On 2:
>> Yes, you should set Heartbeat Interval like described in the documentation:
>>
>> https://docs.bareos.org/TasksAndConcepts/NetworkSetup.html#client-initiated-connection
>
> Yeah thought I did, and like I noted it worked very well for a long time, and
> now it’s spotty. One client is working much more than the other, and two
> others are 100% reliable but connect over a VPN rather than public WAN
>
> I was just going to paste in the client config, but I noticed for both of
> them I had left the LanAddress populated
>
> Client {
> Name = sch-hp-desktop-fd
> FDport = 9102
> Address = <snip>
> LanAddress = 192.168.1.110
> Maximum Concurrent Jobs = 1
> Catalog = myth_catalog
> Password = “<snip>"
> File Retention = 3 months
> Job Retention = 6 months
> AutoPrune = yes
> Connection From Client To Director = yes
> Connection From Director To Client = no
> Heartbeat Interval = 60
> }
>
> Becuse doign a full over the network is bad so we have our own snowball
> running on a Raspbery Pi we mail to their house to do a full backup, then
> override the pool, mail it back, migrate job and then Always Incremental
> after that. So that is a difference from the two that work 100%.
>
> I removed that will see what happens.
>
>>
>> Regards,
>> Jörg
>>
>> --
>> Jörg Steffens [email protected]
>> Bareos GmbH & Co. KG Phone: +49 221 630693-91
>> http://www.bareos.com Fax: +49 221 630693-10
>>
>> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
>> Komplementär: Bareos Verwaltungs-GmbH
>> Geschäftsführer:
>> S. Dühr, M. Außendorf, Jörg Steffens, P. Storz
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "bareos-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/bareos-users/qn77vf%24871e%241%40blaine.gmane.org.
>
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/bareos-users/43F94FC9-8C14-4ED1-8AA0-3E6526802011%40mlds-networks.com.
