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:
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.
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"
means
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-/.
I will open a ticket for an RFE as Dmitri requested for this issue.
Thanks.