linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "bfields@fieldses.org" <bfields@fieldses.org>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"ajmitchell@redhat.com" <ajmitchell@redhat.com>,
	"SteveD@RedHat.com" <SteveD@RedHat.com>,
	"chuck.lever@oracle.com" <chuck.lever@oracle.com>
Subject: Re: [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf
Date: Tue, 20 Apr 2021 17:53:34 +0000	[thread overview]
Message-ID: <85b4ca155d1697a714be88a67c505d287e22be46.camel@hammerspace.com> (raw)
In-Reply-To: <20210420174036.GD4017@fieldses.org>

On Tue, 2021-04-20 at 13:40 -0400, bfields@fieldses.org wrote:
> On Tue, Apr 20, 2021 at 05:28:08PM +0000, Trond Myklebust wrote:
> > On Tue, 2021-04-20 at 13:18 -0400, J. Bruce Fields wrote:
> > > On Tue, Apr 20, 2021 at 02:31:58PM +0000, Trond Myklebust wrote:
> > > > I think the important thing is, as Chuck said, that the setting
> > > > of
> > > > the
> > > > uniquifier has to be automated. There are too many instances
> > > > out
> > > > there
> > > > of people who get confused because they are using a default
> > > > hostname,
> > > > such as 'localhost.localdomain' and are setting no uniquifier.
> > > > 
> > > > So the point is that it needs to be persisted by an automated
> > > > script if
> > > > unset.
> > > > 
> > > > While that script could use nfsconf to get/set the persisted
> > > > uniquifier, the worry is that such an automated change might be
> > > > made
> > > > while the user is performing some other edit of nfs.conf. What
> > > > happens
> > > > then?
> > > 
> > > The one thing I'm a little uneasy about is ignoring /etc/machine-
> > > id.
> > > Seems like distros *should* be creating it for us.  And it would
> > > be
> > > convenient to have one source of machine identity rather than
> > > separate
> > > ones for different subsystems.
> > > 
> > > Maybe we could use that if it exists, and fall back on generating
> > > our
> > > own only if it doesn't?
> > > 
> > > (Well, where "use it" actually means take a hash of it, as
> > > explained
> > > in
> > > machine-id(5).)
> > > 
> > 
> > Maybe, but that ties the nfs-utils package irrevocably to systemd.
> 
> Well, like I say, we could have a fallback.  Or even provide
> alternative
> scripts in nfs-utils and let the distro decide which to install
> depending on whether they use systemd.
> 
> But, whatever, those two alternatives (machine-id or vs. nfs
> generating
> its own uuid) are basically the same on some level.

Not quite. They cause the behaviour to differ depending on whether or
not systemd is installed. So if you imagine a system that gets updated
from "traditional init" to systemd, then that could cause the NFS
identity of the machine to change.

It would be better to be able to specify the identity in a form that is
independent of the platform.

So if the machine-id exists, then maybe we could indeed generate the
identity using the uuid in that file (although the question remains as
to why you'd want that?). However the generated value should then be
persisted separately so that it can be platform independent.

> 
> I agree with the basic idea that this should be automated rather than
> living in a configuration file that humans might have to deal with.
> 
> --b.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2021-04-20 17:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 18:10 [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf Steve Dickson
2021-04-14 18:10 ` [PATCH 1/3] nfs-utils: Enable the retrieval of raw config settings without expansion Steve Dickson
2021-05-06 17:29   ` Steve Dickson
2021-04-14 18:10 ` [PATCH 2/3] nfs-utils: Add support for further ${variable} expansions in nfs.conf Steve Dickson
2021-04-14 18:10 ` [PATCH 3/3] nfs-utils: Update nfs4_unique_id module parameter from the nfs.conf value Steve Dickson
2021-04-14 23:26 ` [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf Chuck Lever III
2021-04-15 15:33   ` Steve Dickson
2021-04-15 16:37     ` Chuck Lever III
2021-04-15 23:30       ` Trond Myklebust
2021-04-16  0:40         ` Trond Myklebust
2021-04-17 16:33           ` Steve Dickson
2021-04-17 18:09             ` Trond Myklebust
2021-04-17 16:18       ` Steve Dickson
2021-04-17 16:36         ` Chuck Lever III
2021-04-17 17:50           ` Steve Dickson
2021-04-18 16:51             ` Chuck Lever III
2021-04-20 13:11               ` Steve Dickson
2021-04-20 14:09                 ` Chuck Lever III
2021-04-20 14:31                   ` Trond Myklebust
2021-04-20 17:18                     ` J. Bruce Fields
2021-04-20 17:28                       ` Trond Myklebust
2021-04-20 17:40                         ` bfields
2021-04-20 17:53                           ` Trond Myklebust [this message]
2021-04-20 18:16                             ` bfields
2021-04-20 19:30                               ` Steve Dickson
2021-04-20 18:47                     ` Steve Dickson
2021-04-20 18:26                   ` Steve Dickson
2021-05-13  0:29     ` NeilBrown
2021-05-18 12:38       ` Steve Dickson
2021-05-21  2:39         ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85b4ca155d1697a714be88a67c505d287e22be46.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=SteveD@RedHat.com \
    --cc=ajmitchell@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).