Received-SPF: pass (google.com: domain of linux-nfs+bounces-1579-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <CALXu0UeGr80OzF7abqxwR5KFJFhpCuomy2_tdFESAKSiW70jfA@mail.gmail.com>
 <CALXu0UcT4gG8xEVOvK1mshMDa_hKYu7rJK2biq8==ySOXdA3+w@mail.gmail.com>
 <4F5C3573-2962-4072-ACB1-1CB8236866D5@oracle.com> <CALXu0Uf2z3um+kh=tgnqskr-ZdY2gU=185K3Amr=F_GJpb2_UQ@mail.gmail.com>
 <FD981B2C-5C24-4349-A279-C70F640C0A01@oracle.com> <CANH4o6O=ihW7ENc-BTBXR4d4JL0QJjZa5YdYaKAdoHdq9vwGcA@mail.gmail.com>
 <5DA015E1-50C6-4F56-B4E7-62A4BE90DBA4@oracle.com> <CALXu0UcLV-KZ4GNY8UgWCwiUOO_HsH=KLWOKuWJ2uEDP+a9sqw@mail.gmail.com>
 <CAKAoaQ=FDdkTW2Vh=_Y08DEWZYaJa6tDSYKnFiZCfQ6+PW_5iQ@mail.gmail.com>
 <610FDE39-3094-40EB-B671-F2CA876CA145@oracle.com> <CAKAoaQkdf41emWL-2Uq9_kFjF99Xc7UEK_ur0MmnfFAjJqLM7A@mail.gmail.com>
 <BCB4C051-B76D-4025-A3FB-78B2F2D069BD@oracle.com>
In-Reply-To: <BCB4C051-B76D-4025-A3FB-78B2F2D069BD@oracle.com>
From: Martin Wege <martin.l.wege@gmail.com>
Date: Tue, 30 Jan 2024 00:45:24 +0100
Message-ID: <CANH4o6M9UrqJ_T3dneaJjA-674+rRRLpFS7DMo8L1rMXOoFo7g@mail.gmail.com>
Subject: Re: refer= syntax in /etc/exports for custom non-2049 TCP ports ? /
 was: Re: Change "hostname" to "hostport" in text-based mountd downcall Re:
 BUG in exports(5), no example for refer= Re: Examples for refer= in /etc/exports?
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Roland Mainz <roland.mainz@nrubsig.org>, 
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>, Cedric Blancher <cedric.blancher@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 29, 2024 at 4:51=E2=80=AFPM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
>
> > On Jan 29, 2024, at 10:07=E2=80=AFAM, Roland Mainz <roland.mainz@nrubsi=
g.org> wrote:
> >
> > On Mon, Jan 29, 2024 at 3:14=E2=80=AFPM Chuck Lever III <chuck.lever@or=
acle.com> wrote:
> >>
> >>> On Jan 29, 2024, at 6:44=E2=80=AFAM, Roland Mainz <roland.mainz@nrubs=
ig.org> wrote:
> >>>
> >>> On Mon, Nov 13, 2023 at 2:01=E2=80=AFAM Cedric Blancher
> >>> <cedric.blancher@gmail.com> wrote:
> >>>> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <chuck.lever@oracle.co=
m> wrote:
> >>>>>> On Nov 10, 2023, at 3:30 AM, Martin Wege <martin.l.wege@gmail.com>=
 wrote:
> >>>>>> On Fri, Nov 10, 2023 at 3:20=E2=80=AFAM Chuck Lever III <chuck.lev=
er@oracle.com> wrote:
> >>>>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <cedric.blancher@gma=
il.com> wrote:
> >>> [snip]
> >>>> Yeah, instead of waiting for NetLink you could implement Roland's
> >>>> suggestion, and change "hostname" to "hostport" in your test-based
> >>>> mount protocol, and technically everywhere else, like /proc/mounts a=
nd
> >>>> the /sbin/mount output.
> >>>> So instead of:
> >>>> mount -t nfs -o port=3D4444 10.10.0.10:/backups /var/backups
> >>>> you could use
> >>>> mount -t nfs 10.10.0.10@4444:/backups /var/backups
> >>>>
> >>>> The same applies to refer=3D - just change from "hostname" to
> >>>> "hostport", and the text-based mountd downcall can stay the same (e.=
g.
> >>>> so "foobarhost" changes to "foobarhost@444" in the mountd download.)
> >>> [snip]
> >>>
> >>> What would be the correct syntax to specify a custom (non-2049) TCP
> >>> port for refer=3D in /etc/exports ?
> >>>
> >>> Would this work:
> >>> ---- snip ----
> >>> `/ref *(no_root_squash,refer=3D/export/home@134.49.22.111:32049)
> >>> ---- snip ----
> >>
> >> Hello Roland -
> >>
> >> Although generic NFSv4 referral support has been in NFSD for
> >> many years, NFSD currently does not implement alternate ports
> >> in referrals.
> >
> > I know, but the question is about the syntax in /etc/exports. The idea
> > is to use the same syntax for other NFSv4 server implementations (like
> > nfs4j) ...
>
> We're planning not to support alternate ports via the refer=3D export
> option. Instead, we plan to add the ability to specify an alternate
> port via the "nfsref" command.

But that was NOT Rolands question. The question was which syntax would
work ('Would this work:'), as this is for other NFSv4 server software
such as nfs4j, which tries to be compatible with Linux.

>
> The refer=3D export option (that is, using this UI for setting up NFSv4
> referrals) has been experimental since it was introduced, and has a
> number of limitations that we hope to avoid by using "nfsref" instead.

The problem I see is that - if Linux nfsref gets fixed to include
custom ports - then it will take at least 3-5 years until this version
is readily available in ALL stable versions of all distributions.
Any improvements or fixes to refer=3D is available with the next Linux
kernel patch, and I'd be more than happy to pay $$$$ to customer
support to have such a patch backported to a stable branch.

>
> As an alternative, Solaris, for instance, does not use the /etc/export
> interface mechanism at all, preferring instead the "share" and "nfsref"
> commands. (though as far as I am aware, Solaris does not implement
> support for alternate ports in referrals either).
>
> Solaris has support for reparse points (as does FreeBSD). "nfsref"
> is supposed to be a mechanism for editing those, and theoretically
> reparse points were supposed to handle more than just NFSv4 referrals.

How would a reparse point with a custom NFSv4 port look like?

>
> Unfortunately I was never able to generate a lot of appetite in the
> Linux kernel community for implementing reparse points in our file
> systems. Our "nfsref" command is therefore somewhat limited.

Did you document this somewhere?

Thanks,
Martin