cPanel and WHM Administration
cPanel and WHM make a large shared-hosting stack approachable, but the control panel is not a replacement for systems administration. A dependable cPanel server still requires careful resource planning, mail and DNS knowledge, backup testing, security controls, and an understanding of what the automation is doing underneath.
cPanel and WHM Serve Different Audiences
| Interface | Primary audience | Typical work |
|---|---|---|
| cPanel | Hosting account owner | Domains, files, databases, email accounts, cron jobs, SSL status, and account-level metrics |
| WHM | Server administrator or reseller | Accounts, packages, services, DNS, transfers, backups, security policies, software configuration, and server health |
| Shell | System administrator | Logs, package management, filesystem repair, service control, scripting, and problems the interface cannot fully explain |
A good administrator knows which layer owns a setting. Editing an automatically generated service file directly may appear to solve a problem until cPanel rebuilds the configuration. Conversely, relying only on the interface can hide the log messages that reveal the actual cause.
Build the Server for Its Workload
Before installing the control panel, define the server’s role. A general-purpose shared server, a mail-heavy reseller server, and a high-traffic WordPress server may need different CPU, memory, disk, and account-density targets.
Pre-install decisions
- Use a supported operating-system release and a clean installation.
- Assign a permanent hostname with working forward and reverse DNS.
- Plan public and private IP use before accounts are created.
- Decide how backups leave the server.
- Confirm storage layout and free-space alerts.
- Establish out-of-band or console access before remote firewall changes.
- Document the intended PHP, database, web-server, and mail configuration.
Do not size only for average load
Shared servers experience overlapping peaks: backups run while customers publish content, mail queues grow during a campaign, malware scans read many small files, and log rotation competes with databases for disk I/O. Leave operational headroom for maintenance and recovery.
Treat the Account as a Lifecycle
An account is more than a username and disk quota. It connects domains, DNS zones, mailboxes, databases, certificates, logs, backups, and billing records.
Provisioning checklist
- Validate the order. Confirm ownership, payment, fraud checks, and acceptable-use fit.
- Select the package. Use a standard package rather than hand-editing every account.
- Create the account. Verify username, primary domain, contact email, IP assignment, and nameservers.
- Validate DNS and SSL. Confirm the expected records and certificate issuance path.
- Enroll operationally. Add the account or server to backups, monitoring, inventory, and documentation.
- Send a useful welcome message. Include nameservers, access URLs, support boundaries, and backup expectations.
Packages should express policy
Packages can standardize disk, bandwidth, email, databases, addon domains, and feature access. They should correspond to products the support team can explain. Avoid creating dozens of nearly identical packages that differ only because one customer requested a temporary exception.
Suspension and termination
Document what suspension changes, whether mail is accepted or rejected, how long terminated data is retained, and whether backup retention differs from live-account retention. A cancellation workflow should also remove monitoring, DNS dependencies, licenses, and stale inventory records.
Mail and DNS Are Usually the Hard Parts
Web content can often be copied and tested before a cutover. Mail and DNS involve outside systems, caches, reputation, and user devices. Many apparent “cPanel problems” are actually DNS or SMTP problems.
Mail operations to watch
- Outbound queue size and oldest-message age
- Repeated authentication failures
- Accounts sending far above their baseline
- Forwarders that generate backscatter or forwarding-reputation problems
- SPF, DKIM, DMARC, PTR, and hostname alignment
- Disk or inode exhaustion in mailbox storage
- Remote-provider deferrals and rate limits
Useful mail and DNS checks
# Review Exim's queue summary
exim -bp | exiqsumm
# Show the oldest queued messages first
exiqgrep -o 3600 -i | head
# Follow the main Exim log
tail -f /var/log/exim_mainlog
# Check authoritative DNS
dig @ns1.example.net example.com A
dig @ns1.example.net example.com MX
dig -x 203.0.113.25
# Test SMTP presentation and STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
Commands and log paths can vary with the platform and configuration. Confirm them on the server before incorporating them into a runbook.
Backups Need an Independent Destination
A backup stored only on the server it protects is a recovery convenience, not a disaster-recovery plan. cPanel’s backup configuration supports schedules, retention, account selection, system files, databases, and additional destinations. The operator must still verify that the destination receives complete backups and that restores work.
A practical cPanel backup pattern
- Keep a short local retention when space allows for fast customer restores.
- Transfer backups to a remote system or object-storage destination.
- Include system files needed to rebuild the server configuration.
- Monitor both backup creation and destination transfer.
- Test full-account, database-only, mailbox, and individual-file restores.
- Measure how much temporary staging space a restore requires.
Shared-Hosting Security Baseline
No single security feature protects a shared server. Use overlapping controls that limit credential abuse, vulnerable applications, cross-account exposure, and outbound damage.
Administrative access
- Use individual privileged accounts where possible.
- Require multi-factor authentication for control-panel administration.
- Restrict SSH and management access by policy and network controls.
- Store emergency access separately from daily credentials.
Account isolation
- Use supported account-isolation and resource-control features.
- Keep file ownership and permissions consistent.
- Do not allow writable shared locations without a documented reason.
- Review reseller privileges carefully.
Application risk
- Identify outdated CMS installations and extensions.
- Rate-limit outbound mail and suspicious login behavior.
- Use malware detection as an investigation signal, not an automatic truth source.
- Preserve evidence before deleting compromised files.
Platform maintenance
- Review update failures and repository health.
- Track certificate, license, and operating-system lifecycle dates.
- Keep a tested reboot procedure.
- Review Security Advisor findings, but understand each recommendation before applying it.
Troubleshoot from the Service Inward
Start with the user-visible failure, then move through DNS, network, listener, application, and data layers.
| Symptom | First checks | Likely layers |
|---|---|---|
| Website timeout | DNS, route, port 80/443 listener, load, firewall | Network, web server, PHP workers |
| HTTP 500 error | Domain error log, PHP log, permissions, application change | Application, PHP, filesystem |
| Database connection failure | Service status, socket/TCP path, grants, disk, connection count | Database, credentials, resources |
| Mail deferred | Exim log, queue reason, DNS, remote response, reputation | SMTP, DNS, policy |
| SSL mismatch | SNI hostname, DNS destination, installed certificate, proxy/CDN path | TLS, DNS, reverse proxy |
| Account at quota | Disk and inode use, mail folders, logs, backups, database size | Filesystem, mailbox, application |
Useful service checks
# cPanel service status summary
/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
# Listening sockets
ss -lntup
# Recent failed system units
systemctl --failed
Transfers and Migrations
WHM’s transfer tools can copy accounts, packages, and selected configuration from another server. The transfer is only one part of the migration. You still need to validate PHP compatibility, DNS behavior, mail routing, external services, licenses, and customer-specific assumptions.
Before the transfer
- Compare operating-system, cPanel, database, PHP, and application versions.
- Check destination disk space, including temporary extraction space.
- Inventory remote DNS, remote mail, dedicated IPs, custom nameservers, and external databases.
- Identify accounts too large for the normal migration window.
- Take a destination-side backup before overwriting any existing account.
After the transfer
- Review every warning and transfer log.
- Test websites using a hosts-file override or temporary hostname.
- Confirm mailboxes, forwarders, filters, autoresponders, and routing mode.
- Validate DNS zones rather than assuming they were copied correctly.
- Perform a final data synchronization when the migration method supports it.
- Keep the source intact until monitoring and customer validation are complete.