Subject: [nfsv4] [FedFS] Root fileset questions

From: <[email-masked]>
Date: Wed, 9 Dec 2009 22:03:15 -0500

Another possible topic for discussion in tomorrow's FedFS call.

We have been talking about using DNS SRV records to locate file servers
that export the root fileset for a namespace.    But how does a file
server wanting to export the root of a namespace know what that root
fileset contains? 

R15(b) of the requirements spec
(http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-reqts-06.txt) says
that the contents of the root fileset are defined/stored in the NSDB.

R15(b) also says that it should be possible for the a fileserver to
locate an NSDB that stores the layout of a root fileset.

I can't remember where it is specified but the root fileset can contain
only directories and junctions.    

R15(g) says that each file server wishing to provide access to the root
of a namespace must render a representation of the root fileset for the
namespace by extracting the definition from the NSDB for that namespace.

I have a few questions related to the above...

(1) How does the file server know which NSDB to query to find out the
contents of the root fileset for a given namespace?     Doesn't it need
a special 'root junction' that identifies the authoritative NSDB for the
root fileset for the namespace?

(2) Given that a root fileset can contain junctions and directories and
it is stored in the NSDB, do we not need LDAP objectclass definitions
for junctions and directories in the NSDB?    Forgive me if I missed
them, I just expected to find them in section 4.2 of
http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-protocol-03bis.txt.

Following from #2, it would be helpful to include equivalent  LDAP
examples for junctions and directories in the NSDB in section 5.1 of the
protocol specification. 

(3)  R15(d) says that the root fileset definition must be able to be
replicated between NSDBs.    That, and file server rendering the root
fileset to clients, leads to the question - how do replica NSDB's and/or
file servers that want to render the root fileset get updates?    The
fedfs-rootfileset draft that Renu circulated back in Sep. '08 says that
this was discussed but no conclusion reached (thanks for digging that
out for me James).   Seem like we need to come to a conclusion on this.

(4) What is the authentication model for access to the contents of the
root file set?  AUTH_NONE, AUTH_SYS?   I think this is the question that
came up recently and started me looking into all this.

(5) What is the security model within the root file set?  Completely
open?   Un-modifiable mode bits and ACLs that are open (read-only) to
all?

Thanks,

Chris

-- 
Chris Stacey - Senior Technologist, Celerra Unified Storage Engineering,
EMC Corporation (New Zealand).  Phone: +64 21 225 3747

---

From: James Lentini <[email-masked]>
Date: Thu, 10 Dec 2009 11:22:57 -0500 (EST)

On Wed, 9 Dec 2009, [email-masked] wrote:

> 
> Another possible topic for discussion in tomorrow’s FedFS call.

Yes, we can discuss this on the call today as well.

We intentionally separated the standardization of a root fileset for 
the rest of the FedFS protocols. I sent an email to the WG mailing 
list last April describing this plan:

http://www.ietf.org/mail-archive/web/nfsv4/current/msg06981.html

The focus and interest has been on the core FedFS protocols. We've 
informally discussed a root fileset definition, but an official IETF 
proposal has not been made yet.

> We have been talking about using DNS SRV records to locate file servers that
> export the root fileset for a namespace.    But how does a file server
> wanting to export the root of a namespace know what that root fileset
> contains?

A root fileserver may export a normal filesystem (perhaps replicated 
between multiple fileservers) or a root fileserver may export a root 
fileset. In the former case, a root fileset is not necessary.

> that the contents of the root fileset are defined/stored in the NSDB.   

That may be an implication of this requirement.

The exact text is:

         b.  It SHOULD be possible for a fileserver to locate an NSDB
             that stores the layout of a root fileset.

Since the structure of the root fileset has not been defined, there is 
still some flexibility on what the NSDB stores.

> R15(b) also says that it should be possible for the a fileserver to locate
> an NSDB that stores the layout of a root fileset.
> 
> I can’t remember where it is specified but the root fileset can contain only
> directories and junctions.   

This was the consensus in our discussions on the topic. As I 
mentioned, a formal specification of the root fileset has not been 
proposed yet.
 
> R15(g) says that each file server wishing to provide access to the root of a
> namespace must render a representation of the root fileset for the namespace
> by extracting the definition from the NSDB for that namespace.

It is a SHOULD, not a MUST, and then only "If a root fileset is 
defined".

> I have a few questions related to the above…
> 
>  
> 
> contents of the root fileset for a given namespace?     Doesn’t it need a
> special ‘root junction’ that identifies the authoritative NSDB for the root
> fileset for the namespace?
> 

