Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Benjamin Coddington <bcodding@redhat.com>
CC:     Steve Dickson <steved@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4
 client uniquifiers
Thread-Topic: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4
 client uniquifiers
Thread-Index: AQHYGca9ZpW/pPf5rEWUIwyc/qfEDKyJ14OAgAAE1wCAADSIgIAAHlWAgAAWowCAAorMAIAAH4+AgAAHOwCAAAqzgA==
Date:   Thu, 10 Feb 2022 16:25:41 +0000
Message-ID: <A9437272-D53D-4678-8FF9-50B87FE5F17A@oracle.com>
References: <c2e8b7c06352d3cad3454de096024fff80e638af.1643979161.git.bcodding@redhat.com>
 <6f01c382-8da5-5673-30db-0c0099d820b5@redhat.com>
 <33B10EBB-3DD1-45FE-B7D2-D5EA21DFB172@oracle.com>
 <839b09ed-fd21-bda1-0502-d7c6f1fa9e88@redhat.com>
 <32D8EBC9-652A-49D7-B763-A82E2AEF6282@oracle.com>
 <281b1976-9b40-fc53-301a-2846c2ead5aa@redhat.com>
 <13069AB1-28EB-43F6-83BF-41E9B9501C75@redhat.com>
 <10D2854A-310D-44DD-A31D-83385AD7D87C@oracle.com>
 <E0B72831-1575-41CC-BB61-752F9CD0367C@redhat.com>
In-Reply-To: <E0B72831-1575-41CC-BB61-752F9CD0367C@redhat.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ceof2lMTNX6wmk/gSFQ/GEFjJKfOEN1Ky/kpa90MxKtS/RzZZj9YBgCDkZtm?=
 =?us-ascii?Q?RkclWFsQIzW4UIQv5Y9TRolBU8zIknNNmtyeo+dKEfWMlo2GGsgKdVfKE8yl?=
 =?us-ascii?Q?wi6EGpG6zuY+nW5U3g5YfyQVJCq2mt5stAC09QVFosSmPjUEINhzOZO7COLr?=
 =?us-ascii?Q?wcUBvHpuqc/cOmjTZu3ZlnlwvQv8Bna6PY5xLy3CuPsE1Fyxd4rlcoVG3gAP?=
 =?us-ascii?Q?OgANFDkPof+SOg7TSlgXL2I56X/8q9VD9zBbpL7Z2YluLBmQ4CbHcqeZp6Qt?=
 =?us-ascii?Q?VRLXVTqO45bFdQQFzqUr8VOnlWRGHoXBpr6zPMKQbtDeb9J1f1GS+D1mN91a?=
 =?us-ascii?Q?hPuFD3AOfJKqzZKXOV5dkB5RQVcmhTi9aAmPPNMECc9YWxHu1Vf5vbhkfES7?=
 =?us-ascii?Q?lBsekvb5AKVLbJ4xc4+bnqAh0K0QAo5VR+RL1FmXaXvVEMC94xxxbnPs1gNw?=
 =?us-ascii?Q?GquZakgr76jB8heOGtI4SOZrgrpHasatXPoq3O5FMGMyD+98vUwaBUEEaKuS?=
 =?us-ascii?Q?xAA0zNfkOhSJDi18pnLhCIyXHWOVSaEDVsGkCmusvWCX3OSm9ojgdZ4kJ19d?=
 =?us-ascii?Q?/rQoX+o2omzjUfEOk2f7md1Xk/ZZf0Vor35keLnKaR/28BU3pOKM4XMjO/io?=
 =?us-ascii?Q?kIaUVW1al/azHqXuY7ZmfHvO8qPIhj2FWTCZICGDrUYaI2/FZblNay4SIm0c?=
 =?us-ascii?Q?rWuaKX/TxQ3u5/YesxamEaSWaNE+XjnEpMFBYa3Vye3GTYiFudf7HUfJW2wh?=
 =?us-ascii?Q?RkqX09tSNxv+RyHE4jCKlEWUz//x3p5cnMvfnjSh4S2PauSVNGQkmHpoDCor?=
 =?us-ascii?Q?8qVAi+6fhKzQHF9T8uD+5w34JYS0+ueALTUUj/pzzye6oypxGgyBMWcDjgzz?=
 =?us-ascii?Q?mwB4sjzVWiZ9pPiHxunpVei9Z50VzFCaCivodB+oxUKqxbSZA2z7Kiyjx/Ix?=
 =?us-ascii?Q?ckWN9MmpCmRIVTWy7lgku4I01LwDqx/+lZeWayl6hx1FooYu39eVRzpe0c33?=
 =?us-ascii?Q?gSUNFqP0XUWOk9IQdYufQud3NVDFAtEwuEXkLK5QCB4M2wd1c8ySp0XmgTmt?=
 =?us-ascii?Q?y2YxkLUklFEOcGuX2J1ybsmNC0FeQ1FFmZd0tReOi7yd9GqD1wY7Wge3QW1B?=
 =?us-ascii?Q?DwFZw3KOCfojOtoLbNaFv+zUaDzxIRAqFznqXwTWrOvMamEFaXo0FB+R618Q?=
 =?us-ascii?Q?zjiieEFIAqoVJObgxzu1K0e3bAP7kSE2wiLmJlCSSdSasD/oF21D52R3tgYb?=
 =?us-ascii?Q?0lWUiYPxwGFsuJ/XIu2O6TOaGmDqt90NIObAR2oNzIz+SMzbbTjK27R0HULa?=
 =?us-ascii?Q?DI/+Q3UmM+B3CRto5Vmwl0pN59EABaEBWP99VNeN2fj3cPqnCSzjEv/EbV3S?=
 =?us-ascii?Q?7stdsyhDAP4k37P7e7ZgM7VUYSXOf/baH8Kx7kQMPFyzYaiaf3/dFGnlHvXw?=
 =?us-ascii?Q?WLzjFYGmgig2cP2iz1o6cWrVvD/zxHzPd8wUVyCKIC4L0+QD8bjftpqwt1RF?=
 =?us-ascii?Q?sb8w/dMVscRmKB2GnA5EcbHa2bxabYp6s0hdfp/y/XLDqDV5fkb1sdLdZ6t1?=
 =?us-ascii?Q?lT3xTiZzkb6VtsgtLHbXxrxxYBlaTq5AxA1yb7MsYYIBY0yFHbr5DedG8fQq?=
 =?us-ascii?Q?ppTNYbZl5Avze6pclfJbnts=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5684309DDF54F54AA51ECD1FFABD0C46@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB4858.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7397fd5d-7eff-4101-c0ef-08d9ecb1fb39
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 16:25:41.7087
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: G33bYqWZhnI0PD98TyRSdMP5m7YrvYBXS7VdKFyp4bIK8vQYFoLAWwWxvudD/4m76vxn2nZmJrH9+BHfP/218A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4815
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10254 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 suspectscore=0
 mlxlogscore=999 mlxscore=0 adultscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202100086
