[Date Prev][Date Next]
Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
On Mon, 2 Jun 2008, firstname.lastname@example.org 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
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
>> 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