Re: [patch] mount.nfs: Add support for nfs://-URLs ...

[Chuck Lever <chuck.lever@oracle.com>]

On 12/6/24 6:33 PM, Roland Mainz wrote:
> On Fri, Dec 6, 2024 at 4:54 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>> Here are some initial review comments to get the ball rolling.
>> On 12/6/24 5:54 AM, Roland Mainz wrote:
>>> Below (and also available at https://nrubsig.kpaste.net/b37) is a
>>> patch which adds support for nfs://-URLs in mount.nfs4, as alternative
>>> to the traditional hostname:/path+-o port=<tcp-port> notation.
>>>
>>> * Main advantages are:
>>> - Single-line notation with the familiar URL syntax, which includes
>>> hostname, path *AND* TCP port number (last one is a common generator
>>> of *PAIN* with ISPs) in ONE string
>>> - Support for non-ASCII mount points, e.g. paths with CJKV (Chinese,
>>
>> s/mount points/export paths
> 
> OK
> 
>> (When/if you need to repost, you should move this introductory text into
>> a cover letter.)
> 
> What is a "cover letter" in this context ? git feature, or something else ?

Have a look at git-send-email(1), and search for "cover". A cover
letter is an introductory email, followed by the patches themselves
in separate email items (usually organized as replies to the cover
letter, but that depends on the email sending tool).


>>> Japanese, ...) characters, which is typically a big problem if you try
>>> to transfer such mount point information across email/chat/clipboard
>>> etc., which tends to mangle such characters to death (e.g.
>>> transliteration, adding of ZWSP or just '?').
>>> - URL parameters are supported, providing support for future extensions
>>
>> IMO, any support for URL parameters should be dropped from this
>> patch and then added later when we know what the parameters look
>> like. Generally, we avoid adding extra code until we have actual
>> use cases. Keeps things simple and reduces technical debt and dead
>> code.
> 
> Originally we had much more URL parameters in the patch.
> 
> After lots of debate I've cut that part down to the set (i.e. { "rw",
> "ro" } * { "0", "1" }, e.g. "ro=1", "ro=0" etc,) which is supported by
> ALL nfs://-URL implementations right now - which means if we revise
> the nfs://-URL RFC to make nfs://-URLs independent then we have to
> cover the existing "ro"/"rw" URL parameters anyway.

NFS URLs are specified by RFC 2224, but extended by RFC 7532
Section 2.8.1:

    https://www.rfc-editor.org/rfc/rfc7532.html#section-2.8.1

Note this language:

    An NFS URI MUST contain both an authority and a path component.  It
    MUST NOT contain a query component or a fragment component.  Use of
    the familiar "nfs" scheme name is retained.

IMHO this part of your implementation needs to be postponed until the
standards are worked out.


> Technically I can rip it out for now, but per URL RFC *any* unexpected
> URL parameter must be fatal, which in this case will break stuff.

Fatal? What does "break stuff" mean, precisely?


> That's why I would prefer to keep this code, and it's also intended to
> demonstrate how to implement URL parameters correctly.
> 
> Maybe split this off into a 2nd patch ?

That would be good.


>>> * Notes:
>>> - Similar support for nfs://-URLs exists in other NFSv4.*
>>> implementations, including Illumos, Windows ms-nfs41-client,
>>> sahlberg/libnfs, ...
>>
>> The key here is that this proposal is implementing a /standard/
>> (RFC 2224).
> 
> Right, I wasn't sure whether to quote it or not, because section 2 of
> that RFC quotes WebNFS, and some people are afraid of
> "WebNFS-will-come-back-from-the-grave-to-have-it's-revenge"... :-)
> ... but yes, I'll quote that.
> 
>>> - This is NOT about WebNFS, this is only to use an URL representation
>>> to make the life of admins a LOT easier
>>> - Only absolute paths are supported
>>
>> This is actually a critical part of this proposal, IMO.
>>
>> RFC 2224 specifies two types of NFS URL: one that specifies an
>> absolute path, which is relative to the server's root FH, and
>> one that specifies a relative path, which is relative to the
>> server's PUB FH.
>>
>> You are adding support for only the absolute path style. This
>> means the URL is converted to string mount options by mount.nfs
>> and no code changes are needed in the kernel. There is no new
>> requirement for support of PUBFH.
> 
> Right, I know.

Some reviewers like to paraphrase to show their understanding --
basically if what I've repeated back to you doesn't reflect your
understanding, here your opportunity to say "No, it works this
way instead".


> And the code will reject any relative URLs ($ grep -r
> -F 'Relative nfs://-URLs are not supported.' #) ...

That is right and proper ;-)


>> I wonder how distributions will test the ability to mount
>> percent-escaped path names, though. Maybe not upstream's problem.
> 
> It's more an issue to generate the URLs, but any URL-encoding-web page
> can do that.
> I also have http://svn.nrubsig.org/svn/people/gisburn/scripts/nfsurlconv/nfsurlconv.ksh
> and other utilities, but that would be a seperate patch series.
> 
> DISCLAIMER: Yes, it's a ksh(93) script (because it needs multiline
> extended regular expressions, which bash does not have in that form),
> and putting that into nfs-utils will NOT cause a runtime dependency to
> /sbin/mount.nfs4 or somehow break DRACUT/initramfs. It's just a
> utility *script*.

That's fine. Testing components like this are generally packaged
so that they are not installed in resource-constrained environments
such as initramfs.


