Re: [PATCH] nfs-utils: Support binding to source address.

[Ben Greear <greearb@candelatech.com>]

On 06/08/2011 02:16 PM, Chuck Lever wrote:
>
> On Jun 8, 2011, at 4:54 PM, Ben Greear wrote:
>
>> On 06/08/2011 01:41 PM, Chuck Lever wrote:

>>> But why is this structure needed?  Why can't you pass a bind address via a struct sockaddr * just as bind(2) does?
>>
>> Someone might one day want to bind to an interface with SO_BINDTODEVICE, so I thought
>> it would be nice to pass a container around so that it would be easy to add a dev-name
>> argument without touching all of the method signatures again.
>
> My preference would be to go with something simple for now.  If we ever need more, it's easy to change.  These are not a published formal API.
>
> Are you thinking of allowing users to specify either an IP address or a hostname as a value for this new option?

I was thinking "eth5", for use with SO_BINDTODEVICE.

But, host-names might also be useful.

It's not that difficult to change the method signatures again, but it sure makes
the patch much bigger than it would otherwise need to be...

>>> When you specify a source address for mountd and statd, wouldn't they need to register that address with rpcbind? That won't work for non-TI-RPC builds, and neither would it work for the kernel, which, according to Trond, will never support listening on specific addresses (he NACKed a patch to the kernel's rpcbind client to support this). Are you sure you need server-side changes too?
>>
>> Much of the changes are just required to make things compile with the changes to the
>> core socket building methods.  I don't notice any changes to mountd or statd in
>> the patch I posted.  What sections are you speaking of?
>>
>>> You can't pass a bind address to the mount command using a command line option, since command line options aren't stored in /etc/fstab or /etc/mtab.  How would umount.nfs learn of the bind address if it can't find it in /etc/mtab?
>>>
>>> It should not read from an environment variable either... how would that work during system boot?  How would such a variable be set during system shutdown?  If we were to do this, it really should use a new mount option.
>>
>> Ok, I've implemented it with a mount-option for my testing.  I'll remove the
>> cmd-line-arg and environ variable logic.
>
> I have to admit that parse_local_bind() doesn't make sense to me.  For example, I don't think there is any need for bind addresses to use the square bracket convention that is used for server addresses; that is there for the NFS special device simply because a colon is already the separator between the server IP address and the export path.  We don't have that problem for a bind address, since it always stands by itself.
>
> I also imagine that the source address will need to be passed to the kernel via mount(2), yes?  That can only be done via a string mount option.  Anyway, point made.

I thought it might be nice to carry on the [] convention of v6 addresses, but it could
be optional.  I'll work on that as well.

>
> And such a mount option would need to be documented in nfs(5) (see utils/mount/nfs.man), and changes included with your patches.

I'm using "srcaddr=foo" currently.  I can update the man page if that option name looks like a good
choice to you (it is used by cifs currently for the same purpose).


Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com