[Fedora-directory-users] Questions about setting up replication by modifying ldap directly.
Rich Megginson
rmeggins at redhat.com
Tue Dec 11 21:31:19 UTC 2007
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 at 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 at 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 at ec.gc.ca
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20071211/6b3e025e/attachment.bin>
More information about the Fedora-directory-users
mailing list