>>> - This feature will not be provided for NFSv3
>>
>> Why shouldn't mount.nfs also support using an NFS URL to mount an
>> NFSv3-only server? Isn't this simply a matter of letting mount.nfs
>> negotiate down to NFSv3 if needed?
> 
> Two issues:
> 1. I consider NFSv2/NFSv3/NFSv4.0 as obsolete

NFSv2 is obsolete, yes.

The NFSv3 standard is not being updated, but NFSv3 is broadly
deployed and implementations are actively maintained. It's not
obsolete.

NFSv4.0 is on its way out, but is not obsolete yet. I don't
think it would be challenging to include support here.


> 2. It would be much more complex because we need to think about how to
> encode rpcbind&transport parameters, e.g. in cases of issues like
> custom rpcbind+mountd ports, and/or UDP.

This is much more than is needed, IMO. NFSv3 can stick with the
standard rpcbind port, an rpcbind query for MNT. My reading of
the RFCs suggests that for NFSv3, the transport protocol is
selected based on what both sides support.

I think we want to avoid trying to build every bell and whistle
into the mount.nfs NFS URL implementation. Just cover the basics,
at least in the initial implementation.


> That will quickly escalate
> and require lots of debates. We had that debate already in ~~2006 when
> I was at SUN Microsystems, and there was never a consensus on how to
> do nfs://-URLs for NFSv3 outside WebNFS.
> 
> I think it can be done, IMHO but this is way outside of the scope of
> this patch, which is mainly intended to fix some *URGENT* issues like
> paths with non-ASCII characters for the CJKV people and implement
> "hostport" notation (e.g. keep hostname+port in one string together).
> 
>> General comments:
>>
>> The white space below looks mangled. That needs to be fixed before
>> this patch can be applied.
> 
> Yes, I know, that is a problem that I only have the choice between
> GoogleMail or MS Outlook at work. That's why I provided kpaste.net
> links (https://nrubsig.kpaste.net/e8c5cb?raw and
> https://nrubsig.kpaste.net/e8c5cb). I'll try to set up git-imap-send
> in the future, but that needs time to convince our IT.
> 
> This should work for the v2 patch:
> ---- snip ----
> git clone git://git.linux-nfs.org/projects/steved/nfs-utils.git
> cd nfs-utils/
> wget 'https://nrubsig.kpaste.net/e8c5cb?raw'
> dos2unix e8c5cb\@raw
> patch -p1 --dry-run <e8c5cb\@raw
> patch -p1 <e8c5cb\@raw

Er. Well maybe. It's up to the nfs-utils maintainer whether he
wants to take a patch like that.

However, our email-based review workflow means that the actual
patch that every one has reviewed and signed off on is preserved
in a public mail archive (along with the Acks, Tested-bys and
Reviewed-bys).

We don't have that when someone posts a link to a temporary
paste bin.

Paste bin submissions are not scalable for the maintainer because
our tool chain is designed around taking an email submission and
applying it directly. Pulling from a paste bin is a lot of manual
work.

We all have the same struggles with our corporate IT departments.


> ---- snip ----
> 
>> IMO, man page updates are needed along with this code change.
> 
> Could we please move this to a separate patch set ?

That's up to the maintainer, but he usually requires adequate
documentation along with new features. It's too easy to submit
code changes and then put off the documentation for ever.


>> IMO, using a URL parser library might be better for us in the
>> long run (eg, more secure) than adding our own little
>> implementation. FedFS used liburiparser.
> 
> The liburiparser is a bit of an overkill, but I can look into it.

Here's the point of using a library:

A popular library implementation has been very well reviewed and is
used by a number of applications. That gives a high degree of confidence
that there are fewer bugs (in particular, security-related bugs). The
library might be actively maintained, and so we don't have to do that
work.

Something like liburiparser might be more than we need for this
particular job, but code re-use is pretty foundational. If liburiparser
isn't a good fit, look for something that is a better fit.


> I
> tried to keep it simple for ms-nfs41-client (see below), because
> otherwise I would've to deal with another DLL (which are far worse
> than any *.so issue I've seen on Solaris/Linux).
> 
> The current urlparser1.[ch] was written for OpenSolaris long ago, and
> then updated for the Windows ms-nfs41-client project (see
> https://github.com/kofemann/ms-nfs41-client/tree/master/mount ; almost
> the same code, except there are additions for wide-char streams and MS
> Visual Studio) and is being maintained for that and several in-house
> projects, so maintenance is guaranteed (that's why my manager (Marvin
> Wenzel) signed it off, too).

OK, but you're /copying/ this into nfs-utils. How will our copy get
updated over time? With an external library, bug fixes go to the library
and nfs-utils gets them automatically when it is re-linked.


> [snip]
>>> ---- snip ----
>>>   From e7b5a3ac981727e4585288bd66d1a9b2dea045dc Mon Sep 17 00:00:00 2001
>>> From: Roland Mainz <roland.mainz@nrubsig.org>
>>> Date: Fri, 6 Dec 2024 10:58:48 +0100
>>> Subject: [PATCH] mount.nfs4: Add support for nfs://-URLs
>>>
>>> Add support for RFC 2224-style nfs://-URLs as alternative to the
>>> traditional hostname:/path+-o port=<tcp-port> notation,
>>> providing standardised, extensible, single-string, crossplatform,
>>> portable, Character-Encoding independent (e.g. mount point with
>>
>> As above: s/mount point/export path
> 
> OK
> 
> Anything else ?

You should expect review comments from others as well.


-- 
Chuck Lever