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.chit...@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@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 <ddstr...@canonical.com> > wrote: > >> On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek >> <steve.langa...@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.langa...@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/ >> > slanga...@ubuntu.com >> vor...@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 >> > -- > 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
