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. 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.
