From 040d20eba487831742f3e2fc1aca0f2165350375 Mon Sep 17 00:00:00 2001 From: Philipp Schlarb Date: Mon, 24 Apr 2023 11:53:46 +0200 Subject: [PATCH 1/7] Merge pull request #1689 from pSchlarb/newNetworkDoc Added Documentation for creating a new Network (cherry picked from commit fe1632ed4e1db9d40f3e69fb932c1f5544e89e1a) Signed-off-by: Philipp Schlarb --- docs/source/NewNetwork/CLIInstall.md | 116 +++++ docs/source/NewNetwork/CreateDID.md | 33 ++ docs/source/NewNetwork/NewNetwork.md | 144 ++++++ docs/source/configuring-2nics.md | 148 +++++++ docs/source/index.rst | 7 +- docs/source/installation-and-configuration.md | 418 ++++++++++++++++++ docs/source/start-nodes.md | 2 +- sample/Network/DIDs.txt | 71 +++ sample/Network/README.md | 132 ++++++ sample/Network/Stewards.csv | 5 + sample/Network/Trustees.csv | 4 + sample/Network/domain_transactions_genesis | 7 + sample/Network/pool_transactions_genesis | 4 + 13 files changed, 1089 insertions(+), 2 deletions(-) create mode 100644 docs/source/NewNetwork/CLIInstall.md create mode 100644 docs/source/NewNetwork/CreateDID.md create mode 100644 docs/source/NewNetwork/NewNetwork.md create mode 100644 docs/source/configuring-2nics.md create mode 100644 docs/source/installation-and-configuration.md create mode 100644 sample/Network/DIDs.txt create mode 100644 sample/Network/README.md create mode 100644 sample/Network/Stewards.csv create mode 100644 sample/Network/Trustees.csv create mode 100644 sample/Network/domain_transactions_genesis create mode 100644 sample/Network/pool_transactions_genesis diff --git a/docs/source/NewNetwork/CLIInstall.md b/docs/source/NewNetwork/CLIInstall.md new file mode 100644 index 000000000..4ce980c75 --- /dev/null +++ b/docs/source/NewNetwork/CLIInstall.md @@ -0,0 +1,116 @@ +# Installing the `indy-cli` + +The `indy-cli` is developed under the [indy-sdk](https://github.com/hyperledger/indy-sdk). This documentation may be not up to date. + +You will need to perform the following once for each `indy-cli` machine you would like to set up (only 1 is required). +It is recommended that you install the `indy-cli` in your native work environment if possible, so you always have it available even when traveling. + +## Containerized `indy-cli` Environment + +The following sections describe how to install and configure the `indy-cli` directly on a machine or VM. However, possibly the most convenient option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) + +## Windows: +To install the `indy-cli` on Windows 10 perform the following steps: +1. Download https://repo.sovrin.org/windows/indy-cli/stable/1.16.0/indy-cli_1.16.0.zip and unzip it. + If there is a newer version under https://repo.sovrin.org/windows/indy-cli/stable/ it instead. +2. Open a command prompt. (This will work differently if you use Windows Terminal). +3. `cd` to the directory where you unzipped the `indy-cli` package. For example, if you unzipped directly in your ‘downloads’ directory like I did you would type: `cd \Users\\Downloads\indy-cli_1.14.2` +4. Create a JSON Config file containing your taaAcceptanceMechanism in the directory where indy-cli.exe resides (I created \Users\\Downloads\indy-cli_1.14.2\cliconfig.json on my machine) + ```json + { + "taaAcceptanceMechanism": "for_session" + } + ``` +5. Run `indy-cli.exe --config cliconfig.json` to verify proper installation. You should see a new window appear with an `indy>` prompt, (If you are double clicking to start `indy-cli`, you need to right click on the .exe in your window and add the --config parameter first.) If you get an error stating that it is missing vcruntime140.dll then do the following: +6. Download and install vc_redist.x64.exe from the Visual Studio 2017 section on the https://support.microsoft.com/en-ae/help/2977003/the-latest-supported-visual-c-downloads page, and then rerun indy-cli.exe to see if it works as described in previous step. +7. Type ‘exit’ in the `indy-cli` + +## Ubuntu: +To install the `indy-cli` on Ubuntu, perform the following steps from the ubuntu command line: + +1. `sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88` +2. `sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable"` +3. `sudo add-apt-repository "deb https://repo.sovrin.org/deb xenial stable"` +4. `sudo apt-get update -y` +5. `sudo apt-get upgrade -y ` +6. `sudo apt-get install -y indy-cli` +7. `cd ~` +8. Create a JSON Config file containing your taaAcceptanceMechanism in your home directory: +`vim ~/cliconfig.json` + + Press the “i” key and paste the following into the file: + ```json + { + "taaAcceptanceMechanism": "for_session" + } + ``` + Press the “esc” key then the following characters to write the file and quit +`:wq` +9. Run `indy-cli --config ~/cliconfig.json` to start the `indy-cli` + +## Mac: + +Since there is not a prepackaged version of the `indy-cli` prepared for the Mac, the following steps will help you to create an environment, build, and run the `indy-cli` in a Mac terminal. + +Open a Terminal +Run the following commands in the terminal: + +1. `cd ~` +2. `mkdir github` +3. `cd github` +4. `git clone https://github.com/hyperledger/indy-sdk.git`(might need xcode-select --install if error occurs) +5. `/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"` +6. `curl https://sh.rustup.rs -sSf | sh` +7. Follow onscreen instructions to install rust +8. `brew install pkg-config libsodium automake autoconf cmake openssl zeromq zmq` + NOTE: the openssl path needs to match what you currently have on your system + +9. Run > `ls /usr/local/Cellar/openssl/` + Note the name of the directory shown (the example below shows 1.0.2p but the latest version is 1.1.1l) + + Use this directory in place of the one listed below in your .profile file + +10. Add the following lines to your` ~/.profile file `(making the correction shown in the previous step if needed) + ``` + export PATH="$HOME/.cargo/bin:$PATH:~/github/indy-sdk/libindy/target/debug:~/github/indy-sdk/cli/target/debug" + export PKG_CONFIG_ALLOW_CROSS=1 + export CARGO_INCREMENTAL=1 + export RUST_LOG=indy=trace + export RUST_TEST_THREADS=1 + export OPENSSL_DIR=/usr/local/Cellar/openssl/1.0.2p #use your path + export LIBRARY_PATH=~/github/indy-sdk/libindy/target/debug/ + export LIBINDY_DIR=~/github/indy-sdk/libindy/target/debug/ + ``` +11. Run the following commands from your terminal to build the `indy-cli`: + ``` + source ~/.profile + cd ~/github/indy-sdk/libindy + cargo build + cd ../cli + cargo build + ``` +12. Create a JSON Config file containing your taaAcceptanceMechanism in your home directory: + `vim ~/cliconfig.json` + + Press the “i” key and paste the following into the file: + ```json + { + "taaAcceptanceMechanism": "for_session" + } + ``` + Press the “esc” key then the following characters to write the file and quit + `:wq` +13. You can now run `indy-cli` from within a terminal by typing + + `indy-cli --config ~/cliconfig.json` + + `indy> exit` (To exit from the `indy-cli` prompt when you ar done) + + If the above gives error regarding library not loaded libssl.1.0.0, you will probably need to run the following command (all in one line should work) to revert your version: + + ``` + brew uninstall --ignore-dependencies openssl; brew uninstall openssl; + brew install https://github.com/tebelorg/Tump/releases/download/v1.0.0/openssl.rb + ``` + + diff --git a/docs/source/NewNetwork/CreateDID.md b/docs/source/NewNetwork/CreateDID.md new file mode 100644 index 000000000..eb8033d12 --- /dev/null +++ b/docs/source/NewNetwork/CreateDID.md @@ -0,0 +1,33 @@ +# Creating a DID using the `indy-cli` + +You will need to perform the following commands once for each `indy-cli` machine that you want to run on. The following commands contain suggestions to save certain values in a secure place. Please do not share those values or that place with anyone. + +_If you just need to quickly generate a set of secrets (Seed and wallet key), or a Seed, DID, and Verkey and do not have an `indy-cli` environment already setup, you can use the `indy-cli` features integrated into `von-network`. Refer to [Generate a set of Secrets](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-a-set-of-secrets), and [Generate your DID](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-your-did) for details._ + + +1. Start your `indy-cli` using the instructions from [Installing the `indy-cli`](./CLIInstall.md) for your platform. + + All following commands are executing inside the `indy-cli`. + +2. Create a wallet with: + + `wallet create key` + + You will be prompted for a wallet key. What you type will not be displayed on the console. Your wallet key is a secure key that only you should know, and it should be randomly generated. Save it in a secure place for later use. You will use it every time you need to send transactions to the ledger from the `indy-cli`. + +3. `wallet open wallet_name key` + + You will be prompted for your wallet key. What you type will not be displayed on the console. + +4. `did new seed` + + You will be prompted for a seed. What you type will not be displayed on the console. + + If you have lost your original seed or have never created one, then create a new one. This seed is used to regenerate your DID and to add your DID to your wallet(s). + + The seed is a 32 character string that only you can know. + + > WARNING: Whoever knows your Seed can recreate your exact DID in their own wallet and use it to manage the ledger. + + Save your Seed in a secure place so that only you can recreate your DID whenever needed. + Also save the public DID and verkey generated from this step so that you will know and can verify your public DID. \ No newline at end of file diff --git a/docs/source/NewNetwork/NewNetwork.md b/docs/source/NewNetwork/NewNetwork.md new file mode 100644 index 000000000..821b03a5a --- /dev/null +++ b/docs/source/NewNetwork/NewNetwork.md @@ -0,0 +1,144 @@ +# Setting up a New Network + +## Introduction + + The purpose of this document is to describe in some detail the process of building a brand-new Indy Node Network (Network) using 4 Stewards on their own separate nodes. + It goes into more details than [Starting a Network](../start-nodes.md). + These instructions are intended to be used for a distributed or “production” level environment but can be adapted to be used to build a private network. + + This document is heavily based on [Create New Indy Network](https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE) and the [Steward Validator Preparation Guide v3](https://docs.google.com/document/d/18MNB7nEKerlcyZKof5AvGMy0GP9T82c4SWaxZkPzya4). + +## I. Create Network Governance documents (Optional) + + Network Governance describes the policies and procedures by which your new network will run and be maintained. Here’s an example: [Sovrin Governance Framework](https://docs.google.com/document/d/1K8l5MfXQWQtpT49-FHuYn_ZnRC5m0Nwk) + + +## II. Assign Network Trustees + + Trustees are the people who manage the network and protect the integrity of the Network Governance. This includes managing the `auth_rules`. + + For a production Network, at least 3 Trustees representing three different persons are required and more are preferred. For a test Network one Trustee is required and 3 or more are preferred (all Trustee DID’s may belong to the same user on a test network if needed). + + Initial Trustees (3 preferred) must create and submit a Trustee DID and Verkey so that the domain genesis file can be built. + + Each trustee has to [instal the `indy-cli`](./CLIInstall.md) and [create a Trustee DID](./CreateDID.md). + + Once the Trustees have created their DID and Verkey give the Trustees access to a spreadsheet like [this one](https://docs.google.com/spreadsheets/d/1LDduIeZp7pansd9deXeVSqGgdf0VdAHNMc7xYli3QAY/edit#gid=0) and have them fill out their own row of the Trustees sheet. The completed sheet will be used to generate the genesis transaction files for the network. + + +## III. Genesis Stewards + + A Steward is an organization responsible for running a Node on the Network + + Exactly 4 “Genesis” Stewards are needed to establish the network, more Stewards can be added later. + + Each Genesis Steward’s node information will be included in the Genesis Pool file, so they should be willing to install and maintain a Node on the new Network for an extended period of time. + + The Stewards must: + 1. Generate Steward DIDs as described in [Creating DID](./CreateDID.md). + 1. Install their node as described in [Installation and configuration of Indy-Node](../installation-and-configuration.md) (with some small adjustments): + 1. Determine a name for the new network and have the stewards substitute it in the appropriate places in the guide, such as when setting the network name and creating the directory when creating the keys for the node. + 1. They all need to stop at the normal place ([3.5. Add Node to a Pool](../installation-and-configuration.md#3.5.-Add-Node-to-a-Pool)) as instructed in the guide as the steps that follow differ when creating a new network. The following sections of this guide describe the steps required to start the new network. + + Once the Stewards have created their DID and Verkey, and performed the initial setup of they node, give the Stewards access to a spreadsheet like [this one](https://docs.google.com/spreadsheets/d/1LDduIeZp7pansd9deXeVSqGgdf0VdAHNMc7xYli3QAY/edit#gid=0) and have them fill out their own row of the Stewards sheet. The completed sheet will be used to generate the genesis transaction files for the network. + +## IV. Create and Distribute genesis transaction files + + Save the sheets filled out by the Trustees and Stewards as separate files in csv format, and use the [genesis_from_files.py](https://github.com/sovrin-foundation/steward-tools/tree/master/create_genesis) script to generate the `pool_transactions_genesis` and `domain_transactions_genesis` files for the network. + + >Tip: The `generategenesisfiles` in `von-network` provides a convenient wrapper around the `genesis_from_files.py` and runs it in a container including all of the dependencies. For more information refer to [Generate Genesis Files](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-genesis-files). + + Double check the files contain the correct information: + - The `domain_transactions_genesis` file should contain all of the DIDs and Verkeys for the Trustees (`"role":"0"`) and the Stewards (`"role":"2"`). + - The `pool_transactions_genesis` file should contain each of the nodes with all their unique information. + + Publish the genesis files to a public location, such as a GitHub repository associated with your network. The Stewards and end users will need this information. + + Inform the Stewards and Trustees where they can download the genesis files. + + - The Trustees and Stewards will need to register the `pool_transactions_genesis` with their `indy-cli` to complete the setup and to be able to connect to the network once it's running. How and where they need to register the `pool_transactions_genesis` depends on how they setup their `indy-cli` environment; [Installing the `indy-cli`](./CLIInstall.md) + + - The Stewards will also need to download the genesis files onto their nodes while completing the setup. All of the following steps are to be completed on the node. + 1. Set the network name in `/etc/indy/indy_config.py`, replacing `` in the following command with the actual network name; + + `sudo sed -i -re "s/(NETWORK_NAME = ')\w+/\1/" /etc/indy/indy_config.py` + + 1. Create a network directory and download the genesis files into it. _The directory name must be the same on all of the nodes and it must match the name of the network._ + 1. `sudo -i -u indy mkdir /var/lib/indy/` + 1. `cd /var/lib/indy/` + 1. `sudo curl -o domain_transactions_genesis ` + 1. `sudo curl -o pool_transactions_genesis ` + 1. `sudo chown indy:indy *` + - It is important the files are owned by `indy:indy`. + +## V. Schedule a meeting to instantiate the new network + + Invite all Genesis Stewards to a meeting where they can execute commands and share their screens for both an `indy-cli` and for their Validator Nodes being added to the Network. + + > NOTE: It is very useful to go through some checks for each node to verify their setup before continuing. Some large amounts of debug and recovery work can be avoided by 5-10 minutes of checking configs of each node at the beginning of the meeting. + > - `/etc/indy/indy_config.py` + > - all nodes need to have the same network name. + > - the name of the network should correspond to the `/var/lib/indy/` directory on each node which contains the genesis files for the network, and the files in the directory should be owned by `indy:indy`. + > - `/etc/indy/indy.env` + > - all nodes should have local ip addresses in this file and be pointing at the correct ports. + > - Genesis files + > - Ensure both `pool_transactions_genesis` and `domain_transactions_genesis` files contain the expected content. + > - Verify the software version on all the nodes match + > ``` + > dpkg -l | grep indy + > dpkg -l | grep sovrin + > ``` + > - Network Connectivity + > - Use `nc -l ` (on the host), and `nc -vz ` (on the remote) to test the following. + > - Check the network connectivity between nodes using the `node_ip:port` combinations. Ensure that each node can communicate with all of the other nodes. + > - Check the network connectivity between the nodes and a client using the `client_ip:port` combinations. Ensure each node is accessible to client machines. + + Once all of the checks are complete have the Stewards simultaneously start their nodes as described in section [3.5.2. Enable the Service](../installation-and-configuration.md#3.5.2.-Enable-the-Service) of the Installation and configuration of Indy-Node guide, and walk though the remainder of that guide. + +## VI. Configure the Indy Network + +### `auth_rules` + Update the network's `auth_rules` to help enforce the governance rules for the network. + + For more information on `auth_rules` refer to: + - [Default AUTH_MAP Rules](../auth_rules.md) + - [auth_rules Walkthough](https://docs.google.com/document/d/1xk0A5FljKOZ2Fazri6J5mAfnYWXdOMl2LwrFK16MJIY) + +### `TAA` (Transaction Author Agreements) + Add a `TAA` to the network. + + For more information on `TAA`s refer to: + - [Transaction Author Agreement - `indy-sdk`](https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/transaction-author-agreement.md) + - [Transaction Author Agreement - `indy-plenum`](https://github.com/hyperledger/indy-plenum/blob/master/docs/source/transaction_author_agreement.md) + - [Transaction Author Agreement Design](../../../design/txn_author_agreement.md) + - [TAA for CLI Walkthrough](https://docs.google.com/document/d/1Ma-EJkYpRfPOZApyEvcWrkb4EKn71XrIFd9KvZL0Whg) + +## Where to go from here? + + ### Add more Nodes + + For the network to remain in write consensus in the event of node failures the network needs to be comprised of `3f+1` nodes, where `f` is the number of failed nodes. + + For a network of 4 nodes the network can remain in write consensus if a single node at a time fails, however if more than a single node fails at a time the network will loose write consensus and go into a read-only state. Similarly, a network comprised of 7 nodes can withstand up to 2 nodes failing at any given time. Therefore, it's recommended to have at least 7 nodes running in your network. + + Examples: + + | Failures to Withstand | 3f+1 | Required Nodes | + |--|--|--| + | 1 | 3(1)+1 | 4 | + | 2 | 3(2)+1 | 7 | + | 3 | 3(3)+1 | 10 | + + ### Network Monitoring + + [hyperledger/indy-node-monitor](https://github.com/hyperledger/indy-node-monitor) is the community supported and maintained tool for network monitoring. + + #### Manual + - Run `indy-node-monitor` at least three times a day to detect any issues with the network. + + #### Automated + - Run `indy-node-monitor` on a schedule (every 15-30 minutes) and add a notification plugin to alert you to any issues. _Please consider contributing your work back to the project._ + +## Hands On Walkthrough + + An example walkthrough of the above mentioned steps can be found in the `sample/Network` [folder](../../../sample/Network/README.md). diff --git a/docs/source/configuring-2nics.md b/docs/source/configuring-2nics.md new file mode 100644 index 000000000..38f7faa22 --- /dev/null +++ b/docs/source/configuring-2nics.md @@ -0,0 +1,148 @@ +# Configuring a 2 NIC Node +First some caveats and warnings. These are notes based on setting up 2 NICs on an AWS VM. It might be possible to adapt them for other environments as well, particularly the "Configure Network Interfaces in Ubuntu" section. + +>WARNING: +When you are doing network configuration, it is very possible to put your VM into a state where you are no longer able to log into it over the network. This may be difficult or impossible to recover from. Be very careful. If you have questions, doubts, or just need help, reach out prior to following these instructions. + +## Initial networking steps in an AWS console +Create security group "validator client" +- Port 22 for ssh +- Port 9702 for Validator client connections + + +Create security group "validator inter-node" +- Port 9701 for Validator inter-node connections +- Initially set up your Validator IP address to accept connections from anywhere, but later modify it as follows to only allow connections from specific IP addresses. + - To generate an allow list, run the following command on a Validator Node: + + `current_validators.py --writeJson | node_address_list.py --outFormat aws` + +Setup Validator instance +1. Provision VM + - Use security group "validator client" for the default network interface + - make note of the instance ID when completed +2. Add and configure a 2nd network interface in AWS. + - On EC2 left side menu - Network & Security -> Network Interfaces -> Create Network Interface + 1. Subnet -> Select a different subnet in the same zone as your instance + 2. Private IP -> auto assign + 3. Security groups -> validator inter-node + - On the main screen, select the new interface and click the Attach button + Find and select the instance ID (recorded in step 1) +3. Note the Network Interface ID of each network interface + - On EC2 left side menu - INSTANCES -> Instances + - Select your instance + - At the bottom of the screen select the description tab and scroll down to ‘Network interfaces’ + - Click on each interface and then record the ‘Interface ID’ and the ‘Private IP Address’ for later use. +4. Create 2 Elastic IP’s, 1 for each NIC, and associate them with the network interfaces + - On EC2 left side menu - Network & Security ->Elastic IPs + 1. Click Allocate New Address + 1. Give your new addresses appropriate names so that you can identify them later. (i.e. BuilderNet Client and BuilderNet Inter-Node) + 2. I used Amazon IP addresses, but you can use your own if you like + 3. Repeat steps 1 and 2 to create a second Elastic IP + 2. For each new Elastic IP do the following: + 1. Select one of the Elastic IP’s you just created + 2. Click Actions -> Associate address + - Resource type -> ‘Network interface’ + - Network Interface -> + - Private IP -> (there should only be one option and it should match the internal IP address of the chosen interface) + - Leave checkbox empty (this might not matter) + - Click “Associate” + 3. Make sure you do this for both interfaces of your instance + +## Configure the Network Interfaces in Ubuntu +1. Disable automatic network management by AWS. (These steps are for AWS users only and will keep AWS from overwriting your settings) Run the following from the Ubuntu command line: +`sudo su -` +`echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg` +>WARNING: The following steps use the common network interface names eth0 and eth1. You must substitute the interface device names used by your system or your instance will lose its network connection and you might not be able to reattach to it. +2. Run the following steps from the Ubuntu command line: + + a. `ip a` + - Record the interface device names and their local IP addresses for later use. + + b. `route -n` + - Record the Gateway for later use. + + c. `cd /etc/network/interfaces.d` + + d. `vim 50-cloud-init.cfg` + - Cut the existing eth0 lines from this file in preparation for moving them to a new file in this same directory. + - Example 50-cloud-init.cfg now looks like: + ``` + auto lo + iface lo inet loopback + ``` + + e. `vim eth0.cfg (use .cfg if your interface name is not eth0)` + - Paste the eth0 lines cut from the 50-cloud-init.cfg file and add the following lines, indented 3 spaces: + ``` + up ip route add default via dev tab 1 + up ip rule add from >/32 tab 1 + up ip rule add to >/32 tab 1 + up ip route flush cache + ``` + - Example eth0.cfg + ``` + auto eth0 + iface eth0 inet dhcp + up ip route add default via 172.31.32.1 dev eth0 tab 1 + up ip rule add from 172.31.33.147/32 tab 1 + up ip rule add to 172.31.33.147/32 tab 1 + up ip route flush cache + ``` + + f. Repeat step `e` but for the second network interface: + - `cp eth0.cfg eth1.cfg` + - `vi eth1.cfg` + - Replace all instances of eth0 with eth1 + - Change to the one corresponding to eth1 + - Change ‘tab 1’ to ‘tab 2’ + - Example eth1.cfg + ``` + auto eth1 + iface eth1 inet dhcp + up ip route add default via 172.31.32.1 dev eth1 tab 2 + up ip rule add from 172.31.35.63/32 tab 2 + up ip rule add to 172.31.35.63/32 tab 2 + up ip route flush cache + ``` + g. `ifup eth1` + - Check to make sure eth1 came up and is working properly. If the eth0 interface becomes unusable, you should then be able to log in through eth1 to fix it. +3. Reboot your machine + +## Tests +If the configuration is working, you should be able to connect a "listener" process to the IP address and port for the client connections. Then from a different, client machine, you should be able to reach that port on that IP address, firewalls permitting. You should also be able to do the same thing for the node IP address and port. Netcat is ubiquitous and convenient for these tests. + +On the Validator: +``` +nc -l < client port> +``` +On the client machine: +``` +nc -v -z +``` +Expected result: +``` +Success! +``` +On the Validator: +``` +nc -l < node port> +``` +On the client machine: +``` +nc -v -z +``` +Expected result: +``` +Success! +``` +Other combinations should fail or not return. Note that in AWS, the netcat commands executed on the Validator should use the private IP address, and the netcat commands executed on the client should use the public IP (Elastic) address. + +Finally, remember to later modify firewalls to allow and deny traffic: + +On client IP address, allow: +- Port 22 from your home network(s). +- Port 9702 (or whatever you have configured for clients) from anywhere. + +On node IP address, allow +-Port 9701 (or whatever you have configured for inter-validator) from an allow list of other Validators. diff --git a/docs/source/index.rst b/docs/source/index.rst index b56ef6cb0..a5508c2e8 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -23,7 +23,12 @@ Welcome to Hyperledger Indy Node's documentation! indy-file-structure-guideline.md write-code-guideline.md setup-dev.md - + installation-and-configuration.md + configuring-2nics.md + NewNetwork/NewNetwork.md + NewNetwork/CLIInstall.md + NewNetwork/CreateDID.md + NewNetwork/CreateValidatorKeys.md diff --git a/docs/source/installation-and-configuration.md b/docs/source/installation-and-configuration.md new file mode 100644 index 000000000..bdb124505 --- /dev/null +++ b/docs/source/installation-and-configuration.md @@ -0,0 +1,418 @@ +# Installation and configuration of Indy-Node + +## 1. Introduction +The purpose of this document is to describe how to setup a production level Indy-Validator-Node and register it on an existing network using an `indy-cli` machine which you also configure along the way. This documentation is based heavily on the [Sovrin Steward Validator Preparation Guide v3](https://docs.google.com/document/d/18MNB7nEKerlcyZKof5AvGMy0GP9T82c4SWaxZkPzya4). + +For information on how to setup a new network, refer to [New Network](./NewNetwork/NewNetwork.md) + +## 2. Preliminaries to the Set Up +Before you start this process, you’ll need to gather a couple of things and make a few decisions. + +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 Steward to post transactions to the ledger. +- Your Steward distributed identity (DID) + - This is public information that is generated based on your Steward Seed. It is an identifier for your organization that will be written to the ledger by an Indy network Trustee. +- Your Steward verification key (verkey) + - This is public information that is generated based on your Steward Seed. It will be written to the ledger by an Indy 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 allow-listed in 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 + - A human readable name for your node. This value is case sensitive. +- The Validator node seed + - This is distinct from your Steward seed and will be used to generate public and private keys that your Validator node will use for communications with other Validators. Like the Steward Seed, it should be kept secure. +- The Validator Node Identifier + - This is distinct from your Steward verkey. It is also public information that will be placed on the ledger but is used as a public key by your Validator node, rather than by you, the Steward. +- 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 BLS key proof-of-possession (pop) + - A cryptographic check against certain forgeries that can be done with BLS keys. + +### 2.1 Two Machines +You’ll need two machines: one is your Validator node and the other an `indy-cli` machine to run the `indy-cli` with which you will interact with the ledger. They can be physical machines, virtual machines, or a combination. The machine with the `indy-cli` can be turned on and off at your convenience (refer to [3.1. `indy-cli` Machine Installation](##3.1.-indy-cli-Machine-Installation) for more details), only the Validator node needs to be public and constantly running. + +>Important: for security reasons, you must not use your Validator node as an `indy-cli` client. If you do, it could expose your Steward credentials needlessly. + +Your Validator **must run Ubuntu 16.04 (64-bit)** as, _at the time of writing_, this is the only version that has a verified and validated release package. Work is actively being done on an Ubuntu 20.04 release. This guide presupposes that your `indy-cli` machine will run on Ubuntu as well. + +Your Validator node should have two NICs, each with associated IP addresses and ports. One NIC will be used for inter-validator communication, and the other for connections from clients, including Indy 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 NIC for inter-validator communications should be behind a firewall that is configured to be much more restrictive of inbound connections than the client-facing NIC is. + +It is currently possible to have just one NIC and IP address, as the transition for older Stewards to change to 2 NICs is ongoing. The inability to or delay of adding a second NIC will likely affect which network your node will be placed on. A resource that may help you to configure your node to use two NICs is described ind [Configuring a 2 NIC Node](./configuring-2nics.md) + +### 2.2 Validator Node Preliminary Information + +#### Get the IP Addresses +Your Validator node will be the machine that will become a part of an Indy 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. + +Obtain IP addresses that meet this requirement. + +#### 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. +- Client Port: TCP + - Clients use this IP address and port combination to communicate with the Validator node, to interact with the ledger. + +By convention, please choose ports 9701 and 9702 for your Node and Client ports, respectively. + +#### 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. It need not reference your company name; however it should be distinguishable from the other Validator nodes on the network. Many Stewards choose a Validator alias that identifies their organization, for pride of their contribution to the cause of self-sovereign identity. + + +## 3. Setup and Configuration + +Some instructions must be executed on the Validator node, and others on the `indy-cli` machine. The command line prompts in the instructions will help remind you which machine should be used for each command. + +### 3.1. `indy-cli` Machine Installation + +The following instructions describe how to install and configure the `indy-cli` directly on a machine or VM. The other, possibly more convenient, option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) + +#### 3.1.1. Install the `indy-cli` +On the machine you’ve chosen for the `indy-cli`, open a terminal and run the following lines to install the `indy-cli` package. + +``` +ubuntu@cli$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 +ubuntu@cli$ sudo apt-get install -y software-properties-common python-software-properties +ubuntu@cli$ sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable" +ubuntu@cli$ sudo add-apt-repository "deb https://repo.sovrin.org/deb xenial stable" +ubuntu@cli$ sudo apt-get update -y +ubuntu@cli$ sudo apt-get upgrade -y +ubuntu@cli$ sudo apt-get install -y indy-cli +``` + +#### 3.1.2. Add an Acceptance Mechanism +To write to an Indy Node Ledger, you’ll need to sign the Transaction Author Agreement (TAA). You can learn more about the TAA [here](https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/transaction-author-agreement.md). This agreement 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 `indy-cli`: + +Create a JSON config file containing your taaAcceptanceMechanism. (You can also add plugins to this config file, but for now just set it up as basic as possible.) + +This example cliconfig.json file contains the line that sets the AML: +```json +{ +"taaAcceptanceMechanism": "for_session" +} +``` + +To start the `indy-cli` using your new config file, run the following: +`ubuntu@cli$ indy-cli --config /cliconfig.json` + +Now all of the appropriate transactions will have an “Agreement Accepted” authorization attached to them during this `indy-cli` session. + +#### 3.1.3. Obtain the Genesis Files +Obtain the genesis transaction files for the Network with the following steps. For the sake of this documentation, we will use the genesis files from the Sovrin Networks. Information on how to create a genesis file can be found [here](./NewNetwork/NewNetwork.md). These files contain bootstrap information about some of the Validator nodes, which will be used by your `indy-cli` to connect to the networks. + +If you are at the `indy` prompt, please exit: + +`indy> exit` + +Most Stewards will currently be onboarded to the BuilderNet. Obtain the genesis transaction file for it: + +`ubuntu@cli$ cd ` + +`ubuntu@cli:~ $ curl -O https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis` + +You will also want to obtain the genesis files for the StagingNet and MainNet, for the possibility of moving between networks: + +``` +ubuntu@cli:~ $ curl -O https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_sandbox_genesis +ubuntu@cli:~ $ curl -O https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_live_genesis +``` + +#### 3.1.4. Generate the Steward Key +Next, generate a Steward key using the `indy-cli` machine you just installed. This will be comprised of a public and private key pair, generated from a seed. Knowing your seed will allow you to regenerate the key 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. If your seed falls into the wrong hands, someone could regenerate your private key, and take over your identity on the ledger. Keys can be rotated, which can stop some of the damage, but damage will still have been done. + +>Note: +It is the same procedure as described in [CreateDID](./NewNetwork/CreateDID.md). + +In the terminal, run the following to install a good random string generator, and then use it to generate your seed: +``` +ubuntu@cli$ sudo apt install pwgen +ubuntu@cli$ pwgen -s 32 1 +``` +EXAMPLE: +``` +ubuntu@cli$ 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. You will need it later in this guide, as well as in the future for other Steward interactions with the ledger. + +##### Run the `indy-cli` and generate key +Next we run the `indy-cli` by entering: + +`ubuntu@cli$ indy-cli --config /cliconfig.json` + +In the command line, enter the following to create your pool configuration and your wallet locally. In these instructions, we use "buildernet" for the pool name and "buildernet_wallet" for the wallet name, although you may use other names of your choosing, if desired. 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 of your local wallet. + +``` +indy> pool create buildernet gen_txn_file=pool_transactions_builder_genesis +indy> wallet create buildernet_wallet key +``` +Upon entering this command, you’ll see a prompt to enter your wallet key. Enter the key and hit enter. + +>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 as well. + +Using the pool configuration and wallet you have created, connect to the pool and open the wallet: + +`indy> pool connect buildernet` + +When you connect to a Network with TAA enabled, you will be asked whether you want to view the Agreement. Type ‘y’ to accept to see the Agreement, then select ‘y’ again to accept the Agreement displayed. If you do not accept the agreement, then you will not be allowed to write to the Network. + +`indy> wallet open buildernet_wallet key` + +`` + +Using the seed that you generated with pwgen, place your public and private keys into your wallet. + +`indy> did new seed` + +`` + +The result should look something like this: + +`Did "DIDDIDDIDDIDDIDDIDDID" has been created with "~VERKEYVERKEYVERKEYVERKEY" verkey` + +>IMPORTANT: Save the “DID” and “verkey” portions of this. They are not secret, but they will be used when you are prompted to supply your Steward verkey and DID. + +### 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 ensure 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 (inter-validator) IP address/port. + +##### 3.2.1.1 Test the node (inter-validator) connection to your Validator +Use netcat to listen on the "node" IP address and port of your Validator + +>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 local address to listen on, and the public address to ping with. + +`ubuntu@validator$ nc -l ` + +The above command will wait for a connection. On a system that can be used as a client, such as your `indy-cli` machine, do a TCP ping of that IP address and port: + +`ubuntu@cli$ nc -vz ` + +If the test is successful, the ping will return a "succeeded" message and the commands on both nodes will exit. + +##### 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 `indy-cli` machine’s IP address. Reminder: The Validator node has a node IP address for communications with other Validators and a “client” IP address for communications with edge agents (anything outside the Network of Validators). + +On your Validator: + +`ubuntu@validator$ nc -l ` + +On your client: + +`ubuntu@cli$ nc -vz ` + +If the test is successful, the ping will return a "succeeded" message and the commands on both nodes will exit. + +>IMPORTANT: +If your system uses NAT, the same approach should be used as above. + +##### 3.2.1.3 Test the connection from your node to another Validator on the BuilderNet +One of the Validator nodes on the BuilderNet is named "FoundationBuilder", which has a node IP address and port of 50.112.53.5 and 9701, respectively. On your Validator, make sure that your node is able to connect to this node on BuilderNet by TCP pinging its node IP address and port: + +``` +ubuntu@validator$ nc -vz 50.112.53.5 9701 +Connection to 50.112.53.5 9701 port [tcp/*] succeeded! +``` +When the above three tests are successful, you may proceed. + +#### 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. + +``` +ubuntu@validator$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 +ubuntu@validator$ sudo apt-get install -y software-properties-common +ubuntu@validator$ sudo add-apt-repository "deb https://repo.sovrin.org/deb xenial stable" +ubuntu@validator$ sudo apt update +ubuntu@validator$ sudo apt upgrade -y +ubuntu@validator$ sudo apt install -y sovrin +``` +#### 3.2.3 Create the Key for the Validator Node + +>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 local addresses for the init_indy_node command. + +Please run the following on the Validator before running `init_indy_node`. + +In the `/etc/indy/indy_config.py` file, change the Network name from “sandbox” (Sovrin StagingNet) to “net3” (Sovrin BuilderNet) (use sudo to edit the file or use `sudo sed -i -re "s/(NETWORK_NAME = ')\w+/\1net3/" /etc/indy/indy_config.py)` then run the following commands: +``` +sudo -i -u indy mkdir /var/lib/indy/net3 +cd /var/lib/indy/net3 +sudo curl -o domain_transactions_genesis https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/domain_transactions_builder_genesis +sudo curl -o pool_transactions_genesis https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis +``` +Make sure that both genesis files are owned by `indy:indy` by running: + +`sudo chown indy:indy *` + +Enter the following where `` is the alias you chose for your Validator node machine and `, , and ` are the correct values for your Validator. + +>Note: The node IP and client IP addresses should be the LOCAL addresses for your node. + +`ubuntu@validator$ sudo -i -u indy init_indy_node ` + +You will see 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 +``` + +**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 keys for you in your Steward role). The Validator verification key and BLS key (with its POP) are public and will be published on the ledger. + +>The random seed should be protected from disclosure. + +### 3.3 Run the Technical Verification Script +>Note: +These steps are only required for becoming a Steward in Sovrin Networks. +However, you could incorporate this process into your own Network registration procedures. + +Download this script and set the execution flag on it: + +``` +ubuntu@validator$ cd ~ +ubuntu@validator$ curl -O https://raw.githubusercontent.com/sovrin-foundation/steward-tools/master/steward_tech_check.py +``` +`ubuntu@validator$ chmod +x steward_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 ./steward_tech_check.py` + +After the script completes, copy the output beginning at '== Results for "A Steward MUST" ==', and send the results to the support team of the related network for review. + +### 3.4. Provide Information to Trustees +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 and Proof of possession (pop) + +### 3.5. Add Node to a Pool + +>DO NOT proceed further with this document until your Steward DID and verkey (the public key) is on the ledger. + +#### 3.5.1 Configuration +After you have been informed that your public key has been placed onto the ledger of the Network, you may complete the configuration steps to activate your Validator node on that network. + +Things to verify before activating the node: +- `cat /etc/indy/indy_config.py` + - Ensure the network configuration is correct. +- `cat /etc/indy/indy.env` + - Verify the node alias and IPs +- `cat /var/lib/indy/net3/domain_transactions_genesis` + - Verify the file contains the correct content. +- `cat /var/lib/indy/net3/pool_transactions_genesis` + - Verify the file contains correct content. + +##### 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. + +Verify Versions +``` +dpkg -l | grep indy +``` + +##### Add Validator Node to Ledger +On your `indy-cli` machine, if you are not still on the `indy-cli` prompt, you will need to return to it. To get back to where you were, type `indy-cli --config /cliconfig.json`, connect to the network pool, designate the wallet to use (using the same wallet key as before), and enter the DID that was returned earlier, when you typed `did new seed` (then enter your seed) for your Steward user: + +``` +ubuntu@cli$ indy-cli --config /cliconfig.json +indy> pool connect buildernet +indy> wallet open buildernet_wallet key= +indy> did use +``` + +>Note: You may need to create a new wallet and run `did new seed` then enter `` instead, if you did not save your wallet or forgot your wallet key. + +If the connection is successful, enter the following, substituting the correct data as appropriate. An example follows. + +>Suggestion: Edit this in a text editor first, then copy and paste it into the `indy-cli`. Some editors will insert 'smart quotes' in place of regular ones. This will cause the command to fail. + +>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. + +``` +indy> ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop= +``` + +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. + +Start the Validator service: + +`ubuntu@validator$ sudo systemctl start indy-node` + +Verify the start: + +`ubuntu@validator$ sudo systemctl status indy-node.service` + +Enable the service so that it will auto-restart when your node reboots: + +`ubuntu@validator$ sudo systemctl enable 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, like what often exists on the BuilderNet, 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. + +To check that messages and connections are occurring normally you can run the following commands to follow the log file: +In the Validator node: + +`ubuntu@validator$ sudo tail -f /var/log/indy/net3/.log` + diff --git a/docs/source/start-nodes.md b/docs/source/start-nodes.md index 24c85887a..d3d1be71c 100644 --- a/docs/source/start-nodes.md +++ b/docs/source/start-nodes.md @@ -1,6 +1,6 @@ # Create a Network and Start Nodes -Please be aware that recommended way of starting a pool is to [use Docker](https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md). +Please be aware that recommended way of starting a pool for development is to [use Docker](https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md). In order to run your own Network, you need to do the following for each Node: 1. Install Indy Node diff --git a/sample/Network/DIDs.txt b/sample/Network/DIDs.txt new file mode 100644 index 000000000..1ac98944d --- /dev/null +++ b/sample/Network/DIDs.txt @@ -0,0 +1,71 @@ +newNetwork:indy> did new seed=000000000000000000000000Trustee1 + Did "V4SGRU86Z58d6TV7PBUe6f" has been created with "~CoRER63DVYnWZtK8uAzNbx" verkey + newNetwork:indy> did new seed=000000000000000000000000Trustee2 + Did "LnXR1rPnncTPZvRdmJKhJQ" has been created with "~RTBtVN3iwcFhbWZzohFTMi" verkey + newNetwork:indy> did new seed=000000000000000000000000Trustee3 + Did "PNQm3CwyXbN5e39Rw3dXYx" has been created with "~AHtGeRXtGjVfXALtXP9WiX" verkey + + + newNetwork:indy> did new seed=000000000000000000000000Steward1 + Did "Th7MpTaRZVRYnPiabds81Y" has been created with "~7TYfekw4GUagBnBVCqPjiC" verkey + newNetwork:indy> did new seed=000000000000000000000000Steward2 + Did "EbP4aYNeTHL6q385GuVpRV" has been created with "~RHGNtfvkgPEUQzQNtNxLNu" verkey + newNetwork:indy> did new seed=000000000000000000000000Steward3 + Did "4cU41vWW82ArfxJxHkzXPG" has been created with "~EMoPA6HrpiExVihsVfxD3H" verkey + newNetwork:indy> did new seed=000000000000000000000000Steward4 + Did "TWwCRQRZ2ZHMJFn9TzLp7W" has been created with "~UhP7K35SAXbix1kCQV4Upx" verkey + + + + + $ init_indy_node Steward1 0.0.0.0 9701 0.0.0.0 9702 + Node-stack name is Steward1 + Client-stack name is Steward1C + Generating keys for random seed b'88c26d3C92bc33Be077Bf22FCBa60E2A' + Init local keys for client-stack + Public key is DGM7x7SQvjKjfUa7VLo5gGCZ6WfKASo6Cp5uP3aBRf7j + Verification key is DJrzRm3ahRkz2pesFVtmH8wA3S3z63XayZgDvV21b4BF + Init local keys for node-stack + Public key is DGM7x7SQvjKjfUa7VLo5gGCZ6WfKASo6Cp5uP3aBRf7j + Verification key is DJrzRm3ahRkz2pesFVtmH8wA3S3z63XayZgDvV21b4BF + BLS Public key is 3k9aPxmqMYY4QQ3MK88Pot5QmqxfaaxuzMeGnKYT8j1Ds1Rcmq2zmjQmLMtKvBzC89E7yCQyiQ9HEDcGAZi6zmarMCQNkY9oYCAUVJGrZgxBE4a1oj7VYKw7zuGpMwsKLPGLcTGwpmX9LS6f5ykbazEwEgQRTiWj2epRKxZC87DLwbH + Proof of possession for BLS key is RT5vLkN7639sXwYMBWkuFnzSM7ezEb49ZZExf6htH1WBWyuYgJsRTqT71HWaizfFLi1zp63eNGKKVzzyMaETYoj8QoV3GejHeZzP7LydJQpHQ5VPuLW3NUy5BGH4Xt7RkCT5pUbwhjz6mwxXfGAtQot7kiMH18QrpcazAmHrFPXKe7 + + $ init_indy_node Steward2 0.0.0.0 9703 0.0.0.0 9704 + Node-stack name is Steward2 + Client-stack name is Steward2C + Generating keys for random seed b'Fa4F5cd101f891ca0Cfa4E02C9Bf1769' + Init local keys for client-stack + Public key is FF3Aq98cJ2QT5EDmtshfVkgyjm9dxJV7xbtFrtMQbKeD + Verification key is EQJ92vJVaAihejc9N2Yqy59L7ixVKMx2FgaXxD8F6vs7 + Init local keys for node-stack + Public key is FF3Aq98cJ2QT5EDmtshfVkgyjm9dxJV7xbtFrtMQbKeD + Verification key is EQJ92vJVaAihejc9N2Yqy59L7ixVKMx2FgaXxD8F6vs7 + BLS Public key is XvFCAC84AjEzcLFfdNQq17rGxheUbd95MCTkg8Bw3CNRR61isy5uNiqaoxZgNZac2MEvZoXX7Wk27YUMB9mc4XFdAHRJiVVs3UcB3giBuhbv4om6GjouGcKWYsFkffA4tvWPyeDDn5ifxZaJBDHVR4AHcvUNxFipGnEptFSDzayzBG + Proof of possession for BLS key is RXfySA7HWDh57hm3GRKqj1DcMPq66fLJHMzaN76U1XqdUaRTRmBtxgSREtEvudSNFL8woXJzqS7VnJehZNd8hXf4bipdBhJ4J7hzBwhpbXfsuH2yH6XExBrxyPCwyQ9K9RAQraHz2RTLhs8r93HNzjauUARbw5ADv2F42FW69kWbdR + + $ init_indy_node Steward3 0.0.0.0 9705 0.0.0.0 9706 + Node-stack name is Steward3 + Client-stack name is Steward3C + Generating keys for random seed b'A59c0EFB9cD7Eccdd4483a3BFbd36EB5' + Init local keys for client-stack + Public key is H3oLLToN9Wy1Yb9R9EMZXot8xCTnQLWMiSHRCpQm9fRD + Verification key is EktpqGnexWaiQyr9vcXDTgNYwqT8cxmAfnX8N7qWwEcC + Init local keys for node-stack + Public key is H3oLLToN9Wy1Yb9R9EMZXot8xCTnQLWMiSHRCpQm9fRD + Verification key is EktpqGnexWaiQyr9vcXDTgNYwqT8cxmAfnX8N7qWwEcC + BLS Public key is 13U7tXXXRTLeavMEQk7MqECuKkuFrHPAwidf2cVqhaJoABmHc4SBMXHVJJkc1pJNvjLu894UZ6pSt3aAYZ5nQrfkuqbBUEToWb5vZSLHTTNnznkzx5PStPFSZkYUuA4bYNLk5b8GbwrHFKjrjqzCdjEWs2hDipAmXfd9NBh3BTEwAxS + Proof of possession for BLS key is RHeKLLefbDdgBMpZ9AUrS8EHPDRnFXNiJ1z8LUgqPa8eUGyeRkAR2ppPkYqcLc9ekzG8cYZMTGx8y52sZ1q2QWqs3BYBH2i3H2WxL4icRq9Kj4kqs3BQadtPWBSq4vEaWTwwieuUXFYqpvk1ALCSNmS9NmMYXYyTL8uzrstviomjXm + + $ init_indy_node Steward4 0.0.0.0 9707 0.0.0.0 9708 + Node-stack name is Steward4 + Client-stack name is Steward4C + Generating keys for random seed b'F20fc06eab86A896A6Ae5D8AfEA46B68' + Init local keys for client-stack + Public key is GJVyfv4XXGHYDYmiifu8XmXyTx9jGb39hACRU23rT9Ww + Verification key is 8XFTwX3rHVUBddyruNTzKnBdbFqWz8eZPRasyySLD7Sv + Init local keys for node-stack + Public key is GJVyfv4XXGHYDYmiifu8XmXyTx9jGb39hACRU23rT9Ww + Verification key is 8XFTwX3rHVUBddyruNTzKnBdbFqWz8eZPRasyySLD7Sv + BLS Public key is oy7vASnhYAYo9fV1MzFSeCHEmyd2dQze6dmwWd5unwoySsA2UauUaKpV6QqwL9WQzQYRXZAoDT9jXGWwGFgCKWKVinFPj2TU5qsqAFt6PcXxQ7ZpBMEiUhQreqQv9BQsb7Upx9cNZKm4wKRyjCryX3TELb3xzz51wwsdeY8hduAKvb + Proof of possession for BLS key is QsrUH1e5zsdiEGij1NeY9S7CwzUdU2rzjskHNGHCQ8rtgYZyBC99MgRPzgkJHP86nWQUo2fSRvyWLQdBwvWfNtSqUBQgVScQPHg9CJXWWohWnzSP4ViBo8EEeGXEoP2NPeRnFCCfuhYAC7stZgBATFyvdFRwG58ws76qQQQsfDDHBV diff --git a/sample/Network/README.md b/sample/Network/README.md new file mode 100644 index 000000000..15177b8ce --- /dev/null +++ b/sample/Network/README.md @@ -0,0 +1,132 @@ +# Hands on Walkthrough + +This walkthrough goes through some of the detailed steps mentioned in [Setting up a New Network](../../docs/source/NewNetwork/NewNetwork.md) + +For the sake of simplicity this walkthrough runs all of the nodes on the local machine. As a result it uses the local python install version of some of the commands rather than the production level Debian package install version of the commands documented in the [Setting up a New Network](../../docs/source/NewNetwork/NewNetwork.md) guide. + +1. Open indy-cli by executing `indy-cli` + + Note that the command prompt changed to `indy>`. + +2. Create and open a wallet in the indy-cli. + + `indy>wallet create newNetwork key=key` + + If not already opened, open the wallet + `indy> wallet open newNetwork key=key` + +3. Create DIDs for Trustees. + + ``` + newNetwork:indy> did new seed=000000000000000000000000Trustee1 + Did "V4SGRU86Z58d6TV7PBUe6f" has been created with "~CoRER63DVYnWZtK8uAzNbx" verkey + newNetwork:indy> did new seed=000000000000000000000000Trustee2 + Did "LnXR1rPnncTPZvRdmJKhJQ" has been created with "~RTBtVN3iwcFhbWZzohFTMi" verkey + newNetwork:indy> did new seed=000000000000000000000000Trustee3 + Did "PNQm3CwyXbN5e39Rw3dXYx" has been created with "~AHtGeRXtGjVfXALtXP9WiX" verkey + ``` + + > Warning: The used seed if used twice will result in the same DID and keys! + +4. Create DIDs for Stewards + + For the sake of this tutorial all DIDs and Stewards are running on the same machine. Normally this would be independent machines and organizations. + + ``` + newNetwork:indy> did new seed=000000000000000000000000Steward1 + Did "Th7MpTaRZVRYnPiabds81Y" has been created with "~7TYfekw4GUagBnBVCqPjiC" verkey + newNetwork:indy> did new seed=000000000000000000000000Steward2 + Did "EbP4aYNeTHL6q385GuVpRV" has been created with "~RHGNtfvkgPEUQzQNtNxLNu" verkey + newNetwork:indy> did new seed=000000000000000000000000Steward3 + Did "4cU41vWW82ArfxJxHkzXPG" has been created with "~EMoPA6HrpiExVihsVfxD3H" verkey + newNetwork:indy> did new seed=000000000000000000000000Steward4 + Did "TWwCRQRZ2ZHMJFn9TzLp7W" has been created with "~UhP7K35SAXbix1kCQV4Upx" verkey + ``` +5. Create Validator Node keys + + > The seed will be randomly generated. As mentioned above with the seed you can recreate the key! + + ``` + $ init_indy_node Steward1 0.0.0.0 9701 0.0.0.0 9702 + Node-stack name is Steward1 + Client-stack name is Steward1C + Generating keys for random seed b'88c26d3C92bc33Be077Bf22FCBa60E2A' + Init local keys for client-stack + Public key is DGM7x7SQvjKjfUa7VLo5gGCZ6WfKASo6Cp5uP3aBRf7j + Verification key is DJrzRm3ahRkz2pesFVtmH8wA3S3z63XayZgDvV21b4BF + Init local keys for node-stack + Public key is DGM7x7SQvjKjfUa7VLo5gGCZ6WfKASo6Cp5uP3aBRf7j + Verification key is DJrzRm3ahRkz2pesFVtmH8wA3S3z63XayZgDvV21b4BF + BLS Public key is 3k9aPxmqMYY4QQ3MK88Pot5QmqxfaaxuzMeGnKYT8j1Ds1Rcmq2zmjQmLMtKvBzC89E7yCQyiQ9HEDcGAZi6zmarMCQNkY9oYCAUVJGrZgxBE4a1oj7VYKw7zuGpMwsKLPGLcTGwpmX9LS6f5ykbazEwEgQRTiWj2epRKxZC87DLwbH + Proof of possession for BLS key is RT5vLkN7639sXwYMBWkuFnzSM7ezEb49ZZExf6htH1WBWyuYgJsRTqT71HWaizfFLi1zp63eNGKKVzzyMaETYoj8QoV3GejHeZzP7LydJQpHQ5VPuLW3NUy5BGH4Xt7RkCT5pUbwhjz6mwxXfGAtQot7kiMH18QrpcazAmHrFPXKe7 + + $ init_indy_node Steward2 0.0.0.0 9703 0.0.0.0 9704 + Node-stack name is Steward2 + Client-stack name is Steward2C + Generating keys for random seed b'Fa4F5cd101f891ca0Cfa4E02C9Bf1769' + Init local keys for client-stack + Public key is FF3Aq98cJ2QT5EDmtshfVkgyjm9dxJV7xbtFrtMQbKeD + Verification key is EQJ92vJVaAihejc9N2Yqy59L7ixVKMx2FgaXxD8F6vs7 + Init local keys for node-stack + Public key is FF3Aq98cJ2QT5EDmtshfVkgyjm9dxJV7xbtFrtMQbKeD + Verification key is EQJ92vJVaAihejc9N2Yqy59L7ixVKMx2FgaXxD8F6vs7 + BLS Public key is XvFCAC84AjEzcLFfdNQq17rGxheUbd95MCTkg8Bw3CNRR61isy5uNiqaoxZgNZac2MEvZoXX7Wk27YUMB9mc4XFdAHRJiVVs3UcB3giBuhbv4om6GjouGcKWYsFkffA4tvWPyeDDn5ifxZaJBDHVR4AHcvUNxFipGnEptFSDzayzBG + Proof of possession for BLS key is RXfySA7HWDh57hm3GRKqj1DcMPq66fLJHMzaN76U1XqdUaRTRmBtxgSREtEvudSNFL8woXJzqS7VnJehZNd8hXf4bipdBhJ4J7hzBwhpbXfsuH2yH6XExBrxyPCwyQ9K9RAQraHz2RTLhs8r93HNzjauUARbw5ADv2F42FW69kWbdR + + $ init_indy_node Steward3 0.0.0.0 9705 0.0.0.0 9706 + Node-stack name is Steward3 + Client-stack name is Steward3C + Generating keys for random seed b'A59c0EFB9cD7Eccdd4483a3BFbd36EB5' + Init local keys for client-stack + Public key is H3oLLToN9Wy1Yb9R9EMZXot8xCTnQLWMiSHRCpQm9fRD + Verification key is EktpqGnexWaiQyr9vcXDTgNYwqT8cxmAfnX8N7qWwEcC + Init local keys for node-stack + Public key is H3oLLToN9Wy1Yb9R9EMZXot8xCTnQLWMiSHRCpQm9fRD + Verification key is EktpqGnexWaiQyr9vcXDTgNYwqT8cxmAfnX8N7qWwEcC + BLS Public key is 13U7tXXXRTLeavMEQk7MqECuKkuFrHPAwidf2cVqhaJoABmHc4SBMXHVJJkc1pJNvjLu894UZ6pSt3aAYZ5nQrfkuqbBUEToWb5vZSLHTTNnznkzx5PStPFSZkYUuA4bYNLk5b8GbwrHFKjrjqzCdjEWs2hDipAmXfd9NBh3BTEwAxS + Proof of possession for BLS key is RHeKLLefbDdgBMpZ9AUrS8EHPDRnFXNiJ1z8LUgqPa8eUGyeRkAR2ppPkYqcLc9ekzG8cYZMTGx8y52sZ1q2QWqs3BYBH2i3H2WxL4icRq9Kj4kqs3BQadtPWBSq4vEaWTwwieuUXFYqpvk1ALCSNmS9NmMYXYyTL8uzrstviomjXm + + $ init_indy_node Steward4 0.0.0.0 9707 0.0.0.0 9708 + Node-stack name is Steward4 + Client-stack name is Steward4C + Generating keys for random seed b'F20fc06eab86A896A6Ae5D8AfEA46B68' + Init local keys for client-stack + Public key is GJVyfv4XXGHYDYmiifu8XmXyTx9jGb39hACRU23rT9Ww + Verification key is 8XFTwX3rHVUBddyruNTzKnBdbFqWz8eZPRasyySLD7Sv + Init local keys for node-stack + Public key is GJVyfv4XXGHYDYmiifu8XmXyTx9jGb39hACRU23rT9Ww + Verification key is 8XFTwX3rHVUBddyruNTzKnBdbFqWz8eZPRasyySLD7Sv + BLS Public key is oy7vASnhYAYo9fV1MzFSeCHEmyd2dQze6dmwWd5unwoySsA2UauUaKpV6QqwL9WQzQYRXZAoDT9jXGWwGFgCKWKVinFPj2TU5qsqAFt6PcXxQ7ZpBMEiUhQreqQv9BQsb7Upx9cNZKm4wKRyjCryX3TELb3xzz51wwsdeY8hduAKvb + Proof of possession for BLS key is QsrUH1e5zsdiEGij1NeY9S7CwzUdU2rzjskHNGHCQ8rtgYZyBC99MgRPzgkJHP86nWQUo2fSRvyWLQdBwvWfNtSqUBQgVScQPHg9CJXWWohWnzSP4ViBo8EEeGXEoP2NPeRnFCCfuhYAC7stZgBATFyvdFRwG58ws76qQQQsfDDHBV + ``` + +6. Fill in the spreadsheet. + +7. Download the script from [https://github.com/sovrin-foundation/steward-tools/tree/master/create_genesis] and generate the genesis file. + + ``` + $ python genesis_from_files.py --trustees Trustees.csv --stewards Stewards.csv + DEBUG:root:new line check for file: ./pool_transactions_genesis + INFO:root:Starting ledger... + INFO:root:Recovering tree from transaction log + INFO:root:Recovered tree in 0.002561586000410898 seconds + DEBUG:root:new line check for file: ./domain_transactions_genesis + INFO:root:Starting ledger... + INFO:root:Recovering tree from transaction log + INFO:root:Recovered tree in 0.000322740000228805 seconds + ``` +8. Edit `/etc/indy/indy_config.py` and change the network name. + `NETWORK_NAME = "newNetwork"` + +9. `mkdir /var/lib/indy/newNetwork` + +10. `cp domain_transactions_genesis /var/lib/indy/newNetwork/ && cp pool_transactions_genesis /var/lib/indy/newNetwork/` + +11. Start the nodes: + + ``` + start_indy_node Steward1 0.0.0.0 9701 0.0.0.0 9702 + start_indy_node Steward2 0.0.0.0 9703 0.0.0.0 9704 + start_indy_node Steward3 0.0.0.0 9705 0.0.0.0 9706 + start_indy_node Steward4 0.0.0.0 9707 0.0.0.0 9708 + ``` \ No newline at end of file diff --git a/sample/Network/Stewards.csv b/sample/Network/Stewards.csv new file mode 100644 index 000000000..2a47429f3 --- /dev/null +++ b/sample/Network/Stewards.csv @@ -0,0 +1,5 @@ +Steward name,Validator alias,Node IP address,Node port,Client IP address,Client port,Validator verkey,Validator BLS key,Validator BLS POP,Steward DID,Steward verkey +Steward1,Steward1,0.0.0.0,9701,0.0.0.0,9702,DJrzRm3ahRkz2pesFVtmH8wA3S3z63XayZgDvV21b4BF,3k9aPxmqMYY4QQ3MK88Pot5QmqxfaaxuzMeGnKYT8j1Ds1Rcmq2zmjQmLMtKvBzC89E7yCQyiQ9HEDcGAZi6zmarMCQNkY9oYCAUVJGrZgxBE4a1oj7VYKw7zuGpMwsKLPGLcTGwpmX9LS6f5ykbazEwEgQRTiWj2epRKxZC87DLwbH,RT5vLkN7639sXwYMBWkuFnzSM7ezEb49ZZExf6htH1WBWyuYgJsRTqT71HWaizfFLi1zp63eNGKKVzzyMaETYoj8QoV3GejHeZzP7LydJQpHQ5VPuLW3NUy5BGH4Xt7RkCT5pUbwhjz6mwxXfGAtQot7kiMH18QrpcazAmHrFPXKe7,Th7MpTaRZVRYnPiabds81Y,~7TYfekw4GUagBnBVCqPjiC +Steward2,Steward2,0.0.0.0,9703,0.0.0.0,9704,EQJ92vJVaAihejc9N2Yqy59L7ixVKMx2FgaXxD8F6vs7,XvFCAC84AjEzcLFfdNQq17rGxheUbd95MCTkg8Bw3CNRR61isy5uNiqaoxZgNZac2MEvZoXX7Wk27YUMB9mc4XFdAHRJiVVs3UcB3giBuhbv4om6GjouGcKWYsFkffA4tvWPyeDDn5ifxZaJBDHVR4AHcvUNxFipGnEptFSDzayzBG,RXfySA7HWDh57hm3GRKqj1DcMPq66fLJHMzaN76U1XqdUaRTRmBtxgSREtEvudSNFL8woXJzqS7VnJehZNd8hXf4bipdBhJ4J7hzBwhpbXfsuH2yH6XExBrxyPCwyQ9K9RAQraHz2RTLhs8r93HNzjauUARbw5ADv2F42FW69kWbdR,EbP4aYNeTHL6q385GuVpRV,~RHGNtfvkgPEUQzQNtNxLNu +Steward3,Steward3,0.0.0.0,9705,0.0.0.0,9706,EktpqGnexWaiQyr9vcXDTgNYwqT8cxmAfnX8N7qWwEcC,13U7tXXXRTLeavMEQk7MqECuKkuFrHPAwidf2cVqhaJoABmHc4SBMXHVJJkc1pJNvjLu894UZ6pSt3aAYZ5nQrfkuqbBUEToWb5vZSLHTTNnznkzx5PStPFSZkYUuA4bYNLk5b8GbwrHFKjrjqzCdjEWs2hDipAmXfd9NBh3BTEwAxS,RHeKLLefbDdgBMpZ9AUrS8EHPDRnFXNiJ1z8LUgqPa8eUGyeRkAR2ppPkYqcLc9ekzG8cYZMTGx8y52sZ1q2QWqs3BYBH2i3H2WxL4icRq9Kj4kqs3BQadtPWBSq4vEaWTwwieuUXFYqpvk1ALCSNmS9NmMYXYyTL8uzrstviomjXm,4cU41vWW82ArfxJxHkzXPG,~EMoPA6HrpiExVihsVfxD3H +Steward4,Steward4,0.0.0.0,9707,0.0.0.0,97008,8XFTwX3rHVUBddyruNTzKnBdbFqWz8eZPRasyySLD7Sv,oy7vASnhYAYo9fV1MzFSeCHEmyd2dQze6dmwWd5unwoySsA2UauUaKpV6QqwL9WQzQYRXZAoDT9jXGWwGFgCKWKVinFPj2TU5qsqAFt6PcXxQ7ZpBMEiUhQreqQv9BQsb7Upx9cNZKm4wKRyjCryX3TELb3xzz51wwsdeY8hduAKvb,QsrUH1e5zsdiEGij1NeY9S7CwzUdU2rzjskHNGHCQ8rtgYZyBC99MgRPzgkJHP86nWQUo2fSRvyWLQdBwvWfNtSqUBQgVScQPHg9CJXWWohWnzSP4ViBo8EEeGXEoP2NPeRnFCCfuhYAC7stZgBATFyvdFRwG58ws76qQQQsfDDHBV,TWwCRQRZ2ZHMJFn9TzLp7W,~UhP7K35SAXbix1kCQV4Upx \ No newline at end of file diff --git a/sample/Network/Trustees.csv b/sample/Network/Trustees.csv new file mode 100644 index 000000000..59604b6ea --- /dev/null +++ b/sample/Network/Trustees.csv @@ -0,0 +1,4 @@ +Trustee name,Trustee DID,Trustee verkey +Trustee1,V4SGRU86Z58d6TV7PBUe6f,~CoRER63DVYnWZtK8uAzNbx +Trustee2,LnXR1rPnncTPZvRdmJKhJQ,~RTBtVN3iwcFhbWZzohFTMi +Trustee3,PNQm3CwyXbN5e39Rw3dXYx,~AHtGeRXtGjVfXALtXP9WiX \ No newline at end of file diff --git a/sample/Network/domain_transactions_genesis b/sample/Network/domain_transactions_genesis new file mode 100644 index 000000000..8f1fbbd77 --- /dev/null +++ b/sample/Network/domain_transactions_genesis @@ -0,0 +1,7 @@ +{"reqSignature":{},"txn":{"data":{"alias":"Trustee1","dest":"V4SGRU86Z58d6TV7PBUe6f","role":"0","verkey":"~CoRER63DVYnWZtK8uAzNbx"},"metadata":{},"type":"1"},"txnMetadata":{"seqNo":1},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"alias":"Trustee2","dest":"LnXR1rPnncTPZvRdmJKhJQ","role":"0","verkey":"~RTBtVN3iwcFhbWZzohFTMi"},"metadata":{},"type":"1"},"txnMetadata":{"seqNo":2},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"alias":"Trustee3","dest":"PNQm3CwyXbN5e39Rw3dXYx","role":"0","verkey":"~AHtGeRXtGjVfXALtXP9WiX"},"metadata":{},"type":"1"},"txnMetadata":{"seqNo":3},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"dest":"Th7MpTaRZVRYnPiabds81Y","role":"2","verkey":"~7TYfekw4GUagBnBVCqPjiC"},"metadata":{"from":"PNQm3CwyXbN5e39Rw3dXYx"},"type":"1"},"txnMetadata":{"seqNo":4},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"dest":"EbP4aYNeTHL6q385GuVpRV","role":"2","verkey":"~RHGNtfvkgPEUQzQNtNxLNu"},"metadata":{"from":"PNQm3CwyXbN5e39Rw3dXYx"},"type":"1"},"txnMetadata":{"seqNo":5},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"dest":"4cU41vWW82ArfxJxHkzXPG","role":"2","verkey":"~EMoPA6HrpiExVihsVfxD3H"},"metadata":{"from":"PNQm3CwyXbN5e39Rw3dXYx"},"type":"1"},"txnMetadata":{"seqNo":6},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"dest":"TWwCRQRZ2ZHMJFn9TzLp7W","role":"2","verkey":"~UhP7K35SAXbix1kCQV4Upx"},"metadata":{"from":"PNQm3CwyXbN5e39Rw3dXYx"},"type":"1"},"txnMetadata":{"seqNo":7},"ver":"1"} diff --git a/sample/Network/pool_transactions_genesis b/sample/Network/pool_transactions_genesis new file mode 100644 index 000000000..7ba1f6f71 --- /dev/null +++ b/sample/Network/pool_transactions_genesis @@ -0,0 +1,4 @@ +{"reqSignature":{},"txn":{"data":{"data":{"alias":"Steward1","blskey":"3k9aPxmqMYY4QQ3MK88Pot5QmqxfaaxuzMeGnKYT8j1Ds1Rcmq2zmjQmLMtKvBzC89E7yCQyiQ9HEDcGAZi6zmarMCQNkY9oYCAUVJGrZgxBE4a1oj7VYKw7zuGpMwsKLPGLcTGwpmX9LS6f5ykbazEwEgQRTiWj2epRKxZC87DLwbH","blskey_pop":"RT5vLkN7639sXwYMBWkuFnzSM7ezEb49ZZExf6htH1WBWyuYgJsRTqT71HWaizfFLi1zp63eNGKKVzzyMaETYoj8QoV3GejHeZzP7LydJQpHQ5VPuLW3NUy5BGH4Xt7RkCT5pUbwhjz6mwxXfGAtQot7kiMH18QrpcazAmHrFPXKe7","client_ip":"0.0.0.0","client_port":"9702","node_ip":"0.0.0.0","node_port":"9701","services":["VALIDATOR"]},"dest":"DJrzRm3ahRkz2pesFVtmH8wA3S3z63XayZgDvV21b4BF"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"7e5d5f22d8c3c68c4532e0a336ba2db3276d12acf7820334bee49b5581d62277"},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"data":{"alias":"Steward2","blskey":"XvFCAC84AjEzcLFfdNQq17rGxheUbd95MCTkg8Bw3CNRR61isy5uNiqaoxZgNZac2MEvZoXX7Wk27YUMB9mc4XFdAHRJiVVs3UcB3giBuhbv4om6GjouGcKWYsFkffA4tvWPyeDDn5ifxZaJBDHVR4AHcvUNxFipGnEptFSDzayzBG","blskey_pop":"RXfySA7HWDh57hm3GRKqj1DcMPq66fLJHMzaN76U1XqdUaRTRmBtxgSREtEvudSNFL8woXJzqS7VnJehZNd8hXf4bipdBhJ4J7hzBwhpbXfsuH2yH6XExBrxyPCwyQ9K9RAQraHz2RTLhs8r93HNzjauUARbw5ADv2F42FW69kWbdR","client_ip":"0.0.0.0","client_port":"9704","node_ip":"0.0.0.0","node_port":"9703","services":["VALIDATOR"]},"dest":"EQJ92vJVaAihejc9N2Yqy59L7ixVKMx2FgaXxD8F6vs7"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"de75d0424859596a865ed9dab1eed1403849dc930dc591ada94d8cad09ecc9be"},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"data":{"alias":"Steward3","blskey":"13U7tXXXRTLeavMEQk7MqECuKkuFrHPAwidf2cVqhaJoABmHc4SBMXHVJJkc1pJNvjLu894UZ6pSt3aAYZ5nQrfkuqbBUEToWb5vZSLHTTNnznkzx5PStPFSZkYUuA4bYNLk5b8GbwrHFKjrjqzCdjEWs2hDipAmXfd9NBh3BTEwAxS","blskey_pop":"RHeKLLefbDdgBMpZ9AUrS8EHPDRnFXNiJ1z8LUgqPa8eUGyeRkAR2ppPkYqcLc9ekzG8cYZMTGx8y52sZ1q2QWqs3BYBH2i3H2WxL4icRq9Kj4kqs3BQadtPWBSq4vEaWTwwieuUXFYqpvk1ALCSNmS9NmMYXYyTL8uzrstviomjXm","client_ip":"0.0.0.0","client_port":"9706","node_ip":"0.0.0.0","node_port":"9705","services":["VALIDATOR"]},"dest":"EktpqGnexWaiQyr9vcXDTgNYwqT8cxmAfnX8N7qWwEcC"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"bab82b59bb4368ea7c3f7e828759d65af76c04a752845135419bd55d32d9a1ee"},"ver":"1"} +{"reqSignature":{},"txn":{"data":{"data":{"alias":"Steward4","blskey":"oy7vASnhYAYo9fV1MzFSeCHEmyd2dQze6dmwWd5unwoySsA2UauUaKpV6QqwL9WQzQYRXZAoDT9jXGWwGFgCKWKVinFPj2TU5qsqAFt6PcXxQ7ZpBMEiUhQreqQv9BQsb7Upx9cNZKm4wKRyjCryX3TELb3xzz51wwsdeY8hduAKvb","blskey_pop":"QsrUH1e5zsdiEGij1NeY9S7CwzUdU2rzjskHNGHCQ8rtgYZyBC99MgRPzgkJHP86nWQUo2fSRvyWLQdBwvWfNtSqUBQgVScQPHg9CJXWWohWnzSP4ViBo8EEeGXEoP2NPeRnFCCfuhYAC7stZgBATFyvdFRwG58ws76qQQQsfDDHBV","client_ip":"0.0.0.0","client_port":"97008","node_ip":"0.0.0.0","node_port":"9707","services":["VALIDATOR"]},"dest":"8XFTwX3rHVUBddyruNTzKnBdbFqWz8eZPRasyySLD7Sv"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"29f95b62b7d162a819ec6973909f5549178d3dc8ef849ea39b440b45842fd177"},"ver":"1"} From fc4ab7e5f4b2b1e213db7796c89cf59ba7cf4218 Mon Sep 17 00:00:00 2001 From: Philipp Schlarb Date: Mon, 24 Apr 2023 12:16:32 +0200 Subject: [PATCH 2/7] `indy-cli-rs` as alternative to `indy-cli` Signed-off-by: Philipp Schlarb --- docs/source/NewNetwork/CLIInstall.md | 3 +++ docs/source/NewNetwork/CreateDID.md | 3 +++ docs/source/installation-and-configuration.md | 6 +++++- sample/Network/README.md | 3 +++ 4 files changed, 14 insertions(+), 1 deletion(-) diff --git a/docs/source/NewNetwork/CLIInstall.md b/docs/source/NewNetwork/CLIInstall.md index 4ce980c75..6bde1a9f4 100644 --- a/docs/source/NewNetwork/CLIInstall.md +++ b/docs/source/NewNetwork/CLIInstall.md @@ -2,6 +2,9 @@ The `indy-cli` is developed under the [indy-sdk](https://github.com/hyperledger/indy-sdk). This documentation may be not up to date. +>As stated in [Installation and configuration of Indy-Node](../installation-and-configuration.md) `indy-cli` can be replaced with [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs) +>This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. + You will need to perform the following once for each `indy-cli` machine you would like to set up (only 1 is required). It is recommended that you install the `indy-cli` in your native work environment if possible, so you always have it available even when traveling. diff --git a/docs/source/NewNetwork/CreateDID.md b/docs/source/NewNetwork/CreateDID.md index eb8033d12..7885e0951 100644 --- a/docs/source/NewNetwork/CreateDID.md +++ b/docs/source/NewNetwork/CreateDID.md @@ -2,6 +2,9 @@ You will need to perform the following commands once for each `indy-cli` machine that you want to run on. The following commands contain suggestions to save certain values in a secure place. Please do not share those values or that place with anyone. +>As stated in [Installation and configuration of Indy-Node](../installation-and-configuration.md) `indy-cli` can be replaced with [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs) +>This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. + _If you just need to quickly generate a set of secrets (Seed and wallet key), or a Seed, DID, and Verkey and do not have an `indy-cli` environment already setup, you can use the `indy-cli` features integrated into `von-network`. Refer to [Generate a set of Secrets](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-a-set-of-secrets), and [Generate your DID](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-your-did) for details._ diff --git a/docs/source/installation-and-configuration.md b/docs/source/installation-and-configuration.md index bdb124505..590d3c000 100644 --- a/docs/source/installation-and-configuration.md +++ b/docs/source/installation-and-configuration.md @@ -1,7 +1,11 @@ # Installation and configuration of Indy-Node ## 1. Introduction -The purpose of this document is to describe how to setup a production level Indy-Validator-Node and register it on an existing network using an `indy-cli` machine which you also configure along the way. This documentation is based heavily on the [Sovrin Steward Validator Preparation Guide v3](https://docs.google.com/document/d/18MNB7nEKerlcyZKof5AvGMy0GP9T82c4SWaxZkPzya4). +The purpose of this document is to describe how to setup a production level Indy-Validator-Node and register it on an existing network using an `indy-cli` machine which you also configure along the way. +>Alternativly you can use [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs), which is command for command compatible with the existing indy-cli (at least ATM). +>This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. + +This documentation is based heavily on the [Sovrin Steward Validator Preparation Guide v3](https://docs.google.com/document/d/18MNB7nEKerlcyZKof5AvGMy0GP9T82c4SWaxZkPzya4). For information on how to setup a new network, refer to [New Network](./NewNetwork/NewNetwork.md) diff --git a/sample/Network/README.md b/sample/Network/README.md index 15177b8ce..25ce596b9 100644 --- a/sample/Network/README.md +++ b/sample/Network/README.md @@ -2,6 +2,9 @@ This walkthrough goes through some of the detailed steps mentioned in [Setting up a New Network](../../docs/source/NewNetwork/NewNetwork.md) +>As stated in [Installation and configuration of Indy-Node](../../docs/source/installation-and-configuration.md) `indy-cli` can be replaced with [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs) +>This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. + For the sake of simplicity this walkthrough runs all of the nodes on the local machine. As a result it uses the local python install version of some of the commands rather than the production level Debian package install version of the commands documented in the [Setting up a New Network](../../docs/source/NewNetwork/NewNetwork.md) guide. 1. Open indy-cli by executing `indy-cli` From 62acd480f0bd32963de7f554d993b7eb4c0c0f74 Mon Sep 17 00:00:00 2001 From: Philipp Schlarb Date: Mon, 24 Apr 2023 12:21:42 +0200 Subject: [PATCH 3/7] Python 3.8 fix in documentation Signed-off-by: Philipp Schlarb --- docs/source/setup-dev.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/setup-dev.md b/docs/source/setup-dev.md index 0a23d1315..56c908385 100644 --- a/docs/source/setup-dev.md +++ b/docs/source/setup-dev.md @@ -18,7 +18,7 @@ The scripts are in [dev-setup](https://github.com/hyperledger/indy-node/tree/mas **Note**: As of now, we provide scripts for Ubuntu only. It's not guaranteed that the code is working on Windows. -- One needs Python 3.5 to work with the code +- One needs Python 3.8 to work with the code - We recommend using Python virtual environment for development - We use pytest for unit and integration testing - There are some dependencies that must be installed before being able to run the code @@ -64,7 +64,7 @@ create a virtualenv to work in ### Setup Python -One needs Python 3.5 to work with the code. You can use `dev-setup/ubuntu/setup_dev_python.sh` script for quick installation of Python 3.5, pip +One needs Python 3.8 to work with the code. You can use `dev-setup/ubuntu/setup_dev_python.sh` script for quick installation of Python 3.8, pip and virtual environment on Ubuntu, or follow the detailed instructions below. @@ -82,7 +82,7 @@ Run ```sudo yum install python3.5``` ##### Mac -1. Go to [python.org](https://www.python.org) and from the "Downloads" menu, download the Python 3.5.0 package (python-3.5.0-macosx10.6.pkg) or later. +1. Go to [python.org](https://www.python.org) and from the "Downloads" menu, download the Python 3.8.0 package or later. 2. Open the downloaded file to install it. From d76e907b342c0f3c51dc2d7e6938ae045a7ea3a6 Mon Sep 17 00:00:00 2001 From: Philipp Schlarb Date: Thu, 4 May 2023 09:21:38 +0000 Subject: [PATCH 4/7] indy-cli-rs installation Signed-off-by: Philipp Schlarb --- docs/source/NewNetwork/CLIInstall.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/source/NewNetwork/CLIInstall.md b/docs/source/NewNetwork/CLIInstall.md index 6bde1a9f4..709d441df 100644 --- a/docs/source/NewNetwork/CLIInstall.md +++ b/docs/source/NewNetwork/CLIInstall.md @@ -8,6 +8,9 @@ The `indy-cli` is developed under the [indy-sdk](https://github.com/hyperledger/ You will need to perform the following once for each `indy-cli` machine you would like to set up (only 1 is required). It is recommended that you install the `indy-cli` in your native work environment if possible, so you always have it available even when traveling. +## Installing `indy-cli-rs` +To install `indy-cli-rs` simply donwload the latest release from its release pages and unpack it. + ## Containerized `indy-cli` Environment The following sections describe how to install and configure the `indy-cli` directly on a machine or VM. However, possibly the most convenient option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) From 175e44fffcc20b0e01e608b88e6defe4f6432ef2 Mon Sep 17 00:00:00 2001 From: Philipp Schlarb Date: Fri, 5 May 2023 09:37:54 +0200 Subject: [PATCH 5/7] removal of old indy-cli from docs Signed-off-by: Philipp Schlarb --- docs/source/NewNetwork/CLIInstall.md | 112 +----------------- docs/source/NewNetwork/CreateDID.md | 6 +- docs/source/installation-and-configuration.md | 37 ++---- sample/Network/README.md | 4 +- 4 files changed, 18 insertions(+), 141 deletions(-) diff --git a/docs/source/NewNetwork/CLIInstall.md b/docs/source/NewNetwork/CLIInstall.md index 709d441df..546587b1b 100644 --- a/docs/source/NewNetwork/CLIInstall.md +++ b/docs/source/NewNetwork/CLIInstall.md @@ -1,122 +1,14 @@ # Installing the `indy-cli` -The `indy-cli` is developed under the [indy-sdk](https://github.com/hyperledger/indy-sdk). This documentation may be not up to date. +The `indy-cli` is developed under the [indy-cli-rs](https://github.com/hyperledger/indy-cli-rs). This documentation may be not up to date. ->As stated in [Installation and configuration of Indy-Node](../installation-and-configuration.md) `indy-cli` can be replaced with [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs) ->This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. You will need to perform the following once for each `indy-cli` machine you would like to set up (only 1 is required). It is recommended that you install the `indy-cli` in your native work environment if possible, so you always have it available even when traveling. ## Installing `indy-cli-rs` -To install `indy-cli-rs` simply donwload the latest release from its release pages and unpack it. +To install `indy-cli-rs` simply download the latest release from its release pages and unpack it. ## Containerized `indy-cli` Environment The following sections describe how to install and configure the `indy-cli` directly on a machine or VM. However, possibly the most convenient option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) - -## Windows: -To install the `indy-cli` on Windows 10 perform the following steps: -1. Download https://repo.sovrin.org/windows/indy-cli/stable/1.16.0/indy-cli_1.16.0.zip and unzip it. - If there is a newer version under https://repo.sovrin.org/windows/indy-cli/stable/ it instead. -2. Open a command prompt. (This will work differently if you use Windows Terminal). -3. `cd` to the directory where you unzipped the `indy-cli` package. For example, if you unzipped directly in your ‘downloads’ directory like I did you would type: `cd \Users\\Downloads\indy-cli_1.14.2` -4. Create a JSON Config file containing your taaAcceptanceMechanism in the directory where indy-cli.exe resides (I created \Users\\Downloads\indy-cli_1.14.2\cliconfig.json on my machine) - ```json - { - "taaAcceptanceMechanism": "for_session" - } - ``` -5. Run `indy-cli.exe --config cliconfig.json` to verify proper installation. You should see a new window appear with an `indy>` prompt, (If you are double clicking to start `indy-cli`, you need to right click on the .exe in your window and add the --config parameter first.) If you get an error stating that it is missing vcruntime140.dll then do the following: -6. Download and install vc_redist.x64.exe from the Visual Studio 2017 section on the https://support.microsoft.com/en-ae/help/2977003/the-latest-supported-visual-c-downloads page, and then rerun indy-cli.exe to see if it works as described in previous step. -7. Type ‘exit’ in the `indy-cli` - -## Ubuntu: -To install the `indy-cli` on Ubuntu, perform the following steps from the ubuntu command line: - -1. `sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88` -2. `sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable"` -3. `sudo add-apt-repository "deb https://repo.sovrin.org/deb xenial stable"` -4. `sudo apt-get update -y` -5. `sudo apt-get upgrade -y ` -6. `sudo apt-get install -y indy-cli` -7. `cd ~` -8. Create a JSON Config file containing your taaAcceptanceMechanism in your home directory: -`vim ~/cliconfig.json` - - Press the “i” key and paste the following into the file: - ```json - { - "taaAcceptanceMechanism": "for_session" - } - ``` - Press the “esc” key then the following characters to write the file and quit -`:wq` -9. Run `indy-cli --config ~/cliconfig.json` to start the `indy-cli` - -## Mac: - -Since there is not a prepackaged version of the `indy-cli` prepared for the Mac, the following steps will help you to create an environment, build, and run the `indy-cli` in a Mac terminal. - -Open a Terminal -Run the following commands in the terminal: - -1. `cd ~` -2. `mkdir github` -3. `cd github` -4. `git clone https://github.com/hyperledger/indy-sdk.git`(might need xcode-select --install if error occurs) -5. `/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"` -6. `curl https://sh.rustup.rs -sSf | sh` -7. Follow onscreen instructions to install rust -8. `brew install pkg-config libsodium automake autoconf cmake openssl zeromq zmq` - NOTE: the openssl path needs to match what you currently have on your system - -9. Run > `ls /usr/local/Cellar/openssl/` - Note the name of the directory shown (the example below shows 1.0.2p but the latest version is 1.1.1l) - - Use this directory in place of the one listed below in your .profile file - -10. Add the following lines to your` ~/.profile file `(making the correction shown in the previous step if needed) - ``` - export PATH="$HOME/.cargo/bin:$PATH:~/github/indy-sdk/libindy/target/debug:~/github/indy-sdk/cli/target/debug" - export PKG_CONFIG_ALLOW_CROSS=1 - export CARGO_INCREMENTAL=1 - export RUST_LOG=indy=trace - export RUST_TEST_THREADS=1 - export OPENSSL_DIR=/usr/local/Cellar/openssl/1.0.2p #use your path - export LIBRARY_PATH=~/github/indy-sdk/libindy/target/debug/ - export LIBINDY_DIR=~/github/indy-sdk/libindy/target/debug/ - ``` -11. Run the following commands from your terminal to build the `indy-cli`: - ``` - source ~/.profile - cd ~/github/indy-sdk/libindy - cargo build - cd ../cli - cargo build - ``` -12. Create a JSON Config file containing your taaAcceptanceMechanism in your home directory: - `vim ~/cliconfig.json` - - Press the “i” key and paste the following into the file: - ```json - { - "taaAcceptanceMechanism": "for_session" - } - ``` - Press the “esc” key then the following characters to write the file and quit - `:wq` -13. You can now run `indy-cli` from within a terminal by typing - - `indy-cli --config ~/cliconfig.json` - - `indy> exit` (To exit from the `indy-cli` prompt when you ar done) - - If the above gives error regarding library not loaded libssl.1.0.0, you will probably need to run the following command (all in one line should work) to revert your version: - - ``` - brew uninstall --ignore-dependencies openssl; brew uninstall openssl; - brew install https://github.com/tebelorg/Tump/releases/download/v1.0.0/openssl.rb - ``` - - diff --git a/docs/source/NewNetwork/CreateDID.md b/docs/source/NewNetwork/CreateDID.md index 7885e0951..56590c6c4 100644 --- a/docs/source/NewNetwork/CreateDID.md +++ b/docs/source/NewNetwork/CreateDID.md @@ -2,15 +2,13 @@ You will need to perform the following commands once for each `indy-cli` machine that you want to run on. The following commands contain suggestions to save certain values in a secure place. Please do not share those values or that place with anyone. ->As stated in [Installation and configuration of Indy-Node](../installation-and-configuration.md) `indy-cli` can be replaced with [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs) ->This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. -_If you just need to quickly generate a set of secrets (Seed and wallet key), or a Seed, DID, and Verkey and do not have an `indy-cli` environment already setup, you can use the `indy-cli` features integrated into `von-network`. Refer to [Generate a set of Secrets](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-a-set-of-secrets), and [Generate your DID](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-your-did) for details._ +_If you just need to quickly generate a set of secrets (Seed and wallet key), or a Seed, DID, and Verkey and do not have an `indy-cli-rs` environment already setup, you can use the `indy-cli` features integrated into `von-network`. Refer to [Generate a set of Secrets](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-a-set-of-secrets), and [Generate your DID](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#generate-your-did) for details._ 1. Start your `indy-cli` using the instructions from [Installing the `indy-cli`](./CLIInstall.md) for your platform. - All following commands are executing inside the `indy-cli`. + All following commands are executing inside the `indy-cli-rs`. 2. Create a wallet with: diff --git a/docs/source/installation-and-configuration.md b/docs/source/installation-and-configuration.md index 590d3c000..38d92dc9e 100644 --- a/docs/source/installation-and-configuration.md +++ b/docs/source/installation-and-configuration.md @@ -1,9 +1,8 @@ # Installation and configuration of Indy-Node ## 1. Introduction -The purpose of this document is to describe how to setup a production level Indy-Validator-Node and register it on an existing network using an `indy-cli` machine which you also configure along the way. ->Alternativly you can use [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs), which is command for command compatible with the existing indy-cli (at least ATM). ->This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. +The purpose of this document is to describe how to setup a production level Indy-Validator-Node and register it on an existing network using an `indy-cli-rs` machine which you also configure along the way. + This documentation is based heavily on the [Sovrin Steward Validator Preparation Guide v3](https://docs.google.com/document/d/18MNB7nEKerlcyZKof5AvGMy0GP9T82c4SWaxZkPzya4). @@ -38,7 +37,7 @@ As you proceed through these steps, you will be generating data that will be nee - A cryptographic check against certain forgeries that can be done with BLS keys. ### 2.1 Two Machines -You’ll need two machines: one is your Validator node and the other an `indy-cli` machine to run the `indy-cli` with which you will interact with the ledger. They can be physical machines, virtual machines, or a combination. The machine with the `indy-cli` can be turned on and off at your convenience (refer to [3.1. `indy-cli` Machine Installation](##3.1.-indy-cli-Machine-Installation) for more details), only the Validator node needs to be public and constantly running. +You’ll need two machines: one is your Validator node and the other an `indy-cli` machine to run the `indy-cli-rs` with which you will interact with the ledger. They can be physical machines, virtual machines, or a combination. The machine with the `indy-cli` can be turned on and off at your convenience (refer to [3.1. `indy-cli` Machine Installation](##3.1.-indy-cli-Machine-Installation) for more details), only the Validator node needs to be public and constantly running. >Important: for security reasons, you must not use your Validator node as an `indy-cli` client. If you do, it could expose your Steward credentials needlessly. @@ -73,22 +72,12 @@ Your Validator node will need to have an alias. This will be used later when we Some instructions must be executed on the Validator node, and others on the `indy-cli` machine. The command line prompts in the instructions will help remind you which machine should be used for each command. -### 3.1. `indy-cli` Machine Installation - -The following instructions describe how to install and configure the `indy-cli` directly on a machine or VM. The other, possibly more convenient, option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) +### 3.1. `indy-cli-rs` Machine Installation -#### 3.1.1. Install the `indy-cli` -On the machine you’ve chosen for the `indy-cli`, open a terminal and run the following lines to install the `indy-cli` package. +The following instructions describe how to install and configure the `indy-cli-rs` directly on a machine or VM. The other, possibly more convenient, option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) -``` -ubuntu@cli$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 -ubuntu@cli$ sudo apt-get install -y software-properties-common python-software-properties -ubuntu@cli$ sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable" -ubuntu@cli$ sudo add-apt-repository "deb https://repo.sovrin.org/deb xenial stable" -ubuntu@cli$ sudo apt-get update -y -ubuntu@cli$ sudo apt-get upgrade -y -ubuntu@cli$ sudo apt-get install -y indy-cli -``` +#### 3.1.1. Install the `indy-cli-rs` +On the machine you’ve chosen for the `indy-cli-rs` simply donwload the latest release from its release pages and unpack it. #### 3.1.2. Add an Acceptance Mechanism To write to an Indy Node Ledger, you’ll need to sign the Transaction Author Agreement (TAA). You can learn more about the TAA [here](https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/transaction-author-agreement.md). This agreement 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 `indy-cli`: @@ -103,12 +92,12 @@ This example cliconfig.json file contains the line that sets the AML: ``` To start the `indy-cli` using your new config file, run the following: -`ubuntu@cli$ indy-cli --config /cliconfig.json` +`ubuntu@cli$ indy-cli-rs --config /cliconfig.json` Now all of the appropriate transactions will have an “Agreement Accepted” authorization attached to them during this `indy-cli` session. #### 3.1.3. Obtain the Genesis Files -Obtain the genesis transaction files for the Network with the following steps. For the sake of this documentation, we will use the genesis files from the Sovrin Networks. Information on how to create a genesis file can be found [here](./NewNetwork/NewNetwork.md). These files contain bootstrap information about some of the Validator nodes, which will be used by your `indy-cli` to connect to the networks. +Obtain the genesis transaction files for the Network with the following steps. For the sake of this documentation, we will use the genesis files from the Sovrin Networks. Information on how to create a genesis file can be found [here](./NewNetwork/NewNetwork.md). These files contain bootstrap information about some of the Validator nodes, which will be used by your `indy-cli-rs` to connect to the networks. If you are at the `indy` prompt, please exit: @@ -152,9 +141,9 @@ ShahXae2ieG1uibeoraepa4eyu6mexei Keep this seed in a safe place, such as an encrypted password manager or other secure location designated by your organization. You will need it later in this guide, as well as in the future for other Steward interactions with the ledger. ##### Run the `indy-cli` and generate key -Next we run the `indy-cli` by entering: +Next we run the `indy-cli-rs` by entering: -`ubuntu@cli$ indy-cli --config /cliconfig.json` +`ubuntu@cli$ indy-cli-rs --config /cliconfig.json` In the command line, enter the following to create your pool configuration and your wallet locally. In these instructions, we use "buildernet" for the pool name and "buildernet_wallet" for the wallet name, although you may use other names of your choosing, if desired. 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 of your local wallet. @@ -351,10 +340,10 @@ dpkg -l | grep indy ``` ##### Add Validator Node to Ledger -On your `indy-cli` machine, if you are not still on the `indy-cli` prompt, you will need to return to it. To get back to where you were, type `indy-cli --config /cliconfig.json`, connect to the network pool, designate the wallet to use (using the same wallet key as before), and enter the DID that was returned earlier, when you typed `did new seed` (then enter your seed) for your Steward user: +On your `indy-cli` machine, if you are not still on the `indy-cli-rs` prompt, you will need to return to it. To get back to where you were, type `indy-cli --config /cliconfig.json`, connect to the network pool, designate the wallet to use (using the same wallet key as before), and enter the DID that was returned earlier, when you typed `did new seed` (then enter your seed) for your Steward user: ``` -ubuntu@cli$ indy-cli --config /cliconfig.json +ubuntu@cli$ indy-cli-rs --config /cliconfig.json indy> pool connect buildernet indy> wallet open buildernet_wallet key= indy> did use diff --git a/sample/Network/README.md b/sample/Network/README.md index 25ce596b9..b93726ac6 100644 --- a/sample/Network/README.md +++ b/sample/Network/README.md @@ -2,12 +2,10 @@ This walkthrough goes through some of the detailed steps mentioned in [Setting up a New Network](../../docs/source/NewNetwork/NewNetwork.md) ->As stated in [Installation and configuration of Indy-Node](../../docs/source/installation-and-configuration.md) `indy-cli` can be replaced with [`indy-cli-rs`](https://github.com/hyperledger/indy-cli-rs) ->This documentation describes the necessarry steps with `indy-cli`, keep in mind that everytime `indy-cli` is mentioned you can also use `indy-cli-rs`. Please refer to the corresponding documentation. For the sake of simplicity this walkthrough runs all of the nodes on the local machine. As a result it uses the local python install version of some of the commands rather than the production level Debian package install version of the commands documented in the [Setting up a New Network](../../docs/source/NewNetwork/NewNetwork.md) guide. -1. Open indy-cli by executing `indy-cli` +1. Open indy-cli by executing `indy-cli-rs` Note that the command prompt changed to `indy>`. From 162cf1f5b3f134430678c6d837c40aa0ea0587f5 Mon Sep 17 00:00:00 2001 From: Wade Barnes Date: Thu, 11 May 2023 09:10:08 -0700 Subject: [PATCH 6/7] Updates to Installing the indy-cli instructions Signed-off-by: Wade Barnes --- docs/source/NewNetwork/CLIInstall.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/source/NewNetwork/CLIInstall.md b/docs/source/NewNetwork/CLIInstall.md index 546587b1b..9187514f8 100644 --- a/docs/source/NewNetwork/CLIInstall.md +++ b/docs/source/NewNetwork/CLIInstall.md @@ -1,14 +1,13 @@ # Installing the `indy-cli` -The `indy-cli` is developed under the [indy-cli-rs](https://github.com/hyperledger/indy-cli-rs). This documentation may be not up to date. +> NOTE: The `indy-cli` is developed under the [indy-cli-rs](https://github.com/hyperledger/indy-cli-rs). This documentation may be not up to date. - -You will need to perform the following once for each `indy-cli` machine you would like to set up (only 1 is required). -It is recommended that you install the `indy-cli` in your native work environment if possible, so you always have it available even when traveling. +You will need to perform the following once for each `indy-cli` machine you would like to set up (only 1 is required). +It is recommended that you install the `indy-cli` in your native work environment if possible, so you always have it available even when traveling. ## Installing `indy-cli-rs` To install `indy-cli-rs` simply download the latest release from its release pages and unpack it. ## Containerized `indy-cli` Environment -The following sections describe how to install and configure the `indy-cli` directly on a machine or VM. However, possibly the most convenient option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) +Possibly the most convenient option is to use a containerized `indy-cli` environment like the one included with [von-network](https://github.com/bcgov/von-network). For information on how to use the containerized `indy-cli` in `von-network`, refer to [Using the containerized indy-cli](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) From 29768f416a7d345afc84bf67b9c435c2ed1879eb Mon Sep 17 00:00:00 2001 From: pSchlarb Date: Tue, 19 Dec 2023 15:51:14 +0000 Subject: [PATCH 7/7] fixed typos Signed-off-by: pSchlarb --- docs/source/NewNetwork/NewNetwork.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/NewNetwork/NewNetwork.md b/docs/source/NewNetwork/NewNetwork.md index 821b03a5a..a17b9aa17 100644 --- a/docs/source/NewNetwork/NewNetwork.md +++ b/docs/source/NewNetwork/NewNetwork.md @@ -21,7 +21,7 @@ Initial Trustees (3 preferred) must create and submit a Trustee DID and Verkey so that the domain genesis file can be built. - Each trustee has to [instal the `indy-cli`](./CLIInstall.md) and [create a Trustee DID](./CreateDID.md). + Each trustee has to [install the `indy-cli`](./CLIInstall.md) and [create a Trustee DID](./CreateDID.md). Once the Trustees have created their DID and Verkey give the Trustees access to a spreadsheet like [this one](https://docs.google.com/spreadsheets/d/1LDduIeZp7pansd9deXeVSqGgdf0VdAHNMc7xYli3QAY/edit#gid=0) and have them fill out their own row of the Trustees sheet. The completed sheet will be used to generate the genesis transaction files for the network. @@ -30,7 +30,7 @@ A Steward is an organization responsible for running a Node on the Network - Exactly 4 “Genesis” Stewards are needed to establish the network, more Stewards can be added later. + Exactly 4 “Genesis” Stewards are required to establish the network, but at least 7 are recommended for a production network that you expect to last for a long time. More Stewards can be added later. Each Genesis Steward’s node information will be included in the Genesis Pool file, so they should be willing to install and maintain a Node on the new Network for an extended period of time. @@ -40,7 +40,7 @@ 1. Determine a name for the new network and have the stewards substitute it in the appropriate places in the guide, such as when setting the network name and creating the directory when creating the keys for the node. 1. They all need to stop at the normal place ([3.5. Add Node to a Pool](../installation-and-configuration.md#3.5.-Add-Node-to-a-Pool)) as instructed in the guide as the steps that follow differ when creating a new network. The following sections of this guide describe the steps required to start the new network. - Once the Stewards have created their DID and Verkey, and performed the initial setup of they node, give the Stewards access to a spreadsheet like [this one](https://docs.google.com/spreadsheets/d/1LDduIeZp7pansd9deXeVSqGgdf0VdAHNMc7xYli3QAY/edit#gid=0) and have them fill out their own row of the Stewards sheet. The completed sheet will be used to generate the genesis transaction files for the network. + Once the Stewards have created their DID and Verkey, and performed the initial setup of their node, give the Stewards access to a spreadsheet like [this one](https://docs.google.com/spreadsheets/d/1LDduIeZp7pansd9deXeVSqGgdf0VdAHNMc7xYli3QAY/edit#gid=0) and have them fill out their own row of the Stewards sheet. The completed sheet will be used to generate the genesis transaction files for the network. ## IV. Create and Distribute genesis transaction files