** Description changed: [Impact] A fresh install of base-files, like done when using debootstrap, using the base-files from the -updates repository (in the case of ubuntu stable releases), will leave an empty /etc/default/motd-news.wasremoved file. This file is an artifact of the mechanism used to handle a corner case in the previous SRU where it would signal the motd-news-config package to install /etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the previous base-files SRU at https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. In test case (i) it was acked that the empty .wasremoved file was lying around, but its impact was deemed not relevant (see [other info] item (a)). Another case where /etc/default/motd-news.wasremoved would be created when it shouldn't be is when you have just base-files installed (and no ubuntu-server or motd-news-config) and did a reinstall of base-files, or an upgrade. It would again touch /etc/default/motd-news.wasremoved. The consequence of having /etc/default/motd-news.wasremoved when it's unintended is that a follow-up install of ubuntu-server, or motd-news- config for that matter, will install /etc/default/motd-news with ENABLED=0 instead of ENABLED=1. This was the case of the groovy debootstrap which resulted in this bug being filed. While debootstrap won't mix multiple repositories (like release with updates), and thus this isn't easily a problem in released versions of ubuntu, the groovy case was the one that was doing a fresh install of base-files with the buggy touch /etc/default/motd- news.wasremoved, and a subsequent install of ubuntu-server left motd- news disabled in groovy images produced by such a method (debootstrap). These are the scenarios I was able to come up with in which a stable release could be affected by this bug: a) debootstrap with release and updates pocket enabled There are no config options that I'm aware of that would tell debootstrap to use multiple pockets when creating a chroot, but let's say it was done by hacking the script or something else. It would then be the same case as groovy until this fix: subsequent installations of ubuntu-server or motd-news-config would default to having motd-news disabled b) A system that has just base-files from the previous SRU installed, and no ubuntu-server and no motd-news-config. If base-files were updated again and without the fix presented here (let's say, another SRU instead of this one), it would create /etc/default/motd-news.wasremoved, and again, a subsequent install of ubuntu-server or motd-news-config would install motd-news in a disabled state c) Any other case where the postinst script of base-files is run again without the fix presented here, and when there is no /etc/default/motd- news{,.dpkg*} file present. To avoid creating /etc/default/motd-news.wasremoved when we shouldn't, the maintainer scripts were changed as follows: - motd-news-config postinst: always remove the .wasremoved file in configure if found, regardless if /etc/default/motd-news was sed'ed or not, or if we are upgrading or on a first install - base-files postinst: guard the creation of .wasremoved with: - - Only during an upgrade - - Only if ubuntu-server is installed (via a dpkg -l check) - + - Only during an upgrade + - Only if ubuntu-server is installed (via a dpkg -l check) [Test Case] + * On the system under test, remove motd-news-config and ubuntu-server if they are installed, and keep base-files from the update pocket. Something like this: + sudo apt update + sudo apt purge motd-news-config ubuntu-server + apt-cache policy base-files <-- to verify it's from updates - * detailed instructions how to reproduce the bug + * In this scenario, you should have no /etc/default/motd* files: + $ ll /etc/default/motd* + ls: cannot access '/etc/default/motd*': No such file or directory - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package fixes - the problem. + * reinstall base-files: + sudo apt install --reinstall base-files + + * Before this SRU, this would create /etc/default/motd-news.wasremoved: + $ ll /etc/default/motd* + -rw-r--r-- 1 root root 0 Sep 16 20:24 /etc/default/motd-news.wasremoved + + With the package from proposed for this SRU installed, no such file is created: + $ ll /etc/default/motd* + ls: cannot access '/etc/default/motd*': No such file or directory + [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] When debootstrapping groovy, we see an empty /etc/default/motd- news.wasremoved file. - groovy: base-files 11ubuntu12 -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved If motd-news-config is later installed, maybe via ubuntu-server, then the presence of this file will disable motd-news by default, which is unintended as it's meant to be enabled on a server.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895302 Title: groovy debootstrap leaves /e/d/motd-news.wasremoved around To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
