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
