[fedfs-utils] [PATCH] FedFS - simple setup howto

[Ian Kent]

On Wed, 2012-08-29 at 13:53 -0700, Chuck Lever wrote:
> On Aug 28, 2012, at 8:45 PM, Ian Kent wrote:
> 
> > On Mon, 2012-08-27 at 08:24 -0700, Chuck Lever wrote:
> >> Hi Ian-
> >> 
> >> FYI, we've got a patchwork repository, your patch is now here:
> >> 
> >>  http://patchwork.ozlabs.org/patch/180159/
> >> 
> >> And I marked it "Under Review."  Thanks for tackling this.  Overall,
> >> the organization is right, but the details need a little work, and
> >> hopefully I've given you some pointers in the right direction.
> >> 
> >> Also there is an INSTALL file in the tar ball.  Should we augment that
> >> instead?
> > 
> > Not sure. I think we'll have to wait and see what we end up with before
> > deciding that. The scope is a bit to broad to be included in install
> > instructions at this stage.
> > 
> >> 
> >> 
> >> On Aug 27, 2012, at 2:28 AM, Ian Kent wrote:
> >> 
> >>> Add a howto to setup a DNS domain fedfs.org, an (OpenLDAP) LDAP
> >>> instance with context dc=fedfs,dc=org and work through the steps
> >>> to setup a read-only FedFS root domain with a single referral.
> >>> 
> >>> Signed-off-by: Ian Kent <raven at themaw.net>
> >>> ---
> >>> 
> >>> doc/howto/fedfs-simple-setup-howto.txt |  465 ++++++++++++++++++++++++++++++++
> >>> 1 files changed, 465 insertions(+), 0 deletions(-)
> >>> create mode 100644 doc/howto/fedfs-simple-setup-howto.txt
> >>> 
> >>> diff --git a/doc/howto/fedfs-simple-setup-howto.txt b/doc/howto/fedfs-simple-setup-howto.txt
> >>> new file mode 100644
> >>> index 0000000..6454f64
> >>> --- /dev/null
> >>> +++ b/doc/howto/fedfs-simple-setup-howto.txt
> >>> @@ -0,0 +1,465 @@
> >>> +
> >>> +Simple example of basic FedFS setup and operation
> >>> +=================================================
> >>> +
> >>> +The examples in this test procedure assume a Fedora 18 install.
> >>> +
> >>> +Assume that the package fedfs-utils-server and fedfs-utils-client
> >>> +are installed on perseus.fedfs.org. And that fedfs-utils-server and
> >>> +a nfs-utils built with fedfs-utils-devel installed on zeus.fedfs.org
> >>> +and that fedfs-utils-lib is also installed on zeus.fedfs.org.
> >> 
> >> Since fedfs-utils is nominally the "upstream" version, we should
> >> discuss the tar ball installation procedure here, and not a particular
> >> distributor's package installation.
> > 
> > OK, so that just means saying something like fedfs-utils has been build
> > and installed on each machine, right.
> > 
> >> 
> >>> +
> >>> +We want to setup perseus.fedfs.org to provide the domain root,
> >>> +be able to use FedFS to mount the domain root, and to setup and
> >>> +use a FedFS juntion to access an export on zeus.fedfs.org upon
> >>> +access to a directory within the domain root. And lastly, setup
> >>> +autofs to use the FedFS program map to mount the root of the
> >>> +domain.
> >> 
> >> There are five roles in a FedFS domain: file server, filesystem client,
> >> NSDB, NSDB admin client, and DNS server.  I find that helps organize
> >> the set-up steps.
> >> 
> >> It's not always clear below where you are switching between perseus and
> >> zeus, nor which host is running the forwarding DNS or the LDAP
> >> service.  It would be good to clarify that.  But also I think at least
> >> the filesystem client (which mounts the domain root or which runs
> >> autofs) ought to be a separate host.
> > 
> > That did get a bit lost in writing this.
> > 
> > The idea was to use only two machines, one for LDAP, DNS and NSDB, and
> > as an NFS server with a single export to be used as a referral
> > (specifically an export on a different machine from the machine
> > exporting the domain root) and a client which was also an NFS server
> > exporting the domain root.
> > 
> > This division happened because I had easy access to two machines.
> > I'm not sure that's a bad thing though because using only two machines
> > will make it easier for someone to play with the functionality before
> > starting out on setting up something in a production testing
> > environment.
> > 
> > The other goal of the procedure was to outline how to setup a domain
> > root that is stand-alone and independent of an exiting environment so
> > that setup in a production test environment is a straight forward
> > extension of the procedure.
> 
> If you stick with two machines, it might help if the domain root was
> exported from the DNS/NSDB system, and the second export was on the
> client.

