[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: How to disable schema

amol g wrote:
How do I disable schema???? 

My latest ldapadd error is pasted below.

[root@srvrenres bjohn]# ldapadd -x -D
"cn=Manager,dc=srvrenres,dc=com"
-W -f boss.ldif
Enter LDAP Password:
adding new entry "o=NetscapeRoot"
ldap_add: No such object

ldif_record() = 32

I don't know that you want to disable the schema checking in OpenLDAP. You should instead clean the boss.ldif file of all Netscape specific data. The entire branch under "o=NetscapeRoot" is extraneous to your own data, and has lots of Netscape schema specific junk. You should not attempt to add any of it to your OpenLDAP implementation.

A better approach would be to export only the subtree that is relevant to the data you want to add. For example, if your organization's base dn is dc=foo, dc=com, then only export only what is in subtree "dc=foo,dc=com" from your Netscape directory (you can do this from the Admin Console). Better yet, build the top of your subtree in OpenLDAP from scratch, then migrate your tree a branch or two at a time. Once you get it working, just concatenate the resulting ldif's into one "boss" file, paying particular attention to adding entries in the correct order.

Another issue you'll have are the access control rules. They will be scattered amongst your data, with the attribute "aci: ". It would be a good idea to record the relevant ones somewhere, but you'll need to remove them from your ldif before loading it into OpenLDAP because the "aci: " attribute is peculiar to the Netscape schema. All access control rules for OpenLDAP should instead be consolidated in the slapd.conf file.

Unfortunately, there will also be some applicable aci rules under that o=NetscapeRoot branch. If you use the directory administration or configuration administration userids, for example, you will need to do extra work to enable these in OpenLDAP. Of course, you can always just use the admin as defined in slapd.conf to accomplish things with much the same authority.

This is one of many prices you pay for what were recently described as "organic" ACLs. I distrust central authority in systems of government, but for systems administration where security is at all important, central definition is key. The OpenLDAP ACL configuration isn't just better, it's a reason to migrate.

Jon Roberts
www.mentata.com