Make Erlang cookie parametric

[pgj]

When linked to CouchDB nodes, the Erlang cookie might be different from the one that is originally assumed. Make it work with ~/.erlang.cookie on launching the instance to facilitate smoother integration.

[rnewson]

history: in couchdb we recently prohibited the value monster for security reasons (many users left this value in place and their installs were exploited as a consequence). We did not follow through with how the dev launch for clouseau works.

Like dev/run in couchdb I suggest we follow this strategy;

1) we default to not explicitly setting the cookie, and let clouseau read the ~/.erlang.cookie file instead (same as dev/run) 2) Optionally you can specify the cookie, in which case the user is responsible for setting the same value for couchdb as for clouseau.

Implied in this is that the word monster will no longer appear in pom.xml.

[pgj]

How can clouseau read the ~/.erlang.cookie file? Does this happen when the clouseau.cookie variable is not set?

[pgj]

Hrm, this does not seem to be the case. Do you think I should the change Scala code to get the default value for the cookie from ~/.erlang.cookie?

[rnewson]

I'm thinking of https://github.com/cloudant/scalang/blob/894bd33fc563b54c455fd78ae6ca72a2d2d25811/src/main/scala/scalang/Node.scala#L68

[pgj]

I'm thinking of https://github.com/cloudant/scalang/blob/894bd33fc563b54c455fd78ae6ca72a2d2d25811/src/main/scala/scalang/Node.scala#L68

Looks like the referenced functionality only kicks in when the cookie parameter is not passed along with the NodeConfig but that latter is Clouseau-specific and cannot be omitted.

[pgj]

@rnewson do you have any comments or requests on the proposed changes? How do you like them?

[pgj]

When I was looking at the scalang repository I had the impression that it is not actively maintained (the latest commit is from 9 years ago) that is why I decided not to hack on it in the first place. But in general, I think you are right @rnewson -- I can give them a try because your way is closer to the true path.

[pgj]

Opened https://github.com/boundary/scalang/pull/37 to address the scalang part.

[jaydoane]

When I was looking at the scalang repository I had the impression that it is not actively maintained (the latest commit is from 9 years ago)

We're using this fork of scalang which has more recent activity.

[pgj]

Thanks @jaydoane for the excellent hint -- I should have thought about it. Per this suggestion, moved the pull request to https://github.com/cloudant/scalang/pull/3 .

[pgj]

@rnewson rebased the solution to scalang 1.0.1. Hopefully this version is now closer to the one you suggested.