cPanel and WHM Administration

cPanel and WHM make a big shared-hosting stack approachable, and I'm glad they exist. But running a good cPanel server takes more than clicking through WHM and hoping the defaults are sensible. You still need to plan resources, understand mail and DNS, test backups, lock things down, and know what the automation is doing under the hood.

cPanel vs. WHM vs. the shell

The trick is knowing which layer owns a setting. Edit a generated config file by hand and it'll look fixed, right up until cPanel rebuilds it and your change disappears. Go the other way and only use the GUI, and you'll never see the log line that tells you what's actually wrong.

Build the server for what it's going to do

Before installing anything, decide what the server is for. A general shared server, a mail-heavy reseller box, and a server full of busy WordPress sites all want different CPU, RAM, disk, and how many accounts you put on them.

Decide before you install

• A supported OS release, installed clean.
• A permanent hostname with working forward and reverse DNS.
• Your IP plan, before any accounts exist.
• How backups are going to leave the server.
• The disk layout, and free-space alerts.
• Out-of-band or console access, before you touch the firewall remotely.
• Which PHP, database, web server, and mail setup you're going with, written down.

Don't size for the average

Shared servers get overlapping peaks. Backups run while people are publishing, mail queues balloon during someone's newsletter, malware scans read millions of tiny files, and log rotation fights the databases for disk. Leave room for maintenance and recovery, not just a normal Tuesday.

The life of an account

An account isn't just a username and a quota. It ties together domains, DNS, mailboxes, databases, certificates, logs, backups, and billing.

Setting one up

1. Check the order. Payment, fraud checks, and whether it fits your acceptable-use policy.
2. Pick a standard package. Don't hand-tune every account.
3. Create it. Double-check the username, primary domain, contact email, IP, and nameservers.
4. Check DNS and SSL. Make sure the records are right and the certificate can actually be issued.
5. Hook it into operations. Backups, monitoring, inventory, docs.
6. Send a welcome email people can use. Nameservers, login URLs, what you do and don't support, and what to expect from backups.

Packages are policy

Packages standardize disk, bandwidth, email, databases, addon domains, and features. Each one should match a product your support team can explain in a sentence. Avoid ending up with forty nearly identical packages because each one started as somebody's "temporary" exception.

Suspension and cancellation

Write down what suspension actually does (is mail still accepted, or bounced?), how long you keep data after termination, and whether backups are kept longer than the live account. Cancellation should also clean up monitoring, DNS, licenses, and inventory, not just the account itself.

Mail and DNS are the hard parts

You can usually copy and test website files ahead of time. Mail and DNS involve the rest of the Internet: other people's servers, caches, reputation, and everyone's phones. A lot of what looks like a "cPanel problem" is really a DNS or SMTP problem.

Mail things I keep an eye on

• Outbound queue size, and how old the oldest message is
• Repeated failed logins
• Accounts suddenly sending way more than usual
• Forwarders that bounce spam back out (backscatter) or hurt reputation
• SPF, DKIM, DMARC, PTR, and the hostname all lining up
• Mailbox storage running out of space or inodes
• Big providers deferring or rate-limiting you

Commands I use

# Summary of what's in the Exim queue
exim -bp | exiqsumm

# Messages that have been sitting there over an hour
exiqgrep -o 3600 -i | head

# Watch the main Exim log
tail -f /var/log/exim_mainlog

# Ask the authoritative server directly
dig @ns1.example.net example.com A
dig @ns1.example.net example.com MX
dig -x 203.0.113.25

# Check SMTP and STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
    

Paths and commands can differ between setups, so double-check them on your own server before putting them in a runbook.

Backups need to leave the building

A backup that only lives on the server it's backing up is a convenience, not disaster recovery. cPanel's backup config handles schedules, retention, which accounts, system files, databases, and extra destinations. It's still on you to make sure complete backups actually arrive and that you can restore them.

What I'd set up

• A short local retention, if there's room, for quick restores.
• Copies to a remote server or object storage.
• The system files you'd need to rebuild the server's config.
• Monitoring on both the backup job and the transfer to the remote side.
• Test restores: a whole account, just a database, a mailbox, a single file.
• Know how much temporary space a restore needs. Big accounts need a lot.

Security on a shared server

There's no single setting that protects a shared server. You stack controls that limit stolen passwords, vulnerable apps, accounts poking at each other, and damage going out to the Internet.

Troubleshooting from the outside in

Start with what the customer sees, then work inward: DNS, network, the service listening, the app, the data.

Quick service checks

# cPanel service status
/usr/local/cpanel/scripts/restartsrv_cpsrvd --status
/usr/local/cpanel/scripts/restartsrv_httpd --status
/usr/local/cpanel/scripts/restartsrv_exim --status
/usr/local/cpanel/scripts/restartsrv_mysql --status

# Disk and inode pressure
df -h
df -i
du -x -h --max-depth=1 /home | sort -h

# What's listening
ss -lntup

# Anything systemd thinks has failed
systemctl --failed
    

Don't forget df -i. Running out of inodes looks exactly like running out of disk, except df -h says you've got plenty of space.

Transfers and migrations

WHM's Transfer Tool can copy accounts, packages, and some config from another server, and it's genuinely good. But the transfer is only part of a migration. You still have to check PHP compatibility, DNS, mail routing, outside services, licenses, and whatever assumptions each customer's setup is quietly making.

Before

• Compare OS, cPanel, database, PHP, and app versions between old and new.
• Make sure the new server has room, including temporary space to unpack accounts.
• List out remote DNS, remote mail, dedicated IPs, custom nameservers, and external databases.
• Find the accounts that are too big for a normal migration window.
• Back up the destination before overwriting any account that already exists there.

After

• Read every warning in the transfer logs.
• Test sites with a hosts file override or a temporary hostname.
• Check mailboxes, forwarders, filters, autoresponders, and the mail routing setting.
• Check the DNS zones. Don't just assume they came over right.
• Do a final sync if your method supports it.
• Leave the old server alone until monitoring and customers say everything's good.

Official docs

• cPanel & WHM Backup Configuration
• WHM Transfer Tool
• Transfer or Restore a cPanel Account
• cPanel & WHM Documentation

Related: planning a low-downtime migration and backups and disaster recovery.