Pierangelo Masarati wrote the following on 2009/04/22 13:10:
Marcel Berteler wrote:
Our test environment:
openldap 2.4.16 with Postgres backend I have loaded CORE in slapd.conf as well as our custom schema for our users
The only ACL in the conf is ACCESS TO * BY * WRITE
Our 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.
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?
[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);
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 OU
Maybe if you let others look at your logs, others can figure it out for you.
What log level do you recommend and what specific part of the log files are of use to 'debug' this?
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