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?
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 <[email protected]>
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
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.
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).
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
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
[email protected]
http://www.netapp.com