<div dir="ltr"><div>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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 6 Jan 2022 at 22:25, John Chittum <<a href="mailto:john.chittum@canonical.com">john.chittum@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:verdana,sans-serif">Going to backtrack slightly to answer Matthew's question:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why is Jammy Server semantically different from Cloud images or<br>
Container images?</blockquote><div><br></div><div>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. <br></div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:verdana,sans-serif"><div>From Steve:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First, I think unattended-upgrades should be directly seeded everywhere; its<br>
inclusion in the images should not be a side-effect of including<br>
software-properties.</blockquote><div><br></div><div>On one hand, I generally agree with this statement. </div></div></div></div></div></blockquote><div><br></div><div>Me too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:verdana,sans-serif"><div><div>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)<br><br>docker run -it --rm ubuntu /bin/bash<br>root@671453626e88:/# dpkg -l | grep unattended</div></div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:verdana,sans-serif"><div><div>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:</div><div><br></div><div><a href="https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n893" target="_blank">https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n893</a></div><div><br></div><div>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. <br></div><div><br></div><div>From Dan:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail_default" style="font-family:verdana,sans-serif"></span> And that isn't necessarily a bad choice - large deployments<br>
really *do not* want software changing outside of predefined<br>
maintenance windows, where actual admins are online to handle any kind<br>
of issues caused by the upgrades. That's obviously not the only case<br>
where unattended upgrades are not desirable, but a very frequent and<br>
large example.</div></blockquote><div><br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>mwh</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:verdana,sans-serif"><div><div></div></div></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><font face="verdana,sans-serif">-----------------------<br></font></div><div><font face="verdana,sans-serif">Dr. John Chittum</font></div><div><font face="verdana,sans-serif">Engineering Manager, Canonical, CPC team<br></font></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 4, 2022 at 5:15 PM Dan Streetman <<a href="mailto:ddstreet@canonical.com" target="_blank">ddstreet@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek<br>
<<a href="mailto:steve.langasek@ubuntu.com" target="_blank">steve.langasek@ubuntu.com</a>> wrote:<br>
><br>
> Matthew, Jay, thanks for pressing on this.<br>
><br>
> On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote:<br>
> > Steve Langasek <<a href="mailto:steve.langasek@ubuntu.com" target="_blank">steve.langasek@ubuntu.com</a>> wrote:<br>
><br>
> > >Hi Matthew,<br>
><br>
> > >On Tue, Dec 14, 2021 at 03:28:32PM +1300, Matthew Ruffell wrote:<br>
><br>
> > >It's not necessary to remove the unattended-upgrades package in order to<br>
> > >achieve this.  unattended-upgrades is configurable, and it's sufficient to<br>
> > >set 'APT::Periodic::Unattended-Upgrade "0";' in<br>
> > >/etc/apt/apt.conf.d/20auto-upgrades (or, in a separate file that sorts<br>
> > >lexically after, if that works better for the user's configuration<br>
> > >management system) to disable unattended-upgrades at runtime.<br>
><br>
> > >Therefore I do not think we should relax the dependency for this use case.<br>
><br>
> >       It is a change in the expectations and established practice for<br>
> > enterprise deployments who manage their own upgrades (i.e., currently<br>
> > they can simply remove unattended-upgrades and require no further action<br>
> > ever).<br>
><br>
> While this may be the case, I don't think the Ubuntu development team was<br>
> consulted before this became "established practice", either.  I certainly<br>
> would have given the same answer then as now: opting out of<br>
> unattended-upgrades should be done by configuring the software, not by<br>
> removing packages from the system.<br>
<br>
Hmm.<br>
<br>
I'm going to reply here by asking "What Would Linus Do" (I'm from the<br>
"south" in the USA so the phrase is borrowed from WWJD, though I'm not<br>
religious and not implying anything religious here...)<br>
<br>
I think there is a relevant youtube video that might answer that question here:<br>
<a href="https://youtu.be/qHGTs1NSB1s?t=42" rel="noreferrer" target="_blank">https://youtu.be/qHGTs1NSB1s?t=42</a><br>
<br>
I suspect you might already be aware of that clip ;-)<br>
<br>
In any case, I think we really should consider his statement; he wants<br>
the distribution to be "easy" so he can "get on with [his] life".<br>
<br>
Just like Linus, users of Ubuntu also want the distribution to "be<br>
easy" so they can "get on with their [business]". If the easiest and<br>
simplest way to avoid unexpected package upgrades is to uninstall<br>
unattended-upgrades, that's what they are going to do, and it doesn't<br>
particularly matter if we would prefer that they manually figure out<br>
how to configure U-A to not actually run instead of uninstalling it.<br>
<br>
Stated more simply, do you think Linus would want to take the time to<br>
understand how to configure U-A not to run instead of simply<br>
uninstalling it?<br>
<br>
We might want all our users to take the time to understand the nuances<br>
of our "required" software, but they won't. Not all of them. We should<br>
consider the impact on them in this situation.<br>
<br>
Also note I'm not making any kind of statement about U-A itself; there<br>
is obvious and significant benefit to having security (and other)<br>
updates automatically installed; I'm only talking about Ubuntu users<br>
who have made the choice to opt-out of what U-A provides, for whatever<br>
reason.<span class="gmail_default" style="font-family:verdana,sans-serif"></span> And that isn't necessarily a bad choice - large deployments<br>
really *do not* want software changing outside of predefined<br>
maintenance windows, where actual admins are online to handle any kind<br>
of issues caused by the upgrades. That's obviously not the only case<br>
where unattended upgrades are not desirable, but a very frequent and<br>
large example.<br>
<br>
><br>
> >       Is there a benefit to having u-u dependent on the server-minimal<br>
> > metapackage?<br>
><br>
> In general, I would say the benefit is reduced overall proliferation of<br>
> variations of installs wrt what software is or isn't installed.<br>
><br>
> >       Is there a risk that package upgrades to u-u could reenable it?<br>
><br>
> There is always risk of bugs.  Not respecting user configuration on upgrade<br>
> is unambiguously a bug.  It is not a class of bug we are particularly likely<br>
> to see in well-maintained core packages in Ubuntu (nor do we have a history<br>
> of such bugs occurring).<br>
><br>
><br>
> On Wed, Dec 15, 2021 at 05:40:21PM +1300, Matthew Ruffell wrote:<br>
><br>
> > Our Enterprise users with larger deployments may not want to risk having the<br>
> > package installed, since a package upgrade might overwrite the configuration<br>
> > file or accidentally trigger the apt-daily-upgrade.timer, which could lead to<br>
> > unplanned upgrades and service restarts taking place.<br>
><br>
> They've chosen to use Ubuntu as their OS, and at the end of the day they<br>
> need to have SOME trust in their OS provider.  I see no reason to be more<br>
> concerned about this entirely hypothetical class of bug being introduced<br>
> than any other.<br>
><br>
> Also I would note that the apt-daily-upgrade timer is shipped in the apt<br>
> package, not in unattended-upgrades...<br>
><br>
> > There is also a distinct lack of consistency as well.<br>
><br>
> > For example, on Jammy Desktop:<br>
><br>
> > $ sudo apt remove unattended-upgrades<br>
> > Reading package lists... Done<br>
> > Building dependency tree... Done<br>
> > Reading state information... Done<br>
> > The following packages will be REMOVED:<br>
> >   unattended-upgrades<br>
> > 0 upgraded, 0 newly installed, 1 to remove and 18 not upgraded.<br>
> > After this operation, 446 kB disk space will be freed.<br>
><br>
> > On Jammy Cloud Images:<br>
><br>
> > $ sudo apt remove unattended-upgrades<br>
> > Reading package lists... Done<br>
> > Building dependency tree... Done<br>
> > Reading state information... Done<br>
> > The following packages will be REMOVED:<br>
> >   unattended-upgrades<br>
> > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.<br>
> > After this operation, 446 kB disk space will be freed.<br>
><br>
> > On Jammy LXD Container Images:<br>
><br>
> > sudo apt remove unattended-upgrades<br>
> > Reading package lists... Done<br>
> > Building dependency tree... Done<br>
> > Reading state information... Done<br>
> > The following packages will be REMOVED:<br>
> >   unattended-upgrades<br>
> > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.<br>
> > After this operation, 446 kB disk space will be freed.<br>
><br>
> > But on Jammy Server, we have ubuntu-server-minimal installed, and thus:<br>
><br>
> > $ sudo apt remove unattended-upgrades<br>
> > Reading package lists... Done<br>
> > Building dependency tree... Done<br>
> > Reading state information... Done<br>
> > The following packages will be REMOVED:<br>
> >   ubuntu-server-minimal unattended-upgrades<br>
> > 0 upgraded, 0 newly installed, 2 to remove and 4 not upgraded.<br>
> > After this operation, 500 kB disk space will be freed.<br>
><br>
> > Why is Jammy Server semantically different from Cloud images or<br>
> > Container images?<br>
><br>
> Thanks for pointing this out.  The inconsistency here is definitely<br>
> unintentional.  It appears that unattended-upgrades is not directly seeded<br>
> on any of the other images, and is only pulled in as a Recommends: of<br>
> python3-software-properties.<br>
><br>
> First, I think unattended-upgrades should be directly seeded everywhere; its<br>
> inclusion in the images should not be a side-effect of including<br>
> software-properties.<br>
><br>
> Second, we should take a decision when seeding it on whether it should be a<br>
> Depends or Recommends of the metapackages and be consistent across the<br>
> various images.  Per above I am still in favor of it being a Depends, not a<br>
> Recommends.<br>
><br>
> Third, longer-term we know that we should fix things so that it's possible<br>
> for the ubuntu-server metapackage to be installed on cloud-images; this is<br>
> also a bug today.<br>
><br>
> --<br>
> Steve Langasek                   Give me a lever long enough and a Free OS<br>
> Debian Developer                   to set it on, and I can move the world.<br>
> Ubuntu Developer                                   <a href="https://www.debian.org/" rel="noreferrer" target="_blank">https://www.debian.org/</a><br>
> <a href="mailto:slangasek@ubuntu.com" target="_blank">slangasek@ubuntu.com</a>                                     <a href="mailto:vorlon@debian.org" target="_blank">vorlon@debian.org</a><br>
> --<br>
> ubuntu-devel mailing list<br>
> <a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank">ubuntu-devel@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
<br>
-- <br>
ubuntu-devel mailing list<br>
<a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank">ubuntu-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
</blockquote></div></div>
-- <br>
ubuntu-devel mailing list<br>
<a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank">ubuntu-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
</blockquote></div></div>