I wasn't being snide, or insulting - that's just your perception. If I wanted to write "I find the security system poorly documented, can someone explain this to me" (your suggestion), I would have written it as "I find the documentation of the security could be expanded for newbies, can someone explain this to me" and avoid a reference to "poorly".
I'm an Apache member - 'hammant' - and wouldn't do what you're claiming I'm doing. - Paul On Sun, Apr 17, 2016 at 8:24 AM, Jan Lehnardt <[email protected]> wrote: > > > On 17 Apr 2016, at 05:09, Paul Hammant <[email protected]> wrote: > > > > (Cultural ref: https://en.wikipedia.org/wiki/Considered_harmful) > > > > So AdminParty is fun for there 2 minute "hey this stuff is great" tour of > > CouchDB, but it leaves me (and others) worried that we don't know the 52 > > specialist knowledge things to do to lock down a couch install > completely. > > You know: 443-only, a top-level administrator, sub administrators, > regular > > accounts, different read vs write permissions, etc etc. We can't imagine > > going live with a CouchDB solution without that, and it makes us think we > > should look for other technologies when there is no cohesive 100% > dev-team > > endorsed page on how to close down the party once and for all. Sooooo - > *if > > that page exists, I can't find it*. > > > > Is the comummunity even in agreement - is it changes to default.ini, > local.ini > > (server side), or is it a series of curl statements over the wire (and > why)? > > No need to be snide about this. A “Why are there two ways to configure > CouchDB?” would have sufficed. > > CouchDB has a config system. It is persisted in two .ini files. You can > change settings by editing local.ini and [re]starting CouchDB or without > restarting CouchDB using curl. The latter is rather beneficial in > production > systems that don’t want to incur downtimes. > > Changes done at runtime are stored in local.ini. When you install a newer > version of CouchDB new config variables can appear in default.ini. If the > install procedure finds an existing local.ini it will not replace it, so > local changes (hence the name) survive software upgrades. > > As Bob pointed out, there is a security consideration with ini vs. curl: > > If you were to start a CouchDB instance and then add an administrator via > curl, there is an ever so slight chance that someone else gets there before > you. The exact scenario is somewhat convoluted, so I won’t bore you with > it. > Suffice it to say, creating an admin in local.ini before the first launch > of CouchDB completely avoids said issue. > > * * * > > If you don’t feel confident using CouchDB then I suggest you look for > alternative technology, or ask someone nicely to explain this to you, > but pressuring the dev team with an somewhat insulting email is not > appreciated here. Again, a “I find the security system poorly documented, > can someone explain this to me?” would have been much more productive. > > > Best > Jan > -- > Apache CouchDB PMC Chair > http://couchdb.apache.org/conduct.html > > >