OK, I'll do that.

The other thing that occurs is we could assume there are several names
like ldap.fedfs.org, nsdb.fedfs.org etc. and, as long as the name is
used when referred to in the procedure, it would be clear what the
target is. That should make the description independent of the number of
machines used.

> 
> Or, something incremental, like:
> 
> 1.  Set up the /.domainroot export and create some basic junctions
> 
> 2.  Make it discoverable by adding the DNS SRV record and setting up
> the client's auto mounter program map
> 
> 3.  Set up the NSDB and create real FedFS junctions in the domain root
> 
> Each step gives more flexibility, but there is something useful going
> on after each step is complete.

OK.

> 
> > The thing that is still missing I think is usage of sub domains (either
> > delegated or included within an existing DNS configuration). But I don't
> > think we have a discovery protocol yet anyway.
> 
> If I understand correctly, I don't think FedFS has "subdomains." 
> Junctions can appear anywhere in the domain's namespace, in any
> export.  They can even refer to other domains.  But as far as I know
> there isn't the concept of a hierarchy of domains.  The top level
> directory of /nfs4 is a flat namespace.

I'm thinking of just the top level.

There's nothing stopping someone setting up multiple name spaces.

For example, assume you have a domain company.com and you've divided
your DNS up like:

company.com
sales.company.com
engineering.company.com

AFAICS each of these can have a name space accessed via:

/nfs4/company.com
/nfs4/sales.company.com
/nfs4/engineering.company.com

and these sub-domains could be actually delegated in the top level
domain or just prefixed names within the company.com DNS.

I admit it isn't great to have the root domain and sub-domains at the
same level but I think this can be done and people with larger name
spaces will likely do it.

Maybe there's an opportunity to think a bit about this before people
start asking for a hierarchic name spaces, although it is out of scope
for this task.

