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 entries
> on demand, I think we need to fetch the whole map there.
Theoretically you could use the pagedResultsControl:
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 "autofs"
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.
I will open a ticket for an RFE as Dmitri requested for this issue.