I am having trouble authenticating with a FD.
currently installed on the client are:
bacula-client-2.4.4-12.el5
bacula-common-2.4.4-12.el5
currently installed on the director/storage are:
bacula-director-common-5.0.0-12.el6.x86_64
bacula-storage-mysql-5.0.0-12.el6.x86_64
bacula-director-postgresql-5.0.0-12.el6.x86_64
bacula-storage-common-5.0.0-12.el6.x86_64
bacula-common-5.0.0-12.el6.x86_64
bacula-client-5.0.0-12.el6.x86_64
bacula-console-5.0.0-12.el6.x86_64
I ran the FD in debug mode and then checked status on the client from the console of the director.
I expected something like what I got when I ran the client status against a different FD:
do10-fd: job.c:233-0 <dird: Hello Director bacula-dir calling
do10-fd: job.c:249-0 Executing Hello command.
do10-fd: job.c:359-0 Calling Authenticate
do10-fd: cram-md5.c:73-0 send: auth cram-md5 <317997768.1426869192@do10-fd> ssl=0
do10-fd: cram-md5.c:133-0 cram-get received: auth cram-md5 <1117902222.1426869192@bacula-dir> ssl=0
do10-fd: cram-md5.c:152-0 sending resp to challenge: Dg/cE8+Lx40i71dz6FhcqC
do10-fd: job.c:363-0 OK Authenticate
I got:
asterisk1-fd: job.c:233-0 <dird: Hello Director bacula-dir calling
asterisk1-fd: job.c:249-0 Executing Hello command.
asterisk1-fd: job.c:359-0 Calling Authenticate
asterisk1-fd: job.c:252-0 Quit command loop. Canceled=0
It doesn't seem to be any of the usual suspects.
Networking is ruled out because the FD received the call from the director and attempted to authenticate
Concurrent jobs was not issue because I restarted the Director, FD, and SD and the problem persisted
I checked the password and name -very- carefully, and as indicated above, it quits before it ever sends an auth to the Director.
It seems like a dependency is somehow suddenly missing, as this configuration has worked up until a week ago. Any help resolving this would be appreciated.
--
Michael TweedSUSD Information Services
661 294 5353 (phone)
661 294 7520 (fax)
