couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Ballance <tzewang.do...@gmail.com>
Subject Re: Command line only install of 2.0 (Linux)
Date Mon, 27 Feb 2017 08:19:19 GMT
That's brilliant, thanks ever so much the additional information. I am
building a local.ini in Salt to override the default settings in
default.ini. I should have a fully automated build working by the end of
today. Hopefully I won't need any further help, but if I do hit any related
issues I will reply in this thread.

Thanks again for your help guys; great support on this list. The project
feels very active and alive which is great when you are committing to a
platform :)

Dan

On Sun, Feb 26, 2017 at 4:07 PM Robert Samuel Newson <rnewson@apache.org>
wrote:

> To expand on that a little, I'd advise you use Salt to build your
> default.ini completely, there are a few sections you need to consider
> beyond the obvious ones like database_dir;
>
> 1) [admins]
>
> As noted already, you should populate this yourself. I would go as far are
> precomputing the hashed output form. Do this before couchdb is even
> started  for the first time.
>
> 2) [couchdb] uuid
>
> This is a little misleading (it's my fault, actually). What you want for a
> 2.0 _cluster_ is that all nodes in the cluster have the _same_ uuid. This
> value is used in finding replication checkpoint documents, so not
> controlling it (a random one is created if not set) means replication can
> be less efficient as each node will have a different idea of where to look
> for a replication checkpoint.
>
> 3) [couch_httpd_auth] secret
>
> This value is used to protect the session cookies. Similar to item 2, you
> want the _same_ secret value on all nodes. Not doing so means a cookie
> issued from one node will not be considered valid by another. Obviously
> make it a long randomly-generated value. Changing it will invalidate all
> session cookies (after node restarts).
>
> Finally, note that changing the config on disk does _not_ affect the
> runtime settings. For that, you need PUT's or DELETE's against the _config
> endpoint. In couchdb 2.0 this moved to /_node/<name of node here>/_config
> as configuration is at the node level.
>
> B.
>
>
> > On 22 Feb 2017, at 09:21, Dan Ballance <tzewang.dorje@gmail.com> wrote:
> >
> > Okay brilliant, yes we are currently only using a single node. I'll take
> a
> > look through this now - it looks like exactly what I need. Thank you!
> >
> > On Wed, Feb 22, 2017 at 9:17 AM Daniel Munch <dani.munch@gmail.com>
> wrote:
> >
> >> Hi Dan,
> >>
> >> in case you're talking about a single-node setup I agree, the
> >> documentation isn't very clear on that. I recently submitted a pull
> >> request which should make it more clear, but apparently it didn't make
> >> it to the site yet:
> >>
> >>
> https://github.com/apache/couchdb-documentation/pull/94/files?short_path=31ac1c6#diff-31ac1c6a7e05dc83bededf911e5b4807
> >>
> >> So in a nutshell:
> >> For a single-node setup, instead of using the wizard, you can also
> >> manually configure an admin user in the config file like explained in
> >> http://docs.couchdb.org/en/2.0.0/config/auth.html#server-administrators
> >>
> >> Afterwards you have to create the three system databases _users,
> >> _replicator and _global_changes like explained in the doc. This is
> >> equivalent to the setup wizard and can be carried out form the command
> >> line.
> >>
> >> Best,
> >> Daniel
> >>
> >> On Wed, Feb 22, 2017 at 9:53 AM, Dan Ballance <tzewang.dorje@gmail.com>
> >> wrote:
> >>> Hi folks,
> >>>
> >>> We've started using CouchDB recently and decided to start with your 2.0
> >>> release. We're really loving the platform so far. We are trying to
> deploy
> >>> CouchDB 2.0 with a configuration management application called Salt. I
> >> have
> >>> a working configuration that does 99% of the install - although there
> >>> appear to be a couple of final steps that need to be performed in a web
> >>> browser which is not ideal from a config management PoV.
> >>>
> >>> So here are the final steps I have - please correct me if I am not
> doing
> >>> this right. I saw an error in my logs which Googling brought me to this
> >>> Hacker News thread:
> >>>
> >>> https://news.ycombinator.com/item?id=12545569
> >>>
> >>> The technique proposed seems to work fine. I go to
> >>> http://hostname:5984/_utils, create an admin account and then proceed
> to
> >>> the single server setup which completes the installation of the
> necessary
> >>> database tables. So my question is:
> >>>
> >>> Is there any way to set up the admin account and trigger the database
> >>> tables to be created without an administrator visiting the server in a
> >> web
> >>> browser?
> >>>
> >>> many thanks in advance for your valuable time,
> >>>
> >>> Dan Ballance.
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message