couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Shorin (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2390) Fauxton config, admin sections considered dangerous in 2.0
Date Mon, 17 Nov 2014 22:27:34 GMT


Alexander Shorin commented on COUCHDB-2390:

My opinion is that anyone setting up a cluster should copy the same config file (or [admins]
section) to all nodes. Anyone half serious should be using some kind of puppet/chef/ansible
tool for that anyway, and any learning hobbyist can very well go in and edit the file themselves
by hand. The nodes need to share the same erlang cookie anyway, so why not the [admins] section

Assume you have cluster and a few nodes. Following your proposal all nodes in cluster must
have the same config file. Ok. But this isn't true for those few nodes. Now you what to add
these nodes to cluster. What's happens now? Should CouchDB reject their addition because their
config files are different? Should CouchDB rewrite their config with cluster one causing configuration
lost? What happens if some node config becomes changed via backdoor iface? Is that node gets
out of cluster? How to keep nodes configs in sync then?

> Fauxton config, admin sections considered dangerous in 2.0
> ----------------------------------------------------------
>                 Key: COUCHDB-2390
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: BigCouch, Fauxton
>            Reporter: Joan Touzet
>            Priority: Blocker
> In Fauxton today, there is are 2 sections to edit config-file settings and to create
new admins. Neither of these sections will work as intended in a clustered setup.
> Any Fauxton session will necessarily be speaking to a single machine. The config APIs
and admin user info as exposed will only add that information to a single node's .ini file.
> We should hide these features in Fauxton for now (short-term fix) and correct the config
/admin creation APIs to work correctly in a clustered setup (medium-term fix).

This message was sent by Atlassian JIRA

View raw message