at some point in the past, i wound up taking drastic measures and rebuilt my two ldap boxes after taking a backup of the data. i think my process could use some fine tuning and polishing, as a weird nuance has found its way into my environment.
i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed".
i think the root of my issue is that i backed up one of the two boxes and restored the one backup to both boxes while they were both offline. i believe that because they both have the same backed up data on them, some of the internal attributes are identical and therefore conflict. i have seen logs about ContextCSNs being identical, but haven't had time to investigate those messages till now. in any case, whatever i did wrong now does not allow the mdb settings to be replicated between the boxes.
what i am looking to understand is how to i correct the situation. i am looking to avoid recreating all of the data, so using backups, exports, etc is something i want to do, and do correctly.
would i need to capture slapcat output to a file, or is ldapsearch the correct way to export the data for backup/restore needs? do i need to follow a destructive path to correct this issue or will surgery on the mdb correct my issue?
i am running 2.4.39 on Fedora 20. any pointers would be appreciated.
brendan
Brendan Kearney wrote:
i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed".
Hmm, I have some doubts.
It would be helpful to the exact LDIF of the modify operation.
Ciao, Michael.
On 07/08/2015 10:11 AM, Michael Ströder wrote:
Brendan Kearney wrote:
i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed".
Hmm, I have some doubts.
It would be helpful to the exact LDIF of the modify operation.
Ciao, Michael.
using phpLdapAdmin, i attempted to add an additional index of "member eq" and got the below:
Could not perform ldap_modify operation. LDAP said: Cannot modify object class Error number: 0x45 (LDAP_NO_OBJECT_CLASS_MODS) Description: ObjectClass modifications are not allowed.
i'll have to try manually adding with ldapmodify.
Brendan Kearney wrote:
On 07/08/2015 10:11 AM, Michael Ströder wrote:
Brendan Kearney wrote:
i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed".
Hmm, I have some doubts.
It would be helpful to the exact LDIF of the modify operation.
using phpLdapAdmin, i attempted to add an additional index of "member eq" and got the below:
Could not perform ldap_modify operation. LDAP said: Cannot modify object class Error number: 0x45 (LDAP_NO_OBJECT_CLASS_MODS) Description: ObjectClass modifications are not allowed.
I suspect it to be a client issue.
i'll have to try manually adding with ldapmodify.
Yes. If it fails then provide the exact LDIF change record used.
Ciao, Michael.
On 07/08/2015 01:40 PM, Michael Ströder wrote:
Brendan Kearney wrote:
On 07/08/2015 10:11 AM, Michael Ströder wrote:
Brendan Kearney wrote:
i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed".
Hmm, I have some doubts.
It would be helpful to the exact LDIF of the modify operation.
using phpLdapAdmin, i attempted to add an additional index of "member eq" and got the below:
Could not perform ldap_modify operation. LDAP said: Cannot modify object class Error number: 0x45 (LDAP_NO_OBJECT_CLASS_MODS) Description: ObjectClass modifications are not allowed.
I suspect it to be a client issue.
i'll have to try manually adding with ldapmodify.
Yes. If it fails then provide the exact LDIF change record used.
Ciao, Michael.
ldif file: --------- dn: olcDatabase={2}mdb,cn=config changetype: modify delete: olcDbIndex - add: olcDbIndex olcDbIndex: automountMapName,entryUUID,gidNumber,ipServicePort,ipServiceProtocol,krbPrincipalName,member,memberUid,objectClass,sudoHost,uid,uidNumber,entryCSN,modifyTimestamp eq - add: olcDbIndex olcDbIndex: cn,givenName,mail,sudoHost,surname,ou eq,sub
ldapmodify command: ----------------------------- [brendan@desktop ~]$ ldapmodify -vvv -f index.ldif ldap_initialize( <DEFAULT> ) SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 56 SASL data security layer installed. delete olcDbIndex: add olcDbIndex: automountMapName,entryUUID,gidNumber,ipServicePort,ipServiceProtocol,krbPrincipalName,member,memberUid,objectClass,sudoHost,uid,uidNumber,entryCSN,modifyTimestamp eq add olcDbIndex: cn,givenName,mail,sudoHost,surname,ou eq,sub modifying entry "olcDatabase={2}mdb,cn=config" ldap_modify: Cannot modify object class (69) additional info: structural object class modification from 'olcHdbConfig' to 'olcMdbConfig' not allowed
so, i have conflicting objectClass and structuralObjectClass values. having seen the above error, i had phpLdapAdmin show me the internal attributes, and the structuralObjectClass is set to olcHdbConfig, but the objectClass is set to olcDatabaseConfig and olcMdbConfig.
this is a function of my export/import. i moved from one db type to the other in the upgrade, and this is a missed edit in the ldif manipulation i did between the export and import.
so, how do i un-bugger this ball of wax?
thanks,
brendan
--On Wednesday, July 08, 2015 3:00 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
this is a function of my export/import. i moved from one db type to the other in the upgrade, and this is a missed edit in the ldif manipulation i did between the export and import.
so, how do i un-bugger this ball of wax?
Export cn=config with slapcat, fix the data, reimport it with slapadd.
--quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 07/08/2015 02:06 PM, Quanah Gibson-Mount wrote:
--On Wednesday, July 08, 2015 3:00 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
this is a function of my export/import. i moved from one db type to the other in the upgrade, and this is a missed edit in the ldif manipulation i did between the export and import.
so, how do i un-bugger this ball of wax?
Export cn=config with slapcat, fix the data, reimport it with slapadd.
--quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
is there a wipe / delete action necessary before reimporting?
--On Wednesday, July 08, 2015 3:40 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
is there a wipe / delete action necessary before reimporting?
Yes. You'll need to remove your existing cn=config db. I'd rename it just in case, so you can back that out of necessary.
I.e., mv configdir configdir.bak
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Brendan Kearney -
Michael Ströder -
Quanah Gibson-Mount