Recent Posts
31
Updates / Re: Alma 9 / 1.3 Update
« Last post by zakrpa on July 29, 2026, 09:10:23 AM »so I was right about script error, had to test it on empty server to confirm last night.
My fix was just rebuilding all again with new apache and vhosts, after that only thing I noticed are these menu module problems and that httpd conf files are overwriten too, in folders where index.html (cwp test page) left undeleted are loaded as default.
Your problem isn't with cwpsrv.
cwp-httpd did an update to 2.4.68-1 at the same time, if you look at the error Apache is throwing, you should be able to track down what happened.
My fix was just rebuilding all again with new apache and vhosts, after that only thing I noticed are these menu module problems and that httpd conf files are overwriten too, in folders where index.html (cwp test page) left undeleted are loaded as default.
32
CentOS-WebPanel Bugs / Re: Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by David on July 29, 2026, 08:45:11 AM »Hello
I installed a pristine Almalinux 9 from scratch and the latest CWP PRO 1.4 as per manual instructions, unfortunately many things are not going quite right.
I too stumbled upon the yum update panel getting stuck in infinite loop, does nothing, can't complete the checks to show if there is anything to update, but also in the other tabs "Installed Packages", "Repositories", "Yum History", "Log Viewer" does show nothing.
There are more problems tough.
Just after install as usual one receive popup notifications telling to enable the firewall, secure the processes and few other alike. Clicking the one that tells to enable the firewall one lands onto the "firewall manager" panel, in this panel trying to enable the firewall results into nothing, the firewall keeps staying disabled, anything done in this panel looks like doing nothing, the firewall manager seems dead.
So I went to security> CSF firewall, clicked enable here, and again apparently nothing happens, clicking on security>firewall manager come out a blank page telling "The module firewallv2 does not exist."
Clicking security>mod security the mod_security panel comes up, does show only the circling wheel, again nothing happens, it indefinitely loops to no avail
Also the already seen "Unauthorized port: php-fpm" popped up, no further info nor tips this time...
Trying the php_switch_v2 panel, selecting a PHP version, Switching to PHP version: 8.3.31, results into a looping circle, does not work
In the PHP-FPM Selector V2 and V3 choosing a PHP version and trying to compile/install it does not activate the "save&build" button
Just out of curiousity I also tried to build webserver, I did chose nginx only, seemed to work, but I did not test it so far...
Overall to me the CWP 1.4 seems mangled, I did not dig further and hope a fix soon comes up... :S
I installed a pristine Almalinux 9 from scratch and the latest CWP PRO 1.4 as per manual instructions, unfortunately many things are not going quite right.
I too stumbled upon the yum update panel getting stuck in infinite loop, does nothing, can't complete the checks to show if there is anything to update, but also in the other tabs "Installed Packages", "Repositories", "Yum History", "Log Viewer" does show nothing.
There are more problems tough.
Just after install as usual one receive popup notifications telling to enable the firewall, secure the processes and few other alike. Clicking the one that tells to enable the firewall one lands onto the "firewall manager" panel, in this panel trying to enable the firewall results into nothing, the firewall keeps staying disabled, anything done in this panel looks like doing nothing, the firewall manager seems dead.
So I went to security> CSF firewall, clicked enable here, and again apparently nothing happens, clicking on security>firewall manager come out a blank page telling "The module firewallv2 does not exist."
Clicking security>mod security the mod_security panel comes up, does show only the circling wheel, again nothing happens, it indefinitely loops to no avail
Also the already seen "Unauthorized port: php-fpm" popped up, no further info nor tips this time...
Trying the php_switch_v2 panel, selecting a PHP version, Switching to PHP version: 8.3.31, results into a looping circle, does not work
In the PHP-FPM Selector V2 and V3 choosing a PHP version and trying to compile/install it does not activate the "save&build" button
Just out of curiousity I also tried to build webserver, I did chose nginx only, seemed to work, but I did not test it so far...
Overall to me the CWP 1.4 seems mangled, I did not dig further and hope a fix soon comes up... :S
33
CentOS-WebPanel Bugs / Re: Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by 6Sense on July 29, 2026, 08:42:50 AM »I posted earlier on another post but this should get you around the 404 error that affects the modsec module UI by copying the JS UI components it wants to where its looking for them. At least until it's patched.
Refresh the browser and all done.
I can't find a work around for the misbehaving Yum page as it's called by an API & I can't see past it. Desipte this dnf update in terminal still works fine for me (Alma 8 here).
/cheer @Netino for showing the way
Code: [Select]
cd /usr/local/cwpsrv/htdocs/admin/design/
chattr -i .
mkdir charts
# use your prefered method to copy the following folders & contents to the new charts folder you created /usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparkline & /usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparklines (I simply used the CWP File Manager copy option)
chattr +i .
Refresh the browser and all done.
I can't find a work around for the misbehaving Yum page as it's called by an API & I can't see past it. Desipte this dnf update in terminal still works fine for me (Alma 8 here).
/cheer @Netino for showing the way
34
I can build it / Re: Want to hire a sysadmin
« Last post by cgauthey on July 29, 2026, 06:40:26 AM »I use 24server management for my server; they respond in just a few minutes and fix things and do everything for you. https://24x7servermanagement.com/centos-server-management/
The best!
The best!
35
CentOS-WebPanel Bugs / Re: Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by cgauthey on July 29, 2026, 06:28:09 AM »I contacted José on Telegram; I think he should see the message and step in quickly.
36
CentOS-WebPanel Bugs / Re: Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by Jamshed Datori on July 29, 2026, 06:23:32 AM »+
Facing the same issue.
Facing the same issue.
37
CentOS-WebPanel Bugs / Re: Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by dmzx on July 29, 2026, 06:05:25 AM »The 404 and the stuck module are two independent bugs. zakrpa spotted the 404
in the Alma 9 / 1.3 thread and noted that fixing it doesn't resolve the stuck
modules — correct, because the hang has a different cause.
Root cause of the hang: jQuery is loaded twice, in two different versions.
design/img/js.php (head) -> jQuery 1.7.1
design/js/libs/jquery-2.1.1.min.js (footer) -> jQuery 2.1.1
DataTables is injected mid-body (design/3rdparty/datatables/js/
jquery.dataTables.min.js, HTTP 200, loads fine) and registers on the jQuery
active at that moment: 1.7.1. The footer script then replaces window.jQuery and
$ with a fresh 2.1.1 instance. When document.ready fires, $ resolves to 2.1.1,
which has no .dataTable.
Verified in console on a stuck mod_security page:
$.fn.jquery -> "2.1.1"
typeof $.fn.dataTable -> "undefined"
and the module dies at:
Uncaught TypeError: Cannot read properties of undefined (reading 'ext')
at $.fn.dataTable.ext.search.push(...)
That handler is what calls initModSecModule(), so the spinner never resolves
and no XHR is ever sent — the server never receives a module request at all.
The backend is fine; the page renders correct data (cwp_pro, modsec_installed,
domains_list are all populated).
Affected on my server, all with the same console error: mod_security,
yum_manager, php_switch_v2, firewallv2, csf. Modules whose plugins load after
the footer jQuery work normally — list_accounts renders its DataTable fine.
The separate 404: the template requests
design/charts/sparklines/jquery.sparkline.js
while the file ships at
design/plugins/charts/sparklines/jquery.sparkline.js
That only breaks the sparklines in blank.js.
For anyone thinking of symlinking around it: /usr/local/cwpsrv/htdocs/admin/
and all of design/ are chattr +i, so it can't be worked around locally. Both
issues need a vendor fix.
Environment: AlmaLinux 8.10, cwpsrv-1.24.0-2, cwpphp-7.2.30-3.
in the Alma 9 / 1.3 thread and noted that fixing it doesn't resolve the stuck
modules — correct, because the hang has a different cause.
Root cause of the hang: jQuery is loaded twice, in two different versions.
design/img/js.php (head) -> jQuery 1.7.1
design/js/libs/jquery-2.1.1.min.js (footer) -> jQuery 2.1.1
DataTables is injected mid-body (design/3rdparty/datatables/js/
jquery.dataTables.min.js, HTTP 200, loads fine) and registers on the jQuery
active at that moment: 1.7.1. The footer script then replaces window.jQuery and
$ with a fresh 2.1.1 instance. When document.ready fires, $ resolves to 2.1.1,
which has no .dataTable.
Verified in console on a stuck mod_security page:
$.fn.jquery -> "2.1.1"
typeof $.fn.dataTable -> "undefined"
and the module dies at:
Uncaught TypeError: Cannot read properties of undefined (reading 'ext')
at $.fn.dataTable.ext.search.push(...)
That handler is what calls initModSecModule(), so the spinner never resolves
and no XHR is ever sent — the server never receives a module request at all.
The backend is fine; the page renders correct data (cwp_pro, modsec_installed,
domains_list are all populated).
Affected on my server, all with the same console error: mod_security,
yum_manager, php_switch_v2, firewallv2, csf. Modules whose plugins load after
the footer jQuery work normally — list_accounts renders its DataTable fine.
The separate 404: the template requests
design/charts/sparklines/jquery.sparkline.js
while the file ships at
design/plugins/charts/sparklines/jquery.sparkline.js
That only breaks the sparklines in blank.js.
For anyone thinking of symlinking around it: /usr/local/cwpsrv/htdocs/admin/
and all of design/ are chattr +i, so it can't be worked around locally. Both
issues need a vendor fix.
Environment: AlmaLinux 8.10, cwpsrv-1.24.0-2, cwpphp-7.2.30-3.
38
Updates / Re: cwpsrv 1.24.0-2 overwrites cwpsrv.conf — service fails to start (missing hostnam
« Last post by dmzx on July 29, 2026, 06:04:35 AM »Confirming this on another server: AlmaLinux 8.10, cwpsrv-1.24.0-2 installed
2026-07-28 03:37. Same failure, but it stayed latent until a reboot the next
morning — worth adding, because others may only hit this weeks from now.
Two findings:
1) hostname.crt is a dead artifact — hostname.bundle is canonical.
The only script that writes hostname.crt is /scripts/generate_hostname_ssl
(line 137), and that runs only on install or hostname change. The renewal
chain is:
/etc/cron.daily/cwp_acme.sh -> acme.sh -> /scripts/hostname_ssl_restart_services
and that works exclusively with hostname.bundle (deriving hostname.pem from it
for postfix/dovecot/pure-ftpd). So after any AutoSSL renewal, .key/.cert/.bundle
are fresh while .crt is stale — key/cert mismatch at the next cwpsrv start.
Note that CWP's own generate_hostname_ssl (lines 171-184) sets all four cwpsrv
confs to hostname.bundle, and conf.d/api.conf already ships that way. The RPM
templates contradict CWP's own script.
2) The failure is silent until reboot.
hostname_ssl_restart_services runs "service cwpsrv reload". With a broken config
the reload fails, the exit code is ignored, and the running master keeps serving
the old certificate from memory. On my server the cert renewed on 11 July and
the panel kept working until a kernel update rebooted the box on 29 July —
then ERR_CONNECTION_REFUSED, restart counter at 602.
On the workarounds circulating in the other thread: symlinking or copying
hostname.cert gives you the leaf only, without the intermediate chain. Browsers
often mask this by caching intermediates, but API clients and curl will fail.
Use the bundle instead:
cp -a /etc/pki/tls/certs/hostname.bundle /etc/pki/tls/certs/hostname.crt
Or point the confs at hostname.bundle directly:
sed -i 's#/etc/pki/tls/certs/hostname\.crt#/etc/pki/tls/certs/hostname.bundle#g' \
/usr/local/cwpsrv/conf/cwpsrv.conf \
/usr/local/cwpsrv/conf.d/{user-api,users,webmail}.conf
/usr/local/cwpsrv/bin/cwpsrv -t && systemctl reload cwpsrv
Always verify before starting:
openssl rsa -noout -modulus -in /etc/pki/tls/private/hostname.key | openssl md5
openssl x509 -noout -modulus -in /etc/pki/tls/certs/hostname.bundle | openssl md5
And a warning: do NOT run generate_hostname_ssl as a fix. It replaces a valid
Let's Encrypt hostname certificate with a CWP self-signed one and restarts
postfix, dovecot, cwpsrv, httpd, nginx and pure-ftpd in sequence.
Requests for CWP:
- Ship the cwpsrv conf templates pointing to hostname.bundle, matching
generate_hostname_ssl.
- Mark the conf files %config(noreplace), or at minimum write .rpmsave.
- Have hostname_ssl_restart_services check the exit code of "cwpsrv -t" and
log a failure, instead of leaving a reload that silently did nothing.
2026-07-28 03:37. Same failure, but it stayed latent until a reboot the next
morning — worth adding, because others may only hit this weeks from now.
Two findings:
1) hostname.crt is a dead artifact — hostname.bundle is canonical.
The only script that writes hostname.crt is /scripts/generate_hostname_ssl
(line 137), and that runs only on install or hostname change. The renewal
chain is:
/etc/cron.daily/cwp_acme.sh -> acme.sh -> /scripts/hostname_ssl_restart_services
and that works exclusively with hostname.bundle (deriving hostname.pem from it
for postfix/dovecot/pure-ftpd). So after any AutoSSL renewal, .key/.cert/.bundle
are fresh while .crt is stale — key/cert mismatch at the next cwpsrv start.
Note that CWP's own generate_hostname_ssl (lines 171-184) sets all four cwpsrv
confs to hostname.bundle, and conf.d/api.conf already ships that way. The RPM
templates contradict CWP's own script.
2) The failure is silent until reboot.
hostname_ssl_restart_services runs "service cwpsrv reload". With a broken config
the reload fails, the exit code is ignored, and the running master keeps serving
the old certificate from memory. On my server the cert renewed on 11 July and
the panel kept working until a kernel update rebooted the box on 29 July —
then ERR_CONNECTION_REFUSED, restart counter at 602.
On the workarounds circulating in the other thread: symlinking or copying
hostname.cert gives you the leaf only, without the intermediate chain. Browsers
often mask this by caching intermediates, but API clients and curl will fail.
Use the bundle instead:
cp -a /etc/pki/tls/certs/hostname.bundle /etc/pki/tls/certs/hostname.crt
Or point the confs at hostname.bundle directly:
sed -i 's#/etc/pki/tls/certs/hostname\.crt#/etc/pki/tls/certs/hostname.bundle#g' \
/usr/local/cwpsrv/conf/cwpsrv.conf \
/usr/local/cwpsrv/conf.d/{user-api,users,webmail}.conf
/usr/local/cwpsrv/bin/cwpsrv -t && systemctl reload cwpsrv
Always verify before starting:
openssl rsa -noout -modulus -in /etc/pki/tls/private/hostname.key | openssl md5
openssl x509 -noout -modulus -in /etc/pki/tls/certs/hostname.bundle | openssl md5
And a warning: do NOT run generate_hostname_ssl as a fix. It replaces a valid
Let's Encrypt hostname certificate with a CWP self-signed one and restarts
postfix, dovecot, cwpsrv, httpd, nginx and pure-ftpd in sequence.
Requests for CWP:
- Ship the cwpsrv conf templates pointing to hostname.bundle, matching
generate_hostname_ssl.
- Mark the conf files %config(noreplace), or at minimum write .rpmsave.
- Have hostname_ssl_restart_services check the exit code of "cwpsrv -t" and
log a failure, instead of leaving a reload that silently did nothing.
39
CentOS-WebPanel Bugs / Re: Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by anandmys on July 29, 2026, 05:53:41 AM »+1
40
CentOS-WebPanel Bugs / Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404
« Last post by Painkiller88 on July 29, 2026, 05:29:18 AM »I am using Alma 8 with CWP
Description:
After the latest CWP update, the Yum Manager interface (yum_manager) is broken and permanently stuck on the "Checking for updates..." loading animation.
Steps to reproduce:
1. Open the Control Web Panel.
2. Navigate to the Yum Manager module.
3. The page remains stuck in an infinite loading state.
Technical Analysis (from Browser Developer Console):
The issue is caused by a missing asset path (404 Not Found) which breaks the subsequent jQuery/JavaScript execution chain.
1. 404 Not Found Error:
The panel tries to fetch a sparkline chart script from an invalid path:
GET https://<server-ip>:2031/cwp_<hash>/admin/design/charts/sparkline... net::ERR_ABORTED 404 (Not Found)
2. Uncaught TypeError (JavaScript Crash):
Because the file is missing, blank.js fails with:
Uncaught TypeError: $(...).sparkline is not a function at blank.js:13:13
3. Status Breakdown:
This uncaught exception causes the main updates-fetching script to crash completely, preventing the status retrieval from processing:
Uncaught TypeError: Cannot read properties of null (reading 'status') at index.php?module=yum_manager:650:22
Expected Fix:
Please verify the file path of the asset in the new design layout update and fix the reference to the sparkline script within the yum_manager module layout.
Description:
After the latest CWP update, the Yum Manager interface (yum_manager) is broken and permanently stuck on the "Checking for updates..." loading animation.
Steps to reproduce:
1. Open the Control Web Panel.
2. Navigate to the Yum Manager module.
3. The page remains stuck in an infinite loading state.
Technical Analysis (from Browser Developer Console):
The issue is caused by a missing asset path (404 Not Found) which breaks the subsequent jQuery/JavaScript execution chain.
1. 404 Not Found Error:
The panel tries to fetch a sparkline chart script from an invalid path:
GET https://<server-ip>:2031/cwp_<hash>/admin/design/charts/sparkline... net::ERR_ABORTED 404 (Not Found)
2. Uncaught TypeError (JavaScript Crash):
Because the file is missing, blank.js fails with:
Uncaught TypeError: $(...).sparkline is not a function at blank.js:13:13
3. Status Breakdown:
This uncaught exception causes the main updates-fetching script to crash completely, preventing the status retrieval from processing:
Uncaught TypeError: Cannot read properties of null (reading 'status') at index.php?module=yum_manager:650:22
Expected Fix:
Please verify the file path of the asset in the new design layout update and fix the reference to the sparkline script within the yum_manager module layout.
