Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal

John Chittum john.chittum at canonical.com
Wed Jan 5 15:40:32 UTC 2022


Going to backtrack slightly to answer Matthew's question:

Why is Jammy Server semantically different from Cloud images or
> Container images?


The Cloud Image and the LXD Container image are the same. Both are
generated by the `ubuntu-cpc` project, and thus take the same initial paths
in `livecd-rootfs` for choosing seed and base install packages. Neither
install `ubuntu-server-minimal` at this time.

There were decisions made (predating me on CPC) that the cloud image (and
lxd rootfs) would be separate entities from the Server product. I'm not
going to weigh in on correctness, but they are separate products at this
point.

>From Steve:

First, I think unattended-upgrades should be directly seeded everywhere; its
> inclusion in the images should not be a side-effect of including
> software-properties.


On one hand, I generally agree with this statement. It seems odd that it is
not directly seeded in the cloud images. the LXD container, I'm a little
less worried about, and I'd almost argue the opposite -- that in a
container image `unattended-upgrades` should not be installed by default.
Or, if it is, the default settings are to not be running. That fits more to
the current world stance on containers (you don't upgrade them, you replace
them). For instance, the Docker container does not have it installed. From
the Impish container (which i have handy)

docker run -it --rm ubuntu /bin/bash
root at 671453626e88:/# dpkg -l | grep unattended

This gets into some of the limitations put in place by livecd-rootfs when
creating images. There is a mapping of $PROJECT to $SEED done in
livecd-rootfs/live-build/auto/config. And cloud-images, while having their
own seed, appear to be using ubuntu.$SUITE/server, and then additional
meta-packages and seed files. the relevant code is here:

https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n893

The gist is anything built by the ubuntu-cpc starts from the server seed,
then runs the seed task minimal, standard, and cloud-image, then installs
the meta-package ubuntu-minimal. It's certainly different than the server
path, and should be different considering the use cases.

>From Dan:

And that isn't necessarily a bad choice - large deployments
> really *do not* want software changing outside of predefined
> maintenance windows, where actual admins are online to handle any kind
> of issues caused by the upgrades. That's obviously not the only case
> where unattended upgrades are not desirable, but a very frequent and
> large example.
>

I very much agree with the ease of removal and the large scale deployments.
Previous life, I was one of those people, doing exactly quarterly updates,
and our initial Ubuntu image deployed by our IT department did not have
unattended-upgrades installed. I'm also thinking about things in a cloud
context, where the approach has been that servers are not "pets." I'd say
that statement is not a universal truth, but is a good starting point for
considering the importance of unattended-upgrades in a cloud context.
-----------------------
Dr. John Chittum
Engineering Manager, Canonical, CPC team


On Tue, Jan 4, 2022 at 5:15 PM Dan Streetman <ddstreet at canonical.com> wrote:

