On Wed, Aug 17, 2011 at 5:03 AM, Randall Leeds <randall.le...@gmail.com> wrote: > On Tue, Aug 16, 2011 at 11:33, Jan Lehnardt <j...@apache.org> 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 net-happy. 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
