autopeering visors to a hypervisor

[0pcom]

The autopeering of visors to a hypervisor is accomplished in skybian once on the first boot via an http endpoint which provides the public key of the hypervisor.

The system I propose will integrate into the package scripts and systemd services to replace this...

#query remote node for pk
_pubkey=$(curl ${_ip}:7998)
#rough errorcheck
if [[ ("${_pubkey}" == *"FATAL"*) || ("${_pubkey}" == *"Failed"*) ]] ; then
_pubkey="0"
fi
fi

#configure skywire
skywire-autoconfig ${_pubkey}

...in a much better way inside the skywire source code using somewhat arbitrary functionality which I will describe.

From the perspective of the packager, it's highly advantageous for certain things like getting a remote hypervisor public key via some script logic to be moved into the source.

It is possible to override defaults of a systemd unit by creating a drop-in file (i.e. /etc/systemd/system/skywire.service.d/skywire.conf)

This drop-in file could be provided by the skybian package to use different flags to start the visor:

ExecStart=/usr/bin/skywire-visor -pl 'skywire-cli hv pk`

In the above example, the skywire-visor -l --autopeer flag is a slight modification of the -j flag which explicitly sets a remote hypervisor at runtime; the -l flag should allow an arbitrary command to be specified which is assumed to return a public key or list of public keys. This gets around the fact that subshells will not work in the systemd file, in any case we don't want to evaluate that command only immediately but also when the visor cannot connect to the hypervisor.

The visor should only try intermittently to re-peer. Errors returned by the command should be printed in the visor's logging, preferably. This should not need to interrupt the running visor process.

Allowing for an arbitrary command to be specified grants ultimate flexibility to this system and allows any scheme to be implemented.

The second command, skywire-cli hv pk should by default (but changeable with flags) query the http endpoint provided by the srvpk.service.. at the xxx.xxx.xxx.2 ip address of the current subnet with default port 7998
It should return the public key or the error from the other skywire-cli command.

It was suggested by @jdknives to keep the srvpk.service how it is.

The major change here, what I am suggesting actually takes the skywire-autoconfig script out of the picture and also the hypervisor key is not actually set in the config.

It is possible to set it in the config.

My suggestion for that is a skywire-cli config gen flag which is similarly able to execute an arbitrary command which is assumed to return a public key or list of public keys. The output of config gen could then be filtered (preferably internally with another flag) to only print out the hypervisor public key.

While it may be worthwhile to implement this for / with config gen I think it's a little bit overkill to think about trying to update the config with the hypervisor. We definitely should not do this in certain instances.

In the instance that someone has set their desktop as the remote hypervisor for their visors, there must be some way to disable this from causing errant peering attempts. The user would need to set some environmental variable on all the boards is the easiest way I can think which won't need to be repeated, still a sub-optimal solution in that regard

Assuming that the automation here does all the hard work of the initial peering, is it too much to ask that the user do some additional config after the fact?

My only other solution would be to not set the hypervisor key at all in the config by default and the user must explicitly set their public key (via skywire-autoconfig) in the visors after they appear in the hypervisor UI with the following command exactly:

skywire-autoconfig $(skywire-cli visor hvpk)

so the skywire-visor -l flag should be ignored if remote hypervisors are set in the config file.

[0pcom]

PR #1309