Again, there isn't a definitive root fileset specification, so it 
could be defined to work in many different ways. 

A special 'root junction' would be one possibility.

Another option would be to use the standard FedFS junction and FSN 
format, but define a special root FSL. Recall that there is already an 
FSL LDAP object hierarchy with a fedfsFsl superclass and a fedfsNfsFsl 
subclass. A 'fedfsRootFsl' could be defined for the root fileset.

I'm sure that there are other options as well.

> 
> (2) Given that a root fileset can contain junctions and directories and it
> is stored in the NSDB, do we not need LDAP objectclass definitions for
> junctions and directories in the NSDB?    Forgive me if I missed them, I
> just expected to find them in section 4.2 of

If the root was rendered from an NSDB-based image, then one or more 
LDAP objects would be necessary. Again, if the root is a standard 
filesystem, then no NSDB-based image is necessary.

> 
> Following from #2, it would be helpful to include equivalent  LDAP examples
> for junctions and directories in the NSDB in section 5.1 of the protocol
> specification.
> 

I think examples would make sense in a specification describing the 
root fileset, not in the NSDB specification.

> replicated between NSDBs.    

This is a SHOULD, not a MUST.

> That, and file server rendering the root
> fileset to clients, leads to the question – how do replica NSDB's and/or
> fedfs-rootfileset draft that Renu circulated back in Sep. '08 says that this
> was discussed but no conclusion reached (thanks for digging that out for me
> James).   Seem like we need to come to a conclusion on this.
> 
>  

I agree, this is an area that would need to be well defined in a root 
fileset specification.

> (4) What is the authentication model for access to the contents of the root
> file set?  AUTH_NONE, AUTH_SYS?   I think this is the question that came up
> recently and started me looking into all this.
> 
>  
> 
> (5) What is the security model within the root file set?  Completely open? 
>  Un-modifiable mode bits and ACLs that are open (read-only) to all?
> 
>  

Security is another area that would need to be well defined in a root 
fileset specification. We've discussed this topic in the past, but I 
don't remember coming to any conclusions.

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 13:07:50 -0500

There I go reading too much into SHOULD's rather than MUST's again.  Sorry about that.

I look forward to discussing further whenever we have time (today or future).

Thanks
Chris

-----Original Message-----
From: James Lentini [mailto:[email-masked]] 
Sent: Friday, 11 December 2009 5:23 a.m.
To: Stacey, Chris
Cc: [email-masked]
Subject: Re: [nfsv4] [FedFS] Root fileset questions

The exact text is:

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Dec 2009 11:33:46 -0600

> mentioned, a formal specification of the root fileset has not been 

A limit on root filesets to directories and junctions does follow if the
contents of a root fileset is published in the NSDB (which might publish
only junctions, with all directories down from / being implied).

This also implies limitations on access controls for root fileset
contents.

> could be defined to work in many different ways. 

Indeed.

> I'm sure that there are other options as well.

It could be configured locally, or published in DNS (e.g., via a TXT RR).

> > James).   Seem like we need to come to a conclusion on this.

For root filesets consisting of junctions published in an NSDB the
servers would have to know to periodically search for new/deleted/
renamed junctions.  IIRC there's a way to get update notifications from
LDAP as well, but I suspect that periodic lookups will be the simplest
update method.

> don't remember coming to any conclusions.

If root fileset contents is to be replicated we must either:

a) Not specify how to replicate it, potentially leading to non-
   heterogeneous root deployments; sadness would ensue, but we'd live;

b) Specify a replication protocol; this could get hairy;

c) Specify a simplified replication protocol (e.g., one master sending
   out tarballs);

d) Simplify the root fileset so much that publishing its contents via
   LDAP, where replication is already provided by existing off-the-shelf
   components, is simple and realistic;

   (Note that for LDAP there's going to be homogeneous NSDB deployments.
   So, (d) is not really a solution to the homogeneity problem in (a).)

All of these options have downsides.  We needn't do anything for (a) --
it's the simplest solution.  (b) is the best approach, but also utterly
not realistic.  (c) strikes me as a good possibility, but only if
there's a realistic chance that we could reach consensus on an archive
format that gives us everything that we need (files, directories,
junctions, including ACLs).  (d) strikes me as a good possibility, but
with poorer security semantics than (c).

Back to security: (d) pretty much implies that everything is wide open
for read and lookup access in the root fileset, which answers (5).  That
answer also answers (4): AUTH_NONE is sufficient.  To do better than
that with (d) would nullify the advantages of (d).

Nico
--