Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     NeilBrown <neilb@suse.de>
Cc:     "Chuck Lever III" <chuck.lever@oracle.com>,
        "Steve Dickson" <steved@redhat.com>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4
 client uniquifiers
Date:   Tue, 08 Feb 2022 06:43:54 -0500
Message-ID: <0BDE59B8-C1FE-4B04-AB89-F65AD37AA8AC@redhat.com>
In-Reply-To: <164429006120.27779.2597672223372340780@noble.neil.brown.name>
References: <c2e8b7c06352d3cad3454de096024fff80e638af.1643979161.git.bcodding@redhat.com>
 <87EAC6F6-C450-4642-A11A-55247C791D66@oracle.com>
 <32889B9A-1293-4050-8131-726042D1EAD9@redhat.com>
 <26803BBB-4F2C-4EFD-BC8D-A50A5C361E5C@oracle.com>
 <164429006120.27779.2597672223372340780@noble.neil.brown.name>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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