Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Benjamin Coddington" <bcodding@redhat.com>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: v4 clientid uniquifiers in containers/namespaces
In-reply-to: <A677D8A9-FD0B-43E5-82D6-E660CCB8B185@redhat.com>
References: <6CEC5101-0512-4082-81F8-BDFEC5B6DF3A@redhat.com>,
 <164428557862.27779.17375354328525752842@noble.neil.brown.name>,
 <A677D8A9-FD0B-43E5-82D6-E660CCB8B185@redhat.com>
Date:   Wed, 09 Feb 2022 07:56:00 +1100
Message-id: <164435376000.27779.4059629372785561121@noble.neil.brown.name>
Precedence: bulk

On Tue, 08 Feb 2022, Benjamin Coddington wrote:
> On 7 Feb 2022, at 20:59, NeilBrown wrote:
>=20
> > On Sun, 06 Feb 2022, Benjamin Coddington wrote:
> >> Hi all,
> >>
> >> Is anyone using a udev(-like) implementation with NETLINK_LISTEN_ALL_NSI=
D?
> >> It looks like that is at least necessary to allow the init namespaced ud=
ev
> >> to receive notifications on /sys/fs/nfs/net/nfs_client/identifier, which
> >> would be a pre-req to automatically uniquify in containers.
> >
> > Could you walk me through the reasoning here - or point me to where it
> > has been discussed.
>=20
> https://lore.kernel.org/linux-nfs/20210414181040.7108-1-steved@redhat.com/

Thanks.  I did remember that discussion though it was helpful to refresh
my memory, and to be sure there is nothing else.

>=20
> > It seems to me that mount.nfs is the place to set nfs_client/identifier.
> > It can be told (via /etc/nfs.conf or /etc/nfsmount.conf) how to generate
> > and where to store the identifier.  It can check the current value and
> > update if needed.  As long as the identifier is set before the first
> > mount, there is no rush.
> >
> > Why does it need to be done in response to a uevent??
>=20
> I think the assertion was that it was the only sensible way, and it does
> seem to be better than exposing yet another knob when all that's needed is a
> way to distinguish and persist NFS clients when network namespaces can come
> and go at any time, and there can be a lot of them.

"assertion" is an apt word.  There wasn't a whole lot of reasoned
argument, mostly just assertions.

The best argument was that "nfs.conf is not namespace aware", which is
only somewhat true.  Using "ip netnfs exec" will make
non-namepsace-aware tools work correctly in namespaces providing their
config files are in /etc/netns/NAME - they get bind-mounted over the
files in /etc.
And of course /etc/nfs.conf can be MADE namespace aware.

There is also a reasonable argument that auto-editiing /etc/nfs.conf
risks collision with an admin, but that is why we have /etc/nfs.conf.d

For me, the weakest part of the Steve's case was that he presented it as
"setting module parameters via nfs.conf" rather than "configuring client
identity via nfs.conf".  A number of the early negative responses were
focused on the distraction of a module parameter being involved.

The weakness for the alternative, of course, is the fact that using the
udev mechanism requires running udevd in each network namespace, which
is an unnecessary burden.

So I still STRONGLY think that the identity should be set by mount.nfs
reading (and writing) some file in /etc or /etc/netnfs/NAME, and I
weakly think that the file should be in /etc/nfs.conf.d/ so that the
reading is automagic.

Thanks,
NeilBrown