On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher
<[email protected]> wrote:
> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <[email protected]> wrote:
> > > On Nov 10, 2023, at 3:30 AM, Martin Wege <[email protected]> wrote:
> > > On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <[email protected]> wrote:
> > >>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <[email protected]> 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 and
> the /sbin/mount output.
> So instead of:
> mount -t nfs -o port=4444 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= - 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= in /etc/exports ?
Would this work:
---- snip ----
`/ref *(no_root_squash,refer=/export/[email protected]:32049)
---- snip ----
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
> On Jan 29, 2024, at 6:44 AM, Roland Mainz <[email protected]> wrote:
>
> On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher
> <[email protected]> wrote:
>> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <[email protected]> wrote:
>>>> On Nov 10, 2023, at 3:30 AM, Martin Wege <[email protected]> wrote:
>>>> On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <[email protected]> wrote:
>>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <[email protected]> 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 and
>> the /sbin/mount output.
>> So instead of:
>> mount -t nfs -o port=4444 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= - 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= in /etc/exports ?
>
> Would this work:
> ---- snip ----
> `/ref *(no_root_squash,refer=/export/[email protected]: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. It is on our enhancement request list.
--
Chuck Lever
On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <[email protected]> wrote:
>
>
>
> > On Jan 29, 2024, at 6:44 AM, Roland Mainz <[email protected]> wrote:
> >
> > On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher
> > <[email protected]> wrote:
> >> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <[email protected]> wrote:
> >>>> On Nov 10, 2023, at 3:30 AM, Martin Wege <[email protected]> wrote:
> >>>> On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <[email protected]> wrote:
> >>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <[email protected]> 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 and
> >> the /sbin/mount output.
> >> So instead of:
> >> mount -t nfs -o port=4444 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= - 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= in /etc/exports ?
> >
> > Would this work:
> > ---- snip ----
> > `/ref *(no_root_squash,refer=/export/[email protected]: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) ...
For context: I have a ticket open for the ms-nfs41-client to get the
referral support with custom (non-2049) TCP ports fixed...
> It is on our enhancement request list.
Thanks... :-)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
> On Jan 29, 2024, at 10:07 AM, Roland Mainz <[email protected]> wrote:
>
> On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <[email protected]> wrote:
>>
>>> On Jan 29, 2024, at 6:44 AM, Roland Mainz <[email protected]> wrote:
>>>
>>> On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher
>>> <[email protected]> wrote:
>>>> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <[email protected]> wrote:
>>>>>> On Nov 10, 2023, at 3:30 AM, Martin Wege <[email protected]> wrote:
>>>>>> On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <[email protected]> wrote:
>>>>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <[email protected]> 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 and
>>>> the /sbin/mount output.
>>>> So instead of:
>>>> mount -t nfs -o port=4444 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= - 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= in /etc/exports ?
>>>
>>> Would this work:
>>> ---- snip ----
>>> `/ref *(no_root_squash,refer=/export/[email protected]: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= export
option. Instead, we plan to add the ability to specify an alternate
port via the "nfsref" command.
The refer= 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.
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.
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.
HTH
--
Chuck Lever
On Mon, Jan 29, 2024 at 4:51 PM Chuck Lever III <[email protected]> wrote:
>
>
> > On Jan 29, 2024, at 10:07 AM, Roland Mainz <[email protected]> wrote:
> >
> > On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <[email protected]> wrote:
> >>
> >>> On Jan 29, 2024, at 6:44 AM, Roland Mainz <[email protected]> wrote:
> >>>
> >>> On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher
> >>> <[email protected]> wrote:
> >>>> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <[email protected]> wrote:
> >>>>>> On Nov 10, 2023, at 3:30 AM, Martin Wege <[email protected]> wrote:
> >>>>>> On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <[email protected]> wrote:
> >>>>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <[email protected]> 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 and
> >>>> the /sbin/mount output.
> >>>> So instead of:
> >>>> mount -t nfs -o port=4444 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= - 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= in /etc/exports ?
> >>>
> >>> Would this work:
> >>> ---- snip ----
> >>> `/ref *(no_root_squash,refer=/export/[email protected]: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= 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= 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= 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
> On Jan 29, 2024, at 10:07 AM, Roland Mainz <[email protected]> wrote:
>
> On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <[email protected]> wrote:
>>
>>> On Jan 29, 2024, at 6:44 AM, Roland Mainz <[email protected]> wrote:
>>>
>>> What would be the correct syntax to specify a custom (non-2049) TCP
>>> port for refer= in /etc/exports ?
>>>
>>> Would this work:
>>> ---- snip ----
>>> `/ref *(no_root_squash,refer=/export/[email protected]: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) ...
>
> For context: I have a ticket open for the ms-nfs41-client to get the
> referral support with custom (non-2049) TCP ports fixed...
Here's a workaround that might be used with current
versions of NFSD. I'm going to walk through this because
there is some information that could be useful for
ms-nfs41-client.
Referrals are conveyed to NFSv4 clients using the
fs_locations attribute of GETATTR. This attribute conveys
a list of alternate locations a client can use to access
the share it's looking for.
Each item in the list looks like this:
struct fs_location4 {
utf8str_cis server<>;
pathname4 rootpath;
};
The content of the server<> field is either a hostname or
an IP address. RFC 8881 Section 11.16 says:
> An IPv4 or IPv6 address is represented as a universal address (see Section 3.3.9 and [12]), minus the netid, and either with or without the trailing ".p1.p2" suffix that represents the port number. If the suffix is omitted, then the default port, 2049, SHOULD be assumed.
Therefore there is only one way to convey an alternate
port. You can't do it when the server<> field contains a
DNS label; the server has to spell it out with a universal
address. This is part of the NFSv4 protocol, it's not an
NFSD limitation.
(When NFSD supports this properly, it will need to resolve
each hostname to an IP address, when an alternate port is
present, before it builds the fs_location4 list item).
It turns out that our mountd passes the "host" part of the
refer= option to the kernel without much additional
checking, so you can specify a full IPv4 universal address
like so:
/export/referral *(refer=/export/[email protected] <mailto:refer=/export/[email protected]>.8.1)
That is, it's an IPv4 address with a .p1.p2 suffix.
p1 = port DIV 256
p2 = port MOD 256
Here, .8.1 is port 2049.
I've tried some simple testing, and it seems to work with
both refer= and nfsref.
This refer= port syntax probably won't work for IPv6
addresses, and definitely will not for DNS labels. Thus
I consider this a hack and not a long-term solution for
NFSD.
Regarding Roland's question about copying this syntax for
other NFSv4 servers: I recommend that you don't do that.
You'll end up copying its mistakes and limitations. To
amplify my previous explanation: this is unfinished work,
and there are other, better ways to handle referrals.
Moreover, you can't copy what doesn't exist. Since NFSD
currently does not support alternate ports in any kind
of robust way, there's nothing to copy. Each server
implementation will have to invent their own.
--
Chuck Lever