On Mon, 8 Jan 2024 at 15:39, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Sun, Jan 07, 2024 at 11:33:31PM +0100, Cedric Blancher wrote: > > Could you please make a concentrated effort and allow non-2049 port > > numbers for NFSv4 mounts, in all of the lifecycle of a NFSv4 mount? > > From nfsd, nfsd referrals, client mount/umount, autofs > > mount/umount+LDAP spec > > One reason we have not pursued stack-wide NFSv4 support for > alternate ports is that they are not firewall-friendly. A major > design point of NFSv4 (and NFSv4.1, with its backchannel) is that > it is supposed to be more firewall-friendly than NFSv3, its > auxiliary protocols, and its requirement to deploy rpcbind. Who came up with THAT argument?! NFSv4 was designed around the concept of ONE TCP port for everything (fs, mount, lock daemons, ...), so multiple servers per IPv4 address can become a reality, but not specifically 2049 - with the clear assumption that using port 2049 might not be feasible for all organisations. If you look at Solaris BUGSTER (remember, we were a big SUN customer in the 1990/2000, so we had lots of bugs open for this mess), you'll find lots of reasons why one single port for NFS is not feasible in all scenarios. Just some examples, but certainly not limited to: - Fine-grained HSM, all on one host - Fine-grained project/resource management, i.e. one nfs server per project, all on one host - Competing teams - Hostile IT department (e.g. port 2049 blocked out of FEAR - not reason, no further discussion/negotiation possible) - NFSv4 tunneled via ssh - NAT, e.g. private IPv4 address range inside, only one IPv4 address outside - IPv4 address shortage - Software test deployments in parallel to the production systems, on the same machine - ... In any of these scenarios you'll end up with NFSv4 certainly not using TCP port 2049. > > Also, these days it is relatively easy in Linux to deploy multiple > NFS services on a single physical host by using containers (or just > separate network namespaces). That would assume people want to waste resources on the container madness. OK, I better stop here, before I start counting how many MB are wasted on the container/VM cr*p. > So instead of alternate ports, each > NFS service is on port 2049, but it has its own IP address. Not feasible with NAT, or IPv4 address shortage. > That > kind of deployment is supposed to be fully supported with NFSD today. > > Commercial NFS server implementations also typically make it easy > to add distinct NFSv4 services at unique IP addresses but all on > port 2049. Unfortunately this is just wishful thinking. Please check how NIH or CERN do their setups - you'll get a nasty surprise in terms of NFSv4 port==2049. Just the reality, from our side: Active, per-project nfs servers: 14030. Only 1717 (less than 10%!!) use TCP port 2049, all others do their duty in the port range of 10000-16999. Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
