On Wed, Aug 17, 2011 at 8:24 PM, Noah Slater <nsla...@apache.org> wrote: > > On 17 Aug 2011, at 02:04, Jason Smith wrote: > >> 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. > > Just to clear up the ad hominem before I continue. Most of your arguments are > directed comments I have made. But of course, I built the original system, > and used my experience as a Debian developer to inform my decisions about > best practice. I've also been a sysadmin for a number of companies, and in > fact, I have never used ./utils/run for anything, so…
Sorry, I'll cut that out on the dev@ list. While I addressed many of your points later on, the motivation to chime in came directly from Randall's post. Out of the blue comes discussion of couchctl, and password management tools, and config file convention-over-configuration. My feeling is make configuration simpler than it is today. Looks like you and I are in broad agreement on the details. Thanks for the feedback! >> 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! > > The argument was that if daemon configuration lives inside the daemon, and > you mess it up, then you wont be able to run the daemon to edit the daemon > configuration. As long as there is a separation of concerns, this shouldn't > be a problem. You shouldn't be able to hose you CouchDB installation through > the configuration options hosted within CouchDB. Think of it in terms of a > managed hosting environment. As the service provider, you want to be able to > let your customers configure users and permissions and URL handlers, etc. But > you don't, necessarily, want them to be messing about with the daemon options. I have no difficulties thinking of it in terms of a managed hosting environment :) and I wrote config_whitelist because users were changing their listen address and port, taking their couches offline. Totally agree. >> 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. > > Why is it quirky? The .ini file that edits itself. There are probably some servers out there which do that, but as you know, sysadmins expect /etc files to stay put! Many use CVS to manage them, as you noted. Hence, I like the generated.ini idea because as a sysadmin, during peacetime (couch is running fine) it is just an opaque file blob I need to back up. During wartime (couch is crashed/misconfigured), I can dig into it with emacs and troubleshoot. -- Iris Couch
