[fedfs-utils] Configuring FedFS domain roots

[J. Bruce Fields]

On Tue, Apr 09, 2013 at 02:01:09PM -0400, Chuck Lever wrote:
> Asking the NFS server gurus....
> 
> As part of the next release of fedfs-utils, I'd like to provide more tools that can hide the details of setting up a FedFS domain.  One of the first tasks when setting up a domain is to create a FedFS domain root directory.  Here are the instructions I provide for fedfs-utils 0.9 (the latest release):
> 
>   http://wiki.linux-nfs.org/wiki/index.php/FedFsNfsDomainRoot0.9
> 
> I'm kind of brainstorming about this right now, not necessarily attached to any particular solution or to the naive way we are doing it now.
> 
> It would be nice if we had a tool that would ensure that all the NFS-related infrastructure was in place:
> 
>   o  Starting and enabling the NFS service as needed
>   o  Verifying the junction resolution plug-in is installed
>   o  Setting up the /.domainroot export if it doesn't exist
> 
> The tool would have the administrator simply specify the name of new domain.  The outcome would be a directory like "/.domainroot/example.net" that would be automatically exported with the correct security flavors and other settings. The NFS server that shares a domain root can be used for more than one domain root, so this process could be done more than once on a particular NFS server.
> 
> Afterwards, an administrator would use nfsref or mkdir to customize the contents of the domain root directory.  We could have the tool create junctions in the domain root directory, no files or directories.  Not sure if that's useful: could be a simplification for our administrative interface, and we could continue to allow arbitrary "mkdir" and "nfsref" in this directory, like any other exported directory, but those would not be managed with the setup tool.
> 
> On NFS servers I've set up for this purpose, I create a separate logical volume with a filesystem mounted at /.domainroot.  This avoids exporting a piece of / on the server.  But maybe there's a better way to go about this.

Sounds OK to me.  Some kind of in-memory filesystem would work, I guess?

--b.
> 
> 
>