On Wed, Sep 24, 2014 at 5:12 PM, Jan Lehnardt <[email protected]> wrote: >>> 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. > > `couchdb` is a shell script that runs before Erlang is booted up, so > there is no race condition.
Aha, so the workflow is: 1. Install couchdb 2. run `couchdb` with some param, set the password 3. start the service right? Not sure that this would be popular feature since it won't work on Windows well, it's hard to automatize in comparison with config file [admins]. On Wed, Sep 24, 2014 at 5:12 PM, Jan Lehnardt <[email protected]> wrote: >>> 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. > > It is not well defined yet, yes, but too much magic? Let’s design it and > decide then :) > > Also what would you do alternatively? Need to think about, but technically all or most part of setup magic could be done on first node addition. I think it's obliviously that if you adds node to other you're going to set up cluster with them. >> Is it the only resource which will verify availability of the node to add? > > Possibly, what other resources would you want to have to expose this > information? /nodes database looks as good host of such feature: if you add node there, it verifies and ensures that it's available and ready for join. Otherwise returns HTTP error back on POST/PUT request. Yes, another system database, but isn't it already such? >> How can I rollback my cluster CouchDB to single node? > > Can you do this today? Is this a feature we want? Don't know about the first and not sure about the second, but for sure that's the case that users will produce and ask about. I don't feel the recommendation "install second instance, replicate the data, delete the first" will be welcome by them (: >> And can I run setup again after that? > > Again unspecified, see above. If something could be done, one day it will be done. Just curious. >> Can I protect my instance from being included into cluster by some other >> node? > > Yes, e.g. don’t give the other node admin creds. Is this enough? I don’t > know. Maybe /_setup is also disabled after the “the cluster is ready” bit was > flipped and you need to disable that that manually again, to get access to > /_setup again. Disabling /_setup may be a solution and for other points, yes. -- ,,,^..^,,,
