This TSR update rebuilt the Exim configuration back to the pre-autofixer (/scripts/autorepair exim_disable_chunking) configuration.
Was this intentional ?
Was this intentional ?
I'm struggling to understand the thinking behind this.
Today's security update found a conflict with my custom Exim configuration. Fine, it happens. But then it went ahead and replaced my custom Exim with the default configuration. Whereupon about email for about 1,000 people became undeliverable, at least until I was able to shut down Exim and restore the custom stuff (except one SRS-related line that was the source of the problem).
Wouldn't it be better to:
1. Stop the update, roll back the changes and let me know about the problem.
2. Finish the update, but take Exim down until the conflict can be resolved.
3. Do pretty much anything other than replace the custom config with the default.
Today's security update found a conflict with my custom Exim configuration. Fine, it happens. But then it went ahead and replaced my custom Exim with the default configuration. Whereupon about email for about 1,000 people became undeliverable, at least until I was able to shut down Exim and restore the custom stuff (except one SRS-related line that was the source of the problem).
Wouldn't it be better to:
1. Stop the update, roll back the changes and let me know about the problem.
2. Finish the update, but take Exim down until the conflict can be resolved.
3. Do pretty much anything other than replace the custom config with the default.
Hi,
When cPanel updated last night, our Exim configuration on all servers seems to have been reset. We received an email with the subject "Unable to automatically update the exim configuration".
I looked through the upcp log and found this:
It wasn't just the ACL settings that were reset. Also SECTION: AUTH, Postmailcount, Transportstart where reset, which means our MailChannels configuration was gone and a bunch of our customers emails where flagged as spam.
The only thing I can found about srs_config is in the backup of exim.conf:
What is the cause of this?
When cPanel updated last night, our Exim configuration on all servers seems to have been reset. We received an email with the subject "Unable to automatically update the exim configuration".
I looked through the upcp log and found this:
We haven't made any changes to srs_config, so I wonder why it's complaining about this setting.
It wasn't just the ACL settings that were reset. Also SECTION: AUTH, Postmailcount, Transportstart where reset, which means our MailChannels configuration was gone and a bunch of our customers emails where flagged as spam.
The only thing I can found about srs_config is in the backup of exim.conf:
It's not present in the new configuration on any of the new servers.
What is the cause of this?
Hello,
The specific change is noted in today's full disclosure of the recent security update:
Thank you.
The specific change is noted in today's full disclosure of the recent security update:
A "Exim Update Failures" notification should have been sent via the configured contact method (WHM >> Contact Manager) if your Exim configuration was reset or could not be modified. Custom Exim configurations are automatically reset if they conflict with the changes associated with critical Exim updates. Feel free to open a support ticket using the link in my signature if you need help applying the update or restoring specific custom changes to your Exim configuration file.
Thank you.
I suspect my Exim problem had to do with my having implemented SRS manually before the cPanel version was ready. As a result, some of my earlier SRS customizations conflicted with the cPanel version. The security key may have been part/all of the problem.
In any case, what I'm really asking here is whether it's wise to overwrite everything with the default configuration in case of a conflict like this. I didn't know there was a problem until I got the notice to the contact email, and by then, mail was already failing, because my custom config referenced an aliases file that Exim's default configuration didn't know about.
I managed shut down Exim and got everything fixed before restarting it, as far as I can tell, but I would have preferred that the update process let me know about the conflict instead of just proceeding and overwriting my customizations.
In any case, what I'm really asking here is whether it's wise to overwrite everything with the default configuration in case of a conflict like this. I didn't know there was a problem until I got the notice to the contact email, and by then, mail was already failing, because my custom config referenced an aliases file that Exim's default configuration didn't know about.
I managed shut down Exim and got everything fixed before restarting it, as far as I can tell, but I would have preferred that the update process let me know about the conflict instead of just proceeding and overwriting my customizations.
What exactly is required by us? Do we need to make any changes (other than revert the changes besides the srs_config setting)?
We had a similar incident where all the Exim configurations were reset.
I had to restore the Exim configurations from the backup and delete the hide srs_config before saving.
I had to restore the Exim configurations from the backup and delete the hide srs_config before saving.
I was just informed in my ticket that the development teams have already figured out what caused the issue and they are working on a fix.
For any others experiencing this issue, this will restore your previous customized configuration while still providing the benefit of the protections from the TSR update.
Specifically:
- Go to the "Restore" tab of the WHM Exim Configuration Manager
- Click the "Restore" link next to the configuration backup created by the update
- Click the "Edit" button to edit the configuration backup
- Scroll down to the section with the "hide srs_config" config option and click the trash icon to the right
- Click "Save" at the bottom of the configuration editor
Thank you.
