Managing multiple PHP versions on CWP can sometimes be difficult, especially when dependency issues involving zlib, libzip, PCRE2, GD, or other libraries cause normal PHP builds to fail.

The AlphaGNU Standalone CLI CWP PHP Build Manager provides a simple alternative: build PHP directly from official PHP source while maintaining CWP-compatible PHP layouts.

Why use it?

If PHP installation is failing on a server because of dependency or repository problems, this manager can be used to quickly build and install the required PHP version without relying on CWP's PHP build scripts or Remi PHP packages.

It supports:

• PHP 7.4.x through PHP 8.5.x

• PHP Selector

• PHP-FPM

• PHP Switcher

• Multiple PHP versions in one command

• One-line CLI installation

• PIE extension installation

• Dedicated PHP 8.5 runtime for PIE

• Automatic dependencies for extensions such as Redis, Memcached and Imagick

Installation/Update

This script will install the latest PHP even if it is not released in the CWP repository; it will download it from php.net when you specify the version during installation.

Download the latest package:

Install it:

rm -rf /root/php-manager
mkdir -p /root/php-manager
cd /root/php-manager
wget https://www.alphagnu.com/upload/cwp-php-manager/cwp_php_manager_alphagnu_v2.zip
unzip cwp_php_manager_alphagnu_v2.zip
chmod +x install.sh bin/*
./install.sh
sed -i -E '/^[[:space:]]*extension_dir[[:space:]]*=[[:space:]]*["'\'']\/usr\/local\/lib\/php\/extensions\/no-debug-non-zts-[0-9]+["'\''][[:space:]]*$/ s/^/;/' /usr/local/php/php.ini  

Verify:

php-manager --help

Start the interactive menu:

php-manager

Build PHP Versions

PHP Selector

Build multiple versions:

php-manager selector 7.4.33 8.2.29 8.3.8 8.4.25 8.5.10

Installed under:

/opt/alt/phpXY/usr/

PHP-FPM Selector

php-manager fpm 7.4.33 8.2.29 8.3.8 8.4.25 8.5.10

Installed under:

/opt/alt/php-fpmXY/usr/

PHP Switcher

Switcher uses one exact version:

php-manager switcher 8.5.10

Installed under:

/usr/local/php/

Dedicated PHP Runtime for PIE

The manager includes a separate PHP 8.5 CLI runtime exclusively for PIE. The first time you run the PIE installer, it will take some time because PHP will be built.

It is installed at:

/usr/local/php-pie/

Build or verify it with:

php-manager pie-runtime 8.5.10

Verify:

/usr/local/php-pie/bin/php -v

This runtime does not replace the server's default PHP and does not create an FPM service.

Install PHP Extensions with PIE

You can find available PHP extension package names by visiting:

https://packagist.org/extensions

Search for the extension you want to install and use its PIE package name.

Install an Extension for PHP-FPM

For example, install Memcached for PHP-FPM 7.4:

php-manager pie 7.4 php-memcached/php-memcached fpm

Redis:

php-manager pie 7.4 phpredis/phpredis fpm

Imagick:

php-manager pie 7.4 imagick/imagick fpm

APCu:

php-manager pie 7.4 apcu/apcu fpm

You can also specify the exact PHP version:

php-manager pie 7.4.33 imagick/imagick fpm

When using only the major/minor version, such as 7.4, PHP Manager automatically detects the installed PHP 7.4.x version.

Install an Extension for Multiple PHP Versions

You can install the same extension for multiple PHP versions in a single command:

php-manager pie 8.0 8.1 8.2 8.3 8.4 8.5 imagick/imagick fpm

The manager resolves each minor version to the corresponding installed PHP version and installs the extension for each target.

Install an Extension for All PHP Versions

To install an extension for all installed PHP versions across all three PHP managers, use:

php-manager pie all imagick/imagick

You can also restrict all to a specific PHP manager:

php-manager pie all imagick/imagick fpm

php-manager pie all imagick/imagick selector

php-manager pie all imagick/imagick switcher

PHP Manager Targets

Use the following target names:

For example:

php-manager pie 8.3 imagick/imagick fpm

installs Imagick for the installed PHP 8.3.x PHP-FPM Selector version.

php-manager pie 8.3 imagick/imagick selector

installs Imagick for the installed PHP 8.3.x PHP Selector version.

php-manager pie 8.3 imagick/imagick switcher

installs Imagick for the installed PHP 8.3.x PHP Switcher version.

PIE Runtime

PIE runs using the dedicated PHP 8.5 runtime:

/usr/local/php-pie/bin/php

The PIE runtime is separate from the PHP Selector, PHP-FPM Selector, and PHP Switcher installations.

The extension is compiled against the selected target PHP version using that target's own:

phpize
php-config

This allows the dedicated PIE runtime to build extensions for the selected PHP installation while keeping the existing PHP Manager installations separate.

Quick PHP Recovery / Alternative Build Method

On some servers, the standard CWP PHP build process can fail because of dependency problems such as:

• zlib

• libzip

• PCRE2

• GD libraries

• incompatible system development packages

Instead of spending time troubleshooting the CWP build wrapper, you can use AlphaGNU PHP Manager to build the required PHP version directly from the official PHP source.

For example:

php-manager fpm 8.3.8

or:

php-manager selector 8.3.8

This makes the manager useful not only for installing additional PHP versions, but also as a quick alternative when the normal CWP PHP build process is blocked by dependency issues.

Summary

AlphaGNU PHP Manager provides a standalone way to manage PHP versions on CWP-compatible servers without depending on CWP's PHP build wrapper scripts or Remi repositories.

It supports:

PHP Selector
PHP-FPM
PHP Switcher
PIE Extensions
Dedicated PHP 8.5 PIE Runtime
Multiple PHP Versions
One-Line Builds

For servers where normal PHP builds are failing due to dependency problems, it provides a practical and faster alternative for getting the required PHP version installed.

Check:

A critical vulnerability was found in the MESSENGER service in the ConfigServer Firewall (CSF) software which could allow for unauthorized code execution.
An insecure Apache configuration in ConfigServer Security & Firewall maps /usr/bin as CGI programs through the Messenger v3 HTTPS virtual host. A remote unauthenticated attacker whose address is blocked can request a mapped executable and run arbitrary commands as the Apache user. The vulnerability affects installations where CSF Messenger v3 and its HTTPS mode are enabled. WebPros (Cpanel team) addressed the vulnerability in version 16.31.

This has a public CVE record listed with further information: CVE-2026-67402

Note: By default, the MESSENGER service is disabled.

Affected Product versions:
Product: csf

Affected Versions: CSF 16.30-1 and older

Patched Versions: 16.31+

Impact:
Exploiting this could allow an attacker to execute code as the Apache user.

Mitigation:

It is highly recommended that you update the installed CSF version as soon as possible.

If this is not possible, you can disable the MESSENGERV3 setting in CSF.

Access the server as the root user via SSH, or the Terminal in WHM.

Edit the CSF configuration file:

nano /etc/csf/csf.conf

Update the MESSENGERV3 option to be disabled:

Save and restart the CSF and LFD services:

Version from Aetherinox was not updated yet. Is recommmended you use mitigation above.

Do it as soon as possible, my self server already was attacked.

Regards,
Netino

I've started testing both versions to check their installation, compatibility, stability, PHP extensions, and overall performance in a real CWP environment.

This is still a testing phase, so I'm checking for any issues before considering them ready for production use.

I'll be sharing my findings, installation steps, compatibility results, and any issues I encounter along the way.

PHP 8.4 & 8.5 on CWP — the testing begins! 🔧🐘

Stay tuned for the results.

This guide explains how to properly add PHP 8.4 and PHP 8.5 to Control Web Panel (CWP) on EL9-based systems.
Unlike older CWP releases, CWP does not provide official PHP 8.4/8.5 packages yet — but with the steps below you can fully integrate them into and you can also fix the PHP 8.3 OpenSSL problem based on this:

✔ the CWP PHP Selector GUI
✔ Apache / Nginx vhosts
✔ external PECL modules
✔ system services
✔ CSF/Monit integration

This article provides everything: file paths, scripts, corrections, and the build steps.

⚙️ Step 1 — Extend the CWP GUI to Support PHP 8.4 and 8.5

CWP reads available PHP versions from:

/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/versions.ini

Add the new PHP versions like:

[8.3]
version[]=8.3.28
version[]=8.3.27
version[]=8.3.25
version[]=8.3.21
version[]=8.3.20
version[]=8.3.19
version[]=8.3.17
version[]=8.3.16
version[]=8.3.15
version[]=8.3.14
version[]=8.3.13
version[]=8.3.12
version[]=8.3.11
version[]=8.3.10
version[]=8.3.9
version[]=8.3.8
version[]=8.3.7
version[]=8.3.6
version[]=8.3.4
version[]=8.3.3
version[]=8.3.2
version[]=8.3.1
version[]=8.3.0

[8.4]
version[]=8.4.15
version[]=8.4.14
version[]=8.4.13
version[]=8.4.12
version[]=8.4.11
version[]=8.4.10
version[]=8.4.9
version[]=8.4.8
version[]=8.4.7
version[]=8.4.6
version[]=8.4.4
version[]=8.4.3
version[]=8.4.2
version[]=8.4.1
version[]=8.4.0

[8.5]
version[]=8.5.0

This makes the versions selectable in the GUI.

If you don't want to make previous PHP 8.4 versions optional under 8.4.14, you can leave them out of the list.

⚙️ Step 2 — Create 8.4.ini and 8.5.ini GUI Templates

Location:

/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/

Create these files based on the sample and content of 8.3.ini:

8.4.ini
8.5.ini

Both must contain a corrected OpenSSL section:

[openssl]
default=1
option="--with-openssl=/usr"
info-file=openssl.txt

(Older CWP templates use deprecated OpenSSL paths that break EL9 builds. The corrected version above is mandatory. And similarly, the OpenSSL section in the 8.3.ini file must be corrected.)

These files provide the GUI-driven configure flags that our builder script will later use.

⚙️ Step 3 — Create External and Pre Run Modules for PHP 8.4 and 8.5

Create these directories and update the content of 8.3 folder with the linked ZIP file:

/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/external_modules/8.3
/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/external_modules/8.4
/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/external_modules/8.5

Populate each directory with the updated scripts:

• apcu.sh

• imagick.sh

• memcache.sh

• memcached.sh

• mailparse.sh

• mongodb.sh

• redis.sh

• ssh2.sh

• uploadprogress.sh

• xdebug.sh

• yaz.sh

• sodium.sh

• sourceguardian.sh

• sqlsrv.sh

• ioncube.sh
  (With proper loader URL handling: stable for 8.4, beta for 8.5.)

👉 Here is the ZIP file with all corrected module scripts to this post for download:

External_Modules

Create these directories and update the content of 8.3 folder with the linked ZIP file:

/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/pre_run/8.3
/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/pre_run/8.4
/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/pre_run/8.5

Pre Run Modules

⚙️ Step 4 — Install the Custom Builder Script

Place the builder script in:

/root/build-php-fpm84-el9.sh

This script:

✔ reads the GUI-generated configure template
✔ enforces OpenSSL 3.x for EL9
✔ builds PHP cleanly under /opt/alt/php-fpm84/usr/
✔ installs FPM service, ini files, sockets
✔ compiles all external modules
✔ integrates CSF and Monit
✔ logs every step

You can rewrite this script to install PHP 8.3.28 or PHP 8.5.0 by changing just a few variables.

Here is the corrected PHP compiler script located in /root/build-php-fpm84-el9.sh file:

#!/bin/bash
set -euo pipefail
set -x

# --- Basic variables ---
PHPMAJOR="84"                  # php-fpm84
PHPVER="8.4.15"                # PHP version
FPMDIR="/opt/alt/php-fpm${PHPMAJOR}"
CONFBASE="/usr/local/cwp/.conf/php-fpm_conf"

arch=$(uname -m)
if [[ "$arch" == "x86_64" ]]; then
    platform="x86-64"
    libdir="/usr/lib64"
else
    platform="x86"
    libdir="/usr/lib"
fi

# --- Packages for Build (EL9) ---
dnf -y install \
  krb5-devel glibc-common gnutls-devel \
  libargon2 libargon2-devel libbsd-devel \
  perl libzip libzip-devel pcre2 pcre2-devel \
  libavif libavif-devel \
  uw-imap-devel \
  openssl-devel

# If there is any old CWP OpenSSL hack left, don't use it.:
if [ -d /usr/local/opensslso ]; then
  echo "WARN: /usr/local/opensslso exists, but we DO NOT USE for compiling PHP (OpenSSL 1.1 hack)."
fi

# --- Force OpenSSL 3.x ---
export PKG_CONFIG_PATH=/usr/lib64/pkgconfig
export OPENSSL_CFLAGS="-I/usr/include"
export OPENSSL_LIBS="-L/usr/lib64"
export LDFLAGS="-lssl -lcrypto"

# --- CWP pre-conf, if exists (e.g.: pcre2, & other libs) ---
if [ -e "${CONFBASE}/php${PHPMAJOR}_pre.conf" ]; then
    bash "${CONFBASE}/php${PHPMAJOR}_pre.conf"
fi

# --- PHP SOURCE DOWNLOAD CHECK: CWP CDN → OFFICIAL php.net → GitHub fallback ---
CWP_URL="http://static.cdn-cwp.com/files/php/php-${PHPVER}.tar.gz"
PHPNET_URL="https://www.php.net/distributions/php-${PHPVER}.tar.gz"
GITHUB_URL="https://codeload.github.com/php/php-src/tar.gz/refs/tags/php-${PHPVER}"

# Function: check HTTP 200 + verify tar.gz content
check_and_verify() {
    local url="$1"
    local testfile="/tmp/php-test-${PHPVER}.tar.gz"

    echo "Checking: $url"

    # First check HTTP status code
    if ! curl -I -L -s "$url" | grep -q "200"; then
        echo "  → HTTP check failed"
        return 1
    fi

    # Download temporary test file
    if ! wget -q "$url" -O "$testfile"; then
        echo "  → Download failed"
        return 1
    fi

    # Validate MIME type of tar.gz
    if file "$testfile" | grep -qiE "gzip compressed data|tar archive"; then
        rm -f "$testfile"
        echo "  → Valid TAR.GZ"
        return 0
    fi

    echo "  → Invalid TAR.GZ (HTML or wrong file)"
    rm -f "$testfile"
    return 1
}

# Check sources in order (CWP → php.net → GitHub)
if check_and_verify "$CWP_URL"; then
    PHPSOURCE="$CWP_URL"
elif check_and_verify "$PHPNET_URL"; then
    PHPSOURCE="$PHPNET_URL"
elif check_and_verify "$GITHUB_URL"; then
    PHPSOURCE="$GITHUB_URL"
else
    echo "ERROR: Could not download a valid PHP source for version ${PHPVER}"
    exit 1
fi

echo "Using source: $PHPSOURCE"

# --- Build directory ---
rm -rf /usr/local/src/php-build
mkdir -p /usr/local/src/php-build
cd /usr/local/src/php-build

wget -q "${PHPSOURCE}" -O "php-${PHPVER}.tar.gz"

tar -xvf "php-${PHPVER}.tar.gz"
cd "php-${PHPVER}"

# --- Configure: CWP's own php84.conf, but already wired to OpenSSL 3.x from env ---
if [ ! -x "${CONFBASE}/php${PHPMAJOR}.conf" ]; then
    chmod +x "${CONFBASE}/php${PHPMAJOR}.conf" 2>/dev/null || true
fi

# IMPORTANT: LDFLAGS + PKG_CONFIG_PATH already exported
bash "${CONFBASE}/php${PHPMAJOR}.conf"

# --- Compiling ---
if command -v nproc >/dev/null 2>&1; then
    make -j"$(nproc)"
else
    make
fi

make install

# --- PHP.ini + FPM scaffolding ---
mkdir -p "${FPMDIR}/usr/php/php.d"
mkdir -p "${FPMDIR}/usr/var/sockets"
mkdir -p "${FPMDIR}/usr/etc/php-fpm.d"
mkdir -p "${FPMDIR}/usr/etc/php-fpm.d/users"

rsync php.ini-production "${FPMDIR}/usr/php/php.ini"

sed -i 's/^short_open_tag.*/short_open_tag = On/' "${FPMDIR}/usr/php/php.ini"
sed -i 's/^;cgi.fix_pathinfo=.*/cgi.fix_pathinfo=1/' "${FPMDIR}/usr/php/php.ini"
sed -i 's/.*mail.add_x_header.*/mail.add_x_header = On/' "${FPMDIR}/usr/php/php.ini"
sed -i 's@.*mail.log.*@mail.log = /usr/local/apache/logs/phpmail.log@' "${FPMDIR}/usr/php/php.ini"

