Documentation
¶
Overview ¶
Package cliconfig cmd/skywire-cli/commands/config/deployment.go c4-vis-cli
A whole deployment in one visor. `config gen --deployment <host>` writes the embedded service blocks and points the visor at them instead of at prod. `config deployment` prints the services-config other visors join that deployment with.
Package cliconfig cmd/skywire-cli/commands/config/envfile_template.go c4-vis-cli
The SKYENV template as a value other commands can write, rather than only something `config gen -q/-Q` prints.
On a packaged install the template reaches /etc/skywire.conf through the install hook — the deb/arch packages run `[[ ! -f /etc/skywire.conf ]] && skywire cli config gen -pqQ /etc/skywire.conf` once and never touch it again, so operator edits survive every upgrade. Installs with no such hook (a `go install`, a release binary unpacked by hand, the browser visor) never get the file, and then every knob in it is invisible: the operator has nothing to edit and `skywire autoconfig --<flag>` fails because skyenvfile.Update can only edit a file that exists.
Exporting the template lets `skywire autoconfig` create it on the same generate-once-if-absent terms, so those installs behave like a packaged one.
Package cliconfig cmd/skywire-cli/commands/config/envfiles.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/gen.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/gen_limits.go
Package cliconfig cmd/skywire-cli/commands/config/identity.go c4-vis-cli
`skywire cli config identity` — export the keypair a config file holds, or install a secret key into it. The desk's identity window drives this for a browser visor (#4484 stage 5): the tab's key lives in the visor's own config file in the exec worker's filesystem, which the running visor's RPC never reveals (GetRuntimeConfig redacts sk), so the file is read here.
Package cliconfig cmd/skywire-cli/commands/config/parse.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/root.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/services.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/set.go c4-vis-cli
`skywire cli config set` — edit the RUNNING visor's config, field by field, through the visor itself.
Editing skywire-config.json by hand while a visor runs does not stick: the visor re-marshals its in-memory config over the file on every setter that persists, so a hand-edit is erased at the next flush (an is_public=true patch typed into the file was reverted within the hour). `config update` edits the FILE and has the same problem on a running visor. This command routes the edit through the visor's own SetConfigFields RPC instead, so the visor's flush carries the change rather than clobbering it.
Reading a value back is `config show`, which already reads the RUNNING visor's config (sk redacted) and honors the global --jq filter:
skywire cli config show --jq .transport.transport_port
Package cliconfig cmd/skywire-cli/commands/config/show.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/skyenvdefaults.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/skyenvpath.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/skyenvpath_common.go c4-vis-cli
Package cliconfig cmd/skywire-cli/commands/config/update.go c4-vis-cli
Index ¶
Constants ¶
This section is empty.
Variables ¶
var RootCmd = &cobra.Command{
Use: "config",
Short: "Generate or update a skywire config",
Long: "Generate or update the config file used by skywire-visor.",
}
RootCmd contains commands that interact with the config of local skywire-visor
Functions ¶
func EnvFileTemplate ¶
EnvFileTemplate returns the annotated SKYENV template for this OS with the install-mode line uncommented — PKGENV for package paths, USRENV for userspace — which is the one choice the file cannot be silent about: it decides where every other path resolves.
Everything else is left commented at its documented default, exactly as `config gen -Q` writes it, so the file reads as a menu of what can be set.
func FlagArgsForSkyenv ¶
FlagArgsForSkyenv returns the `config gen` arguments that set what the SKYENV line key=value would — value in the plain form autoconfig holds before it quotes it for the file: "true"/"false", a string, a number, or a comma-separated list. ok is false when no flag controls key.
It exists for a caller that has just EDITED the SKYENV file and re-enters `config gen` in the same process (the browser build has no subprocess): gen reads the file into its flag DEFAULTS at init, so an edit made after that is invisible to it unless passed explicitly. A subprocess would have re-read the file; passing the flags gives both paths the same result.
Source Files