On Thu, 24 Oct 2013 14:17:10 -0400 Steve Dickson <steved@xxxxxxxxxx> wrote: > [ Here is the second try for these patches incorporating the code review..] > > Recently it was pointed out to me that the [-n | --no-tcp] flags > were broken in mountd. Sure enough they are and they broke > when nfs-utils moved to using libtirpc, which was years ago. > > Obviously nobody is using these flags since has not been > notice until now, but it seemed to me it no longer makes > any sense to have flags. We really want people to use TCP > so why should there be a way to turn it off? It should be > the opposite... They should be able to turn off UDP listeners > not TCP... > > > Steve Dickson (3): > mountd: Use protocol bit fields to turn protocols off. > mountd: Deprecate the ability to disable TCP listeners. > mountd: Add the ability to disable UDP listeners. > > support/include/rpcmisc.h | 2 +- > support/nfs/rpcmisc.c | 19 ++++++++++++++----- > support/nfs/svc_create.c | 5 +++++ > utils/mountd/mountd.c | 17 ++++++++++++----- > utils/mountd/mountd.man | 6 +++--- > 5 files changed, 35 insertions(+), 14 deletions(-) > Sorry I'm coming in late on this... I don't think we want to remove the ability to disable TCP listeners. Why, you ask? We've been on a multi-year effort to move people to NFSv4, and with that, there's no reason to have mountd listen on the network at all. So personally, I think it would make sense to: a) allow people to disable listening on UDP in addition to TCP ...or... b) add an option that prevents it from listening on any sockets for a v4-only configuration In addition, we generally do want people to use UDP for the MNT protocol because it's less apt to cause issues with reserved port exhaustion. Given that it'll continue to listen on a UDP socket by default, that last point is less of an issue, but that might be a good reason to rethink this whole plan. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
