On Wed, Mar 18, 2015 at 01:18:21PM -0700, Paul B. Henson wrote:
> From: Jakub Hrozek
> Sent: Wednesday, March 18, 2015 12:55 PM
> > 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 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.
Hmm, are you talking about retrieving the members of a group, or multiple
groups? The former is actually ranges, it is the latter that would be the
page control. Also, unlike user/groups, where any random number of people
could be calling getXXent, for automount maps, you have one and exactly one
client. Just store the cookie statically somewhere when setautomountent is
called, and use it whenever getautomountent is called and you are out of
entries to fetch the next set. Clear the cookie when endautomountent is
You're right, we only use the cookie when we expect multiple entries.
> 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.
My understanding is that automounter has plug-ins for accessing each
backend, specifically on RHEL6 there is
for using sssd. However, I believe that backend only iterates because sssd
only provided iteration 8-/.
yes, that's what I meant.
Other backends, such as the LDAP backend, are
more efficient and lookup entries as needed. So yes, I guess the automounter
sss lookup backend would need to be updated to match the new feature set of
the sssd provider, but I can't imagine that would be particular complicated
or difficult as it would simply be duplicating existing functionality in
Of course, that does take the probability of me ever actually seeing this
feature in RHEL 6 from 1/infinity to 1/infinity+1 given there would actually
be two RFE's to backport 8-/.
Ian, I don't think there is a separate bug tracker for autofs? Once I open
the sssd ticket, should I just create one on bugzilla.redhat.com
it with the request to enhance autofs to support the new functionality once
it is implemented? Or would it be better to open a Red Hat support case and
have somebody there open the bug?