Centos Web Panel

A reference of the most useful command-line operations for administering a CentOS Web Panel (CWP) server.

CWP Service Management

# Restart the CWP control panel web server:
service cwpsrv restart

# Reload CWP panel web server (config changes):
service cwpsrv reload

# Restart CWP PHP-FPM (used by admin/user panels, phpMyAdmin, Roundcube):
service cwp-phpfpm restart

SSL Certificate Management

# Generate/renew the hostname SSL certificate:
sh /scripts/generate_hostname_ssl

# Force AutoSSL renewal for all domains:
sh /scripts/autossl

Web Server Controls

# Test Apache configuration:
apachectl -t

# Restart Apache:
service httpd restart

# Restart Nginx:
service nginx restart

CWP Updates

# Update CWP to the latest version:
sh /scripts/update_cwp

# Update CWP PHP packages:
yum update cwpphp --enablerepo=cwp

Notes

• All commands require root access.
• CWP auto-starts services on boot; use systemctl enable <service> to manage startup behaviour for custom services.
• CWP forum reference: http://forum.centos-webpanel.com

If SSL certificates are expiring despite auto-renewal being enabled, the old Let's Encrypt Manager may be in use instead of CWP's AutoSSL. This guide migrates you to AutoSSL and sets up automatic renewal.

Prerequisites

• Root SSH access
• CWP with AutoSSL available (any recent version)

Steps

1. Uninstall the legacy Let's Encrypt Manager if shown as "NOT IN USE ANYMORE":

yum remove letsencrypt -y

2. Switch to AutoSSL:
In the CWP Admin Panel go to SSL Certificates → AutoSSL and enable it for the domain.

3. Force an immediate renewal:

sh /scripts/autossl

4. Verify the renewal cron job is in place:

crontab -l | grep autossl

If missing, add it:

(crontab -l; echo "0 3 * * * sh /scripts/autossl >> /var/log/autossl.log 2>&1") | crontab -

5. Confirm the certificate is renewed:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Verify

# The notAfter date should be 90 days from today:
openssl s_client -connect yourdomain.com:443 /dev/null   | openssl x509 -noout -enddate

Notes

• AutoSSL creates its own cron job; do not run both the old LE manager and AutoSSL simultaneously.
• Renewal attempts are logged to /var/log/autossl.log.
• Certificates renew 30 days before expiry by default.

A reference of frequently encountered errors in CentOS Web Panel and their solutions.

Prerequisites

• Root SSH access
• Familiarity with basic Linux file permission commands

Error: UID of script is smaller than min_uid

SoftException in Application.cpp:350: UID of script "/home/username/public_html/index.php" is smaller than min_uid

Fix: The PHP script is running under a UID below the configured minimum. Fix file ownership via CWP or from the command line:

chown -R username:nobody /home/username/public_html/

Error: End of script output before headers

[core:error] End of script output before headers: index.php

Fix: PHP is crashing before producing output. Check the domain error log and fix permissions:

cat /usr/local/apache/domlogs/domain_name.error.log
chmod 755 /home/username/public_html/
chmod 644 /home/username/public_html/index.php

Error: Permission Denied (403)

/home/username/public_html/index.php is forbidden (13: Permission denied)

Fix: The public_html directory must be owned by username:nobody:

chown username:nobody /home/username/public_html/
chmod 750 /home/username/public_html/

Error: Internal Server Error (500)

Fix: Check the domain error log for the actual cause:

tail -50 /usr/local/apache/domlogs/domain_name.error.log

Log File Locations

# Apache error log per domain:
/usr/local/apache/domlogs/<domain_name>.error.log

# Apache access log per domain:
/usr/local/apache/domlogs/<domain_name>

# CWP panel log:
/usr/local/cwpsrv/logs/error.log

Notes

• Always fix ownership via the CWP UI (User Accounts → Manage) where possible, as it handles all related paths.
• After fixing permissions, clear any opcode cache: service cwp-phpfpm restart.

A reference of key configuration file paths and service reload commands for CentOS Web Panel components.

Prerequisites

• Root SSH access

CWP Panel Web Server (cwpsrv)

Used for: CWP Admin panel, CWP User panel, phpMyAdmin, Roundcube.

Config:  /usr/local/cwpsrv/conf/
         /usr/local/cwpsrv/conf.d/
Reload:  service cwpsrv reload

CWP PHP-FPM (cwp-phpfpm)

PHP engine for the CWP panel itself.

Config:  /usr/local/cwp/php71/php.ini
         /usr/local/cwp/php71/php.d/
Reload:  service cwp-phpfpm reload

phpMyAdmin

PHP config: /usr/local/cwp/php71/php.ini
Web root:   /usr/local/cwpsrv/htdocs/phpmyadmin/

Apache

Config:     /usr/local/apache/conf/httpd.conf
            /usr/local/apache/conf.d/
VHost conf: /usr/local/apache/conf.d/vhosts/<domain>.conf
Domlogs:    /usr/local/apache/domlogs/
Htdocs:     /usr/local/apache/htdocs/index.html  (default page)
Reload:     service httpd restart

Nginx

Config:  /usr/local/nginx/conf/nginx.conf
         /usr/local/nginx/conf/conf.d/
Reload:  service nginx restart

MySQL / MariaDB

Config:  /etc/my.cnf
Data:    /var/lib/mysql/
Reload:  service mysqld restart

CSF Firewall

Config:  /etc/csf/csf.conf
Reload:  csf -r

Notes

• Always test Apache config with apachectl -t before restarting.
• Always test Nginx config with nginx -t before restarting.
• CWP stores the MySQL root password in /root/.my.cnf and /usr/local/cwpsrv/htdocs/resources/admin/include/db_conn.php.

This guide covers how to configure HTTP-to-HTTPS redirects and rewrite rules in CWP using both Apache and Nginx configuration methods.

Prerequisites

• Root or domain-level SSH/FTP access
• A valid SSL certificate installed for the domain

Apache — HTTP to HTTPS Redirect via .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Apache — HTTP to HTTPS Redirect via VHost Config

Add to the domain's Apache site config (/usr/local/apache/conf.d/vhosts/example.com.conf):

<VirtualHost *:80>
    ServerName example.com
    Redirect / https://example.com/
</VirtualHost>

Nginx — HTTP to HTTPS Redirect

Add a server block in /usr/local/nginx/conf/conf.d/example.com.conf:

server {
    listen 80;
    server_name example.com www.example.com;
    location / {
        return 301 https://example.com$request_uri;
    }
}

Apache — Non-www to www Redirect

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Verify

curl -I http://example.com/
# Expected: HTTP/1.1 301 Moved Permanently
# Location: https://example.com/

Notes

• After editing Apache config files, run apachectl -t before restarting.
• After editing Nginx config files, run nginx -t before restarting.
• Use R=301 (permanent) for production redirects; use R=302 (temporary) when testing.

CWP ships with Roundcube as its webmail client. You can replace logos and adjust branding for white-label deployments. Changes must be reapplied after CWP updates using the auto-update script.

Prerequisites

• Root SSH access
• Replacement logo files prepared (PNG format, matching the dimensions of originals)

Steps

1. Locate the Roundcube skin directory:

ls /usr/local/cwpsrv/var/services/roundcube/skins/

2. Replace the logo file:

cp /root/my-logo.png /usr/local/cwpsrv/var/services/roundcube/skins/elastic/images/logo.png

3. Edit the Roundcube configuration to set a custom product name:

nano /usr/local/cwpsrv/var/services/roundcube/config/config.inc.php

$config['product_name'] = 'My Company Webmail';

4. To persist branding across CWP updates, create an auto-update script:

nano /root/.cwp_autoupdate.sh

#!/bin/bash
# Restore custom Roundcube logo after CWP update
cp /root/my-logo.png /usr/local/cwpsrv/var/services/roundcube/skins/elastic/images/logo.png

chmod +x /root/.cwp_autoupdate.sh

CWP automatically runs this script after each update.

Verify

Open https://yourdomain.com:2096 (or the Roundcube URL) in a browser and confirm the custom logo appears.

Notes

• Image dimensions should match the originals to avoid layout issues.
• Clear browser cache after changes to see the updated logo.

CWP supports a post-update hook script that runs automatically after each CWP update. Use it to restore custom branding, configuration overrides, or any files that CWP overwrites during updates.

Prerequisites

• Root SSH access

Steps

1. Create the hook script:

nano /root/.cwp_autoupdate.sh

2. Add your custom commands. Example — restore a custom logo:

#!/bin/bash

# Remove the immutable flag from the theme directory:
chattr -i -R /usr/local/cwpsrv/var/services/users/cwp_theme/original/img/

# Copy your custom logo:
cp /root/my/new_logo_small.png   /usr/local/cwpsrv/var/services/users/cwp_theme/original/img/new_logo_small.png

# Suppress login page logo via CSS:
chattr -i /usr/local/cwpsrv/htdocs/admin/design/images/login.css
echo ".login h1 { display: none; }" >>   /usr/local/cwpsrv/htdocs/admin/design/images/login.css

3. Make the script executable:

chmod +x /root/.cwp_autoupdate.sh

4. Test the script manually:

sh /root/.cwp_autoupdate.sh

Verify

Run a CWP update and confirm that your customizations persist afterwards:

sh /scripts/update_cwp

Notes

• CWP detects the script by its exact name and path: /root/.cwp_autoupdate.sh.
• The script runs as root — validate it carefully before deploying.
• Keep the script minimal; complex logic should call separate scripts stored in a safe location such as /root/scripts/.

If a domain was first used as the server hostname and then added as a CWP account, Apache may still serve the hostname's SSL certificate for that domain. This guide explains how to identify and fix the conflicting configuration.

Prerequisites

• Root SSH access
• A valid SSL certificate installed for the domain (not just the hostname)

Steps

1. Identify which Apache config files still reference the domain as the ServerName:

grep -r "ServerName.*yourdomain.com" /usr/local/apache/conf/
grep -r "ServerName.*yourdomain.com" /etc/httpd/conf.d/

2. Check the SSL vhost configs for the hostname:

grep -r "SSLCertificate" /usr/local/apache/conf/ | grep -i hostname

3. Edit the conflicting vhost config and update or remove the stale ServerName directive:

nano /usr/local/apache/conf.d/<conflicting-config>.conf

Update ServerName to the current hostname, or remove the entire stale vhost block if it is no longer needed.

4. Test and restart Apache:

apachectl -t
service httpd restart

Verify

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null   | openssl x509 -noout -subject
# Subject should show CN=yourdomain.com, not the hostname

Notes

• This issue occurs when the hostname is changed after the domain account is created.
• After fixing, also verify the Nginx SSL config is not similarly misconfigured: grep -r "ssl_certificate" /usr/local/nginx/conf/.

If long-running PHP scripts or large file uploads produce 504 Gateway Timeout errors even after raising PHP's max_execution_time, the Apache timeout also needs to be increased. This guide covers both PHP-CGI and PHP-FPM setups.

Prerequisites

• Root SSH access
• CWP with Apache

Steps — PHP-CGI SAPI

1. Create a custom Apache timeout config file:

echo "TimeOut 3600" > /usr/local/apache/conf.d/timeout.conf

2. Restart Apache:

service httpd restart

Steps — PHP-FPM SAPI

1. Add the timeout to the main Apache config or a conf.d file:

echo "TimeOut 3600" >> /usr/local/apache/conf/httpd.conf

2. Also set the ProxyTimeout for requests forwarded to PHP-FPM:

echo "ProxyTimeout 3600" >> /usr/local/apache/conf/httpd.conf

3. Set PHP-FPM request_terminate_timeout:

nano /etc/php-fpm.d/www.conf

request_terminate_timeout = 3600

4. Restart both services:

apachectl -t && service httpd restart
service php-fpm restart

Verify

curl -o /dev/null -w "%{time_total}
" https://yourdomain.com/long-running-script.php

Notes

• Also raise max_execution_time and max_input_time in PHP ini to match the Apache timeout value.
• Timeouts beyond 3600 s (1 hour) are unusual — consider whether the application logic needs optimizing.
• If Nginx is in front of Apache, also add proxy_read_timeout 3600; to the Nginx config.

CWP installs Node.js via the NodeSource repository. When upgrading to a new major version, the old repository definition must be removed first to avoid conflicts.

Prerequisites

• Root SSH access
• CWP on CentOS 7 or compatible RHEL-based OS

Steps

1. Remove the old NodeSource repository definition:

rm -f /etc/yum.repos.d/nodesource-el*

2. Add the NodeSource repository for the desired version (e.g., Node.js 18):

curl -sL https://rpm.nodesource.com/setup_18.x | bash -

3. Install Node.js:

yum install -y nodejs

4. Verify the installed version:

node --version
npm --version

Verify

which node
node -e "console.log('Node.js is working')"

Notes

• Replace setup_18.x with the desired major version number (e.g., setup_20.x for Node.js 20).
• After upgrading, rebuild any native npm modules for the new Node.js version: npm rebuild.
• Global npm packages installed under the old version need to be reinstalled.

The Apache error code 70007 (AH00524) means that a handler — typically PHP via CGI or FPM — took too long to respond and the connection was aborted by the client or server. This manifests as ERR_CONNECTION_ABORTED in browsers.

Prerequisites

• Root SSH access
• CWP on CentOS 7

Steps

1. Confirm the error in Apache logs:

grep "AH00524\|70007" /usr/local/apache/domlogs/yourdomain.com.error.log

2. Increase Apache timeout (the most common fix):

echo "TimeOut 600" > /usr/local/apache/conf.d/timeout.conf
echo "ProxyTimeout 600" >> /usr/local/apache/conf.d/timeout.conf

3. Increase PHP limits in the domain's PHP ini or in CWP PHP Selector:

upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 600
max_input_time = 600

4. If ModSecurity is enabled, check if it is blocking or timing out the request:

grep "yourdomain.com" /usr/local/apache/logs/modsec_audit.log | tail -30

Temporarily disable ModSecurity for the domain to test:

# In the domain .htaccess:
SecFilterEngine Off

5. Restart Apache after changes:

apachectl -t && service httpd restart

Verify

curl -v https://yourdomain.com/wp-admin/theme-install.php 2>&1 | grep -E "HTTP|timeout"

Notes

• This error most commonly occurs during large file uploads (themes, plugins, media) or long database operations.
• If Nginx is in front of Apache, also increase proxy_read_timeout and client_max_body_size in the Nginx config.

The curl version bundled with CentOS/RHEL receives security backports but not new feature releases. If you need a newer curl build, use the city-fan.org or IUS repository.

Prerequisites

• Root SSH access
• CentOS 7 or RHEL 7/8

Steps — CentOS 7 via city-fan.org repo

1. Install the city-fan.org repository (provides up-to-date curl builds):

rpm -Uvh https://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/city-fan.org-release-2-1.rhel7.noarch.rpm

2. Install curl with multilibs support:

yum install -y --enablerepo=city-fan.org curl libcurl libcurl-devel

Steps — Build from source (any version)

1. Install build dependencies:

yum groupinstall -y "Development Tools"
yum install -y openssl-devel

2. Download and build curl:

cd /usr/local/src
curl -LO https://curl.se/download/curl-8.7.1.tar.gz
tar -xzf curl-8.7.1.tar.gz
cd curl-8.7.1
./configure --prefix=/usr/local --with-ssl
make -j$(nproc)
make install

3. Update the dynamic linker cache:

ldconfig
echo "/usr/local/lib" > /etc/ld.so.conf.d/curl.conf
ldconfig

Verify

curl --version
# Expected output shows the new version number

Notes

• System packages that link against libcurl may need to be rebuilt or will use the OS-bundled version — use ldd $(which curl) to confirm which library is in use.
• Replace 8.7.1 in the source build steps with the desired version from https://curl.se/download/.

MySQL failing to start in CWP typically manifests as a lock file error and can render the CWP panel itself inaccessible. This guide covers the most common causes and fixes.

Prerequisites

• Root SSH access (panel login may be unavailable)

Steps

1. Check the error and lock file state:

service mysqld status
ls -lh /var/lock/subsys/mysql

2. Remove stale lock and socket files:

rm -f /var/lock/subsys/mysql
rm -f /var/lib/mysql/mysql.sock
rm -f /tmp/mysql.sock

3. Verify the data directory ownership:

ls -ld /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql/

4. Attempt to start MySQL:

service mysqld start
# or for MariaDB:
service mariadb start

5. If it still fails, check the MySQL error log:

tail -50 /var/log/mysqld.log
# or:
journalctl -u mysqld --since "30 minutes ago"

6. Retrieve the MySQL root password (stored by CWP):

cat /root/.my.cnf
cat /usr/local/cwpsrv/htdocs/resources/admin/include/db_conn.php | grep pass

7. Restart CWP after MySQL is running:

service cwpsrv restart

Verify

service mysqld status
mysql -u root -p -e "SHOW DATABASES;"

Notes

• A disk full condition is a common cause of MySQL start failure — check with df -h.
• InnoDB corruption may require innodb_force_recovery in /etc/my.cnf — set to 1–6 incrementally to recover.

ConfigServer Security & Firewall (CSF) and its companion Login Failure Daemon (LFD) are installed by default on CWP servers. This guide covers the most useful CSF commands.

Prerequisites

• Root SSH access
• CSF installed (default on CWP)

Help and Configuration

# List all options:
csf --help
man csf

# Main config file:
/etc/csf/csf.conf

# IP allow/deny lists:
/etc/csf/csf.allow
/etc/csf/csf.deny

Firewall Control

# Enable CSF (activates iptables rules):
csf -e

# Disable CSF (flushes iptables rules):
csf -x

# Restart CSF (reload iptables rules):
csf -r

# Restart CSF and LFD:
csf -ra

# Restart LFD only:
service lfd restart

IP Management

# Block an IP permanently:
csf -d <IP>

# Block an IP temporarily (e.g., 24 hours = 86400 seconds):
csf -td <IP> 86400

# Unblock an IP:
csf -dr <IP>

# Allow an IP (whitelist, all ports):
csf -a <IP>

# Remove IP from whitelist:
csf -ar <IP>

Diagnostics

# Check why an IP is blocked:
csf -g <IP>
grep "<IP>" /var/log/lfd.log

# View all currently blocked IPs:
csf -l

# Check firewall status:
csf -s

Verify

# Confirm iptables rules are active:
iptables -L INPUT -n | head -20

Notes

• Whitelist your own management IP before enabling strict rules: csf -a <your_IP>.
• Edit /etc/csf/csf.conf and set TESTING = "0" to make rules permanent across restarts.
• LFD monitors logs and auto-blocks IPs that exceed login failure thresholds.

When the CWP panel shows "The encoded file .../cron.php has expired", the CWP PHP files have passed their licence expiry date. Updating the CWP packages resolves the error.

Prerequisites

• Root SSH access (the admin panel may be unavailable)
• Internet access from the server

Steps

Option A — Update via yum:

yum update cwpphp --enablerepo=cwp

Option B — Manual update for EL7/EL8 (CentOS 7, AlmaLinux, Rocky Linux, Oracle Linux):

For CWP Admin:

chattr -i -R /usr/local/cwpsrv/htdocs/admin/
cd /usr/local/cwpsrv/htdocs
wget static.cdn-cwp.com/files/cwp/el7/cwp-el7-0.9.8.1148.zip
unzip -o -q cwp-el7-0.9.8.1148.zip
rm -f cwp-el7-0.9.8.1148.zip

For CWP User Panel:

chattr -i -R /usr/local/cwpsrv/var/services/
cd /usr/local/cwpsrv/var/services/
wget static.cdn-cwp.com/files/cwp/el7/cwp-services.zip
unzip -o -q cwp-services.zip
rm -f cwp-services.zip

Run the CWP update script after extracting files:

sh /scripts/update_cwp

Restart the CWP panel service:

service cwpsrv restart

Verify

# Access the CWP admin panel in a browser:
# https://yourdomain.com:2030
# The error message should no longer appear.

Notes

• Check the CWP website for the latest zip filename before running the manual download; the version string in the URL changes with each release.
• The chattr -i -R command removes immutable flags that CWP sets to protect its files — this is required before replacing them.
• Keep CWP updated regularly to avoid expiry errors: sh /scripts/update_cwp.