Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Since I don't have a clear point to reply to, I'll just delete the message history rather than top-post. I would simply like to interject that, all other things equal, a new LTS is a fantastic time to change behavior, because it also offers a bright, shining opportunity to document a change in behavior. This opportunity remains whether we're looking at a substantive change at 22.04 LTS or 22.10, but it's a lot easier to remember to document for the upcoming LTS when it is imminent. So, when deciding the best practice for 22.04 LTS, be bold. And now I leave the matter where it already was: in the hands of those best suited to decide. Regards, -- Nathan Haines Ubuntu - https://www.ubuntu.com/ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
LXD images called "Ubuntu Server" should behave as similarly as possible to bare metal images called "Ubuntu Server". Unless there is a documented technical reason for the delta, I suspect the difference is a consequence of org boundaries and should be revisited. There is definitely a need for an "Ubuntu Minimal" image which is not as finger-friendly as Ubuntu Server, by excluding as much as possible and preserving only enough to build up the system you want through APT dependencies. That Ubuntu Minimal offering should be available on clouds, and LXD, and bare metal, and as a Docker base image. We've tried that a few times, but lost the work through merges post-release each time. Now that we are growing our Foundations and Server teams and also building out a docker-focused team we should design and sustain the work needed to trim and focus package dependencies for that minimal experience. On the unattended-upgrades front, Matthew, another way for us to help user control this behaviour is through the UA tool, with something like: ua disable automatic-updates We have a number of developers working on UA, with the goal of making it a clean and consistent front-end to various aspects of system operations across different versions of Ubuntu, and this might be a use case worth considering.. Mark -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
On Wed, Jan 05, 2022 at 09:40:32AM -0600, John Chittum wrote: > 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) LXD containers are intended to be Ubuntu systems; they run init, they run services by default. unattended-upgrades should certainly be part of this by default (and in practice is today). docker containers are a different matter. > 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. Well, I don't agree that it "should" be different. It must be different, because the set of packages installed is not identical; but that's not a feature (certainly not for anyone who is trying to reason about the behavior of default installs of Ubuntu in different contexts). On Wed, Jan 12, 2022 at 12:12:21PM +1300, Michael Hudson-Doyle 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. I agree with this. And as I said, I think it's important that we directly recommend this everywhere rather that let it be an accidental side effect. Cheers, -- 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 signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
On Tue, Jan 11, 2022 at 6:12 PM Michael Hudson-Doyle 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 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 wrote: >>> >>> On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek >>> wrote: >>> > >>> > Matthew, Jay, thanks for pressing on this. >>> > >>> > On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote: >>> > > Steve Langasek wrote: >>> > >>> > > >Hi Matthew, >>> > >>> > > >On Tue, Dec 14, 2021 at 03:28:32PM
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
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 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 > wrote: > >> On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek >> wrote: >> > >> > Matthew, Jay, thanks for pressing on this. >> > >> > On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote: >> > > Steve Langasek 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 >> > >
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
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 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 wrote: > On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek > wrote: > > > > Matthew, Jay, thanks for pressing on this. > > > > On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote: > > > Steve Langasek 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
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek wrote: > > Matthew, Jay, thanks for pressing on this. > > On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote: > > Steve Langasek 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
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Hi Steve, On Wed, Dec 15, 2021 at 2:36 PM Jay Vosburgh 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). > > Is there a benefit to having u-u dependent on the server-minimal > metapackage? > > Is there a risk that package upgrades to u-u could reenable it? > 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. I fear that we will just end up with users making master images that just purge unattended-upgrades, and it will take ubuntu-server-minimal with it, causing issues down the line if they ever decide to do a in-place release upgrade. 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? We should absolutely include unattended-upgrades by default in all installations, but we should do so via a Recommends instead of Depends relationship on Ubuntu Server. Please reconsider your view for the server-minimal metapackage. Thanks, Matthew -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Steve Langasek wrote: >Hi Matthew, > >On Tue, Dec 14, 2021 at 03:28:32PM +1300, Matthew Ruffell wrote: > >> I was testing Jammy and happened to notice that unattended-upgrades >> Depends on ubuntu-server-minimal, and when removing unattended-upgrades, >> ubuntu-server-minimal is removed along with it: > >> $ sudo apt remove unattended-upgrades >> ... >> The following packages will be REMOVED: >> ubuntu-server-minimal unattended-upgrades >> 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. >> >> $ sudo apt rdepends unattended-upgrades >> unattended-upgrades >> Reverse Depends: >> Recommends: python3-software-properties >> Recommends: ubuntu-mate-desktop >> Recommends: ubuntu-mate-core >> Depends: freedombox >> Recommends: fbx-all >> Depends: ubuntu-server-minimal > >> Should unattended-upgrades be changed from Depends to Recommends for >> ubuntu-server-minimal? > >> It is very common for our larger users to remove unattended-upgrades so >> they can manage their systems patching manually. > >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). Is there a benefit to having u-u dependent on the server-minimal metapackage? Is there a risk that package upgrades to u-u could reenable it? -J >> I filed a bug against ubuntu-meta: >> >> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724 >> >> I was in the process of making a debdiff, and I happened to notice that >> unattended-upgrades is only in the server-minimal-$ARCH files only: >> >> $ grep -Rin "unattended-upgrades" . >> ./server-minimal-armhf:23:unattended-upgrades >> ./server-minimal-riscv64:23:unattended-upgrades >> ./server-minimal-arm64:23:unattended-upgrades >> ./server-minimal-ppc64el:23:unattended-upgrades >> ./server-minimal-s390x:24:unattended-upgrades >> ./server-minimal-amd64:23:unattended-upgrades >> >> When I also ran the ./update script in ubuntu-meta, it automatically >> repopulated >> server-minimal-$ARCH with unattended-upgrades again, so it seems I am missing >> something to do with dependency magic in the archive. > >The dependencies from ubuntu-meta are generated from the seeds: > > git+ssh://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu > >Cheers, >-- >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 --- -Jay Vosburgh, jay.vosbu...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Matthew, Jay, thanks for pressing on this. On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote: > Steve Langasek 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. > 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. --
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Hi Matthew, On Tue, Dec 14, 2021 at 03:28:32PM +1300, Matthew Ruffell wrote: > I was testing Jammy and happened to notice that unattended-upgrades > Depends on ubuntu-server-minimal, and when removing unattended-upgrades, > ubuntu-server-minimal is removed along with it: > $ sudo apt remove unattended-upgrades > ... > The following packages will be REMOVED: > ubuntu-server-minimal unattended-upgrades > 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. > > $ sudo apt rdepends unattended-upgrades > unattended-upgrades > Reverse Depends: > Recommends: python3-software-properties > Recommends: ubuntu-mate-desktop > Recommends: ubuntu-mate-core > Depends: freedombox > Recommends: fbx-all > Depends: ubuntu-server-minimal > Should unattended-upgrades be changed from Depends to Recommends for > ubuntu-server-minimal? > It is very common for our larger users to remove unattended-upgrades so > they can manage their systems patching manually. 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. > I filed a bug against ubuntu-meta: > > https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724 > > I was in the process of making a debdiff, and I happened to notice that > unattended-upgrades is only in the server-minimal-$ARCH files only: > > $ grep -Rin "unattended-upgrades" . > ./server-minimal-armhf:23:unattended-upgrades > ./server-minimal-riscv64:23:unattended-upgrades > ./server-minimal-arm64:23:unattended-upgrades > ./server-minimal-ppc64el:23:unattended-upgrades > ./server-minimal-s390x:24:unattended-upgrades > ./server-minimal-amd64:23:unattended-upgrades > > When I also ran the ./update script in ubuntu-meta, it automatically > repopulated > server-minimal-$ARCH with unattended-upgrades again, so it seems I am missing > something to do with dependency magic in the archive. The dependencies from ubuntu-meta are generated from the seeds: git+ssh://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu Cheers, -- 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 signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Hey Matthew! When you check what the ./update script does, it actually executes germinate-update-metapackage from germinate, which on the other hand uses the ubuntu and platform seeds to repopulate the metapackage contents. So to get it removed from ubuntu-server-minimal, you will first need to remove it from the server-minimal seed. All the Ubuntu-specific seeds are hosted on Launchpad in the following git repository: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu Cheers, On Tue, 14 Dec 2021 at 17:23, Matthew Ruffell wrote: > > Hi everyone. > > I was testing Jammy and happened to notice that unattended-upgrades Depends on > ubuntu-server-minimal, and when removing unattended-upgrades, > ubuntu-server-minimal is removed along with it: > > $ sudo apt remove unattended-upgrades > ... > The following packages will be REMOVED: > ubuntu-server-minimal unattended-upgrades > 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. > > $ sudo apt rdepends unattended-upgrades > unattended-upgrades > Reverse Depends: > Recommends: python3-software-properties > Recommends: ubuntu-mate-desktop > Recommends: ubuntu-mate-core > Depends: freedombox > Recommends: fbx-all > Depends: ubuntu-server-minimal > > Should unattended-upgrades be changed from Depends to Recommends for > ubuntu-server-minimal? > > It is very common for our larger users to remove unattended-upgrades so they > can > manage their systems patching manually. > > I filed a bug against ubuntu-meta: > > https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724 > > I was in the process of making a debdiff, and I happened to notice that > unattended-upgrades is only in the server-minimal-$ARCH files only: > > $ grep -Rin "unattended-upgrades" . > ./server-minimal-armhf:23:unattended-upgrades > ./server-minimal-riscv64:23:unattended-upgrades > ./server-minimal-arm64:23:unattended-upgrades > ./server-minimal-ppc64el:23:unattended-upgrades > ./server-minimal-s390x:24:unattended-upgrades > ./server-minimal-amd64:23:unattended-upgrades > > When I also ran the ./update script in ubuntu-meta, it automatically > repopulated > server-minimal-$ARCH with unattended-upgrades again, so it seems I am missing > something to do with dependency magic in the archive. > > Thanks, > Matthew > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
