> On Nov 13, 2023, at 5:57 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > On Mon, 13 Nov 2023 at 17:19, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> >>> On Nov 10, 2023, at 2:54 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: >>> >>> On Wed, Nov 1, 2023 at 3:42 PM Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >>>> >>>> On 1 Nov 2023, at 5:06, Martin Wege wrote: >>>> >>>>> Good morning! >>>>> >>>>> We have questions about NFSv4 referrals: >>>>> 1. Is there a way to test them in Debian Linux? >>>>> >>>>> 2. How does a fs_locations attribute look like when a nonstandard port >>>>> like 6666 is used? >>>>> RFC5661 says this: >>>>> >>>>> * http://tools.ietf.org/html/rfc5661#section-11.9 >>>>> * 11.9. The Attribute fs_locations >>>>> * An entry in the server array is a UTF-8 string and represents one of a >>>>> * traditional DNS host name, IPv4 address, IPv6 address, or a zero-length >>>>> * string. An IPv4 or IPv6 address is represented as a universal address >>>>> * (see Section 3.3.9 and [15]), 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. A >>>>> * zero-length string SHOULD be used to indicate the current address being >>>>> * used for the RPC call. >>>>> >>>>> Does anyone have an example of how the content of fs_locations should >>>>> look like with a custom port number? >>>> >>>> If you keep following the references, you end up with the example in >>>> rfc5665, which gives an example for IPv4: >>>> >>>> https://datatracker.ietf.org/doc/html/rfc5665#section-5.2.3.3 >>> >>> So just <address>.<upper-byte-of-port-number>.<lower-byte-of-port-number>? >> >>> How can I test that with the refer= option in /etc/exports? nfsref >>> does not seem to have a ports option... >> >> Neither refer= nor nfsref support alternate ports for exactly the >> same reason: The mountd upcall/downcall, which is how the kernel >> learns of referral target locations, needs to be fixed first. Then >> support for alternate ports can be implemented in both refer= and >> nfsref. > > Just turn "hostname" into "hostport", i.e. the "hostname" string in > the mountd protocol gets the port number encoded into it. Problem > done. This is seriously a non-brainer, It's not as simple as you think. As far as I can tell, the mountd upcall/downcall already uses the "@" character in the refer= value for another purpose. It has the same problem as using ":" -- it would overload the meaning of the character and make the refer= value ambiguous and unparsable. NFSD supports IPv4 addresses, IPv6 addresses, and DNS labels as the hostname part of each fs_locations entry. DNS label support is one reason we might have some difficulty using a universal address in this interface -- the dot notation for the port number bytes looks no different than the dot notation for subdomains, and we want to enable alternate ports for both raw IP addresses and DNS labels. Adding more here means more careful parsing and more to get wrong. In the kernel we don't have a lot of the beefy parsing library support that exists in user space. Thus typically user space needs to digest such arguments and pass the pre-separated tokens to the kernel. > and can be repeated for autofs, > which does not do port number either, autofs is a different subsystem with a different maintainer and a different set of design goals. Not to mention that it also tries to stay roughly comparable to the same administrative interfaces on Solaris and other Unix-like operating systems, since automounter maps can be shared with non-Linux systems. Let's focus on the NFS-server specific components for now, please, and ignore autofs and the mount.nfs command. -- Chuck Lever
