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 <ik...@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 > >
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
