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
