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:09 AM, Chuck Lever III wrote:
>>>> If that is the cause... have the variables in 
>>>> nfs.conf create sysfs/udev file would work better?
>>>
>>> Seems to me we have the same argument for a separate file
>>> to store the nfs4_unique_id that we have for breaking
>>> /etc/exports into a directory of individual files: no
>>> parsing is necessary. Scripts and applications can simply
>>> read the string right out of the file, or update it just
>>> by writing the string into that file.
>> I'm sure I'm following this analogy with the export...
>> but being able to set things up from one configuration 
>> file and command is key.
> 
> I find that to be a red herring. We're not ever going to be
> at a place where everything is configured in one file. Are
> you going to replace /etc/exports.d and automounter.conf
> and krb5.conf and all the other things with just /etc/nfs.conf?
Obviously not... and you for got /etc/idmapd.conf ;-) 
but I have thought about rolling nfsmount.conf into nfs.conf.
 
> Probably not. So let's stop using this strange logic to
> insist that /etc/nfs.conf is the only place for the clientid
> uniqifier.
Maybe this is splitting hairs... but the actual uniqifier does
exist in nfs.conf... Patches introduce a way to generate one
for nfs.conf. 

> 
> Please, let's just focus on what's right for this one setting.
> 
> 
>> nfsconf does an excellent job parsing nfs.conf and I would
>> like to build on that... 
> 
> Just because it is technically possible to save the uniqifier
> in /etc/nfs.conf doesn't mean that's what's best for our users.
> We're in better shape if we can guarantee that setting is
> correct and administrators can't break it.
Again... the id is not saved in nfs.conf... Just a couple
methods to generate one.

> 
> 
>> I understand we have to work well in containers which 
>> is one of the reason I was trying to come up with a
>> nfsv4 only nfs-utils... That went over like a lead balloon ;-)
> 
> I didn't have a problem with an nfsv4-only configuration.
> What I didn't like about that is that you were making the
> administrative interface more complex, and it didn't need to
> be.
I'm sure what you mean... but that is for another day 8-)

> 
> 
>> 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.
Again the id will end up in a different file... Trond
wants it in the sysfs filesystem verses the /etc/modprob.d/nfs.conf
file... Which is fine... 

To me this is sound more like a distro issue of how the
uniqifier is created and what should be used to create it
when nfs-utils is installed. 

steved.