mirror of
https://github.com/NVIDIA/OpenShell.git
synced 2026-10-02 07:34:45 +08:00
main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Oliver Calder
|
1ad4e428a6 |
fix(snap): simplify snap hooks (#3988)
* fix(snap): simplify snap hooks
The `post-refresh` hook runs after initial snap installation as well, so
there is no need to call the `install` hook from within the
`post-refresh` hook; instead, the logic can simply be moved into the
`post-refresh` hook directly, and the `install` hook removed.
Also, the existing `install` hook logic looked for an insecure
configuration, and if found, replaced the entire configuration file with
a minimal default in the current format. But OpenShell does that default
behavior without any config file, so we may as well simply remove the
configuration file entirely to keep up-to-date with the current default
behavior. Let OpenShell create a configuration file if it needs to,
rather than auto-create one via the packaging scripts.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): remove the connect-plug-docker hook
The `openshell:docker` is auto-connected to the system `:docker` slot,
so there should not be a need to separately restart the gateway service
when the interface is connected.
For locally-built test snaps which were not published to the store, the
autoconnection is not made, but when the snap is installed, the gateway
will attempt to start anyway and fail to find any available compute
driver, so quickly restart until it hits the systemd start-limit, after
which systemd prevents the service from being started again. If a user
tries to manually connect their locally-built `openshell` snap to the
`:docker` slot, then the `connect-plug-docker` hook runs and triggers a
restart of the gateway, which will usually fail because the start limit
has already been hit. An error in the hook will thus cause the interface
connection to be undone, which is undesirable.
Thus, we can remove this hook entirely, and instead allow interface
connections to succeed as intended. The user still needs to manually
restart the gateway service after making a manual connection (as was the
case previously) and probably needs to `systemctl reset-failed` first,
but at least connection will succeed beforehand so they can proceed with
these steps.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* fix(snap): set refresh-mode: endure again, with manual restart
Return to the previous behavior before commit
|
||
|
Drew Newberry
|
a67567e583 |
fix(snap): require mTLS for the snap gateway (#3726)
* fix(snap): require mTLS for the snap gateway Replace the installer opt-in with an authenticated snap gateway. The wrapper no longer forces plaintext, so the gateway serves TLS from the bundle it already generates in $SNAP_COMMON/tls. The install hook writes a config that enables mTLS user auth instead of unauthenticated access, and a new post-refresh hook migrates the exact legacy default on existing installs. install.sh waits for the gateway, detects whether it serves TLS, copies the client bundle into the target user's snap state directory, and registers the gateway over HTTPS. Older plaintext snap revisions still register over HTTP with a warning. The release canary asserts mTLS auth and HTTPS registration. Signed-off-by: Drew Newberry <anewberry@nvidia.com> * fix(snap): pass config preflight and detect the mTLS gateway reliably An explicit [openshell.gateway.mtls_auth] table fails config preflight, which validates mTLS auth before the local TLS bundle supplies the client CA. Write a default that pins the Docker driver instead; with the wrapper's TLS bundle the gateway requires client certificates and enables mTLS user auth automatically, as the native packages do. The mTLS gateway rejects TLS handshakes without a client certificate, and it still answers plaintext loopback HTTP for sandbox service routing, so the installer could misdetect it as a legacy plaintext gateway. Probe HTTPS with the root-owned client bundle, and treat a gateway as legacy only when a plaintext gRPC Health call succeeds. Signed-off-by: Drew Newberry <anewberry@nvidia.com> * chore(snap): simplify install hook comment Signed-off-by: Drew Newberry <anewberry@nvidia.com> * fix(snap): migrate insecure gateway configs on refresh Signed-off-by: Drew Newberry <anewberry@nvidia.com> * refactor(snap): simplify mTLS detection and config migration Detect the mTLS snap from the installed revision's post-refresh hook instead of probing plaintext gRPC, and drop the scheme global. Remove the installer's pre-hook config fallback, which is dead now that every channel ships the install hook and which wrote the insecure default. Give the install hook a single write path with a simple backup name, and shorten the manual client certificate steps. Signed-off-by: Drew Newberry <anewberry@nvidia.com> * fix(snap): stop keeping a copy of replaced insecure configs Signed-off-by: Drew Newberry <anewberry@nvidia.com> * feat(install): make the snap an opt-in install method Stop selecting the OpenShell snap just because the snap command exists. Linux installs default to the Debian or RPM package; OPENSHELL_INSTALL_METHOD=snap (or deb, rpm) selects the package explicitly. Hosts that already have the OpenShell snap keep refreshing it rather than gaining a second gateway on the same port. The release canary and snap repro script opt in explicitly. Signed-off-by: Drew Newberry <anewberry@nvidia.com> * fix(snap): let the gateway auto-detect its compute driver Signed-off-by: Drew Newberry <anewberry@nvidia.com> * fix(snap): restart the gateway after refresh Published revisions use refresh-mode: endure, and snapd honors the old revision's setting during a refresh, so the plaintext gateway kept running with the migrated config unused until a manual restart. Restart the gateway from the post-refresh hook so the mTLS config takes effect immediately. Signed-off-by: Drew Newberry <anewberry@nvidia.com> * docs(snap): drop refresh notes from the snap description Signed-off-by: Drew Newberry <anewberry@nvidia.com> * docs(snap): trim snap refresh notes from installation docs Signed-off-by: Drew Newberry <anewberry@nvidia.com> --------- Signed-off-by: Drew Newberry <anewberry@nvidia.com> |
||
|
Oliver Calder
|
e60098d748 |
fix(snap): install openshell snap via install.sh when snap available (#3656)
* 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> |
||
|
Evan Lezar
|
8d7db25403 |
fix(snap): recover gateway after Docker connection (#2866)
Signed-off-by: Evan Lezar <elezar@nvidia.com> |
||
|
Zygmunt Krynicki
|
19be5682d5 |
feat(snap): add openshell.term desktop app (#1693)
Add a desktop launcher for the OpenShell TUI so users can launch
"openshell term" from their desktop environment application menu.
The change adds three files:
- snap/local/term.desktop: desktop entry file for the application launcher
- snap/local/icon.png: application icon (copied from snap store data)
- snapcraft.yaml: new "term" app entry that runs "openshell term"
with home, network, ssh-keys, and system-observe plugs, plus install
rules to stage the desktop file and icon under meta/gui/
The desktop file references the icon via ${SNAP} which is resolved
at runtime to the snap installation directory. The term app reuses
the same connection plugs as the main openshell app.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
|