J Chris Anderson wrote:
> On Feb 22, 2010, at 8:06 AM, Matt Goodall wrote:
>
>   
>> On 22 February 2010 12:06, Matt Goodall <[email protected]> wrote:
>> On 22 February 2010 11:43, Matt Goodall <[email protected]> wrote:
>> On 22 February 2010 11:28, Matt Goodall <[email protected]> wrote:
>> On 22 February 2010 10:53, Brian Candler <[email protected]> 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

Reply via email to