Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Directory (http://www.linux-archive.org/fedora-directory/)
-   -   Replication Referrals being reset unexpectedly (http://www.linux-archive.org/fedora-directory/641749-replication-referrals-being-reset-unexpectedly.html)

Rich Megginson 03-07-2012 03:11 AM

Replication Referrals being reset unexpectedly
 
On 03/06/2012 07:33 PM, Michael R. Gettes wrote:

389-ds-base is 1.2.9.9 on EL5

I have an MMR setup, 2 suppliers to 3 consumers. I am replicating userRoot and netscapeRoot.
All replication agreements are over SSL:636 using simple binds. On the consumers, the referrals shown in the mapping tree (nsslapd-referral) are ldap://hostname:389/suffix for each supplier. I need them to be ldaps://hostname:636/suffix. I have changed them live and then I make an object change and it works as I would expect. But when I restart the dsa the referrals are reset to ldap://hostname:389/suffix

how do i prevent the nsslapd-referral attributes from being reset?

See
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html#Multi_Master_Replication-Configuring_the_Read_Only_Replicas_on_the_Consumer _Servers





Specify the URL for any supplier servers to
which to refer updates, such as the other suppliers in the
multi-master replication set. Only specify the URL for the
supplier server.
For clients to bind using SSL, specify a URL
beginning with ldaps://.


See also
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replicati on_Attributes_under_cnreplica_cnsuffixName_cnmappi ng_tree_cnconfig-nsDS5ReplicaReferral




Thanks.

/mrg
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

"Michael R. Gettes" 03-07-2012 12:35 PM

Replication Referrals being reset unexpectedly
 
Once again, thank you so much. *The first URL, I did read all that and tried to make that work. *11.5.2-3g in particular but those changes weren't being applied. *I have added the specific nsDS5ReplicaReferral attribute and all is working just right now.
/mrg
On Mar 6, 2012, at 23:11, Rich Megginson wrote:




On 03/06/2012 07:33 PM, Michael R. Gettes wrote:

389-ds-base is 1.2.9.9 on EL5

I have an MMR setup, 2 suppliers to 3 consumers. I am replicating userRoot and netscapeRoot.
All replication agreements are over SSL:636 using simple binds. On the consumers, the referrals shown in the mapping tree (nsslapd-referral) are ldap://hostname:389/suffix for each supplier. I need them to be ldaps://hostname:636/suffix. I have changed them live and then I make an object change and it works as I would expect. But when I restart the dsa the referrals are reset to ldap://hostname:389/suffix

how do i prevent the nsslapd-referral attributes from being reset?

See
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html#Multi_Master_Replication-Configuring_the_Read_Only_Replicas_on_the_Consumer _Servers





Specify the URL for any supplier servers to
which to refer updates, such as the other suppliers in the
multi-master replication set. Only specify the URL for the
supplier server.
For clients to bind using SSL, specify a URL
beginning with ldaps://.


See also
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replicati on_Attributes_under_cnreplica_cnsuffixName_cnmappi ng_tree_cnconfig-nsDS5ReplicaReferral



Thanks.

/mrg
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users






--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


All times are GMT. The time now is 08:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.