Alternatives or substituites for sky-imager / adapting skywire-startup script & systemd service

[0pcom]

Describe the bug I am attempting to reproduce exactly the skywire setup contained in skybian using packages

The key critical missing piece of reproducing this has been the configuration which is written with the sky-imager into the boot sector of the created images at /dev/mmcblk0

A substituite for this would entail using a regular file with the public key and IP address of the hypervisor, which is installed to a specific path in the filesystem via a package that is hosted in a local repository on the hypervisor. Visors are configured with this repository during bootstrapping.

Automatic configuration for this local repository can be achieved with environmental variables which are written to the images at the time of their derivation from the base image; along with any static IP configuration.

Another valid implementation would be for skyimager to generate a configuration file that can be used on the same machine, instead of putting this into the images.

Aspects of this issue

• can't run skywire as it is set up in skybian on x86_64
• can't use an existing installation on a microSD / must use a new implementation.

Environment information:

• OS: Archlinux
• Platform: linux

Additional context

I have debian packages which mirror the skywire installation in skybian

I also maintain all the skycoinproject repo packages in the Arch User Repos.

I have archlinuxarm images and an image creator for various SBCs in this skyfleet repo

I have just tested the sky-imager with a local DHCP image for orangepi prime. The sky-imager did not set the IP, but the image booted and bootstrapped correctly, and with the addition of networkmanager, when skywire-startup was called the IP address immediately became static and the hypervisor page was visible at 192.168.1.2.

So it works with my images, but I still want a different implementation which doesn't rely on the skyimager configuration.

Possible implementation

My solution has been to make a package which contains the hypervisor configuration at a certain path, which is installed by visors which are recieving their updates from a particular visor. a configuration script for skywire is run which will automatically configure a hypervisor and create this configuration.

I know there is more to this, such as the https configuration and the bit of configuration that is apparently used by networkmanager, but this shouldnt be too difficult to reproduce.

[some4]

I understand what you're saying @0pcom; you're looking for a file that references a Static IP for the node.

After setup: PubKey's and configuration can be found in /etc/skywire-*.json. Adding a new field with e.g. "IPv4" and the Visor's IP as it's value would satisfy this request, @evanlinjin.

With that change, I can update my setup script and (hopefully) smooth-out @0pcom's (and non-official) miner installations.

[0pcom]

I assumed that skybian was the example to follow.

Before, I was only not packaging skywire as it was set up in skybian because it's forbidden to use the /usr/local path for an installed package. This was changed, so I had no issue mirroring the skybian installation at that point.

The issue is that you have to run skyimager in order for skybian's systemd services and startup script to work. If you break your configuration, you have to start over and reflash rather than being able to preform the config from the running instance.

This prevents it from working on x86_64 and also on any already flashed image.

Perhaps it's somewhere between a bug and a feature request, but why should the implementation won skybian be so architecture-specific when a much more general approach that would work on anything is possible?

This is an attempt at standardization. It's too difficult to troubleshoot someone's DIY skyminer when they followed any one of dozens of guides to get where they are. Use a package and the installation is standardized to exactly the way it is in skybian. I would think that has value.

[some4]

Placing additional fields in skywire-*.json will be problematic as skywire-visor somtimes modifies it's config file and would, hence, discard unknown fields. I see no issue creating an additional config file for this specific use case.

@evanlinjin : better leave it alone then :)

But, please advise with that config file that's within the file system.

Although, I am still confused as to what exactly the problem is.

Based on conversations in Telegram, some concerns:

• Skybian being exclusive to Official Miners; tough to support non-official
• No proper way to update the underlying system; we re-image and write over sdcards for updates
• golang not being installed; just binaries

@0pcom has done work with Debian/Arch packaging--maybe add a Skybian Apt repository?

Is it possible to link Github releases as a package repo?

Thank You

[jdknives]

@some4 Hey. Just an update. @asxtree has been working on a Skybian image for RPis. I tested the image today and it worked fine, so I think we will release that soon to at least cover RPis.

Also @0pcom has a PR here https://github.com/SkycoinProject/skywire-mainnet/pull/355 for a basis for skywire-mainnet apt package. (If I understand the intention of the PR correctly). Would be a good idea to install Go with Skybian.

@evanlinjin putting you in CC.

[0pcom]

@some4 Is it possible to link Github releases as a package repo?

only for archlinux because on arch the package repo is all in one directory / at the same level.

I don't think we need a repo of pre-compiled packages for arch right now. Using yay and the AUR repos for whichever package is sufficient; especially when it comes to binary releases such as we have now for skywire-mainnet, little time is saved on the deployment end versus the overhead / inherent delay of maintaining and updating the package repo with the most recent version; since it's possible to automatically build the package all I need to do is update the version and checksums to make every subsequent build target the latest version version.

Additionally, I have a skywire-mainnet package (the old format I was using) in the AUR that will build from source to the latest commits and that will support any architecture / ones the release doesn't cover.

In theory the package directive in the Makefile would accomplish the same thing with debian-based images for which there isn't a binary release that matches the host architecture.