Thanks for the reply.
My file based maps are as such:
basically blank auto.master  that includes auto.master.d
/etc/auto.master.d/foo.autofs:
/foo/x   /etc/automap/x.txt
/foo/x/dev   /etc/automap/x_dev.txt
foo/x/prod  /etc/automap/x_prod.txt
/foo/z   /etc/automap/z.txt

/etc/automap/x.txt:
dir1 -fstype=nfs4 server1:/share_dir1
dir2 -fstype=nfs4 server2:/share_dir2

/etc/automap/x_dev.txt:
dir3  -fstype=nfs4 devserver1:/share_dir3
dir4  -fstype=nfs4 devserver2:/share_dir4

/etc/automap/x_prod.txt:
dir3  -fstype=nfs4 prodserver1:/share_dir3
dir4  -fstype=nfs4 prodserver2:/share_dir4

/etc/automap/z.txt:
dir5 -fstype=nfs4 server5:/share_dir5


Such a map might not make a lot of sense if you were designing from scratch, but what I'm actually doing is mapping our Windows DFS namespace "\\foo"  in Active Directory where a lot of apps have been written to use just one global namespace, to now be available under linux in the same way at /foo .  This will greatly minimize the effort when having these apps migrate and run under linux, or in some situations, be completely cross platform apps with very minor settings to them to make them work under windows vs. linux  (mostly python apps)

Anyway,  so as I have it above, as long as my indirect map in foo.autofs  is ordered the way I have above,  then everything works fine, and I will end up with:

/foo/x
/foo/x/dir1
/foo/x/dir2
/foo/x/dev/
/foo/x/dev/dir3
/foo/x/dev/dir4
/foo/x/prod/
/foo/x/prod/dir3
/foo/x/prod/dir4
/foo/z

When I model this in LDAP (via sssd) however, I can see the maps perfectly fine in automap -m   
but the order in which they're returned results in some of the parent paths masking their nested children.
i.e. 
if /foo/x/dev   gets mounted first,  and then /foo/x/prod, followed by /foo/x
It will result in  me seeing just
/foo/x/dir1
/foo/x/dir2

The moment I umount /foo/x   I will then see
/foo/x/dev/...  and /foo/x/prod/...

Hopefully that makes sense.

I had previously done hierarchical maps with something like:

auto.master
/foo /etc/automount/foo.txt

/etc/automount/foo.txt:
x    \
  dir1 ... \
  dir2  .... \
  dev/dir3 ....\
  dev/dir4 ... \
  prod/dir3 ...\
  prod/dir4 ...

And that worked, but it had the huge burden that any traversal to a path under /foo/x  meant that ALL mounts got mounted at once, which was quite undesirable.

Would you  have a recommendation on how this might be better authored in ldap?   As I said, I must unfortunately follow the namespace as is.

Thanks again
 



On Wed, Dec 4, 2019 at 7:20 PM Ian Kent <ikent@redhat.com> wrote:
On Wed, 2019-12-04 at 11:36 +0100, Pavel Březina wrote:
> On 11/30/19 5:41 PM, Oguzhan Eris wrote:
> > Hi everyone.
> >
> > First off, thanks to everyone who's ever worked on SSSD.  It's
> > easily in my top 5 favorite FOSS projects out there.
> >
> > I am not sure if this is the right way to ask for an enhancement,
> > or whether I should file an issue on GitHub,  but I am running into
> > an issue that's described in this Red Hat page   
> > https://access.redhat.com/solutions/3673501 (login required)
> >
> > Basically for an automount map where I need nested top level paths:
> >
> > /mnt/foo
> > /mnt/foo/bar

Those look like master map entries or perhaps direct mount map
entries.

Which is it?

In either case nesting mounts is not supported so sorting is not
needed.

Nesting of mounts can only be done by using mount map entries
with offsets.

> >
> > each defined by their own map objects.  SSSD does not handle this
> > (neither does LDAP directly from autofs) because the return map
> > from LDAP is unsorted, and if the maps are provided to autofs
> > ordered as:

So each has their own map, but you haven't provided a complete
master map entry or map examples so I still can't tell what you
actually want to do.

I'll assume these are master map entries ... and the maps are
called auto.foo and auto.bar, and they are indirect mount maps,
and I'll use file maps for the example.

In the master map:
/mnt    /etc/auto.foo

In /etc/auto.foo:

foo     /       foo.server.net:/path/to/foo
        /bar -type=autofs /etc/auto.bar

might be something like what you need to do.

Allowing nesting in offset mounts this problematic enough, due
to the fact that mount dependency changes can (and do) cause
problems that are extremely hard to resolve, nesting won't be
supported in any other way.

> >
> > /mnt/foo/bar
> > /mnt/foo
> >
> > the /mnt/foo map masks the previous /mnt/foo/bar map  and you'll
> > only get the entries from /mnt/foo
> >
> > Using file based mount maps, one can easily sort the top level
> > maps, and get around this issue.
> > Would it be possible to have SSSD return the maps from LDAP query
> > in a sorted way?   There is an LDAP control that most LDAP servers
> > support to return a sorted output, (
> > https://ldapwiki.com/wiki/Server%20Side%20Sort%20Control ) but with
> > so many clients and a large list, this might be better left to the
> > client to do instead.
> >
> > I'm happy to help out if someone can point me in the right
> > direction in the code.
>
> SSSD is just a data provider, if some sorting is needed I do not
> think
> it should be done in SSSD (unless autofs interface says so) but
> rather
> in autofs itself.
>
> CCing Ian, do you have any thoughts on this?

Thanks Pavel, some more specific information about the use case
might still be needed, we'll see.

Ian