feat(affiliate-scripts): initial commit

Author: ngyam

CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,63 @@
+# Contributing
+
+## Introduction
+
+Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
+
+We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
+ - Reporting a bug
+ - Discussing the current state of the code
+ - Submitting a fix
+ - Writing code that can be incorporated into the project itself
+ - Proposing new features
+ - Improving the documentation
+ - Writing tutorials or blog posts
+
+When contributing to this repository, please first discuss the change you wish to make via issue,
+email, or any other method with the owners of this repository before making a change. 
+
+As for everything else in the project, the contributions to this repo are governed by our [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+## Using the issue tracker
+
+Do **NOT** report security vulnerabilities in public issues! See [SECURITY](./SECURITY.md) for further details.
+
+The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests, but please respect the following restrictions:
+
+ - Please do not use the issue tracker for personal support requests. Use our [Slack channel/whatever].
+
+ - Please do not derail or troll issues. Keep the discussion on topic and respect the opinions of others.
+
+## Your first contribution
+
+Working on your first Pull Request? You can learn how from this free series, [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github).
+
+## Pull request process
+
+ 1. Fork the repo, clone it to your own machine and create your branch from `master`
+ 2. Commit changes to your branch
+ 3. If you've added code that should be tested, add tests
+ 4. If you've changed APIs, or if needed, update the documentation, README, etc.
+ 5. Ensure the test suite passes.
+ 6. Make sure formatting is according to the repo`s style guidelines. Use a linter if needed.
+ 7. Push your work back to your fork
+ 8. Create that pull request
+ 9. Pass the review, reiterate if requests are made by the maintainers
+
+NOTE: Be sure to merge the latest from "upstream" before making a pull request!
+
+## Reviews
+
+Don't forget to review your own code first. Does it make sense? Did you include something unrelated to the overall purpose of the changes? Did you forget to remove any debugging code?
+
+Our code review process is based on the following guidelines:
+* [Gitlab's Code Review Guidelines](https://gitlab.com/help/development/code_review.md)
+* [thoughtbot's Code Review Guidelines](https://github.com/thoughtbot/guides/tree/master/code-review)
+
+Especially pay attention to the ["Having your code reviewed"](https://gitlab.com/help/development/code_review.md#having-your-code-reviewed) section.
+
+## Copyright and Licensing
+
+All of your contributions will be made under [GPLv3](./LICENSE.md).
+
+## FAQ

README.md

@@ -1,2 +1,70 @@
-# ewc-affiliate-node-installation-scripts-
-EWC and Volta affiliate validator node installation scripts
+# EWC validator node install scripts
+
+EWC and Volta affiliate validator node installation scripts.
+
+**Keep a scratch file ready to collect outputs in - You'll need them**
+
+### Steps 
+
+1. Prepare an host according to the [system architecture paper](https://github.com/energywebfoundation/system-design-spec-live) (minimal install with ssh) with one of the following operating systems:
+    - Debian v9.x
+    - Ubuntu 18.04 LTS
+    - CentOS 7
+2. Copy the script matching the installed OS from the `affiliate` directory to the host
+3. SSH into the new host
+4. Make sure the latest system updates are installed by running `apt-get update && apt-get dist-upgrade` (debian/ubuntu) or `yum update` (centos)
+5. Make the scrip executable with `chmod +x ./install-*.sh`
+6. Run the script (user parameter `--auto` takes default values for node-name and generates a random key which is NOT recommended for production use)
+7. Send the installation summary to EWF netops to [[email protected]]([email protected])
+
+## Shared secrets
+
+The following files contain secrets that are used on the validators:
+
+-   `.secret` => Contains the password for the ethereum private key
+    Is accessed by `parity` and `nodecontrol` to send transactions to the chain
+-   `.env` => Contains the individual second channel password in the `SFTP_PASS` variable. Used by `nodecontrol`
+-   files in `signer-data/` used by the signer to store the signers encrypted private RSA key for signing telemetry packets.
+
+The following values are considered as public keys in `.env`:
+
+-   `VALIDATOR_ADDRESS` => Ethereum address of the validator account. Used by `signer` and `nodecontrol` for identification.
+-   `TELEMETRY_INGRESS_FINGERPRINT` => SHA256 fingerprint of the Ingress TLS certificate. Ingress presented cert needs to verify against the fingerprint.
+-   `SFTP_FINGER_PRINT` => Fingerprint of the SSH hostkey when connecting to the second channel.
+
+## Files created by the installation scripts
+
+```
+├── docker-stack
+│   ├── .env [Configurations used by docker-compose.yml]
+│   ├── chain-data [Parity data directory]
+│   │   ├── cache
+│   │   ├── chains
+│   │   │   ├── ver.lock
+│   │   │   └── Volta [Blockchainb DB]
+│   │   │       .
+│   │   ├── keys
+│   │   │   └── Volta
+│   │   │       ├── address_book.json
+│   │   │       └── UTC--2019-04-03T10-11-45Z--4d496ffe-8b48-e2a1-881f-351f03ae5539 [Validator signing key (not on bootnode)]
+│   │   ├── network
+│   │   │   └── key
+│   │   └── signer
+│   ├── config
+│   │   ├── chainspec.json 
+│   │   ├── parity-non-signing.toml [Parity configuration when signing disabled by nodecontrol]
+│   │   ├── parity-signing.toml [Parity configuration when signing enabled by nodecontrol (default)]
+│   │   └── peers
+│   ├── curcron
+│   ├── docker-compose.yml [Describes the compose stack]
+│   └── signer-data
+│       ├── signing.key [Encrypted RSA private key of the signer]
+│       └── signing.salt [Salt used to decrypt the RSA key on signer start]
+└── install-validator.sh [Script to install a validator - can be removed after bootstrap]
+```
+
+Other files:
+
+ - `/var/run/influxdb.sock` -> Named pipe for telegraf to write telemetry to and signer to read from.
+ - `/etc/telegraf/telegraf.conf` -> Telegraf collection settings
+

SECURITY.md

@@ -0,0 +1 @@
+If you find security vulnerabilities we kindly ask you not to disclose it in public. Please let the EWF team ([email protected]) know upfront. We will assess the issue as soon as possible on a best-effort basis and will give you an estimate for when we have a fix and release available for an eventual public disclosure.