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: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Benjamin Coddington" <bcodding@redhat.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
In-reply-to: <26803BBB-4F2C-4EFD-BC8D-A50A5C361E5C@oracle.com>
References: =?utf-8?q?=3Cc2e8b7c06352d3cad3454de096024fff80e638af=2E16439791?=
 =?utf-8?q?61=2Egit=2Ebcodding=40redhat=2Ecom=3E=2C?=
 <87EAC6F6-C450-4642-A11A-55247C791D66@oracle.com>,
 <32889B9A-1293-4050-8131-726042D1EAD9@redhat.com>,
 <26803BBB-4F2C-4EFD-BC8D-A50A5C361E5C@oracle.com>
Date:   Tue, 08 Feb 2022 14:14:21 +1100
Message-id: <164429006120.27779.2597672223372340780@noble.neil.brown.name>
Precedence: bulk

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