Re: [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf

[Steve Dickson <SteveD@RedHat.com>]

On 4/20/21 10:31 AM, Trond Myklebust wrote:
>>> What I don't understand is why we can't come up with a 
>>> solution that uniquely set a param that is set by 
>>> nfsconf using nfs.conf.
>> Once we have an automated mechanism to set the uniqifier,
>> it does not need to be set by humans. Let's keep it out of
>> nfs.conf.
>>
>> I'm in favor of making this as automatic as possible. No
>> setting is better than an exposed setting that is never
>> touched.
>>
>> I prefer no change to nfs.conf, and put the uniqifier in a
>> separate file.
>>
> 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.
The current patches use either /etc/machine-id or hostname 
to generate the uniquifier. Alice's patches also included 
/proc/sys/kernel/random/uuid as as way generate. 

People could have those choices... and we (aka nfs-utils) would be 
doing the generations.

> 
> So the point is that it needs to be persisted by an automated script if
> unset.
Yes this is one thing that is missing... Making sure it is not already set.

> 
> 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?
Cat will start dating Dogs??? IDK! :-) 

So it sound like we need a way to generate an uniquifier
which the patches do (we could add your sysfs one) 
but you don't what that way tied to /etc/nfs.conf.

So that means we will generate the uniquifier one
way and only one way that has to work on all distro 
that happens automatically... If id is not already
set... 

There should be a way for distro to decide who the 
uniquifier is generated?

steved.