Yes, I did report a bug regarding the deletion of the replica configuration, but my testing are not related to this. I want to re-create the situation where the slapd process "freezes" with a 1.2.x release. Remember, you analyzed some coredumps of 1.1.2. I want to produce some cores with 1.2.x for that. I still need to get to the bottom of this one......
-Reinhard -----Original Message----- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: Monday, January 10, 2011 1:26 PM To: Reinhard Nappert Cc: 389-us...@lists.fedoraproject.org Subject: Re: Replication with 1.2.7.5 On 01/10/2011 11:16 AM, Reinhard Nappert wrote: > After I did set it to start and did do a ldapsearch and > nsds5beginreplicarefresh was still set to start. None of the other > replication attributes was set. It looks to me that the server did not do any > replication related operations. Is this related to deleting then recreating replica configuration and/or a replication agreement? I believe you reported a bug related to that. > For now, I suggest to not "waste" any time on it, since I've got it working > with 1.2.6. Again, is there a compelling reason to switch to 1.2.7.5? There were a few bugs that we fixed in 1.2.7.x that didn't make it into 1.2.6.x. But if 1.2.6 is working for you, then there is probably no compelling reason to switch. > Once, I am done with my 1.2.x testing tasks, I will re-compile and build the > 1.2.7.5 code and you know. > > -Reinhard > > -----Original Message----- > From: Rich Megginson [mailto:rmegg...@redhat.com] > Sent: Monday, January 10, 2011 1:10 PM > To: Reinhard Nappert > Cc: 389-us...@lists.fedoraproject.org > Subject: Re: Replication with 1.2.7.5 > > On 01/10/2011 08:18 AM, Reinhard Nappert wrote: >> Rich, >> >> I had log level set to 8192 and still there was nothing in errors. > I've tried to reproduce the problem with the latest epel released > 1.2.7.5 on RHEL 5, and with 1.2.7.5 built from source on RHEL 6 - in both > cases, I created the replication agreement, and did an ldapmodify to set > nsds5beginreplicarefresh: start - in both cases, the repl. init works. > > After doing the ldapmodify to set nsds5beginreplicarefresh: start, if you do > an ldapsearch of that entry, do you see that attribute? What about the other > replication status attributes? >> I did compile, build and install 1.2.6. With that, it seems to work. >> >> I need to do some tests with 1.2.6, before I can re-build 1.2.7.5 and try to >> re-produce. >> Are there some compelling reasons to use 1.2.7.5, instead of going with >> 1.2.6? >> >> -Reinhard >> >> -----Original Message----- >> From: Rich Megginson [mailto:rmegg...@redhat.com] >> Sent: Friday, January 07, 2011 4:00 PM >> To: Reinhard Nappert >> Cc: 389-us...@lists.fedoraproject.org >> Subject: Re: Replication with 1.2.7.5 >> >> On 01/07/2011 01:52 PM, Reinhard Nappert wrote: >>> No, it does not. >> And no errors from ldapmodify? What does it say in the directory server >> access log for the operation and result? With log level 8192, is there >> anything in the errors log? >>> -----Original Message----- >>> From: Rich Megginson [mailto:rmegg...@redhat.com] >>> Sent: Friday, January 07, 2011 3:47 PM >>> To: Reinhard Nappert >>> Cc: 389-us...@lists.fedoraproject.org >>> 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:rmegg...@redhat.com] >>>> Sent: Friday, January 07, 2011 3:15 PM >>>> To: 389-us...@lists.fedoraproject.org; 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-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