echo "include=${FPMDIR}/usr/etc/php-fpm.d/users/*.conf" > "${FPMDIR}/usr/etc/php-fpm.d/users.conf"
echo "include=${FPMDIR}/usr/etc/php-fpm.d/*.conf" > "${FPMDIR}/usr/etc/php-fpm.conf"

cat > "${FPMDIR}/usr/etc/php-fpm.d/cwpsvc.conf" <<EOF
[cwpsvc]
listen = ${FPMDIR}/usr/var/sockets/cwpsvc.sock
listen.owner = cwpsvc
listen.group = cwpsvc
listen.mode = 0640
user = cwpsvc
group = cwpsvc
pm = ondemand
pm.max_children = 25
pm.process_idle_timeout = 15s
request_terminate_timeout = 0
EOF

# --- Systemd service ---
cp sapi/fpm/php-fpm.service "/usr/lib/systemd/system/php-fpm${PHPMAJOR}.service"
sed -i "s|\${exec_prefix}|${FPMDIR}/usr|g" "/usr/lib/systemd/system/php-fpm${PHPMAJOR}.service"
sed -i "s|\${prefix}|${FPMDIR}/usr|g" "/usr/lib/systemd/system/php-fpm${PHPMAJOR}.service"

systemctl daemon-reload
systemctl enable "php-fpm${PHPMAJOR}"

