On Tue, Aug 16, 2011 at 12:32 AM, Jan Lehnardt <j...@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
