[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: dynlist enhancements, ITS#9121
Howard Chu wrote:
> Quanah Gibson-Mount wrote:
>>
>>
>> --On Monday, December 16, 2019 11:46 PM +0100 Ondřej Kuzník <ondra@mistotebe.net> wrote:
>>
>>> On Mon, Dec 16, 2019 at 06:55:56PM +0000, Howard Chu wrote:
>>>> The dynlist overlay doesn't define the memberOf attribute schema.
>>>> Something else needs to do that, either loading it as user-defined
>>>> schema, or relying on the memberof overlay to already be initialized.
>>>>
>>>> This seems like a messy loose end to leave dangling, but not sure what
>>>> a better approach would be.
>>>> Suggestions?
>>>
>>> How about being able to merge identical attribute definitions whether
>>> they come from config or directly from code?
>>
>> It would be great along with all of this to finally fix memberOf so it's actually functional (and replication safe) (I.e., can maintain membership regardless of
>> user/group creation order).
>
> That sounds like scope creep. Out of scope for the current discussion.
>
Just thinking about this a bit more - I don't really see any good solution here. If
you want memberof to accept DNs of entries that don't exist, you can set memberof-dangling
to ignore. And then it'll accumulate DNs of nonexistent entries...
If you want it to maintain an accurate list of only existing entry DNs, then you
have to check for existence at the time of updating the memberof attribute.
Another option is to let it update lazily only during a refresh, and then run
a cleanup job when the refresh completes. Not sure how we would rig things up
for refreshDone to trigger other modules.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/