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?
http://git.kolab.org/kolab-schema/tree/kolab3.ldif
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.
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, 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.
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.
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.
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com
pgp: 9342 BF08
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
