On 09/20/2010 11:53 AM, Chuck Lever wrote:
On Sep 20, 2010, at 12:48 PM, Jan RÄkorajski wrote:
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 rpc.mountd is running on a host, and rpcbind is not, it doesn't matter. A port scanner can still find and attack the open mountd port. The best and safest approach, IMO, is to use a firewall, and then test it with a remote port scanner service. Our rpcbind implementation has tcp_wrapper already built in, for instance, but I use the iptables firewall in Fedora 13 (and, I keep RPC services on hosts inside the firewall, not on the firewall itself).
This is true, but if the argument against adding support to various components is
always 'no, because the others don't support it', then we are never going
to make progress in this direction!
If we want to add this feature properly, we will have to change a broad range of user space components. Therefore it will be a non-trivial undertaking.
For one thing, there appears to be more than one virtualization suite available for Linux (containers, kvm, and so on). If our NFS infrastructure (both client and server) is to be adapted for lightweight virtualization then I think we need a clear idea of how networking (host naming, interface assignment, routing, and so on) is going to work in these environments.
Just so you (and Ben) know, I intended to add support during the recent rpc.statd rewrite for multiple hostnames and multiple interfaces, exactly for the purpose of having our NLM and NSM implementations support container-like virtualization. This idea was NACK'd.
I'm sorry to hear it was NACK'd, but even if so, I think it's not a reason to
reject other changes that start adding support for binding to IPs.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
