That's brilliant, thanks ever so much the additional information. I am building a local.ini in Salt to override the default settings in default.ini. I should have a fully automated build working by the end of today. Hopefully I won't need any further help, but if I do hit any related issues I will reply in this thread.
Thanks again for your help guys; great support on this list. The project feels very active and alive which is great when you are committing to a platform :) Dan On Sun, Feb 26, 2017 at 4:07 PM Robert Samuel Newson <[email protected]> wrote: > 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. > >> > >
