Hi,
When trying to sync our LDAP data to a consumer, the consumer errors with:
null_callback : error code 0x13 syncrepl_entry: rid=002 be_add cn=mygroup,ou=Group,dc=domain,dc=com failed (19)
I believe this is because it is a groupOfNames (list of member DNs) that do not yet exist on the consumer. If I sync with a filter to exclude the groupOfNames entries, it completes fine, which confirms it is only having an issue with groupOfNames:
filter="(!(objectClass=groupOfNames))"
Can you advise if this is a known issue, and if there's a way to work around it, short of importing the LDAP data manually? I wonder if there's a way to skip errors, so it will skip the groupOfNames and retry once the users have been created.
Best regards, Jonathan
--On Monday, August 3, 2020 3:35 PM +0000 Jonathan Steel jss92@cam.ac.uk wrote:
Hi,
When trying to sync our LDAP data to a consumer, the consumer errors with:
null_callback : error code 0x13 syncrepl_entry: rid=002 be_add cn=mygroup,ou=Group,dc=domain,dc=com failed (19)
This says it is adding "cn=mygroup", and there is a constraint violation of some sort. You'd need to provide significantly more detail about your setup as you seem to have some set of overlays in use that you haven't disclosed.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
This says it is adding "cn=mygroup", and there is a constraint violation of some sort. You'd need to provide significantly more detail about your setup as you seem to have some set of overlays in use that you haven't disclosed.
This uses the memberOf overlay.
The entry it is having an issue adding is this one. I believe it is because those users do not yet exist, because syncrepl decides to try and sync this entry before the users.
dn: cn=mygroup,ou=Group,dc=hpc,dc=cam,dc=ac,dc=uk objectClass: groupOfNames objectClass: top cn: mygroup description: My Group member: uid=user1,ou=People,dc=domain,dc=com member: uid=user2,ou=People,dc=domain,dc=com member: uid=user3,ou=People,dc=domain,dc=com member: uid=user4,ou=People,dc=domain,dc=com member: uid=user5,ou=People,dc=domain,dc=com
Many thanks, Jonathan
--On Tuesday, August 4, 2020 9:47 AM +0000 Jonathan Steel jss92@cam.ac.uk wrote:
This says it is adding "cn=mygroup", and there is a constraint violation of some sort. You'd need to provide significantly more detail about your setup as you seem to have some set of overlays in use that you haven't disclosed.
This uses the memberOf overlay.
The entry it is having an issue adding is this one. I believe it is because those users do not yet exist, because syncrepl decides to try and sync this entry before the users.
What is the exact configuration of your memberOf overlay? It would appear, for example, that it's doing referential integrity or similar.
The slapo-memberof(5) man page explicitly contains the following:
"Note that slapo-memberOf is not compatible with syncrepl based replication, and should not be used in a replicated environment."
The reason that note is there is due in part to what you're experiencing now -- If the group is replicated before the users exist those users will not have the memberOf attribute added when using a default memberOf configuration.
Your scenario seems to trigger additional problematic behavior which is why I'm asking for the exact configuration. It could be useful in the future for testing.
There's been significant work for OpenLDAP 2.5 to allow slapo-dynlist to be an alternative to slapo-memberOf in a replicated environment as it does not suffer from the replication related issues.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Tue, Aug 04, 2020 at 12:20:35PM -0700, Quanah Gibson-Mount wrote:
There's been significant work for OpenLDAP 2.5 to allow slapo-dynlist to be an alternative to slapo-memberOf in a replicated environment as it does not suffer from the replication related issues.
Hmm, I've been using dynlist for the memberOf attribute with 2.4 ever since you got tired of me reporting weird syncrepl bugs with the slapo-memberOf module and updated the documentation to say it wasn't supported anymore ;). What changes will there be in 2.5 to make it better? Other than not being able to search on memberOf anymore (and the couple of cutover issues that resulting in when a couple apps I was unaware of were doing that 8-/) it's been working well...
--On Wednesday, August 12, 2020 9:56 PM -0700 "Paul B. Henson" henson@acm.org wrote:
On Tue, Aug 04, 2020 at 12:20:35PM -0700, Quanah Gibson-Mount wrote:
There's been significant work for OpenLDAP 2.5 to allow slapo-dynlist to be an alternative to slapo-memberOf in a replicated environment as it does not suffer from the replication related issues.
Hmm, I've been using dynlist for the memberOf attribute with 2.4 ever since you got tired of me reporting weird syncrepl bugs with the slapo-memberOf module and updated the documentation to say it wasn't supported anymore ;). What changes will there be in 2.5 to make it better? Other than not being able to search on memberOf anymore (and the couple of cutover issues that resulting in when a couple apps I was unaware of were doing that 8-/) it's been working well...
You can search on memberOf, you don't need to hack the schema, etc. I suggest looking at the expanded 2.5 test for dynlist and updated man page for dynlist in 2.5 as well. A lot of new functionality has been added.
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
-
Jonathan Steel -
Paul B. Henson -
Quanah Gibson-Mount