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.
--
Dan Langille : Software Developer looking for work
my resume: http://www.freebsddiary.org/dan_langille.php
-------------------------------------------------------------------------
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
