rpcbind -h

rpcbind -h

[Jim Rees]

Is there some good reason why the rpcbind '-h' option (bind to given
address) applies only to the udp listening socket and not to the tcp socket?

And is there any good reason why an nfs3 client not providing any services
would need to run rpcbind?

Re: rpcbind -h

[Trond Myklebust]

On Sun, 2011-11-06 at 10:58 -0500, Jim Rees wrote: 
> Is there some good reason why the rpcbind '-h' option (bind to given
> address) applies only to the udp listening socket and not to the tcp socket?
> 
> And is there any good reason why an nfs3 client not providing any services
> would need to run rpcbind?

Yes: lockd and statd...

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: rpcbind -h

[Jim Rees]

Trond Myklebust wrote:

  On Sun, 2011-11-06 at 10:58 -0500, Jim Rees wrote: 
  > Is there some good reason why the rpcbind '-h' option (bind to given
  > address) applies only to the udp listening socket and not to the tcp socket?
  > 
  > And is there any good reason why an nfs3 client not providing any services
  > would need to run rpcbind?
  
  Yes: lockd and statd...

Oh yeah, I forgot about those v3 relics.  How about if all my mounts are
nolock?  And what about the '-h' option?  It almost looks like a mistake,
but it's documented to work that way.

Re: rpcbind -h

[Chuck Lever]

On Nov 6, 2011, at 10:58 AM, Jim Rees wrote:

> Is there some good reason why the rpcbind '-h' option (bind to given
> address) applies only to the udp listening socket and not to the tcp socket?

Yes.  See the mail archives.  I believe we've discussed this thoroughly within the past six months to a year.  If there's any bug here, it's that "-h" is not well documented.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: rpcbind -h

[Jim Rees]

Chuck Lever wrote:

  On Nov 6, 2011, at 10:58 AM, Jim Rees wrote:
  
  > Is there some good reason why the rpcbind '-h' option (bind to given
  > address) applies only to the udp listening socket and not to the tcp socket?
  
  Yes.  See the mail archives.  I believe we've discussed this thoroughly
  within the past six months to a year.  If there's any bug here, it's that
  "-h" is not well documented.

It's documented well enough but I'm still in the dark about the reason.  I
don't recall the discussion and can't find it in the archives.  The search
box on spinics isn't working for me, it returns results from the entire web,
not just the list archive.

As I said before, I was hoping for the equivalent of "portmap -l".  I was
ready to code up a patch of some kind but now have a workaround (mount with
nolock and don't run rpcbind at all).

Re: rpcbind -h

[Chuck Lever]

On Nov 7, 2011, at 12:21 PM, Jim Rees wrote:

> Chuck Lever wrote:
> 
>  On Nov 6, 2011, at 10:58 AM, Jim Rees wrote:
> 
>> Is there some good reason why the rpcbind '-h' option (bind to given
>> address) applies only to the udp listening socket and not to the tcp socket?
> 
>  Yes.  See the mail archives.  I believe we've discussed this thoroughly
>  within the past six months to a year.  If there's any bug here, it's that
>  "-h" is not well documented.
> 
> It's documented well enough but I'm still in the dark about the reason.  I
> don't recall the discussion and can't find it in the archives.  The search
> box on spinics isn't working for me, it returns results from the entire web,
> not just the list archive.
> 
> As I said before, I was hoping for the equivalent of "portmap -l".  I was
> ready to code up a patch of some kind but now have a workaround (mount with
> nolock and don't run rpcbind at all).

I wouldn't object to having a "local only" option that turns off the AF_INET[6] listener and just listens on the AF_LOCAL socket, but that may be problematic until we have a complete transition away from glibc RPC, which still uses AF_INET loopback extensively.

Glad you found a work-around.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: rpcbind -h

[Max Matveev]

On Mon, 7 Nov 2011 12:21:31 -0500, Jim Rees wrote:

 rees> Chuck Lever wrote:
 rees>   On Nov 6, 2011, at 10:58 AM, Jim Rees wrote:
  
 >> Is there some good reason why the rpcbind '-h' option (bind to given
 >> address) applies only to the udp listening socket and not to the tcp socket?
  
 rees>   Yes.  See the mail archives.  I believe we've discussed this
 rees>   thoroughly within the past six months to a year.  If there's
 rees>   any bug here, it's that "-h" is not well documented.

 rees> It's documented well enough but I'm still in the dark about the
 rees> reason.  I

Chuck's quote from the manpage reminded me - -h was used to work
around the address selection: if server has more then one address the
reply may use any of them. Some clients don't like it.

This issue should go away after

commit 74ef3df0236c55185225c62fba34953f2582da72
Author: Olaf Kirch <okir@suse.de>
Date:   Wed Mar 2 10:09:24 2011 -0500

was added to libtirpc.

 rees> As I said before, I was hoping for the equivalent of "portmap
 rees> -l".  I was ready to code up a patch of some kind but now have
 rees> a workaround (mount with nolock and don't run rpcbind at all).

iptables is another option.

max

Re: rpcbind -h

[Steve Dickson]

On 11/06/2011 10:58 AM, Jim Rees wrote:
> Is there some good reason why the rpcbind '-h' option (bind to given
> address) applies only to the udp listening socket and not to the tcp socket?
No... sounds like a bug to me...

steved.
> 
> And is there any good reason why an nfs3 client not providing any services
> would need to run rpcbind?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rpcbind -h

[Chuck Lever]

On Nov 7, 2011, at 11:23 AM, Steve Dickson wrote:

> 
> 
> On 11/06/2011 10:58 AM, Jim Rees wrote:
>> Is there some good reason why the rpcbind '-h' option (bind to given
>> address) applies only to the udp listening socket and not to the tcp socket?
> No... sounds like a bug to me...

Behavior is described right in the man page.  So this seems to be on purpose.

     -h      Specify specific IP addresses to bind to for UDP requests.  This option
             may be specified multiple times and is typically necessary when running
             on a multi-homed host.  If no -h option is specified, rpcbind will bind
             to INADDR_ANY, which could lead to problems on a multi-homed host due to
             rpcbind returning a UDP packet from a different IP address than it was
             sent to.  Note that when specifying IP addresses with -h, rpcbind will
             automatically add 127.0.0.1 and if IPv6 is enabled, ::1 to the list.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com