Received-SPF: pass (google.com: domain of linux-nfs+bounces-1006-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <CALXu0UdFR7Xn51eKFUUi6a68wvDKc-RXz7F4LKyQgDptqfYbgw@mail.gmail.com>
 <CALXu0UfSJ0Qc3HOecf4pQ=VnEVqxRw6OGzNwhh9BUVYaHV7_oQ@mail.gmail.com> <ZZwJLb7j65QXR1+K@tissot.1015granger.net>
In-Reply-To: <ZZwJLb7j65QXR1+K@tissot.1015granger.net>
From: Cedric Blancher <cedric.blancher@gmail.com>
Date: Wed, 10 Jan 2024 07:06:00 +0100
Message-ID: <CALXu0UdJanF-_=3TzgzUskwh1RGPjw+LeZ0Cht+yP1aQgr8v+w@mail.gmail.com>
Subject: Re: nfs-utils&nfsd&autofs not supporting non-2049 TCP port numbers -
 Fwd: showmount -e with custom port number?
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

On Mon, 8 Jan 2024 at 15:39, Chuck Lever <chuck.lever@oracle.com> 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@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur