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