> On Feb 10, 2022, at 10:47 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > > On 10 Feb 2022, at 10:21, Chuck Lever III wrote: > >>> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >>> >>> 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@xxxxxxxxxx> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 2/8/22 11:21 AM, Chuck Lever III wrote: >>>>>>>> On Feb 8, 2022, at 11:04 AM, Steve Dickson <steved@xxxxxxxxxx> 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@xxxxxxxxxx> >>>>>>>>> --- >>>>>>>>> .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" ? >> >> The client ID can be an arbitrary string, so I think not. > > I feel like we might all be missing the fact that this tool doesn't create > client IDs. The tool only creates uuids, and returns what may have already > been set by something somewhere else. It's not supposed to ever get typed > out or run by people. Any other suggestions? nfsgetclientid nfsgenclientid > Here's where we are: > > nfs4id - no: we dislike the number 4 > nfsuuid - no: it doesn't have to be a uuid > nfsid - no: too ambiguous > nfscltid - no: also too ambiguous > nfsclientid - no: too much typing Since this is not a tool that is meant to be run by humans, I'm not sure why "too much typing" is a reasonable objection. I think we need a name that, when a human reads it in the udev rule, immediately reflects the purpose of the tool. The tool's name is documentation. > Since I've already re-written it, I'm going to send it again as nfsuuid - > and let's bikeshed on it again over there, and see if we can make > suggestions that might make everyone happy. Since you asked above for other suggestions, I responded here. I'll try really hard not to respond again in this thread :-) -- Chuck Lever
