>> 2) We run the enumeration in a single transaction (and yes I have
>> recently introduced this), which means any other operation is blocked
>> until the enumeration is finished.
> Can we create a special back end for enumerations and separate it from
> individual operations?
Not sure what you mean here.
I am just saying that it might make sense to have the identity back end
split into two back ends.
One is responsible of the individual operations and another for
If the enumerations are disabled the enumeration BE is just not started.
The enumeration BE will do periodic updates probably using small pages
and will not in any way interfere with other BE.
Seems like a very logical separation of duties and transaction scoping.
And you do not need to worry about server supporting
page -request-page-request sequence.
I know it can be done from one process using async processing but two
separate independent processes make more sense to me.
I do not see code duplication. Common code should be bundled in
libraries and reused.
>> * Every time we update an entry we store the
>> it as a copy of the remote modifyTimestamp, this allows us to know if we
>> actually need to touch the cached entry at all upon refresh (like when a
>> getpwnam() is called, speeding up operations for entries that need no
>> refresh (we will avoid data transformation and a writing to ldb).
> Is this only for enumerations or on individual updates too?
It can be used to test if the retrieved entry is newer or not so that we
can save on storing on disk again (write is expensive). But it is
primarily for enumerations.
We will go for the entry if we do not see an entry or it is expiring in
I guess I might not understand the details of cache implementation.
I was under the impression that the cache expiration time stamp is a
part of the entry in LDB,
and each time we get a record (new or not) we at least need to update
the time stamp.
Am I right? If so we might save on not updating other attributes of the
entry if it has not changed but it would not eliminate the write
There would be a gain be really a minor one so I am not sure it is worth it.
> How it is related to the currently designed and being implemented
This is backend side.
Yes but it (BE) changes the time stamp that indicates when the entry was
last retrieved so that the front end can be it is decision to request a
> Can you please explain how this would affect the cache logic?
It depends on what cache you are referring to, if you are referring to
refreshes performed by the frontend this may make them unnecessary for
the ldap driver.
Are there more than one caches?
You lost me with the second part of the sentence.
>> NOTE: this means that until the first background enumeration is
>> complete, a getent passwd or a getent group call may return incomplete
>> results. I think this is acceptable as it will really happen only at
>> startup, when the daemon caches are empty.
> Here is my concern I mentioned above: How many services and daemons at
> startup rely on the enumeration?
I think none, only very bad apps really rely on enumeration.
> Do we know? Is there any way to know? Should we ask the communities
> about those to make sure we meet the expectations?
In my experience generally if ldap or nis are not available the machine
still comes up fine. Posix even says explicitly that enumeration request
can returning nothing IIRC.
Also experience with samba's winbindd with enumeration turned off tells
me this is not going to be a problem.
We seem to make some assumptions based on one data point.
May be you are right and things are not that bad for us but such
assumption makes me uneasy.
sssd-devel mailing list
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?