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?

Quanah Gibson-Mount wrote: > > > --On Monday, December 16, 2019 11:46 PM +0100 Ondřej Kuzník <ondra(a)mistotebe.net&gt; 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.

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?

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

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.