All Activity

After recent CWP updates, some AlmaLinux 9.x servers may report false security alerts when running: 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 fixedThere 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_auditBelow 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 fixCWP 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 scriptSave 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 "------------------------------------------------------" VerificationAfter 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. NotesThis does not disable the CWP security audit. It only fixes two false-positive conditions: missing allowed path for /usr/lib64/gconv/, 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.

This has been working. Just noticed we have been getting reports from Cloudflare IP's listed above. e.g. - 104.23.211.82 (US/United States/Virginia/Ashburn/-/[AS13335 Cloudflare, Inc.]) ... 104.23.211.77 (US/United States/Virginia/Ashburn/-/[AS13335 Cloudflare, Inc.]) 104.23.211.200 (US/United States/Virginia/Ashburn/-/[AS13335 Cloudflare, Inc.]) 172.71.164.194 (DE/Germany/Hesse/Frankfurt am Main/-/[AS13335 Cloudflare, Inc.]) 172.71.164.195 (DE/Germany/Hesse/Frankfurt am Main/-/[AS13335 Cloudflare, Inc.])

May be you should change line 87 in /scripts/cwp_security_audit like this: local CURRENT_PORTS=$(ss -ltnp | grep "pid=$PID," | sed -nE 's/.*:([0-9]+).*/\1/p') This way there is no false positives. Or may be, even better: local CURRENT_PORTS=$(ss -ltnp state listening | grep "pid=$PID," | sed -nE 's/.*:([0-9]+).*/\1/p' | sort -u) and after the "for ... do" line: [[ "$PORT" =~ ^[0-9]+$ ]] || continue to avoid garbage.

May be that this also helps on EL9, because imap can't be natively installed from PECL: imap.sh #!/bin/bash set -euo pipefail BASEPATH="/opt/alt/php-fpm85" TMPDIR="/tmp/imap-rpm" RPM_URL="https://rpms.remirepo.net/enterprise/9/modular/x86_64/php-pecl-imap-1.0.3-1.module_php.8.5.el9.remi.x86_64.rpm" echo "[*] Cleaning temporary folder..." rm -rf "$TMPDIR" mkdir -p "$TMPDIR" cd "$TMPDIR" echo "[*] Downloading IMAP RPM..." wget -q --show-progress "$RPM_URL" -O php-pecl-imap.rpm echo "[*] Extracting RPM without installing..." rpm2cpio php-pecl-imap.rpm | cpio -idmv >/dev/null # Detect PHP extension directory EXT_DIR=$("$BASEPATH/usr/bin/php" -r 'echo ini_get("extension_dir");') if [[ ! -d "$EXT_DIR" ]]; then echo "[*] Creating extension directory at $EXT_DIR" mkdir -p "$EXT_DIR" fi echo "[*] Copying imap.so to $EXT_DIR" cp "$TMPDIR/usr/lib64/php/modules/imap.so" "$EXT_DIR/" # Detect php.d folder PHP_D_DIR="$BASEPATH/usr/php/php.d" if [[ ! -d "$PHP_D_DIR" ]]; then echo "[*] Creating php.d folder at $PHP_D_DIR" mkdir -p "$PHP_D_DIR" fi rm -rf "$TMPDIR" # Create the .ini file INI_FILE="$PHP_D_DIR/30-imap.ini" echo "[*] Creating $INI_FILE" echo "extension=imap.so" > "$INI_FILE" echo "[*] Installation complete. Restart PHP-FPM to activate the extension." echo "[*] Verification:" "$BASEPATH/usr/bin/php" -m | grep -i imap || echo "imap not loaded" "$BASEPATH/usr/bin/php" -r "var_dump(function_exists('imap_timeout'));" echo "[*] Done."

Don't do it. Even if you update it, the CWP daily cron will restore the 5.1 version again automatically.

Yep. I'm now getting an alert about unauthorized ports for php-fpm. I'm not sure if it's due to my recent tweak to add php 8.5 support in CWP selectors.

CWP has recently started kicking out this and other like warnings for me as well...

Hello, Thanks to the instructions, we were able to update to version 10.11.16-MariaDB without any problems. How high can the MySQL server be updated without crashing the entire system? By the way, I'm the same person with the same name from the CWP forum! :-)

Can you try this : dnf install perl-DBD-MariaDB

Thanks. It is good suggestion.

Doesn't anyone have an updated dovecot.conf for Dovecot 2.4 that is working correctly? 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

