Disable Ubuntu Pro's ua-timer.timer job; causing OSSEC alerts

[legoktm]

Status

Ready for review

Description of Changes

Ubuntu Pro's "uaclient" expects the Linux kernel package to be versioned in a specific format that we are not currently compliant with. This error message is triggering spurious OSSEC alerts.

While we do plan to fix our kernel versioning scheme, we really don't need this Ubuntu Pro stuff, so let's disable it the same way we do with fwupd.

Fixes #6773.

Testing

• Manually run sudo systemctl disable ua-timer.timer && sudo systemctl mask esm-cache
• Manually reboot your server or wait for the nightly reboot
• Wait another 24h, observe that you get no OSSEC notifications related to failed to process /proc/version_signature

Note that I did not include the extensive testing plan regarding packages that #6401 had as I think we can trust that the postinst and bash conditional logic is correct since it's the same, just that disabling the timer produces the effect we want.

Deployment

Any special considerations for deployment? Not really.

Checklist

• Configuration tests pass
• I have written a test plan and validated it for this PR
• These changes do not require documentation

[cfm]

I've begun this test plan, and I'll update this report tomorrow:

• Manually run sudo systemctl disable ua-timer.timer

amnesia@amnesia:~$ ssh app sudo systemctl disable ua-timer.timer
Removed /etc/systemd/system/timers.target.wants/ua-timer.timer.
amnesia@amnesia:~$ ssh mon sudo systemctl disable ua-timer.timer
Removed /etc/systemd/system/timers.target.wants/ua-timer.timer.

• Manually reboot your server or wait for the nightly reboot
• Wait another 24h, observe that you get no OSSEC notifications related to failed to process /proc/version_signature

Note that I did not include the extensive testing plan regarding packages that #6401 had as I think we can trust that the postinst and bash conditional logic is correct since it's the same, just that disabling the timer produces the effect we want.

No concerns from me. If in release QA the postinst doesn't execute this command, or doing so doesn't have the intended result, then that's a bigger problem than just this command!

[legoktm]

I'm still getting the OSSEC alerts, despite the ua-timer job being stopped... :(

via syslog:

Apr 24 02:04:06 app systemd[1]: Starting Daily apt download activities...
Apr 24 02:04:06 app systemd[1]: Starting Update APT News...
Apr 24 02:04:06 app systemd[1]: Starting Update the local ESM caches...
Apr 24 02:04:06 app python3[268123]: failed to process /proc/version_signature.
Apr 24 02:04:06 app python3[268123]: Failed to parse kernel: 5.15.89-grsec-securedrop

So it's one of those...

root@app:/var/log# systemctl cat esm-cache
# /lib/systemd/system/esm-cache.service
# The ESM apt cache will maintain information about what ESM updates are
# available to a system. This information will be presented to users in the apt
# output, or when running pro security-status. These caches are maintained
# entirely outside the system apt configuration to avoid interference with user
# definitions. This service updates those caches. This will only have effect
# on releases where ESM is applicable, starting from Xenial: esm-apps for
# every LTS, and esm-infra for systems in expanded support period after the LTS
# expires.

[Unit]
Description=Update the local ESM caches

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /usr/lib/ubuntu-advantage/esm_cache.py

Probably that? Though I can't actually figure out what's starting it.

[legoktm]

Via https://askubuntu.com/questions/1452519/what-are-the-services-apt-news-and-esm-cache-and-how-do-i-disable-them

root@app:/lib/systemd# 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";
};

binary::apt::AptCli::Hooks::Upgrade {
        "[ ! -f /usr/lib/ubuntu-advantage/apt-esm-json-hook ] || /usr/lib/ubuntu-advantage/apt-esm-json-hook || true";
};

So we either need to override the hook or mask the units. Sigh.

[airblag]

Same here. I disabled/masked the ua-timer.timer/ua-timer.service but the osssec error continued.
I just ran manually systemctl start esm-cache and got the ossec mail directly.
I now disabled/mask the esm-cache server on both, I hope it will remove the daily errors

[legoktm]

Thanks @airblag - I've updated the PR to also mask esm-cache and applied it to my instance, let's see how it goes...

[cfm]

@legoktm, I've marked this as back in progress until it's ready to review again. :-)

[legoktm]

*checks OSSEC notifications*

Looks working as intended to me, my app server hasn't had an alert since I masked esm-cache on Friday, while mon, which doesn't have any of the changes from this PR, is still emitting alerts.

So ready for review @cfm :)

[cfm]

Test plan checks out!

• Manually run sudo systemctl disable ua-timer.timer && sudo systemctl mask esm-cache
• Manually reboot your server or wait for the nightly reboot
• Wait another 24h, observe that you get no OSSEC notifications related to failed to process /proc/version_signature

I have one question (inline) before I approve.

[legoktm]

(Rebased to fix static-analysis-and-no-known-cves-1 failure)

[cfm]

The testinfra check added today confirms yesterday's successful manual testing. Thanks, @legoktm!