If you’re tired of mySQL—or just want to run it on another machine—but are also unhappily married to cPanel, you might find yourself in quite a pickle with some of the latter’s recent updates. In an effort to be more helpful to someone, cPanel 11.25 includes a number of scripts which blindly assume mySQL is both running and available, and they contain no sort of error handling mechanism to deal with times when it is not. This means that even though you are able to disable the mySQL service through WHM, you’re not going to be able to actually disable it without some manual intervention.
Here’s a brief rundown of the mySQL dependent garbage cPanel installs:
- LeechProtect
-
Nobody likes image leeches, but nobody likes unspeakably lengthy Perl scripts that get executed every single time Apache fields a request, either. Unfortunately for you, dear cPanel user, your httpd.conf file contains a line that looks something like this:
RewriteMap LeechProtect prg:/usr/local/cpanel/bin/leechprotectFor some reason, this script needs mySQL to do its job for it. I have no idea why, and I don’t care to find out; I just want it gone.
There are two plans of attack here: we can either comment out the line in httpd.conf, or we can comment out the contents of the script so it no longer does anything. I prefer to comment out the line, myself, since that will prevent mod_rewrite from being invoked unnecessarily, but whichever approach you take, keep in mind that your change will be obliterated the next time you update anything through cPanel. Keep these directories under version control at all times so you know when they’ve been touched.
- modsecparse.pl
-
ModSecurity is a great little module, and I highly recommend that you consider installing it. While I’m glad that cPanel offers to build it for you, I’m less glad about the absolutely useless Perl script they install along with it: modsecparse.pl.
This piece of shit lives in your /etc/cron.hourly directory and seems to be in charge of archiving the contents of all your ModSecurity logs in a secret mySQL database. Once again, I have no idea why anyone would want this to be done, and if you are of a similar mind, just delete the Perl file and it won’t run no more. At least, not until you install another cPanel update. Did I mention keeping these directories under version control? It’s a great idea.
Once the file’s gone, you will suddenly be in charge of rotating your own ModSecurity logs, so make sure you create appropriate entries for this in your logrotate config (or whatever rotation system your operating system comes bundled with) lest you end up with a disk full of garbage.
- optimizefs
-
Our final gremlin is a compiled tool which tries to speed things up by telling the filesystem not to record modification times for files contained in certain directories. Since it is not a human-readable interpreted script, we may never know why it needs to talk to mySQL to do its job, but it certainly thinks it does, and it likes to complain to stderr about it every time its cron job runs.
Simply add "> /dev/null 2>&1" to the end of its line in root’s crontab, and it’ll shut up. You can probably dump the job entirely without any ill-effects, but I don’t want to advocate such a thing without some hard evidence that its published documentation’s description of its purpose is accurate.
With all that nonsense out of the way you can now go on about your business without mySQL stinking up the joint. I believe that cPanel’s backup system will still gripe about what you’ve done in some way, but I stopped using that years ago; you should probably suggest that your users do the same.
While you’re at it, you should also keep an eye on Apache’s error logs after updating to 11.25 and see just how often cPanel’s extremely stupid log rotation system is sending out graceful restart requests. They can be pretty problematic if you’re running mod_passenger.