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