On Thu, Mar 11, 2010 at 7:48 PM, Ian Kent <[email protected]> wrote:
> On Thu, 2010-03-11 at 18:32 -0700, Techie wrote:
>> On Wed, Mar 10, 2010 at 11:28 PM, Ian Kent <[email protected]> wrote:
>> > On Wed, 2010-03-10 at 22:00 -0700, Techie wrote:
>> >> Hello,
>> >>
>> >> I have a simple question regarding LDAP direct map mounts.
>> >>
>> >> If I use a local direct map "/etc/direct_map"  with the below contents
>> >> to map NFS directories on two different file systems.
>> >>
>> >> /data                                    red:/usr/local/app   \
>> >>          /libs/apps                    red:/var/libs/apps
>> >>
>> >> Both mount points to map properly. The /data directory shows the
>> >> correct contents of red:/usr/local/app. And the /data/lib/apps
>> >> directory also shows the correct contents of  red:/var/libs/apps. This
>> >> is what I believe are nested mount points. However when I try the same
>> >> thing with an LDAP direct map it fails. he contents of the same map in
>> >> LDAP is below.
>> >>
>> >> dn: 
>> >> automountKey=/data,automountMapName=direct_map,ou=Autofs,dc=example,dc=com
>> >> automountInformation: -fstype=nfs,rw red:/usr/local/app
>> >> automountKey: /data
>> >> objectClass: automount
>> >> objectClass: top
>> >>
>> >> dn: 
>> >> automountKey=/data/libs/apps,automountMapName=direct_map,ou=Autofs,dc=example,dc=com
>> >> automountKey: /data/libs/apps
>> >> objectClass: automount
>> >> objectClass: top
>> >> automountInformation: -fstype=nfs,rw red://var/libs/apps
>> >>
>> >>
>> >> When I do this in my LDAP map as shown above, the mount points do not
>> >> show up correctly. The /data directory covers up one of the 2 mount
>> >> points. So it looks like nested mount points don't work in LDAP or I
>> >> am not using correct syntax. All my other LDAP mounts work but two
>> >> mount points in the same dir does not work like it does with local
>> >> direct maps.
>> >>
>> >> Can you please confirm or deny if I can achieve nested mount points
>> >> using LDAP direct maps like I can with local direct maps as shown
>> >> above?
>> >
>> > LDAP map isn't quite right.
>> >
>> > The LDAP map entry must be the same as your file map.
>> >
>> > In your file map the direct mount is
>> > key = "/data"
>> > location = "/ red:/usr/local/app /libs/apps red:/var/libs/apps"
>> >
>> > In your original file map the "/" offset has been implied because the
>> > syntax allows it to be optional.
>> >
>> > and in LDAP
>> > key = "/data"
>> > location = "red:/usr/local/app"
>> >
>> > key = "/data/libs/apps"
>> > Invalid, you can't nest distinct direct mounts.
>> >
>> > You need to use the same value for location as you did for the file map
>> > in LDAP.
>> >
>> >>
>> >>
>> >> Thank you
>> >>
>> >> _______________________________________________
>> Ian,
>> Thanks a bunch for pointing out that the "/" offset is syntactically
>> optional for file based maps but is necessary in LDAP. That really
>> helped my understanding of both formats..
>
> No, actually it's always optional but can cause confusion when omitted.
>
> The issue was that you can't break up the mount location into two
> separate entries (either in a file map or LDAP, LDAP convention just
> happens to make you want to do it that way). You just need to feed the
> same string to the daemon whether the map is in a file or stored in
> LDAP.
>
> Ian
>

I see that makes sense, thank you.
I was also trying to specify multiple direct maps in LDAP. I tried
creating another direct map with a "/-" key but ldap complained saying
that the "/-" key already exists. Which makes sense as the two DNs
would be the same.

In a /etc/auto.master local file I can have multiple direct map entries with ...
/-   /etc/map1
/-   /etc/map2

I was able to accomplish this in ldap by appending multiple map names
to the automountinformation attribute of the dn: automountKey=/-
entry. I am not sure if this is the proper way to do however it seems
to work well so I imagine it may be. I am able to use the different
maps by specifying them by name in the client auto.master files.
AutoFS5 seems to be able to do everything I need it to, it's greatly
improved over Autofs4 from what I can tell.

Thanks again
J

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to