Setup and virtual machines


#1

The setup of a validator node is somewhat involved. Mainly this is because libsodium (which we use for elliptical curve cryptography) has some tricky dependencies that are version-sensitive. Existing instructions do (we believe) guide someone successfully through the process. However, we’ve been eager to make this simpler.

So far, the following shortcuts are all available:

AMI-based approach on EC2 (easy) or VHD-based approach on Azure (easy but large download)
Docker (docker run -it sovrinfoundation/sovrin or this advanced contribution from the community)

We also put a VirtualBox-based linux VM together, and I’m looking to publish it shortly. I am wondering how much interest there is in VM solutions. Would you (the community) like a validator-in-a-box? If so, would you like VMware/ESX, VHD, or a different VM technology? Also, is the interest more Windows-centric or Linux-centric?

For reference, I am also linking to the classic setup instructions for Linux and Windows, if you prefer to build from scratch.


#2

Hello Sovrin,

I just downloaded the Docker image for sovrinfoundation/sovrin and I’m trying to use it for running a validator node, but I’m having issues:

At first, I run:

init_sovrin_raet_keep --name Holis

To which there’re no errors. Random seed and keys are successfully generated… Then:

start_sovrin_node Holis 9700 9799

…Produces an error:

(The next line is highlighted on the following screen)

I thought this could be a problem about UDP ports not being open, so I tried this:

iptables -A INPUT -p udp --dport 9700 -j ACCEPT

To which it replies with “iptables: command not found”.

I thought it could be a sudo problem, but then “sudo: command not found” either…

I think it’d be good if you guys prepare a guide for running the validator with Docker, or update what’s needed for the docker image to be run seamlessly, since Docker is undoubtedly a very convenient approach to count on.

Also, if there’s anything I might be doing wrong, I’d appreciate any help.

Thanks!


#3

Carlos: excellent questions. Thanks for asking them, and for experimenting with the docker image!

I am not a Docker expert; if one happens along, they may refine what I say here. But I believe I can shed a little light.

Docker defies some assumptions that are common among linux power users, and this can be a bit disconcerting at first. A normal linux instance is a multipurpose OS where you might have a handful of shells and dozens of daemons running. Access into and out of the OS is typically over the network, which means a firewall is crucial. Many users may interact with it simultaneously. Docker containers, on the other hand, are designed to be ultra lightweight, so they eliminate everything that is not essential. Each container is dedicated to a single use, and by default all access into or out of the container is turned off, except via stdin/stdout in the shell or process that launched the container. This means that when you fire up a docker container and drop into a bash prompt “inside” it, that prompt is the only way to interact with it. Nobody else can log in, no incoming network traffic can reach it, etc. It can make outgoing network calls, and docker will route packets back for responses, but that’s it. (I’m simplifying quite a bit here, but in broad brush strokes, this is true.) Of course you can punch holes through, start ssh daemons, etc–but none of that is done by default.

As a result, docker containers typically don’t have any iptables running (or even installed) internally. And likewise, docker containers often run as the root user (since multiple login isn’t expected)–which means they have no need for sudo. This is why you saw errors about iptables and sudo. The error from start_sovrin_node is caused by lack of incoming communication for the container.

If you want to open ports, you have to use Docker–not iptables–to do it. Typically you do this by using the -p switch on the “docker run” commandline.

The docker image we published has all the software necessary to run as a validator–but it is not configured to do so if you launch the container in the way we described in the Getting Started tutorial. That cmdline is sufficient to run the sovrin CLI to call other validator nodes and get through the tutorial, nothing more. If you want to use the image to run the docker image as a validator node, you will need to use the docker cmdline to map ports 9700 to 9799 between your container and your host OS, and you will need to give the container an externally callable IP address. I believe both of these things would feel easy to a Docker expert, but I do not know how to do them off the top of my head. Perhaps with these hints you will find the details with a quick web search.

I will check back tomorrow (running out of energy and laptop battery) to see if you’ve had any success.


#4

Thanks for your reply, Daniel!

The fact is that I’m a complete Docker newbie. I’m hoping to get some knowledge about it with this project… I’ll be trying what you told me, and will report back any outcome.

In any case, it’d be good for the Sovrin team to prepare a brief documentation on how to run the validator (as well as the client and any other Sovrin service) with Docker… Knowing how to run each piece step-by-step is actually very valuable. But for practical purposes, I think focusing on Docker might alleviate significant pain for lots of users.

Thanks again.


#5

I have tasked an engineer to begin working on the documentation you requested, Carlos. ETA a few days.


#6

Very much appreciated.


#7

Hello,

I just tried the previously mentioned steps in order to run a node directly on my machine (no Docker), and the same error occurs. Then it might be possible I’m doing something wrong. After I successfully manage to run a node directly on my machine, I will try doing it from within the Docker container.

Any ideas on what could I be doing wrong?

I used the iptables command in the following way:

sudo iptables -A INPUT -p udp --dport 9700 -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 9700 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 9799 -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 9799 -j ACCEPT

Then I initialized the node and client keys with:

init_sovrin_raet_keep --name Holis

(no errors given)

However, the command “start_sovrin_node Holis 9700 9799” fails with ConnectionRefusedError

So I’m assuming the problem is not linked to Docker, but something entirely different.


#8

My orientdb service wasn’t properly started. That’s why a socket connection error occurred. Now I’m able to run validator nodes locally without inconvenient. However, the problem keeps happening from within Docker containers. It might be a port issue, as was mentioned. I’ll keep on trying.

Thanks for your help.


#9

To answer your original question, I would love to see a virtual appliance. OVA would probably be the favored format, and it’s easy to convert to Hyper-V with a few lines of powershell.


#10

I’m trying to walk through this getting started guide: https://sovrin.org/wp-content/uploads/2017/04/getting-started.pdf, but I’m having trouble setting up a validator node in Azure. This document provides detailed instructions on how to set one up with a vm, but the vhd cannot be found here: https://sovrindisks557.blob.core.windows.net/vhds/sovrin-windows201681510726.vhd?st=2016-09-30T03%3A09%3A00Z&se=2099-10-01T03%3A09%3A00Z&sp=rl&sv=2015-12-11&sr=b&sig=bfAdVPGo3jofNWH%2BuqaeiJkQ9mBm436%2F%2FnNxXGMt

Where can I find the vhd?


#11

Daniel:

The VHD is stale, so it wouldn’t help you anyway.

The simplest way to get through the Getting Started Guide right now is to use Vagrant and Virtual Box as documented in the guide. That is a complete solution, and it works. The second easiest way is to fire up an ubuntu VM in the cloud (either AWS or Azure) and then use apt install to put sovrin on it. The challenge with the Getting Started workflow, if you go down this raw install route, is that you also need to interact with a pool/network–so starting up a VM in the cloud will only provide part of the setup.

Sovrin’s Getting Started Guide is going to change in the next couple weeks as the network is deployed more officially, so if you wait, the story will get better. Perhaps, for example, the VHD will get refreshed. In the meantime, i recommend the vagrant solution.


#12

Thanks! I’ll watch for the new getting started guide.


#13

This is an old thread, but in just in case, the correct location for the Getting Started Guide is https://github.com/hyperledger/indy-node/blob/stable/getting-started.md