On 24 Sep 2014, at 15:39 , Alexander Shorin <[email protected]> wrote:
> 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 in 1.x land, we already have a shell script (unix and win) `couchdb` that does everything to start beam(.smp). That same script now also needs to capture admin creds. There is no change to how it works today. > 3. start the service This is implied in 3. > 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]. This is not to the exclusion of the existing methods, just an addition to force an admin user set up on first start. Something which we are still openly discussing at this point, but I don’t see a technical reason, to not have it. The automation is covered by accepting a config file, or env vars, or updating local.ini from your automation tools. > > > 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? /nodes is already how BigCouch does this. all /_setup would do is PUT a new doc in othernode:5984/nodes to set things up, as you would do manually. The only reason it needs to go through an endpoint is cross domain limitations. > > >>> 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 (: sure, we need to think more things through, but that’s a little bit outside the initial setup discussion. Of course we need to make it so all cases are covered eventually, but we’d have to do this regardless :) Best Jan -- > >>> 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. > > -- > ,,,^..^,,,
signature.asc
Description: Message signed with OpenPGP using GPGMail
