On 03/17/2015 04:04 PM, Paul B. Henson wrote:
> From: Ian Kent
> Sent: Tuesday, March 17, 2015 6:37 AM
>
> If an indirect map has the "browse" (or ghost) option the entire map
[...]
> Direct maps must always be read completely because the direct mount
Ah, yes, we do not use the ghost option or direct maps, so I did not consider that use
case.
> I think we discussed this at the time and, given the cases, decided it
> was best for sss to read the entire map and cache it since it might need
> to be able to supply the entire map and can't know if that will be the
> case.
On the other hand, there are cases such as mine where not only is reading the entire map
unnecessary but inadvisable and practically infeasible 8-/. For my deployment, using sssd
to access autofs data in ldap rather than autofs accessing it directly would drastically
increase the load on the LDAP server, which seems completely cross purpose to the
existence of sssd. Currently there is sporadic load as individual entries (probably no
more than 10-1000 or so in a given day, depending on the server) are looked up. With sssd,
all 120000 entries would be pulled over on an ongoing basis throughout the day (I'm
not sure how often it refreshes its local cache).
That's okay though, I don't really have any strong need to use sssd for autofs.
I just thought it would be interesting to look into given the new RHEL6 support from the
perspective of centralizing all LDAP lookups into one place. Assuming there are no planned
changes to the native autofs ldap support, that meets our needs fine.
I think we still should file an RFE for autofs support in SSSD to handle
your case in future.
It is a valid case and there is a reason why SSSD is better for than
direct case (caching mainly).
I am not saying we will fix it quickly but if we see more cases like
yours it will bump the priority.
Thanks…
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.