Maintenance ended; however, it did not exit cleanly - scripts/modsec_vendor
Morning folks... Not necessarily a cPanel issue, but UPCP failed last night as follows:
Maintenance ended; however, it did not exit cleanly (256). The following events were logged: "scripts/modsec_vendor". Review the update logs to determine why the update failed.
[2018-10-09 23:44:05 +0100] E [/usr/local/cpanel/scripts/modsec_vendor] The "/usr/local/cpanel/scripts/modsec_vendor update --auto" command (process 3101) reported error number 1 when it ended.
Manually running /usr/local/cpanel/scripts/modsec_vendor update --auto results in:
warn [modsec_vendor] The system could not add the vendor: The system could not download the file "https://waf.comodo.com/api/cpanel_apache_vendor": curl: (22) The requested URL returned error: 500 Internal Server Error
info [modsec_vendor] Restored modsec_cpanel_conf_datastore backup
warn [modsec_vendor] The system failed to update the vendor from the URL "https://waf.comodo.com/doc/meta_comodo_apache.yaml": The system could not download the file "https://waf.comodo.com/api/cpanel_apache_vendor": curl: (22) The requested URL returned error: 500 Internal Server Error
...and visiting the two destinations in a web browser produces:
"We're sorry, but something went wrong."
A quick trip to ModSecurity Rules | Best Free Web Application Firewall from Comodo and hitting the Login link presents the same "We're sorry, but something went wrong" error.
Is anyone aware of Comodo discontinuing their free ruleset?
They released a new Client agent yesterday, not that that should have any impact on cPanel users that I'm aware of... but waf.comodo.com 500 error - Free Modsecurity rules - Comodo Web Application Firewall
The obvious solution is to turn off Comodo rules and just use the OWasp rulesets, however, there's an undocumented reason why we didn't in the first place (wish I could remember what it was!)-
The obvious solution is to turn off Comodo rules and just use the OWasp rulesets, however, there's an undocumented reason why we didn't in the first place (wish I could remember what it was!)
Or wait a bit and see how things play out. Those rules were never updated nightly as far as I know. Updating them may be an issue right now but they should still be working on our systems. I use them as well. I like these rules more as there were far fewer problems with them blocking legitimate requests from customers scripts. Lets see what the next few days brings. The forum thread you link to hasn't been replied to by staff over there yet.0 -
Comodo had an issue with their WAF page and API - they fixed it this morning, so you can run /usr/local/cpanel/scripts/modsec_vendor update --auto
again and it will work, additionally the next upcp shouldn't "fail" either.0 -
Hi @APatchworkBoy As indicated by @LucasRolff there was an issue with Comodo WAF let us know if his suggestions resolve the issue for you. Thanks! 0 -
*thumbsup* All sorted - ta muchly! (I keep forgetting about timezone differences) info [modsec_vendor] You have updated the vendor "COMODO ModSecurity Apache Rule Set". [comodo_apache] COMODO ModSecurity Apache Rule Set archive_url https://waf.comodo.com/api/cpanel_apache_vendor cpanel_provided 0 description COMODO ModSecurity Rules for Apache dist_md5 c2581339e7c4259d349ea9183cc2437e dist_sha512 cdcc6f2893a2f1d50b02ca71b11f0a8c06b4a5dfdad45d0765c324fa292e1dbeecd8ea392404311a601dfc56aa0799d8df0d0d682656ab7b84b5b71fc4d6c93e enabled 1 inst_dist comodo-apache-1183 installed 1 installed_from https://waf.comodo.com/doc/meta_comodo_apache.yaml name COMODO ModSecurity Apache Rule Set path /etc/apache2/conf.d/modsec_vendor_configs/comodo_apache report_url https://waf.comodo.com/api/cpanel_feedback?source=0&rule_set=1.183 supported_versions (6) vendor_id comodo_apache vendor_url https://waf.comodo.com0
Please sign in to leave a comment.
Comments
4 comments