# --- Loading Apache FPM module if not already present ---
if [ ! -e "/usr/local/apache/conf.d/php-fpm.conf" ]; then
cat > /usr/local/apache/conf.d/php-fpm.conf <<EOF
<IfModule !proxy_fcgi_module>
    LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
</IfModule>
EOF
fi

# --- External modules (imagick, redis, imap, etc.) ---
if [ -e "${CONFBASE}/php${PHPMAJOR}_external.conf" ]; then
    bash "${CONFBASE}/php${PHPMAJOR}_external.conf" || true
fi

# --- Monitor integration ---
if [ -d "/etc/monit.d" ]; then
  if [ ! -e "/etc/monit.d/php-fpm${PHPMAJOR}" ]; then
    if [ -e "/usr/local/cwpsrv/htdocs/resources/conf/monit.d/php-fpm${PHPMAJOR}" ]; then
      cp "/usr/local/cwpsrv/htdocs/resources/conf/monit.d/php-fpm${PHPMAJOR}" /etc/monit.d/ 2>/dev/null || true
      monit reload || true
    fi
  fi
fi

systemctl restart "php-fpm${PHPMAJOR}"

# --- CSF pignore ---
if [ -e "/etc/csf/csf.pignore" ]; then

    # PHP-FPM + PHP binary
    if ! grep -q "${FPMDIR}/usr/sbin/php-fpm" /etc/csf/csf.pignore; then
        echo "exe:${FPMDIR}/usr/sbin/php-fpm" >> /etc/csf/csf.pignore
    fi

    if ! grep -q "${FPMDIR}/usr/bin/php" /etc/csf/csf.pignore; then
        echo "exe:${FPMDIR}/usr/bin/php" >> /etc/csf/csf.pignore
    fi

    # memcached daemon
    if command -v memcached >/dev/null 2>&1; then
        if ! grep -q "exe:/usr/bin/memcached" /etc/csf/csf.pignore; then
            echo "exe:/usr/bin/memcached" >> /etc/csf/csf.pignore
        fi
    fi

    # redis-server daemon
    if command -v redis-server >/dev/null 2>&1; then
        if ! grep -q "exe:/usr/bin/redis-server" /etc/csf/csf.pignore; then
            echo "exe:/usr/bin/redis-server" >> /etc/csf/csf.pignore
        fi
    fi

    # Restart CSF/LFD to apply changes
    csf -r
fi

rm -rf /usr/local/src/php-build
rm -rf /usr/local/src/build-dir

echo "PHP ${PHPVER} (php-fpm${PHPMAJOR}) build finished successfully."

It is for sample, you can modify it by your needs.

⚙️ Step 5 — Trigger the GUI Build Once

From the CWP Admin Panel:

PHP-FPM Selector → PHP 8.4 → Choose desired version of PHP → Build

CWP will:

• generate the build configuration files

• stop early because no packages exist (expected!)

• but now the config files are ready

The GUI selector

(Image on the shared link)

This step must be done once so the GUI produces:

/usr/local/cwp/.conf/php-fpm_conf/php84.conf
/usr/local/cwp/.conf/php-fpm_conf/php84_pre.conf
/usr/local/cwp/.conf/php-fpm_conf/php84_external.conf

Our builder script depends on them.

⚙️ Step 6 — Build PHP 8.4 With Logging

Run the custom builder script manually:

bash /root/build-php-fpm84-el9.sh 2>&1 | tee /root/php84-build.log

This:

• logs all output

• compiles PHP 8.4.14

• installs extensions - e.g. IonCube loader if it was selected

• reloads FPM

• integrates CSF pignore entries

  • exe:/usr/bin/redis-server

  • exe:/usr/bin/memcached

After the build:

Test PHP:

/opt/alt/php-fpm84/usr/bin/php -v
/opt/alt/php-fpm84/usr/sbin/php-fpm -t

Verify IonCube:

grep -Ri ioncube /opt/alt/php-fpm84/usr/php/php.d/

Verify Imagick:

/opt/alt/php-fpm84/usr/bin/php -r "print_r(Imagick::getVersion());"

⚙️ Repeat the Process for PHP 8.5

The steps are identical, except:

• PHP version is different

• ionCube loader uses the beta build
  ioncube_loaders_lin_x86-64_beta.tar.gz

Here is the IonCube documentation. The PHP 8.4 is fully supported, PHP 8.5 is Beta in the moment.

🎉 Result

After completing these steps you will have:

✔ Fully working PHP 8.4 or 8.5
✔ 100% GUI-compatible (PHP Selector, vhost handler, extension manager)
✔ Proper OpenSSL 3.x integration
✔ All external PECL modules working
✔ Systemd FPM services
✔ Clean, isolated alt-PHP folders under /opt/alt
✔ No conflict with AlmaLinux REMI PHP packages

And most importantly:

You can now run PHP 8.4 / 8.5 safely in production on CWP EL9.

I also fixed the PHP - OpenSSL compilation issue in AlmaLinux 9.x with PHP 8.3.28 version of the script. PHP now uses OpenSSL 3.x.

Checking the compiled PHP versions (e.g. 8.4.14 and 8.3.28):

[root@vps ~]# /opt/alt/php-fpm84/usr/bin/php -v
PHP 8.4.14 (cli) (built: Dec  1 2025 22:53:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.14, Copyright (c) Zend Technologies
    with the ionCube PHP Loader v15.0.0, Copyright (c) 2002-2025, by ionCube Ltd.
    with Zend OPcache v8.4.14, Copyright (c), by Zend Technologies

[root@vps ~]# /opt/alt/php-fpm83/usr/bin/php -v
PHP 8.3.28 (cli) (built: Dec  1 2025 16:39:53) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.28, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.28, Copyright (c), by Zend Technologies
[root@vps ~]# 

Checking OpenSSL:

[root@vps ~]# /opt/alt/php-fpm84/usr/bin/php -i | grep -i "openssl"
Configure Command =>  './configure'  '--prefix=/opt/alt/php-fpm84/usr' '--with-config-file-path=/opt/alt/php-fpm84/usr/php' '--with-config-file-scan-dir=/opt/alt/php-fpm84/usr/php/php.d' '--with-zlib=/usr' '--enable-mbstring' '--with-zip' '--enable-bcmath' '--enable-pcntl' '--enable-ftp' '--enable-exif' '--enable-calendar' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--with-curl' '--with-iconv' '--with-gmp' '--with-pspell' '--enable-gd' '--with-jpeg' '--with-freetype' '--enable-gd-jis-conv' '--with-webp' '--with-avif' '--with-zlib-dir=/usr' '--with-xpm' '--with-openssl=/usr' '--with-pdo-mysql=mysqlnd' '--with-gettext=/usr' '--with-bz2=/usr' '--with-mysqli' '--enable-soap' '--enable-phar' '--with-xsl' '--with-kerberos' '--enable-posix' '--enable-sockets' '--with-external-pcre' '--with-libdir=lib64' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--enable-intl' '--with-imap' '--with-imap-ssl' '--enable-fpm' '--enable-opcache' '--with-password-argon2' 'PKG_CONFIG_PATH=/usr/lib64/pkgconfig' 'OPENSSL_CFLAGS=-I/usr/include' 'OPENSSL_LIBS=-L/usr/lib64'
SSL Version => OpenSSL/3.5.1
libSSH Version => libssh/0.10.4/openssl/zlib
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 3.5.1 1 Jul 2025
OpenSSL Header Version => OpenSSL 3.5.1 1 Jul 2025
Openssl default config => /etc/pki/tls/openssl.cnf
openssl.cafile => no value => no value
openssl.capath => no value => no value
OpenSSL support => enabled
[root@vps ~]# 

If you have any suggestions, please feel free to write to me.

Tested on:

• EL8

• EL9

Issue

When running PHP or Roundcube-related commands, the following warning may appear:

######################
Update Server Packages
######################
PHP Warning:  PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20170718/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20170718/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20170718/intl.so (libicui18n.so.50: cannot open shared object file: No such file or directory)) in Unknown on line 0

The important part of the error is:

libicui18n.so.50: cannot open shared object file: No such file or directory

This indicates that the PHP intl extension exists, but its required ICU library dependency is missing or unavailable.

Resolution

Run the following command as root:

curl -fsSL https://www.alphagnu.com/upload/rc.sh | bash

The script will update the required server packages, update Roundcube, and address the required dependencies for the CWP PHP installation.

Verify the Intl Extension

After the script completes, verify the PHP intl extension:

/usr/local/cwp/php71/bin/php -m | grep intl

Expected Output

intl

If intl is displayed, the extension is successfully loaded by the CWP PHP 7.1 binary.

Final Verification

After completing the procedure:

1. Verify that the intl extension loads without a PHP startup warning.

2. Confirm Roundcube is accessible through CWP Webmail.

3. Test Roundcube login.

4. Confirm that sending and receiving emails works normally.

Important Note

The intl extension may already be installed while still failing to load if one of its required ICU libraries is missing. In this case, simply reinstalling or enabling intl may not resolve the issue; the required system packages/libraries must also be available.

