2 Commits

Include renames

Author	SHA1	Message	Date
Oliver Calder	82bc756545	feat(snap): run gateway as a user service by default (#4099) ... * 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>	2026-10-09 11:39:08 +00:00
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 a67567e58, where the gateway is not stopped before refreshes. The `post-refresh` hook now restarts the gateway if the TLS configuration was corrected, so we don't have to enforce restarting the gateway on every refresh even when not necessary. Thus, set `refresh-mode: endure`, and let the hook decide when the gateway needs to be restarted. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * fix(snap): update docs and tests to reflect snap hook changes Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * docs(snap): remove verbose explanation of snap gateway refresh behavior Signed-off-by: Oliver Calder <oliver.calder@canonical.com> --------- Signed-off-by: Oliver Calder <oliver.calder@canonical.com>	2026-10-01 15:10:38 +00:00