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