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. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
