Re: sql-backend

["Pierangelo Masarati" <ando@sys-net.it>]

> hi adam!
>
> work your sql-backend?
>
> Adam Williams wrote:
>
>>>as you could read is my config not working but i will help and me :).
>>> ...
>>>
>>>
>>>>load_schema_map(): at_query 'SELECT
>>>> name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u
>>>> FROM ldap_attr_mappings WHERE oc_map_id=?' load_schema_map():
>>>> objectClass 'inetOrgPerson' is not defined in schema
>>>> ==>backsql_free_db_conn()
>>>>
>>>>
>>
>>Are you includeing /etc/openldap/schema/inetorgperson.schema in
>>slapd.conf?
>>
>>
> yes, but i see ...
>
> [...]
> ==>backsql_add(): adding entry 'dc=sql,dc=hosting'
> oc_check_required entry (dc=sql,dc=hosting), objectClass "dcObject"
> oc_check_required entry (dc=sql,dc=hosting), objectClass "organization"
> oc_check_allowed type "objectClass"
> oc_check_allowed type "o"
> oc_check_allowed type "dc"
> 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(): cannot determine objectclass of entry -- aborting

In your ldap_oc_mappings there's no way
to find how to map the entry you provided
to an objectClass that is known to your
back-sql instance.

> the straing thing is that the other database works great with db 4.1.


this has REALLY nothing to do with back-sql:
the entry you're using can be totally fine,
compliant with the latest (or backward
compatible with the earliest) LDAP standard,
but if the back-sql doesn't know how to store
it in the RDBMS there's no way it can work.

back-bdb stores the entries internally, so
as soon as they're fine the always get stored.

I assume, from wehat you're stating, that you
never had a look at slapd-sql(5), which clearly
statesm, in its opening:

       The primary purpose of this slapd(8) backend is to PRESENT
       information stored in some RDBMS as an LDAP subtree  with-
       out  any programming (some SQL and maybe stored procedures
       can't be considered programming, anyway ;).

       ...

       It is NOT designed as a general-purpose backend that  uses
       RDBMS  instead  of BerkeleyDB (as the standard BDB backend
       does), though it can be used as such with several  limita-
       tions.    You   can   take  a  look  at  http://www.openl-
       dap.org/faq/index.cgi?file=378 (OpenLDAP  FAQ-O-Matic/Gen-
       eral  LDAP  FAQ/Directories vs. conventional databases) to
       find out more on this point.


>
>  >>> dnPrettyNormal: <cn=Manager,dc=my,dc=hosting>
> => ldap_bv2dn(cn=Manager,dc=my,dc=hosting,0)
> <= ldap_bv2dn(cn=Manager,dc=my,dc=hosting,0)=0
> => ldap_dn2bv(272)
> <= ldap_dn2bv(cn=Manager,dc=my,dc=hosting,272)=0
> => ldap_dn2bv(272)
> <= ldap_dn2bv(cn=manager,dc=my,dc=hosting,272)=0
> <<< dnPrettyNormal: <cn=Manager,dc=my,dc=hosting>,
> <cn=manager,dc=my,dc=hosting>
> do_bind: version=3 dn="cn=Manager,dc=my,dc=hosting" method=128
> ==> bdb_bind: dn: cn=Manager,dc=my,dc=hosting
> bdb_dn2entry_rw("cn=manager,dc=my,dc=hosting")
> => bdb_dn2id_matched( "cn=manager,dc=my,dc=hosting" )
> ====> bdb_cache_find_entry_dn2id("dc=my,dc=hosting"): 1 (1 tries)
> ====> bdb_cache_find_entry_id( 1 ) "dc=my,dc=hosting" (found) (1 tries)
> ====> bdb_cache_return_entry_r( 1 ): returned (0)
> do_bind: v3 bind: "cn=Manager,dc=my,dc=hosting" to
> "cn=Manager,dc=my,dc=hosting"
> send_ldap_result: conn=9 op=0 p=3
> send_ldap_result: err=0 matched="" text=""
> send_ldap_response: msgid=1 tag=97 err=0
> ber_flush: 14 bytes to sd 12
>
>
> i build the mysql database with backsql_create.sql what ever there must
> be the problem!

Apparently, you didn't load the meta-data.
"backsql_create.sql" populates an example RDBMS
__BEFORE__ it is back-sql enabled.  You need
to populate the back-sql aware portion of the
database with "testdb_metadata.sql" before you
even run slapd with any instance of back-sql.

This is clearly described in slapd-sql(5) under
the "METAINFORMATION USED", although, I admit,
the "testdb_metadata.sql" is never explicitly
mentioned (sig!).  In any case, crafting meta-
data for back-sql is not a simple exercise, so
I wouldn't suggest to start playing with slapd
by using back-sql, and significantly by trying
to load the database from scratch using add
operations!

It is very unlikely you can write your meta-data
in order to entirely load a database, even for
a very simple example.  Writing thru back-sql
should be an exception; routine writes should
occur directly in the RDBMS.

I hope I was clear enough.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it