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

["NeilBrown" <neilb@suse.de>]

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