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