Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 16686 invoked from network); 20 Aug 2010 18:12:26 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Aug 2010 18:12:26 -0000 Received: (qmail 74913 invoked by uid 500); 20 Aug 2010 18:12:25 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 74845 invoked by uid 500); 20 Aug 2010 18:12:24 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 74834 invoked by uid 99); 20 Aug 2010 18:12:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Aug 2010 18:12:24 +0000 X-ASF-Spam-Status: No, hits=4.3 required=10.0 tests=FS_REPLICA,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.210.52] (HELO mail-pz0-f52.google.com) (209.85.210.52) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Aug 2010 18:12:16 +0000 Received: by pzk27 with SMTP id 27so2109979pzk.11 for ; Fri, 20 Aug 2010 11:11:56 -0700 (PDT) Received: by 10.114.27.17 with SMTP id a17mr1867730waa.115.1282327916033; Fri, 20 Aug 2010 11:11:56 -0700 (PDT) Received: from [10.0.1.2] (c-24-130-240-73.hsd1.ca.comcast.net [24.130.240.73]) by mx.google.com with ESMTPS id q6sm5313835waj.22.2010.08.20.11.11.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 11:11:55 -0700 (PDT) Sender: J Chris Anderson Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: replication users From: J Chris Anderson In-Reply-To: <4C6E8DDD.2080907@lechat.org> Date: Fri, 20 Aug 2010 11:11:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FACADD3-496D-4D4B-AD5E-DDBE7366CD51@apache.org> References: <4C6E8DDD.2080907@lechat.org> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1081) On Aug 20, 2010, at 7:14 AM, zecat wrote: > Hi everyone, >=20 > I'm very interested to get any information on this topic too, and in = security replication in general. > I plan to deploy several couchdb instance, and I plan to implement = different users and roles to use on this cloud. > I think, I don't understand very well the user/role and replication = mechanism. I tried different configuration. > As far as I understand, the _users databases can be replicated, but = not the user and role assigned on another database. Yes, this is true. Replicating the _users database is totally fine (note = that the replicator must have admin privileges on the target database, = or else on the currently logged in user's document will be replicated.) > Example : > - I created a tesdb on couchdb1 > - I applied a security setting (with Futon ) to define some admins and = readers names/roles , > - I defined a replica of testb on couchdb2 > - I launched a replication job between couchdb1/testdb and = couchdb2/testdb. > But it seems there is no security replicated from couchdb1/testdb to = couchdb2/testdb. >=20 The security configuration object is not replicated. This is by design, = as one replica may be on an end-user machine, and another on shared = cloud instance, necessitating different rules. > Is it normal ? Does it could be a great security feature to assist = replication of the security setting for a replication database in a = cloud ? >=20 > Maybe I'm completly wrong on this subject ? >=20 > Other question about multiple couchdb instance and replication : > When (for perf, or LB, or HA purpose) you need more than 2 couchdb = replica of the same database, what is supposed to be the more efficent = architecture ? > - Something in ring style : A>B>C>A > - Same with a dual reverse replication scheme ? A>B>C>A, A>C>B>A > - Or a grap cluster style A>B, A>C, B>A, C>A > - Or a n^2 dual replica with every possible peer db ? A>B, A>C, B>A, = B>C, C>A, C>B >=20 > I'd appreciate any comment on this ! >=20 > Thanks, >=20 > Thierry. >=20 >=20 >=20 > Le 19/08/2010 16:21, Nathan Stott a =E9crit : >> Are there any special considerations when replicating the _users >> database as opposed to normal databases? Is this a good way to share >> users between servers that should share users and trust one another? >> =20