nickchomey
commented
6 months ago This all sounds great. My main question is about how does the sysadmin initially get access to/permissions for the user's system, so as to initiate the staging process described here? Ssh connection? User runs a bash script or otherwise activates a binary service?
I really should have called this repo NATS UP, because thats the goal. We want a system where a bare metal machine ( users desktop or Server ) can be provisioned with NATS and then provision with binaries flowing in from NATS Object Store.
The architecture is an Onion skin design with a core NATS that can hold the binaries and config and then outer NATS that are themselves created off the Core NATS.
There are only Layer 0 and Layer 1. It does not need to go on for ever.
Layer 0 could be hosted NATS from Synadia, that we use as our Layer 1. But it would also be Hetzner.
Layer 1 is User's machines
WE support binaries for:
Staging of Users boot are:
check go exists. if not, install if using gobrew or NATS Obj store.
check git exists. if not, install using NATS Object store ? I prefer the pure golang git libs but anyway.
Check makefile and / or Taskfile exists ? If not install off NATS Object store.
Check for NATS NSC, NAT SERVER. If not, install using NATS object store.
Staging of injection of binaries and config from Sys Admins POV:
A sys admin is someone that is adding binaries to the system to be "consumed" by the Users of the system.
These binaries are things that NATS UP will install based on the Makefile or whatever we use to declare what is needed.
The sys admin is essentially adding binaries to the NATS Object store. These can be and often are rolling out of a Github repo as many binaries representing the GOOS and GOARCH matrix.
Where's the config ?
The config is in a Git repo, and is likely JSON.