I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance:
dn: olcOverlay={5}memberofA,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {5}memberofA olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassA olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf
dn: olcOverlay={6}memberofB,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {6}memberofB olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassB olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf
// John Pfeifer Division of Information Technology University of Maryland, College Park
--On Wednesday, April 24, 2019 2:47 PM -0400 "John C. Pfeifer" pfeifer@umd.edu wrote:
I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance:
Hi John,
I believe it should work fine.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi,
just a quick heads up about an old question from 2019 on this list:
On Monday, April 29, 2019 23:49 CEST Quanah Gibson-Mount quanah@symas.com wrote:
[...]
Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute?
[...] I believe it should work fine.
While Quanah is right, that loading two instances of slapo-memberof works fine if configured with different target attributes (config option `memberof-memberof-ad`), technically slapd denies loading multiple instances of overlays since 2009: https://bugs.openldap.org/show_bug.cgi?id=6030
Maybe one could challenge that decision to deny loading multiple instances per se, as I think this limitation is not inherent to overlays in general but may be reasonable for specific modules. Actually, I understand that some overlay modules specify "SLAPO_BFLAG_SINGLE", so the general constraint introduced via https://git.openldap.org/search?group_id=13&project_id=1&repository_ref=master&scope=commits&search=its%236030 may be a child of its time and unnecessary today. See also https://bugs.openldap.org/show_bug.cgi?id=9309#c2.
Thanks and regards, Arvid
On Monday, April 29, 2019 23:49 CEST Quanah Gibson-Mount quanah@symas.com wrote:
--On Wednesday, April 24, 2019 2:47 PM -0400 "John C. Pfeifer" pfeifer@umd.edu wrote:
I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance:
Hi John,
I believe it should work fine.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Arvid Requate wrote:
Hi,
just a quick heads up about an old question from 2019 on this list:
On Monday, April 29, 2019 23:49 CEST Quanah Gibson-Mount quanah@symas.com wrote:
[...]
Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute?
[...] I believe it should work fine.
While Quanah is right, that loading two instances of slapo-memberof works fine if configured with different target attributes (config option `memberof-memberof-ad`), technically slapd denies loading multiple instances of overlays since 2009: https://bugs.openldap.org/show_bug.cgi?id=6030
Maybe one could challenge that decision to deny loading multiple instances per se, as I think this limitation is not inherent to overlays in general but may be reasonable for specific modules. Actually, I understand that some overlay modules specify "SLAPO_BFLAG_SINGLE", so the general constraint introduced via https://git.openldap.org/search?group_id=13&project_id=1&repository_ref=master&scope=commits&search=its%236030 may be a child of its time and unnecessary today. See also https://bugs.openldap.org/show_bug.cgi?id=9309#c2.
The two items you reference are completely unrelated. ITS#6030 rejects duplicate moduleload attempts - that is, it rejects multiple attempts to dynamically load the same code twice. That has no bearing on how many times you can configure a particular module that has been loaded.
Thanks and regards, Arvid
On Monday, April 29, 2019 23:49 CEST Quanah Gibson-Mount quanah@symas.com wrote:
--On Wednesday, April 24, 2019 2:47 PM -0400 "John C. Pfeifer" pfeifer@umd.edu wrote:
I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance:
Hi John,
I believe it should work fine.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Arvid Requate -
Howard Chu -
John C. Pfeifer -
Quanah Gibson-Mount