`snapd.mounts-pre.target` will be before any mount unit,
`snapd.mounts.target`. Now we can schedule before or after mounts
without needing to modify the mount units.
We also install those mounts to `snapd.mounts.target` so that we can
make snapd.service for example, "want" all mounts.
The snapd.manage script is the interface that the base snaps will
use to start/stop snapd when snapd is run from a base.
Putting the script inside snapd means that we can evolve it without
having to modify any of the bases that use it. If we e.g. use
more systemd units etc.
There will be a coresponding PR for core18 that will use this
script to launch snapd on boot.
Note that this is currently hard to (spread) test because our
current core already has a snapd.{socket,service}. However once
we can bootstrap a core18 system testing this will happen naturally.
This patch adds a new systemd service unit that loads apparmor profiles
on early machine boot-up. It is needed because there are no standardized
apparmor userspace tools that load profiles from
/var/lib/snapd/apparmor/profiles. On Ubuntu and Debian the init scripts
are patched to support this internally but, e.g. on openSUSE they do not.
In general distributions don't ship vanilla upstream init scripts and
until a future release that unifies distributions and makes the list of
profile-holding directories configurable we must do our own thing.
This was requested by jdstrand as an alternative to storing our profiles
in /etc/apparmor.d/.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* many: add the snapd-generator
This patch removes the snap.mount (or var-lib-snapd-snap.mount) unit
and replaces it with a systemd generator that does creates such unit
dynamically at runtime, on early boot, when the system is running
without mount event sharing on the root filesystem.
This fixes a bug where if packaging ships the snap.mount unit and the
unit is stopped (even if it is not started) it would stop all the snap
mount units on the system, resulting in broken snaps.
Since the mount unit is no longer known to packaging it will not be
automatically stopped/started by generated maintainer scripts and thus
avoid the issue.
This will make the release manager happy as we have less unknowns to
deal with. We can polish this by removing that fragment post release.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
On LXD the root filesystem is not mounted with sharing of mount events
so we don't get propagation of mount and unmount events, as snaps get
added and removed, into persistent mount namespaces.
To work around this ship a snap.mount systemd unit that creates a
bind-mount at /snap and makes it shared. The unit is only active inside
LXD which is a high-priority target.
We may want to expand on this to other containers supported in the same
way but this will be in another patch. One of the existing tests that
checked for the sharing is now removed as it artificially broke what we
were doing, instead a new test, explicitly using LXD is added, that
doesn't do any magic manipulation and should be representative of
real-world use.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
