Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)

[duncan.gibb@siriusit.co.uk]

Howard Chu wrote:

HYC> I modified your test case to make it easier to run.
HYC> The new test is in ftp.openldap.org:incoming/its5430.tgz.1

Looks good; thank you very much for this.


HYC> There were also some errors in your config file templates,
HYC> which are corrected in the above archive.

HYC> Most notably, in template 1, you explicitly configured
HYC> syncprov on top of glue instead of taking the default
HYC> behavior of syncprov under glue.  As documented in
HYC> slapd.conf(5), you should only do that when you want a
HYC> single syncprov overlay to be master of the entire tree.
HYC> In this case, you clearly want syncprov to only master
HYC> one portion of the tree, with the subordinate being
HYC> taken care of by its own syncprov overlay.

That's a legacy of several previous iterations of the real project. 
Ideally each box would have at most two backends - one holding 
everything for which it's a consumer, and on the relevant machines a 
second backend holding the data for which it's master, then glue, then a 
single syncprov making the whole tree available.  My colleague who 
implemented the first iteration did it that way and it should have 
worked, but the syncprov-glue interactions in 2.3.x were such that that 
resulted in sections of the tree not replicating and/or disappearing in 
various ill-defined situations.

Replicating each subordinate separately and gluing them together 
per-server was a hack; the default overlay ordering gave us visible 
entries of objectclass glue (and consequent missing subtrees) on some 
consumers, so we reversed them.  It's imperfect but less imperfect than 
it was before ;-)

We will re-architect in the light of the recent changes to syncprov and 
glue.  It has already been pointed out that big-picture discussion is 
noise on this list...


HYC> Not an error, but you used unique rids across all of the
HYC> config files.  rids only need to be unique within a single server.

I know.  That's expediency in the config generator - it just increments 
a global counter each time it processes a consumer<-->provider relation. 
  I'll make it more elegant next time round ;-)


Cheers


Duncan