couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Configuration Load Order
Date Wed, 17 Aug 2011 01:04:56 GMT
On Wed, Aug 17, 2011 at 5:03 AM, Randall Leeds <> wrote:
> On Tue, Aug 16, 2011 at 11:33, Jan Lehnardt <> wrote:
>> On Aug 16, 2011, at 8:31 PM, Noah Slater wrote:
>> >
>> > On 16 Aug 2011, at 10:33, Benoit Chesneau wrote:
>> >
>> >> Imo we shouldn't at all provide plaintext passwords. Maybe a safer
>> >> option would be to let the admin create the first one via http or put
>> >> the hash in the a password.ini file manually. If we are enough kind we
>> >> could also provide a couchctl script allowing user management, config
>> >> changes ... ?
>> >
>> > This sounds like a decent proposal. Much like you have to use htpasswd to
>> generate passwords for Apache httpd, we could bundle a script that lets you
>> generate passwords for the CouchDB ini files, and then forbid the use of
>> plaintext. This solves both the technical problem (I think?) and helps us
>> re-enforce better security practices across the board.
>> Agreed.
> Agreed also. We still have a question about load and save order.
> One idea would be to track the .ini file from whence an option came. If an
> option comes from a local.ini or local.d/ file it could be updated in place.
> If it comes from a default.ini or default.d/ file, updates should be placed
> in local.ini. This would make the most sense to me.
> I would also be in favor of enforcing a load order that supports a directory
> structure like:
> local.d/
>  010-stuff.ini
>  020-others.ini

IMHO, this is madness.

The American quip goes: the professor who never even ran for dog
catcher presumes to tell the president how to do his job. Developers
who spend all day in ./utils/run pontificate about good daemon
behavior in an OS or distribution.

(I don't *really* believe this. I know several of you are responsible
for production couches, but that is the flash-bulb image in my mind.)
I don't feel strongly on the matter, just want to share a sysadmin's
perspective. Any of the proposals would be an improvement, so I'm

Some final apologist thoughts:

My proposal is already implemented. Now I say promote HTTP config
(Futon) over .ini files when possible. Integrators, packagers, and
advanced sysadmins can attack the .ini files just as before.

CouchDB stores versioned data, with a powerful validation and audit
tool (potentially, I'm thinking about validate_doc_update and log()).
Now we are invoking use cases of versioning the config, and auditing
it. Wow! My point is not that the config (or some of it) should be in
a database, but that the config should (1) *lose* complexity over
time, not gain it; and (2) be deprecated as an implementation detail,
or just for advanced users.

Config files that change themselves are bizarre and scary. If that's
what we've got, fine, but make it as simple as possible.

Admins, passwords, and non-boostrappy configuration over HTTP seems
more Couch-like, more "of the web," and more relaxed.

Take a MySQL admin, or an admin of Drupal, Wordpress, Moodle, Joomla,
or pretty much any big PHP application. Tell them this: "You have to
get CouchDB up in the first place. So you edit some config files. Once
it's up, you connect with your client/browser. It assumes you are an
admin, and you complete installation over that interface." They would
respond: "Yeah, sure."

I do not buy the "misbehaving Couch" scenario. Firstly, how common is
that? After installation and confirmation, daemons get pretty stable.
If a misconfiguration totally destroys the couch, well, they are still
plain text. As before, load emacs and go for it!

Finally, I am basically happy with the Couch config. It's quirky but
not too bad. I only hope to share a fresh perspective: the viewpoint
of people for whom couch is just another daemon, like MySQL or httpd
or cron.

Iris Couch

View raw message