On Wed, 2015-03-18 at 20:54 +0100, Jakub Hrozek wrote:
> On Wed, Mar 18, 2015 at 12:14:32PM -0700, Paul B. Henson wrote:
> > > From: Jakub Hrozek
> > > Sent: Wednesday, March 18, 2015 12:29 AM
> > >
> > > I'm not sure if we can optimize getautomntent() to read the next
> > > on demand, I think we need to fetch the whole map there.
> > Theoretically you could use the pagedResultsControl:
> > https://www.ietf.org/rfc/rfc2696.txt
> > I don't know if it would be worth the effort though. If someone has a use
> > case that requires reading the entire map, they probably just need to keep
> > the size of the map small enough that it's not an issue to read it all.
> Yes, that's what we use for retrieving large groups. But for automounter
> maps it's not really practically usable I think because we would have to
> keep the cookie across requests to the back end.
> With large group lookups, we simply do several small internal lookups as
> part of a single large group lookup, so maintaining the cookie is
> > > But it would be
> > > entirely doable to add another LDAP request that would be invoked by
> > > getautomntbyname() and would fetch the single key.
> > >
> > > Would that provide more efficient API towards automounter?
> > Absolutely. My suggestion, as in my reply to Ian, would be to treat autofs
> > maps the same way as users/groups are treated. Do not enumerate by default,
> > and lookup entries as necessary. Also, modify the current enumerate config
> > item to allow enumeration to be enabled/disabled separately for users,
> > groups, and autofs maps. Perhaps extended to allow a list of backends in
> > addition to true/false, where true means enable everything, false means
> > enable nothing, and a specific list "passwd,group,autofs" or
> > enable enumeration only for those data sources.
> > Hmm. Or maybe that's too complicated? Unlike user/groups, where any random
> > user can run setXXent/getXXent and result in enumeration, are autofs map
> > lookups restricted to autofs? Presumably autofs only calls getautomntent
> > when it actually needs the entire map, so maybe an explicit enumeration
> > enable/disable in sssd isn't required. If someone uses an autofs feature
> > that requires the entire map, the entire map will be downloaded, otherwise
> > it won't be. On further thought, an explicit flag might be confusing when
> > someone tries to use direct maps or browse mode and they just mysteriously
> > don't work because sssd has enumeration disabled 8-/.
> The problem is whether the /client/ which is the automounter in this
> case can/should be modified to leverage the new way of doing things.
> Changing the SSSD is one part, but automounter needs to be changed as
> well if I understood Ian correctly as right now the client only iterates
> over the map.
Not sure I understand what the new way of doing things would be.
First, only automount(8) should be doing lookups.
The way it is now autofs must always call setautomntent() to pass the
map name to sss and then an endautomntent() to finish.
When an entire map read is needed autofs will always use getautomntent()
to iterate over the map.
When a key lookup is done autofs will always call getautomntbyname().
OK, so the autofs client module already calls getautomntbyname as
appropriate and if we switched sssd to only read the requested key on
receiving getautomntbyname, you wouldn't need to do any changes to
That's the part that wasn't clear to me..and if that's the case, we
should do the SSSD changes to make SSSD perform better in large
Paul, can you file the SSSD bug either way?
So there's definite distinction between the two cases.
Clearly if there are changes to return codes then I can deal with that.
If you want to change the semantics I can deal with that too but it will
introduce version dependencies I'd rather avoid.