> On 17 Apr 2016, at 16:43, Paul Hammant <p...@hammant.org> wrote: > > I wasn't being snide, or insulting
I’m glad to hear that you didn’t mean to be snide. > 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. I’m not claiming anything, I’m just telling you how this reads to me. Best Jan -- > > - Paul > > On Sun, Apr 17, 2016 at 8:24 AM, Jan Lehnardt <j...@apache.org> wrote: > >> >>> On 17 Apr 2016, at 05:09, Paul Hammant <p...@hammant.org> 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 >> >> >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
