You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Cliff Stanford <cl...@may.be> on 2010/04/07 11:58:07 UTC

New install feedback

Not sure if this is useful feedback or not.  I have just done a new 
install of CouchDB 0.11 on Fedora 11.  This was done from the svn 0.11 
branch:

./bootstrap
./configure
make
sudo make install

First problem was that no couchdb user was installed and couch's 
directories were owned by root 0755.

I then ran the test suite and got the following:

----------------------------------------------------------
delayed_commits

    1. Assertion failed: db.open("3") == null

reader_acl

    1. Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
    2. Assertion failed: CouchDB.session().userCtx.name == 
"jchris@apache.org"
    3. Assertion failed: false && "can't open a doc from a secret db"
    4. Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
    5. Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
    6. Assertion failed: 
CouchDB.session().userCtx.roles.indexOf("_admin") == -1

stats

    1. Assertion 'triggered, "We managed to force a all_dbs_active 
error."' failed: We managed to force a all_dbs_active error.
----------------------------------------------------------

Rerunning the test suite reproduced all but the first problem.

I then changed the ownership on /usr/local/etc/couchdb and its contents 
to the couchdb user.

Only the stats test failed.  The test suite appears to add a 
[couch_httpd_auth] section with a random secret to local.ini, and leave 
it there.

FWIW, it also left a load of databases there that needed cleaning up.

Regards,
Cliff.

-- 
Cliff Stanford
Might Limited                           +44 845 0045 666 (Office)
Suite 67, Dorset House                  +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB

Re: New install feedback

Posted by Jan Lehnardt <ja...@apache.org>.
Hi Cliff,

thanks for sending your feedback. I'l reply inline.

On 7 Apr 2010, at 11:58, Cliff Stanford wrote:

> Not sure if this is useful feedback or not.  I have just done a new install of CouchDB 0.11 on Fedora 11.  This was done from the svn 0.11 branch:
> 
> ./bootstrap
> ./configure
> make
> sudo make install
> 
> First problem was that no couchdb user was installed and couch's directories were owned by root 0755.

make install doesn't create a couchdb user. See the INSTALL.Unix file for a complete set of instructions.


> I then ran the test suite and got the following:
> 
> ----------------------------------------------------------
> delayed_commits
> 
>   1. Assertion failed: db.open("3") == null
> 
> reader_acl
> 
>   1. Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
>   2. Assertion failed: CouchDB.session().userCtx.name == "jchris@apache.org"
>   3. Assertion failed: false && "can't open a doc from a secret db"
>   4. Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
>   5. Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
>   6. Assertion failed: CouchDB.session().userCtx.roles.indexOf("_admin") == -1
> 
> stats
> 
>   1. Assertion 'triggered, "We managed to force a all_dbs_active error."' failed: We managed to force a all_dbs_active error.
> ----------------------------------------------------------
> 
> Rerunning the test suite reproduced all but the first problem.

The test suite isn't as robust as it could be. You should see that if you run the failing tests in isolation, they will succeed eventually. We're working on improving that. In fact, trunk should already be in better shape.

> I then changed the ownership on /usr/local/etc/couchdb and its contents to the couchdb user.
> 
> Only the stats test failed.


> The test suite appears to add a [couch_httpd_auth] section with a random secret to local.ini, and leave it there.

We might want to clean that up. Do you mind opening a ticket for this on https://issues.apache.org/jira/browse/COUCHDB?


> FWIW, it also left a load of databases there that needed cleaning up.

This is intentional, so you can inspect the state of the databases that resulted in a failing test.

Cheers
Jan
--