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

If this information is useful, please help other people find it:
Share via:

Ryan Braun

2007-Dec-11 18:54 UTC

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

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:: //8AABRQWEcAAAAAAgAAAAEAAAAnsDS5ReplicaName:
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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
E-Mail: Ryan.Braun@ec.gc.ca

Rich Megginson

2007-Dec-11 20:31 UTC

head link

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

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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
> E-Mail: Ryan.Braun@ec.gc.ca 
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Ryan Braun

2007-Dec-11 21:08 UTC

head link

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

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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
E-Mail: Ryan.Braun@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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
> > E-Mail: Ryan.Braun@ec.gc.ca
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users

Rich Megginson

2007-Dec-11 21:31 UTC

head link

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

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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
> E-Mail: Ryan.Braun@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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
>>> E-Mail: Ryan.Braun@ec.gc.ca
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>       
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Ryan Braun

2007-Dec-11 23:17 UTC

head link

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

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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
E-Mail: Ryan.Braun@ec.gc.ca

Rich Megginson

2007-Dec-11 23:42 UTC

head link

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

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: (204) 833-2500x2824 CSN: 257-2824  FAX: (204) 833-2524
> E-Mail: Ryan.Braun@ec.gc.ca
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Ryan Braun

2007-Dec-12 15:12 UTC

head link

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

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

2007-Dec-12 15:25 UTC

head link

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

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@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@nitle.org		 734.661.2318

Rich Megginson

2007-Dec-12 16:02 UTC

head link

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

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@redhat.com 
>> <mailto:Fedora-directory-users@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@nitle.org <mailto:chris.sellers@nitle.org> 
734.661.2318
>
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Ryan Braun

2007-Dec-12 16:32 UTC

head link

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

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

2007-Dec-12 16:40 UTC

head link

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

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

Fedora directory users - Dec 2007 - Questions about setting up replication by modifying ldap directly.

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

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

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

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

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

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

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

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.

Re: [Fedora-directory-users] Questions about setting up replicationby modifying ldap directly.