Applicable to:
- Plesk for Linux
Symptoms
-
Apache can not be started on the Plesk Server.
-
One of the following errors can be present:
-
In Tools & Settings > Web Application Firewall (ModSecurity) > Settings tab:
PLESK_ERROR: Failed to update the ModSecurity rule set: modsecurity_ctl failed: The ruleset were not installed Command '['/var/asl/bin/aum', '-uf']' returned non-zero exit status 3.
Output:
Checking versions ...
-------------------------------------------------------------------------------
Errors were encountered:
L CODE SOURCE MESSAGE
- ---- ----------------------------- ------------------------------------------
[0;33m2 9901 ASLCommon::cmd_exec ERROR: '(7) /usr/bin/curl -A "Atomic Updater Modified (4.0)" -s -f --connect-timeout 10 --data "member=interdomain&license=&product=asl-4.0&from_web=1&system_type=webserver&act=2" https://updates.atomicorp.com/pgui_v/rpc4.0.php -- '
[0m[0;33m2 9998 ASLValidate::_send_request validation error: 7
[0m[0;33m2 9999 ASLValidate::validate_asl Bad data from request
[0m[0;33m2 302 Core::distributed_update remote fail: E_CONNECT 7 .. www6.atomicorp.com/channels/rules/VERSION
[0m[0;33m2 302 Core::distributed_update remote fail: E_CONNECT 7 .. www3.atomicorp.com/channels/rules/VERSION
[0m[0;33m2 302 Core::distributed_update remote fail: E_CONNECT 7 .. www4.atomicorp.com/channels/rules/VERSION
[0m[0;33m2 302 Core::distributed_update remote fail: E_CONNECT 7 .. www5.atomicorp.com/channels/rules/VERSION
[0m[0;33m2 302 Core::distributed_update remote fail: E_CONNECT 7 .. www2.atomicorp.com/channels/rules/VERSION
[0m[1;31m3 301 Core::check_versions ASL Version list could not be retrieved.
[0m172.17.0.1
172.16.3.21
172.16.3.22
127.0.0.1
-
The error below may appear in the
/var/log/httpd/error_log:CONFIG_TEXT: ModSecurity: Loaded 0 rules from: 'https://updates.atomicorp.com/channels/rules/installers/indicators.conf'.
ModSecurity: Problems loading external resources: Failed to download: "https://updates.atomicorp.com/channels/rules/installers/indicators.conf" error: Couldn't connect to server.
-
Atomic Standard ruleset can not be enabled in Tools & Settings > Web Application Firewall (ModSecurity) with:
CONFIG_TEXT: modsecurity_ctl failed: Failed to download tortix rule set.
-
Cause
Temporary issue on Atomic side with the Atomic rulesets in ModSecurity. It led to the Apache service timeout to be exceeded.
Resolution
The issue was resolved by Atomicorp. If required, switch the ruleset back to Atomic in Tools & Settings > Web Application Firewall (ModSecurity).
-
Connect to the server via SSH.
-
Execute the command below to rename the ModSecurity configuration file back:
# mv /etc/httpd/conf.d/00_mod_security.conf1 /etc/httpd/conf.d/00_mod_security.conf
Comments
9 comments
I just hope that Atomic finds the solution soon, the servers are vulnerable, and using comodo free is not a solution.
Yes, Gabriella is right! We are looking forward to a fast solution as well. - is there already a feedback from atomicorp's side?
This resolved my issue but I received a different error than the ones listed, I'll put it below in case anyone gets the same as me:
AH00111: Config variable ${} is not definedThanks
+1 please fix this quickly. We are paying $ for the custom Atomic rules.
I understand that there may be issues with downloading new rulesets daily or connecting with Atomic's servers that are out of your hands. That is an Atomic issue. But we really need Plesk to write an interface that fails gracefully if things go wrong on Atomic's end. We had 50 sites with hours of downtime this morning. Nginx should not go down completely if there's a problem connecting to Atomic's servers. There should be error handling and a failover - ideally to keep mod_security running, but just with the previous day's rules... but if that's not possible, even failing over to turn mod_security off and sending admins a notification would be better than just letting the whole server break and cause downtime.
We have had too many problems with Comodo Free resulting in false positives - this is not a solution at all. If Comodo Free worked great, we would not pay the extra license fee for the Pro level Atomic rules.
Thanks in advance for your attention to this!
Hello Gabriella Cocchiarella, Andy Herzig,
Atomicorp resolved the issue, their update service is back online.
Brian Kelly, if the problem still appears on your server please open a support ticket.
Switching back to Atomicorp gives me a Username and Password request for my Atomic Account Credentials. Where would I get these? When I purchased the subscription, it just activated. I have no username and password for this.
@Benjamin Weßel thanks for the update. That's great that the service it back online, but I'm hesitant to re-enable it if you have not changed anything about the error handling. What if their service goes out again next week? Are we just supposed to be dependent on Atomic being fully operational 24/7/365 or else maybe our entire server will crash?
Hello Peter Wise,
Thank you for pointing to that. We've already reported this behavior to our developers so they find a way for preventing Apache to stop when Atomic resources are not available.
Hello Peter Wise,
After completing the investigation by our Development Team, it was defined that improvements should be performed on the Atomic side. We've forwarded the request to Atomic developers and shared feedback received from our customers. They accepted it and are planning improvements to prevent the issue from reoccurrence.
Please sign in to leave a comment.