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
> > > > 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
> > > case that requires reading the entire map, they probably just need to
> > > the size of the map small enough that it's not an issue to read it
> > 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
> > > maps the same way as users/groups are treated. Do not enumerate by
> > > and lookup entries as necessary. Also, modify the current enumerate
> > > 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
> > > 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
> > > that requires the entire map, the entire map will be downloaded,
> > > it won't be. On further thought, an explicit flag might be confusing
> > > someone tries to use direct maps or browse mode and they just
> > > 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
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
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.