Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers

["NeilBrown" <neilb@suse.de>]

On Sat, 12 Feb 2022, Benjamin Coddington wrote:
> On 10 Feb 2022, at 17:54, NeilBrown wrote:
> 
> > On Thu, 10 Feb 2022, Benjamin Coddington wrote:
> >>
> >> Yes, but even better than having the tool do the writing is to have 
> >> udev do
> >> it, because udev makes the problem of when and who will execute this 
> >> tool go
> >> away, and the entire process is configurable for anyone that needs to 
> >> change
> >> any part of it or use their own methods of generating/storing ids.
> >
> > I really don't understand the focus on udev.
> >
> > Something, somewhere, deliberately creates the new network namespace.
> > It then deliberately configures that namespace - creating a virtual
> > device maybe, adding an IP address, setting a default route or 
> > whatever.
> > None of that is done by udev rules (is it)?
> > Setting the NFS identity is just another part of configuring the new
> > network namespace.
> >
> > udev is great when we don't know exactly when an event will happen, 
> > but
> > we want to respond when it does.
> > That doesn't match the case of creating a new network namespace.  Some
> > code deliberately creates it and is perfectly positioned to then
> > configure it.
> 
> I think there's so many ways to create a new network namespace that we 
> can't
> reasonably be expected to try to insert out problem into all of them.

I 100% agree.  Similarly there are lots of init systems and we don't try
to provide configuration for each one to ensure - e.g.  - that sm-notify
is run at the correct time.
But we *do* provide configuration for one - systemd.  This is partly
because it is widely used, but largely because the distro that I
personally help maintain uses it.  So I added those systemd/* files.
(and then others helped improve them).

> Handling the event from the kernel allows us to make a best-effort 
> default attempt.

That "best" effort is not actually very good.

Might I suggest that we take a similar approach to the systemd config.
You choose whatever container system is important to you are the moment,
determine how best to integrate the required support with that system,
make sure the tool works well for that case, provide any config files
that might be generally useful for anyone using that container system,
and in the documentation for the tool explain generally when it must run
and why, and give an example for the system that you know.

If someone else uses a different container system, they are free to
create a solution based on your example, and welcome to submit patches -
either to nfs-utils or to that container system.

Obviously you make the tool reasonably general without over-engineering,
but don't try to solve problems that you don't even know really exist.
I would suggest the tool be passed one of:
 - a unique string 
 - a file containing a unique string
 - a file in which a randomly generated unique string may be stored if
   it doesn't already contain one
 - (maybe) nothing, in which case a new random identity is generate each
   time.  This could be useful for older kernels.

> 
> > udev is async.  How certain can we be that the udev event will be 
> > fully
> > handled before the first mount attempt?
> 
> Good point.  We can't at all be certain.
> 
> We can start over completely from here..
> 
> We can have mount.nfs /also/ try to configure the id.. this is more 
> robust.

If mount.nfs is going to do it, then the "also" is pointless.  There
would be no point in any other code doing it.  However I'm no longer as
keen on mount.nfs as I was.

> 
> We can have mount.nfs do a round of udev settle..

My experience with "udev settle" with md does not make me want to depend
on it.  It has it's place and does useful things, but not always quite
what I want.

> 
> Are there other options?

Document the requirement and make it "someone elses problem".
Your kernel patch to provide a random default mean a lack of
configuration will only hurt the container which lacks it - which nicely
localises the problem.

Thanks,
NeilBrown