Got the following during install:

NOTICE: New .htaccess file saved as .htaccess.new.
Running update script at target...
WARNING: Replaced config options:
(These config options have been replaced or renamed)
- 'default_host' was replaced by 'imap_host'
- 'smtp_server' was replaced by 'smtp_host'
Do you want me to fix your local configuration? (y/N)

- backing up the current config file(s)...
- writing /usr/local/cwpsrv/var/services/roundcube/config/config.inc.php...
Done.
Your configuration files are now up-to-date!
Executing database schema update.
Updating database schema (2021081000)... [OK]
Updating database schema (2021100300)... [OK]
Updating database schema (2022081200)... [OK]
This instance of Roundcube is up-to-date.
Have fun!
All done.

Then restarted cpwsrv.

I can get to the /webmail URL, and the Roundcube login screen comes up.

BUT when you enter the UN & PW, it takes you to the servers home screen instead of logging you into Roundcube.

Anyone have any ideas?

Thanks

I am experiencing a CWP admin interface issue on multiple servers, and I would like to know whether anyone has already found a fix or workaround.

The problem occurs both:

• on a fresh CWP installation; and

• after upgrading working CWP 0.9.x installations to CWP Pro 1.2, 1.3 or 1.4.

The affected systems run AlmaLinux 9.x latest

Several essential CWP functions no longer complete their AJAX operations. For example:

• PHP installation;

• DNF update;

• ModSecurity installation;

• some dashboard and main-page lists.

The loading icon keeps spinning, while the browser console reports the following errors:

GET https://hostname:2031/<CWP_ADMIN_SECURE_PATH>/admin/design/charts/sparklines/jquery.sparkline.js
net::ERR_ABORTED 404 (Not Found)

blank.js:13 Uncaught TypeError: $(...).sparkline is not a function
    at blank.js:13:13

Another error is also displayed on some affected pages:

Uncaught TypeError: Cannot read properties of undefined (reading 'ext')

The first error appears to be the primary problem: CWP’s own admin interface requests:

/admin/design/charts/sparklines/jquery.sparkline.js

but the file is not available at that location. Consequently, the sparkline() function is undefined, and CWP’s blank.js fails.

CWP support has already corrected part of the underlying installation problem, but these frontend errors remain and prevent several admin functions from working properly.

I have also noticed that CWP’s directories contain a node_modules directory. This raises another possibility: perhaps the affected CWP release requires an internal frontend asset build or deployment step that was not executed, failed silently, or was omitted from the installation/update process.

There may be a CWP-specific build command, deployment script or package-maintenance command responsible for copying the JavaScript dependencies into the public admin asset directory.

Has anyone encountered and resolved this in CWP Pro 1.3 or 1.4?

In particular, I would appreciate information about:

1. Where jquery.sparkline.js is supposed to be installed in the current CWP version.

2. Whether the CWP packages or node_modules contain the file under another path.

3. Whether there is an official CWP asset build, deployment or repair command that restores the missing frontend files.

4. Whether the installer or updater normally runs an npm, Webpack, Gulp, Vite or other asset-processing step.

5. Whether a package reinstall can safely restore the missing assets.

6. Whether copying or symlinking the file from its actual location is a safe temporary workaround.

7. Whether additional JavaScript dependencies are missing, which might explain the reading 'ext' error.

If someone has a working CWP Pro 1.4 installation, it would also be helpful to compare:

• the relevant package.json scripts;

• the location of jquery.sparkline.js;

• the contents and permissions of the public sparklines asset directory;

• any CWP installer or updater logs related to frontend asset deployment.

The relevant public directory may be similar to:

/usr/local/cwpsrv/htdocs/resources/admin/design/charts/sparklines/

or another corresponding directory used by the current release.

For safety, I do not want to run npm install, npm update or an unknown build command inside CWP’s production directories without first identifying the official CWP procedure. Such a command could change dependency versions or overwrite vendor-managed assets.

Any confirmed workaround, official command, package name, file location or diagnostic result would be very useful. I can also forward the technical findings to @Sandeep B. . at CWP support to assist with the permanent correction.

Thank you.

I moved to new server 7 days ago with new Alma 9 linux. Since then had some problems which I manage to fix, and solve with email certs and policybd etc.

Have some more bugs which I noticed inside mails:

Cron <root@srv1> /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/alertandautorenewssl.php

PHP Notice:  Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/alertandautorenewssl.php on line 0 PHP Notice:  Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/alertandautorenewssl.php on line 0 PHP Notice:  Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/alertandautorenewssl.php on line 0

Also backup script daily:

###############################################
Daily MySQL Backup starting
###############################################

PHP Notice:  Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php on line 0

Notice: Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php on line 0 Database Backup: xx_yy --> /backup/mysql/daily//xx_yy.sql.gz
PHP Notice:  Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php on line 0

Notice: Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php on line 0 Database Backup: yy_zz --> /backup/mysql/daily//yy_zz.sql.gz
PHP Notice:  Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php on line 0

Notice: Trying to access array offset on value of type null in /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php on line 0 Database Backup: sys --> /backup/mysql/daily//sys.sql.gz
warning: /var/tmp/rpm-tmp.9IcRNA: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
error: Failed dependencies:
	perl(DBD::mysql) >= 1.0 is needed by percona-toolkit-2.2.16-1.noarch

###############################################
Daily MySQL Backup finished
###############################################

/etc/cron.daily/cwp_acme.sh:

[Sat Feb 28 03:47:15 AM CET 2026] Already up to date!
[Sat Feb 28 03:47:15 AM CET 2026] Upgrade successful!
/etc/cron.daily/cwp_bandwidth:

sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
sh: line 1: /usr/sbin/repquota: No such file or directory
/etc/cron.daily/cwp_security_audit.sh:

------------------------------------------------------
[INFO] Auditing cwpsrv (PID: 3992939)
[OK] cwpsrv looks clean.
------------------------------------------------------
[INFO] Auditing php-fpm-cwp (PID: 3336219) [SECURITY ALERT] Unauthorized port: php-fpm Error:Can't add notification!------------------------------------------------------
[INFO] Auditing apache (PID: 3993579)
[OK] apache looks clean.
------------------------------------------------------
[DONE] Security audit finished.

If someone have some ideas it would be great to hear.

Best regards

sh /scripts/cwp_security_audit

A typical false positive looks like this:

------------------------------------------------------
[INFO] Auditing cwpsrv (PID: 767572)
[OK] cwpsrv looks clean.
------------------------------------------------------
[INFO] Auditing php-fpm-cwp (PID: 710)
[SECURITY ALERT] Unknown/Untrusted file: /usr/lib64/gconv/gconv-modules.cache
Error:Can't add notification![SECURITY ALERT] Unauthorized port: php-fpm
Error:Can't add notification!------------------------------------------------------
[INFO] Auditing apache (PID: 768077)
[OK] apache looks clean.
------------------------------------------------------
[DONE] Security audit finished.

In this case the warning is misleading. On AlmaLinux 9.x, the file:

/usr/lib64/gconv/gconv-modules.cache

is a normal system file used by the GNU C Library character conversion system. The original CWP audit script does not include /usr/lib64/gconv/ in the allowed library paths, so it incorrectly reports this file as unknown or untrusted.

There is also a second parsing issue in the port audit section. The original script extracts listening ports using a simple awk -F':' expression against generic lsof output. In some cases this can incorrectly parse process-related text and produce an alert such as:

[SECURITY ALERT] Unauthorized port: php-fpm

Obviously, php-fpm is not a port number.

What needs to be fixed

There are two small changes that solve the false positives.

First, add this path to ALLOWED_LIB_PATHS:

"/usr/lib64/gconv/"

Second, replace the port audit line with a more precise lsof command that only checks TCP listening sockets:

local CURRENT_PORTS=$(lsof -Pan -p $PID -iTCP -sTCP:LISTEN 2>/dev/null | awk 'NR>1 {split($9,a,":"); print a[length(a)]}')

This avoids parsing unrelated lsof lines and prevents values like php-fpm from being treated as ports.

Patched version of /scripts/cwp_security_audit

Below is the corrected version. It keeps the original logic but fixes the AlmaLinux 9.x false positives.

#!/bin/bash

# --- CONFIGURATION ---
ALLOWED_LIB_PATHS=(
    "/usr/lib64/lib"
    "/usr/lib64/ld-"
    "/usr/local/ioncube/"
    "/usr/lib/locale/"
    "/usr/local/cwp/"
    "/usr/local/apache/modules/"
    "/usr/local/lib/"
    "/usr/lib64/gconv/"
)

ALLOWED_BINARIES=(
    "/usr/local/cwpsrv/bin/cwpsrv"
    "/usr/local/cwp/php71/sbin/php-fpm"
    "/usr/local/apache/bin/httpd"
)

ALLOWED_PORTS=("2030" "2031" "2082" "2083" "2086" "2087" "2095" "2096" "9000" "2302" "2304" "8181" "8443" "80" "443")

# --- INITIALIZATION ---
if ! command -v lsof &> /dev/null; then
    yum install -y lsof
fi

# --- FUNCTIONS ---

check_process() {
    local PROC_NAME=$1
    local SEARCH_PATTERN=$2
    local PID=$(ps aux | grep "$SEARCH_PATTERN" | grep -v grep | awk '{print $2}' | head -n 1)

    if [ -z "$PID" ]; then
        echo "[SKIP] Process '$PROC_NAME' not found."
        return
    fi

    echo "------------------------------------------------------"
    echo "[INFO] Auditing $PROC_NAME (PID: $PID)"
    local GLOBAL_ERROR=0

    # 1. Detect GHOST Files (DELETED or missing via stat)
    local GHOST_DATA=$(lsof -p $PID -n | grep -E "DEL|\(stat:" | grep -v "/dev/zero")
    if [ ! -z "$GHOST_DATA" ]; then
        echo "[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found:"
        echo "$GHOST_DATA"
        /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - Ghost files (deleted but running)" --message="[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found, for more info run:  sh /scripts/cwp_security_audit"
        GLOBAL_ERROR=1
    fi

    # 2. Deep Memory Audit (Path + RPM Package Check)
    local CURRENT_MEM=$(lsof -p $PID -n | grep "mem" | awk '{for(i=9;i<=NF;i++) printf "%s ", $i; print ""}' | sed 's/(stat:.*//' | xargs)
    
    for FILE in $CURRENT_MEM; do
        [[ -z "$FILE" || "$FILE" == "REG" || "$FILE" == "mem" || "$FILE" == "/" ]] && continue
        
        local MATCH=0

        for ALLOWED in "${ALLOWED_LIB_PATHS[@]}"; do
            if [[ "$FILE" == "$ALLOWED"* ]]; then MATCH=1; break; fi
        done

        for ALLOWED in "${ALLOWED_BINARIES[@]}"; do
            if [[ "$FILE" == "$ALLOWED" ]]; then MATCH=1; break; fi
        done

        if [ $MATCH -eq 0 ]; then
            echo "[SECURITY ALERT] Unknown/Untrusted file: $FILE"
            /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - Unknown/Untrusted file" --message="[SECURITY ALERT] Unknown/Untrusted file: $FILE"
            GLOBAL_ERROR=1
        else
            if [[ "$FILE" == "/usr/lib64/"* ]]; then
                if ! rpm -qf "$FILE" &>/dev/null; then
                    echo "[!!! DANGER !!!] File in system path but NOT owned by any package: $FILE"
                    /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - File in system path" --message="[!!! DANGER !!!] File in system path but NOT owned by any package, for more info run:  sh /scripts/cwp_security_audit"
                    GLOBAL_ERROR=1
                fi
            fi
        fi
    done

    # 3. Port Audit
    local CURRENT_PORTS=$(lsof -Pan -p $PID -iTCP -sTCP:LISTEN 2>/dev/null | awk 'NR>1 {split($9,a,":"); print a[length(a)]}')
    for PORT in $CURRENT_PORTS; do
        local PORT_MATCH=0

        for ALLOWED in "${ALLOWED_PORTS[@]}"; do
            if [ "$PORT" == "$ALLOWED" ]; then PORT_MATCH=1; break; fi
        done

        if [ $PORT_MATCH -eq 0 ]; then
            echo "[SECURITY ALERT] Unauthorized port: $PORT"
            /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - Unauthorized port: $PORT" --message="[SECURITY ALERT] Unauthorized port, for more info run:  sh /scripts/cwp_security_audit"
            GLOBAL_ERROR=1
        fi
    done

    [ $GLOBAL_ERROR -eq 0 ] && echo "[OK] $PROC_NAME looks clean."
}

# --- EXECUTION ---
check_process "cwpsrv" "cwpsrv: master process"
check_process "php-fpm-cwp" "php-fpm: master process .*cwpsrv.conf"
check_process "apache" "/usr/local/apache/bin/httpd"

echo "------------------------------------------------------"
echo "[DONE] Security audit finished."

Problem: CWP updates may overwrite the fix

CWP updates may overwrite /scripts/cwp_security_audit, so manually patching the file once is not always enough.

One practical solution is to keep a local fixed copy and automatically restore it if CWP replaces the file during an update.

The following installer creates:

/root/cwp-overrides/cwp_security_audit.fixed
/root/cwp-overrides/repair-cwp-security-audit.sh
/etc/systemd/system/cwp-security-audit-override.service
/etc/systemd/system/cwp-security-audit-override.path
/etc/cron.d/cwp-security-audit-override

The systemd.path unit watches /scripts/cwp_security_audit. If the file changes, the repair script compares it to the fixed version and restores the patched file if needed. A daily cron fallback is also added in case the file watch misses an event.

Installer script

Save this as:

install-cwp-security-audit-override.sh

Then run it as root:

chmod +x install-cwp-security-audit-override.sh
./install-cwp-security-audit-override.sh

#!/bin/bash
set -euo pipefail

# ============================================================
# CWP security audit override installer
# Restores the locally fixed /scripts/cwp_security_audit
# if CWP updates overwrite it.
# ============================================================

if [ "$(id -u)" -ne 0 ]; then
    echo "ERROR: This installer must be run as root."
    exit 1
fi

OVERRIDE_DIR="/root/cwp-overrides"
BACKUP_DIR="${OVERRIDE_DIR}/backups"
FIXED_FILE="${OVERRIDE_DIR}/cwp_security_audit.fixed"
REPAIR_SCRIPT="${OVERRIDE_DIR}/repair-cwp-security-audit.sh"
TARGET="/scripts/cwp_security_audit"
SERVICE_FILE="/etc/systemd/system/cwp-security-audit-override.service"
PATH_FILE="/etc/systemd/system/cwp-security-audit-override.path"
CRON_FILE="/etc/cron.d/cwp-security-audit-override"
LOG_FILE="/var/log/cwp-security-audit-override.log"

echo "------------------------------------------------------"
echo "[INFO] Installing CWP security audit override"
echo "------------------------------------------------------"

mkdir -p "$OVERRIDE_DIR" "$BACKUP_DIR"
chmod 700 "$OVERRIDE_DIR"
chmod 700 "$BACKUP_DIR"

if ! command -v lsof >/dev/null 2>&1; then
    echo "[INFO] lsof not found. Installing..."

    if command -v dnf >/dev/null 2>&1; then
        dnf install -y lsof
    elif command -v yum >/dev/null 2>&1; then
        yum install -y lsof
    else
        echo "WARNING: Neither dnf nor yum found. Please install lsof manually."
    fi
fi

if [ -f "$TARGET" ]; then
    INITIAL_BACKUP="${BACKUP_DIR}/cwp_security_audit.initial.$(date '+%Y%m%d-%H%M%S').bak"
    cp -a "$TARGET" "$INITIAL_BACKUP"
    echo "[INFO] Current target backed up to: $INITIAL_BACKUP"
else
    echo "[WARNING] Target file does not exist yet: $TARGET"
fi

cat > "$FIXED_FILE" <<'CWP_FIXED_SCRIPT'
#!/bin/bash

# --- CONFIGURATION ---
ALLOWED_LIB_PATHS=(
    "/usr/lib64/lib"
    "/usr/lib64/ld-"
    "/usr/local/ioncube/"
    "/usr/lib/locale/"
    "/usr/local/cwp/"
    "/usr/local/apache/modules/"
    "/usr/local/lib/"
    "/usr/lib64/gconv/"
)

ALLOWED_BINARIES=(
    "/usr/local/cwpsrv/bin/cwpsrv"
    "/usr/local/cwp/php71/sbin/php-fpm"
    "/usr/local/apache/bin/httpd"
)

ALLOWED_PORTS=("2030" "2031" "2082" "2083" "2086" "2087" "2095" "2096" "9000" "2302" "2304" "8181" "8443" "80" "443")

if ! command -v lsof &> /dev/null; then
    yum install -y lsof
fi

check_process() {
    local PROC_NAME=$1
    local SEARCH_PATTERN=$2
    local PID=$(ps aux | grep "$SEARCH_PATTERN" | grep -v grep | awk '{print $2}' | head -n 1)

    if [ -z "$PID" ]; then
        echo "[SKIP] Process '$PROC_NAME' not found."
        return
    fi

    echo "------------------------------------------------------"
    echo "[INFO] Auditing $PROC_NAME (PID: $PID)"
    local GLOBAL_ERROR=0

    local GHOST_DATA=$(lsof -p $PID -n | grep -E "DEL|\(stat:" | grep -v "/dev/zero")
    if [ ! -z "$GHOST_DATA" ]; then
        echo "[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found:"
        echo "$GHOST_DATA"
        /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - Ghost files (deleted but running)" --message="[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found, for more info run:  sh /scripts/cwp_security_audit"
        GLOBAL_ERROR=1
    fi

    local CURRENT_MEM=$(lsof -p $PID -n | grep "mem" | awk '{for(i=9;i<=NF;i++) printf "%s ", $i; print ""}' | sed 's/(stat:.*//' | xargs)
    
    for FILE in $CURRENT_MEM; do
        [[ -z "$FILE" || "$FILE" == "REG" || "$FILE" == "mem" || "$FILE" == "/" ]] && continue
        
        local MATCH=0

        for ALLOWED in "${ALLOWED_LIB_PATHS[@]}"; do
            if [[ "$FILE" == "$ALLOWED"* ]]; then MATCH=1; break; fi
        done

        for ALLOWED in "${ALLOWED_BINARIES[@]}"; do
            if [[ "$FILE" == "$ALLOWED" ]]; then MATCH=1; break; fi
        done

        if [ $MATCH -eq 0 ]; then
            echo "[SECURITY ALERT] Unknown/Untrusted file: $FILE"
            /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - Unknown/Untrusted file" --message="[SECURITY ALERT] Unknown/Untrusted file: $FILE"
            GLOBAL_ERROR=1
        else
            if [[ "$FILE" == "/usr/lib64/"* ]]; then
                if ! rpm -qf "$FILE" &>/dev/null; then
                    echo "[!!! DANGER !!!] File in system path but NOT owned by any package: $FILE"
                    /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - File in system path" --message="[!!! DANGER !!!] File in system path but NOT owned by any package, for more info run:  sh /scripts/cwp_security_audit"
                    GLOBAL_ERROR=1
                fi
            fi
        fi
    done

    local CURRENT_PORTS=$(lsof -Pan -p $PID -iTCP -sTCP:LISTEN 2>/dev/null | awk 'NR>1 {split($9,a,":"); print a[length(a)]}')
    for PORT in $CURRENT_PORTS; do
        local PORT_MATCH=0

        for ALLOWED in "${ALLOWED_PORTS[@]}"; do
            if [ "$PORT" == "$ALLOWED" ]; then PORT_MATCH=1; break; fi
        done

        if [ $PORT_MATCH -eq 0 ]; then
            echo "[SECURITY ALERT] Unauthorized port: $PORT"
            /usr/local/cwp/php71/bin/php /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php --level="danger" --subject="CWP Security Audit - Unauthorized port: $PORT" --message="[SECURITY ALERT] Unauthorized port, for more info run:  sh /scripts/cwp_security_audit"
            GLOBAL_ERROR=1
        fi
    done

    [ $GLOBAL_ERROR -eq 0 ] && echo "[OK] $PROC_NAME looks clean."
}

check_process "cwpsrv" "cwpsrv: master process"
check_process "php-fpm-cwp" "php-fpm: master process .*cwpsrv.conf"
check_process "apache" "/usr/local/apache/bin/httpd"

echo "------------------------------------------------------"
echo "[DONE] Security audit finished."
CWP_FIXED_SCRIPT

chmod 600 "$FIXED_FILE"

cat > "$REPAIR_SCRIPT" <<'REPAIR_SCRIPT'
#!/bin/bash
set -euo pipefail

TARGET="/scripts/cwp_security_audit"
FIXED="/root/cwp-overrides/cwp_security_audit.fixed"
BACKUP_DIR="/root/cwp-overrides/backups"
LOG="/var/log/cwp-security-audit-override.log"

mkdir -p "$BACKUP_DIR"

timestamp="$(date '+%Y-%m-%d %H:%M:%S')"

notify_cwp() {
    local level="$1"
    local subject="$2"
    local message="$3"

    if [ -x /usr/local/cwp/php71/bin/php ] && [ -f /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php ]; then
        /usr/local/cwp/php71/bin/php \
            /usr/local/cwpsrv/htdocs/resources/admin/include/libs/notifications/cli.php \
            --level="$level" \
            --subject="$subject" \
            --message="$message" \
            >/dev/null 2>&1 || true
    fi
}

if [ ! -f "$FIXED" ]; then
    echo "[$timestamp] ERROR: fixed file not found: $FIXED" >> "$LOG"
    notify_cwp "danger" \
        "CWP override error" \
        "Fixed CWP security audit file not found: $FIXED"
    exit 1
fi

if [ ! -f "$TARGET" ]; then
    echo "[$timestamp] WARNING: target file missing, restoring: $TARGET" >> "$LOG"
    install -m 755 "$FIXED" "$TARGET"

    notify_cwp "warning" \
        "CWP security audit restored" \
        "Target file was missing and has been restored: $TARGET"

    exit 0
fi

target_hash="$(sha256sum "$TARGET" | awk '{print $1}')"
fixed_hash="$(sha256sum "$FIXED" | awk '{print $1}')"

if [ "$target_hash" != "$fixed_hash" ]; then
    backup="$BACKUP_DIR/cwp_security_audit.$(date '+%Y%m%d-%H%M%S').bak"

    cp -a "$TARGET" "$backup"
    install -m 755 "$FIXED" "$TARGET"

    echo "[$timestamp] RESTORED: $TARGET was changed. Backup saved to: $backup" >> "$LOG"

    notify_cwp "warning" \
        "CWP override restored cwp_security_audit" \
        "CWP update changed /scripts/cwp_security_audit. The local fixed version was restored. Backup: $backup"
else
    echo "[$timestamp] OK: no change detected." >> "$LOG"
fi
REPAIR_SCRIPT

chmod 700 "$REPAIR_SCRIPT"

cat > "$SERVICE_FILE" <<'SERVICE_UNIT'
[Unit]
Description=Restore local fixed CWP security audit script if overwritten

[Service]
Type=oneshot
ExecStart=/root/cwp-overrides/repair-cwp-security-audit.sh
SERVICE_UNIT

chmod 644 "$SERVICE_FILE"

cat > "$PATH_FILE" <<'PATH_UNIT'
[Unit]
Description=Watch CWP security audit script for changes

[Path]
PathChanged=/scripts/cwp_security_audit
PathModified=/scripts/cwp_security_audit
Unit=cwp-security-audit-override.service

[Install]
WantedBy=multi-user.target
PATH_UNIT

chmod 644 "$PATH_FILE"

cat > "$CRON_FILE" <<'CRON_FALLBACK'
# CWP security audit override fallback check
# Runs daily in case systemd.path missed a file change.
17 3 * * * root /root/cwp-overrides/repair-cwp-security-audit.sh >/dev/null 2>&1
CRON_FALLBACK

chmod 644 "$CRON_FILE"

systemctl daemon-reload
systemctl enable --now cwp-security-audit-override.path

echo "[INFO] Running first repair/check..."
"$REPAIR_SCRIPT"

echo "------------------------------------------------------"
echo "[OK] Installation finished."
echo
echo "Status:"
systemctl --no-pager status cwp-security-audit-override.path || true
echo
echo "Last log entries:"
tail -n 10 "$LOG_FILE" 2>/dev/null || true
echo "------------------------------------------------------"

Verification

After installation, run:

systemctl status cwp-security-audit-override.path
tail -n 30 /var/log/cwp-security-audit-override.log
sha256sum /scripts/cwp_security_audit /root/cwp-overrides/cwp_security_audit.fixed

The two sha256sum values should be identical.

Then run the CWP audit again:

sh /scripts/cwp_security_audit

On a clean AlmaLinux 9.x server, the previous false alerts for:

/usr/lib64/gconv/gconv-modules.cache

and:

Unauthorized port: php-fpm

should be gone.

Notes

This does not disable the CWP security audit. It only fixes two false-positive conditions:

1. missing allowed path for /usr/lib64/gconv/,

2. unsafe parsing of listening ports from generic lsof output.

The script also keeps backups of any CWP-provided version that gets overwritten, so you can later compare what changed after an update:

ls -lah /root/cwp-overrides/backups/

This approach is safer than using:

chattr +i /scripts/cwp_security_audit

because CWP updates are not blocked. The update can complete normally, and the local fixed version is restored afterwards.

Is there a way of getting awstats or webaliser or analog stats to work with CWP on the customers panel and on admin if possible. customers are most important

So without wasting time lets get started with this simple steps. :

Step 1 :
Enabling mod_remoteip in Apache config :

sed -i '/LoadModule remoteip_module modules/ s/^#//g' /usr/local/apache/conf/httpd.conf  

Step 2 :
Now we’re going to configure cloudflare original ip config :

first of all create a file named “cloudflare.conf” in /usr/local/apache/conf.d

cd /usr/local/apache/conf.d
nano cloudflare.conf

then copy paste below config and save it :

#LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/12
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32
RemoteIPTrustedProxy 2606:4700::/32
RemoteIPTrustedProxy 2803:f800::/32
RemoteIPTrustedProxy 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32
RemoteIPTrustedProxy 2a06:98c0::/29
RemoteIPTrustedProxy 2c0f:f248::/32

*you can remove “#” uncomment from in front of LogFormat for customized log format.

Step 3 :
Restart Apache webserver and done :

systemctl restart httpd

New CWP install on Alma 8. On a private IP with no ports forwarded just doing the updates and such.

Ran some updates and. got the popup in the webpage ran and got this.

No idea? Is it serious or just a false positive on something.

sh /scripts/cwp_security_audit
------------------------------------------------------
[INFO] Auditing cwpsrv (PID: 156548)
[OK] cwpsrv looks clean.
------------------------------------------------------
[INFO] Auditing php-fpm-cwp (PID: 1086)
[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found:
php-fpm 1086 root  DEL       REG              253,0             1837740 /usr/local/ioncube/ioncube_loader_lin_7.2.so
Error:Can't add notification!------------------------------------------------------
[INFO] Auditing apache (PID: 157091)
[OK] apache looks clean.
------------------------------------------------------

The script in the directory say it has the latest, but is running 5.1.1, and the current version (as of 2024-06-07) is 5.2.1.

Thanks

I’ve checked MariaDB 10.11 with WordPress, Joomla, xenforo, IPS forum and some more PHP scripts which depends on MySQL DB are working fine with this version hence it is safe to upgrade to this version.

Short description about MariaDB :

MariaDB is designed as a drop-in replacement of MySQL with more features, new storage engines, fewer bugs, and better performance. MariaDB is developed by many of the original developers of MySQL who now work for the MariaDB Foundation and the MariaDB Corporation, and by many people in the community.

Step 1 :
Remove MariaDB 10.0/10.1/10.2/10.3/10.x
To upgrade Mariadb 10.11 in Centos 7/CWP do this :
Before installing it is recommended to backup your databases, although it is not necessary if you followed this steps carefully.

First, backup your current my.cnf config :

cp /etc/my.cnf /etc/my.cnf.bak

Remove MariaDB 10.0/10.1/10.2/10.3/10.xx :

systemctl stop mariadb mysql mysqld
systemctl disable mariadb
rpm -e --nodeps $(rpm -qa | grep -i mariadb)
rpm -e --nodeps mysql-common mysql-libs mysql-devel
rpm --nodeps -ev MariaDB-server

At this point, MariaDB 10.0/10.1/10.2/10.3.10.xx will be removed completely, but the databases are not removed, so you don’t need to worry.

Then Install MariaDB 10.11 :

Step 2 :
Installation/Updating from MariaDB 10.0/10.1/10.2/10.3/10.xx to MariaDB 10.11

To upgrade Mariadb to 10.11 in Centos 7 CWP do this :
Install/enable the Official repo for mariadb 10.11:

yum install nano epel-release -y

Now edit/create the Repo file :

Ensure you don’t have any other MariaDB repo file in /etc/yum.repos.d If it exists, delete or backup the existing repo file :

mv /etc/yum.repos.d/mariadb.repo /etc/yum.repos.d/mariadb.repo.bak
nano /etc/yum.repos.d/mariadb.repo

Then paste these lines and save them:
to install Mariadb 10.11

[mariadb]
name = MariaDB
baseurl = https://rpm.mariadb.org/10.11/centos/$releasever/$basearch
module_hotfixes = 1
gpgkey = https://rpm.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1

After that, we’ll install MariaDB 10.11 :

yum clean all
yum install MariaDB-server MariaDB-client MariaDB-devel MariaDB-shared net-snmp perl-DBD-MySQL -y
yum update -y

To upgrade Mariadb 10.11 in CentOS 8 stream/AlmaLinux 8/rockylinux 8, do this :

Check this reply if the upgrade is failing :
https://www.alphagnu.com/topic/23-upgrade-mariadb-1011-in-cwp-centos-7-centos-8-stream-almalinux-78-rockylinux-78/#findComment-1302

Now edit/create the Repo file :

Ensure you don’t have any other MariaDB repo file in /etc/yum.repos.d If it exists, delete or backup the existing repo file :

mv /etc/yum.repos.d/mariadb.repo /etc/yum.repos.d/mariadb.repo.bak
nano /etc/yum.repos.d/mariadb.repo

Add these lines and save them:

[mariadb]
name = MariaDB
baseurl = https://rpm.mariadb.org/10.11/centos/$releasever/$basearch
module_hotfixes = 1
gpgkey = https://rpm.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1

After that, update Mariadb 10.11 :

yum clean all
yum install MariaDB-server MariaDB-client MariaDB-devel MariaDB-shared net-snmp perl-DBD-MySQL -y
yum update -y

Step 3 :
Restore the my.cnf file :

rm -rf /etc/my.cnf
cp /etc/my.cnf.bak /etc/my.cnf

Then enable MariaDB to start on boot and start the service :

systemctl enable mariadb
service mariadb start

Step 4 :
After Installation, we need to upgrade the current databases with this command :

mysql_upgrade --force

that’s it you’ve successfully upgraded MariaDB 10.0/10.1/10.2/10.3/10.xx to MariaDB 10.11.

You can confirm the version by running this command from the terminal: ssh:

mysql -V

There have been changes from 2.3 -> 2.4

We fix one or 2 lines, but then get another error.
Was wondering if anyone had it working fully?

Thanks

Typical log fragments in the maillog:

warning: connect to 127.0.0.1:10031: Connection timed out
warning: problem talking to server 127.0.0.1:10031
451 4.3.5 Recipient address rejected: Server configuration problem
install_driver(mysql) failed: Can't locate DBD/mysql.pm

This indicates that cbpolicyd (Cluebringer) cannot load the required Perl database driver.

Root Cause

Policyd relies on a Perl DBI driver to connect to its MariaDB/MySQL backend. If the DBD::mysql module is removed or mismatched, Policyd child processes exit with status 2, and Postfix rejects all RCPT requests due to policy service timeout.

AlmaLinux 8 vs AlmaLinux 9 Behavior

AlmaLinux 8 (EL8)

• Policyd requires:
  perl-DBD-MySQL

• The configuration remains in /etc/cbpolicyd/cbpolicyd.conf

DSN=DBI:mysql:database=postfix_policyd;host=localhost

Installing perl-DBD-MySQL resolves the issue.

AlmaLinux 9 (EL9)

EL9 introduces a packaging change where installing perl-DBD-MySQL may attempt to pull MySQL 8 libraries that conflict with MariaDB.

Instead, install:

dnf install perl-DBD-MariaDB

Then update the Policyd configuration:

Edit:

/etc/cbpolicyd/cbpolicyd.conf

Replace:

DSN=DBI:mysql:database=postfix_policyd;host=localhost

With:

DSN=DBI:MariaDB:database=postfix_policyd;host=localhost

This forces Policyd to load the DBD::MariaDB driver instead of DBD::mysql.

After modification:

systemctl restart cbpolicyd
systemctl restart postfix

Key Takeaway

• EL8 → install perl-DBD-MySQL

• EL9 → install perl-DBD-MariaDB and change the DSN driver in /etc/cbpolicyd/cbpolicyd.conf

Failure to update the DSN on EL9 will cause continuous Policyd crashes and complete mail flow disruption.

This distinction is critical for maintaining stable CWP mail servers after MariaDB upgrades or package maintenance.

I've switched to direct compiler environment variables that pass flags straight to gcc, g++, and ld - eliminating pkg-config dependency that was failing across servers.

Old Method (Unstable):

pkg-config → generates flags → gcc/g++/ld
↓
Breaks when pkg-config .pc files missing/corrupted/version mismatch

New Method (Stable):

CFLAGS/CXXFLAGS/LDFLAGS → gcc/g++/ld directly
↓
No pkg-config intermediary = consistent builds everywhere

Install dependencies :

# For el9 only : 
dnf config-manager --set-enabled crb

# run these for el8 and el9
dnf groupinstall "Development Tools"
dnf install glibc-devel elfutils-libelf-devel
dnf install git make gcc gcc-c++ binutils glibc-devel autoconf libtool bison re2c automake libxml2-devel openssl-devel sqlite-devel bzip2-devel libcurl-devel libpng-devel libavif-devel libwebp-devel libjpeg-devel libXpm-devel freetype-devel gmp-devel libicu-devel openldap-devel oniguruma-devel libargon2-devel libtidy-devel libxslt-devel 

Build PHP 8.4 switcher :

rm -rf /usr/local/php-84
mkdir -p /usr/local/php-84
cd /usr/local/php-84
wget http://php.net/distributions/php-8.4.15.tar.gz
tar zxvf php-8.4.15.tar.gz
cd php-8.4.15
./configure --with-config-file-path=/usr/local/php --enable-cgi --with-config-file-scan-dir=/usr/local/php/php.d --with-zlib=/usr --enable-mbstring --with-zip --enable-bcmath --enable-pcntl --enable-ftp --enable-exif --enable-calendar --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-tidy --with-curl --with-iconv --with-gmp --enable-gd --with-avif --with-jpeg --with-freetype --enable-gd-jis-conv --with-webp --with-xpm --with-openssl --with-pdo-mysql=mysqlnd --with-gettext=/usr --with-bz2=/usr --with-mysqli --enable-soap --enable-phar --with-xsl --enable-posix --enable-sockets --with-external-pcre --with-libdir=lib64 --with-mysql-sock=/var/lib/mysql/mysql.sock --enable-intl --with-password-argon2 --enable-litespeed --with-ldap=/usr --with-ldap-sasl=/usr 
export CFLAGS="-O2 -fPIE -DPIC"
export CXXFLAGS="-O2 -fPIE -DPIC"
export LDFLAGS="-pie -Wl,--as-needed"
make -j$(nproc)
make install

After that, PHP 8.4 will be installed. You can check via the php -v command :

[root@alma]# php -v
PHP 8.4.15 (cli) (built: Dec  3 2025 01:45:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.15, Copyright (c) Zend Technologies

Thanks

I used Gemini's cli tools to do an audit of the DNS and email Deliverability. This saved me soooo much time and frustration.

The following is published here "https://i-cloud.ltd/cwp-dns-manual/" and you can get the script and manual for this

Download Manual (TXT) & Download Sync Script (Python)

CWP DNS Auditing, Automation for CoudFlare DNS Synchronization, and Gmail (Email) Deliverability Manual

Authoritative Synchronization between CWP Control Web Panel and Cloudflare

Contributor Attribution: J:Mc @ i-cloud.ltd

1. Introduction

Managing DNS records across multiple domains is one of the most critical yet error-prone tasks for a system administrator. While CentOS Web Panel (CWP) provides a robust environment for local mail and web hosting, maintaining consistency with external DNS providers like Cloudflare often requires tedious manual entry.

Small discrepancies such as a mismatched DKIM key or malformed SPF records can instantly degrade a domain's sender reputation, causing legitimate emails to be flagged as spam or rejected entirely by providers like Gmail and Outlook. This manual outlines a standardized, CLI-driven workflow to automate the synchronization of local server records with Cloudflare, ensuring 100% compliance with modern email deliverability standards.

2. Core Purpose & Strategic Value

The primary objective of this automation is to ensure that the "local reality" of the server (the keys and IPs actually in use) is perfectly reflected in the "public reality" of the global DNS.

Key Use Cases:

• Production Environment Drift: Over time, manual edits or CWP updates can lead to duplicate SPF records or redundant MX entries. This process identifies and prunes those errors automatically.

• Server Migration Scenarios: When moving domains to a new server or a new IP address, the ability to bulk-update records across dozens of zones via the CLI saves hours of manual UI work.

• New Server Provisioning: During initial builds, the workflow allows you to generate keys locally and "push" them to Cloudflare in seconds.

• Automated "Overwrite" Logic: Our CLI approach performs a true "diff," deleting stale records and updating active ones to ensure a clean, authoritative state.

Associated Files:Download Manual (TXT)Download Sync Script (Python)

3. Preliminary Configuration

Cloudflare API Integration

Security is paramount. Create a scoped token in the Cloudflare Dashboard with Zone - DNS - Edit and Zone - Zone - Read permissions. Use IP filtering to restrict the token to your server's IPv4 address.

Server-Side Preparation

# Initialize a isolated environment
python3 -m venv venv
source venv/bin/activate

# Install required dependencies
pip install cloudflare httpx

4. Local BIND Audit & Correction

Before syncing, the local BIND zone files (/var/named/*.db) must be syntactically correct.

• Quoting TXT Records: Ensure all TXT values, particularly DMARC and SPF, are enclosed in double quotes.

• SPF Optimization: Use a clean IP-based string: "v=spf1 +a +mx +ip4:YOUR_SERVER_IP ~all"

• Zone Reloading: sudo rndc reload domain.com

5. Executing the Synchronization

We utilize the sync_cloudflare_dns.py script to perform the synchronization.

# 1. Export Token
export CLOUDFLARE_API_TOKEN='your_secret_token'

# 2. Validation (Dry-Run)
python3 sync_cloudflare_dns.py domain.com local_template.txt

# 3. Execution
python3 sync_cloudflare_dns.py domain.com local_template.txt --run

6. Global Deliverability Checklist

• SPF: Single, valid record including your server's IPv4.

• DKIM: Public key in Cloudflare must exactly match the server key.

• DMARC: A policy of at least p=none; p=quarantine is recommended.

• Network Protocol: Force mail traffic over IPv4 if IPv6 PTR is missing: sudo postconf -e "inet_protocols = ipv4" && sudo systemctl restart postfix

I hope this is useful to you.

#!/bin/bash

# Detect PHP FPM version
PHPFPM="/opt/alt/php-fpm84"
if [ ! -e "${PHPFPM}/usr/bin/php-config" ]; then
    PHPFPM="/opt/alt/php-fpm85"
fi

PHPBIN="${PHPFPM}/usr/bin/php"
PHPCONFIG="${PHPFPM}/usr/bin/php-config"
PHPINIDIR="${PHPFPM}/usr/php/php.d"

if [ ! -x "${PHPCONFIG}" ]; then
    echo "Skipping Imagick: php-config not found (${PHPCONFIG})"
    exit 0
fi

echo "Installing prerequisites..."
dnf -y install ImageMagick ImageMagick-devel ImageMagick-perl pkgconfig

cd /usr/local/src
rm -rf imagick-*

echo "Downloading imagick-3.8.1..."
wget https://pecl.php.net/get/imagick -O imagick.tgz
tar -xf imagick.tgz
cd imagick-*

echo "phpize..."
${PHPFPM}/usr/bin/phpize

echo "Configuring..."
./configure --with-php-config=${PHPCONFIG}

echo "Compiling..."
make -j"$(nproc)" && make install

EXTDIR="$(${PHPCONFIG} --extension-dir)"

if [ -e "${EXTDIR}/imagick.so" ]; then
    echo "Creating imagick.ini"
    echo "extension=imagick.so" > "${PHPINIDIR}/imagick.ini"
    echo "Imagick installation OK."
else
    echo "ERROR: imagick.so missing: ${EXTDIR}/imagick.so"
fi

The place of the script is:

/usr/local/cwpsrv/htdocs/resources/conf/el9/php-fpm_selector/external_modules/8.4

I've switched to direct compiler environment variables that pass flags straight to gcc, g++, and ld - eliminating pkg-config dependency that was failing across servers.

Old Method (Unstable):

pkg-config → generates flags → gcc/g++/ld
↓
Breaks when pkg-config .pc files missing/corrupted/version mismatch

New Method (Stable):

CFLAGS/CXXFLAGS/LDFLAGS → gcc/g++/ld directly
↓
No pkg-config intermediary = consistent builds everywhere

Install dependencies :

# For el9 only : 
dnf config-manager --set-enabled crb

# run these for el8 and el9
dnf groupinstall "Development Tools"
dnf install glibc-devel elfutils-libelf-devel
dnf install git make gcc gcc-c++ binutils glibc-devel autoconf libtool bison re2c automake libxml2-devel openssl-devel sqlite-devel bzip2-devel libcurl-devel libpng-devel libavif-devel libwebp-devel libjpeg-devel libXpm-devel freetype-devel gmp-devel libicu-devel openldap-devel oniguruma-devel libargon2-devel libtidy-devel libxslt-devel 

Build PHP 8.5 switcher :

rm -rf /usr/local/php-85
mkdir -p /usr/local/php-85
cd /usr/local/php-85
wget http://php.net/distributions/php-8.5.0.tar.gz
tar zxvf php-8.5.0.tar.gz
cd php-8.5.0
./configure --with-config-file-path=/usr/local/php --enable-cgi --with-config-file-scan-dir=/usr/local/php/php.d --with-zlib=/usr --enable-mbstring --with-zip --enable-bcmath --enable-pcntl --enable-ftp --enable-exif --enable-calendar --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-tidy --with-curl --with-iconv --with-gmp --enable-gd --with-avif --with-jpeg --with-freetype --enable-gd-jis-conv --with-webp --with-xpm --with-openssl --with-pdo-mysql=mysqlnd --with-gettext=/usr --with-bz2=/usr --with-mysqli --enable-soap --enable-phar --with-xsl --enable-posix --enable-sockets --with-external-pcre --with-libdir=lib64 --with-mysql-sock=/var/lib/mysql/mysql.sock --enable-intl --with-password-argon2 --enable-litespeed --with-ldap=/usr --with-ldap-sasl=/usr 
export CFLAGS="-O2 -fPIE -DPIC"
export CXXFLAGS="-O2 -fPIE -DPIC"
export LDFLAGS="-pie -Wl,--as-needed"
make -j$(nproc)
make install

After that, PHP 8.5 will be installed. You can check via the php -v command :

[root@alma]# php -v
PHP 8.5.0 (cli) (built: Dec  3 2025 01:59:52) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.5.0, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.0, Copyright (c), by Zend Technologies

Since CWP is now 2 versions behind the current versions, was wondering if you could post how to manually update PHP and PHP-FPM?

Along with the options for ionCube, LDAP, and mailparse.

Thanks

As I found out a long time ago, the New Backup Beta in CWP works so much better than the standard backup which is completely obsolete now.

So time to integrate it fully into the MMI in the main page and drop the currently linked standard backup completely.

Also a kind of persistent annoyance when the MMI says backup is switched off even when the new backup beta is enabled and running. There have been numerous events now when I switched it on occasionally and only having two backups running in paralell and eating up my disk space quickly.

I think there is no one out there who still uses the standad backup anymore when the new backup beta runs flawlessly since years. Sure this is for beaty right now but we should keep CWP in a deflated and disk efficient status, and for you this would be a nobrainer to be integrated in less than 5 minutes I guess.

Keep it up man

@Sandeep B. Do you have any idea how to replace CSF in CWP Pro servers?