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