No, it does not. -----Original Message----- From: Rich Megginson [mailto:rmeggins@xxxxxxxxxx] Sent: Friday, January 07, 2011 3:47 PM To: Reinhard Nappert Cc: 389-users@xxxxxxxxxxxxxxxxxxxxxxx Subject: Re: Replication with 1.2.7.5 On 01/07/2011 01:39 PM, Reinhard Nappert wrote: > 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) Does it do the refresh if you use ldapmodify to change the value of the attribute after creating the entry? > -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