> On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek
> <steve.langasek at ubuntu.com> wrote:
> >
> > Matthew, Jay, thanks for pressing on this.
> >
> > On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote:
> > > Steve Langasek <steve.langasek at ubuntu.com> wrote:
> >
> > > >Hi Matthew,
> >
> > > >On Tue, Dec 14, 2021 at 03:28:32PM +1300, Matthew Ruffell wrote:
> >
> > > >It's not necessary to remove the unattended-upgrades package in order
> to
> > > >achieve this.  unattended-upgrades is configurable, and it's
> sufficient to
> > > >set 'APT::Periodic::Unattended-Upgrade "0";' in
> > > >/etc/apt/apt.conf.d/20auto-upgrades (or, in a separate file that sorts
> > > >lexically after, if that works better for the user's configuration
> > > >management system) to disable unattended-upgrades at runtime.
> >
> > > >Therefore I do not think we should relax the dependency for this use
> case.
> >
> > >       It is a change in the expectations and established practice for
> > > enterprise deployments who manage their own upgrades (i.e., currently
> > > they can simply remove unattended-upgrades and require no further
> action
> > > ever).
> >
> > While this may be the case, I don't think the Ubuntu development team was
> > consulted before this became "established practice", either.  I certainly
> > would have given the same answer then as now: opting out of
> > unattended-upgrades should be done by configuring the software, not by
> > removing packages from the system.
>
> Hmm.
>
> I'm going to reply here by asking "What Would Linus Do" (I'm from the
> "south" in the USA so the phrase is borrowed from WWJD, though I'm not
> religious and not implying anything religious here...)
>
> I think there is a relevant youtube video that might answer that question
> here:
> https://youtu.be/qHGTs1NSB1s?t=42
>
> I suspect you might already be aware of that clip ;-)
>
> In any case, I think we really should consider his statement; he wants
> the distribution to be "easy" so he can "get on with [his] life".
>
> Just like Linus, users of Ubuntu also want the distribution to "be
> easy" so they can "get on with their [business]". If the easiest and
> simplest way to avoid unexpected package upgrades is to uninstall
> unattended-upgrades, that's what they are going to do, and it doesn't
> particularly matter if we would prefer that they manually figure out
> how to configure U-A to not actually run instead of uninstalling it.
>
> Stated more simply, do you think Linus would want to take the time to
> understand how to configure U-A not to run instead of simply
> uninstalling it?
>
> We might want all our users to take the time to understand the nuances
> of our "required" software, but they won't. Not all of them. We should
> consider the impact on them in this situation.
>
> Also note I'm not making any kind of statement about U-A itself; there
> is obvious and significant benefit to having security (and other)
> updates automatically installed; I'm only talking about Ubuntu users
> who have made the choice to opt-out of what U-A provides, for whatever
> reason. And that isn't necessarily a bad choice - large deployments
> really *do not* want software changing outside of predefined
> maintenance windows, where actual admins are online to handle any kind
> of issues caused by the upgrades. That's obviously not the only case
> where unattended upgrades are not desirable, but a very frequent and
> large example.
>
> >
> > >       Is there a benefit to having u-u dependent on the server-minimal
> > > metapackage?
> >
> > In general, I would say the benefit is reduced overall proliferation of
> > variations of installs wrt what software is or isn't installed.
> >
> > >       Is there a risk that package upgrades to u-u could reenable it?
> >
> > There is always risk of bugs.  Not respecting user configuration on
> upgrade
> > is unambiguously a bug.  It is not a class of bug we are particularly
> likely
> > to see in well-maintained core packages in Ubuntu (nor do we have a
> history
> > of such bugs occurring).
> >
> >
> > On Wed, Dec 15, 2021 at 05:40:21PM +1300, Matthew Ruffell wrote:
> >
> > > Our Enterprise users with larger deployments may not want to risk
> having the
> > > package installed, since a package upgrade might overwrite the
> configuration
> > > file or accidentally trigger the apt-daily-upgrade.timer, which could
> lead to
> > > unplanned upgrades and service restarts taking place.
> >
> > They've chosen to use Ubuntu as their OS, and at the end of the day they
> > need to have SOME trust in their OS provider.  I see no reason to be more
> > concerned about this entirely hypothetical class of bug being introduced
> > than any other.
> >
> > Also I would note that the apt-daily-upgrade timer is shipped in the apt
> > package, not in unattended-upgrades...
> >
> > > There is also a distinct lack of consistency as well.
> >
> > > For example, on Jammy Desktop:
> >
> > > $ sudo apt remove unattended-upgrades
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > Reading state information... Done
> > > The following packages will be REMOVED:
> > >   unattended-upgrades
> > > 0 upgraded, 0 newly installed, 1 to remove and 18 not upgraded.
> > > After this operation, 446 kB disk space will be freed.
> >
> > > On Jammy Cloud Images:
> >
> > > $ sudo apt remove unattended-upgrades
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > Reading state information... Done
> > > The following packages will be REMOVED:
> > >   unattended-upgrades
> > > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> > > After this operation, 446 kB disk space will be freed.
> >
> > > On Jammy LXD Container Images:
> >
> > > sudo apt remove unattended-upgrades
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > Reading state information... Done
> > > The following packages will be REMOVED:
> > >   unattended-upgrades
> > > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> > > After this operation, 446 kB disk space will be freed.
> >
> > > But on Jammy Server, we have ubuntu-server-minimal installed, and thus:
> >
> > > $ sudo apt remove unattended-upgrades
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > Reading state information... Done
> > > The following packages will be REMOVED:
> > >   ubuntu-server-minimal unattended-upgrades
> > > 0 upgraded, 0 newly installed, 2 to remove and 4 not upgraded.
> > > After this operation, 500 kB disk space will be freed.
> >
> > > Why is Jammy Server semantically different from Cloud images or
> > > Container images?
> >
> > Thanks for pointing this out.  The inconsistency here is definitely
> > unintentional.  It appears that unattended-upgrades is not directly
> seeded
> > on any of the other images, and is only pulled in as a Recommends: of
> > python3-software-properties.
> >
> > First, I think unattended-upgrades should be directly seeded everywhere;
> its
> > inclusion in the images should not be a side-effect of including
> > software-properties.
> >
> > Second, we should take a decision when seeding it on whether it should
> be a
> > Depends or Recommends of the metapackages and be consistent across the
> > various images.  Per above I am still in favor of it being a Depends,
> not a
> > Recommends.
> >
> > Third, longer-term we know that we should fix things so that it's
> possible
> > for the ubuntu-server metapackage to be installed on cloud-images; this
> is
> > also a bug today.
> >
> > --
> > Steve Langasek                   Give me a lever long enough and a Free
> OS
> > Debian Developer                   to set it on, and I can move the
> world.
> > Ubuntu Developer
> https://www.debian.org/
> > slangasek at ubuntu.com
> vorlon at debian.org
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220105/d86847ef/attachment-0001.html>


More information about the ubuntu-devel mailing list