> 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
>
> Jan may simply have omitted to;
>
> 1) Re-enable anonymous binds on the primary LDAP server (supplier), and
> 2) Register the secondary LDAP server (consumer) with the primary
> LDAP server during its setup, and
> 3) Load the schema extensions on the consumer / use fractional
> replication.
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
>
> PS: Please keep me in CC: on your replies, for I read the archives
> only once my attention is drawn to them. Thanks.
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
No comments:
Post a Comment