On Mon, 20 Sep 2010, Chuck Lever wrote: > > On Sep 20, 2010, at 11:31 AM, Jan RÄkorajski wrote: > > > On Mon, 20 Sep 2010, Chuck Lever wrote: > > > >> > >> On Sep 17, 2010, at 6:22 PM, Jan RÄkorajski wrote: > >> > > [snip] > >>> > >>> What about TCP then? My patch was a by-product of trying to make '-h <IP>' > >>> also work for tcp sockets, so if we skip unbindable addresses for UDP, > >>> then will it be ok to do the same for TCP? > >> > >> Interesting. Now that I've actually looked at the documentation >> > >> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem > >> to recall that the legacy portmapper had a problem on multi-homed > >> hosts where a request was received on one interface, and the reply was > >> sent out another. > >> > >> This is certainly a problem for datagram transports, but shouldn't be > >> an issue for connection-oriented transports: the reply is always sent > >> on the same connection as the request was received. > >> > >> Can you say a little more about why do you need "-h" to work for > >> connection-oriented sockets? > > > > I have a multihomed nfs server, and I don't want the portmapper to even > > listen on an outside interface. > > Understood, but that is accomplished with firewalling, these days. It always was, but it's nice not needing to worry if I closed/opened all that's neccessary. > Usually, NFS servers are not run on the edge of private networks > unless they are serving files to public hosts. I would, if I could :) > None of NFS's RPC daemons allow you to set a bind address, with one > exception. rpc.statd allows one to specify a "bind address" in the > form of a host name for reasons specific to the NSM protocol. I may be wrong here, but maybe it's because it was always portmapper doing the binding, so if portmapper couldn't then no one thought of adding this to RPC daemons. > If this is NFSv4 only, ostensibly rpcbind is not needed. I know our > implementation today still clings to rpcbind a bit, but theoretically > at least, you could just leave it unstarted if you are only running an > NFSv4 service. rpc.mountd should also allow itself to be run without > starting network listeners in recent versions of nfs-utils. That's all good, but some still need portmapper for other services. > I'm not necessarily arguing against the idea of adding a bind address > command line option, but this _would_ be a change to long established > historical behavior, and it would not be consistent with many of the > other Linux RPC services I'm aware of. So, I'd like to be absolutely > sure we understand what you need here, and ensure we can't address it > with existing administrative controls. I understand your concerns, but I have problem imagining someone that had to limit UDP bind not wanting to also limit TCP. > > Second thing is a host for vservers > > (http://linux-vserver.org), I need to run portmapper in guests but > > rpcbind listening on INADDR_ANY is not letting me. > > Can you say more? Maybe it's a bug. It's more of a design flaw, vserver is an isolation techique, and if I bind to some port on INADDR_ANY on host then I can't bind to that port on guests. I don't know the implementation details, but network interfaces other than lo are not (maybe can't be) isolated enough. > > And finally it's good > > to be consistent, it's strange to me that someone may want to limit only > > the UDP part of portmapper (modulo network issues you mentioned). > > "-h" was added to address an issue specific to Linux UDP sockets. > It's not a feature, but a bug fix that is UDP-specific. TCP doesn't > need this bug fix. Of course, but why not change a bugfix into a feature? -- Jan RÄkorajski | ALL SUSPECTS ARE GUILTY. PERIOD! baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
