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.