On 4/21/24 6:14 PM, Trond Myklebust wrote:
On Sun, 2024-04-21 at 17:38 -0400, Steve Dickson wrote:
On 4/21/24 12:06 PM, Trond Myklebust wrote:
On Sun, 2024-04-21 at 07:09 -0400, Steve Dickson wrote:
On 4/12/24 6:26 AM, Alexandre Ratchov wrote:
Hi,
mount.nfs always uses a high port to probe the server's ports
(regardless of
the "-o resvport" option). Certain NFS servers (ex. OpenBSD -
current) will
drop the connection, the probe will fail, and mount.nfs will
exit
before any
attempt to mount the file-system. If mount.nfs doesn't ping
the
server from
a high port, mounting the file system will just work.
Note that the same will happen if the server is behind a
firewall
that
blocks connections to the NFS service that originates from a
high
port.
Committed... (tag: nfs-utils-2-7-1-rc7)
I just hope we don't run out of privilege ports during
a mount storm (aka when a server reboots).
Agreed, and that is why this change was entirely the wrong thing to
do.
Well the patch was sitting around for a while without any objection
so I figured I would go with it since it would make mounts
work on other OSs
The point of the ping is to allow for fast failover in the case
where
the portmap/rpcbind server returns incorrect or stale information.
If there are servers out there that deliberately break the
convention
for NULL ping, as described in RFC5531, then we might allow
optional
use of the privileged port for those servers, but please don't
force
this on everyone else.
The patch is on the top of stack... easy revert-able... Is that what
you are suggesting?
That is my suggestion for now, yes.
I don't have any objection to a patch that adds opt-in functionality
either to turn off the NULL ping, or to force that ping to use a
privileged port. However we should not change the default behaviour to
cause the existing paucity of privileged ports to be even more of a
problem.
Reverted.
steved.
