>> 4) Add marking to the objects. "Complete" mark is
put on the user
>> object when all groups he is a member of are fetched. The groups
>> that were fetched and were not in the cache are marked as
> This is only on initgroups calls, and I think the first part (properly
> marking the user) is already implemented, we only need to mark the
> groups differently.
>> When the group members are enumerated for a group all users for a
>> group should be fetched and "group" should be marked as
>> users fetched by this lookup that were not in the cache are marked
>> as "incomplete".
Why? Or do you mean incomplete wrt to the initgroups() call for that
> I think we could manage by simply marking users as expired, although
> this may cause issues if we go offline, as we do not have uid/gid and
> other fields ... probably we can simply leave those fields off, and
> this will automatically make them "incomplete". We would have to make
> sure the rest of the code can cope (and filter out) these users when
> we are offline.
Are you talking about the rfc2307 case, were "dummy" user object could be
created? In the other cases (IPA, rfc2307bis) the complete user objects
(including gid, uid,...) should be read from LDAP IMO. Reading only a
subset there has no real advantage IMO.
Incomplete user is the user that is fully fetched as user entry but the
list of the groups he is a member of is not fetched.
This makes sense for the cases when there is no memberOf and we do not
want for each user in a group go fetch all the groups this user is a
We already had a performance issue with this approach and we had to fix
it recently. If memberOf is present we can already mark it as complete.
I am not talking about reading parts of user object.
Group is complete is we know all its members. User is complete if we
know all groups he is a member of.
This is how I define completeness in this context. Sorry for confusion.
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?