* fix(ci): allow accepted protobuf breaks for one prerelease
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
* fix(ci): cover all v0.1.6 prerelease candidates
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
* docs(ci): document full rollback of temporary protobuf exception
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
* fix(ci): complete protobuf test copyright header
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
---------
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
* ci(release): infer optional workflow tags
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* fix(release): use resolved tag in success notifications
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* fix(release): pin prerelease notes to resolved candidate
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
---------
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
Branch Checks never runs on main, so PR mirrors had no main rust-checks
cache to restore and each one saved its own. Per-binary release build
caches were also saved from every branch. Together they filled the 50 GB
cache quota within hours and evicted main's caches.
Save per-binary caches only on main, and add a Rust Cache workflow that
builds the Branch Checks test targets on each push to main so PRs and
merge groups can restore a matching rust-checks cache.
Signed-off-by: Kris Hicks <khicks@nvidia.com>
* feat(snap): publish prerelease builds to latest/beta channel
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fixup! feat(snap): publish prerelease builds to latest/beta channel
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): use concurrency group when checking version to publish snap
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* feat(skills): add release-captain skill for the weekly release cadence
Add an internal skill with Monday pre-flight, Tuesday stable cut, and
recovery steps for the RFC 0014 release train. All tag, workflow, merge,
and Slack actions require explicit maintainer approval.
Closes#4433
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): document starting a release train after tag-push triggers
Pre-release tag pushes now start Release Tag, so the skill no longer
dispatches after pushing. Add seed-commit selection from Release Dev
results, a commit-type summary for the patch/minor decision, and a
recovery row for a tag push that starts no run.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): create lightweight release tags regardless of signing config
With tag.gpgSign enabled, git tag creates an annotated tag and blocks in
an editor. Disable signing for the release tag commands so they create
the same lightweight tags as Auto-Tag.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): capture release captain lessons from starting 0.1.5
Note that Auto-Tag skips report success and show how to tell from the
log, the UTC time of the schedule across DST, where pre-releases appear
instead of the Releases page, why tags need a forced fetch, reading
workflow triggers from origin/main, the rolling dev tag, and the common
compatibility-review false positive for unpublished internal crates.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): add recovery for pre-releases failing on new RustSec advisories
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): recommend fixing forward to a green pre-release
A failed pre-release doesn't end the train. Document merging the fix and
tagging the next pre-release by hand once its Release Dev run passes,
letting the failed run finish for its remaining signal.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): describe the triage channel and thread replies for pre-release failures
Name #openshell-triage, where TriageBot posts each failed Release Tag
attempt, and ask the captain to reply in the failure's thread so others
know a fix is underway. List common transient failure types and rerun
once when a failure looks unrelated to the commit.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): drop Codex Security from release captain run matching
Codex Security no longer runs in release qualification (#4469), so the
stable release can't rely on a pre-release's Codex result and runs can't
be matched by its job name. Match dispatched runs by the qualification
artifact name instead.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): describe where and how to post the release coordination thread
Name the CNCF Slack channel, note that the release ships from main with
no release branch or cherry-picks, and add an example post.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): make seeding the next train the outgoing captain's handoff
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): update release captain for the Release workflow and add usage guide
Stable releases are now dispatched with release.yml, which selects the
qualified pre-release and creates the tag, and pre-releases run in
release-prerelease.yml. Replace the stable tag push steps and stale
recovery rows, add a preview of the selected candidate, add a section on
when to use each part of the skill, and trim redundant explanations.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): explain what the release cutoff guarantees
The release ships the final pre-release's commit only if it passes, so
the coordination post must not promise that every PR merged by the
cutoff ships. Describe the Auto-Tag and hand-tagged cutoffs, and tag
the final pre-release by hand on Tuesday for a later cutoff.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): add release notes review and v0.1.5 release day lessons
Review the release notes preview from the Pre-release run before
approval, and describe how Release regenerates them. Correct the thread
when the shipped pre-release was cut before the posted cutoff, require
maintainer agreement for accepted-risk breaks in a patch release, and
add recovery rows for startup failures and release notes failures.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): make starting the next train the captain's final duty
Move starting the next train after closing the loop, so it is the last
Tuesday step. The captain's week ends when the next -pre.1 Pre-release
run passes or its failure is handed off. Also move open milestone items
when closing the loop.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): trim the release captain skill to its durable steps
Remove repeated guidance, week-specific examples, fragile commands, and
debugging detail an agent can derive from the workflows. Keep the
approval guardrails, the weekly steps, and a short recovery table.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(ci): document Release Auto-Tag and pre-release notes previews
Add Release Auto-Tag to the workflow table, including that each train's
-pre.1 is pushed by hand, and note that every Pre-release run writes a
release notes preview.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): add a template for the release announcement reply
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): watch pre-releases in the week before your turn
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): remove internal channel references from release captain
Check pre-release runs directly instead of relying on an internal
notification channel, and drop internal Slack channel IDs.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* docs(skills): fix pre-release failures in a new number via Auto-Tag
A rerun repeats the same commit, so a failure that needs a fix ships
in the next -pre.N. Cut it by dispatching Release Auto-Tag from the tip
of main, and tag a specific commit by hand only when needed.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
---------
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): reuse the promoted prerelease's release notes preview
Stable releases now publish the selected prerelease's release-notes
artifact with the prerelease tag replaced by the stable tag. Release
falls back to generating notes when the preview is missing, expired, or
malformed, or when dispatched with regenerate-notes=true. The selection
script exposes the qualified Pre-release run ID for the download.
Closes#4753
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): reuse release notes from the promotion job
Download and retag the preview in Select Qualified Prerelease, which
already knows the qualified Pre-release run, instead of a separate job.
Drop the regenerate-notes input and preview format checks.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): name the publish notes input after the caller's result
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
---------
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): name the failed stage and failing jobs in pre-release failure notices
The pre-release failure notification said only that the run failed.
Name the failed stage (build, publication, or release qualification),
link the tag, and list each failing job of the run attempt with a link.
Skip the aggregate Release Qualification job unless it is the only
failure, and still send the message if the jobs lookup fails.
Closes#4718
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): simplify the failure notice to a list of failed jobs
Drop the stage headline and the aggregate-job filtering. Keep the
existing message and append a link to each failed job.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
---------
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): promote qualified prereleases to stable
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* fix(release): preserve qualified images during stable publication
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(release): run shared release jobs with Nix
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* fix(release): recheck latest before publishing shared channels
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
---------
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(release): notify Slack when a prerelease succeeds
Post a top-level message to the triage webhook when a prerelease completes, so recovery after failures is visible. The message omits the triage mention.
Closes#4604
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(release): link the prerelease tag in the success notification
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
---------
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(compatibility): review PR breaks and acknowledge release risks
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* fix(ci): use matching compatibility review tooling
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(compatibility): scope Rust SDK review to public exports
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(compatibility): account for Go struct field additions
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(compatibility): restrict egress and fix report retries
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
---------
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* test(tmachine): add K3s PostgreSQL and mTLS conformance installer
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* fix(tmachine): reach the HA TLS gateway through its ClusterIP
Drop the port-forward restart removed by the ClusterIP change, resolve the Service DNS name covered by the server certificate to the ClusterIP, bound each authenticated API wait attempt, and collect diagnostics from every gateway Pod.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* ci(tmachine): run K3s PostgreSQL and mTLS conformance
Add the k3s-ha-tls installer to every core conformance matrix so Branch E2E, Release Dev, Release Tag, and manual Integration Tests cover three gateway replicas sharing PostgreSQL behind mTLS.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* refactor(tmachine): rename k3s-ha-tls installer to k3s-ha
TLS is part of the supported HA configuration once gateway replicas share PostgreSQL, so the installer name only needs to distinguish HA from the single-replica k3s lane.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* refactor(tmachine): install K3s HA in a single Helm rollout
Add an optional Helm values overlay to the K3s installer so the k3s-ha
installer stages PostgreSQL first and installs the three-replica TLS
gateway directly, instead of installing a plaintext gateway and upgrading.
Drop the redundant unauthenticated-users override and the install-time
API wait, which the conformance playbook already performs. Share K3s
installer inputs in the tmachine configuration.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* fix(tmachine): make K3s HA staging rerunnable and wait for PostgreSQL
Apply the OpenShell namespace instead of creating it so the staging play
tolerates an existing namespace, and wait for the PostgreSQL rollout so
gateway Pods do not start crash-looping against a missing database.
Reflow and pluralize the K3s lane notes in CI.md.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
---------
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* test(k3s): connect tmachine clients directly to ClusterIP
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* test(conformance): wait for a connected gateway on every installer
Replace the K3s-specific boot readiness hook with one shared gateway wait in the conformance playbook. Skip conformance and collect the existing diagnostics when the gateway never connects. Discover the gateway Service port with its ClusterIP, and capture both iptables backends in K3s diagnostics.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* test(tmachine): centralize gateway diagnostics and trim K3s changes
Move failure diagnostics into one openshell_diagnostics role that collects the systemd gateway journal and, when K3s is installed, the K3s diagnostics. Drop install-time diagnostics so the K3s installer change stays minimal, revert unrelated skill edits, and shorten the CI.md note.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
---------
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>
* feat(snap): run gateway as a user service by default
Replace the existing system `gateway` service with separate
`user-gateway` and `system-gateway` services. For new installs, only the
`user-gateway` service is enabled. For existing installs, only the
`system-gateway` service is enabled.
Existing installs continue to have a one-time migration which removes
legacy insecure configurations. It is up to `install.sh` or users to
manually copy mTLS credentials from the root-owned `$SNAP_COMMON/tls` to
the invoking user's OpenShell snap directory. This is explained in the
snap description in `snapcraft.yaml`, visible in the Snap Store listing
and via `snap info openshell`.
Service enablement is now managed by a new snap configuration option
named `gateway-mode`, so users can switch from one mode to another via
e.g. `sudo snap set openshell gateway-mode=user`. The `install` and
`post-refresh` hooks select which service to start by setting this mode.
If the `gateway-mode` is already set, then we know the one-time
migration has already taken place.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): simplify the snap gateway wrapper
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): use `snap start --user` when running as non-root
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): ensure install.sh waits for the correct docker daemon
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* feat(snap): document how to safely switch between gateway modes
New installs run the gateway as a user service by default, while
upgrades of existing installs from prior to the user gateway continue to
use the existing system gateway. The user and system gateway are
fundamentally different services and there is no way to migrate state
between them.
However, it may be desirable for a user to run the gateway as a system
service after a fresh install. To support this, this commit adds
documentation for how to safely transition from the user gateway mode to
the system gateway mode, and vice versa.
Also, clarifies when it is necessary to manually copy TLS credentials
from the system gateway state directory to the user's home directory:
when upgrading a pre-TLS snap installation, or when switching from user
to system gateway mode. When upgrading an existing install with an HTTPS
gateway running as a system service, copying credentials again is not
necessary.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* ci(release): add advisory compatibility review
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* test(ci): remove compatibility reviewer test harness
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(release): run compatibility SDK in the dev shell
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(release): trigger a one-shot compatibility review
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(release): remove one-shot review trigger
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
---------
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
Revert PR #4107 and restore binary installers for the Podman driver qualification lanes.
This reverts commit 8990656c13.
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* feat(ci): detect breaking protobuf changes
Compare the proto module against the PR or merge-group base and report Buf violations in Branch Checks. Add local reproduction and fixture coverage.
Closes#3794
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
* fix(ci): pin protobuf check container image
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
* fix(ci): qualify protobuf compatibility by release train
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* refactor(ci): reuse protobuf compatibility action
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* refactor(ci): run protobuf checks as a Nix app with one ref
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
---------
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
Co-authored-by: Mrunal Patel <mrunalp@gmail.com>
* test(tmachine): add K3s conformance scenario
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* refactor(tmachine): use Helm values file for K3s installer
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(tmachine): run K3s conformance in integration jobs
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* ci(tmachine): verify installer scripts and document version baseline
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
---------
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
* fix(policy): propose rules for unknown DNS hosts
Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
* docs(policy): clarify synthetic DNS use across protocols
Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
* fix(policy): harden unknown-host DNS observations
- Emit the policy_dns_ineligible denial for every unknown name and
report observation staging failures as DNS failure events.
- Refuse unknown names during fail-closed quarantine and after the
observation budget, now a quarter of each address family's pool.
- Pin transparent TCP to the mapping of the deciding policy generation
so a reload between DNS and authorization fails closed.
- Stop Docker workloads from inheriting host DNS search domains, which
let the first expanded short name claim an observation address.
- Share mechanistic draft polling in conformance, register
new-hostname-proposal in the installed suite, and update docs.
Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
* test(policy): build policy DNS proxy tests on every target
The proxy tests name PolicyEndpointId, which proxy.rs imported only on
Linux, so the macOS test build failed. Import it for test builds too.
Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
* fix(policy): name DNS queries and mapped hosts in OCSF denials
DNS denial and failure events attached port 53 to the queried name,
which read as a connection to that host. They now carry only the name.
Transparent TCP denials for a policy DNS address show the mapped
hostname and keep the synthetic address in dst_endpoint.ip.
Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
---------
Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
* fix(install): avoid installing incompatible docker snap
The work to land RFC-0012 added new restrictions when interacting with
Docker by setting `NoNewPrivs`. This prevents the `docker` snap from
transitioning its AppArmor profile from `snap.docker.dockerd` to
`docker-default` when it tries to launch a container. Thus, the `docker`
snap is currently incompatible with OpenShell.
This commit prevents `install.sh` from installing the `docker` snap
before installing the `openshell` snap, and instead requires the user to
install a non-snap Docker daemon before proceeding with installing the
snap. Systems without the `snap` command are unaffected, since they
install native packages without checking for the presence of Docker or
other compute providers.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): only snapd 2.76 for openshell snap since store installs work
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fixup! fix(install): avoid installing incompatible docker snap
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fixup! fix(snap): only snapd 2.76 for openshell snap since store installs work
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): update stale snap docs and tests
Previously, the `openshell` snap required the `docker` snap. Now, it
works with any Docker daemon running on the system. Furthermore, the
`snap-declaration` assertion on the `openshell` snap when installed from
the Snap Store causes the `openshell` snap to always connect to the
system `:docker` slot, rather than a slot provided by the `docker` snap.
This commit updates the documentation, including the `description` field in
`snapcraft.yaml`, to ensure that all information is correct and
up-to-date.
Additionally, some tests connected the `openshell:docker` plug to the
`docker` snap's `docker:docker-daemon` slot, which is inconsistent with
how the `openshell` snap operates when installed from the store. Update
those tests to connect to the system `:docker` slot as well.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): require snapd 2.76 for openshell snap
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(nix): align snap gateway reproducer timeout with release-canary
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): require snapd 2.77 for openshell snap
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fixup! fix(snap): require snapd 2.77 for openshell snap
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* feat(snap): install openshell snap via install.sh when snap available
Change `install.sh` to install the `openshell` snap by default when
snapd is installed on the host. This installs the snap from the
`latest/stable` channel, which should match the most up-to-date release
tag on github.
If `OPENSHELL_VERSION=dev` is set for `install.sh`, then it will install
the `openshell` snap from the `latest/edge` channel, which matches the
latest dev release available on github.
The `openshell` snap currently requires Docker in order to function. If
a Docker daemon is already installed on the system, it will be used by
the `openshell` snap. Otherwise, `install.sh` will install the `docker`
snap first, wait for the Docker daemon to be ready, and then install the
`openshell` snap.
Also, update the `release-canary.yml` to split the `ubuntu-snap` job
into `ubuntu-snap-system-docker` and `ubuntu-snap-provisions-docker`,
which test the two aforementioned scenarios. Previously, `ubuntu-snap`
manually installed a given snap artifact as built from CI, but with
these new jobs, it instead uses `install.sh` to install the published
`openshell` snap from the `latest/edge` track, thus matching the
behavior of the other release canary jobs.
Make corresponding changes to the `nix` guest reproducer, documentation,
and tests.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): configure local gateway authentication
The `openshell` snap runs the gateway as a systemd system service, which
runs as root. Thus, the mTLS certs are generated by root and stored in a
root-owned directory to which non-root users do not have access. For
this reason, the snap's `openshell-gateway-wrapper` script sets
`OPENSHELL_DISABLE_TLS=true`.
This commit ensures that the `openshell` snap's gateway allows
unauthenticated local access by writing a default `gateway.toml`
configuration file during the install hook, which runs after the snap is
first installed but before services are started. The config file
contains sets `allow_unauthenticated_users = true`.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(install): configure snap gateway authentication
Recently, a new install hook was added which writes a default config
file for the `openshell` snap to allow unauthenticated local access to
the gateway. This is because the gateway service runs as root and the
mTLS certificates are not accessible to non-root users.
However, the `install.sh` script installs the `openshell` snap from the
snap store, and the published version may not yet have that new install
hook. Or, the user may already have the snap installed, in which case
the install hook does not run. In either case, we need `install.sh` to
ensure that the config file is written to set the gateway auth to
`allow_unauthenticated_users = true`, and then restart the openshell
gateway service.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fixup! feat(snap): install openshell snap via install.sh when snap available
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>