[Fedora-directory-users] Questions about setting up replication by modifying ldap directly.

[Ryan Braun]

I'm working on a perl script that will allow you to setup replication agreements from
the commandline using Net::LDAP.  I've pretty much taken most of the ideas out of the
existing mmr.pl and added some more functionality ( and made the code look alot worse lol
:)

I have a couple questions about a few attributes involved in the various object classes
used in replication,  and a couple logic questions to boot.

First off,  I've been using the sun docs from 6.1 here

http://docs.sun.com/app/docs/doc/820-0384

for some of the attribute and object class info.  I hope it still applies :P

1.  When using the console,  and you right click the replication agreement,  you have the
option to "Send Updates Now".  Which attribute does that set?  I'm assuming
its not nsds5BeginReplicaRefresh,  but that looks like the closest item from either
nsDS5Replica or nsDS5ReplicationAgreement object classes.


Now for some logic questions.  When creating a Supplier -> dedicated consumer
replication.  Here's a rough outline of what I'm doing

1.  Supplier -> create replication user
2. Consumer -> create replication user
3. Supplier -> add changelog object ("cn=changelog5,cn=config")
4. Consumer -> add changelog object ("cn=changelog5,cn=config")
5. Supplier -> add replica object
("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config")
6. Consumer -> add replica object
("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config")
(consumer and supplier rep objects do have their own specific settings in these objects)
7. Supplier -> create rep agreement object ("cn=\"Replication to
$to\",cn=replica,cn=\"$base\",cn=mapping tree,cn=config")
8.  Consumer -> update referral information in 
dn: cn=$config{BASE_DN},cn=mapping tree,cn=config (nsslapd-referral attribute)
and
dn: cn=replica,cn="$config{BASE_DN}",cn=mapping tree,cn=config
(nsDS5ReplicaReferral attribute)
9. Consumer -> modify dn: cn=$config{BASE_DN},cn=mapping tree,cn=config attribute
nsslapd-state to "referral on update"

I *think* thats it.  From what I can when dumping cn=config the 3 objects on the consumer
end up something like this.  Also there's an empty value for 
nsslapd-referralmode:  is that normal?


# dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
dn: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: "dc=xxx,dc=ec,dc=gc,dc=ca"
nsslapd-state: referral on update
nsslapd-backend: userRoot
nsslapd-referral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
nsslapd-referral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca

# replica, dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
dn: cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaRoot: dc=xxx,dc=ec,dc=gc,dc=ca
nsDS5ReplicaType: 2
nsDS5Flags: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: uid=RManager,cn=config
cn: replica
nsDS5ReplicaId: 65535
nsState:: //8AABRQWEcAAAAAAgAAAAEAAAA=
nsDS5ReplicaName: 60c64002-1dd211b2-8039bd5e-680e0000
nsDS5ReplicaReferral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
nsDS5ReplicaReferral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
nsds5ReplicaChangeCount: 2
nsds5replicareapactive: 0

# changelog5, config
dn: cn=changelog5,cn=config
objectClass: top
objectClass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /opt/fedora-ds/slapd-srvr3/changelogdb

Now for setting up an MMR agreement between 2 suppliers

1. Source -> create rep user
2. Target -> create rep user
3. Source -> create changelog object
4. Target -> create changelog object
5. Source -> create replica object
6. Target -> create replica object
7. Source -> create rep agreement
8. Target -> create rep agreement
9. Source -> set nsDS5BeginReplicaRefresh in the rep agreement on the source to init
the target.
10. Source -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config
attribute nsslapd-referral with the ldap://target:PORT/$config{BASE_DN}
11. Target -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config
attribute nsslapd-referral with the ldap://source:PORT/$config{BASE_DN}

How does that look?  

Should the multi-valued attribute nsslapd-referral contain entries for each server for
which it has a MMR agreement with?

One other question,  it seems that sometimes the value has the escape codes for the comma
while sometimes it has the actual comma. 

ryan@infinity:~/fds-tools$ grep -i Referral *
xxxoff-config:nsslapd-referral:
ldap://xxxoff0.xxx.ec.gc.ca:389/dc%3Dxxx%2Cdc%3Dec%2Cdc%3Dgc
xxxsrvr4-config:nsslapd-referral: ldap://srvr1:389/dc=xxx,dc=ec,dc=gc,dc=ca

