cpanel overwrites files, very very bad

[docjones2]

Hello.

Cpanel has been overwriting system files, and it's been a minor inconvenience until now.

the hosts file, my exim.conf file and the /etc/init.d/exim file are all overwritten on a seemingly random basis (other files I'm sure too) and today my exim.conf was wiped which caused major downtime.

Well, I'm sick of this game now and I would like for cpanel to never overwrite another file again in this way again ever for ever. I have no use for this feature--and it's costing me a lot of money every time our server goes. It costs me a lot of bandwidth every time my hosts file is changed so as not to use private network ips, and it costs me a lot of time to have to keep changing these files back.

If this feature can not be turned off, what are the risks if any to my system of uninstalling cpanel?

 

[cPanelTristan]

These files are changed such as /etc/exim.conf due to the fact we have to control the exim configuration. We provide the WHM > Exim Configuration Editor > Advanced Editor to allow changes to that file without those changes being overwritten.

For Apache, we do the same where we provide include files and template files to be used where changes won't be overwritten on periodic updates.

As for the hosts file, I'm uncertain why that file would be written to unless you were changing the hostname on the machine periodically. What does the file look like and what line or lines keep getting removed?

 

[docjones2]

This is our hosts file

127.0.0.1               localhost localhost.localdomain storm
127.0.0.1               ourdotcom.com
127.0.0.1               ourhostname

To answer your question, yes, we change the hosts file very periodically. There are other entries that I did not include, it is usually just loopback ips that cause problems, however sometimes private ips get changed to public ones too.

And it is periodically changed so that the ourdotcom.com and ourhostname no longer point to loopback.

/etc/init.d/exim was modified so that queue runners would run more frequently than once an hour. That also gets reverted.

And I could have sworn I had already taken the appropriate measure to ensure /etc/exim.conf would not be overwritten, I added it to /etc/cpanelsync.exclude. This seemed to work well for about 2 weeks. And today I was started to find out that my email server had been running all day, doing no work whatsoever because /etc/exim.conf was overwritten.

I do not want to prevent cpanel from being able to write to the filesystem, indeed the interface is useful for [some] things, but I never want to see a surprise rewrite again, not even if cpanel does it for my "benefit." It does not benefit me at all to have any files overwritten unless I explicitly asked for it.

 

[Infopro]

You are free to set your update preferences to Never update, and then update manually when you have the time to make sure all goes well in a cPanel update and then edit back in any changes you need. cPanel updates are a way of life, just like any other software you use.

 

[cPanelKenneth]

The cpanelsync.exclude file is only used by the cpanelsync utility. The cpanelsync utility is what we use to download updated files from a cPanel mirror to a server. These files are downloaded to the /scripts and /usr/local/cpanel directories. Files and directories outside those two locations are not handled by cpanelsync, in general. Hence adding something like /etc/exim.conf to /etc/cpanelsync.exclude has no effect as /etc/exim.conf is not handled by cpanelsync.

In particular /etc/exim.conf is managed both by our Exim RPM and by /scripts/buildeximconf. The init script is handled by the Exim RPM and some other utility that isn't coming to mind atm. In the last couple weeks we've published several new Exim RPMs to fix various security holes in Exim. These updates are likely what caused your settings to be undone.

You should be able to use the /scripts/prebuildeximconf and /scripts/postbuildeximconf hook scripts to preserve your exim.conf modifications across updates.


The /etc/hosts modifications are performed by /scripts/fixetchosts which at this time does not provide a means of preventing execution. It gets executed by upcp.