Rich, I am not sure if I tested it with any 1.2.x release. I think, I did it, but this would have been some time back. It is really weird that I do not see anything in errors at all. Anyway, here are the ops from the access file: [07/Jan/2011:15:17:13 -0500] conn=74 op=1 ADD dn="cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config" [07/Jan/2011:15:17:13 -0500] conn=74 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [07/Jan/2011:15:17:13 -0500] conn=74 op=2 ADD dn="cn=changelog5,cn=config" [07/Jan/2011:15:17:13 -0500] conn=74 op=2 RESULT err=0 tag=105 nentries=0 etime=0 [07/Jan/2011:15:17:13 -0500] conn=74 op=3 MOD dn="cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config" [07/Jan/2011:15:17:13 -0500] conn=74 op=3 RESULT err=0 tag=103 nentries=0 etime=0 [07/Jan/2011:15:17:13 -0500] conn=74 op=4 ADD dn="cn=c4000-12c4000-2,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config" [07/Jan/2011:15:17:13 -0500] conn=74 op=4 RESULT err=0 tag=105 nentries=0 etime=0 You see that the operations succeeded. Here is the result of the operations: dn: cn=o\3Dumc,cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: o=umc cn: "o=umc" nsslapd-state: backend nsslapd-backend: userRoot dn: cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config nsDS5ReplicaBindDN: cn=replAdmin,cn=config nsDS5ReplicaRoot: o=UMC nsDS5ReplicaId: 4 nsDS5Flags: 1 nsDS5ReplicaType: 3 nsds5ReplicaPurgeDelay: 43200 objectClass: top objectClass: nsDS5Replica cn: replica nsDS5ReplicaReferral: ldap://c4000-2:389/o=UMC dn: cn=c4000-12c4000-2,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config nsDS5ReplicaBindDN: cn=replAdmin,cn=config nsDS5ReplicaTransportInfo: LDAP nsDS5ReplicaHost: c4000-2 nsDS5ReplicaPort: 389 objectClass: top objectClass: nsDS5ReplicationAgreement nsDS5ReplicaBindMethod: SIMPLE cn: c4000-12c4000-2 description: c4000-12c4000-2 nsDS5ReplicaRoot: o=UMC nsDS5ReplicaCredentials: {DES}IDgUQ80Eh2GlcB8A2TilGg== nsds5BeginReplicaRefresh: start You see that the server does not react to the trigger start (nsds5BeginReplicaRefresh) -Reinhard -----Original Message----- From: Rich Megginson [mailto:rmeggins@xxxxxxxxxx] Sent: Friday, January 07, 2011 3:15 PM To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx; Reinhard Nappert Subject: Re: Replication with 1.2.7.5 > Hi all, > I compiled, built and installed the 389 DS 1.2.7.5 release. > I tried to configure a mm scenario (by using my customized administration application, which works with any 1.1.x release). Have you successfully used it with any 1.2.x release? > When I initialize the agreement, nothing happens and I do not see any logs in errors, although I changed the error log level to 8192. > My application creates the cn=changelog5, cn=config entry as well as the cn=replica entry and the agreement cn=<agreement>,cn=replica entry underneath the cn=<suffix>,cn=mapping tree, cn=config entry. > Did the administration of replication (and agreements) change? No - can you post excerpts from your access logs showing the operations that add these entries, along with the results of those operations? There is nothing in the error log showing any problems? Thanks, -Reinhard -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
