Survey to improve Stamp-IT brainswap

Secured
#1
Greetings ANOs and Testnet operators,

You might already know about Stamp-It brainswap,a tool to brainswap two factomd nodes in a single command. In a few words, this tool is:
  • Simple: only 2 required parameters: the nodes to brainswap; no setup required other than OpenSSH
  • Safe: all the documented safety checks are performed automatically and brainswap is aborted if any check fails
  • Fast: calculates the first safe block height for brainswaping
We are looking at refactoring and improving this this tool and we would like to get feedback to make it as useful as possible for the factom community. Thus, we would appreciate if you take a few minutes to answer one or more of the following questions.
  • Have you tried this tool?
    • If you have:
      • Do you use it regularly on testnet?
      • Do you use it regularly on mainnet?
      • What do you like about it?
      • What do you dislike about it?
    • If you have not:
      • Is there a reason why?
      • What could make you consider its use?
We already have few ideas to improve brainswap: rewrite to improve testability, add consistency checks with respect to TFA bot configuration...
  • Do you have any other suggestion?

  • From your perspective, what should be the most important features of a brainswap tool?
    • Safety
    • Transparency (explaining the actions it takes)
    • Command line simplicity
    • Configuration simplicity
    • Speed
    • Few dependencies
    • Smart phone compatibility
    • Integration with monitoring tools
    • Anything else?
Thank you for your time.
 
Secured
#2
Hi Patrice,

I haven't used your tool yet to be honest. I think the main reason is that we don't do brain-swap that often, and when the time comes I just want to get the thing done and not in a mood to take some extra time to test a new tool. So passivity is probably the main reason for me. But I should definitively start using it at least for the testnet!

For me the most important features:
* safety: I don't want to lose my fed
* transparency: because this is touching a critical part of my infrastructure I need to be sure you are not stealing my keys :D
* simplicity: because I don't want to screw up because I had to overthink it or spend too much time figuring out what to input

Speaking of transparency, how are the keys carried over from one host to the other? Are they cut and pasted? Or are they commented in/out?

In terms of feature, have you thought about storing history of the node endpoints used so the user can just start the cli and pick from an existing list?
 
Secured
#3
Hi Paul,

To answer your question, the content of factomd.conf from both factomd nodes is first downloaded in a shell script variable (CONF1 and CONF2) using OpenSSH and cat. After that, IdentityChainID, LocalServerPrivKey and LocalServerPublicKey are extracted from CONF1 using grep and then used to generate a new configuration locally for the second node (NEWCONF2) using grep (to remove any previous identity) and sed (to add the new one).

The same process would apply using the identity from CONF2 to generate a new configuration NEWCONF1, but usually CONF2 has no identity. After all the checks have past, the new configurations (NEWCONF1 and NEWCONF2) are then uploaded to their respective node using OpenSSH and cat once again.

Thus, the keys are not commented in/out and they are not saved anywhere, except in your other node configuration. Of course, if your configuration file already contains an identity commented out, it is left untouched.

Keeping an history of node endpoints and having a more interactive CLI is a very good idea. Thank you @Paul Bernier !