OK, in the process of writing out the details of my connection problem for this list, I solved my problem, but I thought I'd document it here.
The problem was that all of a sudden my backups started failing with a Warning: bsock.c:107 Could not connect to Storage daemon on odin.cs.csubak.edu:9103. ERR=Connection refused After going through everything I could think of (passwords match, is the daemon running, etc.) I thought of everything else on the system I've changed recently. It turns out that in the process of setting up a monitoring daemon on that server, I had modified the hosts file to assign the normal hostname to localhost. This is not an uncommon setting, but it seems to break bacula. It means that when you try to connect to port 9103 on hostname, the connection is now going to go to 127.0.0.1. And it seems that the storage daemon isn't listening on the localhost interface. This is a configuration directive, but the comments in the default config file, on Debian at least, say "Do not use localhost here." So I didn't. Is there any reason why this should not be localhost? Do the file daemons connect directly to the storage daemon, or are the mediated through the director? I was under the impression that since the only passwords the file daemons have is that of the director that there would be no direct connection to storage. From a security standpoint, I could see advantages for keeping the storage daemon limited to localhost, but obviously not if it needs direct access to file daemons. So does it? Steve Garcia Ignorance killed the cat, curiosity was framed. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
