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

Michael Hudson-Doyle michael.hudson at canonical.com
Tue Jan 11 23:12:21 UTC 2022


So I think we should probably change the server-minimal seed to only
recommend, not depend, on unattended-upgrades. Changing to a hard
dependency was not intended when I wrote that seed and a change like this
should probably be a conscious thing.

On Thu, 6 Jan 2022 at 22:25, John Chittum <john.chittum at canonical.com>
wrote:

> 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.
>

It would be super great to consolidate the vaguely-but-not-quite
overlapping "external product"/"livecd-rootfs project"/"seed definitions"
stuff but there are subtleties all over :/ Something for a sprint, a marker
pen and a very large sheet of paper.

>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.
>

Me too.


> 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
>

Docker images should definitely not have it installed, seeing is there is
no generic mechanism for having it _do_ anything in docker containers. lxd
containers are a bit different.


> 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.
>

The larger scale the deployment, the more expertise we can assume on the
part of the deployer though. I think the defaults have to be targeted at
the "mail server in the closet of a small business" use case.

Cheers,
mwh


> -----------------------
> 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
>>
> --
> 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/20220112/79a3b01f/attachment-0001.html>


More information about the ubuntu-devel mailing list