Pierangelo Masarati wrote the following on 2009/04/22 13:10:
What I do not understand than is that this [1] example does not define functions for editing and creating OUs. Does that mean the only way of adding an OU if you do not define the related functions is by directly adding them to the SQL database? Should I define the functions to create and edit OU as well if I want to edit / delete an OU via ldap?Marcel Berteler wrote:Our test environment: openldap 2.4.16 with Postgres backendI have loaded CORE in slapd.conf as well as our custom schema for our usersThe only ACL in the conf is ACCESS TO * BY * WRITEOur tree looks like this and I have loaded the data tables and meta-data tables:dc=example,dc=come ou=people,dc=example,dc=com cn=user1,dc=example,dc=com The setup is working about 60%. with openLdapAdmin, I can see the tree and I can add users. What I can not do, is add an OU. It gives me: LDAP said: Server is unwilling to perform Error number: 0x35 (LDAP_UNWILLING_TO_PERFORM) Description: The LDAP server refused to perform the operation.If I get this on our custom schema, I can explain this by not having the right meta-data and procedures loaded. But as this is part of the CORE schema, am I right in only adding the meta-data for OU in ldap_attr_mappings without add or delete procedures?No you're not. There is no core schema mapping in back-sql, everything needs to be mapped by you, including core schema items. In fact, back-sql's logic has no notion of attributes per se, but only of attributes in some relationship with (structural) objectClasses according to the mappings you define.If you mapped, say, "cn" for "person", don't expect to be able to use "cn" in, say, "inetOrgPerson" or "device". You need a separate "cn" mapping for each objectClass that needs to use it.
[1] : http://www.darold.net/projects/ldap_pg/HOWTO/x178.html -- The organizationalUnit objectClass insert into ldap_oc_mappings (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) values (2,'organizationalUnit','organizational_unit','id',NULL,NULL,0);
What log level do you recommend and what specific part of the log files are of use to 'debug' this?I have looked at the log files and outputs but I can not figure out what is going wrong and why it is not accepting any new OUMaybe if you let others look at your logs, others can figure it out for you.
Let me anticipate that since you're using OpenLDAP 2.2.6, there is no chance any issue can get fixed.
On our test box, we don't use 2.2.6 but 2.4.16 Marcel