Am Saturday, 15. February 2014 schrieb Rich Megginson:
On 02/14/2014 05:20 PM, Jeroen van Meeuwen (Kolab Systems) wrote:
> On 2014-02-14 23:03, Jan Kowalsky wrote:
>> On 2014-02-14 22:15, Rich Megginson wrote:
>>> On 02/14/2014 01:57 PM, Jan Kowalsky wrote:
>>>> Maybe I have to mention that there are some extra schemas used by
>>>> kolab - namely the kolab2 schema. Could it be possible that there
>>>> are some conflicts?
>>>
>>> Yes.
>
> Could you elaborate on how a set of schema extensions as thrilling as
> ours (not!) could cause dirsrv to issue a message about a replication
> agreement being invalid?
I don't know. It's theoretically possible - 'The replication agreement
named "xxx" could not be correctly parsed' could be schema/syntax
related, because it doesn't seem to be related to the replication
specific validation, but I don't know how it would cause this particular
failure.
>
http://git.kolab.org/kolab-schema/tree/kolab3.ldif
Looks ok. I don't see anything wrong.
> I can only imagine replication failing if the consumer does not have
> the (same) extensions loaded, and no fractional replication is used --
> but that still does not get me to a supplier declaring a replication
> agreement invalid.
Right.
>>>> If set up 389-ds with setup-ds and not with the kolab frontend
>>>> setup-kolab ldap I can replicate the primary db without problem.
>>>
>>> So it would appear to be a problem with kolab.
>>> Have you brought this to the attention of the people supporting kolab?
>>
>> yes, I did:
https://issues.kolab.org/show_bug.cgi?id=2854
>
> Which is how I came here ;-)
>
> Kolab doesn't normally touch replication -- we do however seed the
> configuration for the initial domain database and additional
> databases, commonly with a cn of $domain.replace('.','_') --
there's
> another gotcha in using dots in database names,
What is the gotcha?
> and we can't afford not to distinguish
example.com from
example.org.
>
> This has worked very well for us, across many deployments, with many,
> many domains (in separate root dns, in separate databases, separately
> replicated).
>
> The only circumstance under which we do touch replication, is when
> additional parent domain name spaces are added to a deployed groupware
> environment, that has pre-existing *multi-master* configuration
>
> configured. You can read all about how this occurs here:
>
http://git.kolab.org/pear/Net_LDAP3/tree/lib/Net/LDAP3.php#n234
>
> The function you are reading about here is triggered on a domain_add()
> -- the same function that is triggered to add a domain name space with
> isolated root dn and separate databases in a deployment not replicated
>
> -- the business end of which starts here:
>
http://git.kolab.org/kolab-wap/tree/lib/Auth/LDAP.php#n237
I didn't any kolab-specific for replication
> Jan may simply have omitted to;
As mentioned: I haven't much experience with replication. I tried to follow
the manual for single-master replication:
https://access.redhat.com/site/documentation/en-
US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-
Configuring-Replication-cmd.html
> 1) Re-enable anonymous binds on the primary LDAP server
(supplier), and
No. I didn't in fact. Is it necessary that the supplier allows anonymous
binds?
> 2) Register the secondary LDAP server (consumer) with the
primary
>
> LDAP server during its setup, and
What do you mean with register? I did nothing special in this relation.
> 3) Load the schema extensions on the consumer / use
fractional
>
> replication.
The consumer as the supplier are pure kolab ldap installation - set up with
setup-kolab ldap. Both are configured for the same fqdn (e.g.
example.org).
After setup I added in both instances the same new domain entry (e.g.
test.net)
Then I added
* the replication manager on consumer
* An replication entry on both servers
* a replication agreement on the supplier
(with the statements mentioned in the earlier posts)
nothing more.
Don't blame me if this ist not sufficiant ;-)
The problem ist not that replication isn't working at all - but it's not
working anymore after restarting the service on the supplier side.
This is also the reason because I thought that activating the replication was
more or less the right way.
Jan, can you verify that you have done this?
> This is not too unreasonable, because configuring replication is not
> covered on our end -- the Kolab community does not support it.
>
> Hence, I don't feel the issue necessarily belongs with us. I have
> thousands of deployments happily drinking champagne while Kolab does
> the heavy lifting -- with help of 389 -- as does the 389 community.
>
> That said, I realize this may turn out to be a hard nut to crack, and
> certainly not the first problem we've encountered with 389 DS, so I'd
> like to stay involved for as much as I can.
Jan, please file a 389 ticket - I doubt we are going to figure this out
until someone with some familiarity with the 389 code and gdb can
reproduce this issue.
> Kind regards,
>
> Jeroen van Meeuwen
Thanks for dealing with this issue!
Best regards
Jan.