Re: [Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-20 Thread Steve Garcia 


 Martin Simmons  wrote: 
> > On Thu, 19 Apr 2018 17:05:33 +, Steve Garcia said:
> > 
> >  Martin Simmons  wrote: 
> > > 
> > > 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?
> 
> No, it doesn't send the password from the config file.
> 
> The storage daemon generates a random session key, which is returned to the
> director.  The director passes this to the file daemon to allow it to
> authenticate with the storage daemon.
> 
> __Martin

OK, so it handles the authentication, just not using the original password.  
That makes a lot of sense.


--
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

Re: [Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-20 Thread Martin Simmons 
> On Thu, 19 Apr 2018 17:05:33 +, Steve Garcia said:
> 
>  Martin Simmons  wrote: 
> > 
> > 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?

No, it doesn't send the password from the config file.

The storage daemon generates a random session key, which is returned to the
director.  The director passes this to the file daemon to allow it to
authenticate with the storage daemon.

__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

Re: [Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-19 Thread Dmitri Maziuk 

On 4/19/2018 11:27 AM, Martin Simmons wrote:
... public ip for localhost ...


I've often wondered: is there a good reason for doing that in the hosts file?


Last I heard linux kernel was supposed to figure it out and route 
connections to self locally regardless of the ip. IOW no, and bacula is 
not the only program that can break when you do that.


ICBW, not linux's MMV, and all that.

Dima

--
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

Re: [Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-19 Thread Steve Garcia 

Steve Garcia
Ignorance killed the cat, curiosity was framed.

 Martin Simmons  wrote: 
> > On Tue, 17 Apr 2018 17:53:12 +, 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#SECTION0022

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

Re: [Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-19 Thread Martin Simmons 
> On Tue, 17 Apr 2018 17:53:12 +, 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?


> 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.

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.


> 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:

http://www.bacula.org/9.0.x-manuals/en/main/What_is_Bacula.html#SECTION0022

__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

Re: [Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-18 Thread Radosław Korzeniewski 
Hello,

2018-04-17 19:53 GMT+02:00 Steve Garcia :

>
> 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?


Yes, there is the reason. By default (when no SD calls client directive is
set) the File Daemon connect directly to the Storage Daemon to make backup
and restore operations. So your SD have to listen to external (other then
localhost) IP to make it work. When you define a localhost as a hostname
for your SD you will be able to make a local backups only.


>   Do the file daemons connect directly to the storage daemon,


Yes, and it is a default behavior.


> or are the mediated through the director?


The Director does not forward (*) any backup stream to the SD.

(*) - I think the new Client initiated backup changes it, but I'm not sure.


>   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.


To make a backup or restore job SD<->FD communication is authenticated with
an authorization key generated by Director. No password is required. So in
some sense the Director "mediate" the communication between FD and SD. :)


>   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.


You can use SD calls client directive to accomplish that.

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
--
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

[Bacula-users] Problem connecting to storage daemon [SOLVED]

2018-04-17 Thread Steve Garcia 
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