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

["Benjamin Coddington" <bcodding@redhat.com>]

On 8 Feb 2022, at 17:39, Steve Dickson wrote:

> On 2/8/22 4:18 PM, Chuck Lever III wrote:
>>
>>
>>> On Feb 8, 2022, at 2:29 PM, Steve Dickson <steved@redhat.com> wrote:
>>>
>>>
>>>
>>> On 2/8/22 11:21 AM, Chuck Lever III wrote:
>>>>> On Feb 8, 2022, at 11:04 AM, Steve Dickson <steved@redhat.com> 
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> On 2/4/22 7:56 AM, Benjamin Coddington wrote:
>>>>>> The nfs4id program will either create a new UUID from a random 
>>>>>> source or
>>>>>> derive it from /etc/machine-id, else it returns a UUID that has 
>>>>>> already
>>>>>> been written to /etc/nfs4-id.  This small, lightweight tool is 
>>>>>> suitable for
>>>>>> execution by systemd-udev in rules to populate the nfs4 client 
>>>>>> uniquifier.
>>>>>> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>>>>>> ---
>>>>>>   .gitignore               |   1 +
>>>>>>   configure.ac             |   4 +
>>>>>>   tools/Makefile.am        |   1 +
>>>>>>   tools/nfs4id/Makefile.am |   8 ++
>>>>>>   tools/nfs4id/nfs4id.c    | 184 
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>>   tools/nfs4id/nfs4id.man  |  29 ++++++
>>>>>>   6 files changed, 227 insertions(+)
>>>>>>   create mode 100644 tools/nfs4id/Makefile.am
>>>>>>   create mode 100644 tools/nfs4id/nfs4id.c
>>>>>>   create mode 100644 tools/nfs4id/nfs4id.man
>>>>> Just a nit... naming convention... In the past
>>>>> we never put the protocol version in the name.
>>>>> Do a ls tools and utils directory and you
>>>>> see what I mean....
>>>>>
>>>>> Would it be a problem to change the name from
>>>>> nfs4id to nfsid?
>>>> nfs4id is pretty generic, too.
>>>> Can we go with nfs-client-id ?
>>> I'm never been big with putting '-'
>>> in command names... nfscltid would
>>> be better IMHO... if we actually
>>> need the 'clt' in the name.
>>
>> We have nfsidmap already. IMO we need some distinction
>> with user ID mapping tools... and some day we might
>> want to manage server IDs too (see EXCHANGE_ID).
> Hmm... So we could not use the same tool to do
> both the server and client, via flags?
>
>>
>> nfsclientid then?
> You like to type more than I do... You always have... :-)
>
> But like I started the conversation... the naming is
> a nit... but I would like to see one tool to set the
> ids for both the server and client... how about
> nfsid -s and nfsid -c

The tricky thing here is that this little binary isn't going to set
anything, and we probably never want people to run it from the command 
line.

A 'nfsid -s' and 'nfsid -c' seem to want to do much more.  I feel they 
are
out of scope for the problem I'm trying to solve:  I need something that
will generate a unique value, and persist it, suitable for execution in 
a
udevd rule.

Perhaps we can stop worrying so much about the name of this as I don't 
think
it should be a first-class nfs-utils command, rather just a helper for 
udev.

And maybe the name can reflect that - "nfsuuid" ?

Ben