On Thu, 10 Feb 2022, Trond Myklebust wrote:
> On Thu, 2022-02-10 at 08:21 +1100, NeilBrown wrote:
> >
> > I'm not sure if this has been explicitly answered or not, so just in
> > case...
> > if "ip netns/identify" report NAME, then use /etc/netns/NAME/foo
> > if it fails or report nothing, use /etc/foo
> >
> > I think this is required whether we use nfs4-id, nfs-id, nfs-
> > identity,
> > nfs.conf.d/identity.conf or any other file in /etc.
> >
>
> Who uses this tool, and for what? This isn't anything that the standard
> container orchestration managers use.
At a guess, I'd say it would be used by anyone who just wants to set up
a separate network namespace, not necessarily a full "container".
>
> I'm running docker right now:
>
> NR_09-21:41:07 host ~ $ ls /etc/net*
> /etc/netconfig /etc/networks
> NR_09-21:41:47 hosts ~ $ docker exec -it f7debc079f4e bash
> [root@f7debc079f4e /]# ls /etc/net*
> /etc/netconfig /etc/networks
> [root@f7debc079f4e /]# ip netns identify
>
> [root@f7debc079f4e /]#
>
> As you can see, neither the host nor the container have anything in
> /etc/netns, and 'ip netns identify' is drawing a blank in both.
>
One of the original reasons given to reject the idea of using
/etc/nfs.conf{,.d} was that is wasn't "container aware".
I tried to find out what this might mean and discovered "ip netnfs" and
its man page which says:
For applications that are aware of network namespaces, the convention
is to look for global network configuration files first in
/etc/netns/NAME/ then in /etc/. For example, if you want a different
version of /etc/resolv.conf for a network namespace used to isolate
your vpn you would name it /etc/netns/myvpn/resolv.conf.
Obviously containers don't *have* to follow this model. I guess there
is a difference between being "container aware" and being "network
namespace aware".
Presumably a full container manager (e.g. docker) would set everything up
so that tools don't *need* to be container aware. When you run docker,
do you get a separate /etc/ from the one outside of docker? If you
create /etc/nfs-client-identifier inside the docker container, does it
remain private to that container? Does it persist with the container?
Possibly NFS tools don't need to check in /etc/netnfs/NAME as they could
simply be run with "ip netns exec NAME tool args" which would set up
/etc. This is fine for reading config files, but doesn't necessarily
work correctly for creating config files.
Possibly the goal of having an NFS tool which automatically creates and
persists a client identifier for the current container is not practical.
Maybe we just document what any container-creation platform must do for
NFS, and let them all implement that however seems best. With the new
random-identity-at-namespace-creation patch the cost of not doing
anything is localised to the container
Maybe we should just provide a tool
nfs-set-client-identity NAME
The container setup code provides some "NAME" for the container which it
is responsible for keeping persistent, and we just write it to
/sys/fs/nfs/net/nfs_client/idenfier, possibly after hashing or whatever.
NeilBrown
