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. 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?
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:rmeggins@redhat.com]
Sent: Monday, January 10, 2011 1:10 PM
To: Reinhard Nappert
Cc: 389-users(a)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:rmeggins@redhat.com]
Sent: Friday, January 07, 2011 4:00 PM
To: Reinhard Nappert
Cc: 389-users(a)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:rmeggins@redhat.com]
> Sent: Friday, January 07, 2011 3:47 PM
> To: Reinhard Nappert
> Cc: 389-users(a)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:rmeggins@redhat.com]
>> Sent: Friday, January 07, 2011 3:15 PM
>> To: 389-users(a)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