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@671453626e88:/# dpkg -l | grep unattended
docker run -it --rm ubuntu /bin/bash
root@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:
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@canonical.com> wrote:
On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek
<steve.langasek@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@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@ubuntu.com vorlon@debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
