To expand on that a little, I'd advise you use Salt to build your default.ini completely, there are a few sections you need to consider beyond the obvious ones like database_dir;
1) [admins] As noted already, you should populate this yourself. I would go as far are precomputing the hashed output form. Do this before couchdb is even started for the first time. 2) [couchdb] uuid This is a little misleading (it's my fault, actually). What you want for a 2.0 _cluster_ is that all nodes in the cluster have the _same_ uuid. This value is used in finding replication checkpoint documents, so not controlling it (a random one is created if not set) means replication can be less efficient as each node will have a different idea of where to look for a replication checkpoint. 3) [couch_httpd_auth] secret This value is used to protect the session cookies. Similar to item 2, you want the _same_ secret value on all nodes. Not doing so means a cookie issued from one node will not be considered valid by another. Obviously make it a long randomly-generated value. Changing it will invalidate all session cookies (after node restarts). Finally, note that changing the config on disk does _not_ affect the runtime settings. For that, you need PUT's or DELETE's against the _config endpoint. In couchdb 2.0 this moved to /_node/<name of node here>/_config as configuration is at the node level. B. > On 22 Feb 2017, at 09:21, Dan Ballance <[email protected]> wrote: > > Okay brilliant, yes we are currently only using a single node. I'll take a > look through this now - it looks like exactly what I need. Thank you! > > On Wed, Feb 22, 2017 at 9:17 AM Daniel Munch <[email protected]> wrote: > >> Hi Dan, >> >> in case you're talking about a single-node setup I agree, the >> documentation isn't very clear on that. I recently submitted a pull >> request which should make it more clear, but apparently it didn't make >> it to the site yet: >> >> https://github.com/apache/couchdb-documentation/pull/94/files?short_path=31ac1c6#diff-31ac1c6a7e05dc83bededf911e5b4807 >> >> So in a nutshell: >> For a single-node setup, instead of using the wizard, you can also >> manually configure an admin user in the config file like explained in >> http://docs.couchdb.org/en/2.0.0/config/auth.html#server-administrators >> >> Afterwards you have to create the three system databases _users, >> _replicator and _global_changes like explained in the doc. This is >> equivalent to the setup wizard and can be carried out form the command >> line. >> >> Best, >> Daniel >> >> On Wed, Feb 22, 2017 at 9:53 AM, Dan Ballance <[email protected]> >> wrote: >>> Hi folks, >>> >>> We've started using CouchDB recently and decided to start with your 2.0 >>> release. We're really loving the platform so far. We are trying to deploy >>> CouchDB 2.0 with a configuration management application called Salt. I >> have >>> a working configuration that does 99% of the install - although there >>> appear to be a couple of final steps that need to be performed in a web >>> browser which is not ideal from a config management PoV. >>> >>> So here are the final steps I have - please correct me if I am not doing >>> this right. I saw an error in my logs which Googling brought me to this >>> Hacker News thread: >>> >>> https://news.ycombinator.com/item?id=12545569 >>> >>> The technique proposed seems to work fine. I go to >>> http://hostname:5984/_utils, create an admin account and then proceed to >>> the single server setup which completes the installation of the necessary >>> database tables. So my question is: >>> >>> Is there any way to set up the admin account and trigger the database >>> tables to be created without an administrator visiting the server in a >> web >>> browser? >>> >>> many thanks in advance for your valuable time, >>> >>> Dan Ballance. >>
