poanetwork / poa-devops Goto Github PK

Problem: Some (esp first) nodes have rather low and unstable number of peers.
Possible solution: refresh list of reserved peers (bootnodes.txt) from the repository

I think it would be awesome to incorporate our own notification logic into the nodes. I know that DO/AWS/AZURE all have solutions to monitor bandwidth etc...

But possibly we could have a variable to put in a TWILIO or SENDGRID api in order to get customized notifications. I'm not exactly sure what rulesets we'd implement, but some ideas are:

• if payout script fails
• when someone tries to ssh into your machine
• Whenever new validator joins
• when a new ballot is submitted to validators to vote on
• when a ballot is finalized

I know some of these aren't necessarily on our specific nodes (like when someone finalizes a ballot) -- so a third-party notification system might work for that and now I'm wanting to build that actually. Thoughts?

Refactor upd-scripts-validator to move username used for ssh connection from playbook to vars, so that it can be easily changed, mention this in docs.

Originally by @micwebnet in poanetwork/deployment-playbooks#44

If the SSH keys are password protected, ansible-playbook fails with

TASK [hf-spec-change : Shutdown poa-netstats service] *****************************************************************************
fatal: [52.191.165.235]: FAILED! => {"changed": false, "msg": "Unable to stop service poa-netstats: Failed to stop poa-netstats.service: Interactive authentication required.\nSee system logs and 'systemctl status poa-netstats.service' for details.\n"}
to retry, use: --limit @/home/mm/poa-devops/site.retry

The workaround is to use non-password-protected ssh keys, but that's a security vulnerability if the control system is compromised. Suggest looking into allowing interactive auth during deployment.

Best, MM

Add an option (by default true) to remove keys from parity_data before uploading backup to AWS.

Seems to be an assumption deployments use the same ssh key/pairs, i.e. generate once and used in all deployment scenerios.

This may be fine for a test environment but not sure it is desirable in production.

I think some policy around ssh key management needs to be specified for deployments and then implemented in deployment scripts, or at least any assumptions about ssh keys need to be explicitly stated.

In this way the documentation can be constructed to help our user base, who have a varying degree of technical acumen.

I think that it still says 1.10.0 but ought to say 1.10.6

"PARITY_VERSION_CHECK: "1.10.0" "