Thanks, Simon. Yeah, that is what we did to get our hashed passwords, but it is a bit roundabout, especially when dealing with docker. I think Joan's trick may be the missing piece--I'll have to play with it when I have some time and see if I can package it into a service
On Sun, Jul 23, 2017, 18:33 Simon Keary <[email protected]> wrote: > > Hi Geoff, > > When we were doing the initial setup for the cluster we set up the first > nodes manually and put the password in the file in clear text. As per > normal CouchDB behaviour after we had run CouchDB once the password in the > file was replaced with a hashed version automatically by CouchDB. When we > later created the automation scripts and stored the config files in S3 we > copied across the version of local.ini with the hashed password. > > Cheers, > Simon > > > > > > -----Original Message----- > From: Geoffrey Cox [mailto:[email protected]] > Sent: Friday, 21 July 2017 9:28 PM > To: [email protected] > Subject: Re: Running a CouchDB 2.0 Cluster in Production on AWS with Docker > > Interesting thought, Simon. How do you generate the hashed password in the > initial local.ini file? Do you use a cleat text one and then let the first > CouchDB node hash it? If so, I tried this approach (actually sharing the > local.ini file via EFS) and the drawback I found was that you have to wait > for this first node to complete this process before starting any other > nodes, which I find to sometimes be a little bit of a hindrance when > coordinating the initial start of the nodes; not impossible, but an extra > step indeed. > > On Thu, Jul 20, 2017, 23:12 Simon Keary <[email protected]> > wrote: > > > > > Hi Geoff, > > > > I don't know whether this is relevant for the Docker case but we store > > the local.ini file with the hashed password in S3 for the servers we > > use. When we recreate the servers in our cluster the cloud-init > > scripts copy across the local.ini file with the hashed password in it. > > > > Cheers, > > Simon > > > > > > -----Original Message----- > > From: Joan Touzet [mailto:[email protected]] > > Sent: Friday, 21 July 2017 12:31 PM > > To: [email protected] > > Subject: Re: Running a CouchDB 2.0 Cluster in Production on AWS with > > Docker > > > > Hi Geoff, > > > > I describe one approach in the Chef CouchDB cookbook: > > > > https://github.com/wohali/couchdb-cookbook > > > > "One way is by downloading and extracting CouchDB's source code, > > changing into the dev/ directory, and running the following one-liner, > > replacing MYPASSWORD with your desired password:" > > > > python -c 'import uuid;from pbkdf2 import > > > pbkdf2_hex;password="MYPASSWORD";salt=uuid.uuid4().hex;iterations=10;print("-pbkdf2-{},{},{}".format(pbkdf2_hex(password,salt,iterations,20),salt,iterations))' > > > > -Joan > > > > ----- Original Message ----- > > From: "Geoffrey Cox" <[email protected]> > > To: "user" <[email protected]> > > Sent: Thursday, 20 July, 2017 11:53:13 PM > > Subject: Running a CouchDB 2.0 Cluster in Production on AWS with > > Docker > > > > Hi, > > > > I finally got around to writing a post on how we are running a CouchDB > > 2.0 cluster in production on AWS < > > https://medium.com/@redgeoff/running-a-couchdb-2-0-cluster-in-producti > > on-on-aws-with-docker-50f745d4bdbc > > >. > > I hope this helps others to bootstrap their projects. > > > > For the community, is there a command line tool or a simple command > > line script that can be written to generate the pbkdf2 hash of a > > password given the clear text password and secret? I know you can > > start a CouchDB node with a clear text password in the local.ini file > > and then have it create the hashed value, but this is a bit roundabout. > > > > If you have any feedback, please send it my way. > > > > Thanks! > > > > Geoff > > > > Disclaimer: > > This message contains confidential information and is intended only > > for the individual(s) named. If you are not the named addressee you > > should not disseminate, distribute or copy this email. Please > > immediately delete it and all copies of it from your system, destroy > > any hard copies of it, and notify the sender. Email transmission > > cannot be guaranteed to be secure or error-free as information could > > be intercepted, corrupted, lost, destroyed, arrive late or incomplete, > > or contain viruses. To the maximum extent permitted by law, Immersive > > Technologies Pty. Ltd. does not accept liability for any errors or > > omissions in the contents of this message which arise as a result of > email transmission. > > > > Disclaimer: > This message contains confidential information and is intended only for > the individual(s) named. If you are not the named addressee you should not > disseminate, distribute or copy this email. Please immediately delete it > and all copies of it from your system, destroy any hard copies of it, and > notify the sender. Email transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. To the maximum extent > permitted by law, Immersive Technologies Pty. Ltd. does not accept > liability for any errors or omissions in the contents of this message which > arise as a result of email transmission. >
