Solved :)
I found the problem. It was my tcp wrapper rules -- as earlier I didn't
realize the storage daemon communicated directly with the file daemon. (As
I thought all traffic went though director.) A reply on this thread
clarified this for me. (Thanks!) But I didn't fix my /etc/hosts.allow
accordingly.
Since my debugging kept leading me to cram_md5 I thought the problem was
with authentication not with networking connection.
How I found out:
I upgraded the main server and the second computer to bacula-1.39.28.
I added various Dmsg debugging.
My authentication works fine on the "file daemon" to the directory. But
fails here:
a1-fd: bnet.c:1141 who=Storage daemon host=server port=9103
a1-fd: authenticate.c:207 Authenticating storage daemon
a1-fd: cram-md5.c:110 returning false
a1-fd: authenticate.c:212 cram_respond failed for Storage daemon
(The middle, 2 and 3 lines, above are some of my extra debugging.)
The code is in the cram_md5_respond in src/lib/cram-md5.c (note below adds
one of my debugging lines):
if (bnet_recv(bs) <= 0) {
Dmsg0(50, "returning false\n");
bmicrosleep(5, 0);
return false;
}
I also added debugging to the storage side but it never saw my "file
daemon".
So no data was even received. That gave me my clue.
Once I have commit access, I will add some more good debugging to clearly
show this. (Since I saw at least one other posting from last March that
may have been same problem.)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
