Steve Garcia Ignorance killed the cat, curiosity was framed. ---- Martin Simmons <mar...@lispworks.com> wrote: > >>>>> On Tue, 17 Apr 2018 17:53:12 +0000, Steve Garcia said: > > > > 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. > > I've often wondered: is there a good reason for doing that in the hosts file?
It allows you to use the hostname for a service that is local only. Having a local-only service is more secure than one that listens on all interfaces. This is no advantage if it needs to listen on all interfaces, of course. > > > > 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 that comment in the bacula-dir.conf? That controls how to connect to the > storage daemon, not what it listens on. True. But coupled to the config setting in bacula-sd.conf, it meant that I was connecting to an interface that wasn't listening. > > You can control which addresses the storage daemon listens on using the > SDAddress or SDAddresses options in the bacula-sd.conf. Without either option > (the default), it listens on the wildcard address (i.e. all addresses), but > Debian might have changed that. Apparently so. Or at least the config file I was working with did have an IP address specified, and it was probably because there was one in the sample config from Debian. I first set that config up more than a decade ago, on another machine, so it's entirely possible that I introduced that in there for some reason, but if so it's completely faded out of my memory. :-) > > > > 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? > > Yes. > > The director sends the address (in bacula-dir.conf) of the storage daemon to > the client, which then makes its own connection to the storage daemon. There > is a picture here: And that's the crux of the question. I was under the impression that there was no direct connection. I based that solely on the lack of a shared password between the file daemon and the storage daemon. Does the director pass the authentication to the file daemon as well? > http://www.bacula.org/9.0.x-manuals/en/main/What_is_Bacula.html#SECTION00220000000000000000 Thanks, this is helpful. > > __Martin ------------------------------------------------------------------------------ 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
