Hi Rich,
The following is taken out of config.log:
$ ../configure --prefix=/opt/UMC/jdb --disable-debug --with-ldapsdk=~/UMCjfds.src/dist
--with-svrcore=~/UMCjfds.src/dist --with-icu=~/UMCjfds.src/dist
--with-netsnmp=~/UMCjfds.src/dist --with-nspr=~/UMCjfds.src/dist
--with-nss-inc=~/UMCjfds.src/dist/public/nss --with-nss-lib=~/UMCjfds.src/dist/lib
--with-db=~/UMCjfds.src/dist/ --with-pcre=~/UMCjfds.src/dist
## --------- ##
## Platform. ##
## --------- ##
uname -m = x86_64
uname -r = 2.6.9-42.0.10.ELsmp
uname -s = Linux
-Reinhard
-----Original Message-----
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, January 31, 2011 10:56 AM
To: Reinhard Nappert
Cc: 389-users(a)lists.fedoraproject.org
Subject: Re: Replication with 1.2.7.5
On 01/31/2011 08:45 AM, Reinhard Nappert wrote:
Hi Rich,
I think I figured out what was going on. It looks like the
share/dirsrv/data/template-dse.ldif file was incomplete after the build process. I did not
go through the entire plugin list, but the cn=Multimaster Replication
Plugin,cn=plugins,cn=config object was missing in the template file. I have no clue, how
this can happen, but I also saw it at least once with the 1.2.6.1 code. Strange thing is
that I called exactly the same configuartion parameters (I sue a shell script for that).
Can I see the environment variables and parameters you use with configure and make?
-Reinhard
-----Original Message-----
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, January 10, 2011 1:26 PM
To: Reinhard Nappert
Cc: 389-users(a)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: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