Dan Langille wrote:
> On 6 Oct 2006 at 11:49, Martin Simmons wrote:
>
>
>>>>>>> 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).
>>
>>
That is not a common thing for a client to do. It makes more sense to
leave routing decisions up to the kernel. Normally, a client allows the
kernel to select both interface and port for the client socket. Some
clients allow binding to a particular port when needed for firewall
reasons. For example, named can be configured to bind its client socket
to port 53 when making client connections to a remote DNS server, but it
still doesn't bind to a particular interface as that would restrict routing.
I think this would have to be a feature request and a decision would
have to be made whether or not to implement it.
>> 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?
>>
>
> Director connected to the client in what way? The following were
> taken while a job was running.
>
> On the FD:
>
> # netstat -n | grep 910
> tcp4 0 2497 10.55.0.23.3816 10.55.0.67.9103
> ESTABLISHED
>
> Connection from the local FD to the remote SD
>
> tcp4 0 0 10.55.0.23.9102 10.55.0.67.52459
> ESTABLISHED
>
> Connection to the local FD, but I don't know what from.
>
> tcp4 0 0 10.55.0.23.2831 10.55.0.68.9101
> ESTABLISHED
>
> Connection from local bconsole to Director
>
>
> And on the Director
>
> # netstat -n | grep 910
> tcp4 66182 0 10.55.0.67.9103 10.55.0.23.3816
> ESTABLISHED
> tcp4 0 0 10.55.0.67.52459 10.55.0.23.9102
> ESTABLISHED
> tcp4 0 0 10.55.0.67.9103 10.55.0.67.56424
> ESTABLISHED
> tcp4 0 300 10.55.0.67.56424 10.55.0.67.9103
> ESTABLISHED
> tcp4 0 0 10.55.0.68.9101 10.55.0.23.2831
> ESTABLISHED
>
>
>
> The problem with my tcpdump is it looks only for traffic on 9101,
> which would be incoming connections to the DIR. I was not looking
> for outgoing connections from the DIR.
>
>
> Yes, the DIR is initiating outgoing connections on an IP address not
> specified in the Director resource of the bacula-dir.conf
> configuration file.
>
>
Which is normal behavior. The port and address(es) that the server
listens on has nothing to do with the port and address a client socket
is bound to when making a client connection to a server. Those are
normally assigned by kernel routing. As James Harper mentioned
previously, the routing table is where this sort of routing assignment
should be made. His post shows clearly how to assign a preferred source
address to a particular route.
-------------------------------------------------------------------------
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
