Last commit made on 2019-02-18
Get this branch:
git clone -b release/2.37

Branch merges

Branch information


Recent commits

d755140... by "John R. Lenton" <email address hidden> 5 hours ago

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.

29c3c89... by Paweł Stołowski on 2019-02-15

Updated rule per Jamie's suggestion.

8065e7e... by Paweł Stołowski on 2019-02-15

Allow sending and receiving signals from ourselves.

a3b8555... by Michael Vogt on 2019-02-14

tests: add upgrade test from 2.15.2ubuntu1 -> current

5119092... by Michael Vogt on 2019-02-14

snap-confine: fix fallback to ubuntu-core

54c67f2... by Michael Vogt on 2019-02-14

packaging: avoid race in snapd.postinst

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 "" this
race caused real world upgrades to stop snaps.

ab47c63... by Zygmunt Krynicki on 2019-02-14

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.

Thanks to Samuele for pointing this out!

Signed-off-by: Zygmunt Krynicki <email address hidden>

9f1f6a3... by Zygmunt Krynicki on 2019-02-14

cmd/snap-confine: allow writes to /var/lib/**

This patch restores permissions that snap-confine lost during the
2.36->2.37 transition. This allows a specific, otherwise unsupported,
use case to remain operational.

When an LXD container running something like Jenkins, which keeps data
in /var/lib/<foo>, wishes to use classic snaps and redirect the output
from said classic snap to a log in /var/lob/<foo>, this use case would
work in 2.36 because of additional permissions necessary for the
so-called "quirk" system that used to be present then. The 2.37 release
dropped that, along the extra permissions.

This issue resurfaced during the 2.37.1, 2.37.2 and hopefully the
upcoming 2.37.3 will fix it once and for all. The added regression test
should ensure that things keep working in case we refactor this at some
time in the future.

The fix is unfortunate but in absence of more advanced apparmor features
(e.g. delegation) we have no other choice.

Signed-off-by: Zygmunt Krynicki <email address hidden>

4dcda6a... by Michael Vogt on 2019-02-14

tests: stop catalog-update/apt-hooks test for now

The store is unhappy currently and won't answer to requests for
names. So this test always fails. Once the store is happy again
we can re-enable this test.

d488e89... by Michael Vogt on 2019-02-08

debian: ensure leftover usr.lib.snapd.snap-confine is gone

In commit 0dce4704a5d (2017-03-28, snapd v2.23.6) we renamed
/etc/apparmor.d/usr.lib.snap-confine to usr.lib.snap-confine.real
to fix LP: #1673247 - however some people (upgrades?) still have
the old usr.lib.snap-confine file. This seems to be loaded instead
of the correct usr.lib.snap-confine.real profile. To fix this we
use the rather blunt approach to remove the file forcefully if
it is unchanged.