On 2014-02-14 22:15, Rich Megginson wrote:
On 02/14/2014 01:57 PM, Jan Kowalsky wrote:
> On 2014-02-13 15:12, Rich Megginson wrote:
>> On 02/13/2014 02:05 AM, Jan Kowalsky wrote:
>>> On 2014-02-12 23:25, Rich Megginson wrote:
>>>> On 02/12/2014 02:34 PM, Jan Kowalsky wrote:
>>>>> Hi Rich,
>>>>>
>>>> Not sure what version 1.2.11.15-1 is on Debian. If it is the same
>>>> as
>>>> the upstream 1.2.11.15, that's very old. Should see if you can get
>>>> them to provide 1.2.11.25 or later.
>>>
>>> I tried it again with the newest version in debian unstable:
>>> 1.3.0.3-1
>>> But the same result:
>>
>> Not exactly the same result, unless there is an error message about
>> "cannot parse the agreement entry" that you have elided.
>
> no, it's the same. I only forgot to switch on debugging first.
>
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin - Found replication
> agreement named
> "cn=testreplica,cn=replica,cn=dc\3Ddatenkollektiv\2Cdc\3Dnet,cn=mapping
> tree,cn=config". [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin -
> : Update window will close at Fri Feb 14 00:00:00 2014
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin - The replication
> agreement named
> "cn=testreplica,cn=replica,cn=dc\3Ddatenkollektiv\2Cdc\3Dnet,cn=mapping
> tree,cn=config" could not be correctly parsed. No replication will
> occur with this replica.
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin -
> agmtlist_config_init: found 0 replication agreements in DIT
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin - changelog program
> - _cl5GetDBFile: found DB object 7f2ff3936db0 for database
>
/var/lib/dirsrv/slapd-ldmaster1/changelogdb/8f320883-948c11e3-9af8fb92-daba3ca0_52fc88aa000000070000.db4
> [13/Feb/2014:20:02:08 +0100] - _csngen_adjust_local_time: gen state
> before 52fc88aa0001:1392281770:0:0
> [13/Feb/2014:20:02:08 +0100] - _csngen_adjust_local_time: gen state
> after 52fd16b00000:1392318128:0:0
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin -
> ruv_add_csn_inprogress: successfully inserted csn 52fd16b0000000070000
> into pending list
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin - Purged state
> information from entry dc=datenkollektiv,dc=net up to CSN
> 52f34e81000000070000
> [13/Feb/2014:20:02:08 +0100] NSMMReplicationPlugin -
> csn=52fd16b0000000070000 process postop: canceling operation csn
> [13/Feb/2014:20:02:08 +0100] - slapd started. Listening on All
> Interfaces port 389 for LDAP requests
>
> Also I tried the 1.2.11-15 389-ds version which ships with centos 6.5.
> The error still occurs.
>
> 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.
>
> 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
>
> Unfortunately my knowledge is to little to set up an second db with an
> separate domain to try if the error occurs in the case of as subtree
> replication.
>
> I tried it with:
>
> dn: dc=example_org,cn=ldbm database,cn=plugins,cn=config
> changetype: add
> objectclass: top
> objectclass: extensibleObject
> objectClass: nsbackendinstance
> cn: example_org
> nsslapd-suffix: dc=example,dc=org
>
> But while again adding a replication agreement for the root
examle.org
> I get: "failed to locate mapping tree node for dc=example,dc=org".
>
> Propably I do something wrong.
Yes. Please review
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Serv...
thanks, I tried to understand it on a first glance - but not ;-)
Jan