>>>>> On Thu, 05 Oct 2006 16:28:59 -0400, Dan Langille said:
> Priority: normal
> Content-description: Mail message body
>
> On 5 Oct 2006 at 21:13, Martin Simmons wrote:
>
> > >>>>> On Thu, 05 Oct 2006 14:16:14 -0400, Dan Langille said:
> > > Priority: normal
> > > Content-description: Mail message body
> > >
> > > On 5 Oct 2006 at 19:10, Martin Simmons wrote:
> > >
> > > > >>>>> On Thu, 05 Oct 2006 12:52:44 -0400, Dan Langille said:
> > > > > Priority: normal
> > > > > Content-description: Mail message body
> > > > >
> > > > > On 5 Oct 2006 at 17:27, James Ray wrote:
> > > > >
> > > > > > Dan Langille wrote:
> > > > > > > On 5 Oct 2006 at 16:42, James Ray wrote:
> > > > > > >
> > > > > > >> Dan Langille wrote:
> > > > > > >>> On 5 Oct 2006 at 16:29, James Ray wrote:
> > > > > > >>>
> > > > > > >>>> Dan Langille wrote:
> > > > > > >>>>> On 5 Oct 2006 at 15:36, James Ray wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Dan Langille wrote:
> > > > > > >>>>>>> On 5 Oct 2006 at 9:11, Bill Moran wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>>> I haven't had time to investigate whether the
> > > > > > >>>>>>>> [FD|SD|DIR]Address sets
> > > > > > >>>>>>>> both the listening and the outgoing address, but a
> > > > > > >>>>>>>> firewall audit is
> > > > > > >>>>>>>> on the TODO list, and when I finally get to it, I'll have
> > > > > > >>>>>>>> to address
> > > > > > >>>>>>>> this for a number of services, not only Bacula.
> > > > > > >>>>>>> My testing today shows that is sets both listening and
> > > > > > >>>>>>> outgoing. All
> > > > > > >>>>>>> I tested was a status command. Nothing more.
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>> Well, that doesn't seem to be the case on my linux (FC5)
> > > > > > >>>>>> machine. :(
> > > > > > >>>>>>
> > > > > > >>>>>> The LISTEN addresses are right but the address the
> > > > > > >>>>>> communications spawn
> > > > > > >>>>>> from is the base system address.
> > > > > > >>>>>>
> > > > > > >>>>>> tcp 0 0 xxx.xxx.x.49:9101 0.0.0.0:*
> > > > > > >>>>>> LISTEN 100 9291 3056/bacula-dir
> > > > > > >>>>>> tcp 0 0 xxx.xxx.x.49:9103 0.0.0.0:*
> > > > > > >>>>>> LISTEN 0 9239 3011/bacula-sd
> > > > > > >>>>>>
> > > > > > >>>>>> Then run a status client command with the following ngrep
> > > > > > >>>>>> running (I
> > > > > > >>>>>> shouldn't see any data)
> > > > > > >>>>>>
> > > > > > >>>>>> [EMAIL PROTECTED] bacula]# ngrep "" "src host xxx.xxx.x.48
> > > > > > >>>>>> and dst host
> > > > > > >>>>>> xxx.xxx.x.3"
> > > > > > >>>>>> interface: eth0 (xxx.xxx.x.0/255.255.254.0)
> > > > > > >>>>>> filter: (ip) and ( src host xxx.xxx.x.48 and dst host
> > > > > > >>>>>> xxx.xxx.x.3 )
> > > > > > >>>>>> 114 received, 0 dropped
> > > > > > >>>>>>
> > > > > > >>>>>> And I see the following in netstat:
> > > > > > >>>>>>
> > > > > > >>>>>> tcp 0 0 xxx.xxx.x.48:53286
> > > > > > >>>>>> xxx.xxx.x.3:9102
> > > > > > >>>>>> TIME_WAIT 0 0 -
> > > > > > >>>>>>
> > > > > > >>>>>> :(
> > > > > > >>>>> Without the corrresponding configuration file, I cannot
> > > > > > >>>>> comment.
> > > > > > >>>>>
> > > > > > >>>> Director{} resource from bacula-dir.conf
> > > > > > >>>> Director { # define myself
> > > > > > >>>> Name = bacula-dir
> > > > > > >>>> DIRport = 9101 # where we listen for UA
> > > > > > >>>> connections
> > > > > > >>>> QueryFile = "/etc/bacula/query.sql"
> > > > > > >>>> WorkingDirectory = "/var/bacula/working"
> > > > > > >>>> PidDirectory = "/var/bacula/run"
> > > > > > >>>> Maximum Concurrent Jobs = 8
> > > > > > >>>> Password = <REMOVED> # Console password
> > > > > > >>>> Messages = Daemon
> > > > > > >>>> DirAddress = xxx.xxx.x.49
> > > > > > >>>> }
> > > > > > >>> This tells the FD that only the given DIR may connect. This
> > > > > > >>> does not
> > > > > > >>> tell the FD where it should listen. To tell the FD how to
> > > > > > >>> listen,
> > > > > > >>> here is what I did:
> > > > > > >>>
> > > > > > >>> FileDaemon {
> > > > > > >>> Name = ngaio-fd
> > > > > > >>> FDport = 9102
> > > > > > >>> WorkingDirectory = /home/bacula/db
> > > > > > >>> Pid Directory = /var/run
> > > > > > >>> Maximum Concurrent Jobs = 20
> > > > > > >>>
> > > > > > >>> FDAddress = 192.168.0.68;
> > > > > > >>> }
> > > > > > >>>
> > > > > > >>> This is an extract from the bacula-fd.conf file.
> > > > > > >>>
> > > > > > >>> The FDAddress directive tells the FD to listen (and answer)
> > > > > > >>> only on
> > > > > > >>> that given address.
> > > > > > >>>
> > > > > > >>> I think you know what to do now... ;)
> > > > > > >>>
> > > > > > >> I think you are confused....
> > > > > > >> The FD is listening on another machine on the correct IP
> > > > > > >> address, its
> > > > > > >> the Director that is talking out of the the 'wrong' (for want of
> > > > > > >> a
> > > > > > >> better name) IP address.
> > > > > > >>
> > > > > > >> The server where the director is running has two interfaces (one
> > > > > > >> phyiscal one virtual), of .48 and .49, I want it to talk out of
> > > > > > >> the .49
> > > > > > >> IP addresses, however it sends out communications from the .48
> > > > > > >> IP address.
> > > > > > >>
> > > > > > >> Does that clear it up? (confusing I know!)
> > > > > > >
> > > > > > > I just tested this with the latest BETA code (for bacula-dir;
> > > > > > > bconsole was 1.38.11, but I do not think that will affect these
> > > > > > > results).
> > > > > > >
> > > > > > > The bacula-dir config:
> > > > > > >
> > > > > > > Director { # define myself
> > > > > > > Name = ngaio-dir
> > > > > > > DIRport = 9101 # where we listen for UA
> > > > > > > connections
> > > > > > > QueryFile = "/usr/local/share/bacula/query.sql"
> > > > > > > WorkingDirectory = "/home/bacula/db"
> > > > > > > PidDirectory = "/var/run"
> > > > > > > Maximum Concurrent Jobs = 3
> > > > > > > Password = "****" # Console password
> > > > > > > Messages = Daemon
> > > > > > >
> > > > > > > DirAddress = 192.168.0.68
> > > > > > > }
> > > > > > >
> > > > > > > The bconsole.conf:
> > > > > > >
> > > > > > > Director {
> > > > > > > Name = ngaio-dir
> > > > > > > DIRport = 9101
> > > > > > > Address = 192.168.0.68
> > > > > > > # address = ngaio
> > > > > > > Password = "***"
> > > > > > > }
> > > > > > >
> > > > > > > Connecting thusly:
> > > > > > >
> > > > > > > $ bconsole -c ~/bconsole.conf
> > > > > > > Connecting to Director 192.168.0.68:9101
> > > > > > > 1000 OK: ngaio-dir Version: 1.39.24 (02 October 2006)
> > > > > > > Enter a period to cancel a command.
> > > > > > > *
> > > > > > >
> > > > > > > All comms went via 192.168.0.68
> > > > > > >
> > > > > > > Monitored like this:
> > > > > > >
> > > > > > > sudo tcpdump -ni fxp0 port 9101 | grep -v 10.55.0.68
> > > > > > >
> > > > > > > Any questions? I'll answer.
> > > > > > >
> > > > > > > I used the beta because it was already installed on this machine.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Make an outgoing command to a client and see what IP address that
> > > > > > comes
> > > > > > from... something like a status client=blah should work.
> > > > > >
> > > > > > The Outgoing IP address will be your system default address.
> > > > >
> > > > > Done. Nothing caught by the above (and repeated below) filter. I
> > > > > also tried running a job. Nothing out on the the primary IP address.
> > > > > The filter is:
> > > > >
> > > > > tcpdump -ni fxp0 port 9101 | grep -v 10.55.0.68
> > > > >
> > > > > The ifconfig is:
> > > > >
> > > > > $ ifconfig fxp0
> > > > > fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
> > > > > 1500
> > > > > options=8<VLAN_MTU>
> > > > > inet6 fe80::204:acff:fea3:703d%fxp0 prefixlen 64 scopeid 0x1
> > > > > inet 10.55.0.67 netmask 0xffffff00 broadcast 10.55.0.255
> > > > > inet 10.55.0.68 netmask 0xffffffff broadcast 10.55.0.68
> > > > > ether 00:04:ac:a3:70:3d
> > > > > media: Ethernet autoselect (100baseTX <full-duplex>)
> > > > > status: active
> > > >
> > > > From your results, it looks to me like the Director didn't bind the
> > > > source IP address when connecting to the client. Right?
> > >
> > > I do not understand what you are saying. :)
> >
> > I thought you were an expert by using tcpdump :-)
>
> ;)
>
> >
> > Assuming that 10.55.0.68 and 192.168.0.68 are somehow related, your primary
> > IP
>
> Yes, sorry, my error. They should be the same address.
>
> > address is 10.55.0.67 and your alias is 10.55.0.68.
>
> Correct.
>
> > You said "Nothing caught by the above" when looking for 10.55.0.68 in
> > the tcpdump.
>
> The dump is: tcpdump -ni fxp0 port 9101 | grep -v 10.55.0.68
>
> Which means, show me everything on device fxp0 for port 9101. Then
> the grep ignores everything to/from 10.55.0.68. The only stuff that
> should be displayed will be traffic not to or from 10.55.0.68, which
> leaves the primary. So any possible output must be port 9101 on the
> primary IP address.
>
> I think the confusion is my choice of words: "nothing caught"...
>
> > so I assume that the traffic is on the primary IP address instead
> > (though for the client test you need to change the port number in
> > tcpdump of course). You could probably check this with something like
> >
> > tcpdump -ni fxp0 port 9102 | grep -v 10.55.0.67
>
> That would show only traffic not from the primary.
Doh, right, I missed (and copied!) the -v option.
In that case, I don't understand it because I don't see any code in Bacula to
bind the local address before calling connect(2).
While the director is connected to the client, if you run netstat -n (on both
machines) does it confirm that the connection comes from 10.55.0.68? And this
changes if you change the Director's config to listen only on 10.55.0.67?
__Martin
-------------------------------------------------------------------------
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
