On Fri, Oct 12, 2012 at 01:22:05PM -0400, Simo Sorce wrote: > On Thu, 2012-10-11 at 15:24 -0400, Simo Sorce wrote: > > On Thu, 2012-10-11 at 20:25 +0200, Jakub Hrozek wrote: > > > On Thu, Oct 11, 2012 at 02:06:22PM -0400, Simo Sorce wrote: > > > > On Thu, 2012-10-11 at 19:47 +0200, Jakub Hrozek wrote: > > > > > On Thu, Oct 11, 2012 at 09:44:46AM -0400, Simo Sorce wrote: > > > > > > On Thu, 2012-10-11 at 10:52 +0200, Jakub Hrozek wrote: > > > > > > > The IPA has a defined directory tree structure that allows us to > > > > > > > guess > > > > > > > the username from a DN without having to look up the DN in LDAP. > > > > > > > > > > > > Jakub, > > > > > > it looks like you always take the shortcut in this case. > > > > > > I am not comfortable with that, I'd rather you check the DN matches > > > > > > the > > > > > > expected tree structure, and fallback to the classic method if not. > > > > > > This allows us to future-proof sssd if we were to relax constraints > > > > > > later on in IPA and allow for adding users and groups in custom OUs, > > > > > > while keeping the optimization for the current DIT. > > > > > > > > > > > > Simo. > > > > > > > > > > I already check if the DN matches the expected tree structure, check > > > > > out > > > > > sdap_nested_get_ipa_user(). But you're right that failure to parse the > > > > > user should not be fatal. > > > > > > > > Yup I saw that, sorry for the poor wording, I was only asking for the > > > > fallback. > > > > > > > > > I attached new patches that fall back to an LDAP lookup if the DN > > > > > heuristics fail. > > > > > > > > They look good to me, but I wonder, should this be user specific ? > > > > Or are you going to add a similar set of patches for groups ? > > > > > > Don't we still need to go to LDAP in case we're processing a group DN to > > > recurse down that nesting level? > > > > Well not when we are using memberof to list the groups a user is member > > of. In that case we do not need to recurse. However I guess in that case > > we still need to fetch the gid so the point may be moot. > > > > Simo. > > > > Ah also ACK :) > > Simo.
Pushed to master. What we also talked about with Simo on IRC was that given how rare GID changes are, we might also implement a new option (or timeout? tbd) that would only check the group memberships based on the memberof: links and if all the groups are cached simply return them from cache and do not check LDAP for GIDs. Tracked by: https://fedorahosted.org/sssd/ticket/1580 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel