While I was trying to recover my directory from an aborted attempt to implement the memberof overlay, I ended up dumping the database with slapcat and then reloading it with slapadd after removing the now invalid MEMBEROF attributes that lingered after the overlay was disabled.
Strangely, on some of my servers, a glue object with an empty DN showed up in the slapcat output:
dn: objectClass: glue structuralObjectClass: glue entryUUID: 411f0301-e857-4228-a22d-c5d1451d4496 creatorsName: cn=ldaproot,dc=csupomona,dc=edu createTimestamp: 20131007210011Z entryCSN: 20131007210011.273579Z#000000#000#000000 modifyTimestamp: 20131007210011Z modifiersName: cn=idmgmt,ou=user,ou=service,dc=csupomona,dc=edu
slapadd refused to load the input file with this record at the top, I ended up deleting it and then it seemed to load fine. I'm not sure where this record came from? From what I could research, it seems glue records are created when you delete part of the hierarchy that is in between the top and some lower record? I don't think I did that, plus I don't see why it would have an empty DN? This must have something to do with my attempt to implement the memberof overlay, as I have never seen it before.
Any thoughts?
Thanks.
--On Friday, October 11, 2013 1:10 PM -0700 "Paul B. Henson" henson@acm.org wrote:
Any thoughts?
Did you correctly load the memberof overlay onto all servers?
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Friday, October 11, 2013 2:22 PM
Did you correctly load the memberof overlay onto all servers?
Evidently not. While the overlay was eventually configured on all of the servers, in order to avoid a service outage it was not done at exactly the same time on all of them. In hindsight, with the knowledge that contrary to the documentation the attribute was replicated, it would've been better to update the configuration on the slaves first, then the active master, whereas I updated configuration on a master first, resulting in an invalid attribute being replicated to the slaves.
This caused the creation of the glue record? What was being glued together? Or did the glue record serve some other purpose in this instance than the one that I found documented?
Thanks.
openldap-technical@openldap.org
-
Paul B. Henson -
Quanah Gibson-Mount