On Mon, 13 Nov 2023 at 02:01, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > > > > > > > On Nov 10, 2023, at 3:30 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: > > > > > > On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > >> > > >>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > >>> > > >>> On Fri, 10 Nov 2023 at 01:37, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > >>>> > > >>>>> On Nov 9, 2023, at 7:05 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > >>>>> > > >>>>> On Thu, 2 Nov 2023 at 10:51, Cedric Blancher <cedric.blancher@xxxxxxxxx> 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.) This issue is still open, and BURNING! Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
