You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Matt Goodall <ma...@gmail.com> on 2010/02/22 09:32:50 UTC
First admin user is not created in _users db
Hi,
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.
- Matt
Re: First admin user is not created in _users db
Posted by J Chris Anderson <jc...@gmail.com>.
On Feb 23, 2010, at 12:34 AM, Andrew Straw wrote:
>
> 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 should note that this is intentional. Roles beginning with _ are not permitted in the users db. The _admin role is assigned based on configuration data. It's still handy to have a user doc for admins, in cases where the admin user should have other roles as well, or for when applications want to store data on the user document.
Chris
> -Andrew
Re: First admin user is not created in _users db
Posted by Andrew Straw <st...@astraw.com>.
Matt Goodall wrote:
> On 23 February 2010 08:34, Andrew Straw <st...@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 <ma...@gmail.com> wrote:
>>>> On 22 February 2010 11:43, Matt Goodall <ma...@gmail.com> wrote:
>>>> On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
>>>> On 22 February 2010 10:53, Brian Candler <B....@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
Re: First admin user is not created in _users db
Posted by Matt Goodall <ma...@gmail.com>.
On 23 February 2010 08:34, Andrew Straw <st...@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 <ma...@gmail.com> wrote:
> >> On 22 February 2010 11:43, Matt Goodall <ma...@gmail.com> wrote:
> >> On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
> >> On 22 February 2010 10:53, Brian Candler <B....@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.
- Matt
Re: First admin user is not created in _users db
Posted by Andrew Straw <st...@astraw.com>.
J Chris Anderson wrote:
> On Feb 22, 2010, at 8:06 AM, Matt Goodall wrote:
>
>
>> On 22 February 2010 12:06, Matt Goodall <ma...@gmail.com> wrote:
>> On 22 February 2010 11:43, Matt Goodall <ma...@gmail.com> wrote:
>> On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
>> On 22 February 2010 10:53, Brian Candler <B....@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
Re: First admin user is not created in _users db
Posted by J Chris Anderson <jc...@gmail.com>.
On Feb 22, 2010, at 8:06 AM, Matt Goodall wrote:
> On 22 February 2010 12:06, Matt Goodall <ma...@gmail.com> wrote:
> On 22 February 2010 11:43, Matt Goodall <ma...@gmail.com> wrote:
> On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
> On 22 February 2010 10:53, Brian Candler <B....@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.
Chris
> - Matt
>
>
> Just for extra information, on a faster machine I've not seen it fail yet and on a slower machine I've not seen it succeed. Like I said, that's a speculative conclusion based on the playing I've done here.
>
> - Matt
>
>
> <futon-createAdmin-race.diff>
Re: First admin user is not created in _users db
Posted by Matt Goodall <ma...@gmail.com>.
On 22 February 2010 12:06, Matt Goodall <ma...@gmail.com> wrote:
> On 22 February 2010 11:43, Matt Goodall <ma...@gmail.com> wrote:
>
>> On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
>>
>>> On 22 February 2010 10:53, Brian Candler <B....@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
>
> Just for extra information, on a faster machine I've not seen it fail yet
> and on a slower machine I've not seen it succeed. Like I said, that's a
> speculative conclusion based on the playing I've done here.
>
> - Matt
>
>
Re: First admin user is not created in _users db
Posted by Matt Goodall <ma...@gmail.com>.
On 22 February 2010 11:43, Matt Goodall <ma...@gmail.com> wrote:
> On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
>
>> On 22 February 2010 10:53, Brian Candler <B....@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.
Just for extra information, on a faster machine I've not seen it fail yet
and on a slower machine I've not seen it succeed. Like I said, that's a
speculative conclusion based on the playing I've done here.
- Matt
Re: First admin user is not created in _users db
Posted by Matt Goodall <ma...@gmail.com>.
On 22 February 2010 11:28, Matt Goodall <ma...@gmail.com> wrote:
> On 22 February 2010 10:53, Brian Candler <B....@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).
- Matt
Re: First admin user is not created in _users db
Posted by Matt Goodall <ma...@gmail.com>.
On 22 February 2010 10:53, Brian Candler <B....@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.
- Matt
Re: First admin user is not created in _users db
Posted by Brian Candler <B....@pobox.com>.
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.