I assume either way will work and not break anything?  (which seems to be the case as
it's running :)


Ryan Braun
Informatics Operations
Aviation and Defence Services Division 
Chief Information Officer Branch, Environment Canada 
CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
E-Mail: Ryan.Braun(a)ec.gc.ca

[Rich Megginson]

Ryan Braun wrote:
>  I'm working on a perl script that will allow you to setup
> replication agreements from the commandline using Net::LDAP.  I've pretty much taken
> most of the ideas out of the existing mmr.pl and added some more functionality ( and made
> the code look alot worse lol :)
>     
It's perl - how could it possibly look any worse than it already is :P

Can you make your perl script available to the community?
>  I have a couple questions about a few attributes involved in the
> various object classes used in replication,  and a couple logic questions to boot.
>
>  First off,  I've been using the sun docs from 6.1 here
>
>  http://docs.sun.com/app/docs/doc/820-0384
>
>  for some of the attribute and object class info.  I hope it still applies :P
>     
Looks like it mostly still applies.  Use this as your primary reference 
- http://www.redhat.com/docs/manuals/dir-server/pdf/ds71cli.pdf and see 
also http://www.redhat.com/docs/manuals/dir-server/schema/7.1/schemaTOC.html
>  1.  When using the console,  and you right click the replication
> agreement,  you have the option to "Send Updates Now".  Which attribute does
> that set?  I'm assuming its not nsds5BeginReplicaRefresh,  but that looks like the
> closest item from either nsDS5Replica or nsDS5ReplicationAgreement object classes.
>     
It probably uses the "trick" of setting the replication schedule to
some 
bogus value (e.g. "0 0000-0001") then setting it back to its original 
setting.  This will in effect tell replication to send all updates 
immediately.  nsds5BeginReplicaRefresh is only used for full replica 
initialization.
>  Now for some logic questions.  When creating a Supplier -> dedicated consumer
> replication.  Here's a rough outline of what I'm doing
>
>  1.  Supplier -> create replication user
>     
Unless the Supplier will also be a Consumer, this step is not necessary.
>  2. Consumer -> create replication user
>  3. Supplier -> add changelog object ("cn=changelog5,cn=config")
>  4. Consumer -> add changelog object ("cn=changelog5,cn=config")
>     
Unless the Consumer will also be a Supplier, this step is not necessary.
>  5. Supplier -> add replica object
> ("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config")
>  6. Consumer -> add replica object
> ("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config")
> (consumer and supplier rep objects do have their own specific settings in these objects)
>  7. Supplier -> create rep agreement object ("cn=\"Replication to
> $to\",cn=replica,cn=\"$base\",cn=mapping tree,cn=config")
>  8.  Consumer -> update referral information in 
>  dn: cn=$config{BASE_DN},cn=mapping tree,cn=config (nsslapd-referral attribute)
>  and
>  dn: cn=replica,cn="$config{BASE_DN}",cn=mapping tree,cn=config
> (nsDS5ReplicaReferral attribute)
>     
This should not be necessary unless you want to provide custom 
referrals.  The server will automatically set the referrals back to the 
Supplier or Master.
>  9. Consumer -> modify dn: cn=$config{BASE_DN},cn=mapping
> tree,cn=config attribute nsslapd-state to "referral on update"
>     
I think this is also unnecessary, but should be ok anyway.
>  I *think* thats it.  From what I can when dumping cn=config the 3
> objects on the consumer end up something like this.  Also there's an empty value for 
>  nsslapd-referralmode:  is that normal?
>     
I think so.
>  # dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
>  dn: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
>  objectClass: top
>  objectClass: extensibleObject
>  objectClass: nsMappingTree
>  cn: "dc=xxx,dc=ec,dc=gc,dc=ca"
>  nsslapd-state: referral on update
>  nsslapd-backend: userRoot
>  nsslapd-referral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  nsslapd-referral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
>
>  # replica, dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
>  dn: cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
>  objectClass: nsDS5Replica
>  objectClass: top
>  nsDS5ReplicaRoot: dc=xxx,dc=ec,dc=gc,dc=ca
>  nsDS5ReplicaType: 2
>  nsDS5Flags: 0
>  nsds5ReplicaPurgeDelay: 604800
>  nsDS5ReplicaBindDN: uid=RManager,cn=config
>  cn: replica
>  nsDS5ReplicaId: 65535
>  nsState:: //8AABRQWEcAAAAAAgAAAAEAAAA=
>  nsDS5ReplicaName: 60c64002-1dd211b2-8039bd5e-680e0000
>  nsDS5ReplicaReferral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  nsDS5ReplicaReferral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  nsds5ReplicaChangeCount: 2
>  nsds5replicareapactive: 0
>
>  # changelog5, config
>  dn: cn=changelog5,cn=config
>  objectClass: top
>  objectClass: extensibleObject
>  cn: changelog5
>  nsslapd-changelogdir: /opt/fedora-ds/slapd-srvr3/changelogdb
>
>  Now for setting up an MMR agreement between 2 suppliers
>
>  1. Source -> create rep user
>  2. Target -> create rep user
>  3. Source -> create changelog object
>  4. Target -> create changelog object
>  5. Source -> create replica object
>  6. Target -> create replica object
>  7. Source -> create rep agreement
>  8. Target -> create rep agreement
>  9. Source -> set nsDS5BeginReplicaRefresh in the rep agreement on the source to init
> the target.
>  10. Source -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config
> attribute nsslapd-referral with the ldap://target:PORT/$config{BASE_DN}
>  11. Target -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config
> attribute nsslapd-referral with the ldap://source:PORT/$config{BASE_DN}
>     
10, 11 - the referrals should be set automatically.
>  How does that look?  
>     
Looks good.
>  Should the multi-valued attribute nsslapd-referral contain entries
> for each server for which it has a MMR agreement with?
>     
Yes, but that should be handled automatically, unless you want to 
override it.
>  One other question,  it seems that sometimes the value has the escape
> codes for the comma while sometimes it has the actual comma. 
>
>  ryan@infinity:~/fds-tools$ grep -i Referral *
>  xxxoff-config:nsslapd-referral:
> ldap://xxxoff0.xxx.ec.gc.ca:389/dc%3Dxxx%2Cdc%3Dec%2Cdc%3Dgc
>  xxxsrvr4-config:nsslapd-referral: ldap://srvr1:389/dc=xxx,dc=ec,dc=gc,dc=ca
>
>  I assume either way will work and not break anything?  (which seems to be the case as
> it's running :)
>     
Yes.
>  Ryan Braun
>  Informatics Operations
>  Aviation and Defence Services Division 
>  Chief Information Officer Branch, Environment Canada 
>  CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
>  E-Mail: Ryan.Braun(a)ec.gc.ca 
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

[Ryan Braun]

On Tuesday 11 December 2007 8:31 pm, Rich Megginson wrote:
>  Ryan Braun wrote:
>  > I'm working on a perl script that will allow you to setup replication
>  > agreements from the commandline using Net::LDAP.  I've pretty much taken
>  > most of the ideas out of the existing mmr.pl and added some more
>  > functionality ( and made the code look alot worse lol :)
>
>  It's perl - how could it possibly look any worse than it already is :P
>
>  Can you make your perl script available to the community? 
I'll provide it on one condition,  no on makes fun of me :)  I'll probably 
have something rough tomorrow or thursday,

>  > I have a couple questions about a few attributes involved in the various
>  > object classes used in replication,  and a couple logic questions to
>  > boot.
>  >
>  > First off,  I've been using the sun docs from 6.1 here
>  >
>  > http://docs.sun.com/app/docs/doc/820-0384
>  >
>  > for some of the attribute and object class info.  I hope it still applies
>  > :P
>
>  Looks like it mostly still applies.  Use this as your primary reference
>  - http://www.redhat.com/docs/manuals/dir-server/pdf/ds71cli.pdf and see
>  also
>  http://www.redhat.com/docs/manuals/dir-server/schema/7.1/schemaTOC.html 
Will do.

>  > 1.  When using the console,  and you right click the replication
>  > agreement,  you have the option to "Send Updates Now".  Which attribute
>  > does that set?  I'm assuming its not nsds5BeginReplicaRefresh,  but that
>  > looks like the closest item from either nsDS5Replica or
>  > nsDS5ReplicationAgreement object classes.
>
>  It probably uses the "trick" of setting the replication schedule to some
>  bogus value (e.g. "0 0000-0001") then setting it back to its original
>  setting.  This will in effect tell replication to send all updates
>  immediately.  nsds5BeginReplicaRefresh is only used for full replica
>  initialization. 
The reason I ask,  is when I was playing around and turned off one of the 
consumer servers,  it came back and was taking a while so sync up the updates 
from the supplier.  I wasn't sure what kind of time frame to expect in this 
situation.  That and it seems like a handy option.

>  > Now for some logic questions.  When creating a Supplier -> dedicated
>  > consumer replication.  Here's a rough outline of what I'm doing
>  >
>  > 1.  Supplier -> create replication user
>
>  Unless the Supplier will also be a Consumer, this step is not necessary. 
Ahh ok,  I'll assume that all suppliers will be setup as MMR for now.  Maybe 
add SMR functionality later if needed.
>  > 2. Consumer -> create replication user
>  > 3. Supplier -> add changelog object ("cn=changelog5,cn=config")
>  > 4. Consumer -> add changelog object ("cn=changelog5,cn=config")
>
>  Unless the Consumer will also be a Supplier, this step is not necessary. 
ok so read only consumers don't need the changelog object.
>  > 5. Supplier -> add replica object
>  > ("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config")
> 6.
>  > Consumer -> add replica object
>  > ("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping
> tree,cn=config")
>  > (consumer and supplier rep objects do have their own specific settings in
>  > these objects) 7. Supplier -> create rep agreement object
>  > ("cn=\"Replication to
> $to\",cn=replica,cn=\"$base\",cn=mapping
>  > tree,cn=config") 8.  Consumer -> update referral information in
>  > dn: cn=$config{BASE_DN},cn=mapping tree,cn=config (nsslapd-referral
>  > attribute) and
>  > dn: cn=replica,cn="$config{BASE_DN}",cn=mapping tree,cn=config
>  > (nsDS5ReplicaReferral attribute)
>
>  This should not be necessary unless you want to provide custom
>  referrals.  The server will automatically set the referrals back to the
>  Supplier or Master. 
I wasn't sure if these entries were populated dynamically or if they needed to 
be manually set.  Here's a question I forgot to ask before.  Say you have 2 
or 3 or X amount of suppliers feeding a read only consumer.  Will the 
consumer automatically figure out it can send referrals back all the servers.  
ie.  the first server on the referral list is down so send to the second. Is 
there some replication protocol magic going on that lets the consumers know 
what the referrals should be and then auto populates the nsDS5ReplicaReferral 
and nsslapd-referral attributes?

>  > 9. Consumer -> modify dn: cn=$config{BASE_DN},cn=mapping tree,cn=config
>  > attribute nsslapd-state to "referral on update"
>
>  I think this is also unnecessary, but should be ok anyway.
>
>  > I *think* thats it.  From what I can when dumping cn=config the 3 objects
>  > on the consumer end up something like this.  Also there's an empty value
>  > for nsslapd-referralmode:  is that normal?
>
>  I think so.
>
>  > # dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
>  > dn: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
>  > objectClass: top
>  > objectClass: extensibleObject
>  > objectClass: nsMappingTree
>  > cn: "dc=xxx,dc=ec,dc=gc,dc=ca"
>  > nsslapd-state: referral on update
>  > nsslapd-backend: userRoot
>  > nsslapd-referral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  > nsslapd-referral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  >
>  > # replica, dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
>  > dn: cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
>  > objectClass: nsDS5Replica
>  > objectClass: top
>  > nsDS5ReplicaRoot: dc=xxx,dc=ec,dc=gc,dc=ca
>  > nsDS5ReplicaType: 2
>  > nsDS5Flags: 0
>  > nsds5ReplicaPurgeDelay: 604800
>  > nsDS5ReplicaBindDN: uid=RManager,cn=config
>  > cn: replica
>  > nsDS5ReplicaId: 65535
>  > nsState:: //8AABRQWEcAAAAAAgAAAAEAAAA=
>  > nsDS5ReplicaName: 60c64002-1dd211b2-8039bd5e-680e0000
>  > nsDS5ReplicaReferral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  > nsDS5ReplicaReferral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  > nsds5ReplicaChangeCount: 2
>  > nsds5replicareapactive: 0
>  >
>  > # changelog5, config
>  > dn: cn=changelog5,cn=config
>  > objectClass: top
>  > objectClass: extensibleObject
>  > cn: changelog5
>  > nsslapd-changelogdir: /opt/fedora-ds/slapd-srvr3/changelogdb
>  >
>  > Now for setting up an MMR agreement between 2 suppliers
>  >
>  > 1. Source -> create rep user
>  > 2. Target -> create rep user
>  > 3. Source -> create changelog object
>  > 4. Target -> create changelog object
>  > 5. Source -> create replica object
>  > 6. Target -> create replica object
>  > 7. Source -> create rep agreement
>  > 8. Target -> create rep agreement
>  > 9. Source -> set nsDS5BeginReplicaRefresh in the rep agreement on the
>  > source to init the target. 10. Source -> update dn:
>  > cn="$config{BASE_DN}",cn=mapping tree,cn=config attribute
>  > nsslapd-referral with the ldap://target:PORT/$config{BASE_DN} 11. Target
>  > -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config
> attribute
>  > nsslapd-referral with the ldap://source:PORT/$config{BASE_DN}
>
>  10, 11 - the referrals should be set automatically. 
>  > How does that look?
>
>  Looks good.
>
>  > Should the multi-valued attribute nsslapd-referral contain entries for
>  > each server for which it has a MMR agreement with?
>
>  Yes, but that should be handled automatically, unless you want to
>  override it.
>  
Same replication protocol magic question as above.

Ryan Braun
Informatics Operations
Aviation and Defence Services Division
Chief Information Officer Branch, Environment Canada
CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
E-Mail: Ryan.Braun(a)ec.gc.ca

>  > One other question,  it seems that sometimes the value has the
> escape
>  > codes for the comma while sometimes it has the actual comma.
>  >
>  > ryan@infinity:~/fds-tools$ grep -i Referral *
>  > xxxoff-config:nsslapd-referral:
>  > ldap://xxxoff0.xxx.ec.gc.ca:389/dc%3Dxxx%2Cdc%3Dec%2Cdc%3Dgc
>  > xxxsrvr4-config:nsslapd-referral:
>  > ldap://srvr1:389/dc=xxx,dc=ec,dc=gc,dc=ca
>  >
>  > I assume either way will work and not break anything?  (which seems to be
>  > the case as it's running :)
>
>  Yes.
>
>  > Ryan Braun
>  > Informatics Operations
>  > Aviation and Defence Services Division
>  > Chief Information Officer Branch, Environment Canada
>  > CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
>  > E-Mail: Ryan.Braun(a)ec.gc.ca
>  >
>  > --
>  > Fedora-directory-users mailing list
>  > Fedora-directory-users(a)redhat.com
>  > https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Rich Megginson]

Ryan Braun wrote:
>  On Tuesday 11 December 2007 8:31 pm, Rich Megginson wrote:
>    
> > Ryan Braun wrote:
> >     
> >> I'm working on a perl script that will allow you to setup replication
> >> agreements from the commandline using Net::LDAP.  I've pretty much taken
> >> most of the ideas out of the existing mmr.pl and added some more
> >> functionality ( and made the code look alot worse lol :)
> >>       
> > It's perl - how could it possibly look any worse than it already is :P
> >
> > Can you make your perl script available to the community?
> >     
>
>  I'll provide it on one condition,  no on makes fun of me :)  I'll probably 
>  have something rough tomorrow or thursday,
>
>    
> >> I have a couple questions about a few attributes involved in the various
> >> object classes used in replication,  and a couple logic questions to
> >> boot.
> >>
> >> First off,  I've been using the sun docs from 6.1 here
> >>
> >> http://docs.sun.com/app/docs/doc/820-0384
> >>
> >> for some of the attribute and object class info.  I hope it still applies
> >> :P
> >>       
> > Looks like it mostly still applies.  Use this as your primary reference
> > - http://www.redhat.com/docs/manuals/dir-server/pdf/ds71cli.pdf and see
> > also
> > http://www.redhat.com/docs/manuals/dir-server/schema/7.1/schemaTOC.html
> >     
>
>  Will do.
>
>    
> >> 1.  When using the console,  and you right click the replication
> >> agreement,  you have the option to "Send Updates Now".  Which
> attribute
> >> does that set?  I'm assuming its not nsds5BeginReplicaRefresh,  but that
> >> looks like the closest item from either nsDS5Replica or
> >> nsDS5ReplicationAgreement object classes.
> >>       
> > It probably uses the "trick" of setting the replication schedule to some
> > bogus value (e.g. "0 0000-0001") then setting it back to its original
> > setting.  This will in effect tell replication to send all updates
> > immediately.  nsds5BeginReplicaRefresh is only used for full replica
> > initialization.
> >     
>
>  The reason I ask,  is when I was playing around and turned off one of the 
>  consumer servers,  it came back and was taking a while so sync up the updates 
>  from the supplier.  I wasn't sure what kind of time frame to expect in this 
>  situation.  That and it seems like a handy option.
>     
The supplier will by default attempt to send updates immediately.  If 
the consumer goes down, the supplier will keep trying to reach it, using 
an exponential backoff strategy, until it attempts to contact the 
consumer every 5 minutes.  So at most you should only have to wait 5 
minutes after the consumer comes back online.
>    
> >> Now for some logic questions.  When creating a Supplier -> dedicated
> >> consumer replication.  Here's a rough outline of what I'm doing
> >>
> >> 1.  Supplier -> create replication user
> >>       
> > Unless the Supplier will also be a Consumer, this step is not necessary.
> >     
>
>  Ahh ok,  I'll assume that all suppliers will be setup as MMR for now.  Maybe 
>  add SMR functionality later if needed.
>    
> >> 2. Consumer -> create replication user
> >> 3. Supplier -> add changelog object ("cn=changelog5,cn=config")
> >> 4. Consumer -> add changelog object ("cn=changelog5,cn=config")
> >>       
> > Unless the Consumer will also be a Supplier, this step is not necessary.
> >     
>
>  ok so read only consumers don't need the changelog object.
>    
> >> 5. Supplier -> add replica object
> >> ("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping
> tree,cn=config") 6.
> >> Consumer -> add replica object
> >> ("cn=replica,cn=\"$config{BASE_DN}\",cn=mapping
> tree,cn=config")
> >> (consumer and supplier rep objects do have their own specific settings in
> >> these objects) 7. Supplier -> create rep agreement object
> >> ("cn=\"Replication to
> $to\",cn=replica,cn=\"$base\",cn=mapping
> >> tree,cn=config") 8.  Consumer -> update referral information in
> >> dn: cn=$config{BASE_DN},cn=mapping tree,cn=config (nsslapd-referral
> >> attribute) and
> >> dn: cn=replica,cn="$config{BASE_DN}",cn=mapping tree,cn=config
> >> (nsDS5ReplicaReferral attribute)
> >>       
> > This should not be necessary unless you want to provide custom
> > referrals.  The server will automatically set the referrals back to the
> > Supplier or Master.
> >     
>
>  I wasn't sure if these entries were populated dynamically or if they needed to 
>  be manually set.  Here's a question I forgot to ask before.  Say you have 2 
>  or 3 or X amount of suppliers feeding a read only consumer.  Will the 
>  consumer automatically figure out it can send referrals back all the servers.  
>  ie.  the first server on the referral list is down so send to the second. Is 
>  there some replication protocol magic going on that lets the consumers know 
>  what the referrals should be and then auto populates the nsDS5ReplicaReferral 
>  and nsslapd-referral attributes?
>     
The referrals are automatically set to go to all of the masters, but 
there is no guaranteed order.  So there is no guarantee of which master 
the client will be referred to, only that it will be referred to one of 
the masters.
>    
> >> 9. Consumer -> modify dn: cn=$config{BASE_DN},cn=mapping tree,cn=config
> >> attribute nsslapd-state to "referral on update"
> >>       
> > I think this is also unnecessary, but should be ok anyway.
> >
> >     
> >> I *think* thats it.  From what I can when dumping cn=config the 3 objects
> >> on the consumer end up something like this.  Also there's an empty value
> >> for nsslapd-referralmode:  is that normal?
> >>       
> > I think so.
> >
> >     
> >> # dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
> >> dn: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
> >> objectClass: top
> >> objectClass: extensibleObject
> >> objectClass: nsMappingTree
> >> cn: "dc=xxx,dc=ec,dc=gc,dc=ca"
> >> nsslapd-state: referral on update
> >> nsslapd-backend: userRoot
> >> nsslapd-referral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
> >> nsslapd-referral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
> >>
> >> # replica, dc\3Dxxx\2Cdc\3Dec\2Cdc\3Dgc\2Cdc\3Dca, mapping tree, config
> >> dn: cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
> >> objectClass: nsDS5Replica
> >> objectClass: top
> >> nsDS5ReplicaRoot: dc=xxx,dc=ec,dc=gc,dc=ca
> >> nsDS5ReplicaType: 2
> >> nsDS5Flags: 0
> >> nsds5ReplicaPurgeDelay: 604800
> >> nsDS5ReplicaBindDN: uid=RManager,cn=config
> >> cn: replica
> >> nsDS5ReplicaId: 65535
> >> nsState:: //8AABRQWEcAAAAAAgAAAAEAAAA=
> >> nsDS5ReplicaName: 60c64002-1dd211b2-8039bd5e-680e0000
> >> nsDS5ReplicaReferral: ldap://SRVR1:389/dc=xxx,dc=ec,dc=gc,dc=ca
> >> nsDS5ReplicaReferral: ldap://SRVR2:389/dc=xxx,dc=ec,dc=gc,dc=ca
> >> nsds5ReplicaChangeCount: 2
> >> nsds5replicareapactive: 0
> >>
> >> # changelog5, config
> >> dn: cn=changelog5,cn=config
> >> objectClass: top
> >> objectClass: extensibleObject
> >> cn: changelog5
> >> nsslapd-changelogdir: /opt/fedora-ds/slapd-srvr3/changelogdb
> >>
> >> Now for setting up an MMR agreement between 2 suppliers
> >>
> >> 1. Source -> create rep user
> >> 2. Target -> create rep user
> >> 3. Source -> create changelog object
> >> 4. Target -> create changelog object
> >> 5. Source -> create replica object
> >> 6. Target -> create replica object
> >> 7. Source -> create rep agreement
> >> 8. Target -> create rep agreement
> >> 9. Source -> set nsDS5BeginReplicaRefresh in the rep agreement on the
> >> source to init the target. 10. Source -> update dn:
> >> cn="$config{BASE_DN}",cn=mapping tree,cn=config attribute
> >> nsslapd-referral with the ldap://target:PORT/$config{BASE_DN} 11. Target
> >> -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config
> attribute
> >> nsslapd-referral with the ldap://source:PORT/$config{BASE_DN}
> >>       
> > 10, 11 - the referrals should be set automatically.
> >     
>
>    
> >> How does that look?
> >>       
> > Looks good.
> >
> >     
> >> Should the multi-valued attribute nsslapd-referral contain entries for
> >> each server for which it has a MMR agreement with?
> >>       
> > Yes, but that should be handled automatically, unless you want to
> > override it.
> >
> >     
>
>  Same replication protocol magic question as above.
>
>  Ryan Braun
>  Informatics Operations
>  Aviation and Defence Services Division
>  Chief Information Officer Branch, Environment Canada
>  CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
>  E-Mail: Ryan.Braun(a)ec.gc.ca
>
>    
> >> One other question,  it seems that sometimes the value has the escape
> >> codes for the comma while sometimes it has the actual comma.
> >>
> >> ryan@infinity:~/fds-tools$ grep -i Referral *
> >> xxxoff-config:nsslapd-referral:
> >> ldap://xxxoff0.xxx.ec.gc.ca:389/dc%3Dxxx%2Cdc%3Dec%2Cdc%3Dgc
> >> xxxsrvr4-config:nsslapd-referral:
> >> ldap://srvr1:389/dc=xxx,dc=ec,dc=gc,dc=ca
> >>
> >> I assume either way will work and not break anything?  (which seems to be
> >> the case as it's running :)
> >>       
> > Yes.
> >
> >     
> >> Ryan Braun
> >> Informatics Operations
> >> Aviation and Defence Services Division
> >> Chief Information Officer Branch, Environment Canada
> >> CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
> >> E-Mail: Ryan.Braun(a)ec.gc.ca
> >>
> >> --
> >> Fedora-directory-users mailing list
> >> Fedora-directory-users(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>       
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

[Ryan Braun]

On Tuesday 11 December 2007 9:31 pm, Rich Megginson wrote:

[big time snip]

>  The supplier will by default attempt to send updates immediately. 
> If
>  the consumer goes down, the supplier will keep trying to reach it, using
>  an exponential backoff strategy, until it attempts to contact the
>  consumer every 5 minutes.  So at most you should only have to wait 5
>  minutes after the consumer comes back online. 
Ahhh good to know,  I'm pretty impatient and wanted the updates now.  

>  The referrals are automatically set to go to all of the masters, but
>  there is no guaranteed order.  So there is no guarantee of which master
>  the client will be referred to, only that it will be referred to one of
>  the masters. 
Well I used my script to setup a MMR agreement between 2 servers.  Then a consumer read
only agreement on those 2 servers to a third server.  Replication is working over all the
servers.  With one really odd quirk.  When I open up the console,  goto the configuration
tab -> Replication -> userRoot.  Then I click on one of the rep agreements I get an
insufficient permissions error (I'm logging in as cn=Directory Manager).

I click ok,  get prompted for a username and password (cn=Directory Manager is already in
the username box).  I just click cancel and it lets me continue to view/edit/delete the
rep agreement.

I restarted the server, same issue.

There aren't any err= messages in the access log and the error log doesn't have
any info about the message either.

Here is the rep agreement straight from the dse.ldif file

dn: cn=Replication to xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=,dc=ec,dc=gc,
 dc=ca",cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Replication to xxxldap1.isb.ec.gc.ca
nsDS5ReplicaHost: xxxldap1.xxx.ec.gc.ca
nsDS5ReplicaRoot: dc=xxx,dc=ec,dc=gc,dc=ca
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: uid=RManager,cn=config
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaUpdateSchedule: 0000-2359 0123456
nsds5replicaTimeout: 120
nsDS5ReplicaCredentials: {DES}S7ig2LTq5lWO65tutWo4JQ==
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20071211223651Z
modifyTimestamp: 20071211230605Z
nsds50ruv: {replicageneration} 475f0e11000000030000
nsds50ruv: {replica 1 ldap://xxxldap1.xxx.ec.gc.ca:389} 475f11c3000000010000 4
 75f11c3000000010000
nsds50ruv: {replica 3 ldap://infinity.xxx.ec.gc.ca:389} 475f11a6000000030000 4
 75f151a000000030000
nsruvReplicaLastModified: {replica 1 ldap://xxxldap1.xxx.ec.gc.ca:389} 0000000
 0
nsruvReplicaLastModified: {replica 3 ldap://infinity.xxx.ec.gc.ca:389} 0000000
 0

Ryan Braun
Informatics Operations
Aviation and Defence Services Division
Chief Information Officer Branch, Environment Canada
CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
E-Mail: Ryan.Braun(a)ec.gc.ca

[Rich Megginson]

Ryan Braun wrote:
>  <snip>
>    
>
>  Well I used my script to setup a MMR agreement between 2 servers.  Then a consumer read
> only agreement on those 2 servers to a third server.  Replication is working over all the
> servers.  With one really odd quirk.  When I open up the console,  goto the configuration
> tab -> Replication -> userRoot.  Then I click on one of the rep agreements I get an
> insufficient permissions error (I'm logging in as cn=Directory Manager).
>
>  I click ok,  get prompted for a username and password (cn=Directory Manager is already in
> the username box).  I just click cancel and it lets me continue to view/edit/delete the
> rep agreement.
>     
Try startconsole -D -f console.log - see if the log has any more 
information.
>  I restarted the server, same issue.
>
>  There aren't any err= messages in the access log and the error log doesn't have
> any info about the message either.
>
>  Here is the rep agreement straight from the dse.ldif file
>
>  dn: cn=Replication to xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=,dc=ec,dc=gc,
>   dc=ca",cn=mapping tree,cn=config
>  objectClass: top
>  objectClass: nsDS5ReplicationAgreement
>  cn: Replication to xxxldap1.isb.ec.gc.ca
>  nsDS5ReplicaHost: xxxldap1.xxx.ec.gc.ca
>  nsDS5ReplicaRoot: dc=xxx,dc=ec,dc=gc,dc=ca
>  nsDS5ReplicaPort: 389
>  nsDS5ReplicaBindDN: uid=RManager,cn=config
>  nsDS5ReplicaBindMethod: simple
>  nsDS5ReplicaUpdateSchedule: 0000-2359 0123456
>  nsds5replicaTimeout: 120
>  nsDS5ReplicaCredentials: {DES}S7ig2LTq5lWO65tutWo4JQ==
>  creatorsName: cn=directory manager
>  modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
>  createTimestamp: 20071211223651Z
>  modifyTimestamp: 20071211230605Z
>  nsds50ruv: {replicageneration} 475f0e11000000030000
>  nsds50ruv: {replica 1 ldap://xxxldap1.xxx.ec.gc.ca:389} 475f11c3000000010000 4
>   75f11c3000000010000
>  nsds50ruv: {replica 3 ldap://infinity.xxx.ec.gc.ca:389} 475f11a6000000030000 4
>   75f151a000000030000
>  nsruvReplicaLastModified: {replica 1 ldap://xxxldap1.xxx.ec.gc.ca:389} 0000000
>   0
>  nsruvReplicaLastModified: {replica 3 ldap://infinity.xxx.ec.gc.ca:389} 0000000
>   0
>
>  Ryan Braun
>  Informatics Operations
>  Aviation and Defence Services Division
>  Chief Information Officer Branch, Environment Canada
>  CIV: [phone]x2824 CSN: 257-2824  FAX: [phone]
>  E-Mail: Ryan.Braun(a)ec.gc.ca
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

[Ryan Braun]

On Tuesday 11 December 2007 11:42 pm, Rich Megginson wrote:
>  startconsole -D -f console.log - 

Below is the last 40 lines after the error.  It looks like these 3 lines tell the story
though

ReplicationAgreement.updateAgreementFromServer: unable to read the replica number of
changes from {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica refresh
attribute {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the consumer initialization
status attribute (nsds5replicalastinitstatus) {host=infinity.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}




AgreementReader: start readAgreements()
AgreementReader: getFromServer()
     Agreement Base DN: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
     Filter:           
|(objectclass=nsDS5ReplicationAgreement)(objectclass=LDAPReplica)(objectclass=nsDSWindowsReplicationAgreement)
ReplicationAgreement.setOrigEntryDN: cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
ReplicationAgreement.setEntryDN: cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
ReplicationAgreement.setOrigEntryDN: cn=Replication to
xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
ReplicationAgreement.setEntryDN: cn=Replication to
xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
AgreementReader: end readAgreements()
ReplicaResourceObject.treeExpanded: this
ReplicationTool.verifyDM: authDN = <cn=Directory Manager>, authPassword =
<xxxxxxxx>
getMachineDataDN: returning cn=replication,cn=config
AgreementReader: start readAgreements()
AgreementReader: getFromServer()
     Agreement Base DN: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping tree,cn=config
     Filter:           
|(objectclass=nsDS5ReplicationAgreement)(objectclass=LDAPReplica)(objectclass=nsDSWindowsReplicationAgreement)
ReplicationAgreement.setOrigEntryDN: cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
ReplicationAgreement.setEntryDN: cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
ReplicationAgreement.setOrigEntryDN: cn=Replication to
xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
ReplicationAgreement.setEntryDN: cn=Replication to
xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
AgreementReader: end readAgreements()
Add MMR Node
Class is com.netscape.admin.dirserv.panel.replication.MMRAgreement
Add MMR Node
Class is com.netscape.admin.dirserv.panel.replication.MMRAgreement
ResourceSet:getString():Unable to resolve general-Apply-ttip
ResourceSet:getString():Unable to resolve general-Reset-ttip
ResourceSet:getString():Unable to resolve general-Help-ttip
ReplicationAgreement.updateAgreementFromServer: unable to read the replica number of
changes from {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica refresh
attribute {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the consumer initialization
status attribute (nsds5replicalastinitstatus) {host=infinity.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}
BlankPanel.refresh:refreshed panel data. Class
com.netscape.admin.dirserv.panel.replication.AgreementInfoPanel
DSEntrySet.getAttributes(): read entry from DS:LDAPEntry: cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config; LDAPAttributeSet:
DSEntrySet.getAttributes(): attributes for this entry:[Ljava.lang.String;@1a28362
DSEntrySet.getAttributes(): failed to get attribute description in cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
DSEntrySet.show(): some of the attributes of cn=Replication to
xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config could not be read.  Either they are not present in the entry or there is an
ACI which prevents that attribute from being read. Try authenticating as a user with more
access
DSUtil.reauthenticate: begin: ldc={host=infinity.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica number of
changes from {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica refresh
attribute {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the consumer initialization
status attribute (nsds5replicalastinitstatus) {host=infinity.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}
DSTabbedPanel.select:
com.netscape.admin.dirserv.panel.replication.AgreementPanel[,0,0,605x468,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=java.awt.Dimension[width=1,height=1],preferredSize=]

[Chris G. Sellers]

Sorry for jumping in here (just joined the list) but it sounds like  
your replication user is being blocked by an ACI that you have  
applied.  These could be explicit or inherited from a parent OU in the  
tree.

Make sure your Replication User is not part of a ACI or make it part  
of a new ACI that allows objectclass=* full permissions.

Sellers

On Dec 12, 2007, at 10:12 AM, Ryan Braun wrote:

>  On Tuesday 11 December 2007 11:42 pm, Rich Megginson wrote:
>  > startconsole -D -f console.log -
>
>
>  Below is the last 40 lines after the error.  It looks like these 3  
>  lines tell the story though
>
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  replica number of changes from {host=infinity.xxx.ec.gc.ca}  
>  {port=389} {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  replica refresh attribute {host=infinity.xxx.ec.gc.ca} {port=389}  
>  {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  consumer initialization status attribute  
>  (nsds5replicalastinitstatus) {host=infinity.xxx.ec.gc.ca} {port=389}  
>  {authdn=cn=Directory Manager}
>
>
>
>
>  AgreementReader: start readAgreements()
>  AgreementReader: getFromServer()
>       Agreement Base DN: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>       Filter:            |(objectclass=nsDS5ReplicationAgreement) 
>  (objectclass=LDAPReplica)(objectclass=nsDSWindowsReplicationAgreement)
>  ReplicationAgreement.setOrigEntryDN: cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  ReplicationAgreement.setEntryDN: cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  ReplicationAgreement.setOrigEntryDN: cn=Replication to  
>  xxxsrvr4 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  ReplicationAgreement.setEntryDN: cn=Replication to  
>  xxxsrvr4 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  AgreementReader: end readAgreements()
>  ReplicaResourceObject.treeExpanded: this
>  ReplicationTool.verifyDM: authDN = <cn=Directory Manager>,  
>  authPassword = <xxxxxxxx>
>  getMachineDataDN: returning cn=replication,cn=config
>  AgreementReader: start readAgreements()
>  AgreementReader: getFromServer()
>       Agreement Base DN: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>       Filter:            |(objectclass=nsDS5ReplicationAgreement) 
>  (objectclass=LDAPReplica)(objectclass=nsDSWindowsReplicationAgreement)
>  ReplicationAgreement.setOrigEntryDN: cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  ReplicationAgreement.setEntryDN: cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  ReplicationAgreement.setOrigEntryDN: cn=Replication to  
>  xxxsrvr4 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  ReplicationAgreement.setEntryDN: cn=Replication to  
>  xxxsrvr4 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  AgreementReader: end readAgreements()
>  Add MMR Node
>  Class is com.netscape.admin.dirserv.panel.replication.MMRAgreement
>  Add MMR Node
>  Class is com.netscape.admin.dirserv.panel.replication.MMRAgreement
>  ResourceSet:getString():Unable to resolve general-Apply-ttip
>  ResourceSet:getString():Unable to resolve general-Reset-ttip
>  ResourceSet:getString():Unable to resolve general-Help-ttip
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  replica number of changes from {host=infinity.xxx.ec.gc.ca}  
>  {port=389} {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  replica refresh attribute {host=infinity.xxx.ec.gc.ca} {port=389}  
>  {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  consumer initialization status attribute  
>  (nsds5replicalastinitstatus) {host=infinity.xxx.ec.gc.ca} {port=389}  
>  {authdn=cn=Directory Manager}
>  BlankPanel.refresh:refreshed panel data. Class  
>  com.netscape.admin.dirserv.panel.replication.AgreementInfoPanel
>  DSEntrySet.getAttributes(): read entry from DS:LDAPEntry:  
>  cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config; LDAPAttributeSet:
>  DSEntrySet.getAttributes(): attributes for this entry: 
>  [Ljava.lang.String;@1a28362
>  DSEntrySet.getAttributes(): failed to get attribute description in  
>  cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config
>  DSEntrySet.show(): some of the attributes of cn=Replication to  
>  xxxldap1 
>  .xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping  
>  tree,cn=config could not be read.  Either they are not present in  
>  the entry or there is an ACI which prevents that attribute from  
>  being read. Try authenticating as a user with more access
>  DSUtil.reauthenticate: begin: ldc={host=infinity.xxx.ec.gc.ca}  
>  {port=389} {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  replica number of changes from {host=infinity.xxx.ec.gc.ca}  
>  {port=389} {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  replica refresh attribute {host=infinity.xxx.ec.gc.ca} {port=389}  
>  {authdn=cn=Directory Manager}
>  ReplicationAgreement.updateAgreementFromServer: unable to read the  
>  consumer initialization status attribute  
>  (nsds5replicalastinitstatus) {host=infinity.xxx.ec.gc.ca} {port=389}  
>  {authdn=cn=Directory Manager}
>  DSTabbedPanel.select:  
>  com.netscape.admin.dirserv.panel.replication.AgreementPanel[, 
>  0,0,605x468 
>  ,layout 
>  = 
>  java 
>  .awt 
>  .BorderLayout 
>  ,alignmentX 
>  = 
>  0.0 
>  ,alignmentY 
>  = 
>  0.0 
>  ,border 
>  = 
>  ,flags 
>  = 
>  9 
>  ,maximumSize 
>  =,minimumSize=java.awt.Dimension[width=1,height=1],preferredSize=]
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  

---
Chris G. Sellers		Lead Internet Engineer
National Institute for Technology & Liberal Ed.
535 West William Street, Ann Arbor, MI 48103
chris.sellers(a)nitle.org		 734.661.2318

[Rich Megginson]

Chris G. Sellers wrote:
>  Sorry for jumping in here (just joined the list) but it sounds like 
>  your replication user is being blocked by an ACI that you have 
>  applied.  These could be explicit or inherited from a parent OU in the 
>  tree. 
And you should definitely be able to see something in the access log for 
host=infinity.xxx.ec.gc.ca.  Keep in mind that the access log is 
buffered so events will not show up for a few minutes if there is no 
other activity.
>  Make sure your Replication User is not part of a ACI or make it part 
>  of a new ACI that allows objectclass=* full permissions.
>
>  Sellers
>
>  On Dec 12, 2007, at 10:12 AM, Ryan Braun wrote:
>
> > On Tuesday 11 December 2007 11:42 pm, Rich Megginson wrote:
> > > startconsole -D -f console.log -
> >
> >
> > Below is the last 40 lines after the error.  It looks like these 3 
> > lines tell the story though
> >
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > replica number of changes from {host=infinity.xxx.ec.gc.ca} 
> > {port=389} {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > replica refresh attribute {host=infinity.xxx.ec.gc.ca} {port=389} 
> > {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > consumer initialization status attribute (nsds5replicalastinitstatus) 
> > {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
> >
> >
> >
> >
> > AgreementReader: start readAgreements()
> > AgreementReader: getFromServer()
> >      Agreement Base DN: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> >      Filter:            
> >
> |(objectclass=nsDS5ReplicationAgreement)(objectclass=LDAPReplica)(objectclass=nsDSWindowsReplicationAgreement)
> > ReplicationAgreement.setOrigEntryDN: cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > ReplicationAgreement.setEntryDN: cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > ReplicationAgreement.setOrigEntryDN: cn=Replication to 
> > xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > ReplicationAgreement.setEntryDN: cn=Replication to 
> > xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > AgreementReader: end readAgreements()
> > ReplicaResourceObject.treeExpanded: this
> > ReplicationTool.verifyDM: authDN = <cn=Directory Manager>, 
> > authPassword = <xxxxxxxx>
> > getMachineDataDN: returning cn=replication,cn=config
> > AgreementReader: start readAgreements()
> > AgreementReader: getFromServer()
> >      Agreement Base DN: cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> >      Filter:            
> >
> |(objectclass=nsDS5ReplicationAgreement)(objectclass=LDAPReplica)(objectclass=nsDSWindowsReplicationAgreement)
> > ReplicationAgreement.setOrigEntryDN: cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > ReplicationAgreement.setEntryDN: cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > ReplicationAgreement.setOrigEntryDN: cn=Replication to 
> > xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > ReplicationAgreement.setEntryDN: cn=Replication to 
> > xxxsrvr4.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > AgreementReader: end readAgreements()
> > Add MMR Node
> > Class is com.netscape.admin.dirserv.panel.replication.MMRAgreement
> > Add MMR Node
> > Class is com.netscape.admin.dirserv.panel.replication.MMRAgreement
> > ResourceSet:getString():Unable to resolve general-Apply-ttip
> > ResourceSet:getString():Unable to resolve general-Reset-ttip
> > ResourceSet:getString():Unable to resolve general-Help-ttip
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > replica number of changes from {host=infinity.xxx.ec.gc.ca} 
> > {port=389} {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > replica refresh attribute {host=infinity.xxx.ec.gc.ca} {port=389} 
> > {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > consumer initialization status attribute (nsds5replicalastinitstatus) 
> > {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
> > BlankPanel.refresh:refreshed panel data. Class 
> > com.netscape.admin.dirserv.panel.replication.AgreementInfoPanel
> > DSEntrySet.getAttributes(): read entry from DS:LDAPEntry: 
> > cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config; LDAPAttributeSet:
> > DSEntrySet.getAttributes(): attributes for this 
> > entry:[Ljava.lang.String;@1a28362
> > DSEntrySet.getAttributes(): failed to get attribute description in 
> > cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config
> > DSEntrySet.show(): some of the attributes of cn=Replication to 
> > xxxldap1.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
> > tree,cn=config could not be read.  Either they are not present in the 
> > entry or there is an ACI which prevents that attribute from being 
> > read. Try authenticating as a user with more access
> > DSUtil.reauthenticate: begin: ldc={host=infinity.xxx.ec.gc.ca} 
> > {port=389} {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > replica number of changes from {host=infinity.xxx.ec.gc.ca} 
> > {port=389} {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > replica refresh attribute {host=infinity.xxx.ec.gc.ca} {port=389} 
> > {authdn=cn=Directory Manager}
> > ReplicationAgreement.updateAgreementFromServer: unable to read the 
> > consumer initialization status attribute (nsds5replicalastinitstatus) 
> > {host=infinity.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
> > DSTabbedPanel.select: 
> >
> com.netscape.admin.dirserv.panel.replication.AgreementPanel[,0,0,605x468,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=java.awt.Dimension[width=1,height=1],preferredSize=]
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com 
> > <mailto:[e-mail]>
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
>
>
>  ---
>  Chris G. Sellers Lead Internet Engineer
>  National Institute for Technology & Liberal Ed.
>  535 West William Street, Ann Arbor, MI 48103
>  chris.sellers(a)nitle.org <mailto:[e-mail]>  734.661.2318
>
>
>
>
>
>  ------------------------------------------------------------------------
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

[Ryan Braun]

On Wednesday 12 December 2007 4:02 pm, Rich Megginson wrote:
>  Chris G. Sellers wrote:
>  > Sorry for jumping in here (just joined the list) but it sounds like
>  > your replication user is being blocked by an ACI that you have
>  > applied.  These could be explicit or inherited from a parent OU in the
>  > tree.
>
>  And you should definitely be able to see something in the access log for
>  host=infinity.xxx.ec.gc.ca.  Keep in mind that the access log is
>  buffered so events will not show up for a few minutes if there is no
>  other activity.
>  
I've turned off buffering for the time being

Here is the access log

[12/Dec/2007:16:22:29 +0000] conn=7 op=17 SRCH base="cn=Replication to
infinity.xxx.ec.gc.ca,cn=replica,cn=\22dc=xxx,dc=ec,dc=gc,dc=ca\22,cn=mapping
tree,cn=config" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[12/Dec/2007:16:22:29 +0000] conn=7 op=17 RESULT err=0 tag=101 nentries=1 etime=0
[12/Dec/2007:16:22:29 +0000] conn=7 op=18 SRCH base="cn=Replication to
infinity.xxx.ec.gc.ca,cn=replica,cn=\22dc=xxx,dc=ec,dc=gc,dc=ca\22,cn=mapping
tree,cn=config" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))"
attrs="description"
[12/Dec/2007:16:22:29 +0000] conn=7 op=18 RESULT err=0 tag=101 nentries=1 etime=0
[12/Dec/2007:16:22:36 +0000] conn=7 op=20 SRCH base="cn=Replication to
infinity.xxx.ec.gc.ca,cn=replica,cn=\22dc=xxx,dc=ec,dc=gc,dc=ca\22,cn=mapping
tree,cn=config" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[12/Dec/2007:16:22:36 +0000] conn=7 op=20 RESULT err=0 tag=101 nentries=1 etime=0


And the console log

ResourceSet:getString():Unable to resolve general-Apply-ttip
ResourceSet:getString():Unable to resolve general-Reset-ttip
ResourceSet:getString():Unable to resolve general-Help-ttip
ReplicationAgreement.updateAgreementFromServer: unable to read the replica number of
changes from {host=xxxldap1.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica refresh
attribute {host=xxxldap1.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the consumer initialization
status attribute (nsds5replicalastinitstatus) {host=xxxldap1.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}
BlankPanel.refresh:refreshed panel data. Class
com.netscape.admin.dirserv.panel.replication.AgreementInfoPanel
DSEntrySet.getAttributes(): read entry from DS:LDAPEntry: cn=Replication to
infinity.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config; LDAPAttributeSet:
DSEntrySet.getAttributes(): attributes for this entry:[Ljava.lang.String;@18235ed
DSEntrySet.getAttributes(): failed to get attribute description in cn=Replication to
infinity.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config
DSEntrySet.show(): some of the attributes of cn=Replication to
infinity.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping
tree,cn=config could not be read.  Either they are not present in the entry or there is an
ACI which prevents that attribute from being read. Try authenticating as a user with more
access
DSUtil.reauthenticate: begin: ldc={host=xxxldap1.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica number of
changes from {host=xxxldap1.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica refresh
attribute {host=xxxldap1.xxx.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the consumer initialization
status attribute (nsds5replicalastinitstatus) {host=xxxldap1.xxx.ec.gc.ca} {port=389}
{authdn=cn=Directory Manager}
DSTabbedPanel.select:
com.netscape.admin.dirserv.panel.replication.AgreementPanel[,0,0,827x493,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=java.awt.Dimension[width=1,height=1],preferredSize=]



>  > Make sure your Replication User is not part of a ACI or make it
> part
>  > of a new ACI that allows objectclass=* full permissions. 
There was no configuration done on the test servers.  I installed the packages,  brought
up the console and made sure everything was working then ran my script.  And the
replication does in fact work across all machines.  The console client is the only thing
throwing errors.

Here are the subs I use to create replication objects and rep agreements.


sub add_rep_agreement
{
	my ($source, $source_port, $target, $target_port,$with_ssl, $bind_pw) = @_;
	my ($ldap, $msg);

	$ldap = conn_bind($source, $source_port, $bind_pw);

	print "adding to Replication Agreement $source -> $target\n";
	$msg = $ldap->add(
		"cn=Replication to $target,cn=replica,cn=\"$config{BASE_DN}\",cn=mapping
tree,cn=config",
			attr => [
			objectclass                  => [qw (top nsDS5ReplicationAgreement)],
			cn                           => "Replication to $target",
			nsDS5ReplicaHost             => $target,
			nsDS5ReplicaRoot             => "$config{BASE_DN}",
			nsDS5ReplicaPort             => $target_port,
			#nsDS5ReplicaTransportInfo    => "SSL",
			nsDS5ReplicaBindDN           => $config{REP_DN},
			nsDS5ReplicaBindMethod       => "simple",
			nsDS5ReplicaCredentials      => $config{REPMAN_PW},
			nsDS5ReplicaUpdateSchedule   => "0000-2359 0123456",
			nsDS5ReplicaTimeOut          => 120,
		]
	);

	if ($msg->code == LDAP_ALREADY_EXISTS) {
		print "\t -> already exists\n\n";
		# disconnect here and return if exists
		disconnect($ldap);
		return
	} else {
		$msg->code && die "failed to add replication agreement entry: " .
$msg->error;
        }

	if ($with_ssl eq 1) {
		# TODO ldapmodify and add #nsDS5ReplicaTransportInfo    => "SSL",
		print "Should be adding SSL here!\n";
	}
	
	disconnect($ldap);
	
}

sub add_rep_object
{
	# TODO specify multiple referral entries ?
	# 
	# nsDS5ReplicaType
	# 0 - reserved for internal use
	# 1 - Dedicated Supplier
	# 2 - Dedicated Consumer	<---- consumer only
	# 3 - Supplier/Consumer		<---- MMR server
	
	# passed variable $rep_type is not the same as the above!!

	my ($server, $server_port, $referral, $referral_port, $bind_pw, $rep_type) = @_;
	my ($ldap, $msg);
	
	# server is the server the object is getting created on
	# referral is the server to send referrals to if setting up a consumer read only
	$ldap = conn_bind($server, $server_port, $bind_pw);

	##############################
	# add replica object
	##############################

	# type 1 is MMR
	# type 2 is consumer read only
	print "adding to Replica object to $server ->
cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config\n";
	
	# add consumer type rep
	if ( $rep_type eq 2 ) 	{
		$msg = $ldap->add(
			"cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config",
			attr => [
				objectclass                  => [qw (top nsDS5Replica)],
				cn                           => "replica",
				nsDS5ReplicaId               => 65535,
				nsDS5ReplicaReferral	     =>
"ldap://$referral:$referral_port/$config{BASE_DN}",
				nsDS5ReplicaRoot             => $config{BASE_DN},
				nsDS5Flags                   => 0,
				nsDS5ReplicaBindDN           => $config{REP_DN},
				nsds5ReplicaPurgeDelay       => 604800,
				nsds5ReplicaLegacyConsumer   => "off",
				nsDS5ReplicaType             => 2,
			]
		);
	}

	# add MMR type rep
	if ($rep_type eq 1) {
		$msg = $ldap->add(
			"cn=replica,cn=\"$config{BASE_DN}\",cn=mapping tree,cn=config",
			attr => [
				objectclass                  => [qw (top nsDS5Replica)],
				cn                           => "replica",
				nsDS5ReplicaId               => $config{REP_ID},
				nsDS5ReplicaRoot             => $config{BASE_DN},
				nsDS5Flags                   => 1,
				nsDS5ReplicaBindDN           => $config{REP_DN},
				nsds5ReplicaPurgeDelay       => 604800,
				nsds5ReplicaLegacyConsumer   => "off",
				nsDS5ReplicaType             => 3,
			]
		);

		
	}

	if ($msg->code == LDAP_ALREADY_EXISTS)
	{
		print "\t -> already exists\n\n";
		# disconnect and return here before incrementing the rep_id if the object already
exists
		disconnect($ldap);
		return;
		
	} else {
		$msg->code && die "failed to add replica entry: " .
$msg->error;
	}

	# if MMR reptype,  and we created an object,  we need to increment the rep_id in the
config file
	if ( $rep_type eq 1 ) {
		
		$config{REP_ID} = $config{REP_ID} + 1;
		save_config();
		load_config();
	}
	
	disconnect($ldap);

}

[Ryan Braun]

On Wednesday 12 December 2007 4:02 pm, Rich Megginson wrote:
>  Chris G. Sellers wrote:
>  > Sorry for jumping in here (just joined the list) but it sounds like
>  > your replication user is being blocked by an ACI that you have
>  > applied.  These could be explicit or inherited from a parent OU in the
>  > tree.
>
>  And you should definitely be able to see something in the access log for
>  host=infinity.xxx.ec.gc.ca.  Keep in mind that the access log is
>  buffered so events will not show up for a few minutes if there is no
>  other activity.
>
>  > Make sure your Replication User is not part of a ACI or make it part
>  > of a new ACI that allows objectclass=* full permissions. 
Ok I think I got it.

After looking closer at the console log file and this line
DSEntrySet.getAttributes(): failed to get attribute description in 
cn=Replication to 
infinity.xxx.ec.gc.ca,cn=replica,cn="dc=xxx,dc=ec,dc=gc,dc=ca",cn=mapping 
tree,cn=config

I went and manually added a description attribute for the replication 
agreement and I no longer am getting prompted for authentication.  So I'll 
just modify my sub and have it create some kind of default description 
attribute.

Still get the

ReplicationAgreement.updateAgreementFromServer: unable to read the replica 
number of changes from {host=ywgldap1.isb.ec.gc.ca} {port=389} 
{authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the replica 
refresh attribute {host=ywgldap1.isb.ec.gc.ca} {port=389} 
{authdn=cn=Directory Manager}
ReplicationAgreement.updateAgreementFromServer: unable to read the consumer 
initialization status attribute (nsds5replicalastinitstatus) 
{host=ywgldap1.isb.ec.gc.ca} {port=389} {authdn=cn=Directory Manager}

But I'm guessing those are more informative type messages then error messages.

Ryan