[Federated-fs] discussion on bootstrapping clients

[Spencer Shepler]

On May 17, 2008, at 7:10 PM, Ellard, Daniel wrote:

>
> Regarding the automounter, yes, this could be done by a module in
> something extensible like autofs.  That would be a fine vehicle for
> getting the top-level working, but that doesn't addess all of the
> issues.  The first issue is what the autofs module needs to do to get
> the info it requires (not a big deal, but it needs to be speced).  The
> second, and in my opinion more important, issue is about  
> configuration.
> Right now, when I set up autofs on a new unixy machine, I have to copy
> several scripts and config files and create some directories and
> symlinks (and these operations require root or sudo) -- and these are
> neither portable nor user-friendly.  I'd like to improve on that.   
> We'd
> really like users to be able to utter a reasonably mnemonic name  
> for the
> the filesystem they want, and have it appear in their namespace (if
> accessible, etc) without any more fuss.

This is my opinion as well.  In short, any configuration to enable
this feature other than turning the switch to "on" is too burdensome.
The feature set may be contained within the automounter as an
implementation choice but there must be one switch and a reasonable
standard of defacto to specified behavior that leads to usefulness.

Spencer

>
> I think this is consistent with your last paragraph, but it never  
> hurts
> to be sure...
>
> -Dan
>
> -----Original Message-----
> From: Paul Lemahieu [mailto:LeMahieu_Paul at emc.com]
> Sent: Friday, May 16, 2008 9:22 PM
> To: federated-fs at sdsc.edu
> Subject: [Federated-fs] discussion on bootstrapping clients
>
> I had a talk with a few engineers here today, to get their opinions on
> the sort of client behavior they'd like to see.
>
> Here are a few key points I heard:
>     * Rely on DNS SRV records
>     * This is really automount functionality
>     * Lookup by domain, most likely set via DHCP. Mount each domain  
> for
> which a SRV record exists. For example, you'd automount both /net/
> pasadena.emc.com and /net/emc.com, if SRV records existed.
>     * Have DNS return value include both hostname and path to mount (I
> was told it's possible, I'd have to look into that to understand  
> more).
> It was felt that simply mounting / on the given host wouldn't be
> flexible enough. For example, if you ever need to move / from  
> fileserver
> A to a subdirectory on fileserver B, but want to continue showing the
> same world, what do you do?
>     * Any more "local and friendly" names, which were referred to as
> aliases, got a less than warm welcome. For example, say EMC IT wanted
> everyone to see /net/emc or even /emc. Should there be any way to do
> that?
>
> The biggest benefit was that simply automatically mounting anything is
> the real benefit. That gets the client to the point where it has
> something it can browse.
>
> --Paul