Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Updates / Re: CWP 1.8 – Can we have a clear Production Readiness / Fixed Issues list?
« on: August 13, 2026, 07:28:49 AM »
It's fine to use AI, but tone it down a bit. Ask them to use BBCode instead of Markdown.
2
DKIM / CWP 1.7 on AlmaLinux 9: DKIM Generated but Not Applied by Postfix
« on: August 09, 2026, 12:30:14 AM »- Control panel: CWP 1.7
- Operating system: AlmaLinux 9.8
- MTA: Postfix
- DKIM service: OpenDKIM
- Mail filtering: Amavis
CWP generated the DKIM key and the corresponding DNS record correctly. The CWP interface showed Install DKIM & SPF enabled, and the OpenDKIM service was running.
However, messages sent to external providers arrived with:
Code: [Select]
dkim=none (message not signed)
spf=pass
dmarc=pass
The local OpenDKIM key test was successful:
Code: [Select]
opendkim-testkey -d example.tld -s default -vvv
key OK
The problem was not the DKIM key or the DNS record. Postfix was not connected to OpenDKIM.
Diagnosis
After using Rebuild Mail Server, CWP recorded:
Code: [Select]
dkimspf = 1
However, the effective Postfix configuration did not contain:
Code: [Select]
smtpd_milters
non_smtpd_milters
content_filter
The SMTP service for Amavis existed in
Code: [Select]
master.cf, but the line connecting Postfix to Amavis was commented:Code: [Select]
# -o content_filter=smtp-amavis:127.0.0.1:10024
Therefore, CWP generated the DKIM infrastructure, but the outgoing Postfix delivery path did not use OpenDKIM.
Solution
The integration was added directly to
Code: [Select]
/etc/postfix/main.cf:Code: [Select]
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
milter_default_action = accept
milter_protocol = 6
No internal CWP scripts were modified.
After reloading Postfix, the active configuration showed:
Code: [Select]
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
milter_default_action = accept
milter_protocol = 6
External validation
Test messages were sent to Gmail and Outlook.
Gmail reported:
Code: [Select]
dkim=pass
spf=pass
dmarc=pass
Outlook reported:
Code: [Select]
dkim=pass
spf=pass
dmarc=pass
compauth=pass
Conclusion
In this installation, CWP generated the DKIM keys and DNS records correctly, but the mail server rebuild did not connect Postfix to OpenDKIM.
Adding the local OpenDKIM milter settings to Postfix resolved the issue without modifying CWP internal scripts.
3
Updates / Migration experience: AlmaLinux 8 to AlmaLinux 9 with CWP 1.7
« on: August 03, 2026, 12:28:09 PM »[size=150]Successful migration between two CWP 1.7 servers[/size]
Summary
I would like to share a recent experience migrating a hosting account between two servers running Control Web Panel (CWP).
The source server runs AlmaLinux 8.1 and the destination server runs AlmaLinux 9.8. Both servers run CWP 1.7.
The migration was performed using the native CWP-to-CWP migration procedure provided by the panel.
Background
The source server originally ran CentOS 7 and was later upgraded to AlmaLinux 8.1. That process was difficult and involved many problems. Each script failure was analyzed, patched, and tested until the migration was finally completed.
During the first two account migration attempts between these servers, CWP reported that the operation had completed successfully. However, manual work was still required to finish the transfers.
For the third attempt, the decision was made to use only the native CWP migration procedure and carefully verify the result afterwards.
Environment
- Source server: AlmaLinux 8.1.
- Destination server: AlmaLinux 9.8.
- CWP on both servers: version 1.7.
- CWP on both package: cwpsrv 1.24.0-2.
- Services involved: Apache, Nginx, Postfix, Dovecot, DNS, and FTP.
Migration result
CWP successfully completed the main migration stages:
- Account creation.
- Home directory transfer.
- Migration of the account structure.
- Creation of domains and subdomains.
- Creation of email accounts.
- Restoration of the associated configuration.
The account contained a static website. A comparison between the source and destination servers confirmed that the public files were present, and rsync was not required to complete the transfer.
The minor differences detected were related to CWP metadata and internal state files, not to the website content.
Database
The migration included the internal database associated with the account, managed by CWP as part of the common account structure.
No manual database work was required.
The account contained eight mailboxes.
All mailboxes were created successfully on the destination server. The mailboxes were empty, except for one mailbox containing a single message. That message was also preserved during the migration.
Afterwards, the appropriate certificates had to be installed so that CWP could generate the correct mail server name for secure IMAP, POP3, and SMTP connections.
Post-migration verification
The following components were checked:
- Account files.
- Domains and subdomains.
- DNS zones.
- Apache and Nginx virtual hosts.
- Apache and Nginx configuration syntax.
- Email accounts and mailbox structure.
- TLS certificates for the mail services.
Conclusion
After two previous attempts that required manual work, the third attempt was successful using the native CWP procedure.
It was not necessary to:
- Transfer files manually with rsync.
- Modify internal CWP scripts.
- Rebuild virtual hosts manually.
- Create email accounts manually.
- Restore the account structure manually.
The manual intervention was limited to verifying the result and installing the mail certificates.
This experience shows that CWP 1.7 can successfully perform a CWP-to-CWP migration between AlmaLinux 8.1 and AlmaLinux 9.8, provided that the result is verified after restoration instead of relying solely on the “All files were copied” message.
After all the work performed on the source server since its former CentOS 7 installation, and after seeing the result of this migration, both VPSs finally provide a renewed sense of stability.
Third time lucky.
Question for the community
Has anyone else performed CWP-to-CWP migrations between AlmaLinux 8 and AlmaLinux 9 using CWP 1.7? Have you noticed differences between previous versions and the current migration procedure?
5
Updates / Re: CWP 1.6 update from 1.4: ModSec, Firewall, Yum, New Ba
« on: August 01, 2026, 09:37:27 PM »"3. Yum Manager (FIXED)
This module is finally working flawlessly. It no longer gets stuck on "checking for updates" nor returns 404 errors. It properly syncs with the OS package manager in the background and displays the green "All packages are up to date!" badge accurately, mirroring terminal updates."
When I click on installed packages i get a blank list. Does yours work?
Hi! Yes, I am experiencing the exact same issue after upgrading to CWP 1.6, and I have found the root cause.
The blank list is a Front-End rendering issue caused by a broken file path (hardcoded error) in the new update. When you open the browser's developer console, you will see that the page breaks because it fails to load a JavaScript dependency:
* It throws a 404 Not Found error for: /admin/design/charts/sparklines/jquery.sparkline.js
* Because this file fails to load, it crashes the subsequent jQuery scripts, preventing .DataTable() from initializing and drawing the list of packages.
The file actually exists on the server filesystem (/usr/local/cwpsrv/htdocs/admin/design/plugins/...), but the developers accidentally omitted the /plugins/ directory in the source code of the yum_manager module.
So it's a general bug in this release that CWP developers need to hotfix in the next build.
Regards,
6
Updates / [BUG] Yum Manager - "Installed Packages" blank table root cause found (CWP 1.6)
« on: August 01, 2026, 09:35:14 PM »
Confirmed Diagnosis: Path bug in Yum Manager module (CWP 1.6)
Hello everyone,
I confirm the cause of the failure regarding the blank table in "Installed Packages". This is not an issue with AlmaLinux 8 or dnf commands on my VPS, but rather a static path bug introduced in the web interface of v1.6 or possibly earlier.
Details of the finding:
1. Upon loading the page, the web console throws a 404 Not Found error trying to fetch the script from:
.../admin/design/charts/sparklines/jquery.sparkline.js
2. When checking the internal directory tree of cwpsrv, the actual file is located under an additional subfolder:
/usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparklines/jquery.sparkline.js
For the CWP development team:
There is an omission of the /plugins/ directory in the sparklines script call within the backend of the yum_manager PHP file. This error halts the execution of subsequent scripts and prevents the initialization of the .DataTable() function, which is responsible for rendering the package list in the GUI.
Hello everyone,
I confirm the cause of the failure regarding the blank table in "Installed Packages". This is not an issue with AlmaLinux 8 or dnf commands on my VPS, but rather a static path bug introduced in the web interface of v1.6 or possibly earlier.
Details of the finding:
1. Upon loading the page, the web console throws a 404 Not Found error trying to fetch the script from:
.../admin/design/charts/sparklines/jquery.sparkline.js
2. When checking the internal directory tree of cwpsrv, the actual file is located under an additional subfolder:
/usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparklines/jquery.sparkline.js
For the CWP development team:
There is an omission of the /plugins/ directory in the sparklines script call within the backend of the yum_manager PHP file. This error halts the execution of subsequent scripts and prevents the initialization of the .DataTable() function, which is responsible for rendering the package list in the GUI.
7
Updates / Re: CWP 1.5 / cwpsrv-1.24.0-2 update: Are GUI modules -ModSec, Firewall, Yum, New Ba
« on: August 01, 2026, 12:34:33 PM »Would help to know what OS you are running?
As it seems some OS'es are working OK, while others aren't.
AL8 was the crossover from YUM to DNF, either worked, but on AL9 and later dnf should be used.
I have two VPS running AL8 and AL9. At first, AL8 gave me more trouble and required more attention, but right now the situation is equally precarious on both. So far, I am managing to keep the VPS operational.Note: The AL8 is an upgrade from CentOS 7, which took quite a lot of work.
8
Updates / CWP 1.6 update from 1.4: ModSec, Firewall, Yum, New Ba
« on: July 31, 2026, 06:06:21 AM »
Hello community,
I have two production servers running under AlmaLinux (EL9 environment). I took the risk and updated them straight to CWPpro version 1.6 to verify if the critical frontend bugs introduced in the previous cwpsrv-1.24.0-2 build were finally addressed.
After running deep diagnostics both via web and terminal commands, here are the real-world results point by point:
1. ModSecurity Manager (STILL BROKEN)
Even though the backend engine is up and running perfectly on the Apache/Nginx environment (actively intercepting real-time exploits as verified in modsec_audit.log), the CWP GUI framework is completely broken. It stays trapped in an infinite loop showing the "Starting module" spinner indefinitely.
2. Firewall Manager (PARTIALLY SOLVED / INTERFACE CONFLICT)
The old navigation paths from the left sidebar are experiencing severe issues and mismatches:
* Menu > CSF Firewall (csf) | No changes (remains legacy).
* Menu > Firewall Manager (firewallv2) | Displays the new interface. It is safe to assume this modern UI will replace the older version.
* Menu > Mod Security (mod_security) | The interface does not load. Furthermore, a severe JavaScript/jQuery conflict exists within this section: once loaded, it completely freezes the interactivity of the left navigation menu, forcing you to reload the main Dashboard page to recover control of the panel.
* Dashboard > Firewall Shield Icon (firewall) | Launches the traditional "Firewall Manager" interface. This classic UI seems to be deprecated and currently being replaced by the new firewallv2.
3. Yum Manager (FIXED)
This module is finally working flawlessly. It no longer gets stuck on "checking for updates" nor returns 404 errors. It properly syncs with the OS package manager in the background and displays the green "All packages are up to date!" badge accurately, mirroring terminal updates.
4. New Backup Module Email Reports (STILL BROKEN)
Your complaint regarding the email alert logs is 100% accurate. Checking the backend log files (/var/log/cwp/cwp_backup.log), CWP only prints a raw execution timestamp line (e.g., Thu Jul 30 03:48:11 -03 2026). It completely lacks any granular details regarding local/remote delivery, individual account success status, or secondary domain metrics. This makes the email notifications completely vague.
5. Final Verdict / Recommendation
If you heavily rely on a working ModSecurity GUI or pristine backup report insights, do not update your production environment yet. Stay on your current stable version and wait for a cleaner release. While the underlying backend services (CSF, Apache, and ModSec rules) remain completely solid and secure, the frontend template engine in CWP 1.6 still carries multiple unresolved script overlaps.
I have two production servers running under AlmaLinux (EL9 environment). I took the risk and updated them straight to CWPpro version 1.6 to verify if the critical frontend bugs introduced in the previous cwpsrv-1.24.0-2 build were finally addressed.
After running deep diagnostics both via web and terminal commands, here are the real-world results point by point:
1. ModSecurity Manager (STILL BROKEN)
Even though the backend engine is up and running perfectly on the Apache/Nginx environment (actively intercepting real-time exploits as verified in modsec_audit.log), the CWP GUI framework is completely broken. It stays trapped in an infinite loop showing the "Starting module" spinner indefinitely.
2. Firewall Manager (PARTIALLY SOLVED / INTERFACE CONFLICT)
The old navigation paths from the left sidebar are experiencing severe issues and mismatches:
* Menu > CSF Firewall (csf) | No changes (remains legacy).
* Menu > Firewall Manager (firewallv2) | Displays the new interface. It is safe to assume this modern UI will replace the older version.
* Menu > Mod Security (mod_security) | The interface does not load. Furthermore, a severe JavaScript/jQuery conflict exists within this section: once loaded, it completely freezes the interactivity of the left navigation menu, forcing you to reload the main Dashboard page to recover control of the panel.
* Dashboard > Firewall Shield Icon (firewall) | Launches the traditional "Firewall Manager" interface. This classic UI seems to be deprecated and currently being replaced by the new firewallv2.
3. Yum Manager (FIXED)
This module is finally working flawlessly. It no longer gets stuck on "checking for updates" nor returns 404 errors. It properly syncs with the OS package manager in the background and displays the green "All packages are up to date!" badge accurately, mirroring terminal updates.
4. New Backup Module Email Reports (STILL BROKEN)
Your complaint regarding the email alert logs is 100% accurate. Checking the backend log files (/var/log/cwp/cwp_backup.log), CWP only prints a raw execution timestamp line (e.g., Thu Jul 30 03:48:11 -03 2026). It completely lacks any granular details regarding local/remote delivery, individual account success status, or secondary domain metrics. This makes the email notifications completely vague.
5. Final Verdict / Recommendation
If you heavily rely on a working ModSecurity GUI or pristine backup report insights, do not update your production environment yet. Stay on your current stable version and wait for a cleaner release. While the underlying backend services (CSF, Apache, and ModSec rules) remain completely solid and secure, the frontend template engine in CWP 1.6 still carries multiple unresolved script overlaps.
9
Updates / Re: CWP 1.5 / cwpsrv-1.24.0-2 update: Are GUI modules -ModSec, Firewall, Yum, New Ba
« on: July 31, 2026, 06:04:34 AM »
Hello xWeb,
I have two production servers running under AlmaLinux (EL9 environment). I took the risk and updated them straight to CWPpro version 1.6 to verify if the critical frontend bugs introduced in the previous cwpsrv-1.24.0-2 build were finally addressed.
After running deep diagnostics both via web and terminal commands, here are the real-world results point by point:
1. ModSecurity Manager (STILL BROKEN)
Even though the backend engine is up and running perfectly on the Apache/Nginx environment (actively intercepting real-time exploits as verified in modsec_audit.log), the CWP GUI framework is completely broken. It stays trapped in an infinite loop showing the "Starting module" spinner indefinitely.
2. Firewall Manager (PARTIALLY SOLVED / INTERFACE CONFLICT)
The old navigation paths from the left sidebar are experiencing severe issues and mismatches:
* Menu > CSF Firewall (csf) | No changes (remains legacy).
* Menu > Firewall Manager (firewallv2) | Displays the new interface. It is safe to assume this modern UI will replace the older version.
* Menu > Mod Security (mod_security) | The interface does not load. Furthermore, a severe JavaScript/jQuery conflict exists within this section: once loaded, it completely freezes the interactivity of the left navigation menu, forcing you to reload the main Dashboard page to recover control of the panel.
* Dashboard > Firewall Shield Icon (firewall) | Launches the traditional "Firewall Manager" interface. This classic UI seems to be deprecated and currently being replaced by the new firewallv2.
3. Yum Manager (FIXED)
This module is finally working flawlessly. It no longer gets stuck on "checking for updates" nor returns 404 errors. It properly syncs with the OS package manager in the background and displays the green "All packages are up to date!" badge accurately, mirroring terminal updates.
4. New Backup Module Email Reports (STILL BROKEN)
Your complaint regarding the email alert logs is 100% accurate. Checking the backend log files (/var/log/cwp/cwp_backup.log), CWP only prints a raw execution timestamp line (e.g., Thu Jul 30 03:48:11 -03 2026). It completely lacks any granular details regarding local/remote delivery, individual account success status, or secondary domain metrics. This makes the email notifications completely vague.
5. Final Verdict / Recommendation
If you heavily rely on a working ModSecurity GUI or pristine backup report insights, do not update your production environment yet. Stay on your current stable version and wait for a cleaner release. While the underlying backend services (CSF, Apache, and ModSec rules) remain completely solid and secure, the frontend template engine in CWP 1.6 still carries multiple unresolved script overlaps.
Hope this field feedback helps the community make an informed decision!
I have two production servers running under AlmaLinux (EL9 environment). I took the risk and updated them straight to CWPpro version 1.6 to verify if the critical frontend bugs introduced in the previous cwpsrv-1.24.0-2 build were finally addressed.
After running deep diagnostics both via web and terminal commands, here are the real-world results point by point:
1. ModSecurity Manager (STILL BROKEN)
Even though the backend engine is up and running perfectly on the Apache/Nginx environment (actively intercepting real-time exploits as verified in modsec_audit.log), the CWP GUI framework is completely broken. It stays trapped in an infinite loop showing the "Starting module" spinner indefinitely.
2. Firewall Manager (PARTIALLY SOLVED / INTERFACE CONFLICT)
The old navigation paths from the left sidebar are experiencing severe issues and mismatches:
* Menu > CSF Firewall (csf) | No changes (remains legacy).
* Menu > Firewall Manager (firewallv2) | Displays the new interface. It is safe to assume this modern UI will replace the older version.
* Menu > Mod Security (mod_security) | The interface does not load. Furthermore, a severe JavaScript/jQuery conflict exists within this section: once loaded, it completely freezes the interactivity of the left navigation menu, forcing you to reload the main Dashboard page to recover control of the panel.
* Dashboard > Firewall Shield Icon (firewall) | Launches the traditional "Firewall Manager" interface. This classic UI seems to be deprecated and currently being replaced by the new firewallv2.
3. Yum Manager (FIXED)
This module is finally working flawlessly. It no longer gets stuck on "checking for updates" nor returns 404 errors. It properly syncs with the OS package manager in the background and displays the green "All packages are up to date!" badge accurately, mirroring terminal updates.
4. New Backup Module Email Reports (STILL BROKEN)
Your complaint regarding the email alert logs is 100% accurate. Checking the backend log files (/var/log/cwp/cwp_backup.log), CWP only prints a raw execution timestamp line (e.g., Thu Jul 30 03:48:11 -03 2026). It completely lacks any granular details regarding local/remote delivery, individual account success status, or secondary domain metrics. This makes the email notifications completely vague.
5. Final Verdict / Recommendation
If you heavily rely on a working ModSecurity GUI or pristine backup report insights, do not update your production environment yet. Stay on your current stable version and wait for a cleaner release. While the underlying backend services (CSF, Apache, and ModSec rules) remain completely solid and secure, the frontend template engine in CWP 1.6 still carries multiple unresolved script overlaps.
Hope this field feedback helps the community make an informed decision!
10
Updates / Re: CWP version 1.3 and 1.4 issues
« on: July 30, 2026, 07:01:07 AM »
Virtually the same problems in AlmaLinux 8 and 9.
11
E-Mail / CBPolicyD: Source 'any' is not a valid specification
« on: July 12, 2024, 07:31:12 PM »Hello CWP Community,
I hope this message finds everyone well. I am currently facing an issue with my CentOS 7.9.2009 server and would appreciate any assistance or insights you can provide.
Problem Description:
I am encountering the following error in the logs:
Quote
Source 'any' is not a valid specification
Server Configuration:
- CentOS Version: 7.9.2009 (Core)
- Kernel: 3.10.0-1160.119.1.el7.x86_64
- Active Services:
- Apache Webserver: Active
- Nginx Reverse Proxy: Active
- BIND DNS Server: Active
- SSH Server: Active
- Postfix Mail Server: Active
- Dovecot IMAP/POP3 Server: Active
- ClamAV: Active
- AMaViS: Active
- OpenDKIM: Active
- SpamAssassin: Active
- CBPolicyD: Active
Steps Taken:
1. Checked policies in CWP panel, especially policy IDs 6 (Default Server Limit) and 7 (package_default).
2. Verified configuration files manually:
Code: [Select]
/etc/cbpolicyd/cluebringer.conf
/etc/cbpolicyd/webui.conf
4. Restarted services:Code: [Select]
systemctl restart cbpolicyd
systemctl restart postfix
5. Monitored logs using:Code: [Select]
tail -f /var/log/messages
Jul 12 16:14:14 srv5us3 cbpolicyd: [2024/07/12-16:14:14 - 2467] [POLICIES] WARNING: [ID:6/Name:Default Server Limit]=>(group:cwp_domains): - Source 'any' is not a valid specification
Jul 12 16:14:14 srv5us3 cbpolicyd: [2024/07/12-16:14:14 - 2467] [POLICIES] WARNING: [ID:7/Name:Default Server Limit]=>(group:cwp_domains): - Source 'any' is not a valid specification
Jul 12 16:14:15 srv5us3 cbpolicyd: [2024/07/12-16:14:15 - 2465] [POLICIES] WARNING: [ID:6/Name:Default Server Limit]=>(group:cwp_domains): - Source 'any' is not a valid specification
Jul 12 16:14:15 srv5us3 cbpolicyd: [2024/07/12-16:14:15 - 2465] [POLICIES] WARNING: [ID:7/Name:Default Server Limit]=>(group:cwp_domains): - Source 'any' is not a valid specification
Current Situation:
Despite these steps, the error persists. I have also reduced the maximum emails allowed in policies 6 and 7 to 25 and 20 respectively. I am now looking to identify the exact file where these changes are stored to further troubleshoot the issue.
Any advice or guidance on resolving this error would be greatly appreciated.
Thank you in advance for your support!
Best regards,
12
CentOS 7 Problems / Re: SSL DNS Error
« on: December 14, 2020, 07:53:17 PM »Auto SSL not working today.
Getting error: DNS of your domain doesn't point to this server or you have htaccess restrictions.
Everything is up-to-date and DNS is right.
Can fix restart the server.
13
CentOS 7 Problems / Re: Fresh install cwp in centos 7, phpmyadmin error 404
« on: August 03, 2020, 04:29:35 AM »Sorry about the late reply, I have successfully fix the problem with first way. Thanks very muchHi, How to fix the problem. I have the same problem.
Pages: [1]
