Hi Jan, Looks good, replied inline.
On Wed, Sep 24, 2014 at 2:35 PM, Jan Lehnardt <[email protected]> wrote: > # Setting up CouchDB 2.0 > > Hey all, since we are getting close to feature completeness, I’d like to > bring up the topic of setting up CouchDB 2.0 solo and as a cluster. Actually, > Bob Newson brought this up on IRC, and we discussed it a bit and I agreed to > write up our current thoughts. As usual, please be generous with your > commentary :) > > Here is what we envision (includes feedback by rnewson, chewbranca and > davisp). This needs to be squared against current implementation > (http://bigcouch.cloudant.com/use), required engineering and security > considerations. > > My main motivation is to make sure that CouchDB 2.0 is as simple to use as > CouchDB 1.0. Because setting up a cluster is intrinsically more complicated > than launching a single node, this isn’t quite possible, but I believe it is > crucial to make this as simple as it can be made. > > The current setup procedure (again, at http://bigcouch.cloudant.com/use) is > not terribly hard, but I think we can do better. > > ## The Setup Procedure > > Here is a preliminary outline of how we thing this could go. It is still very > high-level, but should give you the idea. If you see any technical or > security roadblocks that could make this hard to actually build, please > holler :) > > N. End User Action > - what happens behind the scenes > > 1. User sets up a new CouchDB 2.0 (A), starts it and goes to Faxuton > - `couchdb` prompts for admin user and pass, if none are configured, > rejects startup without I think password MUST be set manually in config file. Otherwise this will be nothing different from Admin Party when there is a race condition: who opens Fauxton first wins. > 2. Fauxton sees that it has no nodes connected to it yet (/nodes db empty or > non existent), so Fauxton shows a cluster setup screen (that we can go back > later as well). > - *handwaving* something about a /_membership endpoint that I don’t know > much about, yet. > 2.1. If the user just wants a single node couch, there is a button “Thanks no > cluster setup needed” and we go directly to step 5. > > 3. User sets up another CouchDB 2.0 (B) and notes its fully qualified domain > name or ip address (fqdn/ip) > - and uses the same admin/pass combo as on node A. > > 4. User goes back to Fauxton on A and adds a node in the (fictitious at this > point) UI and enters node B’s fqdn/ip > - Fauxton posts this info to e.g. /_setup on A, A then checks if the node > fqdn/ip is reachable, if not, returns an error, if yes, it creates the node > doc in /nodes > - The post to /_setup also configures the erlang cookie/shared secret (this > requires code that updates a shared cookie value (could be a UUID, or > readable-secure random password) but results in really nice end-user > friendliness). This enables secure Erlang-level communication that the > cluster needs to do its work, without any end-user interaction. > - a security consideration here is that a node is open to receive a shared > secret via HTTP, someone might be able to hijack an in-setup cluster node, > requiring an admin/pass on node-startup and making the /_setup endpoint > admin-only should mitigate that. > > // Repeat steps 3. and 4. until all nodes are added > > 5. User clicks a “cluster setup done” button and goes back to the regular > Fauxton start page. > - fauxton posts to /_setup with a body that indicates that the setup is > complete and node A creates /_users and /_replicator and whatever else is > needed) in the cluster, to get it into a production-ready state (*waves > hands*) > - this could also flip a bit “cluster setup done” in all nodes, not yet > sure what we’d use this for, though, maybe block all non-fauxton/setup > traffic until setup is done. > > There is some handwaving how the adding-nodes machinery works under the hood, > but I think that can be worked out later. Too much magic is applied for /_setup. Is it the only resource which will verify availability of the node to add? Can I run setup once again right after it is done? How can I rollback my cluster CouchDB to single node? And can I run setup again after that? Can I protect my instance from being included into cluster by some other node? Also, UI-less setup also requires and probably it have to be the base for Fauxton UI workflow. > ## Requirements > > This requires at least a new HTTP endpoint /_setup which needs to be defined > in a little more detail. I might give it a stab later. > > This also requires a start script that knows how to read a username and > password from the command line (for interactive setups) or from a config file > or environment vars (for automated setups). > > This finally requires a Fauxton addition that makes /_setup accessible to > users. > > I think the engineering effort is small enough to warrant the “expense” of > having a really nice user experience for CouchDB 2.0. > > ### A note on admin party > > Admin party has to go. It is the right thing to do to keep a node or a > cluster in a “vulnerable setup state” as short as possible. As outlined > above, a node would not even start with out an admin set up, and creating an > admin user can be made super simple, so it doesn’t inhibit the setup user > experience too much (we’ve done the same thing at Hoodie, and it works really > well). This will also give us some more “doing it right” credibility among > the folks who care about these things (c.f. turning off delayed commits). Wouldn't it cause "false protection" problem? If user need just a database that works for local need without auth headaches forcing him to set some password will make him set something trivial like "123", "qwerty", "god", "sex", "love" etc. Yay, user has admin now, but does such admin protects instance or makes a feel that instance is protected? What if we keep Admin Party as an option, but disabled by default? For sure, only for single node mode. Too complicated? > That’s it so far, what do you think? :) > > Best > Jan > -- > > -- ,,,^..^,,,
