Resolved awp cron job failing after update to Plesk 18.0.57

[opus68]

Server operating system version

CentOS Linux 7.9.2009 (Core)

Plesk version and microupdate number

18.0.57 #1

Immediately after updating to Plesk 18.0.57 I started receiving hourly cron job notices by email:

Subject: Cron <root@hostname> run-parts /etc/cron.hourly /etc/cron.hourly/01-awp_hourly: AIR_GAPPED set to yes. Skipping execution of awp_hourly

And indeed, in /var/awp/etc/config (sourced from /etc/cron.hourly/01-awp_hourly), the variable AIR_GAPPED is set to "yes".

Has anybody observed the same behaviour? Could this be some incompatibility between Plesk 18.0.57 and aum?

Thanks!

 

[Peter Debik]

This is a known issue, internal ID PPP-63350. At the moment it is still unclear here, whether it is best to change the AIR_GAPPED setting or if the consequence could be that future nightly Atomic updates could break Apache in that case. For that reason I suggest to temporarily suppress the crontab notifications or just ignore them until PPP-63350 is solved.

 

[opus68]

Will do so - thank you very much for the quick response, @Peter Debik.

 

[Peter Debik]

Please see this article on the issue:

https://support.plesk.com/hc/en-us/articles/19294694284951

 

[Dork]

Please see this article on the issue:

https://support.plesk.com/hc/en-us/articles/19294694284951

And what's about config.aum?

 

[EricRB]

This is a known issue, internal ID PPP-63350. At the moment it is still unclear here, whether it is best to change the AIR_GAPPED setting or if the consequence could be that future nightly Atomic updates could break Apache in that case. For that reason I suggest to temporarily suppress the crontab notifications or just ignore them until PPP-63350 is solved.

INFO: I changed the setting back to "no" according to the plesk support article, yesterday, and today I see it is back to "yes" in the config file and all was well until just before 4 AM (EDT) this morning. I got the first CRON error By the way, apache does not restart after the aum -u process has finished. I restarted it with systemctl. However the point remains that something changed the "/var/awp/etc/config" file prior to 3:56 AM (EDT) this morning, setting the air gapped setting back to "yes". Once again I changed the manual file to set AIR_GAPPED = "no" and aum -u ran fine. As yesterday, I expect that I will get no errors until tomorrow when some cron job runs that seems to modify the /var/awp/etc/config to set the setting back to "yes". Pretty weird.

 

[GravuTrad]

Same problem for me.

 

[EricRB]

Once again, this morning the config file was changed to AIR_GAPPED = "yes" but the time stamp on the file was still the same from when I fixed it yesterday. So it is bizarre that the AIR_GAPPED was changed back to "no" with no change in the file's time stamp.

 

[Peter Debik]

Maybe the Atomic ruleset is just not the right choice for you at the moment? I've been using it in production for years - until spring 2023 when all kinds of issues were brought in by nightly maintenance updates. I just don't have the time to deal with them all the time, so now am using Comodo. Plesk has also disabled Atomic on all new installations. Now, I don't want to ask you to switch, but just mentioning that there is an option.

 

[EricRB]

Maybe the Atomic ruleset is just not the right choice for you at the moment? I've been using it in production for years - until spring 2023 when all kinds of issues were brought in by nightly maintenance updates. I just don't have the time to deal with them all the time, so now am using Comodo. Plesk has also disabled Atomic on all new installations. Now, I don't want to ask you to switch, but just mentioning that there is an option.

Hi Peter,
I just ran another test, and used the GUI to bounce the ruleset to Comodo, and then back to Atomic. Lo and behold, the /var/awp/etc/config file was rewritten of course, but with AIR_GAPPED set to "yes". I simply changed it to "no" and ran aum -u again. Won't be bothered by the failure messages from cron.hourly. The config is set to update daily, not hourly anyway, but because there is the IF statement at the beginning of the cron.daily still checks for AIR_GAPPED set to "yes", it generates the error message.

I've retired now from active hosting but still maintain this Plesk server for personal/friends/family reasons. I was running Comodo on a server running CentOS 8 before because CentOS 8 wouldn't allow for Atomic ruleset, and had nothing but problems with Comodo giving false positives on many activities of legitimate web users, esp with WordPress sites. Had to put many exceptions in. In my view, Atomic is much more stable in terms of false positives. I appreciate the feedback. When you say Plesk has disabled Atomic on new installations, do you mean it can't be used on a new installation at all?

 

[Peter Debik]

What I said was a diplomatic way of suggesting an alternative path to solve current issues. After all, the goal should be to provide solutions, not problems.

 

[GravuTrad]

Once again, this morning the config file was changed to AIR_GAPPED = "yes" but the time stamp on the file was still the same from when I fixed it yesterday. So it is bizarre that the AIR_GAPPED was changed back to "no" with no change in the file's time stamp.

Exactly the same thing. What's this ****?

 

[Peter Debik]

Could you please install the latest update 18.0.57 #2 and check whether it resolves the issue? It includes a fix "ModSecurity no longer automatically updates the “Atomic Standard” and “Atomic Advanced” rule sets ignoring the Plesk settings. (PPPM-14222)" that is related to the issue.

 

[GravuTrad]

sorry but my panel isn't giving it. (yet?)

 

[GravuTrad]

The update has been found and done. I will check.

 

[opus68]

Could you please install the latest update 18.0.57 #2 and check whether it resolves the issue? It includes a fix "ModSecurity no longer automatically updates the “Atomic Standard” and “Atomic Advanced” rule sets ignoring the Plesk settings. (PPPM-14222)" that is related to the issue.

18.0.57 #2 fixes the problem on my server. Thanks a lot!

 

[GravuTrad]

it's seems working yes. No more mail.