Re: (ITS#7499)

[hyc@symas.com]

Benin Technologies wrote:
> Yes the fix worked (I downloaded the latest openldap.tar.gz on your
> gitweb and installed it). Now slapd starts after having converted to
> cn=config
>
> But after the conversion my ldapsearch returns an 80 error (with
> slapd.conf it worked, the data from PostgreSQL where returned)
> Thus my question : are there other steps to be taken after the
> conversion (all I did was : slaptest -f slapd.conf -F slapd.d)

Ah. In that case the fix must still be wrong. (Sorry, I'm patching this blind 
as I don't have any current SQL installation to test with.)

> I don't think this has something to do with that 7499 bug, so I'll post
> the question on the technical mailing list (but if nobody bumped into
> that 7499 bug before, it logically means that nobody is using back-sql
> with cn=config yet)

Agreed, I think it's unlikely that anyone else has used this yet.
>
> ldapsearch -x -h localhost -b "dc=example,dc=com" "(objectClass=*)"
> # extended LDIF
> #
> # LDAPv3
> # base <dc=example,dc=com> with scope subtree
> # filter: (objectClass=*)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 80 Other (e.g., implementation specific) error
>
> # numResponses: 1
>
>
> Le 24/01/2013 04:46, Howard Chu a écrit :
>> Benin Technologies wrote:
>>>>>>> Yes, it's a bug. The conversion should have used double-quotes on
>>> these
>>>>>>> parameters. Will be fixed shortly.
>>>
>>>
>>> ok thanks, I added manually the double-quotes on olcSqlInsEntryStmt in
>>> the file olcDatabase={1}sql.ldif, like this :
>>>
>>> olcSqlInsEntryStmt: "insert into ldap_entries
>>> (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from
>>> ldap_entries),?,?,?,?)"
>>>
>>>
>>> Now slapd starts, but ldapsearch returns "80 Other (e.g., implementation
>>> specific error)". With the old "slapd.conf", ldapsearch works fine. Is
>>> there anything else to do when converting slapd.conf to cn=config on a
>>> back-sql implementation ?
>>
>> Yes, actually the quotes are optional, but you must get the fix from git.
>> Commit 56a0d9004f0fba943028041ea5af62338b6dfccd
>>>
>>>
>>>
>>>
>>> Le 24/01/2013 02:44, hyc@symas.com a écrit :
>>>> benintechnologies@yahoo.fr wrote:
>>>>> Hi,
>>>>>
>>>>> thank you for your reply
>>>>>
>>>>> I simply took the slapd.conf file adapted to PostgreSQL in the source
>>>>> (/openldap-2.4.33/servers/slapd/back-sql/rdbms_depend/pgsql)
>>>>>
>>>>> In that file, we have :
>>>>> olcSqlInsEntryStmt: insert into ldap_entries
>>>>> (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from
>>>>> ldap_entries),?,?,?,?)
>>>>>
>>>>> it works with static configuration (slapd.conf) : I successfully
>>>>> managed
>>>>> to insert some data into the postgresql tables
>>>>>
>>>>> But after having converted it to cn=config (slaptest -f slapd.conf -F
>>>>> slapd.d) slapd doesn't start anymore :
>>>>> 0ff3f0a<<<  dnPrettyNormal:<cn=root,dc=example,dc=com>,
>>>>> <cn=root,dc=example,dc=com>
>>>>> 50ff3f0a olcSqlInsEntryStmt: value #0:<olcSqlInsEntryStmt>  extra
>>>>> cruft
>>>>> after<SQL expression>.
>>>>> 50ff3f0a config error processing olcDatabase={1}sql,cn=config:
>>>>> <olcSqlInsEntryStmt>  *extra cruft after<SQL expression>*
>>>>> 50ff3f0a send_ldap_result: conn=-1 op=0 p=0
>>>>> 50ff3f0a send_ldap_result: err=19 matched="" text=""
>>>>> 50ff3f0a slapd destroy: freeing system resources.
>>>>> 50ff3f0a slapd stopped.
>>>>> 50ff3f0a connections_destroy: nothing to destroy.
>>>>>
>>>>> I believe it's a bug, no ?
>>>
>>>
>>
>>
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/