[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault



masarati@aero.polimi.it wrote:

> OK, I've found the problem, and it seems to be a configuration problem. 
> Please read below.

Great. Thanks for taking the time to look at this.

> ^^^ An entry with the same DN exists in the superior database.  As a
> consequence, this entry is returned by back-bdb's tool functions, but
> backglue tries to release it using back-perl.  Since back-perl does not
> have any tool functions, what is considered a safe replacement is used. 
> Unfortunately, the safe replacement doesn't know how to deal with
> read-only entries returned by back-bdb.  The solution consists in:
> 
> - temporarily commenting the instance of back-perl
> 
> - removing this entry from your back-bdb
> 
> - re-enabling the instance of back-perl
> 
> A follow-on to this ITS could be to devise a means to detect whether a
> superior database contains entries that belong to a subordinate one, and
> warn the administrator of the inconsistency.

Ah I see. I remember thinking at the time whether or not I needed a DN 
within my master database too (similar to a FS mount point) but 
obviously it has been this that has been causing the problem. At least 
now I know that this isn't the case and can work around it.

I'd expect a subordinate database to always override the master (similar 
to the mount point idea again) but in the case of slapcat then I believe 
it should probably just ignore a subordinate that doesn't have a 
physical backing store presence such as back-perl. I'm not sure quite 
how you'd mark this though.

An appropriately worded warning would definitely be a good start, 
especially as when I first started working with back-perl as a 
subordinate, I was confused that putting the subordinate definition 
after the master would always fail whereas putting it before would allow 
it to work.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs