r/cpanel

Several days ago, csf on my VPS (cPanel 136.0.33, AlmaLinux 8) mysteriously went from 16.20 back to 14.24.

I've tried to return to the current fork by running sudo yum install cpanel-csf but the csf main page in WHM continues to display 14.24.

Has anyone else seen this, and if I'm not using the right command to fix it, please advise?

Thanks

https://support.cpanel.net/hc/en-us/articles/42694659893143-Security-Privilege-Escalation-via-Phusion-Passenger-s-Watchdog-API

Has anyone been able to update on CL8?

I cleaned DNF's cache and tried to update the packages, but there are no updates available for 6.1.8-2; my packages are stuck on version 6.1.8-1

I've been helping with a small web hosting business and spending more time looking at how people actually choose a cPanel provider.

One of the companies I'm working with is RSH Web Services, and one thing I've noticed is that having cPanel itself isn't really enough. People also care about reliability, how easy it is to manage multiple sites, how quickly issues get resolved, and what happens when a site needs to be migrated or restored.

The company also has services around hosting, including domains, WordPress hosting, SSL, and website management, so I'm looking at the overall experience rather than just the control panel.

What has been the biggest factor that made you stay with, or leave, a cPanel hosting provider?

This is more for people that have the same problem I had, hoping they can find this instead of spending hours panicking like I did.

I have a new VPS, using AlmaLinux v9.8.0 STANDARD kvm, cPanel Version 136.0.33.

I began to transfer a Wordpress site, but wasn't sure if it would work with the new version of PHP so I wanted to test run first. I used Transfer Tool, then de-selected:

Update DNS Zone 
Enable this setting to update DNS records on the destination server.

After the transfer I checked the DNS records on the old VPS and confirmed that they did not change.

Shortly thereafter, though, I discovered that an email sent to the client was rejected, and the bounce message noted that their email server was on the new VPS instead of the old one.

Then I looked at the live site and found that it was pointing to the new VPS!

It took about 3 hours to find that Transfer Tool modified the source VPS, anyway:

1. a ProxyPass record was added to httpd.conf (with a dash-delimited version of the IP, so a simple grep for the new IP didn't find it; eg, http://123-45-67-89); and

2. when I ran # exim -bt client@example.com (using the client's email address that had bounced), it returned the new VPS instead of the correct one: host new.vps.com [123.45.67.89]

The solutions were to run this to fix it in Apache:

whmapi1 unset_all_service_proxy_backends username=<account name>

then rebuild and restart Apache. Then run this for Exim (no restart required):

whmapi1 unset_manual_mx_redirects domain='<domain name for the account>'

I ran the one for Exim first before finding the problem in Apache, so running the first one MIGHT have fixed Exim, too.

This might be a feature instead of a bug, but I expected that when I disabled "Update DNS Zone" then it wouldn't change ANYTHING on the source VPS. I was wrong.

Hi Everyone,

I’m looking for some perspective and practical suggestions from the community.

We’re currently managing 200+ servers and use a jumpbox as the primary access point. I’d be interested to hear how others approach server management at this scale, particularly around auditing staff access and controlling privileged (root) access.

I’ve already looked at options such as Vauban, FreeIPA, LDAP-based solutions, PAM, and similar tools. I’m not searching for a ready-made drop-in replacement, but rather guidance and real-world approaches that others have found effective.

With the growing relevance of AI-driven threats and the shift toward Zero Trust models, securing root access and maintaining responsible operational practices feels increasingly important.

Any insights, architecture patterns, or lessons learned would be greatly appreciated.