On Thu, 2015-03-19 at 10:09 +0100, Jakub Hrozek wrote: > On Thu, Mar 19, 2015 at 11:05:15AM +0800, Ian Kent wrote: > > 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 > > > > > 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. > > > > > > 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 > > > trivial. > > > > > > > > > > > > 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-/. > > > > > > 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 > SSSD?
Don't think so, by the sound of it. I must do specific key lookups because I avoid reading the entire map whenever possible for the same reason that's come up here. Even if I read the entire map I still do individual key lookups to check if the entry has changed (for indirect maps that is). > > 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 > environments.. > > 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. > > > > Ian > > _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
