Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie

[rein@OpenLDAP.org]

On Mon, 2 Jun 2008, hyc@symas.com wrote:

> Rein Tollevik wrote:
>
>> I see you have commited an alternative version to syncrepl.c.  This
>> version don't include the serverID in the cookie when syncrepl is used on
>> the glue database itself, only when used on subordinate DBs.  And
>> unfortunately, it is when used on the glue database it is needed (at least
>> in my configuration).
>
> Hm, can you show the configuration you're dealing with now? Is it still
> similar to your test053 setup? (By the way, the test053 in HEAD works 
> with the current code.

No, that test has a stripped down config used to trigger that bug.  To 
show this problem the producer2 would have to syncrepl the basedn back 
from the first producer, and producer2 would need a subordinate database 
which it manages itself (the base DN for the syncrepl used by the first 
producer).

I'm thinking about creating a new test script that tests more of my 
configuration.  It seems as my config is a bit off the usual, as I have 
managed to hit a lot of bugs lately...  And there are still a few open 
issues I would like solved before everything works as I wish, although I 
think all (or at least most) of my critical problems has been solved now.

>> So, I still think we have to always include it when it is configured.
>
> Probably. But when I went down that route it seemed to require configuring it
> in several cases that never needed it before, which is why I changed approach.

It was my intention to avoid changes to existing configurations, and I do 
believe it wasn't needed with my approach.  Although I think it would be 
preferrable (but not necessary) if we could forbid explicit usage of 
serverID=0.  That would require a config change for those that used it. 
But a change to another unused ID should be sufficient, i.e no changes to 
existing databases.

>> Unless there exist some easy way to know that a subordinate DB is not
>> managed by syncrepl.  The only solution I know to that is to loop through
>> all the subordinate DBs and compare the rootdn values.
>
> We can think about this some more but I'd like to get 2.4.10 out now. A final
> resolution of this issue may have to wait for 2.4.11.

That should be OK, this bug isn't critical as it is possible to configure 
around it.

Rein