[Date Prev][Date Next]
Re: Adding OU with PSQL backend
Pierangelo Masarati wrote the following on 2009/04/22 13:10:
What I do not understand than is that this  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 backend
I have loaded CORE in slapd.conf as well as our custom schema for our
The only ACL in the conf is ACCESS TO * BY * WRITE
Our tree looks like this and I have loaded the data tables and
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.
 : 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 OU
Maybe if you let others look at your logs, others can figure it out
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