On Tue, Jan 11, 2022 at 6:12 PM Michael Hudson-Doyle <michael.hud...@canonical.com> wrote: > > 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.
Please don't assume that. There are lots of people in Canonical with real direct experience with large scale customer deployments; you should ask them directly instead of making any assumptions. > 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