I did try that, I think replacement for mariadb is installed. yum install perl-DBD-MariaDB Last metadata expiration check: 1:23:09 ago on Mon 02 Mar 2026 08:48:52 PM CET. Package perl-DBD-MariaDB-1.21-17.el9.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete!Installing that package gets me to this: Last metadata expiration check: 1:20:08 ago on Mon 02 Mar 2026 08:48:52 PM CET. Dependencies resolved. ========================================================================================================================================================================================================================================================================================================================================================================= Package Architecture Version Repository Size ========================================================================================================================================================================================================================================================================================================================================================================= Installing: perl-DBD-MySQL x86_64 4.053-1.el9 appstream 144 k Installing dependencies: mysql-common x86_64 8.0.44-1.el9_7 appstream 67 k mysql-libs x86_64 8.0.44-1.el9_7 appstream 1.2 M Downgrading: MariaDB-common x86_64 10.11.15-1.el9 mariadb 88 k Transaction Summary ========================================================================================================================================================================================================================================================================================================================================================================= Install 3 Packages Downgrade 1 Package Total download size: 1.5 M Downloading Packages: (1/4): mysql-common-8.0.44-1.el9_7.x86_64.rpm 2.5 MB/s | 67 kB 00:00 (2/4): perl-DBD-MySQL-4.053-1.el9.x86_64.rpm 15 MB/s | 144 kB 00:00 (3/4): mysql-libs-8.0.44-1.el9_7.x86_64.rpm 18 MB/s | 1.2 MB 00:00 (4/4): MariaDB-common-10.11.15-1.el9.x86_64.rpm 1.1 MB/s | 88 kB 00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 3.9 MB/s | 1.5 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. Error: Transaction test error: file /usr/share/mysql/charsets/Index.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/armscii8.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/ascii.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp1250.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp1251.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp1256.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp1257.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp850.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp852.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/cp866.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/dec8.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/geostd8.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/greek.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/hebrew.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/hp8.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/keybcs2.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/koi8r.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/koi8u.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/latin1.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/latin2.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/latin5.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/latin7.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/macce.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/macroman.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64 file /usr/share/mysql/charsets/swe7.xml conflicts between attempted installs of mysql-common-8.0.44-1.el9_7.x86_64 and MariaDB-common-10.11.15-1.el9.x86_64

try to install this package and test : yum install perl-DBD-MySQL -y

Hi, 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 0Also 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

It's clean; there is no rootkit on your server. IonCube is used by CWP as it is encoded with it, and for decryption purposes .so is loaded

Really useful. Thanks a lot. But all scripts into the 8.5 folder should be modified to have a fixed version because as it's right now it doesn't work if you need to have both 8.4 and 8.5 versions installed at the same time. There is a fallback logic that always goes into 8.4 and that makes the 8.5 build to fail.

Posted in the CWP forums but there is not much going on there figure might get some help here.. 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. ------------------------------------------------------

@Starburst The mentioned issue may related to this topic:

This phenomenon typically occurs after a MariaDB upgrade.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.pmThis indicates that cbpolicyd (Cluebringer) cannot load the required Perl database driver. Root CausePolicyd 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 BehaviorAlmaLinux 8 (EL8)Policyd requires: perl-DBD-MySQL The configuration remains in /etc/cbpolicyd/cbpolicyd.conf DSN=DBI:mysql:database=postfix_policyd;host=localhostInstalling 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-MariaDBThen update the Policyd configuration: Edit: /etc/cbpolicyd/cbpolicyd.confReplace: DSN=DBI:mysql:database=postfix_policyd;host=localhostWith: DSN=DBI:MariaDB:database=postfix_policyd;host=localhostThis forces Policyd to load the DBD::MariaDB driver instead of DBD::mysql. After modification: systemctl restart cbpolicyd systemctl restart postfixKey TakeawayEL8 → 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 actually bought CWP PRO the other day, it is a shame their forum is down a lot and i can't create a new account when it is online. But this forum has been useful a lot, i actually tried with AL8 for the first time using just to learn more how it works. Will try to update to AL9 once i understand it better.

Still CWP Pro with EL9 based op.system. It's true that it needs some tweaking after installation, but it still offers far better services than other alternatives.

@SubZero5 Something was missing to run the installation script, but I can't see what it is.

Unfortunately that doesn't work on CWP. :/ Step 5 is specific to Plesk.

Hello everyone, as of 2026 what control panel do you guys recommend with mail services, support for node.js, postgresql and wordpress? Not really inside all these control panel lists.

Over the years I made some sloppy edits and god knows what tech support might have done DNS records. 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. IntroductionManaging 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 ValueThe 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 ConfigurationCloudflare API IntegrationSecurity 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 httpx4. Local BIND Audit & CorrectionBefore 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 SynchronizationWe 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 --run6. Global Deliverability ChecklistSPF: 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.