On Thu, 2019-12-05 at 23:09 -0500, Oguzhan Eris wrote:
> 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
Ok, thanks for that.
>
>
> 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)
LOL, the why people do what they do is not really my place to question.
The fact you feel you need to do it is enough for me.
But, for various reasons, it may need to be done a bit differently.
>
> 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.
Yes, I got the idea of the problem you were having at the start.
>
> 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.
Yes, that can happen with this type of map entry.
This sort of construct probably could be done using submounts
similar to the example I gave previously.
I guess I should ask what version of autofs your using and on what
distribution?
Do you set browse_mode in your autofs configuration?
If browse_mode is set to "no" (if it's not present in the config
it's default is yes) then mount point directories in indirect
mounts won't be seen until mounted so they won't get mounted
when the tree is scanned ... but with that construct you have
above those offsets will behave like direct mounts which will
be present and will respond to scans.
It may be possible to break this tree down to use submounts which
could prevent (at least some of the sensitivity) to the mount on
scan problem you have.
I'll need to think about it.
>
> 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.
LDAP, and NIS and NISPLUS all have no ordering guarantee.
Strictly speaking I don't allow nesting in anything other than those
hierarchical mount map entries but I don't explicitly check for it.
And I don't really want to put that sort of a limitation into autofs.
But the problem happens all to often (with hierarchical map entries)
that someone rips out an export in the midst of a tree that's in use
and the mount ends up not behaving properly. Then, after the kernel
mounts list gets disjointed they demand to know why this happened
and I can't give an answer because something like "you did something
you should have known not to do" doesn't go down all that well.
Inevitably I can't reproduce these types of problem so I can't even
work out if I can improve things ...
Also, while I'm tempted to just sort the master map list I'm pretty
sure that could break other functionality people might have come to
expect to behave a certain way.
Consequently I would like to find another way to achieve this if we
can. I'll give that some thought.
Your mounting NFS mounts, could you use the NFS cross-mount
automounting here?
I'm pretty sure nfs-utils (but perhaps fairly recent releases) have
a utility to set basic mount junctions. Have you investigated this,
autofs should play well with the NFS automounting?
I guess that takes away the benefit of being able to manage your
mounts in one place using one method ...
I'll have a bit of a think about this one.
Ian
>
> 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
> >