inline response continued:
> On 20. Jul 2022, at 01:38, Bill Arlofski via Bacula-users
> <[email protected]> wrote:
>
> On 7/19/22 16:55, Justin Case wrote:
>> Error: getmsg.c:217 Malformed message: [bsockcore.c:265 Unable to connect to
>> Director daemon on bacula-dir.lan.net:9101. ERR=Connection refused
>
>
> Hello Justin,
>
> My guess is that the FD is configured to call the Director, and it tries, but
> fails either due to a firewall blocking it, or,
The firewall is _not_ blocking the FD connecting to the director. However, the
firewall is blocking the Director from connecting to the FD.
> more likely, the Director has not been configured to allow this Client to
> connect to the Director.
>
> Then, when you run the job, the Director simply calls the client as normal.
>
> In the Client{} resource on the Director for this Client, you need:
> ----8<----
> AllowFDConnections = yes
> ----8<----
Excuse me, I forgot to show the config of the client in the director (and yes,
I allow FD connections):
Client {
Name = "myfd"
Address = “myfd-fqdn"
FdPort = 9102
Password = “redacted
Catalog = "MyCatalog"
FileRetention = 5184000
JobRetention = 15552000
AutoPrune = yes
SDCallsClient = no
AllowFDConnections = yes
MaximumConcurrentJobs = 2
}
Job {
Name = “job1"
Client = "myfd"
JobDefs = "tier1"
Enabled = yes
AllowIncompleteJobs = no
AllowDuplicateJobs = no
}
Job {
Name = “job2"
Client = “mfdy"
JobDefs = "tier2"
Enabled = yes
AllowIncompleteJobs = no
AllowDuplicateJobs = no
}
JobDefs {
Name = "tier1"
Type = "Backup"
Level = "Full"
Messages = "Standard"
Storage = "tier1-storage"
Pool = "full-tier1"
FullBackupPool = "full-tier1"
IncrementalBackupPool = "incr-tier1"
Fileset = "various"
Schedule = “sched1"
}
JobDefs {
Name = "tier2"
Type = "Backup"
Level = "Full"
Messages = "Standard"
Storage = "tier2-storage"
Pool = "full-tier2"
FullBackupPool = "full-tier2"
IncrementalBackupPool = "incr-tier2"
Fileset = "various"
Schedule = "sched2"
}
> See, if makes no sense to me that if the Client is not connected, or cannot
> connect that the Director can (or would) call out
> to it to start a job with "AllowFDConnections = yes" set for this client.
> The connection should be already established By the Client -> to the Director
> and there would be no connection refused
> messages generated by the client - w
> hich is why I asked about the JobId 0 possibility for these log entries.
Sure. The FD can always connect.
> BTW, I just tested this on a client that is local to the Director (ie: no
> firewalls between the two) and it works as
> expected. No errors.
>
> If I run the Director in foreground and debug mode, I can see after a few
> seconds of it starting up, an incoming connection
> from the Client I configured, and then the authentication and finally the
> inbound connection allowed:
> ----8<----
> [...snip a lot of Director startup stuff...]
> bacula-dir: authenticate.c:267-0 authenticate user agent: Hello speedy-fd
> fdcallsdir 1 tlspsk=100
> bacula-dir: authenticate.c:286-0 *** No Dir compression to UA
> bacula-dir: authenticatebase.cc:335-0 TLSPSK Local need 100
> bacula-dir: authenticatebase.cc:365-0 TLSPSK Remote need 100
> bacula-dir: authenticatebase.cc:563-0 TLSPSK Start PSK
> bacula-dir: authenticatebase.cc:365-0 TLSPSK Remote need 100
> bacula-dir: authenticatebase.cc:563-0 TLSPSK Start PSK
> bacula-dir: bnet.c:96-0 TLS serve
> r negotiation established.
> bacula-dir: bnet.c:155-0 TLS client negotiation established.
> bacula-dir: cram-md5.c:68-0 send: auth cram-md5 challenge
> <695684628.1658273108@bacula-dir> ssl=0
> bacula-dir: cram-md5.c:132-0 cram-get received: auth cram-md5
> <1878454514.1658273108@speedy-fd> ssl=0
> bacula-dir: cram-md5.c:132-0 cram-get received: auth cram-md5
> <40069706.1658273108@speedy-fd> ssl=0
> bacula-dir: cram-md5.c:156-0 sending resp to challenge: hG/bnB+/sA+oS8RQ+S+nEA
> bacula-dir: cram-md5.c:156-0 sending resp to challenge: 9+BJT+cVo5tAb6/dZ/+9nB
> bacula-dir: cram-md5.c:75-0 send: auth cram-md5 challenge
> <472182750.1658273108@bacula-dir> ssl=0
> bacula-dir: authenticate.c:368-0 FDCallsDir OK for speedy-fd
> ----8<----
>
> The first line shows the client connecting inbound to the Director and that
> 'fdcallsdir = 1' for this client called
> 'speedy-fd' which allows the inbound attempt and authentication processes,
> then the last line shows the connection has been
> allowed and is OK.
>
>
> Hope
> this helps,
> Bill
>
> --
> Bill Arlofski
> [email protected]
> _______________________________________________
> Bacula-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
