0

How can i replace/modify attribute type definition from LDAP server schema? I need to change the syntax of one attribute type.

When i try to use ldapmodify with replace, it gives me the following error:

ldap_modify: DSA is unwilling to perform ldap_modify: additional info: attributeTypes: Replace is not allowed on the subschema subentry

Please help.

Thanks. Sash.

sash
  • 85
  • 2
  • 10
  • 1
    I will only comment since I have nothing to back up my suspicion, but I think you cannot change syntax of an existing ldap attribute as it would introduce data inconsitencies in the directory. You can, however, create a new attribute, copy the data to it using the new syntax and then delete the old attribute. Or, if there's no need to preserve existing data, simply delete the attribute and create it anew with proper syntax definition. – Robert Rossmann Aug 21 '13 at 20:19
  • @Shadow Walker, you are actually right. One cannot change the syntax definition of an attribute in the schema when that attribute is already populated with data. The data need to be unloaded/backed up (e.g , in an LDIF file perhaps) first. The schema changes can be done after that. The data then can be reloaded with the new syntax. – Bora Aug 21 '13 at 21:22
  • @ShadowWalker Deleting the attribute and re-adding will cause any inconsistency? – sash Aug 22 '13 at 11:24
  • I believe that if you delete the attribute from the schema it is also deleted from all objects that have a value associated with that attribute. So it should not cause inconsistencies. @Bora, you seem to be more experienced with this - can you please confirm my belief? Thanks! – Robert Rossmann Aug 22 '13 at 15:06
  • You don't have to delete the attribute from the schema. Its syntax OID can easily be replaced in the schema (after the data unloaded, of course). @Shadow Walker, it depends on the directory server software. Usually, the software expects the objectclasses to be updated explicitly to remove the associated attribute when that attribute is a required (MUST) attribute. – Bora Aug 22 '13 at 22:47
  • I strongly suggest that you don't do this. Add your own attribute type with its own syntax. Don't mess around with predefined stuff like this. – user207421 Aug 23 '13 at 01:13
  • @Bora Thank you. I actually have a custom attribute with 'MAY' in object class with syntax 'telephonenumber', i need to change it to 'directory string' and i'm using critical path meta directory. The amount of data in the directory is very huge. Can you pls help suggesting best way to deal with this? Data-unloading, reloading is good when data is huge? – sash Aug 23 '13 at 06:11
  • @sash, I am not familiar with that particular directory software. However, we did a similar exercise in our directory shop recently to convert an attribute that was incorrectly defined as directory string to an integer. This affected ~400K entries in a directory of ~1M objects. Our directory services are powered by Tivoli Directory Server (TDS), which provides a bulk-load utility. However, we didn't use the tool because we figured that it'd be the same amount of effort if we used good old `ldapsearch` and `ldapmodify` tools.[cont.] – Bora Aug 23 '13 at 16:21
  • We used the `ldapsearch` command with its -L option (or whatever the argument that produces fully qualified LDIF output of the matching entries and attributes) to grab the entries that had the attribute populated and dump the output into an LDIF file. We used awk/sed/your-favorite-swiss-army-tools to manipulate this file to create two operational LDIF files: one for deleting the individual attribute values from each entry and one for adding those values back. We started with the deletion first and executed `ldapmodify` against the LDAP master server so the changes would be propagated[cont.] – Bora Aug 23 '13 at 16:26
  • to all the replicas in the topology. Then, we applied the schema changes to update the syntax OID of the attribute to make it an integer. We did this against all servers as we don't replicate schema changes. Finally, we executed `ldapmodify` against the LDAP master again to load the data back. This was/is relatively tedious work, but it was/is safe and worked/works. We have two directory sites each of which consists of a large cluster of LDAP replicas. Therefore, we paced both `ldapmodify` operations so we wouldn't flood the master with so many updates.[cont.] – Bora Aug 23 '13 at 16:31
  • This could otherwise cause our more important or higher priority updates (e.g., password updates, entitlement/group updates, etc.) to be delayed. We didn't plan for any directory service outage for this as none of the operations would require us to stop/restart the servers (also, since we have so many replicas, we can afford to pull one out of the cluster and do our work on it while the other replicas can happily serve to the clients). The only outage planned was for the application that updated the attribute. It was stopped for the duration of the exercise. I hope this helps. Cheers! – Bora Aug 23 '13 at 16:35

0 Answers0