cPanel overwriting SA rules on a daily basis
Since the last few updates, cPanel somehow updates SA rules on a daily basis and overwrites all manually edited files. Is there a way to turn off the daily SA rule updates?
-
I'm pretty sure the same thing happened to me. Just checked my /etc/mail/spamassassin/local.cf file and all of my custom rules are gone. However, I don't want to turn off the daily rule updates for spamassassin, but I would like to know why my local file has been overwritten and how to prevent it from happening again. Thanks! 0 -
Hello :) Could you open a support ticket using the link in my signature so we can take a closer look? You can post the ticket number here so we can update this thread with the outcome. Thank you. 0 -
I can confirm this happening on my servers as well, cpanel updates overwriting /etc/mail/spamassassin/local.cf all my custom rules were gone. 0 -
I can confirm this happening on my servers as well, cpanel updates overwriting /etc/mail/spamassassin/local.cf all my custom rules were gone.
Hello :) Please follow the first step on the following document if you are using cPanel version 11.52 or earlier: How to Configure the Apache SpamAssassin Report_Safe Option - cPanel Knowledge Base - cPanel Documentation This will ensure changes are not overwritten. Thank you.0 -
What about releases later than 11.52???? 0 -
Yeah cPanel on major version updates is still replacing local.cf and v*.pre files with defaults instead of leaving them alone. It does create .rpmsave files so you can revert changes but I don't see the reason these files are messed with in the first place. As far as I understand new changes to Spamassassin are introduced with a new.pre file for that version. I've added a Feature Request (pending moderation). 0 -
Should be a bug considering that cPanel tells you to put your custom rules there. Wiping out user configuration files on automatic updates without warning or notice is not documented behavior. 0 -
Should be a bug considering that cPanel tells you to put your custom rules there. Wiping out user configuration files on automatic updates without warning or notice is not documented behavior.
Hello, Would you mind sharing the links to the documentation or options in cPanel/WHM that reference these instructions so we can open an internal case to address the issue? Currently, there's a document at: How to Configure the Apache SpamAssassin Report_Safe Option - cPanel Knowledge Base - cPanel Documentation However, it states: This document is for cPanel & WHM version 11.52 and earlier. We removed the Old-Style Spam System setting and its functionality in cPanel & WHM version 54.
I've added a Feature Request (pending moderation).
Would you mind sharing the URL to the feature request? Thank you.0 -
@cPanelMichael, You personally have recommended using local.cf for spamassassin as "the right way to change SpamAssassin rule score" Right way to change SpamAssasin rule score and as the place to make Custom SpamAssassin Rules Custom SpamAssassin Rules and as the place to put SpamAssassin Custom ruleset files Apache SpamAssassin custom ruleset files and another recommendation to use local.cf by you Spam assassin rewrite_header not working Also, cPanel puts lines in local.cf like this: dns_available yes # Autoconfigured by cPanel - comment out this line or set to no to avoid future updates pyzor_options --homedir /etc/mail/spamassassin # Autoconfigured by cPanel - comment out this line to avoid future updates
Uncommenting those lines to make them permanent won't work when local.cf gets overwritten during upgrades so its not working as documented right in the local.cf file. Oh, and the very first line of local.cf says "This is the right place to customize your installation of SpamAssassin."0 -
Hello, Thank you for reporting those forum threads. cPanel version 11.52 was published to the "Release" build tier on 10/12/15, so while those threads are from older dates, I'll update them with a link to the new document in-case users reach those threads from search results on our forums here, or on search engines. Also, the "Report" option under the "Tools" menu on a post is available anytime you need to report outdated or incorrect information on a post. As far as the document, I'll open a case with our documentation team and provide an update here with more details. Thank you. 0 -
What new document? That's what I was asking about in the first place. I can find no doc that says how we should be doing things in a post-52 world. I just ran into another thread with this post: Customize SpamAssassin score Sounds like someone at cPanel is recommending putting your own .cf file in /etc/mail/spamassassin instead of modifying local.cf. Is that what we should be doing now? Will it survive upgrades? If that doesn't work and there is no way to make global spamassassin changes without them getting wiped out by an upgrade post-52 can you just come right out and say that instead of just saying here's how to do it in older releases and not mentioning newer releases? 0 -
Would you mind sharing the URL to the feature request?
It ended up being declined as a feature request and Benny opened a Bug instead as CPANEL-6016.0 -
Hello, As mentioned, CPANEL-6016 is open to address this issue. I'll keep this thread updated with the status of this case. In the meantime, yes, the instructions in the following post will allow you to retain custom changes through the use of individual custom configuration files: Customize SpamAssassin score Thank you. Update: This case is included in cPanel version 60: Fixed case CPANEL-6016: Updated SpamAssassin to 3.004001-cp1156. 0 -
Sounds like someone at cPanel is recommending putting your own .cf file in /etc/mail/spamassassin instead of modifying local.cf. Is that what we should be doing now? Will it survive upgrades?
We've had a "/etc/mail/spamassassin/custom.cf" file in place for some time with custom rules and scoring and the file has survived intact following updates/upgrades.0 -
It looks the order of precedence for the files in /etc/mail/spamassassin/ are alphabetical, so to override anything in init.pre, local.cf or the v3xx.pre files, it'd be safer using a file starting with a Z, perhaps zenith.cf. :) 0
Please sign in to leave a comment.
Comments
15 comments