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.