There's some ambiguities that still need to be resolved, around the memberOf functionality.
The dynlist code only adds memberOf values for dynamic groups. It doesn't do anything about static group memberships. This implies that you still need to use the memberOf overlay too, if you want to also support static groups.
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?
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?
--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).
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
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.
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.
On 12/18/19 6:09 PM, Howard Chu wrote:
Howard Chu wrote:
Quanah Gibson-Mount wrote:
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.
My feeling always was that 'memberOf' should simply be replicated like other operational attributes (modifiersName, pwdChangedTime etc.).
Ondrej and me had a longer discussion about this at LDAPcon pre-conference dinner. He was not sure whether my proposal could work.
So the big question is: Why is 'memberOf' not replicated?
Next question is: Can slapo-memberof detect whether a write operation comes from replication and simply ignore that?
Ciao, Michael.
Ondřej Kuzník 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?
We've got other overlays that do something similar, ignore an error if the schema element they'yre runtime loading is already defined. I guess my question is whether we want to include memberOf in the schema like this or not. If not, then it's always up to the admin to define their own particular attribute that functions as a memberOf attribute.
On Wed, Dec 18, 2019 at 02:02:40AM +0000, Howard Chu wrote:
Ondřej Kuzník wrote:
How about being able to merge identical attribute definitions whether they come from config or directly from code?
We've got other overlays that do something similar, ignore an error if the schema element they'yre runtime loading is already defined. I guess my question is whether we want to include memberOf in the schema like this or not. If not, then it's always up to the admin to define their own particular attribute that functions as a memberOf attribute.
More like making it no longer an error to load the same schema twice.
Modules could then define it at load time but ship it as a schema file too. The admin could then include that on all servers that need to deal with the data (while they match) so it's available even if the module isn't.
That would almost sort out the schema issues we have with ppolicy where currently it needs to be loaded on all replicas even if they don't need the functionality.
--On Wednesday, December 18, 2019 8:04 AM +0100 Ondřej Kuzník ondra@mistotebe.net wrote:
More like making it no longer an error to load the same schema twice.
From the usage cases I've seen, we should be able to support both static
groups + old memberOf overlay and dynamic groups + dynamic memberOf concurrently in the deployment.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Wednesday, December 18, 2019 8:04 AM +0100 Ondřej Kuzník ondra@mistotebe.net wrote:
More like making it no longer an error to load the same schema twice.
From the usage cases I've seen, we should be able to support both static groups + old memberOf overlay and dynamic groups + dynamic memberOf concurrently in the deployment.
Which will work already with the code in master.
Ondřej Kuzník wrote:
On Wed, Dec 18, 2019 at 02:02:40AM +0000, Howard Chu wrote:
Ondřej Kuzník wrote:
How about being able to merge identical attribute definitions whether they come from config or directly from code?
We've got other overlays that do something similar, ignore an error if the schema element they'yre runtime loading is already defined. I guess my question is whether we want to include memberOf in the schema like this or not. If not, then it's always up to the admin to define their own particular attribute that functions as a memberOf attribute.
More like making it no longer an error to load the same schema twice.
Modules could then define it at load time but ship it as a schema file too. The admin could then include that on all servers that need to deal with the data (while they match) so it's available even if the module isn't.
That would almost sort out the schema issues we have with ppolicy where currently it needs to be loaded on all replicas even if they don't need the functionality.
Since we're talking about operational attributes, that are only valid if the server has code to implement them, I think trying to support them without loading the modules is a wrong approach.
Should be a moot point for a lot of these that are defined as dSAoperation, since they are, by definition, specific to a single server and not replicatable.
-
Howard Chu -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount