[Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around
Andreas Hasenack
1895302 at bugs.launchpad.net
Wed Sep 16 20:15:24 UTC 2020
** 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 low (see [other info] item (a)).
+ 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 strictly 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-
+ 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).
- For stable releases, the impact is lessened because debootstrap will
- grab the release pocket for its job, and base-files from that pocket, in
- all ubuntu releases other than groovy, does not have the code that
- creates /etc/default/motd-news.wasremoved.
-
- There are two ways this can affect a stable release of ubuntu:
+ 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. In this case, it would be the same case as groovy was until this fix: subsequent installations of ubuntu-server or motd-news-config would default to having motd-news disabled
+ 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, 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
+ 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)
+
[Test Case]
* detailed instructions how to reproduce the bug
* 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.
[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
Foundations Bugs, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1895302
Title:
groovy debootstrap leaves /e/d/motd-news.wasremoved around
Status in base-files package in Ubuntu:
In Progress
Status in base-files source package in Focal:
In Progress
Bug description:
[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)
[Test Case]
* detailed instructions how to reproduce the bug
* 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.
[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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+subscriptions
More information about the foundations-bugs
mailing list