From 68d62d953f944ffd0128fc8d0ee2a3152b1e955c Mon Sep 17 00:00:00 2001 From: Lynn Bendixsen Date: Thu, 9 Nov 2023 10:18:38 -0700 Subject: [PATCH 1/3] Renamed the install docs to have the "md" extension. Signed-off-by: Lynn Bendixsen --- .../{AWS-NodeInstall-20.04 => AWS-NodeInstall-20.04.md} | 0 .../{Azure-NodeInstall-20.04 => Azure-NodeInstall-20.04.md} | 0 .../{GC-NodeInstall-20.04 => GC-NodeInstall-20.04.md} | 0 .../{Physical-NodeInstall-20.04 => Physical-NodeInstall-20.04.md} | 0 4 files changed, 0 insertions(+), 0 deletions(-) rename docs/source/install-docs/{AWS-NodeInstall-20.04 => AWS-NodeInstall-20.04.md} (100%) rename docs/source/install-docs/{Azure-NodeInstall-20.04 => Azure-NodeInstall-20.04.md} (100%) rename docs/source/install-docs/{GC-NodeInstall-20.04 => GC-NodeInstall-20.04.md} (100%) rename docs/source/install-docs/{Physical-NodeInstall-20.04 => Physical-NodeInstall-20.04.md} (100%) diff --git a/docs/source/install-docs/AWS-NodeInstall-20.04 b/docs/source/install-docs/AWS-NodeInstall-20.04.md similarity index 100% rename from docs/source/install-docs/AWS-NodeInstall-20.04 rename to docs/source/install-docs/AWS-NodeInstall-20.04.md diff --git a/docs/source/install-docs/Azure-NodeInstall-20.04 b/docs/source/install-docs/Azure-NodeInstall-20.04.md similarity index 100% rename from docs/source/install-docs/Azure-NodeInstall-20.04 rename to docs/source/install-docs/Azure-NodeInstall-20.04.md diff --git a/docs/source/install-docs/GC-NodeInstall-20.04 b/docs/source/install-docs/GC-NodeInstall-20.04.md similarity index 100% rename from docs/source/install-docs/GC-NodeInstall-20.04 rename to docs/source/install-docs/GC-NodeInstall-20.04.md diff --git a/docs/source/install-docs/Physical-NodeInstall-20.04 b/docs/source/install-docs/Physical-NodeInstall-20.04.md similarity index 100% rename from docs/source/install-docs/Physical-NodeInstall-20.04 rename to docs/source/install-docs/Physical-NodeInstall-20.04.md From d95be3b1b943e88e585a30e525529fdd9217ddb8 Mon Sep 17 00:00:00 2001 From: Lynn Bendixsen Date: Tue, 14 Nov 2023 18:22:47 -0700 Subject: [PATCH 2/3] Added the validator preparation guide, references to it, and a spreadsheet file for node info. Signed-off-by: Lynn Bendixsen --- .../install-docs/AWS-NodeInstall-20.04.md | 2 +- .../install-docs/Azure-NodeInstall-20.04.md | 2 +- .../install-docs/GC-NodeInstall-20.04.md | 2 +- .../Physical-NodeInstall-20.04.md | 2 +- .../install-docs/node-installation-info.xlsx | Bin 0 -> 5369 bytes .../install-docs/validator-prep-20.04.md | 590 ++++++++++++++++++ 6 files changed, 594 insertions(+), 4 deletions(-) create mode 100644 docs/source/install-docs/node-installation-info.xlsx create mode 100644 docs/source/install-docs/validator-prep-20.04.md diff --git a/docs/source/install-docs/AWS-NodeInstall-20.04.md b/docs/source/install-docs/AWS-NodeInstall-20.04.md index fd7c881a2..7558fc34e 100644 --- a/docs/source/install-docs/AWS-NodeInstall-20.04.md +++ b/docs/source/install-docs/AWS-NodeInstall-20.04.md @@ -340,4 +340,4 @@ NOTE: Since AWS regularly updates their user interface, this document becomes ou 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -30. You can now begin the Indy Node installation using the Validator Preparation Guide. +30. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/Azure-NodeInstall-20.04.md b/docs/source/install-docs/Azure-NodeInstall-20.04.md index eb9d902b3..3433749a9 100644 --- a/docs/source/install-docs/Azure-NodeInstall-20.04.md +++ b/docs/source/install-docs/Azure-NodeInstall-20.04.md @@ -371,4 +371,4 @@ NOTE: Since Azure regularly updates their user interface, this document becomes 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -30. You can now begin the Indy Node installation using the Validator Preparation Guide. +30. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/GC-NodeInstall-20.04.md b/docs/source/install-docs/GC-NodeInstall-20.04.md index 626d42dd3..a10305eb9 100644 --- a/docs/source/install-docs/GC-NodeInstall-20.04.md +++ b/docs/source/install-docs/GC-NodeInstall-20.04.md @@ -375,4 +375,4 @@ NOTE: Since GC regularly updates their user interface, this document becomes out 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -28. You can now begin the Indy Node installation using the Validator Preparation Guide. +28. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/Physical-NodeInstall-20.04.md b/docs/source/install-docs/Physical-NodeInstall-20.04.md index ca63c669e..7396ba386 100644 --- a/docs/source/install-docs/Physical-NodeInstall-20.04.md +++ b/docs/source/install-docs/Physical-NodeInstall-20.04.md @@ -220,4 +220,4 @@ The following steps are one way to adhere to the Indy Node guidelines for instal 6. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 7. Log out and then log back in to check and make sure it worked! 5. All of your secondary admin users should be setup now. -30. You can now begin the Indy Node installation using the Validator Preparation Guide. +30. You can now begin the Indy Node installation using the [Validator Preparation Guide](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs/validator-prep-20.04.md). diff --git a/docs/source/install-docs/node-installation-info.xlsx b/docs/source/install-docs/node-installation-info.xlsx new file mode 100644 index 0000000000000000000000000000000000000000..f28587384bbe69bf310d942586845c3cdd9f05ca GIT binary patch literal 5369 zcmai21z3}9+lB$sFghd!Ns-YhEg@afU89DM?i$jFbgFbCq2y?ZfutfG5)u=TR8im? z`hCB={@?q4*LG~ra~!+RJ@*yoeO{NADh4Jw8V(K)+Mu$d0ooO#MqT^3@Y+JHyd5D9 z?*F;qyY1uZk~?Mw=>`#CeQgyH!=^05`xQ+Sdm-On(g;*Rf;9-?eUZ(jI~8SyQCgp3eX(DzEW@tWzN7U6y)QUSAO;XAoW|9J}SoU|BNAn!+~*X+5~EbliES<7bLo@}S+y&KvH#-I-!8fX&zy1G!yg%Ezl z!R=COzF769{zjvPmMS(5wzXq87CIUlHU=7+*8g&)w;R;i9c*Xk;m-T>>z6CjW*`M1 z>WF8Si|7w6I)$B63bS687kf{F)10Ytu2HNGc%`+UW!&@%v%wv{OA6WuxNvhPFp_%e zxJr*pCFE=%g>z$x#T8NBa%T9gBe+d+t(~0}!aZM;R{4YX#*hBv#`WlZ%~}=(KfJM+ z)Q)6m2ade7Nc*$`>)7Mt^~U(_h@iiV0qJhH46S@D*~)e z&pSEB4t9c)8uXh}t$O!KwI)w(_jyzWZn-s;8!^CakFaU(p)FMmP%_efd!5zcdDGj8 z;2P(|s`QLXY%-IocmRTSJoxd;*zqsm1)`3x^A}J1xbLEkZNm3L3$UFuNwGNg*acFM zCHrwV&3VNneBp;&mfoMuv=zJ=5->D-Lc+=#B9iE*#`z_^ZXIiT4Tof*D?O@3bKRoI zmK`5meH1E)VMO55;Zn&{YbTpr7k*>+1%(kNM!z2Eu-Y5wJcmw|a#i_$Ah?(((@tgA z1nP?5Q5DZL36c<5&N9i%jIe<)@jFIUw#*dna;Q|3k{LZg?0o@LLq*nZy=vua20VC2 z{on&yHWRvSW{8br2!b@qb&B=1X2D0lr=27^mZVsu{@%|y#cB}=dg#dtmP#b7x=``& ziy3f$L=97JSpAG;vQuK~4X_R#UaQYXA3)}^oJ14TGbz|Lb$k6t@wDqWrnF$eu_9T; zaMP@5uyr~cU)Jj)m3TH!NB#nYY1TX#nqCab>duorHFrsL&V4d-zIl*UD`@|n1-uut zbx!k*=2+<9wQpt`{=1QF@T!oxNUN;2d4`g&HYJRJ45at%S7L6L_!0k$-?+T9sR zOZX&{%GX%DpSo!HQ4thNK9cp(qoPxGiLvJHErp%8LUG97^9R{4A9#T6 zT>OjIt!t`{vsJq;Tc6Qbf4gB@pmx8gYZ@Tzc-~I!?;4<* zZ_i?90az7?6cFf49IEJ`!6Jsm3OYE0EewG`$~CLO6`>!;?iar3p@|t086V>+Kai1p zb~@Z5ePJud4@i+9d?9oy8jgw1Yq;OSyVq+wb@*$;b z_E|@t^y7R%rdCN&dl(`HMix_)bUW!K5D3cQjE{r?IhQ}O9;78r$frCCIgo#zN?h}y z&Fq{+vVBg6hyi3KuX@2WYnp#eW*yi#)j?~3(e1x+Q>tX;`ifrwZAiGxT|Uz}cgpj{ zirQrz>#LW0gd5bjN#IxNEe40dic_cLywPx zNb62z_|$V)@u#4W2G^w}h_eSqH1u@c&L>u`Z=~!;X3ne<&3W=+8(?##d-LdAl&+pvO_wyyv;2qV?0KTy2`eUjKKrgnQQpTLeCrj^rS@v(TuVsmqXRg!OX!xRmlCj+G4Tp_OE3(jux| z5%X40^gw52G196xKZF!#&LZt;IGkV2jLe@lt)#v0AEMi)%2Xi1U4s?nmb+0PHm5|w zhE#&|@`+Wx;_Pldx#;B5KA*o$MqMl?JVT%haoH7)Z9|qz#jx;7o`vMy4MQean}4J* zeSBR^kN?_b133CAl=7b9#qKF zSJb>ZQS8@G!-&}jt&fI_B~J#}h-~f|+rqhzE5B&YA?m(iUly8OL8ui6>X5D?`lmu8 z|5a%2U@NGdt*!_3QutizorvTv4FDhT(X&qPjH5zq!!=8S88c!a8L7Oo!kw&H`k6k6 z!;YHl;v&G$$Vkl(ym9gUEVp=gubmeAI)Mv`xK!O>KhAs$kvX!4>{ z>qw_`-%$4GL}2Bp1f*j(((tCpG?7X3Ky6TR&LCm3tbP;gqbhYLf4i9Th@v9;xGe=npHbu>E!AD)w`0q!YcDZ&CUTF$Ma7Ya|9K4}5qQcmOF zkpnBG8MumlkuSTfEVf;wkjYQ^a=?DORd8dA9rLsE141Enzp0BRj(gYFN58upR_Pj) z$Qqr}t&3d7X#2I{zBP&njsHXe^xA`QjyXC2hubw{r?6otWW{m`dE`gu49QZ}%}- zxCBxKn&Uoyxy#@3dcg38dv|If38bt`WIuasI_>TEB%N3^*({v&_xGn{E$fo-tozFI zNhKpD!VIam?JT*}RUq@MUEwpf2U0+o$|sWQ?5!MIY|$_~V;cSGhs6rdW5Vo?fLmNm zc*^ftqUAGKpqS&to7{fIF5tq5L?uUjPj)a4HJg%^%D#C|ghVhsO18*@&DPCI@ zH%%z>zQtij6t?CVk;(=xSJ}fPbW3bp$%1j(a(%t&pmrp z#|TZ$9H$yIcvlzqT*6p)kDBP~2DBwRbSv&q{r$%D^%Y=4zYY%>_4DJy{3^>~(t8s< z9uIjH+#7D~IH=FQEuro;+V!|4y<3g2AYuy~B>807p0uO;MWVaGlgDGALtJlW+7PU3O#vTO@vP7FJxEu}@W_QU< z!mNCtGo!1~-myq|Jqb2YwKi)sfS>@(P-(U@Zj35zjNrbXOHAhK6E6^q!XqG7H3;ub zp78BqxqTM>Xci+q4-lpJRzIsV(?2NUX8?0l~|P|>(m1R-bIBYYG$e~S?6AKjyi|! zTroCqVw%79CbRnN=}E5evN%wV$~^j__s7K;xc-dRZ$FgNyNkOth7{9}%w@v_YcDeW zJ3BD*Wn&9514UehmC2H;dF|9|ff-Lee4>4$P?nfc9sAV>W6d}uca{X139}4~?<=|{ zwA^jx8dA#qNTX$88`Gwrc+voPNX>H2E+MGy@PO)#ql~5j7wi5l=yMI8q%aF#;fk;x z8FL3i9z>$!r*DMpQT6Tm9p*0=w_qpnq`W>Fe2s2hlDBXVX(sq26izWRD;f2qihBoQ z84ZGe3hXqRF5PXEKbldQ`}g7!AN7l0?)tZomL&=U0kOtVLfZaB=YdsRUJW0c3n9bv z26<+g632?}ogJNc{Pg5+he5@a>Au#)M^;SS&j+BEV2Z6STJ)(C_#HHSZDStxIu6TT zG|yL@yrPH#Rr$mNaZbZ4Dcz z&@GRt4z&@E|EZ%*J>Lg*?q-)o`bu|51Cj6NQcV$A z-LKN?ayar$F(Km1ma-;v&W?=?>L{wld<~8dd(+OE9KGV$Z|PQVHYB~~3YX#&5U1uO zo82W4Vw*TFLo0a41wR;OE!ejp&8v==qklL1@SX}EGuR1OU%xI~s4uc7w8XSd^+1iw z`+iV3Yb%J8IQ8igwosy0$HwdUVrE`xqMWyp8Z~w!%)=N8{fL{$QUBPU2=4*0RDoc8 zx}@!pAUL=}ER87cVrMw;QH}Wa(5}O1`%kaCM!nP$LV279^D@EE0pw`EM@d&FBbTG3 zzuMmomi|P!+9UoIMHThGD3mLG;qRHspD0(mtjm7#w?(3!{I4kgwY&Ti@T!`;Y|egL zEY?rJKU=jw0j^4&OVRn;j&Obg{67i$C&JYu=~5E?whUB1joOp@{|Tf&mtJMk%QNe@ z@uQIb?T-JPV1F*YN-CFR``a2&(i*k+Z>aZAoU0XkNkPAD6ZK422kept secure. +* The Validator Node Identifier (Also referred to as Validator Verkey or Target by some Node tools used herein) + * This is distinct from your Steward DID and verkey. It is also public information that will be placed on the ledger, but this one is used as a public key by your Validator Node. +* The Validator BLS public key. + * Used by the Validator to sign individual transactions that will be committed to the ledger. It is public information that will be written to the ledger. +* The Validator proof of possession for BLS key (pop) + * A cryptographic check against certain forgeries that can be done with BLS keys. This key is also public information that will be written to the ledger. + + +### 2.1. Two Machines + +You’ll need two machines: one will be your Validator node and the other a CLI machine to run a CLI with which you will interact with the ledger. They can be actual physical machines, virtual machines, or a combination. The machine with the CLI can be turned on and off at your convenience (e.g., it could be a shared VM, a VM on a laptop, run directly from your workstation, etc.); only the Validator node needs to be public and constantly up. + + +**Important:** For security reasons, you must NOT use your Validator node as a CLI machine. If you do, it could expose your Steward credentials needlessly. + +Your Validator **must run Ubuntu 20.04 (64-bit)** as this guide covers instructions for that version only. To install your Ubuntu Validator you can follow some public step-by-step instructions created for that purpose. [Install Docs](https://github.com/hyperledger/indy-node/tree/main/docs/source/install-docs) + +This preparation guide recommends to use the [containerized Indy CLI](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) in all environments and includes instructions only for that version. + +Your Validator node must have two NICs, each with associated IP addresses and ports. One NIC (Node-NIC) will be used for inter-validator communication, and the other (Client-NIC) for connections from clients, including edge agents, as well as ssh and other connections you use for administration. This two NIC approach is required as a defense against denial-of-service attacks, since the Node-NIC should be behind a firewall that is configured to be much more restrictive of inbound connections than the Client-NIC is. + + +### 2.2. Validator Node Preliminary Information + + +##### Get the IP Addresses + +Your Validator node will be the machine that will become a part of the network. It should have two static, publicly accessible, world routable IP addresses. It should be configured so that outgoing TCP/IP connections are from these same addresses, as well as incoming connections. + + +##### Choose Port Numbers: + +The Validator node will also be required to have the following: + + + +* **Node Port: TCP** - The Validators use this IP address and port combination to communicate with each other within an Indy Network. +* **Client Port: TCP** - Clients use this IP address and port combination to communicate with the Validator node, for all ledger interactions. + +While ports 9700-9799 are allowed, by convention most node operators choose the default ports 9701 and 9702 for their Node and Client ports, respectively, and related instructions and documentation use those defaults. + +##### Choose an Alias: + +Your Validator node will need to have an alias. This will be used later when we create a key for the node. It can be any convenient, unique name that you don’t mind the world seeing. Reference to your company name is preferred, but not required, and it is required be distinguishable from the other Validator nodes on the network. Many Node Operators choose a Validator alias that identifies their organization, for pride of their contribution to the cause of decentralized identity. + + +## 3. Setup and Configuration + +You must perform the following instructions in order. If you require assistance, please contact your Network Administrator or post to the [indy-node](https://discord.com/channels/905194001349627914/941709259710808155) discord channel. Some instructions must be executed on the Validator node, and others on the CLI machine. + + +### 3.1. CLI Machine Installation + + +#### 3.1.1. Install the CLI machine + +On the machine you’ve chosen for the CLI, do the following to install a containerized indy-cli ([more details](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md) are available if desired): + + + +1. Install docker +2. Navigate to your github directory (your choice) +3. Clone the von-network repo (for access to the containerized indy-cli) + + git clone [https://github.com/bcgov/von-network.git](https://github.com/bcgov/von-network.git) + +4. `cd von-network` +5. `./manage build` + + +#### 3.1.2. Add an Acceptance Mechanism + +To write to many Indy ledgers, you’ll need to “sign” the Transaction Author Agreement for that ledger. This Agreement acceptance is incorporated into the process of connecting to the node pool and requires an acceptance mechanism. For the Indy CLI, the default mechanism is “For Session” and the following instructions are required to be able to use “For Session” for your CLI: + +Create a JSON Config file in the tmp directory containing your taaAcceptanceMechanism. + + +``` +vim /von-network/tmp/cliconfig.json +``` + + +Copy in the following example cliconfig file which contains the line that sets the acceptance mechanism: + +``` +{ + "taaAcceptanceMechanism": "for_session" +} +``` + +Now all of the appropriate transactions will have an “Agreement Accepted” authorization attached to them during your CLI sessions. + + +#### 3.1.3. Initialize a pool + +Initialize a “pool” for the network your Node will be joining with the following steps. The pool genesis file contains connection information about some of the Validator nodes, which will be used by your CLI to connect to the network. The "network name" is your choice (it's best if it resembles the network you are joining) and the "genesis file link" will be provided by your network administrator. + +From the indy-cli machines "von-network" directory run: + +`./manage cli init-pool ` + +For example: run the following if your node will be added to the Indicio TestNet and a pool handle named "testnet" will be added to your CLI list of pools: + + ubuntu@von-network$ ./manage cli init-pool testnet [https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_testnet_genesis](https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_testnet_genesis)`` + + +#### 3.1.4. Generate the Steward DID + +Next, generate a Steward DID/Verkey. This will be comprised of a public and private key pair, generated from a seed. Your seed will allow you to regenerate the Steward DID on demand. _To keep this secure, you will need to have a **very** secure seed that is not easy to guess._ + + +##### Generate a Seed + +**WARNING:** +**You want to guard your seed well. The seed will be used to generate your public (verification) key as well as your secret private key for your DID. If your seed falls into the wrong hands, someone could regenerate your private key, and take over your identity on the ledger.** + + +In a terminal, run the following to install a random string generator, and then use it to generate your Steward seed (or create your own random 32 character seed): + + +``` +sudo apt install pwgen +pwgen -s 32 1 +``` + + +EXAMPLE: +``` +pwgen -s 32 1 +ShahXae2ieG1uibeoraepa4eyu6mexei +``` + +**IMPORTANT:** +**Keep this seed in a safe place, such as an encrypted password manager or other secure location designated by your organization. ** + + + +##### Generate DID and Verkey + +Enter the following to create your wallet and store your Steward DID in it. In these instructions substitute in names of your choosing for your wallet. The encrypted wallet will be used to store important information on this machine, such as your public and private keys. When creating your wallet, you will need to provide a "key" that is any string desired. It will be the encryption key (essentially the password) of your local wallet. + + +``` +./manage indy-cli create-wallet walletName= +``` + + +When prompted, enter the wallet key to complete the creation of the wallet. + +**IMPORTANT:** +**To be able to retain your wallet and not re-create it when you need it in the future, keep this wallet key in a secure location.** + + + +When prompted, enter the wallet key to open the wallet. + + +When prompted, enter your seed. (The create-wallet command includes an automated workflow for using the Steward seed that you generated in the immediately preceding step to create your Steward DID) + + +**IMPORTANT: Save the displayed “DID” and “verkey” portions of this. They are not secret, and they will be used later when you are prompted to supply your Steward DID and verkey.** + + + +### 3.2. Validator Node Installation + + +#### 3.2.1. Perform Network Test + +This test is to confirm that your Validator node can connect with external devices. + +Note that the communication protocol used for both node and client connections is ZMQ. If your firewall uses deep packet inspection, be sure to allow this protocol bi-directionally. + +The tests in this section are to assure that your node's networking is operational, and that firewalls will allow TCP traffic to and from your IP addresses and ports. The assumptions are that for this stage of testing, you will be able to reach both sets of IP address/port combinations from an arbitrary client, but that later you will implement rules on your firewall restricting access to your Node-IP address/port. + + +##### 3.2.1.1 Test the Node connection to your Validator + +Use netcat to listen on the Node-IP address and port on your Validator + +IMPORTANT: +Many cloud providers, use local, non-routable IP addresses on their servers and then use NAT to translate these to public, routable IP addresses. If you are on such a system, use the **local address** to listen on, and the **public address** to ping with. + +`nc -l <node_ip_address> <node_port> ` + +The above command will wait for a connection. On a system that can be used as a client, such as your CLI machine, do a TCP ping of that IP address and port: + +`nc -vz <node_ip_address> <node_port>` + +If the test is successful, the ping will return a "succeeded" message and the commands on both systems will exit. + +NOTE: Sometimes the above fails when the connection is actually set up correctly. In that case, you might try and install socat and run something like the following but substitute in your own interface name and port: + +`socat tcp4-listen:9701,so-bindtodevice=ens5,reuseaddr,fork -` + + +##### 3.2.1.2 Test the client (edge agent) connection to your Validator + +Repeat the above test on your Validator and a test client, but using the Validator's "client" IP address and port. + +Important: The “client” IP address referred to here is not the CLI machine’s IP address. Reminder: The Validator node has a Node-IP for communications with other Validator Nodes and a Client-IP for communications with edge agents (anything outside the Network of Validator Nodes). + +On your Validator: + +`nc -l <client_ip_address> <client_port> ` + +On your client: + +`nc -vz <client_ip_address> <client_port>` + +If the test is successful, the ping will return a "succeeded" message and the commands on both systems will exit. + + +##### 3.2.1.3 Test the connection from your node to another Validator on the network you will be joining + +For Example: One of the Validator nodes on the Indicio TestNet is named "OpsNode", which has a node IP address and port of 3.135.134.42 and 9701, respectively. (Ask your Network Administrator for your networks' information.) On your Validator, make sure that your node is able to connect to this node by TCP pinging its node IP address and port: + +``` +nc -vz 3.135.134.42 9701 +Connection to 3.135.134.42 9701 port [tcp/*] succeeded! +``` + +When the above three tests are successful, you may proceed. + +NOTE: On Ubuntu 20.04, some of the above "tests" can fail when the networking is actually set up correctly. It is recommended to try the above tests, but if they fail and you are confident that networking is set up correctly feel free to proceed with the installation instructions. + + + +#### 3.2.2. Install the Validator Node + +Continue on your Validator node machine. + + +**Important: You must use a login user with sudo privileges (not root or indy) to run these commands, unless otherwise indicated.** + + + +``` +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9692C00E657DDE61 +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3BC8C2DD662F1C45 +sudo add-apt-repository "deb https://hyperledger.jfrog.io/artifactory/indy focal rc" +sudo add-apt-repository "deb http://security.ubuntu.com/ubuntu bionic-security main" +sudo add-apt-repository "deb https://repo.sovrin.org/deb bionic master" +sudo add-apt-repository "deb https://sovrin.jfrog.io/artifactory/deb focal rc" +sudo apt-get update -y +sudo apt-get upgrade -y +sudo apt-get install -y \ + rocksdb=5.8.8 \ + libgflags-dev \ + libsnappy-dev \ + zlib1g-dev \ + libbz2-dev \ + liblz4-dev \ + libgflags-dev \ + python3-libnacl=1.6.1 \ + python3-sortedcontainers=1.5.7 \ + python3-ujson=1.33 \ + python3-pyzmq=22.3.0 \ + indy-plenum=1.13.1~rc3 \ + indy-node=1.13.2~rc5 \ + sovtoken=1.1.0~rc0 \ + sovtokenfees=1.1.0~rc0 \ + sovrin=1.2.0~rc1 \ + libssl1.0.0 \ + ursa=0.3.2-1 + +sudo ln -sv /usr/lib/ursa/* /usr/lib +``` +NOTE: You must add the line REV_STRATEGY_USE_COMPAT_ORDERING = True in the /etc/indy/indy_config.py file of any 20.04 node being added to an existing 16.04 network. (The default is False) +`echo "REV_STRATEGY_USE_COMPAT_ORDERING = True" | sudo tee -a /etc/indy/indy_config.py` + + +#### 3.2.3. Create the Key for the Validator Node + +IMPORTANT: +Many providers, like AWS, use local, non-routable IP addresses on their nodes and then use NAT to translate these to public, routable IP addresses. If you are on such a system, use the **local addresses** for the init_indy_node command. + +Please run the following steps on the Validator before running init-indy-node. The default instruction examples are for the Indicio TestNet, but please use the alternate values supplied by your Network administrator for each use of "your_network_name" and any links. The network name mentioned in these steps is the network directory name that your Network Administrator has supplied you with. All nodes on a network **must use the same directory name**. + +1. In the /etc/indy/indy_config.py file, **change the Network name from “sandbox” to “”** Use sudo to edit the file directly or run: +`sudo -i -u indy sed -i -re "s/(NETWORK_NAME = ')\w+/\1your_network_name/" /etc/indy/indy_config.py` +EXAMPLE for Indicio TestNet: +`sudo -i -u indy sed -i -re "s/(NETWORK_NAME = ')\w+/\1itn/" /etc/indy/indy_config.py` +2. sudo -i -u indy mkdir /var/lib/indy/your_network_name \ +EXAMPLE for Indicio TestNet: `sudo -i -u indy mkdir /var/lib/indy/itn` +3. cd /var/lib/indy/your_network_name \ +EXAMPLE or Indicio TestNet: `cd /var/lib/indy/itn` +4. sudo curl -o domain_transactions_genesis +EXAMPLE for Indicio Testnet: `sudo curl -o domain_transactions_genesis https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/domain_transactions_testnet_genesis` +5. sudo curl -o pool_transactions_genesis +EXAMPLE for Indicio Testnet: `sudo curl -o pool_transactions_genesis https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_testnet_genesis` +6. Make sure that both genesis files are owned by indy:indy + `sudo chown indy:indy *` + +Enter the following command to initialize your Indy Node. <ALIAS> is the alias you chose for your Validator node machine and <node ip>, <client IP>, <node port #> and <client port #> should match the corresponding values for your Validator. + +**Note: The node IP and client IP addresses in this command should be the LOCAL (or private) addresses for your node.** + + +``` +ubuntu@validator$ sudo -i -u indy init_indy_node +``` + + +The output will look something like this: + + +``` +Node-stack name is Node19 +Client-stack name is Node19C +Generating keys for random seed b'FA7b1cc42Da11B8F4BC83990cECF63aD' +Init local keys for client-stack +Public key is a9abcd497631de182bb6f767ffb4921cdf83ffdb20e9d22e252883b4fc34bf2f +Verification key is 3d604d22c4bbfd55508a5a7e0008847bdeccd98a41acd048b500030020629ee1 +Init local keys for node-stack +Public key is a9abcd497631de182bb6f767ffb4921cdf83ffdb20e9d22e252883b4fc34bf2f +Verification key is bfede8c4581f03d16eb053450d103477c6e840e5682adc67dc948a177ab8bc9b +BLS Public key is 4kCWXzcEEzdh93rf3zhhDEeybLij7AwcE4NDewTf3LRdn8eoKBwufFcUyyvSJ4GfPpTQLuX6iHjQwnCCQx4sSpfnptCWzvFEdJnhNSt4tJMQ2EzjcL9ewRWi24QxAaCnwbm2BBGJXF7JjqFgMzGfuFXXHhGPX3UtdfAphrojk3A1sgq +Proof of possession for BLS key is QqPuAnjnkYcE51H11Tub12i7Yri3ZLHmEYtJuaH1NFYKZBLi87SXgC3tMHxw3LMxErnbFwJCSdJKbTb2aCVmGzqXQtVWSpTVEQCsaSm4SUZLbzWVoHNQqDJASRYNbHH2CqpR2MtntA4YNb2WixNSZNXFSdHMbB1yMQ7XUcZqtGHhcb +``` + + +When running this command again on the same node (or during the 16.04 to 20.04 upgrade), to keep the same keys you will need to add the seed that was generated the first time you ran the command to the end of the repeated command. + +The new command looks like: `sudo -i -u indy init_indy_node ` + +**Store the original command, the random seed, the verification key, the BLS public key, and the BLS key proof-of-possession (POP).** These are the keys for your Validator node (not to be confused with the Steward keys). The Validator verification key and BLS key (with its POP) are public, and will be published on the ledger. + +IMPORTANT: The random seed should be protected from disclosure. + + +#### 3.2.4. Enable DDOS protection on the Validator +This step is required by most public networks. + + 1. sudo sed -i -re "s/(^CLIENT_CONNECTIONS_LIMIT=).*$/\115000/" /etc/indy/indy.env + + 2. sudo apt-get install -y iptables-persistent + + 3. sudo setup_indy_node_iptables + +To confirm the new settings run: + + sudo iptables -v -L + + + +#### 3.2.5. Add data directory (Optional) + +If your new 20.04 node is being added to an existing network (and especially if that network has been running for a while) these steps are highly recommended: + +1. Ask your Network Administrator for a copy of the data directory for the network you are joining. Make extra sure the data directory matches the network you will join. + +2. Copy the data directory file (zipped or tarred) to the /tmp directory on your Node + +3. Depending of the method used to compress the files. Use something like the following commands to unpack the compressed file (based on the extension of the compressed file): + a. `cd /var/lib/indy/` + b. `sudo rm -rf data` + c. `sudo tar xf /tmp/data.tgz` + d. OR `sudo xz -d /tmp/data.xz` + e. `cd data` + f. `ls` + g. Rename the listed directory to the alias name of the node you are building (must be EXACT): `sudo mv ` + +### 3.3. Run the Technical Verification Script + +Download [this script](https://raw.githubusercontent.com/sovrin-foundation/steward-tools/master/steward_tech_check.py) (or a similar one provided by your Network Administrator), upload it to your Validator node, and set the execution flag on it (The link above is for Sovrin's tech-check script and the example below is Indicio's): + + + ubuntu@validator$ cd ~ + + + ubuntu@validator$ curl -O https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/nodeop-tools/nodeop-tech-check.py + + + ubuntu@validator$ chmod +x nodeop-tech-check.py + +Execute it, answering the questions that it asks. There are no wrong answers; please be honest. Questions that can be answered by scripting are automatically completed for you. + + + ubuntu@validator$ sudo python3 ./nodeop-tech-check.py + +After the script completes, copy the output beginning at `= Results for "A Node Operator MUST" ==`, and send it to your Network Administrator. + + +### 3.4. Provide Information + +At this point you should have the following data available: + + + +* Your Steward verkey and DID +* The Validator ‘node IP address’ +* The Validator ‘client IP address’ +* The Validator ‘node port’ +* The Validator ‘client port’ +* The Validator alias +* The Validator verkey +* The BLS key + +Please go to the Node Operator Validator Registration form provided by your Network administrator and provide the requested information. For Example: Indicio uses [Node Operator Validator Registration](https://forms.gle/yBFBiFioSQ5SQRY9A). + +Note: You are done with the first part of the onboarding. Your Network Administrator will contact you to go through the rest of this guide together on a call. + + +### 3.5. Add Node to a Pool + +After your data is submitted via the Node Operator Validator Registration form, a Network Trustee will put your Steward DID into the ledger. You will receive notification when your DID and verkey have been added to the ledger. You will be asked to work together on a call with the Network Administrator to complete the final steps to onboard your node onto the network. Please be prepared to suggest times to do this together. \ + \ +**IMPORTANT: \ + DO NOT proceed further with this document until your Steward DID and verkey are on the ledger. ** + + +#### 3.5.1. Configuration + +After you have been informed that your DID has been placed onto the ledger, you may complete the configuration steps to activate your Validator node on that network. + + +##### Make Sure Your Version Is Current + +In some cases, some time may have passed before reaching this point. You should ensure that you have the current version of indy software installed before proceeding. On the Validator node, execute the following. + +In the Validator node: + + +``` +ubuntu@validator$ sudo apt update +ubuntu@validator$ apt-cache policy sovrin +``` + + +If your installed version is not the newest, upgrade your version using the install command provided earlier in this guide. + +At this point your Network Administrator will likely run some routine checks with you to verify that your node is configured correctly before proceeding. + + +##### Add Validator Node to Ledger + +On your CLI machine, [open an interactive indy-cli session](https://github.com/bcgov/von-network/blob/main/docs/Indy-CLI.md#open-an-interactive-indy-cli-session) using information that you saved from earlier in this guide: + +ubuntu@von-network$ `./manage indy-cli --config /tmp/cliconfig.json start-session walletName=(your_wallet) poolName=(your_pool_name) useDid=(your_steward_DID)` + +Enter your wallet encryption key when prompted. + +At the indy-cli command prompt, enter the following, substituting in the correct data any place you see <>. An example will follow. + + + +* _Suggestion: Edit this in a text editor first, then copy and paste it into the Indy CLI. Caution: Some editors will insert 'smart quotes' in place of regular ones. This will cause the command to fail._ + + +``` +indy> ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop= +``` + + +IMPORTANT: + +Many providers, such as AWS, use local, non-routable IP addresses on their nodes and then use NAT to translate these to public, routable IP addresses. If you are on such a system, use the **routable public addresses** for the ledger node command. + +**Example:** + + +``` +indy> ledger node target=4Tn3wZMNCvhSTXPcLinQDnHyj56DTLQtL61ki4jo2Loc node_ip=18.136.178.42 client_ip=18.136.178.42 node_port=9701 client_port=9702 services=VALIDATOR alias=Node19 blskey=4kCWXzcEEzdh93rf3zhhDEeybLij7AwcE4NDewTf3LRdn8eoKBwufFcUyyvSJ4GfPpTQLuX6iHjQwnCCQx4sSpfnptCWzvFEdJnhNSt4tJMQ2EzjcL9ewRWi24QxAaCnwbm2BBGJXF7JjqFgMzGfuFXXHhGPX3UtdfAphrojk3A1sgq blskey_pop=QqPuAnjnkYcE51H11Tub12i7Yri3ZLHmEYtJuaH1NFYKZBLi87SXgC3tMHxw3LMxErnbFwJCSdJKbTb2aCVmGzqXQtVWSpTVEQCsaSm4SUZLbzWVoHNQqDJASRYNbHH2CqpR2MtntA4YNb2WixNSZNXFSdHMbB1yMQ7XUcZqtGHhcb +``` + + + +* _Suggestion: Save this command. You will use it again if you later move to another Network._ + + +#### 3.5.2. Enable the Service + +In the Validator node: + +Return to the Validator node machine. + +Enable the service so that it will auto-restart when your node reboots: + + +``` +ubuntu@validator$ sudo systemctl enable indy-node.service +``` + + +Start the Validator service: + + +``` +ubuntu@validator$ sudo systemctl start indy-node +``` + + +Verify the start: + + +``` +ubuntu@validator$ sudo systemctl status indy-node.service +``` + + + +### 3.6. See if the Node Is Working + +If the setup is successful, your Validator node now connects to the Validator pool. + +In the Validator node: + + +``` +ubuntu@validator$ sudo validator-info +``` + + +If your node is configured properly, you should see several nodes being selected as the primary or its backups, as in this example: + + +``` + England (1) + Singapore (3) + Virginia (4) + RFCU (5) + Canada (0) + Korea (2) +``` + + + + _Note: A ledger with a lot of transactions on it, can take a lot of time to sync up a new Validator node. If you don't get the right results for this test right away, try it again in a few minutes(or longer)._ + +To check that messages and connections are occurring normally you can run the following command to follow the log file: + +In the Validator node: + + +``` +ubuntu@validator$ sudo tail -f /var/log/indy/itn/.log From a85b28176fd065262f873f06cbdbb6fd7812e88e Mon Sep 17 00:00:00 2001 From: Lynn Bendixsen Date: Tue, 21 Nov 2023 07:58:43 -0700 Subject: [PATCH 3/3] Added a note and a link link to the Node Installation Spreadsheet for all server install documents. Signed-off-by: Lynn Bendixsen --- docs/source/install-docs/AWS-NodeInstall-20.04.md | 2 ++ docs/source/install-docs/Azure-NodeInstall-20.04.md | 2 ++ docs/source/install-docs/GC-NodeInstall-20.04.md | 3 +++ docs/source/install-docs/Physical-NodeInstall-20.04.md | 2 ++ 4 files changed, 9 insertions(+) diff --git a/docs/source/install-docs/AWS-NodeInstall-20.04.md b/docs/source/install-docs/AWS-NodeInstall-20.04.md index 7558fc34e..63f962e17 100644 --- a/docs/source/install-docs/AWS-NodeInstall-20.04.md +++ b/docs/source/install-docs/AWS-NodeInstall-20.04.md @@ -6,6 +6,8 @@ NOTE: Since AWS regularly updates their user interface, this document becomes ou #### Installation +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. Before you begin the installation steps, login to your AWS console and select a region to run your VM in. Recommendation: Select the region matching the jurisdiction of your company's corporate offices. 2. From the AWS EC2 services page, click 'Instances' 3. Click 'Launch Instances' diff --git a/docs/source/install-docs/Azure-NodeInstall-20.04.md b/docs/source/install-docs/Azure-NodeInstall-20.04.md index 3433749a9..3de567b59 100644 --- a/docs/source/install-docs/Azure-NodeInstall-20.04.md +++ b/docs/source/install-docs/Azure-NodeInstall-20.04.md @@ -6,6 +6,8 @@ NOTE: Since Azure regularly updates their user interface, this document becomes #### Installation +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. Create a new or open an existing “Resource Group” (“Create New” was used for this document.) You can also do this later. 2. From the Azure portal ‘home’ click 'Create a resource'. 3. Type “ubuntu server” in the search field, ‘Enter’, then select 'Ubuntu server 20.04 LTS' diff --git a/docs/source/install-docs/GC-NodeInstall-20.04.md b/docs/source/install-docs/GC-NodeInstall-20.04.md index a10305eb9..ca1b9cdb0 100644 --- a/docs/source/install-docs/GC-NodeInstall-20.04.md +++ b/docs/source/install-docs/GC-NodeInstall-20.04.md @@ -5,6 +5,9 @@ The following steps are one way to adhere to the Indy Node guidelines for instal NOTE: Since GC regularly updates their user interface, this document becomes outdated quickly. The general steps can still be followed with a good chance of success, but please submit a PR with any changes you see or inform the author of the updates (lynn@indicio.tech) to keep this document up to date. #### Installation + +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. To prepare for VM creation, there are a few preliminary steps needed. First you might need to create a project in which you will create your VM. You will then need to set up items needed for Node networking (detailed steps below). You will also need to create a snapshot schedule so that your VM can be backed up automatically (optional, but this is the only method described herein that satisfies the "backup" requirement). 2. From the GCP console ([https://console.cloud.google.com/](https://console.cloud.google.com/)) scroll down in the upper left hamburger menu to the 'Networking' section, select 'VPC Network', then 'VPC Networks' If you haven’t already, you might need to “Enable” the compute engine API. 1. Before you begin, decide on a 'region' in which to run your VM that closely matches the jurisdiction of your company's corporate offices. Record the region selected as it will be used later in these instructions. diff --git a/docs/source/install-docs/Physical-NodeInstall-20.04.md b/docs/source/install-docs/Physical-NodeInstall-20.04.md index 7396ba386..f53c422f2 100644 --- a/docs/source/install-docs/Physical-NodeInstall-20.04.md +++ b/docs/source/install-docs/Physical-NodeInstall-20.04.md @@ -5,6 +5,8 @@ The following steps are one way to adhere to the Indy Node guidelines for instal #### Installation +TIP: Make a copy of the [Node Installation Setup Spreadsheet Template](https://github.com/hyperledger/indy-node/blob/main/docs/source/install-docs/node-installation-info.xlsx) to store your Node information during installation. + 1. Before you begin: 1. For most governance frameworks' hardware requirements, you will need 2 NIC's and 2 subnets (one per NIC). Configure these before beginning the install. 2. Hardware requirements might include the following, (or greater, depending on your network governance requirements):