RE: sql-backend - ldapadd fails

[dpinkard@AccessLine.com]

I'd say that it is likely do to my relative lack of understanding about
LDAP, except the configurations and schemas I'm using were directly lifted
from ~/src/openldap-2.3.11/servers/slapd/back-sql/rdbms_depend/mysql
including slapd.conf which now reads:

include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /usr/local/var/slapd.pid
argsfile        /usr/local/var/slapd.args

#######################################################################
# sql database definitions
#######################################################################

database        sql
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
#suffix         "o=sql,c=RU"
#rootdn         "cn=root,o=sql,c=RU"
rootpw          secret
dbname          ldap
dbuser          ldap
dbpasswd        *********
subtree_cond    "ldap_entries.dn LIKE CONCAT('%',?)"
insentry_stmt   "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval)
VALUES (?,?,?,?)"
has_ldapinfo_dn_ru      no


The ldif I was adding is:
dn: cn=Dan Pinkard,dc=example,dc=com
objectClass: inetOrgPerson
cn: Dan Pinkard
sn: Pinkard


As you mentioned the tracelog does explain things a little, but I'm not sure
what it's telling me to fix:
==>backsql_add("cn=Dan Pinkard,dc=example,dc=com")
oc_check_required entry (cn=Dan Pinkard,dc=example,dc=com), objectClass
"inetOrgPerson"
oc_check_allowed type "objectClass"
oc_check_allowed type "cn"
oc_check_allowed type "sn"
oc_check_allowed type "structuralObjectClass"
oc_check_allowed type "entryUUID"
oc_check_allowed type "creatorsName"
oc_check_allowed type "createTimestamp"
oc_check_allowed type "entryCSN"
oc_check_allowed type "modifiersName"
oc_check_allowed type "modifyTimestamp"
   backsql_add("cn=Dan Pinkard,dc=example,dc=com"): create procedure is not
defined for structuralObjectClass "inetOrgPerson" - aborting
send_ldap_result: conn=0 op=1 p=3
send_ldap_response: msgid=2 tag=105 err=53
ber_flush: 58 bytes to sd 9
<==backsql_add("cn=Dan Pinkard,dc=example,dc=com"): 53 "operation not
permitted within namingContext"
connection_get(9): got connid=0
connection_read(9): checking for input on id=0


The confusing part here is that it makes no reads to determine anything at
all.. it just 




-----Original Message-----
From: Pierangelo Masarati [mailto:ando@sys-net.it]
Sent: Monday, November 28, 2005 1:44 PM
To: dpinkard@AccessLine.com
Cc: OpenLDAP-software@OpenLDAP.org
Subject: Re: sql-backend - ldapadd fails


On Mon, 2005-11-28 at 12:03 -0800, dpinkard@AccessLine.com wrote:
> Some time ago someone posted about a problem with the SQL back-end
> connecting to a MySQL database. In my case I
> 'm using unixODBC 2.2.11 and MySQL 5.0.15 against openldap-2.3.11, and I'm
> getting the same problem I saw listed here some months ago. 
> 
> ldapadd -x -h 192.168.0.3 -D "cn=Manager,dc=example,dc=com" -wsecret -f
> example.ldif3
> adding new entry "cn=Dan Pinkard,dc=example,dc=com"ldap_add: Server is
> unwilling to perform (53)
>         additional info: operation not permitted within namingContext

To say anything more about that we need to know more, because back-sql
is far from something that just works out of the box.  In detail, I need
to know about your slapd.conf and your settings in ldap_oc_mappings and
ldap_attr_mappings tables; a schematic of your ldap_entries would help
as well.

> I know that the ODBC and SQL pieces are functioning, as it can read
> successfully when I execute ldapsearch -x -h 192.168.0.3 -b
> 'dc=example,dc=com' '(objectclass=*)', however I do not even get a
> connection to the MySQL database when I attempt the ldap add. 

sounds like back-sql doesn't let you there because it knows in advance
it has no clues about how to write to the RDBMS; should be a mapping
problem, but I'm just guessing.

I'd note that back-sql write routines return that error code and that
very message in many, many places; each of those places, however,
produces a very specific log message (at "trace" level).  If you look at
the server logs at "trace" level you'll quickly discover if and what is
missing from your configuration/metadata.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------