couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Configuration Load Order
Date Tue, 16 Aug 2011 01:20:20 GMT
On Tue, Aug 16, 2011 at 12:32 AM, Jan Lehnardt <jan@apache.org> wrote:
>
> On Jul 19, 2011, at 5:28 PM, Noah Slater wrote:
>
>>
>> On 19 Jul 2011, at 09:22, Matt Goodall wrote:
>>
>>> This makes sense to me. Personally, I don't think a
>>> generated.ini/generated.d pair is needed - just a single generated.ini would
>>> do.
>>>
>>> As well as ensuring changes are written to the last .ini file in the
>>> configuration chain a generated.ini would act very nicely as a per-instance
>>> configuration for when multiple CouchDB instances are run from the same,
>>> read-only installation, i.e.
>>>
>>>   default.ini/default.d  --  CouchDB default config, system-wide (R)
>>>   local.ini/local.d  --  local sysadmin's config, system-wide (R)
>>>   generated.ini  --  per-instance config (RW)
>>>
>>> As such, I would suggest naming generated.ini something more like
>>> instance.ini.
>>
>> I am +1 on all of this.
>
> This doesn't solve the problem that spawned this discussion:
>
> 1. Write admin = password to local.ini
> 2. Restart CouchDB
> 3. Hash gets persisted to generated.ini
> 4. Plain text password remains in local.ini

That is an excellent point.

IMO (and sysadmins responsible for couches would agree): the .ini
system, especially the automatic editing and overwriting by couch
itself, is brittle or at best confusing. CouchDB's raison d'être is to
store structured data which changes over time. And yet the config is a
totally separate, less mature, less coherent implementation.

You can talk about bootstrapping or human-access or backups, but
wearing my sysadmin hat, I don't care. All I know is the config files
change arbitrarily and incomprehensibly depending on the whims of
CouchDB. (Remember, I wrote the config_whitelist patch in part to
address this.)

Maybe the answer is not in code but in documentation.

Is it possible to deprecate the .ini files as a configuration tool? In
other words, tell the world: "Configure CouchDB over HTTP via the
/_config URLs, probably via Futon."

The .ini files become an irrelevant implementation detail. The fact
that one of them changes is of no concern. Is that possible?

The abstraction is slightly leaky:

1. Sysadmins still have to edit the bootstrapping config, such as the
listen address and port.
2. Sysadmins still have to back-up the .ini files because they do in
fact reflect changes to the config.

But I still think it's a net-win:

1. No changes to the code, just to the mental model of CouchDB
2. Nobody will ever put an admin account in foo.ini, but the hash
shows up in bar.ini

-- 
Iris Couch

Mime
View raw message