Separate dmsgpty binary

[jdknives]

Feature description

It needs to be discussed if we should ship a separate dmsgpty binary with Skywire in order to allow for instance the updating process of Skywire to be improved. Currently restarting the visor also breaks the connection via dmsgpty which makes manual interventions and fixes impossible in case something goes wrong during the update.

Details are to be determined.

[mrpalide]

In #1250, I added dmsgpty-cli to skywire-cli, is it sufficient for this ticket? 🤔

[0pcom]

this will be solved in #1254

@mrpalide will just need you to make it work for windows

[0pcom]

I see the point you are making about updates @jdknives ; however it is not possible or not advisable to distribute a separate dmsgpty(-host) binary for updates currently.

Basically, let's assume that we have the dmsgpty host running on a service which provides this other means of accessing the visor for updates. When that process is stopped during the update itself, it will kill the ongoing update.

It would be possible to do it as another package, but updating that other one would not be possible remotely for the above reason.

However, I note that ssh is able to work even when updating the ssh package. Ssh is simpler in that it's only listening for a connection, while for dmsg, a connection must first be established to the dmsg network.

Further investigation is warranted, however in my assessment the proposed solution is not going to be effective and will suffer the same shortcoming as the current system.

With all that said, it is possible to update the visor over skywire (for instance via dmsgpty or ssh over socks5) by using a separate systemd service (currently called install-skywire.service) which may be invoked over the existing connection. Because systemd starts that, it is not considered a child process of the visor and therefore it does work to update

However, the connection for the current session is expected to break in the course of starting this service and great care must be taken to not render the board inaccessible, which is always a risk with remote updates.

The advised procedure to remotely update a multi-node cluster is to connect to one (over skywire) and then to update every other node except the one you are connected to in that cluster. Then, establish a connection to one which was updated and update the one you had connected to originally.

[0pcom]

We now have cmd/skywire-deployment/skywire.go and a release of the same (for linux) which includes dmsgpty utilities, as well as a dmsg socks5 proxy which is even better as a fallback way to access remote visors.

We have also gotten rid of the binary updater since this ticket was filed ; and users have encountered no such errors which necessitate this functionality ; however it can be included in the package via systemd service which would run a separate instance of dmsgpty host and / or the dmsg-socks5 proxy which can be accessed remotely as a fallback for instances where the visor cannot be accessed for one reason or another.