Josh Fisher wrote:
> 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.
>
I don't really see this as a 'routing' decision though. Lets take
proftpd as an example here.
Now I connect to proftpd that is running on a system with virtual
interfaces, proftpd's listening port is bound to one interface which is
a virtual one...
Now I have passive mode turned on and I do an 'ls' command, at which
point the FTP server opens a connection to my client _from the virtual
interfaces IP address_.
This just wouldn't work at all if I go a connection coming from the
machines physical 'default' IP address.
All I want is for when I connect to a client from the director that it
uses a defined IP address rather than me Source NATing or doing other
evil routing things.
I don't want to always talk to these machines from the virtual interface
either so the routing tricks aren't really feasible. I want all my
normal communications (sshing outwards, blah blah blah) to come from the
'default' IP address, but I want bacula to come from its service IP
address which isn't the default one.
--
James Ray. <[EMAIL PROTECTED]>
Computing Services
Queen Mary, University of London
-------------------------------------------------------------------------
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
