On 17/07/14 05:49, John Meinel wrote:
Michael is working on changing how we handle sessions with Mongo, and
noticed that his first attempt started running into Auth failures.
It turned out that this was because of the hash(password) dance. (For
those who don't know, in certain circumstances we used to seed the
password for the database with the hash(password) and then once we had
a secure channel we would replace it with the real password.)
I believe all of our production bootstrap code has gotten rid of the
password dance, because we now just use cloud-init to bring up a
machine and then SSH into that machine to finish provisioning. Thus
all the information is already over the secure SSH channel, instead of
the insecure cloud-init user data.
From what I can tell poking around the code base, the only place that
still uses the hash(password) is actually in the Dummy provider.
Right, and when I remove that code all the tests pass with some session
copying in place!
https://github.com/voidspace/juju/compare/master...copy-sessions
I feel like we're at a point where we can safely remove that from the
Dummy provider, and also remove the fallback code in our 'connect to
the database' code. (If we leave it in, then I think after
Do you mean the "oldPassword" logic in cmd/jujud/agent.go (I had to add
code there to re-open the state when we change the password.)
All the best,
Michael
changing the password just reconnecting to the database is fine,
because it should happen infrequently.
Thoughts?
John
=:->
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
