To be clear, is the suggestion that this script simply be a wrapper around updating the password via CouchDB's HTTP API? Having gone back and forth on this thread for the past few days, I think it makes sense to keep user info in CouchDB, and not in the ini files. If a user manages to lock themselves out of the server, they can start it with --admin-party and disable the auth system while they fix things up.
On 17 Aug 2011, at 17:09, Robert Newson wrote: > It's also the sort of thing one would expect in a Debian postinst via Dialog. > > B. > > On 17 August 2011 17:04, Benoit Chesneau <[email protected]> wrote: >> On Wednesday, August 17, 2011, Jason Smith <[email protected]> wrote: >>> On Wed, Aug 17, 2011 at 10:22 PM, Robert Newson <[email protected]> >> wrote: >>>> Jason, >>>> >>>> The --set-password thing is to ensure there are no plaintext passwords >>>> in the first place, which eliminates the oddness of couch rewriting a >>>> plaintext pwd to a digested pwd (and putting the output in a different >>>> file). >>> >>> Thanks for the clarification. >>> >>> If you can read a plaintext password from an .ini file, then you can >>> hit the HTTP API as the admin and make changes to the couch. So that >>> is privilege escalation. >>> >>> To answer Benoit's question, it is simpler to tell admins to use the >>> HTTP API (or Futon) to create the admin account. The password is >>> stored *somewhere* under the hood. IMHO it is less simple to add a >>> command-line tool as a requirement (or worse, as an alternative >>> option) to deploy Couch. >>> >>> -- >> it all depends if you admin via a console. >> >> couchctl set-password username is a way easier than curl -XPUT >> http://blah/_users -D... -H... . at the end if you are a good admin you >> will write this script. providing useful helpere don't break the kiss way >> here. >> >> benoît >>
