Error in ModSecurity transfer

PeteS

Well-Known Member
Jun 8, 2017
390
88
78
Oregon
cPanel Access Level
Root Administrator
On transferring Service Configurations, ModSecurity completed with one failure: Failed: (XID 2chkk6) The WHM API v1 call “modsec_make_config_inactive” failed: The following configuration is not active: modsec_vendor_configs/OWASP3/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf

Upon retrying it competes without failure, though the restoration log is entirely in red except for the last entry of "Success" because everything was already done.

This failure happened on transfer to two different fresh servers, from the same source.

I looked on the source server and I did not see that rule. To me the error seems to indicate that it wanted to inactivate what wasn't active. So does that mean it's all good, or what?
 
Last edited by a moderator:

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
Hey hey! I want to say "yes" and that your logic is correct, but I'm not finding much for this error on my end. For confirmation, it might be a good idea to submit a ticket to our team so we can do some additional testing with that Source server.
 

PeteS

Well-Known Member
Jun 8, 2017
390
88
78
Oregon
cPanel Access Level
Root Administrator
Hey hey! I want to say "yes" and that your logic is correct, but I'm not finding much for this error on my end. For confirmation, it might be a good idea to submit a ticket to our team so we can do some additional testing with that Source server.
Ticket: 94434733

Can this be looked at asap? This source server is needing to be migrated asap, and I am holding off on and changes to it, or transfer from it, until this resolves.

Thanks.
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
Following on my end now. I'm pretty cool, but I'm not "skip the queue" cool. Even if I was, I wouldn't say it on the Forums because people would quickly realize they could poke me here and give their ticket priorioty.

The queue doesn't look too terrible on my end, so I'm guesstimating you'll hear something official within a few hours.
 
  • Like
Reactions: PeteS

PeteS

Well-Known Member
Jun 8, 2017
390
88
78
Oregon
cPanel Access Level
Root Administrator
No, no, I didn't mean "skip the queue." :) It's been almost a year since I opened a ticket, and somewhere along the line the queue position update went away, so I have no way of even guessing.

But since you brought up prioritizing... Are licenses not directly purchased from cPanel still given second priority?

I have licensing both ways at current, and I have considered changing them all to direct for this reason. It's only a little more expensive, so that's not the issue, but it is more convenient for me going non-direct because the provided adjusts the licenses up/down automatically based on accounts, and I can also spin up a cPanel server in one click - stupid easy. So this is something I've been pondering about which way to go with...
 

PeteS

Well-Known Member
Jun 8, 2017
390
88
78
Oregon
cPanel Access Level
Root Administrator
Update: I was incorrect about the REQUEST-931-APPLICATION-ATTACK-RFI not being on the source server, it is there. (Search error on my part.)

When I compare a search for that rule on the source and destinations I see the destination I retied matches the source, but the destination I didn't retry has no rules at all. So the failure is legit, but the why of it, and whether a retry with success as described above resolves it completely is awaiting the ticket response. (Tech is looking in to both source and destination servers now.) I'll post back when the ticket is resolved.
 

PeteS

Well-Known Member
Jun 8, 2017
390
88
78
Oregon
cPanel Access Level
Root Administrator
Long story short, the retry did in fact successfully and correctly transfer the modSec setup (including having that rule inactive) and resolve the issue.

Longer story:
For some reason the rule in question was off on the source server's vendor settings but marked on in ModSec Tools. This conflict caused the initial error... no idea why/how it got that way.

One gotcha - rebuilding the datastore ( https://support.cpanel.net/hc/en-us...file-var-cpanel-modsec-cpanel-conf-datastore- ) turns off the vendor, and that confused me for a while. Turning it and update back on, and enabling the missing rule, resolved that.