We use the snapweb snap in various tests. The package is now
unpublished from the store and thus the tests break. We really
don't want this package anymore.
interfaces/seccomp: generate global seccomp profile (#6516)
* interfaces/seccomp: generate global seccomp profile
When initializing the seccomp backend, write the global profile to disk.
This is picked up by snap-confine and applied to all non-classic snaps.
Signed-off-by: Zygmunt Krynicki <email address hidden>
* interfaces/seccomp: handle big endian arches
Signed-off-by: Zygmunt Krynicki <email address hidden>
d755140...
by
"John R. Lenton" <email address hidden>
overlord/snapstate: add some randomness to the catalog refresh (#6506)
overlord/snapstate: add some randomness to the catalog refresh
Without this change, once the catalog refresh was successful it was
done every 24 hours exactly. This meant that if other external factors
conspired to synchronise a large number of machines to do a catalog
refresh at the same time, we'd get a thundering herd every day.
This change adds a delta to spread things out.
Also, previously the presence of the `sections` file was used to
mean "a catalog refresh happened", when it's the `names` file that is
more indivative of that; sections can easily succeed (or fail with no
error, returning empty) and `names` (and `commands.db`) fail. This
changes that.
Lastly, due to a bad systems: line the snap-advise-command integration test
wasn't running. This fixes that, tweaks the prepare so that it works
as it had apparently bitrotten, and then makes it skip for now because
the store.
We need to run dh_apparmor before dh_systemd_enable so that
the snapd.postinst is written in the right way.
The old code was doing things in the *wrong* order:
- it (re)starts snapd first
- it reloads the snap-confine apparmor profile *after* that
which of course means that on an upgrade there is a time window
in which snapd is available for the system-key check but
snap-confine has an old profile and will die because it tries
to do things that it cannot do with that old profile.
Together with the removal of "snapd.framework.target" this
race caused real world upgrades to stop snaps.
overlord/snapstate: discard mount namespace when undoing 1st link snap
When a snap is installed for the first time but the installation fails,
e.g. because the install hook fails or because a service fails to start,
the mount namespace would remain behind, possibly messing up subsequent
attempts to install the snap.
When the undo handler for "link-snap" detects that it runs for the 1st
revision is already removes snap cookies, this is the perfect place to
add the logic to discard the mount namespace.
