Re: referral on update equivalent with dsconf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On 21 May 2019, at 21:37, Angel Bosch Mora <abosch@xxxxxxxxxxxxxxxx> wrote:
> 
> Hi,
> 
> is this new command:
> 
> dsconf instance replication set --suffix "dc=example,dc=net" --repl-add-ref master1.example.net
> 
> 
> the same as this modification?
> 
> REF_LDIF="dn: cn=dc\=example\,dc\=net,cn=mapping tree,cn=config
> changetype: modify
> replace: nsslapd-referral
> nsslapd-referral: ldap://master1.example.net:389/dc\=example\,dc\=net
> -
> replace: nsslapd-state
> nsslapd-state: referral on update
> "
> 
> echo "$REF_LDIF" | ldapmodify -h "$HOST" -x -D "$ROOT_DN" -w "$ROOT_PASS"
> 
> I'm trying to follow all docs https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-configuring-replication-cmd
> 
> but with new tools, and I'm struggling with some commands.
> 
> regards,
> 
> abosch
> 

I don't think so. I think some of the commands were created to be "manipulating attributes" rather than 'recipe oriented', which leads to this confusion because we do not clearly convey the intent of the action that teh command will execute. A better command syntax here would have been "dsconf instance replication role read-only configure-write-referal", where the the ldif you list would be "dsconf instance query-routing add-remote-referral" or something like that. 

In this command you have listed, it is setting and controlling the value of nsDS5ReplicaReferral in the replication agreement. This means that a read-only consumer when updated will return a referral to a writable server.

The modification you list is about allowing a server which is *not* part of the replication topology to be able to provide referrals to another server that can fufil the request. 

To demonstrate the two scenarios with an example: 


[ Write Server A ] -- replication --> [ RO server B ]
      ^                                    |   ^
      | 3.                              2. |   |  1.
      |                                    v   |
      \-------------------------------- [ client ] 

1. Client writes under (dc=a) to RO server
2. RO Server returns referral to Write Server A
3. Client follows the referral and attempts the write of (dc=a) on A


[ Server A (dc=a) ]                [ Server B (dc=b) ]
      ^                                    |   ^
      | 3.                              2. |   |  1.
      |                                    v   |
      \-------------------------------- [ client ] 

1. Client wants to READ or WRITE to (dc=a) on Server B
2. Mapping tree router determines a referral should be sent and responds with referral to Server A
3. Client follows referral and re-attempts on Server A.


So I think that really, mapping tree is an ldap router function inside the server, so perhaps it's best to consider it like that, which is why the cli tools were misleading you here sadly. I think we as a team, need to review and understand what happened here to cause them to mislead a person about their function. :( 

Sorry that this confusion occured. Does my answer help? 


> 
> 
> 
> 
> -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent.
> -- Abans d'imprimir aquest missatge, pensau si es realment necessari.
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux