| 2020-09-11 13:52:25 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2020-09-11 18:20:13 |
Andreas Hasenack |
base-files (Ubuntu): importance |
Undecided |
High |
|
| 2020-09-11 18:20:15 |
Andreas Hasenack |
base-files (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-09-11 18:20:19 |
Andreas Hasenack |
base-files (Ubuntu): status |
New |
In Progress |
|
| 2020-09-16 13:23:40 |
Andreas Hasenack |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/390766 |
|
| 2020-09-16 19:22:06 |
Andreas Hasenack |
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. |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[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. |
|
| 2020-09-16 19:22:15 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Focal |
|
| 2020-09-16 19:22:15 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Focal) |
|
| 2020-09-16 19:22:24 |
Andreas Hasenack |
base-files (Ubuntu Focal): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-09-16 19:22:30 |
Andreas Hasenack |
base-files (Ubuntu Focal): status |
New |
In Progress |
|
| 2020-09-16 19:46:28 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[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. |
[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)).
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-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.
This would affect a stable release anytime the postinst script from base-files from the previous SRU is run and there are no /etc/default/motd-news{,.dpkg*} files present. This could be a system which just doesn't have ubuntu-server or motd-news-config installed, in which case creating the .wasremoved file is wrong. Or a system which has those packages installed, and the user erroneously, in an attempt to disable motd-news, removed /etc/default/motd-news, in which case it's correct to create /etc/default/motd-news.wasremoved.
If debootstrap is somehow coached into using the release and updates pocket, then the stable release it's bootstrapping would suffer from this bug in the same way that groovy did: base-files would be installed without ubuntu-server or motd-news-config, and an empty /etc/default/motd-news.wasremoved file would be creating, disabling motd-news in any future installation of motd-news-config or ubuntu-server.
[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. |
|
| 2020-09-16 19:57:31 |
Andreas Hasenack |
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 low (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-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.
This would affect a stable release anytime the postinst script from base-files from the previous SRU is run and there are no /etc/default/motd-news{,.dpkg*} files present. This could be a system which just doesn't have ubuntu-server or motd-news-config installed, in which case creating the .wasremoved file is wrong. Or a system which has those packages installed, and the user erroneously, in an attempt to disable motd-news, removed /etc/default/motd-news, in which case it's correct to create /etc/default/motd-news.wasremoved.
If debootstrap is somehow coached into using the release and updates pocket, then the stable release it's bootstrapping would suffer from this bug in the same way that groovy did: base-files would be installed without ubuntu-server or motd-news-config, and an empty /etc/default/motd-news.wasremoved file would be creating, disabling motd-news in any future installation of motd-news-config or ubuntu-server.
[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. |
[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)).
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-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:
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
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
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.
[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. |
|
| 2020-09-16 20:15:24 |
Andreas Hasenack |
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 low (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-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:
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
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
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.
[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. |
[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. |
|
| 2020-09-16 20:26:22 |
Andreas Hasenack |
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. |
[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]
* 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
* 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
* 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. |
|
| 2020-09-16 20:33:25 |
Andreas Hasenack |
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]
* 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
* 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
* 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. |
[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]
* 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
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[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. |
|
| 2020-09-16 20:36:53 |
Andreas Hasenack |
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]
* 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
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[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. |
[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]
* 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
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[Other Info]
The previous SRU at https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 and its attached merge proposals has more detailed info about the history of this motd-news split, and things that were considered.
Manually, I used debootstrap with --make-tarball, replace the base-files deb, and --unpack-tarball, to simulate debootstrap with an updated base-files, to confirm this change here would fix the debootstrap problem, and it worked. But I deemed it too complicated to describe as a testcase for this SRU. If you, dear SRU reviewer, would prefer this test to be added, please let me know.
[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. |
|
| 2020-09-16 20:37:07 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2020-09-16 20:37:07 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Xenial) |
|
| 2020-09-16 20:37:07 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-09-16 20:37:07 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Bionic) |
|
| 2020-09-16 20:37:16 |
Andreas Hasenack |
base-files (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-09-16 20:37:19 |
Andreas Hasenack |
base-files (Ubuntu Bionic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-09-16 20:37:23 |
Andreas Hasenack |
base-files (Ubuntu Xenial): status |
New |
In Progress |
|
| 2020-09-16 20:37:26 |
Andreas Hasenack |
base-files (Ubuntu Bionic): status |
New |
In Progress |
|
| 2020-09-16 20:55:16 |
Andreas Hasenack |
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]
* 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
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[Other Info]
The previous SRU at https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 and its attached merge proposals has more detailed info about the history of this motd-news split, and things that were considered.
Manually, I used debootstrap with --make-tarball, replace the base-files deb, and --unpack-tarball, to simulate debootstrap with an updated base-files, to confirm this change here would fix the debootstrap problem, and it worked. But I deemed it too complicated to describe as a testcase for this SRU. If you, dear SRU reviewer, would prefer this test to be added, please let me know.
[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. |
[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]
* 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 dist-upgrade -y
sudo apt purge motd-news-config ubuntu-server
apt-cache policy base-files <-- to verify it's from updates
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[Other Info]
The previous SRU at https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 and its attached merge proposals has more detailed info about the history of this motd-news split, and things that were considered.
Manually, I used debootstrap with --make-tarball, replace the base-files deb, and --unpack-tarball, to simulate debootstrap with an updated base-files, to confirm this change here would fix the debootstrap problem, and it worked. But I deemed it too complicated to describe as a testcase for this SRU. If you, dear SRU reviewer, would prefer this test to be added, please let me know.
[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. |
|
| 2020-09-16 21:01:00 |
Andreas Hasenack |
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]
* 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 dist-upgrade -y
sudo apt purge motd-news-config ubuntu-server
apt-cache policy base-files <-- to verify it's from updates
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[Other Info]
The previous SRU at https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 and its attached merge proposals has more detailed info about the history of this motd-news split, and things that were considered.
Manually, I used debootstrap with --make-tarball, replace the base-files deb, and --unpack-tarball, to simulate debootstrap with an updated base-files, to confirm this change here would fix the debootstrap problem, and it worked. But I deemed it too complicated to describe as a testcase for this SRU. If you, dear SRU reviewer, would prefer this test to be added, please let me know.
[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. |
[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]
* 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 dist-upgrade -y
sudo apt purge motd-news-config ubuntu-server
apt-cache policy base-files <-- to verify it's from updates
* 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
* 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]
This SRU is further changing maintainer scripts, to address an issue in the previous maintainer script. Should there be new regressions or new issues, it might get harder and harder to fix them.
I did wonder about the `dpkg -l` call in base-files' postinst. I worried about locks, or pre-dependencies, but dpkg was already being used in this script, although not with -l (list), just a version comparison. But at least it's already installed.
My other worry was with the dpkg -l output and which flags I should check to determine if ubuntu-server was installed. "^ii" doesn't work, because ubuntu-server might be being upgraded in the same apt transaction, but ^i seemed good enough. Furthermore, I changed the check for a package name that doesn't exist, to see if dpkg -l would complain and fail the whole script (which runs with set -e), but it was ok and just behaved as if the package wasn't installed, which is what we need.
[Other Info]
The previous SRU at https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 and its attached merge proposals has more detailed info about the history of this motd-news split, and things that were considered.
Manually, I used debootstrap with --make-tarball, replace the base-files deb, and --unpack-tarball, to simulate debootstrap with an updated base-files, to confirm this change here would fix the debootstrap problem, and it worked. But I deemed it too complicated to describe as a testcase for this SRU. If you, dear SRU reviewer, would prefer this test to be added, please let me know.
If a user of a stable release already has an unintended /etc/default/motd-news.wasremoved file created, this update will not fix that.
[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. |
|
| 2020-09-16 21:17:55 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/390863 |
|
| 2020-09-16 21:18:34 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/390864 |
|
| 2020-09-16 21:19:15 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/390865 |
|
| 2020-09-16 23:45:28 |
Launchpad Janitor |
base-files (Ubuntu): status |
In Progress |
Fix Released |
|
| 2020-09-23 20:49:27 |
Steve Langasek |
base-files (Ubuntu Focal): status |
In Progress |
Incomplete |
|
| 2020-09-23 20:49:34 |
Steve Langasek |
base-files (Ubuntu Xenial): status |
In Progress |
Incomplete |
|
| 2020-09-23 20:49:36 |
Steve Langasek |
base-files (Ubuntu Bionic): status |
In Progress |
Incomplete |
|
| 2020-09-23 21:03:13 |
Andreas Hasenack |
base-files (Ubuntu Xenial): status |
Incomplete |
In Progress |
|
| 2020-09-23 21:03:17 |
Andreas Hasenack |
base-files (Ubuntu Bionic): status |
Incomplete |
In Progress |
|
| 2020-09-23 21:03:19 |
Andreas Hasenack |
base-files (Ubuntu Focal): status |
Incomplete |
In Progress |
|
| 2021-07-16 12:36:46 |
Andreas Hasenack |
base-files (Ubuntu Xenial): status |
In Progress |
Confirmed |
|
| 2021-07-16 12:36:50 |
Andreas Hasenack |
base-files (Ubuntu Bionic): status |
In Progress |
Confirmed |
|
| 2021-07-16 12:36:52 |
Andreas Hasenack |
base-files (Ubuntu Focal): status |
In Progress |
Confirmed |
|
| 2021-07-16 12:36:57 |
Andreas Hasenack |
base-files (Ubuntu Xenial): assignee |
Andreas Hasenack (ahasenack) |
|
|
| 2021-07-16 12:37:01 |
Andreas Hasenack |
base-files (Ubuntu Bionic): assignee |
Andreas Hasenack (ahasenack) |
|
|
| 2021-07-16 12:37:03 |
Andreas Hasenack |
base-files (Ubuntu Focal): assignee |
Andreas Hasenack (ahasenack) |
|
|
