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 12:41:14 GMT
Matt Goodall wrote:
> On 23 February 2010 08:34, Andrew Straw <strawman@astraw.com> wrote:
>
>   
>> 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).
>>
>>
>>     
>  I don't think this is the same problem. Your astraw user doc is getting
> created, it's just not got the role you expected.
>
> If you look in your etc/couchdb/local.ini you should see astraw in the
> [admins] section. I believe that implicitly adds the _admin role for the
> user.
>   
Indeed, you're right -- the user doc is created. Sorry for the noise.

-Andrew

Mime
View raw message