couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Straw <straw...@astraw.com>
Subject Re: First admin user is not created in _users db
Date Tue, 23 Feb 2010 08:34:43 GMT
J Chris Anderson wrote:
> On Feb 22, 2010, at 8:06 AM, Matt Goodall wrote:
>
>   
>> On 22 February 2010 12:06, Matt Goodall <matt.goodall@gmail.com> wrote:
>> On 22 February 2010 11:43, Matt Goodall <matt.goodall@gmail.com> wrote:
>> On 22 February 2010 11:28, Matt Goodall <matt.goodall@gmail.com> wrote:
>> On 22 February 2010 10:53, Brian Candler <B.Candler@pobox.com> wrote:
>> On Mon, Feb 22, 2010 at 08:32:50AM +0000, Matt Goodall wrote:
>>     
>>> Before 0.11 gets released ... after creating the first admin user in a
>>> completely fresh install of the 0.11.x branch I see a _users database
>>> containing only design doc, i.e. no doc for the new user. Subsequent admin
>>> users do get added the the _users db.
>>>       
>> Is the first admin user created in local.ini then?
>>
>> I thought *all* admin users ended up created in local.ini. At least, when I
>> created two admins via futon, I got them both in local.ini. But I haven't
>> tested this for a week or so.
>>
>> The first admin user added to in local.ini but not in the _users database.
>>
>> Subsequent admin users are added to local.ini and the _users database.
>>
>> OK, I seem to be getting different behaviour on different machines. Let me look into
it more first, perhaps I didn't install something correctly (although I tried multiple times
and just did the same on a new machine).
>>
>> Looks like a timing problem. Gut feeling says the slower machine the more likely
it is to occur but that's entirely speculative.
>>
>> So, when it work I see the following in the couchdb log:
>>
>> [info] [<0.101.0>] 127.0.0.1 - - 'PUT' /_config/admins/matt 200
>> [info] [<0.100.0>] 127.0.0.1 - - 'GET' /_session 200
>> [info] [<0.101.0>] 127.0.0.1 - - 'POST' /_session 200
>> [info] [<0.101.0>] 127.0.0.1 - - 'GET' /_session 200
>> [info] [<0.100.0>] 127.0.0.1 - - 'PUT' /_users/org.couchdb.user%3Amatt 201
>>
>> And when it fails I see:
>>
>> [info] [<0.105.0>] 127.0.0.1 - - 'PUT' /_config/admins/matt 200
>> [info] [<0.95.0>] 127.0.0.1 - - 'GET' /_session 200
>> [info] [<0.95.0>] 127.0.0.1 - - 'PUT' /_users/org.couchdb.user%3Amatt 409
>> [info] [<0.105.0>] 127.0.0.1 - - 'POST' /_session 200
>> [info] [<0.105.0>] 127.0.0.1 - - 'GET' /_session 200
>>
>> Both of those were run on the same machine with a completely fresh couchdb install
(deleted between runs) and a newly opened chromium "incognito" window to avoid browser caching
between sessions.
>>
>> It looks like there's two concurrent async requests and it just depends on which
one completes first ... but I haven't looked at the JS code to prove that.
>>
>> Yep, Futon's createAdmin is calling doLogin and doSignup in sequence, both of which
are async. doSignup can only happen once doLogin has completed successfully.
>>
>> Attached is a patch (git diff against 0.11.x branch) that chains the two calls. Works
consistently and correctly for me now. Hope it looks ok, feel free to reformat as necessary.

>>
>> Sorry Noah, but I think getting this fix in is a showstopper for the 0.11 release.
>>
>>     
>
> Matt,
>
> Thanks for the investigation and patch. It's pretty much always worked for me over here,
so I didn't realize it was an issue. 
>
> I've committed (and am backporting) the patch. I think this is trivial enough that it
doesn't need to go through Jira, but I've added you to the thanks file.

I'm still getting Matt's initial problem, despite using the patched
0.11.x branch. Following his same procedure (fresh install of CouchDB,
using Chromium incognito window), I see this:

[info] [<0.129.0>] 127.0.0.1 - - 'PUT' /_config/admins/astraw 200
[info] [<0.129.0>] 127.0.0.1 - - 'POST' /_session 200
[info] [<0.129.0>] 127.0.0.1 - - 'GET' /_session 200
[info] [<0.129.0>] 127.0.0.1 - - 'GET' /_session 200
[info] [<0.129.0>] 127.0.0.1 - - 'PUT' /_users/org.couchdb.user%3Aastraw 201


But looking at the user doc of the _users db in futon, there's no
"_admin" in the roles field. However, doing a get with curl on _session
shows it. All of this testing is on a speedy local desktop machine
(Ubuntu Karmic amd64).

-Andrew

Mime
View raw message