From: Ian Kent
Sent: Tuesday, March 17, 2015 6:45 PM
is about the practical limit for reading the entire map. There would be
other side effects in autofs spending that much time reading the the
entire map too so I don't think it will ever be possible in your case.
I can't really envision a use case for reading the entire map when it is so large.
I can't change the way the lookup and read map works very much
specifically because of the problems really large maps bring. If there
are any changes made they must also cover the large map requirement.
But we haven't heard from Jakub yet, it may be possible to change sss to
lookup and read the map on demand rather than all at once. Not sure
though given I'm not familiar with the wider design of sss.
I don't think any changes are required on the autofs side, as I mentioned, when it
accesses LDAP directly it works perfectly. I'm sure sssd could support accessing
entries on demand. I'm not sure why they decided to just read the entire map always.
Based on a design document I found and also I believe mentioned in this thread, the
thought was since they didn't know whether they would need the entire map or not, to
just go ahead and read the entire map.
Interestingly, the same behavior for user/groups is explicitly disabled by default:
https://fedorahosted.org/sssd/wiki/FAQ#WhenshouldIenableenumerationinSSSD...
While sometimes the entire map is required for autofs (direct maps, browse mode) sometimes
it's not. Just like for user/groups sometimes the entire map is required
(setXXent/getXXent), sometimes it is not. It would make more sense to me to treat them the
same way. Although it looks like for user/groups you can only enable enumeration for both
or neither, not separately. Ideally, sssd could be enhanced to treat autofs data the same
as user/group, with enumeration optional, and also extend the enumeration control to allow
enumeration to be toggled individually for users, groups, or autofs.