[Freeipa-devel] automount in LDAP

[Rob Crittenden]

Simo Sorce wrote:
> On Thu, 2008-11-06 at 08:52 -0500, Rob Crittenden wrote:
>> Nalin Dahyabhai wrote:
>>> On Wed, Nov 05, 2008 at 04:49:57PM -0500, Rob Crittenden wrote:
>>>> Ok, here is some LDIF that will define some defaults. I haven't tackled  
>>>> auto.home yet.
>>> [snip]
>>>> So adding a new direct mount is as simple as:
>>>>
>>>> ipa automount-addkey --key=share --info=server:/share auto.direct
>>> Slick!
>>>
>>>> Nalin, if I create an auto.home map that handles /home is that going to  
>>>> confuse local accounts who exist on /home? That happens on Solaris and  
>>>> has always driven me nuts.
>>> Yes.  On Linux, at least, /home becomes a mount point for an autofs
>>> filesystem, and behaves like other mount points (meaning whatever was
>>> there before the filesystem was mounted is hidden until it's unmounted
>>> again).
>>>
>>> You could get around that using the direct map, but that requires more
>>> resources, maybe too many.
>>>
>>> I don't have hard numbers to back it up, but I expect that heavy users
>>> of the automounter make sure to either store home directories for local
>>> users elsewhere on the filesystem (/export?), or to use some other
>>> location for the mountpoint (in school, we used /ncsu).
>>>
>> Ok, so how about an API to create indirect maps. Then all one would need 
>> to do is add the keys (mounts) needed.
>>
>> As I understand it a new indirect map requires 2 entries, one that 
>> defines the map name itself and one that associates the mount point with 
>>   that map.
>>
>> So it might look something like:
>>
>> % ipa automount-addindirect --root=/export auto.export
>>
>> This will create these two entries:
>>
>> dn: automountmapname=auto.export, cn=automount, $SUFFIX
>> objectclass: automountmap
>>
>> dn: automountkey=/export, automountmapname=auto.master, cn=automount, 
>> $SUFFIX
>> objectclass: automount
>> automountinformation: ldap:automountmapname=auth.export, cn=automount, 
>> $SUFFIX
>> automountkey=/export
> 
> Where is the server being specified ?

On the client. This LDAP notation is defined by autofs. If I understand 
this correctly (and that is not necessarily a safe assumption), this 
says "the map is stored in LDAP, so use the LDAP information from your 
autofs configuration to retrieve it." The format is ldap:dn_of_map

>> Then you could add a new key with:
>>
>> % ipa automount-addkey --key=src --info=server:/exports/stuff/src 
>> auto.export
>>
>> And then have /export/src available.
>>
>> If I'm reading this right this should be equivalent to:
>>
>> auto.master:
>> 	/export	auto.share
> 
> what is auto.share?

An indirect automount map. See autofs(5)

>> auto.export:
>> 	src	server:/exports/stuff/src
>>
>> What this buys one is that the admin adding the indirect map doesn't 
>> need to worry about the details of the automountinformation attribute.
>>
>> Does this make sense?
> 
> So to recap, this basically "remaps" where exports appears ?

Yes, this is fairly basic automount configuration.

>> And one more question. If I want to provide some mount options, say 
>> -ro,soft, where are those applied? I assume it goes into the attribute 
>> automountInformation but is it a prefix or a suffix:
>>
>> So:
>>
>> automountInformation: server:/exports/stuff/src -ro,soft
>>
>> OR
>>
>> automountInformation: -ro,soft server:/exports/stuff/src
> 
> 
> Looking at this discussion, it is unclear to me how geographical
> situations are handled. If I have IPA server in 3 continents, are we
> making all clients still try to connect to servers in other continents ?
> 
> How do clients choose which server to connect to ?

Hardcoded in /etc/sysconfig/autofs on Fedora and RHEL.

> Is there any concept like that in automount ? Should we care ?

AFAIK there is no accomodation for this. We'd either have to provide 
separate areas (in the dn) to store the maps or the end-user would need 
to carefully configure things.

LDAP for autofs is configured on Fedora (the only thing I've 
experimented with so far) in /etc/sysconfig/autofs. You can specify the 
server and the search base.

To accomodate geographic areas we could use a separate basedn for each 
one, something like:

cn=australia,cn=autoumount,$SUFFIX
cn=baltimore,cn=automount,$SUFFIX

autofs issues a query like this when starting up:

SRCH base="$SEARCH_BASE_FROM_AUTOFS_CONF" scope=2 
filter="(&(objectClass=automountMap)(automountMapName=auto.master))" 
attrs="automountMapName"

So this still wouldn't work if you travel from Europe to the U.S. You 
wouldn't automatically mount the local servers.

rob