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:
1. Have 2 multi-master Directory Servers (1.2.9.9) setup and running
2. Create another DS, set Replication to "dedicated consumer"
3. Create a replication agreement from 1 of the multi-masters to this consumer
4. Modify an entry from the consumer
5. 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?
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).
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.
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:
1.Have 2 multi-master Directory Servers (1.2.9.9) setup and running
2.Create another DS, set Replication to "dedicated consumer"
3.Create a replication agreement from 1 of the multi-masters to this consumer
4.Modify an entry from the consumer
5.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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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 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? 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.
From: Rich Megginson [mailto:rmeggins@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@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
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@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@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Ok so to stop updates just don't let the clients through the firewall. To allow updates I'd investigate the ChainOnUpdate method. Thanks Rich
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Thursday, February 09, 2012 11:38 AM To: Groten, Ryan Cc: General discussion list for the 389 Directory server project. Subject: Re: [389-users] How do read-only consumers work?
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@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@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
389-users@lists.fedoraproject.org
-
Groten, Ryan -
Rich Megginson