All of lore.kernel.org
 help / color / mirror / Atom feed
* [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
@ 2022-02-04 12:56 Benjamin Coddington
  2022-02-04 15:17 ` Chuck Lever III
  2022-02-08 16:04 ` Steve Dickson
  0 siblings, 2 replies; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-04 12:56 UTC (permalink / raw)
  To: Steve Dickson; +Cc: linux-nfs

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

diff --git a/.gitignore b/.gitignore
index c89d1cd2583d..a37964148dd8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -61,6 +61,7 @@ utils/statd/statd
 tools/locktest/testlk
 tools/getiversion/getiversion
 tools/nfsconf/nfsconf
+tools/nfs4id/nfs4id
 support/export/mount.h
 support/export/mount_clnt.c
 support/export/mount_xdr.c
diff --git a/configure.ac b/configure.ac
index 50e9b321dcf3..93d0a902cfd8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
   dnl check for the keyutils libraries and headers
   AC_KEYUTILS
 
+  dnl check for the libuuid library and headers
+  AC_LIBUUID
+
   dnl Check for sqlite3
   AC_SQLITE3_VERS
 
@@ -740,6 +743,7 @@ AC_CONFIG_FILES([
 	tools/nfsdclnts/Makefile
 	tools/nfsconf/Makefile
 	tools/nfsdclddb/Makefile
+	tools/nfs4id/Makefile
 	utils/Makefile
 	utils/blkmapd/Makefile
 	utils/nfsdcld/Makefile
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 9b4b0803db39..cc658f69bb32 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -7,6 +7,7 @@ OPTDIRS += rpcgen
 endif
 
 OPTDIRS += nfsconf
+OPTDIRS += nfs4id
 
 if CONFIG_NFSDCLD
 OPTDIRS += nfsdclddb
diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
new file mode 100644
index 000000000000..d1e60a35a510
--- /dev/null
+++ b/tools/nfs4id/Makefile.am
@@ -0,0 +1,8 @@
+## Process this file with automake to produce Makefile.in
+
+man8_MANS	= nfs4id.man
+
+bin_PROGRAMS = nfs4id
+
+nfs4id_SOURCES = nfs4id.c
+nfs4id_LDADD = $(LIBUUID)
diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
new file mode 100644
index 000000000000..dbb807ae21f3
--- /dev/null
+++ b/tools/nfs4id/nfs4id.c
@@ -0,0 +1,184 @@
+/*
+ * nfs4id.c -- create and persist uniquifiers for nfs4 clients
+ *
+ * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+ */
+
+#include <stdio.h>
+#include <stdarg.h>
+#include <getopt.h>
+#include <string.h>
+#include <errno.h>
+#include <stdlib.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <uuid/uuid.h>
+
+#define NFS4IDFILE "/etc/nfs4-id"
+
+UUID_DEFINE(nfs4_clientid_uuid_template,
+	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
+	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
+
+static char *prog;
+static char *source = NULL;
+static char nfs4_id[64];
+static int force = 0;
+
+static void usage(void)
+{
+	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
+}
+
+static void fatal(const char *fmt, ...)
+{
+	int err = errno;
+	va_list args;
+	char fatal_msg[256] = "fatal: ";
+
+	va_start(args, fmt);
+	vsnprintf(&fatal_msg[7], 255, fmt, args);
+	if (err)
+		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
+	else
+		fprintf(stderr, "%s\n", fatal_msg);
+	exit(-1);
+}
+
+static int read_nfs4_id(void)
+{
+	int fd;
+
+	fd = open(NFS4IDFILE, O_RDONLY);
+	if (fd < 0)
+		return fd;
+	read(fd, nfs4_id, 64);
+	close(fd);
+	return 0;
+}
+
+static void write_nfs4_id(void)
+{
+	int fd;
+
+	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
+	if (fd < 0)
+		fatal("could not write id to " NFS4IDFILE);
+	write(fd, nfs4_id, 37);
+}
+
+static void print_nfs4_id(void)
+{
+	fprintf(stdout, "%s", nfs4_id);
+}
+	
+static void check_or_make_id(void)
+{
+	int ret;
+	uuid_t nfs4id_uuid;
+
+	ret = read_nfs4_id();
+	if (ret != 0) {
+		if (errno != ENOENT )
+			fatal("reading file " NFS4IDFILE);
+		uuid_generate_random(nfs4id_uuid);
+		uuid_unparse(nfs4id_uuid, nfs4_id);
+		nfs4_id[36] = '\n';
+		nfs4_id[37] = '\0';
+		write_nfs4_id();
+	}
+	print_nfs4_id();	
+}
+
+static void check_or_make_id_from_machine(void)
+{
+	int fd, ret;
+	char machineid[32];
+	uuid_t nfs4id_uuid;
+
+	ret = read_nfs4_id();
+	if (ret != 0) {
+		if (errno != ENOENT )
+			fatal("reading file " NFS4IDFILE);
+
+		fd = open("/etc/machine-id", O_RDONLY);
+		if (fd < 0)
+			fatal("unable to read /etc/machine-id");
+
+		read(fd, machineid, 32);
+		close(fd);
+
+		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
+		uuid_unparse(nfs4id_uuid, nfs4_id);
+		nfs4_id[36] = '\n';
+		nfs4_id[37] = '\0';
+		write_nfs4_id();
+	}
+	print_nfs4_id();
+}
+
+int main(int argc, char **argv)
+{
+	prog = argv[0];
+
+	while (1) {
+		int opt;
+		int option_index = 0;
+		static struct option long_options[] = {
+			{"force",	no_argument,	0, 'f' },
+			{0,			0,				0, 0 }
+		};
+
+		errno = 0;
+		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
+		if (opt == -1)
+			break;
+
+		switch (opt) {
+		case 'f':
+			force = 1;
+			break;
+		case '?':
+			usage();
+			fatal("unexpected arg \"%s\"", argv[optind - 1]);
+			break;
+		}
+	}
+
+	argc -= optind;
+
+	if (argc > 1) {
+		usage();
+		fatal("Too many arguments");
+	}
+
+	if (argc)
+		source = argv[optind++];
+
+	if (force)
+		unlink(NFS4IDFILE);
+
+	if (!source)
+		check_or_make_id();
+	else if (strcmp(source, "machine") == 0)
+		check_or_make_id_from_machine();
+	else {
+		usage();
+		fatal("unrecognized source %s\n", source);
+	}
+}
diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
new file mode 100644
index 000000000000..358f836468a2
--- /dev/null
+++ b/tools/nfs4id/nfs4id.man
@@ -0,0 +1,29 @@
+.\"
+.\" nfs4id(8)
+.\"
+.TH nfs4id 8 "3 Feb 2022"
+.SH NAME
+nfs4id \- Generate or return nfs4 client id uniqueifiers
+.SH SYNOPSIS
+.B nfs4id [ -f | --force ] [<source>]
+
+.SH DESCRIPTION
+The
+.B nfs4id
+command provides a simple utility to help NFS Version 4 clients use unique
+and persistent client id values.  The command checks for the existence of a
+file /etc/nfs4-id and returns the first 64 chars read from that file.  If
+the file is not found, a UUID is generated from the specified source and
+written to the file and returned.
+.SH OPTIONS
+.TP
+.BR \-f, \-\-force
+Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
+.SH Sources
+If <source> is not specified, nfs4id will generate a new random UUID.
+
+If <source> is "machine", nfs4id will generate a deterministic UUID value
+derived from a sha1 hash of the contents of /etc/machine-id and a static
+key.
+.SH SEE ALSO
+.BR machine-id (5)
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 12:56 [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers Benjamin Coddington
@ 2022-02-04 15:17 ` Chuck Lever III
  2022-02-04 15:49   ` Benjamin Coddington
  2022-02-08 16:04 ` Steve Dickson
  1 sibling, 1 reply; 33+ messages in thread
From: Chuck Lever III @ 2022-02-04 15:17 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Steve Dickson, Linux NFS Mailing List

Hi Ben-

> On Feb 4, 2022, at 7:56 AM, Benjamin Coddington <bcodding@redhat.com> 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.

Glad to see some progress here!

Regarding the generation of these uniquifiers:

If you have a UUID generation mechanism, why bother with machine-id at all?

As noted in bugzilla@redhat 1801326, these uniquifiers will appear in the
clear on open networks (and we all know open network deployments are common
for NFS). I don't believe that TLS or GSS Kerberos will be available to
protect every deployment from a network MitM from sniffing these values and
attempting to make some hay with them. In particular, any deployment of a
system before we have in-transit NFS encryption implemented will be
vulnerable.

Some young punk from Tatooine could drop a bomb down our reactor shaft,
and then where would we be?


Regarding the storage of these uniquifiers:

As discussed in earlier threads, we believe that storing multiple unique-ids
in one file, especially without locking to prevent tearing of data in the
file, is problematic. Now, it might be that the objection to this was based
on storing these in a file that can simultaneously be edited by humans
(ie, /etc/nfs.conf). But I would prefer to see a separate file used for
each uniquifier / network namespace.


> 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
> 
> diff --git a/.gitignore b/.gitignore
> index c89d1cd2583d..a37964148dd8 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -61,6 +61,7 @@ utils/statd/statd
> tools/locktest/testlk
> tools/getiversion/getiversion
> tools/nfsconf/nfsconf
> +tools/nfs4id/nfs4id
> support/export/mount.h
> support/export/mount_clnt.c
> support/export/mount_xdr.c
> diff --git a/configure.ac b/configure.ac
> index 50e9b321dcf3..93d0a902cfd8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
>   dnl check for the keyutils libraries and headers
>   AC_KEYUTILS
> 
> +  dnl check for the libuuid library and headers
> +  AC_LIBUUID
> +
>   dnl Check for sqlite3
>   AC_SQLITE3_VERS
> 
> @@ -740,6 +743,7 @@ AC_CONFIG_FILES([
> 	tools/nfsdclnts/Makefile
> 	tools/nfsconf/Makefile
> 	tools/nfsdclddb/Makefile
> +	tools/nfs4id/Makefile
> 	utils/Makefile
> 	utils/blkmapd/Makefile
> 	utils/nfsdcld/Makefile
> diff --git a/tools/Makefile.am b/tools/Makefile.am
> index 9b4b0803db39..cc658f69bb32 100644
> --- a/tools/Makefile.am
> +++ b/tools/Makefile.am
> @@ -7,6 +7,7 @@ OPTDIRS += rpcgen
> endif
> 
> OPTDIRS += nfsconf
> +OPTDIRS += nfs4id
> 
> if CONFIG_NFSDCLD
> OPTDIRS += nfsdclddb
> diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
> new file mode 100644
> index 000000000000..d1e60a35a510
> --- /dev/null
> +++ b/tools/nfs4id/Makefile.am
> @@ -0,0 +1,8 @@
> +## Process this file with automake to produce Makefile.in
> +
> +man8_MANS	= nfs4id.man
> +
> +bin_PROGRAMS = nfs4id
> +
> +nfs4id_SOURCES = nfs4id.c
> +nfs4id_LDADD = $(LIBUUID)
> diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
> new file mode 100644
> index 000000000000..dbb807ae21f3
> --- /dev/null
> +++ b/tools/nfs4id/nfs4id.c
> @@ -0,0 +1,184 @@
> +/*
> + * nfs4id.c -- create and persist uniquifiers for nfs4 clients
> + *
> + * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
> + * Boston, MA 02110-1301, USA.
> + */
> +
> +#include <stdio.h>
> +#include <stdarg.h>
> +#include <getopt.h>
> +#include <string.h>
> +#include <errno.h>
> +#include <stdlib.h>
> +#include <fcntl.h>
> +#include <unistd.h>
> +#include <uuid/uuid.h>
> +
> +#define NFS4IDFILE "/etc/nfs4-id"
> +
> +UUID_DEFINE(nfs4_clientid_uuid_template,
> +	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
> +	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
> +
> +static char *prog;
> +static char *source = NULL;
> +static char nfs4_id[64];
> +static int force = 0;
> +
> +static void usage(void)
> +{
> +	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
> +}
> +
> +static void fatal(const char *fmt, ...)
> +{
> +	int err = errno;
> +	va_list args;
> +	char fatal_msg[256] = "fatal: ";
> +
> +	va_start(args, fmt);
> +	vsnprintf(&fatal_msg[7], 255, fmt, args);
> +	if (err)
> +		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
> +	else
> +		fprintf(stderr, "%s\n", fatal_msg);
> +	exit(-1);
> +}
> +
> +static int read_nfs4_id(void)
> +{
> +	int fd;
> +
> +	fd = open(NFS4IDFILE, O_RDONLY);
> +	if (fd < 0)
> +		return fd;
> +	read(fd, nfs4_id, 64);
> +	close(fd);
> +	return 0;
> +}
> +
> +static void write_nfs4_id(void)
> +{
> +	int fd;
> +
> +	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
> +	if (fd < 0)
> +		fatal("could not write id to " NFS4IDFILE);
> +	write(fd, nfs4_id, 37);
> +}
> +
> +static void print_nfs4_id(void)
> +{
> +	fprintf(stdout, "%s", nfs4_id);
> +}
> +	
> +static void check_or_make_id(void)
> +{
> +	int ret;
> +	uuid_t nfs4id_uuid;
> +
> +	ret = read_nfs4_id();
> +	if (ret != 0) {
> +		if (errno != ENOENT )
> +			fatal("reading file " NFS4IDFILE);
> +		uuid_generate_random(nfs4id_uuid);
> +		uuid_unparse(nfs4id_uuid, nfs4_id);
> +		nfs4_id[36] = '\n';
> +		nfs4_id[37] = '\0';
> +		write_nfs4_id();
> +	}
> +	print_nfs4_id();	
> +}
> +
> +static void check_or_make_id_from_machine(void)
> +{
> +	int fd, ret;
> +	char machineid[32];
> +	uuid_t nfs4id_uuid;
> +
> +	ret = read_nfs4_id();
> +	if (ret != 0) {
> +		if (errno != ENOENT )
> +			fatal("reading file " NFS4IDFILE);
> +
> +		fd = open("/etc/machine-id", O_RDONLY);
> +		if (fd < 0)
> +			fatal("unable to read /etc/machine-id");
> +
> +		read(fd, machineid, 32);
> +		close(fd);
> +
> +		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
> +		uuid_unparse(nfs4id_uuid, nfs4_id);
> +		nfs4_id[36] = '\n';
> +		nfs4_id[37] = '\0';
> +		write_nfs4_id();
> +	}
> +	print_nfs4_id();
> +}
> +
> +int main(int argc, char **argv)
> +{
> +	prog = argv[0];
> +
> +	while (1) {
> +		int opt;
> +		int option_index = 0;
> +		static struct option long_options[] = {
> +			{"force",	no_argument,	0, 'f' },
> +			{0,			0,				0, 0 }
> +		};
> +
> +		errno = 0;
> +		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
> +		if (opt == -1)
> +			break;
> +
> +		switch (opt) {
> +		case 'f':
> +			force = 1;
> +			break;
> +		case '?':
> +			usage();
> +			fatal("unexpected arg \"%s\"", argv[optind - 1]);
> +			break;
> +		}
> +	}
> +
> +	argc -= optind;
> +
> +	if (argc > 1) {
> +		usage();
> +		fatal("Too many arguments");
> +	}
> +
> +	if (argc)
> +		source = argv[optind++];
> +
> +	if (force)
> +		unlink(NFS4IDFILE);
> +
> +	if (!source)
> +		check_or_make_id();
> +	else if (strcmp(source, "machine") == 0)
> +		check_or_make_id_from_machine();
> +	else {
> +		usage();
> +		fatal("unrecognized source %s\n", source);
> +	}
> +}
> diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
> new file mode 100644
> index 000000000000..358f836468a2
> --- /dev/null
> +++ b/tools/nfs4id/nfs4id.man
> @@ -0,0 +1,29 @@
> +.\"
> +.\" nfs4id(8)
> +.\"
> +.TH nfs4id 8 "3 Feb 2022"
> +.SH NAME
> +nfs4id \- Generate or return nfs4 client id uniqueifiers
> +.SH SYNOPSIS
> +.B nfs4id [ -f | --force ] [<source>]
> +
> +.SH DESCRIPTION
> +The
> +.B nfs4id
> +command provides a simple utility to help NFS Version 4 clients use unique
> +and persistent client id values.  The command checks for the existence of a
> +file /etc/nfs4-id and returns the first 64 chars read from that file.  If
> +the file is not found, a UUID is generated from the specified source and
> +written to the file and returned.
> +.SH OPTIONS
> +.TP
> +.BR \-f, \-\-force
> +Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
> +.SH Sources
> +If <source> is not specified, nfs4id will generate a new random UUID.
> +
> +If <source> is "machine", nfs4id will generate a deterministic UUID value
> +derived from a sha1 hash of the contents of /etc/machine-id and a static
> +key.
> +.SH SEE ALSO
> +.BR machine-id (5)
> -- 
> 2.31.1
> 

--
Chuck Lever




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 15:17 ` Chuck Lever III
@ 2022-02-04 15:49   ` Benjamin Coddington
  2022-02-04 18:45     ` Chuck Lever III
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-04 15:49 UTC (permalink / raw)
  To: Chuck Lever III; +Cc: Steve Dickson, Linux NFS Mailing List

On 4 Feb 2022, at 10:17, Chuck Lever III wrote:

> Hi Ben-
>
>> On Feb 4, 2022, at 7:56 AM, Benjamin Coddington <bcodding@redhat.com> 
>> 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.
>
> Glad to see some progress here!
>
> Regarding the generation of these uniquifiers:
>
> If you have a UUID generation mechanism, why bother with machine-id at 
> all?

We'd like to deterministically tie our clients to /etc/machine-id for a 
number
of reasons:

  - it condenses the work of "uniquifying" a machine to a single point 
in
    the distro.

  - the machine-id has a number of ways to handle cases where machines 
are
    PXE-booted, cloned, or used as "golden images" for cloud containers 
(See
    machine-id(5)).

  - the machine-id has good documentation and awareness (See sd-id128(3) 
and
    friends)

> As noted in bugzilla@redhat 1801326, these uniquifiers will appear in 
> the
> clear on open networks (and we all know open network deployments are 
> common
> for NFS). I don't believe that TLS or GSS Kerberos will be available 
> to
> protect every deployment from a network MitM from sniffing these 
> values and
> attempting to make some hay with them. In particular, any deployment 
> of a
> system before we have in-transit NFS encryption implemented will be
> vulnerable.

Yes.

> Some young punk from Tatooine could drop a bomb down our reactor 
> shaft,
> and then where would we be?

This little tool isn't attempting to solve any of those problems.

> Regarding the storage of these uniquifiers:
>
> As discussed in earlier threads, we believe that storing multiple 
> unique-ids
> in one file, especially without locking to prevent tearing of data in 
> the
> file, is problematic. Now, it might be that the objection to this was 
> based
> on storing these in a file that can simultaneously be edited by humans
> (ie, /etc/nfs.conf). But I would prefer to see a separate file used 
> for
> each uniquifier / network namespace.

This tool isn't trying to store uniquifiers for multiple namespaces, or
describe how it ought to be used in relation to namespaces.  It only
attempts to create a fairly persistent unique value that can be 
generated
and consumed from a udev rule.

I think the problem of how to create uniquifiers for every net namespace
might easily be solved by bind-mounding /etc/nfs4-id into the
namespace-specific filesystem, or a number of other ways.  That would be 
an
interesting new topic.  New sources could be added to this tool in the
future that are namespace-aware.

Thanks for the look at this!

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 15:49   ` Benjamin Coddington
@ 2022-02-04 18:45     ` Chuck Lever III
  2022-02-04 19:44       ` Benjamin Coddington
  2022-02-08  3:14       ` NeilBrown
  0 siblings, 2 replies; 33+ messages in thread
From: Chuck Lever III @ 2022-02-04 18:45 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Steve Dickson, Linux NFS Mailing List


> On Feb 4, 2022, at 10:49 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
> 
> On 4 Feb 2022, at 10:17, Chuck Lever III wrote:
> 
>> As discussed in earlier threads, we believe that storing multiple unique-ids
>> in one file, especially without locking to prevent tearing of data in the
>> file, is problematic. Now, it might be that the objection to this was based
>> on storing these in a file that can simultaneously be edited by humans
>> (ie, /etc/nfs.conf). But I would prefer to see a separate file used for
>> each uniquifier / network namespace.
> 
> This tool isn't trying to store uniquifiers for multiple namespaces, or
> describe how it ought to be used in relation to namespaces.  It only
> attempts to create a fairly persistent unique value that can be generated
> and consumed from a udev rule.
> 
> I think the problem of how to create uniquifiers for every net namespace
> might easily be solved by bind-mounding /etc/nfs4-id into the
> namespace-specific filesystem, or a number of other ways.  That would be an
> interesting new topic.

I don't think that's a new topic at all. This mechanism needs to
deal with containers properly from day one. That's why we are
using a udev rule for this purpose in the first place instead of
something more obvious.

The problem is that a network namespace (to which the persistent
uniquifier is attached) and an FS namespace (in which the persistent
uniquifier is stored) are created and managed independently.

We need to agree on how NFSv4 clients in containers are to be
supported before the proposed tool can be evaluated fully.


--
Chuck Lever




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 18:45     ` Chuck Lever III
@ 2022-02-04 19:44       ` Benjamin Coddington
  2022-02-05 17:35         ` Chuck Lever III
  2022-02-08  3:14       ` NeilBrown
  1 sibling, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-04 19:44 UTC (permalink / raw)
  To: Chuck Lever III; +Cc: Steve Dickson, Linux NFS Mailing List

On 4 Feb 2022, at 13:45, Chuck Lever III wrote:

>> On Feb 4, 2022, at 10:49 AM, Benjamin Coddington 
>> <bcodding@redhat.com> wrote:
>>
>> On 4 Feb 2022, at 10:17, Chuck Lever III wrote:
>>
>>> As discussed in earlier threads, we believe that storing multiple 
>>> unique-ids
>>> in one file, especially without locking to prevent tearing of data 
>>> in the
>>> file, is problematic. Now, it might be that the objection to this 
>>> was based
>>> on storing these in a file that can simultaneously be edited by 
>>> humans
>>> (ie, /etc/nfs.conf). But I would prefer to see a separate file used 
>>> for
>>> each uniquifier / network namespace.
>>
>> This tool isn't trying to store uniquifiers for multiple namespaces, 
>> or
>> describe how it ought to be used in relation to namespaces.  It only
>> attempts to create a fairly persistent unique value that can be 
>> generated
>> and consumed from a udev rule.
>>
>> I think the problem of how to create uniquifiers for every net 
>> namespace
>> might easily be solved by bind-mounding /etc/nfs4-id into the
>> namespace-specific filesystem, or a number of other ways.  That would 
>> be an
>> interesting new topic.
>
> I don't think that's a new topic at all. This mechanism needs to
> deal with containers properly from day one. That's why we are
> using a udev rule for this purpose in the first place instead of
> something more obvious.

This isn't a mechanism to deal with containers, its a small helper 
utility
that we'd like to use to solve an existing, non-container problem in a 
way
that's future-proof for containers.

> The problem is that a network namespace (to which the persistent
> uniquifier is attached) and an FS namespace (in which the persistent
> uniquifier is stored) are created and managed independently.
>
> We need to agree on how NFSv4 clients in containers are to be
> supported before the proposed tool can be evaluated fully.

I disagree.  This tool is immediately useful when I have multiple NAT-ed 
NFS
clients with the same hostnames and they end up with identical NFS 
client
identifiers.  That's the problem this little utility helps to solve, and
that's the real-world issue we've been asked to fix.

I don't think we have to solve all the problems at once, and I think 
this is
headed in the right direction.  I can commit to working on the namespace
part.. but there's a number of things that aren't clear to me there:

  - is udev namespace-aware?

  - can we get udev rules to trigger for a namespace (my simple tests 
show
    that my "root" system-udevd doesnt see the creation or entry of 
processes
    into a new network namespace)  Maybe we need to run udevd in every
    network namespace?

  - can uniquifiers be network-namespace uniquified by just using 
information
    available within a udev rule, or do we really need this utility to 
be
    namespace aware?

There's a bunch of stuff to discuss and figure out (unless someone else
already has), maybe we can start a new thread?

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 19:44       ` Benjamin Coddington
@ 2022-02-05 17:35         ` Chuck Lever III
  0 siblings, 0 replies; 33+ messages in thread
From: Chuck Lever III @ 2022-02-05 17:35 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Steve Dickson, Linux NFS Mailing List



> On Feb 4, 2022, at 2:44 PM, Benjamin Coddington <bcodding@redhat.com> wrote:
> 
> On 4 Feb 2022, at 13:45, Chuck Lever III wrote:
> 
>>> On Feb 4, 2022, at 10:49 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
>>> 
>>> On 4 Feb 2022, at 10:17, Chuck Lever III wrote:
>>> 
>>>> As discussed in earlier threads, we believe that storing multiple unique-ids
>>>> in one file, especially without locking to prevent tearing of data in the
>>>> file, is problematic. Now, it might be that the objection to this was based
>>>> on storing these in a file that can simultaneously be edited by humans
>>>> (ie, /etc/nfs.conf). But I would prefer to see a separate file used for
>>>> each uniquifier / network namespace.
>>> 
>>> This tool isn't trying to store uniquifiers for multiple namespaces, or
>>> describe how it ought to be used in relation to namespaces.  It only
>>> attempts to create a fairly persistent unique value that can be generated
>>> and consumed from a udev rule.
>>> 
>>> I think the problem of how to create uniquifiers for every net namespace
>>> might easily be solved by bind-mounding /etc/nfs4-id into the
>>> namespace-specific filesystem, or a number of other ways.  That would be an
>>> interesting new topic.
>> 
>> I don't think that's a new topic at all. This mechanism needs to
>> deal with containers properly from day one. That's why we are
>> using a udev rule for this purpose in the first place instead of
>> something more obvious.
> 
> This isn't a mechanism to deal with containers, its a small helper utility
> that we'd like to use to solve an existing, non-container problem in a way
> that's future-proof for containers.

I understand that it doesn't support containers. I also understand
that the uniquifier issue is a nagging and ongoing problem that
needs to be rectified as soon as possible. I'm not pushing back
on this without (good) reason, and I will try to be as helpful
as I can to move this forward.

I don't believe the solution to this problem is complete unless
it deals with containers. I fear that the simpler non-container
solution will be merged and then we will all put our pencils
down and never deal properly with NFSv4 in containers. Or, that
we will get farther down the road and discover that the simple
solution has painted us into a corner, and significant visible
changes will be necessary to get proper container support. (This
viewpoint is based on watching other subsystems attempt to go
from single instance to container support).

I'd like to have some confidence that neither of those things
will happen, and I don't think it will take a lot more effort
to see that this is a proper and complete solution. To be
absolutely clear, I want to see this issue resolved, but
without adding more long-term to-dos or other issues hanging
over our heads.


>> The problem is that a network namespace (to which the persistent
>> uniquifier is attached) and an FS namespace (in which the persistent
>> uniquifier is stored) are created and managed independently.
>> 
>> We need to agree on how NFSv4 clients in containers are to be
>> supported before the proposed tool can be evaluated fully.
> 
> I disagree.  This tool is immediately useful when I have multiple NAT-ed NFS
> clients with the same hostnames and they end up with identical NFS client
> identifiers.  That's the problem this little utility helps to solve, and
> that's the real-world issue we've been asked to fix.

The real-world problem is linked to the container issue whether
Red Hat likes it or not. Upstream we have to think about the
larger issues.

Again, I do understand the narrower scope of your bugzilla /
enhancement request. Yes, your proposal addresses the narrowly
defined issue, but I'm concerned that it will introduce long-
term problems.


> I don't think we have to solve all the problems at once, and I think this is
> headed in the right direction.

This is the best solution I've seen so far, but it needs a
little more design thinking IMHO. Like earlier proposals,
there is still a possibility that significant and visible
changes will be necessary to convert from single instance
systems to containers.

I'd really really like to avoid that, and I believe our
users would also appreciate it.


> I can commit to working on the namespace part..

I very much appreciate your effort.


> but there's a number of things that aren't clear to me there:
> 
> - is udev namespace-aware?

I thought that it was. That was supposed to be the reason
Trond went with a udev rule mechanism. The rule is supposed
to fire when each network namespace is created.


> - can we get udev rules to trigger for a namespace (my simple tests show
>   that my "root" system-udevd doesnt see the creation or entry of processes
>   into a new network namespace)  Maybe we need to run udevd in every
>   network namespace?
> 
> - can uniquifiers be network-namespace uniquified by just using information
>   available within a udev rule, or do we really need this utility to be
>   namespace aware?

I thought that was how this mechanism was supposed to work. I
believe Trond even posted an example rule at some point in the
past.


> There's a bunch of stuff to discuss and figure out (unless someone else
> already has), maybe we can start a new thread?

Since neither of us is 100% certain, can you find a container
or udev expert inside of Red Hat who can give some guidance?


--
Chuck Lever




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 18:45     ` Chuck Lever III
  2022-02-04 19:44       ` Benjamin Coddington
@ 2022-02-08  3:14       ` NeilBrown
  2022-02-08 11:43         ` Benjamin Coddington
  1 sibling, 1 reply; 33+ messages in thread
From: NeilBrown @ 2022-02-08  3:14 UTC (permalink / raw)
  To: Chuck Lever III
  Cc: Benjamin Coddington, Steve Dickson, Linux NFS Mailing List

On Sat, 05 Feb 2022, Chuck Lever III wrote:
> 
> The problem is that a network namespace (to which the persistent
> uniquifier is attached) and an FS namespace (in which the persistent
> uniquifier is stored) are created and managed independently.

Not necessarily ....  at least: network namespaces do have visibility in
the filesystem and you can have files that associate with a specific
network namespace - without depending on FS namespaces.

"man ip-netns" tells us that when a tool (e.g.  mount.nfs) is
network-namespace aware, it should first look in /etc/netns/NAME/
before looking in /etc/ for any config file.
The tool can determine "NAME" by running "ip netns identify", but there
is bound to library code to achieve the same effect.
You stat /proc/self/ns/net, then readdir /run/netns and stat everything
in there until you find something that matches /proc/self/ns/net

If a container management system wants to put /etc/ elsewhere, it can
doubtlessly install a symlink in /etc/netns/NAME, and as this is an
established standard, it seems likely that they already do.

So: enhance nfs-utils config code to (optionally) look in
/etc/netns/NAME first (or maybe last if they are to override) , and
store the identity in /etc/{netns/NAME/}nfs.conf.d/identity.conf

Whatever tool creates the identity, writes it to
  /etc/netns/NAME/nfs.conf.d/identity.conf

While we are at it, we should get exportfs to look there too, and
establish some convention so /var/lib/nfs can use a different path in
different network namespaces.

Thanks,
NeilBrown


> 
> We need to agree on how NFSv4 clients in containers are to be
> supported before the proposed tool can be evaluated fully.
> 
> 
> --
> Chuck Lever
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08  3:14       ` NeilBrown
@ 2022-02-08 11:43         ` Benjamin Coddington
  0 siblings, 0 replies; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-08 11:43 UTC (permalink / raw)
  To: NeilBrown; +Cc: Chuck Lever III, Steve Dickson, Linux NFS Mailing List

On 7 Feb 2022, at 22:14, NeilBrown wrote:

> On Sat, 05 Feb 2022, Chuck Lever III wrote:
>>
>> The problem is that a network namespace (to which the persistent
>> uniquifier is attached) and an FS namespace (in which the persistent
>> uniquifier is stored) are created and managed independently.
>
> Not necessarily ....  at least: network namespaces do have visibility in
> the filesystem and you can have files that associate with a specific
> network namespace - without depending on FS namespaces.
>
> "man ip-netns" tells us that when a tool (e.g.  mount.nfs) is
> network-namespace aware, it should first look in /etc/netns/NAME/
> before looking in /etc/ for any config file.
> The tool can determine "NAME" by running "ip netns identify", but there
> is bound to library code to achieve the same effect.
> You stat /proc/self/ns/net, then readdir /run/netns and stat everything
> in there until you find something that matches /proc/self/ns/net
>
> If a container management system wants to put /etc/ elsewhere, it can
> doubtlessly install a symlink in /etc/netns/NAME, and as this is an
> established standard, it seems likely that they already do.
>
> So: enhance nfs-utils config code to (optionally) look in
> /etc/netns/NAME first (or maybe last if they are to override) , and
> store the identity in /etc/{netns/NAME/}nfs.conf.d/identity.conf
>
> Whatever tool creates the identity, writes it to
>   /etc/netns/NAME/nfs.conf.d/identity.conf
>
> While we are at it, we should get exportfs to look there too, and
> establish some convention so /var/lib/nfs can use a different path in
> different network namespaces.

Thanks! This is extremely helpful.

I can modify nfs4id to check if it has been invoked within a network
namespace, then then check and store uuids in /etc/netns/NAME first.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-04 12:56 [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers Benjamin Coddington
  2022-02-04 15:17 ` Chuck Lever III
@ 2022-02-08 16:04 ` Steve Dickson
  2022-02-08 16:21   ` Chuck Lever III
  2022-02-08 16:22   ` Benjamin Coddington
  1 sibling, 2 replies; 33+ messages in thread
From: Steve Dickson @ 2022-02-08 16:04 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: linux-nfs

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?

steved.

> 
> diff --git a/.gitignore b/.gitignore
> index c89d1cd2583d..a37964148dd8 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -61,6 +61,7 @@ utils/statd/statd
>   tools/locktest/testlk
>   tools/getiversion/getiversion
>   tools/nfsconf/nfsconf
> +tools/nfs4id/nfs4id
>   support/export/mount.h
>   support/export/mount_clnt.c
>   support/export/mount_xdr.c
> diff --git a/configure.ac b/configure.ac
> index 50e9b321dcf3..93d0a902cfd8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
>     dnl check for the keyutils libraries and headers
>     AC_KEYUTILS
>   
> +  dnl check for the libuuid library and headers
> +  AC_LIBUUID
> +
>     dnl Check for sqlite3
>     AC_SQLITE3_VERS
>   
> @@ -740,6 +743,7 @@ AC_CONFIG_FILES([
>   	tools/nfsdclnts/Makefile
>   	tools/nfsconf/Makefile
>   	tools/nfsdclddb/Makefile
> +	tools/nfs4id/Makefile
>   	utils/Makefile
>   	utils/blkmapd/Makefile
>   	utils/nfsdcld/Makefile
> diff --git a/tools/Makefile.am b/tools/Makefile.am
> index 9b4b0803db39..cc658f69bb32 100644
> --- a/tools/Makefile.am
> +++ b/tools/Makefile.am
> @@ -7,6 +7,7 @@ OPTDIRS += rpcgen
>   endif
>   
>   OPTDIRS += nfsconf
> +OPTDIRS += nfs4id
>   
>   if CONFIG_NFSDCLD
>   OPTDIRS += nfsdclddb
> diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
> new file mode 100644
> index 000000000000..d1e60a35a510
> --- /dev/null
> +++ b/tools/nfs4id/Makefile.am
> @@ -0,0 +1,8 @@
> +## Process this file with automake to produce Makefile.in
> +
> +man8_MANS	= nfs4id.man
> +
> +bin_PROGRAMS = nfs4id
> +
> +nfs4id_SOURCES = nfs4id.c
> +nfs4id_LDADD = $(LIBUUID)
> diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
> new file mode 100644
> index 000000000000..dbb807ae21f3
> --- /dev/null
> +++ b/tools/nfs4id/nfs4id.c
> @@ -0,0 +1,184 @@
> +/*
> + * nfs4id.c -- create and persist uniquifiers for nfs4 clients
> + *
> + * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
> + * Boston, MA 02110-1301, USA.
> + */
> +
> +#include <stdio.h>
> +#include <stdarg.h>
> +#include <getopt.h>
> +#include <string.h>
> +#include <errno.h>
> +#include <stdlib.h>
> +#include <fcntl.h>
> +#include <unistd.h>
> +#include <uuid/uuid.h>
> +
> +#define NFS4IDFILE "/etc/nfs4-id"
> +
> +UUID_DEFINE(nfs4_clientid_uuid_template,
> +	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
> +	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
> +
> +static char *prog;
> +static char *source = NULL;
> +static char nfs4_id[64];
> +static int force = 0;
> +
> +static void usage(void)
> +{
> +	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
> +}
> +
> +static void fatal(const char *fmt, ...)
> +{
> +	int err = errno;
> +	va_list args;
> +	char fatal_msg[256] = "fatal: ";
> +
> +	va_start(args, fmt);
> +	vsnprintf(&fatal_msg[7], 255, fmt, args);
> +	if (err)
> +		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
> +	else
> +		fprintf(stderr, "%s\n", fatal_msg);
> +	exit(-1);
> +}
> +
> +static int read_nfs4_id(void)
> +{
> +	int fd;
> +
> +	fd = open(NFS4IDFILE, O_RDONLY);
> +	if (fd < 0)
> +		return fd;
> +	read(fd, nfs4_id, 64);
> +	close(fd);
> +	return 0;
> +}
> +
> +static void write_nfs4_id(void)
> +{
> +	int fd;
> +
> +	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
> +	if (fd < 0)
> +		fatal("could not write id to " NFS4IDFILE);
> +	write(fd, nfs4_id, 37);
> +}
> +
> +static void print_nfs4_id(void)
> +{
> +	fprintf(stdout, "%s", nfs4_id);
> +}
> +	
> +static void check_or_make_id(void)
> +{
> +	int ret;
> +	uuid_t nfs4id_uuid;
> +
> +	ret = read_nfs4_id();
> +	if (ret != 0) {
> +		if (errno != ENOENT )
> +			fatal("reading file " NFS4IDFILE);
> +		uuid_generate_random(nfs4id_uuid);
> +		uuid_unparse(nfs4id_uuid, nfs4_id);
> +		nfs4_id[36] = '\n';
> +		nfs4_id[37] = '\0';
> +		write_nfs4_id();
> +	}
> +	print_nfs4_id();	
> +}
> +
> +static void check_or_make_id_from_machine(void)
> +{
> +	int fd, ret;
> +	char machineid[32];
> +	uuid_t nfs4id_uuid;
> +
> +	ret = read_nfs4_id();
> +	if (ret != 0) {
> +		if (errno != ENOENT )
> +			fatal("reading file " NFS4IDFILE);
> +
> +		fd = open("/etc/machine-id", O_RDONLY);
> +		if (fd < 0)
> +			fatal("unable to read /etc/machine-id");
> +
> +		read(fd, machineid, 32);
> +		close(fd);
> +
> +		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
> +		uuid_unparse(nfs4id_uuid, nfs4_id);
> +		nfs4_id[36] = '\n';
> +		nfs4_id[37] = '\0';
> +		write_nfs4_id();
> +	}
> +	print_nfs4_id();
> +}
> +
> +int main(int argc, char **argv)
> +{
> +	prog = argv[0];
> +
> +	while (1) {
> +		int opt;
> +		int option_index = 0;
> +		static struct option long_options[] = {
> +			{"force",	no_argument,	0, 'f' },
> +			{0,			0,				0, 0 }
> +		};
> +
> +		errno = 0;
> +		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
> +		if (opt == -1)
> +			break;
> +
> +		switch (opt) {
> +		case 'f':
> +			force = 1;
> +			break;
> +		case '?':
> +			usage();
> +			fatal("unexpected arg \"%s\"", argv[optind - 1]);
> +			break;
> +		}
> +	}
> +
> +	argc -= optind;
> +
> +	if (argc > 1) {
> +		usage();
> +		fatal("Too many arguments");
> +	}
> +
> +	if (argc)
> +		source = argv[optind++];
> +
> +	if (force)
> +		unlink(NFS4IDFILE);
> +
> +	if (!source)
> +		check_or_make_id();
> +	else if (strcmp(source, "machine") == 0)
> +		check_or_make_id_from_machine();
> +	else {
> +		usage();
> +		fatal("unrecognized source %s\n", source);
> +	}
> +}
> diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
> new file mode 100644
> index 000000000000..358f836468a2
> --- /dev/null
> +++ b/tools/nfs4id/nfs4id.man
> @@ -0,0 +1,29 @@
> +.\"
> +.\" nfs4id(8)
> +.\"
> +.TH nfs4id 8 "3 Feb 2022"
> +.SH NAME
> +nfs4id \- Generate or return nfs4 client id uniqueifiers
> +.SH SYNOPSIS
> +.B nfs4id [ -f | --force ] [<source>]
> +
> +.SH DESCRIPTION
> +The
> +.B nfs4id
> +command provides a simple utility to help NFS Version 4 clients use unique
> +and persistent client id values.  The command checks for the existence of a
> +file /etc/nfs4-id and returns the first 64 chars read from that file.  If
> +the file is not found, a UUID is generated from the specified source and
> +written to the file and returned.
> +.SH OPTIONS
> +.TP
> +.BR \-f, \-\-force
> +Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
> +.SH Sources
> +If <source> is not specified, nfs4id will generate a new random UUID.
> +
> +If <source> is "machine", nfs4id will generate a deterministic UUID value
> +derived from a sha1 hash of the contents of /etc/machine-id and a static
> +key.
> +.SH SEE ALSO
> +.BR machine-id (5)


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 16:04 ` Steve Dickson
@ 2022-02-08 16:21   ` Chuck Lever III
  2022-02-08 19:29     ` Steve Dickson
  2022-02-08 16:22   ` Benjamin Coddington
  1 sibling, 1 reply; 33+ messages in thread
From: Chuck Lever III @ 2022-02-08 16:21 UTC (permalink / raw)
  To: Steve Dickson, Benjamin Coddington; +Cc: Linux NFS Mailing List



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


> steved.
> 
>> diff --git a/.gitignore b/.gitignore
>> index c89d1cd2583d..a37964148dd8 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -61,6 +61,7 @@ utils/statd/statd
>>  tools/locktest/testlk
>>  tools/getiversion/getiversion
>>  tools/nfsconf/nfsconf
>> +tools/nfs4id/nfs4id
>>  support/export/mount.h
>>  support/export/mount_clnt.c
>>  support/export/mount_xdr.c
>> diff --git a/configure.ac b/configure.ac
>> index 50e9b321dcf3..93d0a902cfd8 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
>>    dnl check for the keyutils libraries and headers
>>    AC_KEYUTILS
>>  +  dnl check for the libuuid library and headers
>> +  AC_LIBUUID
>> +
>>    dnl Check for sqlite3
>>    AC_SQLITE3_VERS
>>  @@ -740,6 +743,7 @@ AC_CONFIG_FILES([
>>  	tools/nfsdclnts/Makefile
>>  	tools/nfsconf/Makefile
>>  	tools/nfsdclddb/Makefile
>> +	tools/nfs4id/Makefile
>>  	utils/Makefile
>>  	utils/blkmapd/Makefile
>>  	utils/nfsdcld/Makefile
>> diff --git a/tools/Makefile.am b/tools/Makefile.am
>> index 9b4b0803db39..cc658f69bb32 100644
>> --- a/tools/Makefile.am
>> +++ b/tools/Makefile.am
>> @@ -7,6 +7,7 @@ OPTDIRS += rpcgen
>>  endif
>>    OPTDIRS += nfsconf
>> +OPTDIRS += nfs4id
>>    if CONFIG_NFSDCLD
>>  OPTDIRS += nfsdclddb
>> diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
>> new file mode 100644
>> index 000000000000..d1e60a35a510
>> --- /dev/null
>> +++ b/tools/nfs4id/Makefile.am
>> @@ -0,0 +1,8 @@
>> +## Process this file with automake to produce Makefile.in
>> +
>> +man8_MANS	= nfs4id.man
>> +
>> +bin_PROGRAMS = nfs4id
>> +
>> +nfs4id_SOURCES = nfs4id.c
>> +nfs4id_LDADD = $(LIBUUID)
>> diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
>> new file mode 100644
>> index 000000000000..dbb807ae21f3
>> --- /dev/null
>> +++ b/tools/nfs4id/nfs4id.c
>> @@ -0,0 +1,184 @@
>> +/*
>> + * nfs4id.c -- create and persist uniquifiers for nfs4 clients
>> + *
>> + * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
>> + * Boston, MA 02110-1301, USA.
>> + */
>> +
>> +#include <stdio.h>
>> +#include <stdarg.h>
>> +#include <getopt.h>
>> +#include <string.h>
>> +#include <errno.h>
>> +#include <stdlib.h>
>> +#include <fcntl.h>
>> +#include <unistd.h>
>> +#include <uuid/uuid.h>
>> +
>> +#define NFS4IDFILE "/etc/nfs4-id"
>> +
>> +UUID_DEFINE(nfs4_clientid_uuid_template,
>> +	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
>> +	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
>> +
>> +static char *prog;
>> +static char *source = NULL;
>> +static char nfs4_id[64];
>> +static int force = 0;
>> +
>> +static void usage(void)
>> +{
>> +	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
>> +}
>> +
>> +static void fatal(const char *fmt, ...)
>> +{
>> +	int err = errno;
>> +	va_list args;
>> +	char fatal_msg[256] = "fatal: ";
>> +
>> +	va_start(args, fmt);
>> +	vsnprintf(&fatal_msg[7], 255, fmt, args);
>> +	if (err)
>> +		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
>> +	else
>> +		fprintf(stderr, "%s\n", fatal_msg);
>> +	exit(-1);
>> +}
>> +
>> +static int read_nfs4_id(void)
>> +{
>> +	int fd;
>> +
>> +	fd = open(NFS4IDFILE, O_RDONLY);
>> +	if (fd < 0)
>> +		return fd;
>> +	read(fd, nfs4_id, 64);
>> +	close(fd);
>> +	return 0;
>> +}
>> +
>> +static void write_nfs4_id(void)
>> +{
>> +	int fd;
>> +
>> +	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
>> +	if (fd < 0)
>> +		fatal("could not write id to " NFS4IDFILE);
>> +	write(fd, nfs4_id, 37);
>> +}
>> +
>> +static void print_nfs4_id(void)
>> +{
>> +	fprintf(stdout, "%s", nfs4_id);
>> +}
>> +	
>> +static void check_or_make_id(void)
>> +{
>> +	int ret;
>> +	uuid_t nfs4id_uuid;
>> +
>> +	ret = read_nfs4_id();
>> +	if (ret != 0) {
>> +		if (errno != ENOENT )
>> +			fatal("reading file " NFS4IDFILE);
>> +		uuid_generate_random(nfs4id_uuid);
>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>> +		nfs4_id[36] = '\n';
>> +		nfs4_id[37] = '\0';
>> +		write_nfs4_id();
>> +	}
>> +	print_nfs4_id();	
>> +}
>> +
>> +static void check_or_make_id_from_machine(void)
>> +{
>> +	int fd, ret;
>> +	char machineid[32];
>> +	uuid_t nfs4id_uuid;
>> +
>> +	ret = read_nfs4_id();
>> +	if (ret != 0) {
>> +		if (errno != ENOENT )
>> +			fatal("reading file " NFS4IDFILE);
>> +
>> +		fd = open("/etc/machine-id", O_RDONLY);
>> +		if (fd < 0)
>> +			fatal("unable to read /etc/machine-id");
>> +
>> +		read(fd, machineid, 32);
>> +		close(fd);
>> +
>> +		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>> +		nfs4_id[36] = '\n';
>> +		nfs4_id[37] = '\0';
>> +		write_nfs4_id();
>> +	}
>> +	print_nfs4_id();
>> +}
>> +
>> +int main(int argc, char **argv)
>> +{
>> +	prog = argv[0];
>> +
>> +	while (1) {
>> +		int opt;
>> +		int option_index = 0;
>> +		static struct option long_options[] = {
>> +			{"force",	no_argument,	0, 'f' },
>> +			{0,			0,				0, 0 }
>> +		};
>> +
>> +		errno = 0;
>> +		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
>> +		if (opt == -1)
>> +			break;
>> +
>> +		switch (opt) {
>> +		case 'f':
>> +			force = 1;
>> +			break;
>> +		case '?':
>> +			usage();
>> +			fatal("unexpected arg \"%s\"", argv[optind - 1]);
>> +			break;
>> +		}
>> +	}
>> +
>> +	argc -= optind;
>> +
>> +	if (argc > 1) {
>> +		usage();
>> +		fatal("Too many arguments");
>> +	}
>> +
>> +	if (argc)
>> +		source = argv[optind++];
>> +
>> +	if (force)
>> +		unlink(NFS4IDFILE);
>> +
>> +	if (!source)
>> +		check_or_make_id();
>> +	else if (strcmp(source, "machine") == 0)
>> +		check_or_make_id_from_machine();
>> +	else {
>> +		usage();
>> +		fatal("unrecognized source %s\n", source);
>> +	}
>> +}
>> diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
>> new file mode 100644
>> index 000000000000..358f836468a2
>> --- /dev/null
>> +++ b/tools/nfs4id/nfs4id.man
>> @@ -0,0 +1,29 @@
>> +.\"
>> +.\" nfs4id(8)
>> +.\"
>> +.TH nfs4id 8 "3 Feb 2022"
>> +.SH NAME
>> +nfs4id \- Generate or return nfs4 client id uniqueifiers
>> +.SH SYNOPSIS
>> +.B nfs4id [ -f | --force ] [<source>]
>> +
>> +.SH DESCRIPTION
>> +The
>> +.B nfs4id
>> +command provides a simple utility to help NFS Version 4 clients use unique
>> +and persistent client id values.  The command checks for the existence of a
>> +file /etc/nfs4-id and returns the first 64 chars read from that file.  If
>> +the file is not found, a UUID is generated from the specified source and
>> +written to the file and returned.
>> +.SH OPTIONS
>> +.TP
>> +.BR \-f, \-\-force
>> +Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
>> +.SH Sources
>> +If <source> is not specified, nfs4id will generate a new random UUID.
>> +
>> +If <source> is "machine", nfs4id will generate a deterministic UUID value
>> +derived from a sha1 hash of the contents of /etc/machine-id and a static
>> +key.
>> +.SH SEE ALSO
>> +.BR machine-id (5)

--
Chuck Lever




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 16:04 ` Steve Dickson
  2022-02-08 16:21   ` Chuck Lever III
@ 2022-02-08 16:22   ` Benjamin Coddington
  2022-02-08 19:52     ` Steve Dickson
  1 sibling, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-08 16:22 UTC (permalink / raw)
  To: Steve Dickson; +Cc: linux-nfs

On 8 Feb 2022, at 11:04, Steve Dickson 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?

Not at all.. and I think there's a lot of room for naming discussions 
about
the file to store the id too:

Trond sent /etc/nfs4_uuid
Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
Ben sent /etc/nfs4-id (to match /etc/machine-id)

Maybe the tool wants an option to specify the file?

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 16:21   ` Chuck Lever III
@ 2022-02-08 19:29     ` Steve Dickson
  2022-02-08 21:18       ` Chuck Lever III
  0 siblings, 1 reply; 33+ messages in thread
From: Steve Dickson @ 2022-02-08 19:29 UTC (permalink / raw)
  To: Chuck Lever III, Benjamin Coddington; +Cc: Linux NFS Mailing List



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.

steved.

> 
> 
>> steved.
>>
>>> diff --git a/.gitignore b/.gitignore
>>> index c89d1cd2583d..a37964148dd8 100644
>>> --- a/.gitignore
>>> +++ b/.gitignore
>>> @@ -61,6 +61,7 @@ utils/statd/statd
>>>   tools/locktest/testlk
>>>   tools/getiversion/getiversion
>>>   tools/nfsconf/nfsconf
>>> +tools/nfs4id/nfs4id
>>>   support/export/mount.h
>>>   support/export/mount_clnt.c
>>>   support/export/mount_xdr.c
>>> diff --git a/configure.ac b/configure.ac
>>> index 50e9b321dcf3..93d0a902cfd8 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
>>>     dnl check for the keyutils libraries and headers
>>>     AC_KEYUTILS
>>>   +  dnl check for the libuuid library and headers
>>> +  AC_LIBUUID
>>> +
>>>     dnl Check for sqlite3
>>>     AC_SQLITE3_VERS
>>>   @@ -740,6 +743,7 @@ AC_CONFIG_FILES([
>>>   	tools/nfsdclnts/Makefile
>>>   	tools/nfsconf/Makefile
>>>   	tools/nfsdclddb/Makefile
>>> +	tools/nfs4id/Makefile
>>>   	utils/Makefile
>>>   	utils/blkmapd/Makefile
>>>   	utils/nfsdcld/Makefile
>>> diff --git a/tools/Makefile.am b/tools/Makefile.am
>>> index 9b4b0803db39..cc658f69bb32 100644
>>> --- a/tools/Makefile.am
>>> +++ b/tools/Makefile.am
>>> @@ -7,6 +7,7 @@ OPTDIRS += rpcgen
>>>   endif
>>>     OPTDIRS += nfsconf
>>> +OPTDIRS += nfs4id
>>>     if CONFIG_NFSDCLD
>>>   OPTDIRS += nfsdclddb
>>> diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
>>> new file mode 100644
>>> index 000000000000..d1e60a35a510
>>> --- /dev/null
>>> +++ b/tools/nfs4id/Makefile.am
>>> @@ -0,0 +1,8 @@
>>> +## Process this file with automake to produce Makefile.in
>>> +
>>> +man8_MANS	= nfs4id.man
>>> +
>>> +bin_PROGRAMS = nfs4id
>>> +
>>> +nfs4id_SOURCES = nfs4id.c
>>> +nfs4id_LDADD = $(LIBUUID)
>>> diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
>>> new file mode 100644
>>> index 000000000000..dbb807ae21f3
>>> --- /dev/null
>>> +++ b/tools/nfs4id/nfs4id.c
>>> @@ -0,0 +1,184 @@
>>> +/*
>>> + * nfs4id.c -- create and persist uniquifiers for nfs4 clients
>>> + *
>>> + * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License
>>> + * as published by the Free Software Foundation; either version 2
>>> + * of the License, or (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
>>> + * Boston, MA 02110-1301, USA.
>>> + */
>>> +
>>> +#include <stdio.h>
>>> +#include <stdarg.h>
>>> +#include <getopt.h>
>>> +#include <string.h>
>>> +#include <errno.h>
>>> +#include <stdlib.h>
>>> +#include <fcntl.h>
>>> +#include <unistd.h>
>>> +#include <uuid/uuid.h>
>>> +
>>> +#define NFS4IDFILE "/etc/nfs4-id"
>>> +
>>> +UUID_DEFINE(nfs4_clientid_uuid_template,
>>> +	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
>>> +	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
>>> +
>>> +static char *prog;
>>> +static char *source = NULL;
>>> +static char nfs4_id[64];
>>> +static int force = 0;
>>> +
>>> +static void usage(void)
>>> +{
>>> +	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
>>> +}
>>> +
>>> +static void fatal(const char *fmt, ...)
>>> +{
>>> +	int err = errno;
>>> +	va_list args;
>>> +	char fatal_msg[256] = "fatal: ";
>>> +
>>> +	va_start(args, fmt);
>>> +	vsnprintf(&fatal_msg[7], 255, fmt, args);
>>> +	if (err)
>>> +		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
>>> +	else
>>> +		fprintf(stderr, "%s\n", fatal_msg);
>>> +	exit(-1);
>>> +}
>>> +
>>> +static int read_nfs4_id(void)
>>> +{
>>> +	int fd;
>>> +
>>> +	fd = open(NFS4IDFILE, O_RDONLY);
>>> +	if (fd < 0)
>>> +		return fd;
>>> +	read(fd, nfs4_id, 64);
>>> +	close(fd);
>>> +	return 0;
>>> +}
>>> +
>>> +static void write_nfs4_id(void)
>>> +{
>>> +	int fd;
>>> +
>>> +	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
>>> +	if (fd < 0)
>>> +		fatal("could not write id to " NFS4IDFILE);
>>> +	write(fd, nfs4_id, 37);
>>> +}
>>> +
>>> +static void print_nfs4_id(void)
>>> +{
>>> +	fprintf(stdout, "%s", nfs4_id);
>>> +}
>>> +	
>>> +static void check_or_make_id(void)
>>> +{
>>> +	int ret;
>>> +	uuid_t nfs4id_uuid;
>>> +
>>> +	ret = read_nfs4_id();
>>> +	if (ret != 0) {
>>> +		if (errno != ENOENT )
>>> +			fatal("reading file " NFS4IDFILE);
>>> +		uuid_generate_random(nfs4id_uuid);
>>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>>> +		nfs4_id[36] = '\n';
>>> +		nfs4_id[37] = '\0';
>>> +		write_nfs4_id();
>>> +	}
>>> +	print_nfs4_id();	
>>> +}
>>> +
>>> +static void check_or_make_id_from_machine(void)
>>> +{
>>> +	int fd, ret;
>>> +	char machineid[32];
>>> +	uuid_t nfs4id_uuid;
>>> +
>>> +	ret = read_nfs4_id();
>>> +	if (ret != 0) {
>>> +		if (errno != ENOENT )
>>> +			fatal("reading file " NFS4IDFILE);
>>> +
>>> +		fd = open("/etc/machine-id", O_RDONLY);
>>> +		if (fd < 0)
>>> +			fatal("unable to read /etc/machine-id");
>>> +
>>> +		read(fd, machineid, 32);
>>> +		close(fd);
>>> +
>>> +		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
>>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>>> +		nfs4_id[36] = '\n';
>>> +		nfs4_id[37] = '\0';
>>> +		write_nfs4_id();
>>> +	}
>>> +	print_nfs4_id();
>>> +}
>>> +
>>> +int main(int argc, char **argv)
>>> +{
>>> +	prog = argv[0];
>>> +
>>> +	while (1) {
>>> +		int opt;
>>> +		int option_index = 0;
>>> +		static struct option long_options[] = {
>>> +			{"force",	no_argument,	0, 'f' },
>>> +			{0,			0,				0, 0 }
>>> +		};
>>> +
>>> +		errno = 0;
>>> +		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
>>> +		if (opt == -1)
>>> +			break;
>>> +
>>> +		switch (opt) {
>>> +		case 'f':
>>> +			force = 1;
>>> +			break;
>>> +		case '?':
>>> +			usage();
>>> +			fatal("unexpected arg \"%s\"", argv[optind - 1]);
>>> +			break;
>>> +		}
>>> +	}
>>> +
>>> +	argc -= optind;
>>> +
>>> +	if (argc > 1) {
>>> +		usage();
>>> +		fatal("Too many arguments");
>>> +	}
>>> +
>>> +	if (argc)
>>> +		source = argv[optind++];
>>> +
>>> +	if (force)
>>> +		unlink(NFS4IDFILE);
>>> +
>>> +	if (!source)
>>> +		check_or_make_id();
>>> +	else if (strcmp(source, "machine") == 0)
>>> +		check_or_make_id_from_machine();
>>> +	else {
>>> +		usage();
>>> +		fatal("unrecognized source %s\n", source);
>>> +	}
>>> +}
>>> diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
>>> new file mode 100644
>>> index 000000000000..358f836468a2
>>> --- /dev/null
>>> +++ b/tools/nfs4id/nfs4id.man
>>> @@ -0,0 +1,29 @@
>>> +.\"
>>> +.\" nfs4id(8)
>>> +.\"
>>> +.TH nfs4id 8 "3 Feb 2022"
>>> +.SH NAME
>>> +nfs4id \- Generate or return nfs4 client id uniqueifiers
>>> +.SH SYNOPSIS
>>> +.B nfs4id [ -f | --force ] [<source>]
>>> +
>>> +.SH DESCRIPTION
>>> +The
>>> +.B nfs4id
>>> +command provides a simple utility to help NFS Version 4 clients use unique
>>> +and persistent client id values.  The command checks for the existence of a
>>> +file /etc/nfs4-id and returns the first 64 chars read from that file.  If
>>> +the file is not found, a UUID is generated from the specified source and
>>> +written to the file and returned.
>>> +.SH OPTIONS
>>> +.TP
>>> +.BR \-f, \-\-force
>>> +Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
>>> +.SH Sources
>>> +If <source> is not specified, nfs4id will generate a new random UUID.
>>> +
>>> +If <source> is "machine", nfs4id will generate a deterministic UUID value
>>> +derived from a sha1 hash of the contents of /etc/machine-id and a static
>>> +key.
>>> +.SH SEE ALSO
>>> +.BR machine-id (5)
> 
> --
> Chuck Lever
> 
> 
> 


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 16:22   ` Benjamin Coddington
@ 2022-02-08 19:52     ` Steve Dickson
  2022-02-08 20:00       ` Benjamin Coddington
  2022-02-09 21:21       ` NeilBrown
  0 siblings, 2 replies; 33+ messages in thread
From: Steve Dickson @ 2022-02-08 19:52 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: linux-nfs



On 2/8/22 11:22 AM, Benjamin Coddington wrote:
> On 8 Feb 2022, at 11:04, Steve Dickson 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?
> 
> Not at all.. 
Good...

> and I think there's a lot of room for naming discussions about
> the file to store the id too:
> 
> Trond sent /etc/nfs4_uuid
> Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
> Ben sent /etc/nfs4-id (to match /etc/machine-id)
Question... is it kosher to be writing /etc which is
generally on the root filesystem?

By far Neil suggestion is the most intriguing... but
on the containers I'm looking at there no /etc/netns
directory.

I had to install the iproute package to do the
"ip netns identify" which returns NULL...
also adds yet another dependency on nfs-utils.

So if "ip netns identify" does return NULL what directory
path should be used?

I'm all for making things container friendly but I'm
also a fan of keeping things simple... So
how about /etc/nfs.conf.d/identity.conf or
/etc/nfs.conf.d/nfsid.conf?

> 
> Maybe the tool wants an option to specify the file?
This is probably not a bad idea... It is a common practice

steved.

> 
> Ben
> 


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 19:52     ` Steve Dickson
@ 2022-02-08 20:00       ` Benjamin Coddington
  2022-02-08 22:30         ` Steve Dickson
  2022-02-09 21:21       ` NeilBrown
  1 sibling, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-08 20:00 UTC (permalink / raw)
  To: Steve Dickson; +Cc: linux-nfs

On 8 Feb 2022, at 14:52, Steve Dickson wrote:

> On 2/8/22 11:22 AM, Benjamin Coddington wrote:
>> On 8 Feb 2022, at 11:04, Steve Dickson 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?
>>
>> Not at all..
> Good...

I didn't orginally do that because I thought it might be confusing for 
some
folks who want `nfsid` to display their kerberos identity.  There's a BZ
open for that!

Do you think that's a problem?  I feel like it's a problem.

>> and I think there's a lot of room for naming discussions about
>> the file to store the id too:
>>
>> Trond sent /etc/nfs4_uuid
>> Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
>> Ben sent /etc/nfs4-id (to match /etc/machine-id)
> Question... is it kosher to be writing /etc which is
> generally on the root filesystem?

Sure, why not?

> By far Neil suggestion is the most intriguing... but
> on the containers I'm looking at there no /etc/netns
> directory.

Not yet -- you can create it.

> I had to install the iproute package to do the
> "ip netns identify" which returns NULL...
> also adds yet another dependency on nfs-utils.

We don't need the dependency..this little binary is just a helper for a 
udev
rule.  Trond already wrote his version of this.  :)  This one's just 
trying
to be a little lighter (whoa, we don't need all of bash!).

> So if "ip netns identify" does return NULL what directory
> path should be used?

I think thats out of scope..  if udevd is running in a container, and 
has a
rule that uses this tool, then the container either is likely to have
already customized its /etc.  Or perhaps we can make the udev rule 
namespace
aware (I need to look into what's available to udev's rule environment 
when
it runs in a namespace).

> I'm all for making things container friendly but I'm
> also a fan of keeping things simple... So
> how about /etc/nfs.conf.d/identity.conf or
> /etc/nfs.conf.d/nfsid.conf?

Really, because its not a configuration.  Its value persistence, and we 
/really/
don't want people configuring it.

>>
>> Maybe the tool wants an option to specify the file?
> This is probably not a bad idea... It is a common practice

OK, I'll do that.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 19:29     ` Steve Dickson
@ 2022-02-08 21:18       ` Chuck Lever III
  2022-02-08 22:39         ` Steve Dickson
  0 siblings, 1 reply; 33+ messages in thread
From: Chuck Lever III @ 2022-02-08 21:18 UTC (permalink / raw)
  To: Steve Dickson; +Cc: Benjamin Coddington, Linux NFS Mailing List



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

nfsclientid then?


> steved.
> 
>>> steved.
>>> 
>>>> diff --git a/.gitignore b/.gitignore
>>>> index c89d1cd2583d..a37964148dd8 100644
>>>> --- a/.gitignore
>>>> +++ b/.gitignore
>>>> @@ -61,6 +61,7 @@ utils/statd/statd
>>>>  tools/locktest/testlk
>>>>  tools/getiversion/getiversion
>>>>  tools/nfsconf/nfsconf
>>>> +tools/nfs4id/nfs4id
>>>>  support/export/mount.h
>>>>  support/export/mount_clnt.c
>>>>  support/export/mount_xdr.c
>>>> diff --git a/configure.ac b/configure.ac
>>>> index 50e9b321dcf3..93d0a902cfd8 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
>>>>    dnl check for the keyutils libraries and headers
>>>>    AC_KEYUTILS
>>>>  +  dnl check for the libuuid library and headers
>>>> +  AC_LIBUUID
>>>> +
>>>>    dnl Check for sqlite3
>>>>    AC_SQLITE3_VERS
>>>>  @@ -740,6 +743,7 @@ AC_CONFIG_FILES([
>>>>  	tools/nfsdclnts/Makefile
>>>>  	tools/nfsconf/Makefile
>>>>  	tools/nfsdclddb/Makefile
>>>> +	tools/nfs4id/Makefile
>>>>  	utils/Makefile
>>>>  	utils/blkmapd/Makefile
>>>>  	utils/nfsdcld/Makefile
>>>> diff --git a/tools/Makefile.am b/tools/Makefile.am
>>>> index 9b4b0803db39..cc658f69bb32 100644
>>>> --- a/tools/Makefile.am
>>>> +++ b/tools/Makefile.am
>>>> @@ -7,6 +7,7 @@ OPTDIRS += rpcgen
>>>>  endif
>>>>    OPTDIRS += nfsconf
>>>> +OPTDIRS += nfs4id
>>>>    if CONFIG_NFSDCLD
>>>>  OPTDIRS += nfsdclddb
>>>> diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
>>>> new file mode 100644
>>>> index 000000000000..d1e60a35a510
>>>> --- /dev/null
>>>> +++ b/tools/nfs4id/Makefile.am
>>>> @@ -0,0 +1,8 @@
>>>> +## Process this file with automake to produce Makefile.in
>>>> +
>>>> +man8_MANS	= nfs4id.man
>>>> +
>>>> +bin_PROGRAMS = nfs4id
>>>> +
>>>> +nfs4id_SOURCES = nfs4id.c
>>>> +nfs4id_LDADD = $(LIBUUID)
>>>> diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
>>>> new file mode 100644
>>>> index 000000000000..dbb807ae21f3
>>>> --- /dev/null
>>>> +++ b/tools/nfs4id/nfs4id.c
>>>> @@ -0,0 +1,184 @@
>>>> +/*
>>>> + * nfs4id.c -- create and persist uniquifiers for nfs4 clients
>>>> + *
>>>> + * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU General Public License
>>>> + * as published by the Free Software Foundation; either version 2
>>>> + * of the License, or (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program; if not, write to the Free Software
>>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
>>>> + * Boston, MA 02110-1301, USA.
>>>> + */
>>>> +
>>>> +#include <stdio.h>
>>>> +#include <stdarg.h>
>>>> +#include <getopt.h>
>>>> +#include <string.h>
>>>> +#include <errno.h>
>>>> +#include <stdlib.h>
>>>> +#include <fcntl.h>
>>>> +#include <unistd.h>
>>>> +#include <uuid/uuid.h>
>>>> +
>>>> +#define NFS4IDFILE "/etc/nfs4-id"
>>>> +
>>>> +UUID_DEFINE(nfs4_clientid_uuid_template,
>>>> +	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
>>>> +	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
>>>> +
>>>> +static char *prog;
>>>> +static char *source = NULL;
>>>> +static char nfs4_id[64];
>>>> +static int force = 0;
>>>> +
>>>> +static void usage(void)
>>>> +{
>>>> +	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
>>>> +}
>>>> +
>>>> +static void fatal(const char *fmt, ...)
>>>> +{
>>>> +	int err = errno;
>>>> +	va_list args;
>>>> +	char fatal_msg[256] = "fatal: ";
>>>> +
>>>> +	va_start(args, fmt);
>>>> +	vsnprintf(&fatal_msg[7], 255, fmt, args);
>>>> +	if (err)
>>>> +		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
>>>> +	else
>>>> +		fprintf(stderr, "%s\n", fatal_msg);
>>>> +	exit(-1);
>>>> +}
>>>> +
>>>> +static int read_nfs4_id(void)
>>>> +{
>>>> +	int fd;
>>>> +
>>>> +	fd = open(NFS4IDFILE, O_RDONLY);
>>>> +	if (fd < 0)
>>>> +		return fd;
>>>> +	read(fd, nfs4_id, 64);
>>>> +	close(fd);
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static void write_nfs4_id(void)
>>>> +{
>>>> +	int fd;
>>>> +
>>>> +	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
>>>> +	if (fd < 0)
>>>> +		fatal("could not write id to " NFS4IDFILE);
>>>> +	write(fd, nfs4_id, 37);
>>>> +}
>>>> +
>>>> +static void print_nfs4_id(void)
>>>> +{
>>>> +	fprintf(stdout, "%s", nfs4_id);
>>>> +}
>>>> +	
>>>> +static void check_or_make_id(void)
>>>> +{
>>>> +	int ret;
>>>> +	uuid_t nfs4id_uuid;
>>>> +
>>>> +	ret = read_nfs4_id();
>>>> +	if (ret != 0) {
>>>> +		if (errno != ENOENT )
>>>> +			fatal("reading file " NFS4IDFILE);
>>>> +		uuid_generate_random(nfs4id_uuid);
>>>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>>>> +		nfs4_id[36] = '\n';
>>>> +		nfs4_id[37] = '\0';
>>>> +		write_nfs4_id();
>>>> +	}
>>>> +	print_nfs4_id();	
>>>> +}
>>>> +
>>>> +static void check_or_make_id_from_machine(void)
>>>> +{
>>>> +	int fd, ret;
>>>> +	char machineid[32];
>>>> +	uuid_t nfs4id_uuid;
>>>> +
>>>> +	ret = read_nfs4_id();
>>>> +	if (ret != 0) {
>>>> +		if (errno != ENOENT )
>>>> +			fatal("reading file " NFS4IDFILE);
>>>> +
>>>> +		fd = open("/etc/machine-id", O_RDONLY);
>>>> +		if (fd < 0)
>>>> +			fatal("unable to read /etc/machine-id");
>>>> +
>>>> +		read(fd, machineid, 32);
>>>> +		close(fd);
>>>> +
>>>> +		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
>>>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>>>> +		nfs4_id[36] = '\n';
>>>> +		nfs4_id[37] = '\0';
>>>> +		write_nfs4_id();
>>>> +	}
>>>> +	print_nfs4_id();
>>>> +}
>>>> +
>>>> +int main(int argc, char **argv)
>>>> +{
>>>> +	prog = argv[0];
>>>> +
>>>> +	while (1) {
>>>> +		int opt;
>>>> +		int option_index = 0;
>>>> +		static struct option long_options[] = {
>>>> +			{"force",	no_argument,	0, 'f' },
>>>> +			{0,			0,				0, 0 }
>>>> +		};
>>>> +
>>>> +		errno = 0;
>>>> +		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
>>>> +		if (opt == -1)
>>>> +			break;
>>>> +
>>>> +		switch (opt) {
>>>> +		case 'f':
>>>> +			force = 1;
>>>> +			break;
>>>> +		case '?':
>>>> +			usage();
>>>> +			fatal("unexpected arg \"%s\"", argv[optind - 1]);
>>>> +			break;
>>>> +		}
>>>> +	}
>>>> +
>>>> +	argc -= optind;
>>>> +
>>>> +	if (argc > 1) {
>>>> +		usage();
>>>> +		fatal("Too many arguments");
>>>> +	}
>>>> +
>>>> +	if (argc)
>>>> +		source = argv[optind++];
>>>> +
>>>> +	if (force)
>>>> +		unlink(NFS4IDFILE);
>>>> +
>>>> +	if (!source)
>>>> +		check_or_make_id();
>>>> +	else if (strcmp(source, "machine") == 0)
>>>> +		check_or_make_id_from_machine();
>>>> +	else {
>>>> +		usage();
>>>> +		fatal("unrecognized source %s\n", source);
>>>> +	}
>>>> +}
>>>> diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
>>>> new file mode 100644
>>>> index 000000000000..358f836468a2
>>>> --- /dev/null
>>>> +++ b/tools/nfs4id/nfs4id.man
>>>> @@ -0,0 +1,29 @@
>>>> +.\"
>>>> +.\" nfs4id(8)
>>>> +.\"
>>>> +.TH nfs4id 8 "3 Feb 2022"
>>>> +.SH NAME
>>>> +nfs4id \- Generate or return nfs4 client id uniqueifiers
>>>> +.SH SYNOPSIS
>>>> +.B nfs4id [ -f | --force ] [<source>]
>>>> +
>>>> +.SH DESCRIPTION
>>>> +The
>>>> +.B nfs4id
>>>> +command provides a simple utility to help NFS Version 4 clients use unique
>>>> +and persistent client id values.  The command checks for the existence of a
>>>> +file /etc/nfs4-id and returns the first 64 chars read from that file.  If
>>>> +the file is not found, a UUID is generated from the specified source and
>>>> +written to the file and returned.
>>>> +.SH OPTIONS
>>>> +.TP
>>>> +.BR \-f, \-\-force
>>>> +Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
>>>> +.SH Sources
>>>> +If <source> is not specified, nfs4id will generate a new random UUID.
>>>> +
>>>> +If <source> is "machine", nfs4id will generate a deterministic UUID value
>>>> +derived from a sha1 hash of the contents of /etc/machine-id and a static
>>>> +key.
>>>> +.SH SEE ALSO
>>>> +.BR machine-id (5)
>> --
>> Chuck Lever
> 

--
Chuck Lever




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 20:00       ` Benjamin Coddington
@ 2022-02-08 22:30         ` Steve Dickson
  2022-02-09 13:55           ` Benjamin Coddington
  0 siblings, 1 reply; 33+ messages in thread
From: Steve Dickson @ 2022-02-08 22:30 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: linux-nfs

Hey!

On 2/8/22 3:00 PM, Benjamin Coddington wrote:
> On 8 Feb 2022, at 14:52, Steve Dickson wrote:
> 
>> On 2/8/22 11:22 AM, Benjamin Coddington wrote:
>>> On 8 Feb 2022, at 11:04, Steve Dickson 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?
>>>
>>> Not at all..
>> Good...
> 
> I didn't orginally do that because I thought it might be confusing for some
> folks who want `nfsid` to display their kerberos identity.  There's a BZ
> open for that!
> 
> Do you think that's a problem?  I feel like it's a problem.
> 
>>> and I think there's a lot of room for naming discussions about
>>> the file to store the id too:
>>>
>>> Trond sent /etc/nfs4_uuid
>>> Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
>>> Ben sent /etc/nfs4-id (to match /etc/machine-id)
>> Question... is it kosher to be writing /etc which is
>> generally on the root filesystem?
> 
> Sure, why not?
In general, writes to /etc are only happen when packages
are installed and removed... any real time writes go
to /var or /run (which is not persistent).

> 
>> By far Neil suggestion is the most intriguing... but
>> on the containers I'm looking at there no /etc/netns
>> directory.
> 
> Not yet -- you can create it.
"you" meaning who? the nfs-utils install or network
namespace env? Or is it, when /etc/netns exists
there is a network namespace and we should use
that dir?

> 
>> I had to install the iproute package to do the
>> "ip netns identify" which returns NULL...
>> also adds yet another dependency on nfs-utils.
> 
> We don't need the dependency..this little binary is just a helper for a 
> udev
> rule.  Trond already wrote his version of this.  :)  This one's just trying
> to be a little lighter (whoa, we don't need all of bash!).
Fair enough.

> 
>> So if "ip netns identify" does return NULL what directory
>> path should be used?
> 
> I think thats out of scope..  if udevd is running in a container, and has a
> rule that uses this tool, then the container either is likely to have
> already customized its /etc.  Or perhaps we can make the udev rule 
> namespace
> aware (I need to look into what's available to udev's rule environment when
> it runs in a namespace).
With all do respect... that is a lot of hand waving :-)
I'll wait to see what comes you come up with.

> 
>> I'm all for making things container friendly but I'm
>> also a fan of keeping things simple... So
>> how about /etc/nfs.conf.d/identity.conf or
>> /etc/nfs.conf.d/nfsid.conf?
> 
> Really, because its not a configuration.  Its value persistence, and we 
> /really/
> don't want people configuring it.
Good point... and I got it... I was just trying to used
the parsing code we already have in place.

> 
>>>
>>> Maybe the tool wants an option to specify the file?
>> This is probably not a bad idea... It is a common practice
> 
> OK, I'll do that.
Thanks!

steved.

> 
> Ben
> 


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 21:18       ` Chuck Lever III
@ 2022-02-08 22:39         ` Steve Dickson
  2022-02-10 13:28           ` Benjamin Coddington
  0 siblings, 1 reply; 33+ messages in thread
From: Steve Dickson @ 2022-02-08 22:39 UTC (permalink / raw)
  To: Chuck Lever III; +Cc: Benjamin Coddington, Linux NFS Mailing List



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

steved.
> 
> 
>> steved.
>>
>>>> steved.
>>>>
>>>>> diff --git a/.gitignore b/.gitignore
>>>>> index c89d1cd2583d..a37964148dd8 100644
>>>>> --- a/.gitignore
>>>>> +++ b/.gitignore
>>>>> @@ -61,6 +61,7 @@ utils/statd/statd
>>>>>   tools/locktest/testlk
>>>>>   tools/getiversion/getiversion
>>>>>   tools/nfsconf/nfsconf
>>>>> +tools/nfs4id/nfs4id
>>>>>   support/export/mount.h
>>>>>   support/export/mount_clnt.c
>>>>>   support/export/mount_xdr.c
>>>>> diff --git a/configure.ac b/configure.ac
>>>>> index 50e9b321dcf3..93d0a902cfd8 100644
>>>>> --- a/configure.ac
>>>>> +++ b/configure.ac
>>>>> @@ -355,6 +355,9 @@ if test "$enable_nfsv4" = yes; then
>>>>>     dnl check for the keyutils libraries and headers
>>>>>     AC_KEYUTILS
>>>>>   +  dnl check for the libuuid library and headers
>>>>> +  AC_LIBUUID
>>>>> +
>>>>>     dnl Check for sqlite3
>>>>>     AC_SQLITE3_VERS
>>>>>   @@ -740,6 +743,7 @@ AC_CONFIG_FILES([
>>>>>   	tools/nfsdclnts/Makefile
>>>>>   	tools/nfsconf/Makefile
>>>>>   	tools/nfsdclddb/Makefile
>>>>> +	tools/nfs4id/Makefile
>>>>>   	utils/Makefile
>>>>>   	utils/blkmapd/Makefile
>>>>>   	utils/nfsdcld/Makefile
>>>>> diff --git a/tools/Makefile.am b/tools/Makefile.am
>>>>> index 9b4b0803db39..cc658f69bb32 100644
>>>>> --- a/tools/Makefile.am
>>>>> +++ b/tools/Makefile.am
>>>>> @@ -7,6 +7,7 @@ OPTDIRS += rpcgen
>>>>>   endif
>>>>>     OPTDIRS += nfsconf
>>>>> +OPTDIRS += nfs4id
>>>>>     if CONFIG_NFSDCLD
>>>>>   OPTDIRS += nfsdclddb
>>>>> diff --git a/tools/nfs4id/Makefile.am b/tools/nfs4id/Makefile.am
>>>>> new file mode 100644
>>>>> index 000000000000..d1e60a35a510
>>>>> --- /dev/null
>>>>> +++ b/tools/nfs4id/Makefile.am
>>>>> @@ -0,0 +1,8 @@
>>>>> +## Process this file with automake to produce Makefile.in
>>>>> +
>>>>> +man8_MANS	= nfs4id.man
>>>>> +
>>>>> +bin_PROGRAMS = nfs4id
>>>>> +
>>>>> +nfs4id_SOURCES = nfs4id.c
>>>>> +nfs4id_LDADD = $(LIBUUID)
>>>>> diff --git a/tools/nfs4id/nfs4id.c b/tools/nfs4id/nfs4id.c
>>>>> new file mode 100644
>>>>> index 000000000000..dbb807ae21f3
>>>>> --- /dev/null
>>>>> +++ b/tools/nfs4id/nfs4id.c
>>>>> @@ -0,0 +1,184 @@
>>>>> +/*
>>>>> + * nfs4id.c -- create and persist uniquifiers for nfs4 clients
>>>>> + *
>>>>> + * Copyright (C) 2022  Red Hat, Benjamin Coddington <bcodding@redhat.com>
>>>>> + *
>>>>> + * This program is free software; you can redistribute it and/or
>>>>> + * modify it under the terms of the GNU General Public License
>>>>> + * as published by the Free Software Foundation; either version 2
>>>>> + * of the License, or (at your option) any later version.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>>> + * GNU General Public License for more details.
>>>>> + *
>>>>> + * You should have received a copy of the GNU General Public License
>>>>> + * along with this program; if not, write to the Free Software
>>>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
>>>>> + * Boston, MA 02110-1301, USA.
>>>>> + */
>>>>> +
>>>>> +#include <stdio.h>
>>>>> +#include <stdarg.h>
>>>>> +#include <getopt.h>
>>>>> +#include <string.h>
>>>>> +#include <errno.h>
>>>>> +#include <stdlib.h>
>>>>> +#include <fcntl.h>
>>>>> +#include <unistd.h>
>>>>> +#include <uuid/uuid.h>
>>>>> +
>>>>> +#define NFS4IDFILE "/etc/nfs4-id"
>>>>> +
>>>>> +UUID_DEFINE(nfs4_clientid_uuid_template,
>>>>> +	0xa2, 0x25, 0x68, 0xb2, 0x7a, 0x5f, 0x49, 0x90,
>>>>> +	0x8f, 0x98, 0xc5, 0xf0, 0x67, 0x78, 0xcc, 0xf1);
>>>>> +
>>>>> +static char *prog;
>>>>> +static char *source = NULL;
>>>>> +static char nfs4_id[64];
>>>>> +static int force = 0;
>>>>> +
>>>>> +static void usage(void)
>>>>> +{
>>>>> +	fprintf(stderr, "usage: %s [-f|--force] [machine]\n", prog);
>>>>> +}
>>>>> +
>>>>> +static void fatal(const char *fmt, ...)
>>>>> +{
>>>>> +	int err = errno;
>>>>> +	va_list args;
>>>>> +	char fatal_msg[256] = "fatal: ";
>>>>> +
>>>>> +	va_start(args, fmt);
>>>>> +	vsnprintf(&fatal_msg[7], 255, fmt, args);
>>>>> +	if (err)
>>>>> +		fprintf(stderr, "%s: %s\n", fatal_msg, strerror(err));
>>>>> +	else
>>>>> +		fprintf(stderr, "%s\n", fatal_msg);
>>>>> +	exit(-1);
>>>>> +}
>>>>> +
>>>>> +static int read_nfs4_id(void)
>>>>> +{
>>>>> +	int fd;
>>>>> +
>>>>> +	fd = open(NFS4IDFILE, O_RDONLY);
>>>>> +	if (fd < 0)
>>>>> +		return fd;
>>>>> +	read(fd, nfs4_id, 64);
>>>>> +	close(fd);
>>>>> +	return 0;
>>>>> +}
>>>>> +
>>>>> +static void write_nfs4_id(void)
>>>>> +{
>>>>> +	int fd;
>>>>> +
>>>>> +	fd = open(NFS4IDFILE, O_RDWR|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
>>>>> +	if (fd < 0)
>>>>> +		fatal("could not write id to " NFS4IDFILE);
>>>>> +	write(fd, nfs4_id, 37);
>>>>> +}
>>>>> +
>>>>> +static void print_nfs4_id(void)
>>>>> +{
>>>>> +	fprintf(stdout, "%s", nfs4_id);
>>>>> +}
>>>>> +	
>>>>> +static void check_or_make_id(void)
>>>>> +{
>>>>> +	int ret;
>>>>> +	uuid_t nfs4id_uuid;
>>>>> +
>>>>> +	ret = read_nfs4_id();
>>>>> +	if (ret != 0) {
>>>>> +		if (errno != ENOENT )
>>>>> +			fatal("reading file " NFS4IDFILE);
>>>>> +		uuid_generate_random(nfs4id_uuid);
>>>>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>>>>> +		nfs4_id[36] = '\n';
>>>>> +		nfs4_id[37] = '\0';
>>>>> +		write_nfs4_id();
>>>>> +	}
>>>>> +	print_nfs4_id();	
>>>>> +}
>>>>> +
>>>>> +static void check_or_make_id_from_machine(void)
>>>>> +{
>>>>> +	int fd, ret;
>>>>> +	char machineid[32];
>>>>> +	uuid_t nfs4id_uuid;
>>>>> +
>>>>> +	ret = read_nfs4_id();
>>>>> +	if (ret != 0) {
>>>>> +		if (errno != ENOENT )
>>>>> +			fatal("reading file " NFS4IDFILE);
>>>>> +
>>>>> +		fd = open("/etc/machine-id", O_RDONLY);
>>>>> +		if (fd < 0)
>>>>> +			fatal("unable to read /etc/machine-id");
>>>>> +
>>>>> +		read(fd, machineid, 32);
>>>>> +		close(fd);
>>>>> +
>>>>> +		uuid_generate_sha1(nfs4id_uuid, nfs4_clientid_uuid_template, machineid, 32);
>>>>> +		uuid_unparse(nfs4id_uuid, nfs4_id);
>>>>> +		nfs4_id[36] = '\n';
>>>>> +		nfs4_id[37] = '\0';
>>>>> +		write_nfs4_id();
>>>>> +	}
>>>>> +	print_nfs4_id();
>>>>> +}
>>>>> +
>>>>> +int main(int argc, char **argv)
>>>>> +{
>>>>> +	prog = argv[0];
>>>>> +
>>>>> +	while (1) {
>>>>> +		int opt;
>>>>> +		int option_index = 0;
>>>>> +		static struct option long_options[] = {
>>>>> +			{"force",	no_argument,	0, 'f' },
>>>>> +			{0,			0,				0, 0 }
>>>>> +		};
>>>>> +
>>>>> +		errno = 0;
>>>>> +		opt = getopt_long(argc, argv, ":f", long_options, &option_index);
>>>>> +		if (opt == -1)
>>>>> +			break;
>>>>> +
>>>>> +		switch (opt) {
>>>>> +		case 'f':
>>>>> +			force = 1;
>>>>> +			break;
>>>>> +		case '?':
>>>>> +			usage();
>>>>> +			fatal("unexpected arg \"%s\"", argv[optind - 1]);
>>>>> +			break;
>>>>> +		}
>>>>> +	}
>>>>> +
>>>>> +	argc -= optind;
>>>>> +
>>>>> +	if (argc > 1) {
>>>>> +		usage();
>>>>> +		fatal("Too many arguments");
>>>>> +	}
>>>>> +
>>>>> +	if (argc)
>>>>> +		source = argv[optind++];
>>>>> +
>>>>> +	if (force)
>>>>> +		unlink(NFS4IDFILE);
>>>>> +
>>>>> +	if (!source)
>>>>> +		check_or_make_id();
>>>>> +	else if (strcmp(source, "machine") == 0)
>>>>> +		check_or_make_id_from_machine();
>>>>> +	else {
>>>>> +		usage();
>>>>> +		fatal("unrecognized source %s\n", source);
>>>>> +	}
>>>>> +}
>>>>> diff --git a/tools/nfs4id/nfs4id.man b/tools/nfs4id/nfs4id.man
>>>>> new file mode 100644
>>>>> index 000000000000..358f836468a2
>>>>> --- /dev/null
>>>>> +++ b/tools/nfs4id/nfs4id.man
>>>>> @@ -0,0 +1,29 @@
>>>>> +.\"
>>>>> +.\" nfs4id(8)
>>>>> +.\"
>>>>> +.TH nfs4id 8 "3 Feb 2022"
>>>>> +.SH NAME
>>>>> +nfs4id \- Generate or return nfs4 client id uniqueifiers
>>>>> +.SH SYNOPSIS
>>>>> +.B nfs4id [ -f | --force ] [<source>]
>>>>> +
>>>>> +.SH DESCRIPTION
>>>>> +The
>>>>> +.B nfs4id
>>>>> +command provides a simple utility to help NFS Version 4 clients use unique
>>>>> +and persistent client id values.  The command checks for the existence of a
>>>>> +file /etc/nfs4-id and returns the first 64 chars read from that file.  If
>>>>> +the file is not found, a UUID is generated from the specified source and
>>>>> +written to the file and returned.
>>>>> +.SH OPTIONS
>>>>> +.TP
>>>>> +.BR \-f, \-\-force
>>>>> +Overwrite the existing /etc/nfs4-id with a UUID generated from <source>.
>>>>> +.SH Sources
>>>>> +If <source> is not specified, nfs4id will generate a new random UUID.
>>>>> +
>>>>> +If <source> is "machine", nfs4id will generate a deterministic UUID value
>>>>> +derived from a sha1 hash of the contents of /etc/machine-id and a static
>>>>> +key.
>>>>> +.SH SEE ALSO
>>>>> +.BR machine-id (5)
>>> --
>>> Chuck Lever
>>
> 
> --
> Chuck Lever
> 
> 
> 


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 22:30         ` Steve Dickson
@ 2022-02-09 13:55           ` Benjamin Coddington
  2022-02-09 15:23             ` Steve Dickson
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-09 13:55 UTC (permalink / raw)
  To: Steve Dickson; +Cc: linux-nfs

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

> Hey!
>
> On 2/8/22 3:00 PM, Benjamin Coddington wrote:
>> On 8 Feb 2022, at 14:52, Steve Dickson wrote:
>>
>>> On 2/8/22 11:22 AM, Benjamin Coddington wrote:
>>>> On 8 Feb 2022, at 11:04, Steve Dickson 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?
>>>>
>>>> Not at all..
>>> Good...
>>
>> I didn't orginally do that because I thought it might be confusing 
>> for some
>> folks who want `nfsid` to display their kerberos identity.  There's 
>> a BZ
>> open for that!
>>
>> Do you think that's a problem?  I feel like it's a problem.
>>
>>>> and I think there's a lot of room for naming discussions about
>>>> the file to store the id too:
>>>>
>>>> Trond sent /etc/nfs4_uuid
>>>> Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
>>>> Ben sent /etc/nfs4-id (to match /etc/machine-id)
>>> Question... is it kosher to be writing /etc which is
>>> generally on the root filesystem?
>>
>> Sure, why not?
> In general, writes to /etc are only happen when packages
> are installed and removed... any real time writes go
> to /var or /run (which is not persistent).

I use `passwd` and `usermod`, which write to etc.  I can think of other
examples.  For me, /etc is fair game.

There's three of us that think /etc is a good place.  You're the 
maintainer
though, tell us what's acceptable.  If we add an -f option to specify 
the
file, I'd like there to be a sane default if -f is absent.

>>> By far Neil suggestion is the most intriguing... but
>>> on the containers I'm looking at there no /etc/netns
>>> directory.
>>
>> Not yet -- you can create it.
> "you" meaning who? the nfs-utils install or network
> namespace env? Or is it, when /etc/netns exists
> there is a network namespace and we should use
> that dir?

Anyone that wants to create network namespace specific configuration can
create /etc/netns/NAME, and the iproute2 tools will bind-mount 
configuration
from there over /etc/ when doing `ip netns exec`.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-09 13:55           ` Benjamin Coddington
@ 2022-02-09 15:23             ` Steve Dickson
  0 siblings, 0 replies; 33+ messages in thread
From: Steve Dickson @ 2022-02-09 15:23 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: linux-nfs



On 2/9/22 8:55 AM, Benjamin Coddington wrote:
> On 8 Feb 2022, at 17:30, Steve Dickson wrote:
> 
>> Hey!
>>
>> On 2/8/22 3:00 PM, Benjamin Coddington wrote:
>>> On 8 Feb 2022, at 14:52, Steve Dickson wrote:
>>>
>>>> On 2/8/22 11:22 AM, Benjamin Coddington wrote:
>>>>> On 8 Feb 2022, at 11:04, Steve Dickson 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?
>>>>>
>>>>> Not at all..
>>>> Good...
>>>
>>> I didn't orginally do that because I thought it might be confusing 
>>> for some
>>> folks who want `nfsid` to display their kerberos identity.  There's a BZ
>>> open for that!
>>>
>>> Do you think that's a problem?  I feel like it's a problem.
>>>
>>>>> and I think there's a lot of room for naming discussions about
>>>>> the file to store the id too:
>>>>>
>>>>> Trond sent /etc/nfs4_uuid
>>>>> Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
>>>>> Ben sent /etc/nfs4-id (to match /etc/machine-id)
>>>> Question... is it kosher to be writing /etc which is
>>>> generally on the root filesystem?
>>>
>>> Sure, why not?
>> In general, writes to /etc are only happen when packages
>> are installed and removed... any real time writes go
>> to /var or /run (which is not persistent).
> 
> I use `passwd` and `usermod`, which write to etc.  I can think of other
> examples.  For me, /etc is fair game.
> 
> There's three of us that think /etc is a good place.  You're the maintainer
> though, tell us what's acceptable.  If we add an -f option to specify the
> file, I'd like there to be a sane default if -f is absent.
/etc is fine...

steved,

> 
>>>> By far Neil suggestion is the most intriguing... but
>>>> on the containers I'm looking at there no /etc/netns
>>>> directory.
>>>
>>> Not yet -- you can create it.
>> "you" meaning who? the nfs-utils install or network
>> namespace env? Or is it, when /etc/netns exists
>> there is a network namespace and we should use
>> that dir?
> 
> Anyone that wants to create network namespace specific configuration can
> create /etc/netns/NAME, and the iproute2 tools will bind-mount 
> configuration
> from there over /etc/ when doing `ip netns exec`.
> 
> Ben
> 


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 19:52     ` Steve Dickson
  2022-02-08 20:00       ` Benjamin Coddington
@ 2022-02-09 21:21       ` NeilBrown
  2022-02-09 21:45         ` Trond Myklebust
  1 sibling, 1 reply; 33+ messages in thread
From: NeilBrown @ 2022-02-09 21:21 UTC (permalink / raw)
  To: Steve Dickson; +Cc: Benjamin Coddington, linux-nfs

On Wed, 09 Feb 2022, Steve Dickson wrote:
> 
> On 2/8/22 11:22 AM, Benjamin Coddington wrote:
> > On 8 Feb 2022, at 11:04, Steve Dickson 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?
> > 
> > Not at all.. 
> Good...
> 
> > and I think there's a lot of room for naming discussions about
> > the file to store the id too:
> > 
> > Trond sent /etc/nfs4_uuid
> > Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
> > Ben sent /etc/nfs4-id (to match /etc/machine-id)
> Question... is it kosher to be writing /etc which is
> generally on the root filesystem?
> 
> By far Neil suggestion is the most intriguing... but
> on the containers I'm looking at there no /etc/netns
> directory.
> 
> I had to install the iproute package to do the
> "ip netns identify" which returns NULL...
> also adds yet another dependency on nfs-utils.
> 
> So if "ip netns identify" does return NULL what directory
> path should be used?

I'm not sure if this has been explicitly answered or not, so just in
case... 
  if "ip netns/identify" report NAME, then use /etc/netns/NAME/foo
  if it fails or report nothing, use /etc/foo

I think this is required whether we use nfs4-id, nfs-id, nfs-identity,
nfs.conf.d/identity.conf or any other file in /etc.

NeilBrown

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-09 21:21       ` NeilBrown
@ 2022-02-09 21:45         ` Trond Myklebust
  2022-02-09 23:58           ` NeilBrown
  0 siblings, 1 reply; 33+ messages in thread
From: Trond Myklebust @ 2022-02-09 21:45 UTC (permalink / raw)
  To: neilb, steved; +Cc: linux-nfs, bcodding

On Thu, 2022-02-10 at 08:21 +1100, NeilBrown wrote:
> On Wed, 09 Feb 2022, Steve Dickson wrote:
> > 
> > On 2/8/22 11:22 AM, Benjamin Coddington wrote:
> > > On 8 Feb 2022, at 11:04, Steve Dickson 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?
> > > 
> > > Not at all.. 
> > Good...
> > 
> > > and I think there's a lot of room for naming discussions about
> > > the file to store the id too:
> > > 
> > > Trond sent /etc/nfs4_uuid
> > > Neil suggests /etc/netns/NAME/nfs.conf.d/identity.conf
> > > Ben sent /etc/nfs4-id (to match /etc/machine-id)
> > Question... is it kosher to be writing /etc which is
> > generally on the root filesystem?
> > 
> > By far Neil suggestion is the most intriguing... but
> > on the containers I'm looking at there no /etc/netns
> > directory.
> > 
> > I had to install the iproute package to do the
> > "ip netns identify" which returns NULL...
> > also adds yet another dependency on nfs-utils.
> > 
> > So if "ip netns identify" does return NULL what directory
> > path should be used?
> 
> I'm not sure if this has been explicitly answered or not, so just in
> case... 
>   if "ip netns/identify" report NAME, then use /etc/netns/NAME/foo
>   if it fails or report nothing, use /etc/foo
> 
> I think this is required whether we use nfs4-id, nfs-id, nfs-
> identity,
> nfs.conf.d/identity.conf or any other file in /etc.
> 

Who uses this tool, and for what? This isn't anything that the standard
container orchestration managers use.

I'm running docker right now:

NR_09-21:41:07 host ~ $ ls /etc/net*
/etc/netconfig  /etc/networks
NR_09-21:41:47 hosts ~ $ docker exec -it f7debc079f4e bash
[root@f7debc079f4e /]# ls /etc/net*
/etc/netconfig  /etc/networks
[root@f7debc079f4e /]# ip netns identify

[root@f7debc079f4e /]# 

As you can see, neither the host nor the container have anything in
/etc/netns, and 'ip netns identify' is drawing a blank in both.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-09 21:45         ` Trond Myklebust
@ 2022-02-09 23:58           ` NeilBrown
  2022-02-10 12:25             ` Benjamin Coddington
  0 siblings, 1 reply; 33+ messages in thread
From: NeilBrown @ 2022-02-09 23:58 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: steved, linux-nfs, bcodding

On Thu, 10 Feb 2022, Trond Myklebust wrote:
> On Thu, 2022-02-10 at 08:21 +1100, NeilBrown wrote:
> > 
> > I'm not sure if this has been explicitly answered or not, so just in
> > case... 
> >   if "ip netns/identify" report NAME, then use /etc/netns/NAME/foo
> >   if it fails or report nothing, use /etc/foo
> > 
> > I think this is required whether we use nfs4-id, nfs-id, nfs-
> > identity,
> > nfs.conf.d/identity.conf or any other file in /etc.
> > 
> 
> Who uses this tool, and for what? This isn't anything that the standard
> container orchestration managers use.

At a guess, I'd say it would be used by anyone who just wants to set up
a separate network namespace, not necessarily a full "container".

> 
> I'm running docker right now:
> 
> NR_09-21:41:07 host ~ $ ls /etc/net*
> /etc/netconfig  /etc/networks
> NR_09-21:41:47 hosts ~ $ docker exec -it f7debc079f4e bash
> [root@f7debc079f4e /]# ls /etc/net*
> /etc/netconfig  /etc/networks
> [root@f7debc079f4e /]# ip netns identify
> 
> [root@f7debc079f4e /]# 
> 
> As you can see, neither the host nor the container have anything in
> /etc/netns, and 'ip netns identify' is drawing a blank in both.
> 

One of the original reasons given to reject the idea of using
/etc/nfs.conf{,.d} was that is wasn't "container aware".
I tried to find out what this might mean and discovered "ip netnfs" and
its man page which says:

   For applications that are aware of network namespaces, the convention
   is to look for global network configuration files first in
   /etc/netns/NAME/ then in /etc/.  For example, if you want a different
   version of /etc/resolv.conf for a network namespace used to isolate
   your vpn you would name it /etc/netns/myvpn/resolv.conf.

Obviously containers don't *have* to follow this model.  I guess there
is a difference between being "container aware" and being "network
namespace aware".

Presumably a full container manager (e.g.  docker) would set everything up
so that tools don't *need* to be container aware.  When you run docker,
do you get a separate /etc/ from the one outside of docker?  If you
create /etc/nfs-client-identifier inside the docker container, does it
remain private to that container?  Does it persist with the container?

Possibly NFS tools don't need to check in /etc/netnfs/NAME as they could
simply be run with "ip netns exec NAME tool args" which would set up
/etc.  This is fine for reading config files, but doesn't necessarily
work correctly for creating config files.

Possibly the goal of having an NFS tool which automatically creates and
persists a client identifier for the current container is not practical. 
Maybe we just document what any container-creation platform must do for
NFS, and let them all implement that however seems best.  With the new
random-identity-at-namespace-creation patch the cost of not doing
anything is localised to the container

Maybe we should just provide a tool
   nfs-set-client-identity NAME
The container setup code provides some "NAME" for the container which it
is responsible for keeping persistent, and we just write it to
/sys/fs/nfs/net/nfs_client/idenfier, possibly after hashing or whatever.

NeilBrown

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-09 23:58           ` NeilBrown
@ 2022-02-10 12:25             ` Benjamin Coddington
  2022-02-10 22:54               ` NeilBrown
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-10 12:25 UTC (permalink / raw)
  To: NeilBrown; +Cc: Trond Myklebust, steved, linux-nfs

On 9 Feb 2022, at 18:58, NeilBrown wrote:

> On Thu, 10 Feb 2022, Trond Myklebust wrote:
>> On Thu, 2022-02-10 at 08:21 +1100, NeilBrown wrote:
>>>
>>> I'm not sure if this has been explicitly answered or not, so just in
>>> case...
>>>   if "ip netns/identify" report NAME, then use /etc/netns/NAME/foo
>>>   if it fails or report nothing, use /etc/foo
>>>
>>> I think this is required whether we use nfs4-id, nfs-id, nfs-
>>> identity,
>>> nfs.conf.d/identity.conf or any other file in /etc.
>>>
>>
>> Who uses this tool, and for what? This isn't anything that the standard
>> container orchestration managers use.
>
> At a guess, I'd say it would be used by anyone who just wants to set up
> a separate network namespace, not necessarily a full "container".
>
>>
>> I'm running docker right now:
>>
>> NR_09-21:41:07 host ~ $ ls /etc/net*
>> /etc/netconfig  /etc/networks
>> NR_09-21:41:47 hosts ~ $ docker exec -it f7debc079f4e bash
>> [root@f7debc079f4e /]# ls /etc/net*
>> /etc/netconfig  /etc/networks
>> [root@f7debc079f4e /]# ip netns identify
>>
>> [root@f7debc079f4e /]#
>>
>> As you can see, neither the host nor the container have anything in
>> /etc/netns, and 'ip netns identify' is drawing a blank in both.
>>
>
> One of the original reasons given to reject the idea of using
> /etc/nfs.conf{,.d} was that is wasn't "container aware".
> I tried to find out what this might mean and discovered "ip netnfs" and
> its man page which says:
>
>    For applications that are aware of network namespaces, the convention
>    is to look for global network configuration files first in
>    /etc/netns/NAME/ then in /etc/.  For example, if you want a different
>    version of /etc/resolv.conf for a network namespace used to isolate
>    your vpn you would name it /etc/netns/myvpn/resolv.conf.
>
> Obviously containers don't *have* to follow this model.  I guess there
> is a difference between being "container aware" and being "network
> namespace aware".
>
> Presumably a full container manager (e.g.  docker) would set everything up
> so that tools don't *need* to be container aware.  When you run docker,
> do you get a separate /etc/ from the one outside of docker?  If you
> create /etc/nfs-client-identifier inside the docker container, does it
> remain private to that container?  Does it persist with the container?
>
> Possibly NFS tools don't need to check in /etc/netnfs/NAME as they could
> simply be run with "ip netns exec NAME tool args" which would set up
> /etc.  This is fine for reading config files, but doesn't necessarily
> work correctly for creating config files.
>
> Possibly the goal of having an NFS tool which automatically creates and
> persists a client identifier for the current container is not practical.
> Maybe we just document what any container-creation platform must do for
> NFS, and let them all implement that however seems best.  With the new
> random-identity-at-namespace-creation patch the cost of not doing
> anything is localised to the container

Yes, I think this is the right approach, since all the containers do it
differently.

If there's a simple way to generate and persist a uuid (a small tool to do
so), and a udev rule to move that value to the kernel, that should be
sufficient for a container to use as well as our common case with the host.
When (if?) container folks want persistent ids, We can simply say: the way
to have persistent ids is to run udev in your container with a rule just
like the one on the host.

I can't imagine a container that needs to be persistent for NFS not having
its own /etc, but if it doesn't (say only /var is writeable) the udev rule
can be modififed to send an argument to the tool to change where it stores
the id.  Another way of generating a stable uniquifier might be to just
simply specify a static value in the udev rule itself, or containers might
just come up with their own methods.

On our distro, we want to seed the client id from /etc/machine-id.

> Maybe we should just provide a tool
>    nfs-set-client-identity NAME
> The container setup code provides some "NAME" for the container which it
> is responsible for keeping persistent, and we just write it to
> /sys/fs/nfs/net/nfs_client/idenfier, possibly after hashing or whatever.

Yes, but even better than having the tool do the writing is to have udev do
it, because udev makes the problem of when and who will execute this tool go
away, and the entire process is configurable for anyone that needs to change
any part of it or use their own methods of generating/storing ids.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-08 22:39         ` Steve Dickson
@ 2022-02-10 13:28           ` Benjamin Coddington
  2022-02-10 15:21             ` Chuck Lever III
  2022-02-10 17:11             ` Steve Dickson
  0 siblings, 2 replies; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-10 13:28 UTC (permalink / raw)
  To: Steve Dickson; +Cc: Chuck Lever III, Linux NFS Mailing List

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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 13:28           ` Benjamin Coddington
@ 2022-02-10 15:21             ` Chuck Lever III
  2022-02-10 15:47               ` Benjamin Coddington
  2022-02-10 17:11             ` Steve Dickson
  1 sibling, 1 reply; 33+ messages in thread
From: Chuck Lever III @ 2022-02-10 15:21 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Steve Dickson, Linux NFS Mailing List



> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington <bcodding@redhat.com> 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@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" ?

The client ID can be an arbitrary string, so I think not.



--
Chuck Lever




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 15:21             ` Chuck Lever III
@ 2022-02-10 15:47               ` Benjamin Coddington
  2022-02-10 16:25                 ` Chuck Lever III
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-10 15:47 UTC (permalink / raw)
  To: Chuck Lever III; +Cc: Steve Dickson, Linux NFS Mailing List

On 10 Feb 2022, at 10:21, Chuck Lever III wrote:

>> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington 
>> <bcodding@redhat.com> 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@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" ?
>
> 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?  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 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.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 15:47               ` Benjamin Coddington
@ 2022-02-10 16:25                 ` Chuck Lever III
  2022-02-10 16:41                   ` Benjamin Coddington
  0 siblings, 1 reply; 33+ messages in thread
From: Chuck Lever III @ 2022-02-10 16:25 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Steve Dickson, Linux NFS Mailing List



> On Feb 10, 2022, at 10:47 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
> 
> On 10 Feb 2022, at 10:21, Chuck Lever III wrote:
> 
>>> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington <bcodding@redhat.com> 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@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" ?
>> 
>> 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




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 16:25                 ` Chuck Lever III
@ 2022-02-10 16:41                   ` Benjamin Coddington
  0 siblings, 0 replies; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-10 16:41 UTC (permalink / raw)
  To: Chuck Lever III; +Cc: Steve Dickson, Linux NFS Mailing List

On 10 Feb 2022, at 11:25, Chuck Lever III wrote:

>> On Feb 10, 2022, at 10:47 AM, Benjamin Coddington 
>> <bcodding@redhat.com> wrote:
>>
>> On 10 Feb 2022, at 10:21, Chuck Lever III wrote:
>>
>>>> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington 
>>>> <bcodding@redhat.com> 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@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" ?
>>>
>>> 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

But it doesn't generate client ids either.. the client id is the 
uniquifier
and the nodename and conditionally the address.  I feel thats even more
misleading.

> Since you asked above for other suggestions, I responded here.
> I'll try really hard not to respond again in this thread :)

:)   I got sucked into this thread again too.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 13:28           ` Benjamin Coddington
  2022-02-10 15:21             ` Chuck Lever III
@ 2022-02-10 17:11             ` Steve Dickson
  1 sibling, 0 replies; 33+ messages in thread
From: Steve Dickson @ 2022-02-10 17:11 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Chuck Lever III, Linux NFS Mailing List



On 2/10/22 8:28 AM, Benjamin Coddington 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@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" ?
I can live with this....

steved


> 
> Ben
> 


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 12:25             ` Benjamin Coddington
@ 2022-02-10 22:54               ` NeilBrown
  2022-02-11 13:35                 ` Benjamin Coddington
  0 siblings, 1 reply; 33+ messages in thread
From: NeilBrown @ 2022-02-10 22:54 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Trond Myklebust, steved, linux-nfs

On Thu, 10 Feb 2022, Benjamin Coddington wrote:
> 
> Yes, but even better than having the tool do the writing is to have udev do
> it, because udev makes the problem of when and who will execute this tool go
> away, and the entire process is configurable for anyone that needs to change
> any part of it or use their own methods of generating/storing ids.

I really don't understand the focus on udev.

Something, somewhere, deliberately creates the new network namespace.
It then deliberately configures that namespace - creating a virtual
device maybe, adding an IP address, setting a default route or whatever.
None of that is done by udev rules (is it)?
Setting the NFS identity is just another part of configuring the new
network namespace.

udev is great when we don't know exactly when an event will happen, but
we want to respond when it does.
That doesn't match the case of creating a new network namespace.  Some
code deliberately creates it and is perfectly positioned to then
configure it.

udev is async.  How certain can we be that the udev event will be fully
handled before the first mount attempt?

NeilBrown

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-10 22:54               ` NeilBrown
@ 2022-02-11 13:35                 ` Benjamin Coddington
  2022-02-13 23:24                   ` NeilBrown
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-11 13:35 UTC (permalink / raw)
  To: NeilBrown; +Cc: Trond Myklebust, steved, linux-nfs

On 10 Feb 2022, at 17:54, NeilBrown wrote:

> On Thu, 10 Feb 2022, Benjamin Coddington wrote:
>>
>> Yes, but even better than having the tool do the writing is to have 
>> udev do
>> it, because udev makes the problem of when and who will execute this 
>> tool go
>> away, and the entire process is configurable for anyone that needs to 
>> change
>> any part of it or use their own methods of generating/storing ids.
>
> I really don't understand the focus on udev.
>
> Something, somewhere, deliberately creates the new network namespace.
> It then deliberately configures that namespace - creating a virtual
> device maybe, adding an IP address, setting a default route or 
> whatever.
> None of that is done by udev rules (is it)?
> Setting the NFS identity is just another part of configuring the new
> network namespace.
>
> udev is great when we don't know exactly when an event will happen, 
> but
> we want to respond when it does.
> That doesn't match the case of creating a new network namespace.  Some
> code deliberately creates it and is perfectly positioned to then
> configure it.

I think there's so many ways to create a new network namespace that we 
can't
reasonably be expected to try to insert out problem into all of them.
Handling the event from the kernel allows us to make a best-effort 
default
attempt.

> udev is async.  How certain can we be that the udev event will be 
> fully
> handled before the first mount attempt?

Good point.  We can't at all be certain.

We can start over completely from here..

We can have mount.nfs /also/ try to configure the id.. this is more 
robust.

We can have mount.nfs do a round of udev settle..

Are there other options?

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-11 13:35                 ` Benjamin Coddington
@ 2022-02-13 23:24                   ` NeilBrown
  2022-02-14 11:34                     ` Benjamin Coddington
  0 siblings, 1 reply; 33+ messages in thread
From: NeilBrown @ 2022-02-13 23:24 UTC (permalink / raw)
  To: Benjamin Coddington; +Cc: Trond Myklebust, steved, linux-nfs

On Sat, 12 Feb 2022, Benjamin Coddington wrote:
> On 10 Feb 2022, at 17:54, NeilBrown wrote:
> 
> > On Thu, 10 Feb 2022, Benjamin Coddington wrote:
> >>
> >> Yes, but even better than having the tool do the writing is to have 
> >> udev do
> >> it, because udev makes the problem of when and who will execute this 
> >> tool go
> >> away, and the entire process is configurable for anyone that needs to 
> >> change
> >> any part of it or use their own methods of generating/storing ids.
> >
> > I really don't understand the focus on udev.
> >
> > Something, somewhere, deliberately creates the new network namespace.
> > It then deliberately configures that namespace - creating a virtual
> > device maybe, adding an IP address, setting a default route or 
> > whatever.
> > None of that is done by udev rules (is it)?
> > Setting the NFS identity is just another part of configuring the new
> > network namespace.
> >
> > udev is great when we don't know exactly when an event will happen, 
> > but
> > we want to respond when it does.
> > That doesn't match the case of creating a new network namespace.  Some
> > code deliberately creates it and is perfectly positioned to then
> > configure it.
> 
> I think there's so many ways to create a new network namespace that we 
> can't
> reasonably be expected to try to insert out problem into all of them.

I 100% agree.  Similarly there are lots of init systems and we don't try
to provide configuration for each one to ensure - e.g.  - that sm-notify
is run at the correct time.
But we *do* provide configuration for one - systemd.  This is partly
because it is widely used, but largely because the distro that I
personally help maintain uses it.  So I added those systemd/* files.
(and then others helped improve them).

> Handling the event from the kernel allows us to make a best-effort 
> default attempt.

That "best" effort is not actually very good.

Might I suggest that we take a similar approach to the systemd config.
You choose whatever container system is important to you are the moment,
determine how best to integrate the required support with that system,
make sure the tool works well for that case, provide any config files
that might be generally useful for anyone using that container system,
and in the documentation for the tool explain generally when it must run
and why, and give an example for the system that you know.

If someone else uses a different container system, they are free to
create a solution based on your example, and welcome to submit patches -
either to nfs-utils or to that container system.

Obviously you make the tool reasonably general without over-engineering,
but don't try to solve problems that you don't even know really exist.
I would suggest the tool be passed one of:
 - a unique string 
 - a file containing a unique string
 - a file in which a randomly generated unique string may be stored if
   it doesn't already contain one
 - (maybe) nothing, in which case a new random identity is generate each
   time.  This could be useful for older kernels.

> 
> > udev is async.  How certain can we be that the udev event will be 
> > fully
> > handled before the first mount attempt?
> 
> Good point.  We can't at all be certain.
> 
> We can start over completely from here..
> 
> We can have mount.nfs /also/ try to configure the id.. this is more 
> robust.

If mount.nfs is going to do it, then the "also" is pointless.  There
would be no point in any other code doing it.  However I'm no longer as
keen on mount.nfs as I was.

> 
> We can have mount.nfs do a round of udev settle..

My experience with "udev settle" with md does not make me want to depend
on it.  It has it's place and does useful things, but not always quite
what I want.

> 
> Are there other options?

Document the requirement and make it "someone elses problem".
Your kernel patch to provide a random default mean a lack of
configuration will only hurt the container which lacks it - which nicely
localises the problem.

Thanks,
NeilBrown

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
  2022-02-13 23:24                   ` NeilBrown
@ 2022-02-14 11:34                     ` Benjamin Coddington
  0 siblings, 0 replies; 33+ messages in thread
From: Benjamin Coddington @ 2022-02-14 11:34 UTC (permalink / raw)
  To: NeilBrown; +Cc: Trond Myklebust, steved, linux-nfs

On 13 Feb 2022, at 18:24, NeilBrown wrote:
> Document the requirement and make it "someone elses problem".
> Your kernel patch to provide a random default mean a lack of
> configuration will only hurt the container which lacks it - which nicely
> localises the problem.

I thought of another approach which was to have either mount.nfs or the
kernel emit a warning if a client is not uniquified.

Ben


^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2022-02-14 11:43 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-04 12:56 [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers Benjamin Coddington
2022-02-04 15:17 ` Chuck Lever III
2022-02-04 15:49   ` Benjamin Coddington
2022-02-04 18:45     ` Chuck Lever III
2022-02-04 19:44       ` Benjamin Coddington
2022-02-05 17:35         ` Chuck Lever III
2022-02-08  3:14       ` NeilBrown
2022-02-08 11:43         ` Benjamin Coddington
2022-02-08 16:04 ` Steve Dickson
2022-02-08 16:21   ` Chuck Lever III
2022-02-08 19:29     ` Steve Dickson
2022-02-08 21:18       ` Chuck Lever III
2022-02-08 22:39         ` Steve Dickson
2022-02-10 13:28           ` Benjamin Coddington
2022-02-10 15:21             ` Chuck Lever III
2022-02-10 15:47               ` Benjamin Coddington
2022-02-10 16:25                 ` Chuck Lever III
2022-02-10 16:41                   ` Benjamin Coddington
2022-02-10 17:11             ` Steve Dickson
2022-02-08 16:22   ` Benjamin Coddington
2022-02-08 19:52     ` Steve Dickson
2022-02-08 20:00       ` Benjamin Coddington
2022-02-08 22:30         ` Steve Dickson
2022-02-09 13:55           ` Benjamin Coddington
2022-02-09 15:23             ` Steve Dickson
2022-02-09 21:21       ` NeilBrown
2022-02-09 21:45         ` Trond Myklebust
2022-02-09 23:58           ` NeilBrown
2022-02-10 12:25             ` Benjamin Coddington
2022-02-10 22:54               ` NeilBrown
2022-02-11 13:35                 ` Benjamin Coddington
2022-02-13 23:24                   ` NeilBrown
2022-02-14 11:34                     ` Benjamin Coddington

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.