[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:: //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: (204) 833-2500x2824 CSN: 257-2824 FAX: (204) 833-2524 E-Mail: Ryan.Braun@ec.gc.ca
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
- 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
- Supplier -> create replication user
Unless the Supplier will also be a Consumer, this step is not necessary.
- Consumer -> create replication user
- Supplier -> add changelog object ("cn=changelog5,cn=config")
- Consumer -> add changelog object ("cn=changelog5,cn=config")
Unless the Consumer will also be a Supplier, this step is not necessary.
- Supplier -> add replica object ("cn=replica,cn="$config{BASE_DN}",cn=mapping tree,cn=config")
- 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)
- Supplier -> create rep agreement object ("cn="Replication to $to",cn=replica,cn="$base",cn=mapping tree,cn=config")
- 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.
- 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
- Source -> create rep user
- Target -> create rep user
- Source -> create changelog object
- Target -> create changelog object
- Source -> create replica object
- Target -> create replica object
- Source -> create rep agreement
- Target -> create rep agreement
- Source -> set nsDS5BeginReplicaRefresh in the rep agreement on the source to init the target.
- Source -> update dn: cn="$config{BASE_DN}",cn=mapping tree,cn=config attribute nsslapd-referral with the ldap://target:PORT/$config{BASE_DN}
- 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
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
also http://www.redhat.com/docs/manuals/dir-server/schema/7.1/schemaTOC.html
Will do.
- 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
- 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.
- Consumer -> create replication user
- Supplier -> add changelog object ("cn=changelog5,cn=config")
- 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.
- 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?
- 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
- Source -> create rep user
- Target -> create rep user
- Source -> create changelog object
- Target -> create changelog object
- Source -> create replica object
- Target -> create replica object
- Source -> create rep agreement
- Target -> create rep agreement
- 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
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
also http://www.redhat.com/docs/manuals/dir-server/schema/7.1/schemaTOC.html
Will do.
- 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
- 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.
- Consumer -> create replication user
- Supplier -> add changelog object ("cn=changelog5,cn=config")
- 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.
- 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.
- 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
- Source -> create rep user
- Target -> create rep user
- Source -> create changelog object
- Target -> create changelog object
- Source -> create replica object
- Target -> create replica object
- Source -> create rep agreement
- Target -> create rep agreement
- 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
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
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
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=]
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
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
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);
}
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
389-users@lists.fedoraproject.org
-
Chris G. Sellers -
Rich Megginson -
Ryan Braun