> 
> [ … snip … ]
> 
> > 
> >> 
> >>> +
> >>> +2. Setup an OpenLDAP instance for fedfs.org:
> >>> +	service slapd stop
> >>> +or
> >>> +	systemctl stop slapd.service
> >>> +
> >>> +Create /etc/openldap/slapd.conf as:
> >>> +        include         /etc/openldap/schema/core.schema
> >>> +        include         /etc/openldap/schema/cosine.schema
> >>> +        include         /etc/openldap/schema/inetorgperson.schema
> >>> +        include         /etc/openldap/schema/nis.schema
> >>> +	# Get this from the FedFS distribution
> >>> +        include         /etc/openldap/schema/fedfs.schema
> >>> +
> >>> +        pidfile         /var/run/openldap/slapd.pid
> >>> +        argsfile        /var/run/openldap/slapd.args
> >>> +
> >>> +        database        bdb
> >>> +        suffix          "dc=fedfs,dc=org"
> >>> +        rootdn          "cn=Manager,dc=fedfs,dc=org"
> >>> +        rootpw          secret
> >>> +        directory       /var/lib/ldap
> >>> +
> >>> +        index objectClass                       eq,pres
> >>> +        index ou,cn,mail,surname,givenname      eq,pres,sub
> >>> +        index uidNumber,gidNumber,loginShell    eq,pres
> >>> +        index uid,memberUid                     eq,pres,sub
> >>> +        index nisMapName,nisMapEntry            eq,pres,sub
> >>> +
> >>> +Create fedfs.org-naming-context.ldif as:
> >>> +	dn: dc=fedfs,dc=org
> >>> +	objectClass: domain
> >>> +	dc: fedfs
> >>> +	description: naming context
> >>> +
> >>> +Create an OpenLDAP instance for fedfs.org:
> >>> +	# Ensure that /etc/openldap/ldap.conf is setup to use fedfs.org
> >>> +	# by commenting out any other URI and BASE directives and then
> >>> +	# add definitions to the end of the configuration.
> >>> +	echo "URI ldap://zeus.fedfs.org/" >> /etc/openldap/ldap.conf
> >>> +	echo "BASE dc=fedfs,dc=org" >> /etc/openldap/ldap.conf
> >>> +
> >>> +	# Setup OpenLDAP for fedfs.org
> >>> +	cd /etc/openldap
> >>> +	restorecon -v slapd.conf
> >>> +
> >>> +	rm -f /var/lib/ldap/*
> >>> +	# supress warnings that this file does not exist
> >>> +	touch /var/lib/ldap/DB_CONFIG
> >>> +
> >>> +	rm -rf slapd.d
> >>> +	slaptest -F slapd.d -f slapd.conf
> >>> +	# I think this will restore the correct ownership
> >>> +	# of the configuration directory tree but it may
> >>> +	# be necessary to chmod -R ldap.ldap slapd.d also.
> >>> +	restorecon -R -v slapd.d
> >>> +
> >>> +	slapadd -l fedfs.org-naming-context.ldif
> >>> +	chown ldap.ldap /var/lib/ldap/*
> >>> +	restorecon -v /var/lib/ldap/*
> >>> +
> >>> +	service slapd start
> >>> +or
> >>> +	systemctl start slapd.service
> >> 
> >> Is all of this necessary to include here?  I'm a detail-oriented
> >> person, but I'm little concerned about how long these instructions are
> >> (for DNS and LDAP set-up), since it gives the impression of a lot of
> >> complexity (yes, I know, there are already a lot of moving parts
> >> here).  But one would hope that installing and configuring an LDAP
> >> server would be simpler…
> > 
> > That was the dilemma when I set out to do this.
> > 
> > The aim of having a procedure to setup something completely standalone
> > means that we need this stuff somewhere but it completely obscures the
> > actual message of FedFS usage.
> > 
> > The DNS configuration is fairly standard and much of the configuration
> > would be present in any caching nameserver install so not a lot more is
> > needed.
> > 
> > But LDAP has proved to be rather painful over time and there are
> > elements in the procedure that are useful for demonstrating those
> > gotchas so it's worth keeping somewhere.
> 
> This is the crux… LDAP is complicated, and the set up recipes depend
> explicitly on which LDAP server is in use.  That's exactly why I have
> provided NSDB admin tools specifically for setting up the NCI, but I
> agree that's not yet enough.  Here's where we can use some thought
> about how to make this a simpler process.
> 
> For example, if we stick to keeping NSDB records under the LDAP
> server's default domain controller naming context (dc=example,dc=net),
> which should be created automatically by the LDAP server's installation
> procedure, and not use a brand new naming context (o=fedfs) maybe there
> is less LDAP specific set up required (i.e., we can manage more of the
> set up with the server's default set up instructions, plus a generic
> tool to turn it into an NSDB).

OK, that sounds like a good idea, I'll give that a try.

The other possibility, in order to retain the information, is to break
it out into a separate howto for OpenLDAP "hints" perhaps.

The same can be said of the DNS configuration steps, put that into a
separate howto and then reference them in the preamble as assumptions
about existing setup so that the actual FedFS procedure is clean and
straight forward.

> 
> Btw, your recipe may be missing a step: where is the FedFS schema
> installed on the LDAP server?  I'm trying to make that step unneeded by
> having the LDAP vendors include the schema in their distribution
> packaging, but that hasn't happened yet.

Yeah, that's something that should have been left out of the slapd.conf
above and added as a separate step.

Ian