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