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?
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
Also tried to replicate the primary domain inside an kolab 389-ds
environment: this works mainly - but breaks some other stuff. Eg. I
can't login anymore in the kolab-webadmin of the consumer. But I think
it's not the idea to replicate the primary db there.
Any help apreciated.
Thanks
Jan.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
