[fedfs-utils] [PATCH] FedFS - simple setup howto
Chuck Lever
chuck.lever at oracle.com
Wed Aug 29 13:53:52 PDT 2012
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.
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.
> 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.
Let me know if I misunderstood.
[ … 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).
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.
> For example, the OpenLDAP change to the directory based setup under
> slapd.d is problematic when setting up a test instance. Even though
> removing slapd.d and just using slapd.conf will work (still I believe)
> it probably isn't a good idea to do it that way since the ability to use
> slapd.conf might be removed at some point. Another issue is that if the
> suffix (the dc=fedfs,dc=org) is changed and a default installed database
> exists then, AFAICT, the LDAP database must be deleted and re-created.
> Not only that, it appears that the directory based configuration can't
> be properly updated in this case and must be re-created, but I probably
> just don't know how to do it. Finally, at least on Fedora, the ownership
> (and selinux context settings) must be correct for the LDAP server to
> start.
>
> So I think we need to capture this somewhere but probably not right
> here.
>
>>
>>> +
>>> +4. Add NCI (NSDB Container information) attributes to the
>>> + naming context LDAP entry:
>>> + nsdb-update-nci -l zeus.fedfs.org \
>>> + -D "cn=Manager,dc=fedfs,dc=org" \
>>> + -e "dc=fedfs,dc=org"
>>> +
>>> +
>>> +Add a FedFS junction within a domain root directory
>>> +===================================================
>>> +
>>> +Assuming there is a file system mounted on /vm (or just a directory
>>> +we can export) on server zues.fedfs.org which we want to access
>>> +under the domain root as <domain root mount point>/vm, we will be
>>> +exporting /.domainroot-fedfs.org as the domain root.
>>> +
>>> +1. Add an entry to /etc/exports on zeus.fedfs.org:
>>> +
>>> + # Add to /etc/exports
>>> + /vm *(ro)
>>> +
>>> + # Restart the nfs service or just re-export the table
>>> + exportfs -r
>>
>> Why not just create and export a directory called
>> "/.domainroot-fedfs.org" here? Alternatively you could describe how to
>> use a bind mount to export some other FS as "/.domainroot-fedfs.org."
>
> This is out of order.
>
> The exporting of the root domain on perseus below should have come
> before this. And using only two machines lends to confusion mmm ....
>
>>
>>> +
>>> +2. Add a junction to the domain root on persues.fedfs.org:
>>
>> Actually, the domain root is the top of the namespace tree, so you
>> should create junctions in the domain root, not point junctions to it.
>
> Right but I think the aim of having the referral on a different machine
> and the out of order procedure has obscured this.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
More information about the fedfs-utils-devel
mailing list