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.
