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_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html
thanks, I tried to understand it on a first glance - but not ;-)
Jan
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
