[Date Prev][Date Next]
Re: Getting more meaningful error out of back-config
- To: firstname.lastname@example.org
- Subject: Re: Getting more meaningful error out of back-config
- From: Ralf Haferkamp <email@example.com>
- Date: Wed, 18 Jul 2007 15:57:18 +0200
- Content-disposition: inline
- In-reply-to: <463F7D4B.firstname.lastname@example.org>
- References: <email@example.com> <463F6C34.firstname.lastname@example.org> <463F7D4B.email@example.com>
- User-agent: KMail/1.9.5
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
SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg
F: +49-911-74053575 - Ralf.Haferkamp@suse.com