diff --git a/docs/source/install-docs/AWS-NodeInstall-20.04 b/docs/source/install-docs/AWS-NodeInstall-20.04.md similarity index 98% rename from docs/source/install-docs/AWS-NodeInstall-20.04 rename to docs/source/install-docs/AWS-NodeInstall-20.04.md index fd7c881a2..63f962e17 100644 --- a/docs/source/install-docs/AWS-NodeInstall-20.04 +++ b/docs/source/install-docs/AWS-NodeInstall-20.04.md @@ -6,6 +6,8 @@ NOTE: Since AWS regularly updates their user interface, this document becomes ou #### Installation +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. Before you begin the installation steps, login to your AWS console and select a region to run your VM in. Recommendation: Select the region matching the jurisdiction of your company's corporate offices. 2. From the AWS EC2 services page, click 'Instances' 3. Click 'Launch Instances' @@ -340,4 +342,4 @@ NOTE: Since AWS regularly updates their user interface, this document becomes ou 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -30. You can now begin the Indy Node installation using the Validator Preparation Guide. +30. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/Azure-NodeInstall-20.04 b/docs/source/install-docs/Azure-NodeInstall-20.04.md similarity index 98% rename from docs/source/install-docs/Azure-NodeInstall-20.04 rename to docs/source/install-docs/Azure-NodeInstall-20.04.md index eb9d902b3..3de567b59 100644 --- a/docs/source/install-docs/Azure-NodeInstall-20.04 +++ b/docs/source/install-docs/Azure-NodeInstall-20.04.md @@ -6,6 +6,8 @@ NOTE: Since Azure regularly updates their user interface, this document becomes #### Installation +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. Create a new or open an existing “Resource Group” (“Create New” was used for this document.) You can also do this later. 2. From the Azure portal ‘home’ click 'Create a resource'. 3. Type “ubuntu server” in the search field, ‘Enter’, then select 'Ubuntu server 20.04 LTS' @@ -371,4 +373,4 @@ NOTE: Since Azure regularly updates their user interface, this document becomes 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -30. You can now begin the Indy Node installation using the Validator Preparation Guide. +30. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/GC-NodeInstall-20.04 b/docs/source/install-docs/GC-NodeInstall-20.04.md similarity index 98% rename from docs/source/install-docs/GC-NodeInstall-20.04 rename to docs/source/install-docs/GC-NodeInstall-20.04.md index 626d42dd3..ca1b9cdb0 100644 --- a/docs/source/install-docs/GC-NodeInstall-20.04 +++ b/docs/source/install-docs/GC-NodeInstall-20.04.md @@ -5,6 +5,9 @@ The following steps are one way to adhere to the Indy Node guidelines for instal NOTE: Since GC regularly updates their user interface, this document becomes outdated quickly. The general steps can still be followed with a good chance of success, but please submit a PR with any changes you see or inform the author of the updates (lynn@indicio.tech) to keep this document up to date. #### Installation + +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. To prepare for VM creation, there are a few preliminary steps needed. First you might need to create a project in which you will create your VM. You will then need to set up items needed for Node networking (detailed steps below). You will also need to create a snapshot schedule so that your VM can be backed up automatically (optional, but this is the only method described herein that satisfies the "backup" requirement). 2. From the GCP console ([https://console.cloud.google.com/](https://console.cloud.google.com/)) scroll down in the upper left hamburger menu to the 'Networking' section, select 'VPC Network', then 'VPC Networks' If you haven’t already, you might need to “Enable” the compute engine API. 1. Before you begin, decide on a 'region' in which to run your VM that closely matches the jurisdiction of your company's corporate offices. Record the region selected as it will be used later in these instructions. @@ -375,4 +378,4 @@ NOTE: Since GC regularly updates their user interface, this document becomes out 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -28. You can now begin the Indy Node installation using the Validator Preparation Guide. +28. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/Physical-NodeInstall-20.04 b/docs/source/install-docs/Physical-NodeInstall-20.04.md similarity index 97% rename from docs/source/install-docs/Physical-NodeInstall-20.04 rename to docs/source/install-docs/Physical-NodeInstall-20.04.md index ca63c669e..f53c422f2 100644 --- a/docs/source/install-docs/Physical-NodeInstall-20.04 +++ b/docs/source/install-docs/Physical-NodeInstall-20.04.md @@ -5,6 +5,8 @@ The following steps are one way to adhere to the Indy Node guidelines for instal #### Installation +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. Before you begin: 1. For most governance frameworks' hardware requirements, you will need 2 NIC's and 2 subnets (one per NIC). Configure these before beginning the install. 2. Hardware requirements might include the following, (or greater, depending on your network governance requirements): @@ -220,4 +222,4 @@ The following steps are one way to adhere to the Indy Node guidelines for instal 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -30. You can now begin the Indy Node installation using the Validator Preparation Guide. +30. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/node-installation-info.xlsx b/docs/source/install-docs/node-installation-info.xlsx new file mode 100644 index 000000000..f28587384 Binary files /dev/null and b/docs/source/install-docs/node-installation-info.xlsx differ diff --git a/docs/source/install-docs/validator-prep-20.04.md b/docs/source/install-docs/validator-prep-20.04.md new file mode 100644 index 000000000..2d1c1efe6 --- /dev/null +++ b/docs/source/install-docs/validator-prep-20.04.md @@ -0,0 +1,590 @@ +## Validator Preparation Guide + + +The purpose of this document is to help you to set up a Validator node on a Hyperledger Indy network, as well as to set up a CLI machine for using the indy-cli. The CLI will be used now and in the future to post transactions to networks and retrieve information as a Steward. + +Table of Contents + + +[TOC] + + + +## 1. Introduction + +Before reading the contents of this document it is highly recommended that you have a good understanding of at least the technical section of the governance framework for the network you are joining. Your Network Administrator will be able to provide you with that document plus the other items needed as mentioned throughout this document. + +### 1.1. High Level Overview + +Node Operators (or Stewards) operate the Validator nodes of the Hyperledger Indy decentralized identity network. Please see your governance framework document for more information about Node Operators and their role. + +By design, as a Node Operator, you are only allowed to operate one Validator node per network. + + +### 1.2. Hyperledger Indy and Indy-SDK + +All Node Operators on a network run the same codebase. This codebase is open source Validator node software developed under the [Hyperledger Indy](https://github.com/hyperledger/indy-node) project hosted and managed by the [Linux Foundation](https://www.linuxfoundation.org/). This enables Node Operators (and everyone else in the ecosystem) to be confident in the code running the network. + + +## 2. Preliminaries to the Set Up + +Before you start the Node set up process, you’ll need to have a place where you can store all of the following information. You can make a copy of the [Node Installation Setup Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to use for saving the needed information. + +As you proceed through these steps, you will be generating data that will be needed later. As you follow the instructions and obtain the following, store them for later use: + + + +* Your Steward seed + * This is extremely important and it must be kept **safe and private**. It is used to generate the public/private key pair that you will use as a Node Operator to post transactions to the ledger. +* Your Steward DID + * This is public information that is generated by your Steward seed. It is an identifier for your organization that will be written to the ledger by a Network Trustee. +* Your Steward verification key (verkey) + * This is public information that is generated by your Steward seed. It will be written to the ledger by a Network Trustee along with your DID, and will be used to verify transactions that you write to the ledger. +* The Validator IP Address for inter-node communications + * This IP address must be configured for exclusive use of inter-node consensus traffic. Ideally, traffic to this address will be allowed through your firewall. +* The Validator node port +* The Validator IP Address for client connections + * This IP address must be open for connections from anywhere, since clients around the world will need to be able to connect to your node freely. +* The Validator client port +* The Validator alias + * It is critical to use the exact same alias name with the same capitalization in all places that it is used. +* The Node seed + * This is distinct from your Steward seed, and will generate public and private keys that your Node will use for communications with other Nodes. Like the Steward seed, it should be kept secure. +* The Validator Node Identifier (Also referred to as Validator Verkey or Target by some Node tools used herein) + * This is distinct from your Steward DID and verkey. It is also public information that will be placed on the ledger, but this one is used as a public key by your Validator Node. +* The Validator BLS public key. + * Used by the Validator to sign individual transactions that will be committed to the ledger. It is public information that will be written to the ledger. +* The Validator proof of possession for BLS key (pop) + * A cryptographic check against certain forgeries that can be done with BLS keys. This key is also public information that will be written to the ledger. + + +### 2.1. Two Machines + +You’ll need two machines: one will be your Validator node and the other a CLI machine to run a CLI with which you will interact with the ledger. They can be actual physical machines, virtual machines, or a combination. The machine with the CLI can be turned on and off at your convenience (e.g., it could be a shared VM, a VM on a laptop, run directly from your workstation, etc.); only the Validator node needs to be public and constantly up. + + +**Important:** For security reasons, you must NOT use your Validator node as a CLI machine. If you do, it could expose your Steward credentials needlessly. + +Your Validator **must run Ubuntu 20.04 (64-bit)** as this guide covers instructions for that version only. To install your Ubuntu Validator you can follow some public step-by-step instructions created for that purpose. [Install Docs](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs) + +This preparation guide recommends to use the [containerized Indy CLI](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) in all environments and includes instructions only for that version. + +Your Validator node must have two NICs, each with associated IP addresses and ports. One NIC (Node-NIC) will be used for inter-validator communication, and the other (Client-NIC) for connections from clients, including edge agents, as well as ssh and other connections you use for administration. This two NIC approach is required as a defense against denial-of-service attacks, since the Node-NIC should be behind a firewall that is configured to be much more restrictive of inbound connections than the Client-NIC is. + + +### 2.2. Validator Node Preliminary Information + + +##### Get the IP Addresses + +Your Validator node will be the machine that will become a part of the network. It should have two static, publicly accessible, world routable IP addresses. It should be configured so that outgoing TCP/IP connections are from these same addresses, as well as incoming connections. + + +##### Choose Port Numbers: + +The Validator node will also be required to have the following: + + + +* **Node Port: TCP** - The Validators use this IP address and port combination to communicate with each other within an Indy Network. +* **Client Port: TCP** - Clients use this IP address and port combination to communicate with the Validator node, for all ledger interactions. + +While ports 9700-9799 are allowed, by convention most node operators choose the default ports 9701 and 9702 for their Node and Client ports, respectively, and related instructions and documentation use those defaults. + +##### Choose an Alias: + +Your Validator node will need to have an alias. This will be used later when we create a key for the node. It can be any convenient, unique name that you don’t mind the world seeing. Reference to your company name is preferred, but not required, and it is required be distinguishable from the other Validator nodes on the network. Many Node Operators choose a Validator alias that identifies their organization, for pride of their contribution to the cause of decentralized identity. + + +## 3. Setup and Configuration + +You must perform the following instructions in order. If you require assistance, please contact your Network Administrator or post to the [indy-node](https://discord.com/channels/905194001349627914/941709259710808155) discord channel. Some instructions must be executed on the Validator node, and others on the CLI machine. + + +### 3.1. CLI Machine Installation + + +#### 3.1.1. Install the CLI machine + +On the machine you’ve chosen for the CLI, do the following to install a containerized indy-cli ([more details](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) are available if desired): + + + +1. Install docker +2. Navigate to your github directory (your choice) +3. Clone the von-network repo (for access to the containerized indy-cli) + + git clone [https://github.com/bcgov/von-network.git](https://github.com/bcgov/von-network.git) + +4. `cd von-network` +5. `./manage build` + + +#### 3.1.2. Add an Acceptance Mechanism + +To write to many Indy ledgers, you’ll need to “sign” the Transaction Author Agreement for that ledger. This Agreement acceptance is incorporated into the process of connecting to the node pool and requires an acceptance mechanism. For the Indy CLI, the default mechanism is “For Session” and the following instructions are required to be able to use “For Session” for your CLI: + +Create a JSON Config file in the tmp directory containing your taaAcceptanceMechanism. + + +``` +vim /von-network/tmp/cliconfig.json +``` + + +Copy in the following example cliconfig file which contains the line that sets the acceptance mechanism: + +``` +{ + "taaAcceptanceMechanism": "for_session" +} +``` + +Now all of the appropriate transactions will have an “Agreement Accepted” authorization attached to them during your CLI sessions. + + +#### 3.1.3. Initialize a pool + +Initialize a “pool” for the network your Node will be joining with the following steps. The pool genesis file contains connection information about some of the Validator nodes, which will be used by your CLI to connect to the network. The "network name" is your choice (it's best if it resembles the network you are joining) and the "genesis file link" will be provided by your network administrator. + +From the indy-cli machines "von-network" directory run: + +`./manage cli init-pool ` + +For example: run the following if your node will be added to the Indicio TestNet and a pool handle named "testnet" will be added to your CLI list of pools: + + ubuntu@von-network$ ./manage cli init-pool testnet [https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_testnet_genesis](https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_testnet_genesis)`` + + +#### 3.1.4. Generate the Steward DID + +Next, generate a Steward DID/Verkey. This will be comprised of a public and private key pair, generated from a seed. Your seed will allow you to regenerate the Steward DID on demand. _To keep this secure, you will need to have a **very** secure seed that is not easy to guess._ + + +##### Generate a Seed + +**WARNING:** +**You want to guard your seed well. The seed will be used to generate your public (verification) key as well as your secret private key for your DID. If your seed falls into the wrong hands, someone could regenerate your private key, and take over your identity on the ledger.** + + +In a terminal, run the following to install a random string generator, and then use it to generate your Steward seed (or create your own random 32 character seed): + + +``` +sudo apt install pwgen +pwgen -s 32 1 +``` + + +EXAMPLE: +``` +pwgen -s 32 1 +ShahXae2ieG1uibeoraepa4eyu6mexei +``` + +**IMPORTANT:** +**Keep this seed in a safe place, such as an encrypted password manager or other secure location designated by your organization. ** + + + +##### Generate DID and Verkey + +Enter the following to create your wallet and store your Steward DID in it. In these instructions substitute in names of your choosing for your wallet. The encrypted wallet will be used to store important information on this machine, such as your public and private keys. When creating your wallet, you will need to provide a "key" that is any string desired. It will be the encryption key (essentially the password) of your local wallet. + + +``` +./manage indy-cli create-wallet walletName= +``` + + +When prompted, enter the wallet key to complete the creation of the wallet. + +**IMPORTANT:** +**To be able to retain your wallet and not re-create it when you need it in the future, keep this wallet key in a secure location.** + + + +When prompted, enter the wallet key to open the wallet. + + +When prompted, enter your seed. (The create-wallet command includes an automated workflow for using the Steward seed that you generated in the immediately preceding step to create your Steward DID) + + +**IMPORTANT: Save the displayed “DID” and “verkey” portions of this. They are not secret, and they will be used later when you are prompted to supply your Steward DID and verkey.** + + + +### 3.2. Validator Node Installation + + +#### 3.2.1. Perform Network Test + +This test is to confirm that your Validator node can connect with external devices. + +Note that the communication protocol used for both node and client connections is ZMQ. If your firewall uses deep packet inspection, be sure to allow this protocol bi-directionally. + +The tests in this section are to assure that your node's networking is operational, and that firewalls will allow TCP traffic to and from your IP addresses and ports. The assumptions are that for this stage of testing, you will be able to reach both sets of IP address/port combinations from an arbitrary client, but that later you will implement rules on your firewall restricting access to your Node-IP address/port. + + +##### 3.2.1.1 Test the Node connection to your Validator + +Use netcat to listen on the Node-IP address and port on your Validator + +IMPORTANT: +Many cloud providers, use local, non-routable IP addresses on their servers and then use NAT to translate these to public, routable IP addresses. If you are on such a system, use the **local address** to listen on, and the **public address** to ping with. + +`nc -l <node_ip_address> <node_port> ` + +The above command will wait for a connection. On a system that can be used as a client, such as your CLI machine, do a TCP ping of that IP address and port: + +`nc -vz <node_ip_address> <node_port>` + +If the test is successful, the ping will return a "succeeded" message and the commands on both systems will exit. + +NOTE: Sometimes the above fails when the connection is actually set up correctly. In that case, you might try and install socat and run something like the following but substitute in your own interface name and port: + +`socat tcp4-listen:9701,so-bindtodevice=ens5,reuseaddr,fork -` + + +##### 3.2.1.2 Test the client (edge agent) connection to your Validator + +Repeat the above test on your Validator and a test client, but using the Validator's "client" IP address and port. + +Important: The “client” IP address referred to here is not the CLI machine’s IP address. Reminder: The Validator node has a Node-IP for communications with other Validator Nodes and a Client-IP for communications with edge agents (anything outside the Network of Validator Nodes). + +On your Validator: + +`nc -l <client_ip_address> <client_port> ` + +On your client: + +`nc -vz <client_ip_address> <client_port>` + +If the test is successful, the ping will return a "succeeded" message and the commands on both systems will exit. + + +##### 3.2.1.3 Test the connection from your node to another Validator on the network you will be joining + +For Example: One of the Validator nodes on the Indicio TestNet is named "OpsNode", which has a node IP address and port of 3.135.134.42 and 9701, respectively. (Ask your Network Administrator for your networks' information.) On your Validator, make sure that your node is able to connect to this node by TCP pinging its node IP address and port: + +``` +nc -vz 3.135.134.42 9701 +Connection to 3.135.134.42 9701 port [tcp/*] succeeded! +``` + +When the above three tests are successful, you may proceed. + +NOTE: On Ubuntu 20.04, some of the above "tests" can fail when the networking is actually set up correctly. It is recommended to try the above tests, but if they fail and you are confident that networking is set up correctly feel free to proceed with the installation instructions. + + + +#### 3.2.2. Install the Validator Node + +Continue on your Validator node machine. + + +**Important: You must use a login user with sudo privileges (not root or indy) to run these commands, unless otherwise indicated.** + + + +``` +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9692C00E657DDE61 +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3BC8C2DD662F1C45 +sudo add-apt-repository "deb https://hyperledger.jfrog.io/artifactory/indy focal rc" +sudo add-apt-repository "deb http://security.ubuntu.com/ubuntu bionic-security main" +sudo add-apt-repository "deb https://repo.sovrin.org/deb bionic master" +sudo add-apt-repository "deb https://sovrin.jfrog.io/artifactory/deb focal rc" +sudo apt-get update -y +sudo apt-get upgrade -y +sudo apt-get install -y \ + rocksdb=5.8.8 \ + libgflags-dev \ + libsnappy-dev \ + zlib1g-dev \ + libbz2-dev \ + liblz4-dev \ + libgflags-dev \ + python3-libnacl=1.6.1 \ + python3-sortedcontainers=1.5.7 \ + python3-ujson=1.33 \ + python3-pyzmq=22.3.0 \ + indy-plenum=1.13.1~rc3 \ + indy-node=1.13.2~rc5 \ + sovtoken=1.1.0~rc0 \ + sovtokenfees=1.1.0~rc0 \ + sovrin=1.2.0~rc1 \ + libssl1.0.0 \ + ursa=0.3.2-1 + +sudo ln -sv /usr/lib/ursa/* /usr/lib +``` +NOTE: You must add the line REV_STRATEGY_USE_COMPAT_ORDERING = True in the /etc/indy/indy_config.py file of any 20.04 node being added to an existing 16.04 network. (The default is False) +`echo "REV_STRATEGY_USE_COMPAT_ORDERING = True" | sudo tee -a /etc/indy/indy_config.py` + + +#### 3.2.3. Create the Key for the Validator Node + +IMPORTANT: +Many providers, like AWS, use local, non-routable IP addresses on their nodes and then use NAT to translate these to public, routable IP addresses. If you are on such a system, use the **local addresses** for the init_indy_node command. + +Please run the following steps on the Validator before running init-indy-node. The default instruction examples are for the Indicio TestNet, but please use the alternate values supplied by your Network administrator for each use of "your_network_name" and any links. The network name mentioned in these steps is the network directory name that your Network Administrator has supplied you with. All nodes on a network **must use the same directory name**. + +1. In the /etc/indy/indy_config.py file, **change the Network name from “sandbox” to “”** Use sudo to edit the file directly or run: +`sudo -i -u indy sed -i -re "s/(NETWORK_NAME = ')\w+/\1your_network_name/" /etc/indy/indy_config.py` +EXAMPLE for Indicio TestNet: +`sudo -i -u indy sed -i -re "s/(NETWORK_NAME = ')\w+/\1itn/" /etc/indy/indy_config.py` +2. sudo -i -u indy mkdir /var/lib/indy/your_network_name \ +EXAMPLE for Indicio TestNet: `sudo -i -u indy mkdir /var/lib/indy/itn` +3. cd /var/lib/indy/your_network_name \ +EXAMPLE or Indicio TestNet: `cd /var/lib/indy/itn` +4. sudo curl -o domain_transactions_genesis +EXAMPLE for Indicio Testnet: `sudo curl -o domain_transactions_genesis https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/domain_transactions_testnet_genesis` +5. sudo curl -o pool_transactions_genesis +EXAMPLE for Indicio Testnet: `sudo curl -o pool_transactions_genesis https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_testnet_genesis` +6. Make sure that both genesis files are owned by indy:indy + `sudo chown indy:indy *` + +Enter the following command to initialize your Indy Node. <ALIAS> is the alias you chose for your Validator node machine and <node ip>, <client IP>, <node port #> and <client port #> should match the corresponding values for your Validator. + +**Note: The node IP and client IP addresses in this command should be the LOCAL (or private) addresses for your node.** + + +``` +ubuntu@validator$ sudo -i -u indy init_indy_node +``` + + +The output will look something like this: + + +``` +Node-stack name is Node19 +Client-stack name is Node19C +Generating keys for random seed b'FA7b1cc42Da11B8F4BC83990cECF63aD' +Init local keys for client-stack +Public key is a9abcd497631de182bb6f767ffb4921cdf83ffdb20e9d22e252883b4fc34bf2f +Verification key is 3d604d22c4bbfd55508a5a7e0008847bdeccd98a41acd048b500030020629ee1 +Init local keys for node-stack +Public key is a9abcd497631de182bb6f767ffb4921cdf83ffdb20e9d22e252883b4fc34bf2f +Verification key is bfede8c4581f03d16eb053450d103477c6e840e5682adc67dc948a177ab8bc9b +BLS Public key is 4kCWXzcEEzdh93rf3zhhDEeybLij7AwcE4NDewTf3LRdn8eoKBwufFcUyyvSJ4GfPpTQLuX6iHjQwnCCQx4sSpfnptCWzvFEdJnhNSt4tJMQ2EzjcL9ewRWi24QxAaCnwbm2BBGJXF7JjqFgMzGfuFXXHhGPX3UtdfAphrojk3A1sgq +Proof of possession for BLS key is QqPuAnjnkYcE51H11Tub12i7Yri3ZLHmEYtJuaH1NFYKZBLi87SXgC3tMHxw3LMxErnbFwJCSdJKbTb2aCVmGzqXQtVWSpTVEQCsaSm4SUZLbzWVoHNQqDJASRYNbHH2CqpR2MtntA4YNb2WixNSZNXFSdHMbB1yMQ7XUcZqtGHhcb +``` + + +When running this command again on the same node (or during the 16.04 to 20.04 upgrade), to keep the same keys you will need to add the seed that was generated the first time you ran the command to the end of the repeated command. + +The new command looks like: `sudo -i -u indy init_indy_node ` + +**Store the original command, the random seed, the verification key, the BLS public key, and the BLS key proof-of-possession (POP).** These are the keys for your Validator node (not to be confused with the Steward keys). The Validator verification key and BLS key (with its POP) are public, and will be published on the ledger. + +IMPORTANT: The random seed should be protected from disclosure. + + +#### 3.2.4. Enable DDOS protection on the Validator +This step is required by most public networks. + + 1. sudo sed -i -re "s/(^CLIENT_CONNECTIONS_LIMIT=).*$/\115000/" /etc/indy/indy.env + + 2. sudo apt-get install -y iptables-persistent + + 3. sudo setup_indy_node_iptables + +To confirm the new settings run: + + sudo iptables -v -L + + + +#### 3.2.5. Add data directory (Optional) + +If your new 20.04 node is being added to an existing network (and especially if that network has been running for a while) these steps are highly recommended: + +1. Ask your Network Administrator for a copy of the data directory for the network you are joining. Make extra sure the data directory matches the network you will join. + +2. Copy the data directory file (zipped or tarred) to the /tmp directory on your Node + +3. Depending of the method used to compress the files. Use something like the following commands to unpack the compressed file (based on the extension of the compressed file): + a. `cd /var/lib/indy/` + b. `sudo rm -rf data` + c. `sudo tar xf /tmp/data.tgz` + d. OR `sudo xz -d /tmp/data.xz` + e. `cd data` + f. `ls` + g. Rename the listed directory to the alias name of the node you are building (must be EXACT): `sudo mv ` + +### 3.3. Run the Technical Verification Script + +Download [this script](https://raw.githubusercontent.com/sovrin-foundation/steward-tools/master/steward_tech_check.py) (or a similar one provided by your Network Administrator), upload it to your Validator node, and set the execution flag on it (The link above is for Sovrin's tech-check script and the example below is Indicio's): + + + ubuntu@validator$ cd ~ + + + ubuntu@validator$ curl -O https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/nodeop-tools/nodeop-tech-check.py + + + ubuntu@validator$ chmod +x nodeop-tech-check.py + +Execute it, answering the questions that it asks. There are no wrong answers; please be honest. Questions that can be answered by scripting are automatically completed for you. + + + ubuntu@validator$ sudo python3 ./nodeop-tech-check.py + +After the script completes, copy the output beginning at `= Results for "A Node Operator MUST" ==`, and send it to your Network Administrator. + + +### 3.4. Provide Information + +At this point you should have the following data available: + + + +* Your Steward verkey and DID +* The Validator ‘node IP address’ +* The Validator ‘client IP address’ +* The Validator ‘node port’ +* The Validator ‘client port’ +* The Validator alias +* The Validator verkey +* The BLS key + +Please go to the Node Operator Validator Registration form provided by your Network administrator and provide the requested information. For Example: Indicio uses [Node Operator Validator Registration](https://forms.gle/yBFBiFioSQ5SQRY9A). + +Note: You are done with the first part of the onboarding. Your Network Administrator will contact you to go through the rest of this guide together on a call. + + +### 3.5. Add Node to a Pool + +After your data is submitted via the Node Operator Validator Registration form, a Network Trustee will put your Steward DID into the ledger. You will receive notification when your DID and verkey have been added to the ledger. You will be asked to work together on a call with the Network Administrator to complete the final steps to onboard your node onto the network. Please be prepared to suggest times to do this together. \ + \ +**IMPORTANT: \ + DO NOT proceed further with this document until your Steward DID and verkey are on the ledger. ** + + +#### 3.5.1. Configuration + +After you have been informed that your DID has been placed onto the ledger, you may complete the configuration steps to activate your Validator node on that network. + + +##### Make Sure Your Version Is Current + +In some cases, some time may have passed before reaching this point. You should ensure that you have the current version of indy software installed before proceeding. On the Validator node, execute the following. + +In the Validator node: + + +``` +ubuntu@validator$ sudo apt update +ubuntu@validator$ apt-cache policy sovrin +``` + + +If your installed version is not the newest, upgrade your version using the install command provided earlier in this guide. + +At this point your Network Administrator will likely run some routine checks with you to verify that your node is configured correctly before proceeding. + + +##### Add Validator Node to Ledger + +On your CLI machine, [open an interactive indy-cli session](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#open-an-interactive-indy-cli-session) using information that you saved from earlier in this guide: + +ubuntu@von-network$ `./manage indy-cli --config /tmp/cliconfig.json start-session walletName=(your_wallet) poolName=(your_pool_name) useDid=(your_steward_DID)` + +Enter your wallet encryption key when prompted. + +At the indy-cli command prompt, enter the following, substituting in the correct data any place you see <>. An example will follow. + + + +* _Suggestion: Edit this in a text editor first, then copy and paste it into the Indy CLI. Caution: Some editors will insert 'smart quotes' in place of regular ones. This will cause the command to fail._ + + +``` +indy> ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop= +``` + + +IMPORTANT: + +Many providers, such as AWS, use local, non-routable IP addresses on their nodes and then use NAT to translate these to public, routable IP addresses. If you are on such a system, use the **routable public addresses** for the ledger node command. + +**Example:** + + +``` +indy> ledger node target=4Tn3wZMNCvhSTXPcLinQDnHyj56DTLQtL61ki4jo2Loc node_ip=18.136.178.42 client_ip=18.136.178.42 node_port=9701 client_port=9702 services=VALIDATOR alias=Node19 blskey=4kCWXzcEEzdh93rf3zhhDEeybLij7AwcE4NDewTf3LRdn8eoKBwufFcUyyvSJ4GfPpTQLuX6iHjQwnCCQx4sSpfnptCWzvFEdJnhNSt4tJMQ2EzjcL9ewRWi24QxAaCnwbm2BBGJXF7JjqFgMzGfuFXXHhGPX3UtdfAphrojk3A1sgq blskey_pop=QqPuAnjnkYcE51H11Tub12i7Yri3ZLHmEYtJuaH1NFYKZBLi87SXgC3tMHxw3LMxErnbFwJCSdJKbTb2aCVmGzqXQtVWSpTVEQCsaSm4SUZLbzWVoHNQqDJASRYNbHH2CqpR2MtntA4YNb2WixNSZNXFSdHMbB1yMQ7XUcZqtGHhcb +``` + + + +* _Suggestion: Save this command. You will use it again if you later move to another Network._ + + +#### 3.5.2. Enable the Service + +In the Validator node: + +Return to the Validator node machine. + +Enable the service so that it will auto-restart when your node reboots: + + +``` +ubuntu@validator$ sudo systemctl enable indy-node.service +``` + + +Start the Validator service: + + +``` +ubuntu@validator$ sudo systemctl start indy-node +``` + + +Verify the start: + + +``` +ubuntu@validator$ sudo systemctl status indy-node.service +``` + + + +### 3.6. See if the Node Is Working + +If the setup is successful, your Validator node now connects to the Validator pool. + +In the Validator node: + + +``` +ubuntu@validator$ sudo validator-info +``` + + +If your node is configured properly, you should see several nodes being selected as the primary or its backups, as in this example: + + +``` + England (1) + Singapore (3) + Virginia (4) + RFCU (5) + Canada (0) + Korea (2) +``` + + + + _Note: A ledger with a lot of transactions on it, can take a lot of time to sync up a new Validator node. If you don't get the right results for this test right away, try it again in a few minutes(or longer)._ + +To check that messages and connections are occurring normally you can run the following command to follow the log file: + +In the Validator node: + + +``` +ubuntu@validator$ sudo tail -f /var/log/indy/itn/.log