Yup, that's the document I was referring to, thanks for the confirmation. I suppose it's just disorienting to have the model part ways with several conventions--FHS/hier, foo.d directories being implicitly or explicitly bound to parent configs, a clear distinction between static and dynamic configuration. I believe the documentation promises a more traditional configure/make system in a future release, so perhaps the situation is still in flux.
As surprising as an auto-mutating etc is, I agree that it shouldn't be hard to converge on a stable configuration state in the short term. Mostly it just has that feel of something high on the "most likely to create chaos in the future" list. To be safe, I reckon I'll at least want to disable access to the config-mutating APIs. Or maybe hook them up to the Benny Hill theme. Thanks for the quick reply, Peter > On Oct 5, 2017, at 3:53 PM, Joan Touzet <[email protected]> wrote: > > This is all documented here: > > http://docs.couchdb.org/en/2.1.0/config/intro.html > > What you're experiencing is expected, given the override that you are > using. > > CouchDB abandoned the "install into FHS" Linux approach with the 2.x > series when we started embedding the version of Erlang that we use into > the release artefact that we build. > > This is why all of the packages released to date install to the > /opt/couchdb directory. > > The best approach to managing CouchDB ini files when using a CD system > (Salt, Ansible, Chef, Puppet) is to ensure that CouchDB doesn't need > to rewrite any of the files when it starts up. This includes not using > the /_node/<nodename>/_config endpoint, pre-seeding the correct server > uuid and hashed passwords into the .ini file you drop on a system, etc. > Done correctly, Couch will never have to write to an .ini file under > normal operation. I've seen this successful in deployment with all of > the above toolsets. > > -Joan > > ----- Original Message ----- > From: "Peter Sagerson" <[email protected]> > To: [email protected] > Sent: Thursday, 5 October, 2017 6:30:08 PM > Subject: 2.1 config files > > Hello, > > I'm trying to get CouchDB 2.1 running on a FreeBSD server. As the 2.x series > has not yet made it into ports, I'm just building it manually for the time > being. I can mostly get it running this way, but integrating it into the > system in a sensible way has not been very relaxing thus far. > > The first thing I'd like to do is move the config files under /usr/local/etc > where they belong. The documentation explains the use of -couch_ini, which > works as far as it goes, but when I do that, it appears that default.d and > local.d are not included. Is that expected? Is there a way to relocate these > as well? > > Since I'm not (yet) trying to manhandle CouchDB into a package manager, I > could just ignore this, but for one other quirk: couchdb likes to modify > local.ini! Or sometimes one of the files in local.d, if I'm using the default > config location. Does it pick a random local config file? Last in a lexical > ordering? It's not clear. In any case, this is pretty disastrous for any > system managed by deployment automation (e.g. SaltStack), as the two will be > stepping all over each other. Is there a principled way to maintain an > unambiguous distinction between files that I manage and files that couchdb > manages? > > Thanks, > Peter
