Getting more meaningful error out of back-config

Hi,

I'd like to improve the error messages that back-config
returns via LDAP to 
the client. Currently in many case you only get back a very
generic error 
messages. E.g. when trying to add a second monitor database
you just get:
Error code LDAP_OTHER with the diagnostic message set to
"<olcDatabase> failed 
init". To find out what really went wrong you need to
dig up the logfiles.

One way to get more meaningful error messages to the client
would be by adding 
an additional const char** text parameter to the _db_init
functions (and 
probably some other of the BI_db_func() functions as well),
similiar to what 
is done in many other case when error messages need to be
passed to the 
caller.

Does somebody have better ideas how to achieve this?

-- 
Ralf

Ralf Haferkamp wrote:
> Hi,
> 
> I'd like to improve the error messages that back-config
returns via LDAP to 
> the client. Currently in many case you only get back a
very generic error 
> messages. E.g. when trying to add a second monitor
database you just get:
> Error code LDAP_OTHER with the diagnostic message set
to "<olcDatabase> failed 
> init". To find out what really went wrong you need
to dig up the logfiles.
> 
> One way to get more meaningful error messages to the
client would be by adding 
> an additional const char** text parameter to the
_db_init functions (and 
> probably some other of the BI_db_func() functions as
well), similiar to what 
> is done in many other case when error messages need to
be passed to the 
> caller.
> 
> Does somebody have better ideas how to achieve this?
> 
That sounds like a good enough approach. Go ahead...

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

Howard Chu wrote:
> Ralf Haferkamp wrote:
>> Hi,
>>
>> I'd like to improve the error messages that
back-config returns via
>> LDAP to the client. Currently in many case you only
get back a very
>> generic error messages. E.g. when trying to add a
second monitor
>> database you just get:
>> Error code LDAP_OTHER with the diagnostic message
set to
>> "<olcDatabase> failed init". To
find out what really went wrong you
>> need to dig up the logfiles.
>>
>> One way to get more meaningful error messages to
the client would be
>> by adding an additional const char** text parameter
to the _db_init
>> functions (and probably some other of the
BI_db_func() functions as
>> well), similiar to what is done in many other case
when error messages
>> need to be passed to the caller.
>>
>> Does somebody have better ideas how to achieve
this?
>>
> That sounds like a good enough approach. Go ahead...

What about passing a SlapReply *, or a specific type? 
SlapReply already
contains sr_err and sr_text, and other useful parameters
that could be
filled by functions for the purpose of being returned to a
client (I can
figure out possible uses of sr_matched and of sr_ctrls for
future
extensibility).  Probably, a REP_INTERNAL should be added to
the REP_*
enum, to clearly distinguish responses to internal
operations not
related to the protocol.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masaratisys-net.it
---------------------------------------

Ralf Haferkamp wrote:

>> What about passing a SlapReply *, or a specific
type?
> I'd like to avoid defining an addtional type. But using
SlapReply for my 
> purpose would certainly be possible I think. I'll take
a look into this.

Passing a pointer to struct, rather that a char**, would
save you from
reworking the whole API once more, in case you need to
pass/want back
more elaborate data in the future.  Passing a SlapReply*
could require
twice the effort as soon as your needs diverge from what's
available in
SlapReply; this could be avoided by adding yet another
structure to
SlapReply's union for internal purposes, if ever required.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masaratisys-net.it
---------------------------------------

On Monday 07 May 2007 21:26, Pierangelo Masarati wrote:
> Howard Chu wrote:
> > Ralf Haferkamp wrote:
> >> Hi,
> >>
> >> I'd like to improve the error messages that
back-config returns via
> >> LDAP to the client. Currently in many case you
only get back a very
> >> generic error messages. E.g. when trying to
add a second monitor
> >> database you just get:
> >> Error code LDAP_OTHER with the diagnostic
message set to
> >> "<olcDatabase> failed init".
To find out what really went wrong you
> >> need to dig up the logfiles.
> >>
> >> One way to get more meaningful error messages
to the client would be
> >> by adding an additional const char** text
parameter to the _db_init
> >> functions (and probably some other of the
BI_db_func() functions as
> >> well), similiar to what is done in many other
case when error messages
> >> need to be passed to the caller.
> >>
> >> Does somebody have better ideas how to achieve
this?
> >
> > That sounds like a good enough approach. Go
ahead...
>
> What about passing a SlapReply *, or a specific type? 
SlapReply already
> contains sr_err and sr_text, and other useful
parameters that could be
> filled by functions for the purpose of being returned
to a client (I can
> figure out possible uses of sr_matched and of sr_ctrls
for future
> extensibility).  Probably, a REP_INTERNAL should be
added to the REP_*
> enum, to clearly distinguish responses to internal
operations not
> related to the protocol.

After having some time to look again at this I think the
easiest approach 
would be to just pass the ConfigArgs pointer down to the
BI_db_func functions 
(_db_init, _db_open and _db_close). That way they could
directly print into 
the ca->msg field which finally ends up in sr_text of the
SlapReply 
structure.

regards,
	Ralf

-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409
Nuernberg
T: +49-911-74053-0
F: +49-911-74053575 - Ralf.Haferkampsuse.com