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?

[Steve Dickson <steved@redhat.com>]

Hello Ced,

On 11/12/23 8:01 PM, Cedric Blancher wrote:
> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <chuck.lever@oracle.com> 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 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
>>>>
>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <cedric.blancher@gmail.com> wrote:
>>>>>
>>>>> On Fri, 10 Nov 2023 at 01:37, Chuck Lever III <chuck.lever@oracle.com> wrote:
>>>>>>
>>>>>>> On Nov 9, 2023, at 7:05 PM, Cedric Blancher <cedric.blancher@gmail.com> wrote:
>>>>>>>
>>>>>>> On Thu, 2 Nov 2023 at 10:51, Cedric Blancher <cedric.blancher@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Good morning!
>>>>>>>>
>>>>>>>> Does anyone have examples of how to use the refer= option in /etc/exports?
>>>>>>>
>>>>>>> Short answer:
>>>>>>> To redirect an NFS mount from local machine /ref/baguette to
>>>>>>> /export/home/baguette on host 134.49.22.111 add this to Linux
>>>>>>> /etc/exports:
>>>>>>>
>>>>>>> /ref *(no_root_squash,refer=/export/home@134.49.22.111)
>>>>>>>
>>>>>>> This is basically an exports(5) manpage bug, which does not provide
>>>>>>> ANY examples.
>>>>>>
>>>>>> That's because setting up a referral this way is deprecated.
>>>>>
>>>>> Why did you do that?
>>>>
>>>> The nfsref command on Linux matches the same command on Solaris.
>>>>
>>>> nfsref was added years ago to manage junctions, as part of FedFS.
>>>> The "refer=" export option can't do that...
>>>
>>> Where in the kernel is the code for the refer= option? I'd like to get
>>> some of my students to contribute support for custom NFS ports.
>>
>> IIRC supporting ports is one thing we can't do right now because
>> the mountd downcall interface is text-based, and its parser can
>> barely handle "refer=", let alone specifying a port.
> 
> I had a chat this weekend with Roland Mainz (who works on the NFSv4
> driver for Windows these days):
> ...
> That is the old mistake to think that "hostname" and "port" are
> separate entities. We had this kind of debate at SUN/MPK17 several
> times. Host and TCP port are the "location of the server", and they
> are inseparable.
> ...
> The RFCs even help out with that one, for example RFC1738 (URL RFC)
> defines a "hostport" in Page 18.
> And that's what I actually did for ms-nfs41-client: NIH&Institute
> Pasteur needed custom TCP server ports, and I implemented this by
> changing the communication of nfs41_driver.sys (kernel) to userland
> NFSv4 client daemon (nfsd_debug.exe) from "hostname" to "hostport",
> and added the port number in the UNC, so Windows always uses (and
> remembers!) the port number together with the hostname.
> Or easier: I changed "hostname" to "hostport" to embed the port number
> in the up-/downcalls for mount requests - and that is what the Linux
> people can use too.
> ...
> 
>> Our plan is to replace the mountd downcall with a netlink protocol
>> that Lorenzo is working on, and then it would be very straightforward
>> to add a port to each target location. But getting to a mature
>> netlink implementation will take a while.
> 
> 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.)
My suggestion is you and Roland attend the next Bakeathon, this
spring, which will have remote access for testing and
talk about this on one of @2pm talks.

steved.