While I appreciate the clarification for those who did not understand what pro is or what the messages in apt were originating from, I feel this clarification is only the first step. The next goal should be to remove the advertisement from apt completely. I agree with the commercial Pro subscription service and the effort Canonical is putting into keeping these packages updated on their dime. And I hope it’s a good source of incoming to pay for that service.
But advertising a commercial subscription as part of a critical update tool in maintaining infrastructure is not the right place to do it. Users and admins have an expectation of trust, reliability and output from doing updates. Showing updates to the end user that they can’t install because they are not willing or able to pay for a commercial subscription(regardless of who qualifies for a free subscription) breaks that trust and reliability in the apt update system. I’m sorry, but leaving it up to the user/admin to manually delete the advertisement across 3 or 3000 devices is not an adequate solution. Unfortunately, I do not have a better place to display these advertisements. At the very least, a delineation between pro updates and regular updates would be better than the current state. As an example, phased updates and other updates held back for different reasons are mixed in with the commercial subscription updates with no way to tell the apart and which ones are available to install without the commercial subscription. This would break automation and reporting.
I wasted my entire morning trying to unconfigure the ESM messages that are displayed at each login over and over again.
The messages that I want to stop from appearing are:
Expanded Security Maintenance for Applications is not enabled.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
I followed the hints, that I read in
The official documentation led me to:
How are the APT messages generated?
`apt-esm-hook` and `apt-esm-json-hook` in config file: `/etc/apt/apt.conf.d/20apt-esm-hook.conf`
We have two distinct apt hooks that allow us to deliver these messages when you run apt upgrade or apt dist-upgrade. They are:
apt-esm-hook
Responsible for populating templates with accurate package counts (i.e. the package count we see on the Expired contract messages). However, the messaging here is created by two distinct steps:
- Our update_messages timer job creates templates for the APT messages this hook will deliver. We cannot create the full message on the timer job, because we need the accurate package names and count. This information can only be obtained when running the
aptcommand.
Note
These templates will only be produced if certain conditions are met. For example, we only produce “expired contract” templates if the contracts are indeed expired.
- When you run either
apt upgradeorapt dist-upgrade, the hook searches for these templates and if they exist, they are populated with the correctaptcontent and delivered to the user.
apt-esm-json-hook
The JSON hook is responsible for delivering the rest of the message we have presented here. This hook is used to inject the message in the exact place we want, so we need to use a specific apt JSON hook to communicate with it.
Note
Those hooks are only delivered on LTS releases. This is because the hooks will not deliver useful messages on non-LTS due to lack of support for ESM services.
How are APT configured to deliver those messages?
We currently ship the package the 20apt-esm-hook.conf configuration that configures both the basic apt hooks to call our apt-esm-hook binary, and also the json API of apt to call our apt-esm-json-hook binary.
So I did just that, I commented out the two hooks.
Commented out hooks in file: `20apt-esm-hook.conf`
$ cat /etc/apt/apt.conf.d/20apt-esm-hook.conf
APT::Update::Pre-Invoke {
“[ ! -e /run/systemd/system ] || [ $(id -u) -ne 0 ] || systemctl start --no-block apt-news.service esm-cache.service || true”;
};
APT::Update::Post-Invoke-Stats {
# Disable ESM messages
# “[ ! -f /usr/lib/ubuntu-advantage/apt-esm-hook ] || /usr/lib/ubuntu-advantage/apt-esm-hook || true”;
};
binary::apt::AptCli::Hooks::Upgrade {
# Disable ESM messages
# “[ ! -f /usr/lib/ubuntu-advantage/apt-esm-json-hook ] || /usr/lib/ubuntu-advantage/apt-esm-json-hook || true”;
};
I rebooter and low and behold,…
Nothing changed
I’ve tested this on a headless Raspberry Pi running: Ubuntu Server 22.04.2 LTS (GNU/Linux 5.15.0-1026-raspi armv7l)
Some helpful tips for people wanting to try for themselves what I did.
The annoying messages are generated as part of the dynamic motd generation (update-motd package).
This service executes /etc/update-motd.d/90-updates-available.
You can test generation of the MOTD scripts with:
$ sudo run-parts /etc/update-motd.d/
On its turn motd.d shows a cached result.
That result was generated by update-notifier and cached in:
“/var/lib/update-notifier/updates-available”
by python script:
/usr/lib/update-notifier/apt_check.py
One can force the generation of the file by doing:
$ sudo /usr/lib/update-notifier/update-motd-updates-available --force
Verify removal of esm apt config with:
$ apt-config dump|grep esm
How can one elegantly unconfigure the messages from appearing at each login?
Hi @Marty
There are two places where pro related messaging happens:
You found and followed the documentation for apt related messages and then rightfully wondered why it didn’t change anything. Well, as you found by now it most likely did change things, but not in the MOTD at login that you were looking at.
It is worth to note that there has already been an effort to make it possible to - as you call it - “elegantly unconfigure” those.
Following the doc on “disable apt news” would give you a way that is way nicer and easier than modifying config files.
But back to the login messages, as I said (and you found by now) there are those two places.
You have debugged your way to find the same as documented, the motd page also documents that it is generated by apt_check.py of update-notifier.
And you are right - currently it is burdensome to disable those MOTD messages if someone wants to.
We are indeed already intending to make this messaging more easily configurable as well.
But due to being intertwined with update-notifier it is more complex to do that and therefore will take a while.
FYI there is a similar discussion happening in this issue leading to - just like your suggestion - backing our intend to work on this, hopefully allowing to tackle that more sooner than later.
While things were tracked internally already I furthermore filed this issue to ensure when we tackle it we will cover it all at once - thanks for your input @Marty!
While things were tracked internally already I furthermore filed this issue to ensure when we tackle it we will cover it all at once - thanks for your input @Marty!
While I can not yet do it all (like splitting update-notifier from pro/esm takes time) I’ve given it a try to (hopefully) better document how it works and how you would disable the different related messaging selectively. Feel free to have a look and chime in at https://github.com/canonical/ubuntu-pro-client/pull/2534
@ paelzer
Thanks for your reply and thanks for creating an issue report, but I’m missing the /etc/update-motd.d/90-updates-available inserting ESM messages that can’t be configured off.
It’s the repeating nature of the login messages and waste of screen real-estate that they consume, that gets increasingly annoying. After logging in for the 100th time we know already that ESM has not been activated. The messages become more annoying than informative each time they are repeated.
That said, I had another look at all the links and the document you worked on. Thanks for the effort.
Unfortunately your document doesn’t show a way to disable the messages that I described. It merely states:
If you want to disable any message of update-notifier (not just related to Ubuntu Pro and ESM) about potentially available updates remove
/etc/update-motd.d/90-updates-available.
I do want to be notified about updates, but I don’t want the superfluous ESM notices being repeated over and over again. So I can’t remove /etc/update-motd.d/90-updates-available for I will lose available update notifications too.
What boggles my mind is, why doesn’t /usr/lib/update-notifier/apt-check adhere to the apt cofiguration in /etc/apt/apt.conf.d/20apt-esm-hook.conf?
Why does /usr/lib/update-notifier/apt-check keep inserting the ESM messages:
In the end it is apt that generates the information and the apt-esm-hook and apt-esm-json-hook in the apt config file: /etc/apt/apt.conf.d/20apt-esm-hook.conf are commented out. So why is this ignored?
I came to the conclusion that the messages can’t be configured off and will be repeated mandatory. They will only disappear when you give into an ESM / Pro subscription.
[quote=“Marty, post:5, topic:34051”]
… but I’m missing the /etc/update-motd.d/90-updates-available inserting ESM messages that can’t be configured off. [/quote]
As my PR linked from that issue shows, right now, you can only disable all or nothing of the info of 90-updates-available. That will include update info due to packages available in the Ubuntu archive as well as those available through ESM.
To split the remaining message further so that you can disable one, but not the other needs more than just config or documentation. It is a proper feature request that we already filed out of this and other discussions at https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/2015420
This will need development in the pro client as well as update-notifier and won’t complete asap, the work on it will happen, but doesn’t fit in the near term plan yet.
You might want to subscribe there to be notified when it is available?
As it seems the problem won’t be solved in the near term. I’m thinking about pragmatically giving into a free personal Ubuntu pro subscription to make the messages go away, but then I read the following:
As I stated above, I’m running:
So now all of a sudden an important legal issue lurks beneath:
What qualifies as a “non-desktop” use case?
I’m running an old 32 bit headless Raspberry Pi 2 with Ubuntu Server (a minimal installation) for personal use.
Is that a “non-desktop” use case? (Running a full fledged desktop on an RPi 2 is very heavy, it swamps the little computer making it useless.)
How can I find out if my setup is a “non-desktop” use case?
I tried commands: lsb_release -a, uname -a and pro status (see outputs below), but none give me any helpful information about determining if this is a non-desktop use case.
lsb_release -a
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
uname -a
$ uname -a
Linux bug 5.15.0-1026-raspi #28-Ubuntu SMP PREEMPT Fri Mar 10 14:33:39 UTC 2023 armv7l armv7l armv7l GNU/Linux
pro status
$ pro status
SERVICE AVAILABLE DESCRIPTION
esm-apps yes Expanded Security Maintenance for Applications
esm-infra yes Expanded Security Maintenance for Infrastructure
livepatch yes Canonical Livepatch service
realtime-kernel yes Ubuntu kernel with PREEMPT_RT patches integrated
This machine is not attached to an Ubuntu Pro subscription.
See https://ubuntu.com/pro
What commands do I have to enter in order to find out?
What if I might decide to install a little web server later on, will I suddenly be in breach of contract and liable for whatever?
Will Canonical be surveilling my system remotely?
Why would you care? This is about paid support.
The free subscription can be used on desktops as well as VMs, cloud instances or personal servers likewise as long as it does not exceed 5 installs (or 50 installs if you are an Ubuntu member)…
What qualifies as a “non-desktop” use case?
The exact definition of that is always hard and I’d refer to @Lech to answer that. Maybe we can use some insights of that clarification eventually to also put it into the FAQ?
Will Canonical be surveilling my system remotely?
No, there is no “check exactly what you do” functionality