couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: 2.1 config files
Date Thu, 05 Oct 2017 22:53:58 GMT
This is all documented here:

What you're experiencing is expected, given the override that you are

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.

----- Original Message -----
From: "Peter Sagerson" <>
Sent: Thursday, 5 October, 2017 6:30:08 PM
Subject: 2.1 config files


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?


View raw message