Linked new merge proposals with a different approach to the problem -
checking for a marker file instead of passing an option in a conf script
- and updated the description to match the new approach.
** Description changed:
[ Impact ]
If ESM Infra/Apps is available for a system, users will always see
messages related to those Ubuntu Pro services in their MOTDs. As stated
in the original description, there have been complains on how hard it is
to disable those messages - we have users who don't want Pro and don't
want to be reminded of Pro all the time.
The fix here is making it easier for people to disable the ESM related
messages in the update-related MOTD, by giving them a way to opt-out.
- Users will have the option to add the --no-esm-messages flag to
- /etc/apt/apt.conf.d/99update-notifier, where the message generation
- script is executed as a hook.
+ Users will have the option to create the /var/lib/ubuntu-advantage/hide-
+ esm-in-motd marker file, causing the /usr/lib/update-notifier/update-
+ motd-updates-available script to include a --no-esm-messages flag when
+ generating the outputs.
+
+ This file is the same file used in the Pro Client to suppress those
+ messages.
[ Test Plan ]
Compare the messages before and after installing the new version of the
package, and make sure they are exactly the same in different scenarios:
- ESM status: unavailable, disabled, enabled
- LTS system: yes or no
- updates available: yes or no
Thankfully, the unit test suite in tests/test_motd.py covers all of
those scenarios functionality-wise. Manual checks on real systems may
endorse the functionality.
New tests were added to the suite making sure the flag hides the ESM
related messages when it is present.
- On real systems, adding --no-esm-messages to the conf script and making
- sure it updates the MOTDs should remove ESM related messages for the
- same scenarios above.
+ On real systems, creating the /var/lib/ubuntu-advantage/hide-esm-in-motd
+ marker file and making sure it updates the MOTDs should remove ESM
+ related messages for the same scenarios above.
- The contents of /etc/apt/apt.conf.d/99update-notifier should be similar
- to:
-
- DPkg::Post-Invoke {"if [ -d /var/lib/update-notifier ]; then touch
/var/lib/update-notifier/dpkg-run-stamp; fi;
/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true";};
- APT::Update::Post-Invoke-Success
{"/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true";};
-
- To perform the test, the new flag needs to be added to all calls to
- update-motd-updates-available. Using the above as an example, the result
- would be:
-
- DPkg::Post-Invoke {"if [ -d /var/lib/update-notifier ]; then touch
/var/lib/update-notifier/dpkg-run-stamp; fi;
/usr/lib/update-notifier/update-motd-updates-available --no-esm-messages
2>/dev/null || true";};
- APT::Update::Post-Invoke-Success
{"/usr/lib/update-notifier/update-motd-updates-available --no-esm-messages
2>/dev/null || true";};
-
- The execution of the script relies on running one of those trigger
- hooks. Running `apt update` will trigger the second hook in the example
- above. To make sure messages will be updated, remove the
- /var/lib/update-notifier/updates-available stamp file before. (The
- alternative would be running manually with --force, but that is slightly
- worse for acceptance testing)
+ The execution of the script relies on running one of a couple trigger
+ hooks set in the apt configuration. Running `apt update` will trigger
+ one of them. To make sure messages will be updated, the /var/lib/update-
+ notifier/updates-available stamp file can be removed before the update.
+ (The alternative would be running manually with --force, but that is
+ slightly worse for acceptance testing)
[ Where problems could occur ]
- Other software may be relying on the apt-check script to generate
human-readable messages. A mistake here could intefere with the message
generated, changing expectation on stable releases, or causing errors.
- To mitigate that, the new flag is set to False as default, and all
- existing functionality is preserved.
+ To mitigate that, the standard behavior is exactly the same if the
+ marker file is absent, and all existing functionality is preserved.
- - Users may make mistakes when writing the new flag in the
- /etc/apt/apt.conf.d/99update-notifier configuration file. We will
+ - Users may make mistakes when creating the marker file. We will
mitigate that by having comprehensible documentation with a clear
- explanation of what the flag does and where to put it.
+ explanation of what the flag does and where to put it. The worst that
+ can happen is that users create a useless file, and no change happens.
- - If the user makes the mistake even following the documented steps,
- then it is out of our control. The impact of breaking the configuration
- file is that There will be no MOTD related to updates at all (as errors
- are redirected to /dev/null), or the errors themselves will appear in
- the apt update screen, or in the MOTD, if the user messes up the
- redirection.
[ Other Info ]
As opposed to what was in the original description, the proposed
changeset does not separate esm messages from the regular updates
messages - this ensures current users and potential callers get exactly
the same result when checking their outputs after the change lands.
As suggested in the original description, we understand that it is not
- easy and straightforward to add a flag to a script when compared to
- running a command or clicking a button. However, the messages are there
- for a product decision, and it is a product decision not to have a "too
- easy opt-out". On the other hand, users who want to disable this are
- capable of editing the file, and it will be way easier for them than
- making the changes in the python script itself - plus the configuration
- is kept between upgrades.
-
- If the default configuration file shipped by update-notifier changes in
- the future, the user may see a debconf prompt when upgrading the package
- - that is expected, as the user has made changes to a config file for a
- reason and needs to decide on keeping those or not.
+ the easiest and straightforward approach create a specific file when
+ compared to running a command or clicking a button. However, the
+ messages are there for a product decision, and it is a product decision
+ not to have a "too easy opt-out". On the other hand, users who want to
+ disable this are capable of creating the file, and it will be way easier
+ for them than making the changes in the python script itself - plus the
+ configuration is kept between upgrades.
As noted in a subsequent comment, the patch fixing this bug introduces a
new help message. The translations of update-notifier are shipped
together with the package. Consulting with @enr0n, the decision about
this new entry is:
- For the Noble version, @enr0n will add this new line to the pot file, so it
can be translated for the future releases.
- For the SRUs, we will let it be as is. The main two reasons are:
1. there is low value in translating this string to the couple
languages we know, and new translations would require a new SRU in the
future - except in special cases, there are no translations done in SRUs
anyway
2. there is low exposure of the string - it is not in the consumable
output of the command, but rather help text for a command that is niched
enough - as also noted, we don't expect all users to be applying this.
[ Original Description ]
See https://github.com/canonical/ubuntu-pro-client/issues/2458 for the
origin of the conversation.
We don't think it needs to be _easy_, but it should probably be less
burdensome to disable ESM update notifications in MOTD without disabling
all update notifications in MOTD.
One idea to accomplish this is to separate the /etc/update-motd.d/ files
into two. One would print the normal update message, and the other would
print the ESM message. Then, if an admin knows what they're doing and is
willing to accept the risk, they can remove or edit the ESM update-
notifier motd conffile. This is similar to how you can remove the APT
ESM messages by removing/editing /etc/apt/apt.conf.d/20apt-esm-hook.conf
if you know what you're doing.
This would also require some changes to how the messages are created,
since currently it is all in apt_check.py and printed into a single
message file. They'll need to be separated somehow.
** Description changed:
[ Impact ]
If ESM Infra/Apps is available for a system, users will always see
messages related to those Ubuntu Pro services in their MOTDs. As stated
in the original description, there have been complains on how hard it is
to disable those messages - we have users who don't want Pro and don't
want to be reminded of Pro all the time.
The fix here is making it easier for people to disable the ESM related
messages in the update-related MOTD, by giving them a way to opt-out.
Users will have the option to create the /var/lib/ubuntu-advantage/hide-
esm-in-motd marker file, causing the /usr/lib/update-notifier/update-
motd-updates-available script to include a --no-esm-messages flag when
generating the outputs.
This file is the same file used in the Pro Client to suppress those
messages.
[ Test Plan ]
Compare the messages before and after installing the new version of the
package, and make sure they are exactly the same in different scenarios:
- ESM status: unavailable, disabled, enabled
- LTS system: yes or no
- updates available: yes or no
Thankfully, the unit test suite in tests/test_motd.py covers all of
those scenarios functionality-wise. Manual checks on real systems may
endorse the functionality.
New tests were added to the suite making sure the flag hides the ESM
related messages when it is present.
On real systems, creating the /var/lib/ubuntu-advantage/hide-esm-in-motd
- marker file and making sure it updates the MOTDs should remove ESM
+ marker file and making sure to update the MOTDs should remove ESM
related messages for the same scenarios above.
The execution of the script relies on running one of a couple trigger
hooks set in the apt configuration. Running `apt update` will trigger
one of them. To make sure messages will be updated, the /var/lib/update-
notifier/updates-available stamp file can be removed before the update.
(The alternative would be running manually with --force, but that is
slightly worse for acceptance testing)
[ Where problems could occur ]
- Other software may be relying on the apt-check script to generate
human-readable messages. A mistake here could intefere with the message
generated, changing expectation on stable releases, or causing errors.
To mitigate that, the standard behavior is exactly the same if the
marker file is absent, and all existing functionality is preserved.
- Users may make mistakes when creating the marker file. We will
mitigate that by having comprehensible documentation with a clear
explanation of what the flag does and where to put it. The worst that
can happen is that users create a useless file, and no change happens.
-
[ Other Info ]
As opposed to what was in the original description, the proposed
changeset does not separate esm messages from the regular updates
messages - this ensures current users and potential callers get exactly
the same result when checking their outputs after the change lands.
As suggested in the original description, we understand that it is not
the easiest and straightforward approach create a specific file when
compared to running a command or clicking a button. However, the
messages are there for a product decision, and it is a product decision
not to have a "too easy opt-out". On the other hand, users who want to
disable this are capable of creating the file, and it will be way easier
for them than making the changes in the python script itself - plus the
configuration is kept between upgrades.
As noted in a subsequent comment, the patch fixing this bug introduces a
new help message. The translations of update-notifier are shipped
together with the package. Consulting with @enr0n, the decision about
this new entry is:
- For the Noble version, @enr0n will add this new line to the pot file, so it
can be translated for the future releases.
- For the SRUs, we will let it be as is. The main two reasons are:
1. there is low value in translating this string to the couple
languages we know, and new translations would require a new SRU in the
future - except in special cases, there are no translations done in SRUs
anyway
2. there is low exposure of the string - it is not in the consumable
output of the command, but rather help text for a command that is niched
enough - as also noted, we don't expect all users to be applying this.
[ Original Description ]
See https://github.com/canonical/ubuntu-pro-client/issues/2458 for the
origin of the conversation.
We don't think it needs to be _easy_, but it should probably be less
burdensome to disable ESM update notifications in MOTD without disabling
all update notifications in MOTD.
One idea to accomplish this is to separate the /etc/update-motd.d/ files
into two. One would print the normal update message, and the other would
print the ESM message. Then, if an admin knows what they're doing and is
willing to accept the risk, they can remove or edit the ESM update-
notifier motd conffile. This is similar to how you can remove the APT
ESM messages by removing/editing /etc/apt/apt.conf.d/20apt-esm-hook.conf
if you know what you're doing.
This would also require some changes to how the messages are created,
since currently it is all in apt_check.py and printed into a single
message file. They'll need to be separated somehow.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2015420
Title:
motd: can't disable esm-related messages
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/2015420/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
