[389-users] How do read-only consumers work?

[Rich Megginson]

On 02/09/2012 11:37 AM, Groten, Ryan wrote:
>
> What if the clients are external (along with the consumer) and can't 
> follow the referral?  Ideally the read-only replica is put in place 
> outside a firewall, then it is allowed to talk directly to the master 
> (clients are not allowed).  This would prevent having to allow X 
> number of clients to connect directly to a master directory server.
>
If they can't follow the referral, they will get an error.
>
> If it's not possible to control which updates are allowed and which 
> aren't, is there a way to disable updates (from the read-only to the 
> master) entirely?
>
There are no updates from the read-only to the master.  There are only 
updates from clients.
>
> This wouldn't be ideal because it complicates the environment for 
> users (ie: don't change your password in external facing zones because 
> it won't be reflected internally), but prevents an external intrusion 
> from affecting internal.
>
See also http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
>
> *From:*Rich Megginson [mailto:rmeggins at redhat.com]
> *Sent:* Thursday, February 09, 2012 11:27 AM
> *To:* General discussion list for the 389 Directory server project.
> *Cc:* Groten, Ryan
> *Subject:* Re: [389-users] How do read-only consumers work?
>
> On 02/09/2012 11:24 AM, Groten, Ryan wrote:
>
> Hi all,
>
> I'm testing out setting up 2 read-only consumers (each matches 1 of 2 
> multi-masters).  Seems to be working fine, but I'm just trying to wrap 
> my head around what's happening when changes are made:
>
> Have 2 multi-master Directory Servers (1.2.9.9) setup and running
>
> Create another DS, set Replication to "dedicated consumer"
>
> Create a replication agreement from 1 of the multi-masters to this 
> consumer
>
> Modify an entry from the consumer
>
> Change is made on the read-only server and on the multi-masters
>
> There's no replication agreement going FROM the consumer to the 
> master, but I see changes on the master side anyways.  Is the consumer 
> sending a request with the change to the master, who then makes the 
> change and replicates it back to the consumer?
>
> No.  The database state on the consumers are set to "referral on 
> update".  This means that when a update request is received on the 
> consumer, it sends back to the client a referral to one of the 
> masters.  If you are using a "smart" client like the console, it will 
> automatically follow the referral for you.
>
> If the above is true, then how would I go about doing something like this:
>
> The goal I'm trying to achieve is I want to put some read-only DS in 
> an external zone.  In theory I don't think the read-only's should be 
> able to modify the masters for security reasons (ie: if someone 
> external compromises the external DS, they shouldn't be able to delete 
> all the entries in the internal).  However, having the option to allow 
> certain changes from the external into internal may be useful (maybe 
> allowing password changes from the read-only to the master or something).
>
> That would be tricky to implement
>
> Thanks,
>
> Ryan
>
> ------------------------------------------------------------------------
>
> This communication, including any attached documentation, is intended 
> only for the person or entity to which it is addressed, and may 
> contain confidential, personal and/or privileged information. Any 
> unauthorized disclosure, copying, or taking action on the contents is 
> strictly prohibited. If you have received this message in error, 
> please contact us immediately so we may correct our records. Please 
> then delete or destroy the original transmission and any subsequent reply.
>
>   
>   
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120209/7a5a209e/attachment-0001.html>