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?
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.htmlI 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
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.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
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.
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.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 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.
Yes, but that should be handled automatically, unless you want to override it.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 :)
Yes.
Ryan Braun Informatics OperationsAviation 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@xxxxxxxx-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
