FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 01-07-2011, 07:39 PM
Reinhard Nappert
 
Default Replication with 1.2.7.5

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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@redhat.com]
Sent: Friday, January 07, 2011 3:15 PM
To: 389-users@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-07-2011, 07:46 PM
Rich Megginson
 
Default 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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-07-2011, 07:52 PM
Reinhard Nappert
 
Default Replication with 1.2.7.5

No, it does not.

-----Original Message-----
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Friday, January 07, 2011 3:47 PM
To: Reinhard Nappert
Cc: 389-users@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-07-2011, 07:59 PM
Rich Megginson
 
Default 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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-10-2011, 02:18 PM
Reinhard Nappert
 
Default Replication with 1.2.7.5

Rich,

I had log level set to 8192 and still there was nothing in errors.

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@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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-10-2011, 05:09 PM
Rich Megginson
 
Default 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@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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-10-2011, 05:16 PM
Reinhard Nappert
 
Default Replication with 1.2.7.5

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@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@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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-10-2011, 05:25 PM
Rich Megginson
 
Default 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@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@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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-10-2011, 05:32 PM
Reinhard Nappert
 
Default Replication with 1.2.7.5

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:rmeggins@redhat.com]
Sent: Monday, January 10, 2011 1:26 PM
To: Reinhard Nappert
Cc: 389-users@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@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@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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 01-13-2011, 01:53 PM
Reinhard Nappert
 
Default Replication with 1.2.7.5

Rich,

I did configure and compile the 1.2.7.5 source from http://port389.org/sources/389-ds-base-1.2.7.5.tar.bz2 with the same options and libraries as the source of 1.2.6.1 (http://port389.org/sources/389-ds-base-1.2.6.1.tar.bz2).

While the replication works as designed with 1.2.6.1, by using my administration application, the 1.2.7.5 DS does not react to the application at all.
Once I have a bit more time, I will provide you more info.

-Reinhard

-----Original Message-----
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Reinhard Nappert
Sent: Monday, January 10, 2011 1:32 PM
To: Rich Megginson
Cc: 389-users@lists.fedoraproject.org
Subject: Re: [389-users] Replication with 1.2.7.5

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:rmeggins@redhat.com]
Sent: Monday, January 10, 2011 1:26 PM
To: Reinhard Nappert
Cc: 389-users@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@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@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@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=o3DUMC,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=o3DUMC,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=o3DUMC,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=o3Dumc,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=o3DUMC,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=o3DUMC,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@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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 07:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org