All Activity

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.

I saw something like this: https://support.plesk.com/hc/en-us/articles/16552367086231-How-to-create-TLSA-DNS-record-in-Plesk-and-adjust-DANE