> On Wed, 2018-02-21 at 13:40 -0800, Frank Filz wrote: > > > On 2/21/18 1:59 PM, GerritHub wrote: > > > > Jeff Layton has uploaded this change for *review*. > > > > > > > > View Change <https://review.gerrithub.io/400871> > > > > > > > > MainNFSD: invert _NO_PORTMAPPER option > > > > > > > > The fact that this is a "negative" option is confusing. Change it > > > > to a "PORTMAPPER" option, and have it default to ON. > > > > > > > > > > While I vaguely agree with the former in principle, in this day and > > > age we > > > > really > > > should stop using the name PORTMAPPER. Replaced by rpcbind a long > > > time > > > > ago, > > > and shouldn't be shipping with modern systems. > > > > > > In ntirpc, PORTMAP is as expected the old version 2 UDP-only call. > > > We > > > > should > > > kill it. > > > > > > We really shouldn't encourage folks to use a UDP system that has > > > long had known DDoS attacks. > > > > > > And we really should be migrating from NFS 2 UDP to NFS 3 TCP, as a > > > > minimum > > > supported version.... > > > > > > Also, we have talked about adding rpcbind itself to Ganesha or ntirpc. > > > > Well, the "NO_PORTMAPPER" option really controls rpcbind now... > > > > Though actually, I'm not sure Ganesha actually uses any of the > > extension of rpcbind, it would probably talk to portmap just fine... > > > > And we no longer support NFS v2 (we have a couple NFS v2 stubs because > > at one time in history, the Linux client issued NFS v2 requests even > > though it was an NFS v3 mount - really just the UMOUNT was the NFS v2 > > version I think > > - it's all there in the code). That code might indeed be safe to > > remove, on the other hand, folks with appliance products tend to not > > like to force particular client versions too much as long as the pain > > point isn't too bad, and this fragment of V2 support isn't too bad. > > > > We could take this opportunity to change the option to RPCBIND... > > > > Fair enough. > > I actually disagree with the "no udp" statement above too. UDP is great for > single-shot request protocols like rpcbind, and the NFS client will use it. > DDoS is > a possibility, but who exposes their rpcbind port to the Internet? > > In any case, the real fix to this issue is to move to protocols that don't > require > rpcbind at all. That means NFSv4.0 at a minimum (though obviously v4.1+ would > be preferred).
The Linux kernel client can use NFS v3 without rpcbind, though not sure you can specify the NLM port, I know you can specify the NFS and MOUNT ports. On the other hand, rpcbind is a nice way to check general reachability of the server and what's up (and you can ping services via rpcinfo...). Frank ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