X-Proofpoint-GUID: Eh_03JXExkhSyrtJVy-F30kJvQv-q3td
X-Proofpoint-ORIG-GUID: Eh_03JXExkhSyrtJVy-F30kJvQv-q3td
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Feb 10, 2022, at 10:47 AM, Benjamin Coddington <bcodding@redhat.com> w=
rote:
>=20
> On 10 Feb 2022, at 10:21, Chuck Lever III wrote:
>=20
>>> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington <bcodding@redhat.com> =
wrote:
>>>=20
>>> On 8 Feb 2022, at 17:39, Steve Dickson wrote:
>>>=20
>>>> On 2/8/22 4:18 PM, Chuck Lever III wrote:
>>>>>=20
>>>>>=20
>>>>>> On Feb 8, 2022, at 2:29 PM, Steve Dickson <steved@redhat.com> wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2/8/22 11:21 AM, Chuck Lever III wrote:
>>>>>>>> On Feb 8, 2022, at 11:04 AM, Steve Dickson <steved@redhat.com> wro=
te:
>>>>>>>>=20
>>>>>>>> Hello,
>>>>>>>>=20
>>>>>>>> On 2/4/22 7:56 AM, Benjamin Coddington wrote:
>>>>>>>>> The nfs4id program will either create a new UUID from a random so=
urce or
>>>>>>>>> derive it from /etc/machine-id, else it returns a UUID that has a=
lready
>>>>>>>>> been written to /etc/nfs4-id.  This small, lightweight tool is su=
itable for
>>>>>>>>> execution by systemd-udev in rules to populate the nfs4 client un=
iquifier.
>>>>>>>>> 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....
>>>>>>>>=20
>>>>>>>> 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.
>>>>>=20
>>>>> 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?
>>>>=20
>>>>>=20
>>>>> nfsclientid then?
>>>> You like to type more than I do... You always have... :-)
>>>>=20
>>>> 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
>>>=20
>>> 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.
>>>=20
>>> 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 tha=
t
>>> will generate a unique value, and persist it, suitable for execution in=
 a
>>> udevd rule.
>>>=20
>>> 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.
>>>=20
>>> And maybe the name can reflect that - "nfsuuid" ?
>>=20
>> The client ID can be an arbitrary string, so I think not.
>=20
> I feel like we might all be missing the fact that this tool doesn't creat=
e
> client IDs.  The tool only creates uuids, and returns what may have alrea=
dy
> been set by something somewhere else.  It's not supposed to ever get type=
d
> out or run by people.  Any other suggestions?

nfsgetclientid
nfsgenclientid


> Here's where we are:
>=20
> 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