> 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
No comments:
Post a Comment