SOLVED CPANEL-39815 - Not receiving security advisor notifications

[cPRex]

I did read through the ticket and it was definitely an odd issue, but I'm glad we were able to track it down. Our developers are working on that now so that will get taken care of in a future release.

 

[cPSloaneB]

Quick follow-up on CPANEL-41626: The issue turns out to be an extremely subtle logic inversion in the check_security_advice_changes script. Specifically, near the top of that file, there should be the following lines:

sub _run_from_command_line {
    my (@args) = @_;
    if ( grep { index( $_, '-background' ) > -1 } @args ) {
        @args = grep { index( $_, '-background' ) != -1 } @args;

That last line cited above is the problem. It's supposed to filter out command line arguments which contain "-background", because the code that handles this argument is running early, but instead it filters out the ones which do not contain that match, meaning that the --notify flag being passed to the script to tell it to issue notifications is never noticed later on in the script, because this earlier mistake effectively erases it. Changing that line to the following should fix it:

        @args = grep { index( $_, '-background' ) == -1 } @args;

 

[WorkinOnIt]

Hey @cPSloaneB

I am pleased to see the progress - I've been a bit too busy to follow up - but was wondering if I should start a new thread....

I could try that mod myself in the /scripts/check_security_advice_changes script, but I assume it will get overwritten in nightly updates?

When will your fix make it into the release?

 

[cPSloaneB]

I could try that mod myself in the /scripts/check_security_advice_changes script, but I assume it will get overwritten in nightly updates?

When will your fix make it into the release?

The script file is not controlled by an RPM package, so it will only be updated when cPanel itself updates to a new version.

Because of the way our internal development process works, the farthest back I can directly put this fix is into 108. I can mark it with a request to backport to earlier versions, but that is entirely at the discretion of the people in charge of issuing releases. As usual, it will be in our changelogs listed by the case ID (CPANEL-41626) when it does make it into a particular release branch.

 

[WorkinOnIt]

The script file is not controlled by an RPM package, so it will only be updated when cPanel itself updates to a new version.

OK I will try it. Once I have updated the file, what other actions do you recommend I do, to test if it's working?

 

[cPSloaneB]

OK I will try it. Once I have updated the file, what other actions do you recommend I do, to test if it's working?

It should be the last time you need to remove /var/cpanel/security_advisor_history.json. Presuming you still have items with sufficient severity, the notification should be issued next time cPanel performs its nightly maintenance.

 

[WorkinOnIt]

It should be the last time you need to remove /var/cpanel/security_advisor_history.json. Presuming you still have items with sufficient severity, the notification should be issued next time cPanel performs its nightly maintenance.

Hey, I have now set up the test and gave it a week. This morning I ran the security advisor in WHM and saw the following:

The system’s core libraries or services have been updated.
Reboot the server to ensure the system benefits from these updates.


However, I did not receive any notice in email.

 

[cPSloaneB]

Hey, I have now set up the test and gave it a week. This morning I ran the security advisor in WHM and saw the following:

The system’s core libraries or services have been updated.
Reboot the server to ensure the system benefits from these updates.


However, I did not receive any notice in email.

When exactly were packages updated? If cPanel updated them automatically, you should be able to find this among the last week's worth of update logs in /var/cpanel/updatelogs/. The same log should also indicate when scripts/check_security_advice_changes ran on that day.

 

[WorkinOnIt]

When exactly were packages updated? If cPanel updated them automatically, you should be able to find this among the last week's worth of update logs in /var/cpanel/updatelogs/. The same log should also indicate when scripts/check_security_advice_changes ran on that day.

cPanel updated them automatically.

The log says the following have run every day - but no emails.

[2022-10-20 02:41:29 +1300] - Processing command `/usr/local/cpanel/scripts/check_security_advice_changes --notify --background`
[2022-10-20 02:41:29 +1300] - Finished command `/usr/local/cpanel/scripts/check_security_advice_changes --notify --background` in 0.065 seconds

[2022-10-21 02:41:29 +1300] - Processing command `/usr/local/cpanel/scripts/check_security_advice_changes --notify --background`
[2022-10-21 02:41:29 +1300] - Finished command `/usr/local/cpanel/scripts/check_security_advice_changes --notify --background` in 0.127 seconds

[2022-10-22 02:41:49 +1300] - Processing command `/usr/local/cpanel/scripts/check_security_advice_changes --notify --background`
[2022-10-22 02:41:49 +1300] - Finished command `/usr/local/cpanel/scripts/check_security_advice_changes --notify --background` in 0.155 seconds

etc

Let me know the email address and I can forward them to you if you wish.

 

[WorkinOnIt]

Hello.

This issue is still not resolved.

I am on version 1.04.

I did receive a "New Security Advisor notification email..." one !

It said " Detected 1 process that is running outdated executables: You must take one of the following actions to ensure the system is up-to-date: "

Which is great, but then when I checked in the server, there was a system kernel update notice, but that had not been sent in the email.

I run multiple servers. the issue persists across all servers.

 

[WorkinOnIt]

Further to the above, after performing a restart last night, I got this this morning:

Medium

Kernel

The system cannot check the kernel status: “/usr/bin/yum” reported error code “1” when it ended: Error: Failed to download metadata for repo 'MariaDB103': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

Medium	Kernel	The system cannot check the kernel status: “/usr/bin/yum” reported error code “1” when it ended: https://archive.mariadb.org/mariadb-10.3/yum/centos/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors If above article doesn't help to resolve this issue please use https://bugs.centos.org/. One of the configured repositories failed (MariaDB103), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=MariaDB103 ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable MariaDB103 or subscription-manager repos --disable=MariaDB103 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=MariaDB103.skip_if_unavailable=true failure: repodata/repomd.xml from MariaDB103: [Errno 256] No more mirrors to try. https://archive.mariadb.org/mariadb-10.3/yum/centos/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
Info	Elevate	The system detected the following issues which would prevent cPanel ELevate from upgrading the system to AlmaLinux 8: yum is not stable System is not up to date

 

[cPRex]

@cPSloaneB

 

[cPSloaneB]

Hello.

This issue is still not resolved.

I am on version 1.04.

I did receive a "New Security Advisor notification email..." one !

It said " Detected 1 process that is running outdated executables: You must take one of the following actions to ensure the system is up-to-date: "

Which is great, but then when I checked in the server, there was a system kernel update notice, but that had not been sent in the email.

I run multiple servers. the issue persists across all servers.

Issues depending on external data and/or timing of events have a way of being difficult to track down. I know this isn't what you would like to hear, but if the issue persists even after the most recent fix, then you will need to open yet another support ticket, so that we can continue to investigate. Thank you for your continued patience and understanding.

Further to the above, after performing a restart last night, I got this this morning:

Medium

Kernel

The system cannot check the kernel status: “/usr/bin/yum” reported error code “1” when it ended: Error: Failed to download metadata for repo 'MariaDB103': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

Medium	Kernel	The system cannot check the kernel status: “/usr/bin/yum” reported error code “1” when it ended: https://archive.mariadb.org/mariadb-10.3/yum/centos/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors If above article doesn't help to resolve this issue please use https://bugs.centos.org/. One of the configured repositories failed (MariaDB103), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=MariaDB103 ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable MariaDB103 or subscription-manager repos --disable=MariaDB103 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=MariaDB103.skip_if_unavailable=true failure: repodata/repomd.xml from MariaDB103: [Errno 256] No more mirrors to try. https://archive.mariadb.org/mariadb-10.3/yum/centos/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
Info	Elevate	The system detected the following issues which would prevent cPanel ELevate from upgrading the system to AlmaLinux 8: yum is not stable System is not up to date

All of this is saying that there were problems with MariaDB's repository. This was likely a transient event on their end. In any case, the only part of it relevant to the Security Advisor is that the output could be cleaner, and Security Advisor could have a better way to distinguish between outcomes which are noteworthy because they reveal a potential security issue and those which are noteworthy because the underlying mechanism experienced an error and could not make a proper determination.