Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Updates / Re: CWP Netdata Installation Faild
« Last post by overseer on August 24, 2026, 04:38:23 PM »
Agreed, look elsewhere. Netdata looks pretty, but is actually pretty heavy on the server for a resource monitor. You have to edit the configuration a bit extensively just to calm it down and produce less frequent polling on the server. (Best use case is for a private lab/testing server where you need the granularity and like the pretty output -- and have plenty of server resources and not a lot of traffic.)
22
Updates / Re: ssh config manager
« Last post by Starburst on August 24, 2026, 03:26:29 PM »
Sounds like a bug that needs to be reported.

I just edit the config directly.

Code: [Select]
nano /etc/ssh/sshd_config
23
Updates / Re: CWP Netdata Installation Faild
« Last post by Starburst on August 24, 2026, 03:23:36 PM »
I can try and work on that.

But we use a 3rd party HetrixTools and install their Agent on the servers. And stopped using Netdata years ago.
They have a free level up to 15 Uptime Monitors and 32 Blacklist Monitors.

https://hetrixtools.com/

They allow up to 9 services to be monitored also beside all the standard server monitors.
What they call 'Uptime Monitors' is actually a server, so 15 servers.
Alerts can be sent via multiple options, including SMS.

The Blacklist Monitors are nice also, they will monitor the RBL's for the IP's you have.
Usually you just put the servers base IPv4.
24
Updates / ssh config manager
« Last post by alexander999 on August 24, 2026, 11:38:03 AM »
Hello,

Please fix the error when restarting service ssh in admin panel.
Code: [Select]
Error
Server returned non-JSON response: AJAX module does not exist.CWPpro version: 1.9
Distro Name: AlmaLinux release 9.8 (Olive Jaguar)


25
Updates / CWP Netdata Installation Faild
« Last post by Sina on August 24, 2026, 08:23:41 AM »
Unfortunately, for some time now, it has not been possible to install Netdata on CWP.

When we click Install from the CWP management panel, it takes some time, but then the same page is refreshed and Netdata is still not installed.

System information:

OS: AlmaLinux 9
CWP: Latest version (1.9)

I recently found some very useful tutorials on https://starburst.help/ that have helped me a lot.

It would be great if this issue could be fixed so that Netdata can be installed directly from the CWP panel.

Also, if possible, it would be very helpful to have a reliable tutorial showing how to install and update Netdata via SSH on CWP.

Thank you.
26
Backup / Re: NEW Backup (beta) / Restore Account -> Does not list accounts to restore
« Last post by DA_MAN on August 24, 2026, 01:14:10 AM »
 I have the same problem I think, It backups up okay to local and an S3 garage bucket, but when I go to the restore button, there is nothing listed under user accounts. Below that it says in the yellow box, "Please first select the backup you want to restore."

Well I can't select any backups because nothing is listed there - the top field is totally blank, no accounts to select. I'm pretty livid about this. Long ago this worked; I don't know how long it has been broken, but it is broken in AlmaLinux 8 and 9 on CWP version 1.9. I have CWP updates set to two weeks, do I need to step that up to immediately to get a bugfix or something? I am so used to having to fix things that are broken in CWP that I fear taking breaking updates from this operation...

This truly is not acceptable. To be able to make backups but not restore them makes it 100% worthless.
27
DNS Manager / Whats the most spontaneous way youve ever met someone for a fun, no-pressure hangout?
« Last post by rajanxsingh on August 23, 2026, 10:23:49 PM »
I was scrolling through old photos the other day and realized half my best memories involve people I barely knew before that daysomeones random suggestion, a last-minute invite, or just striking up a chat with a stranger. How do you usually find yourself in those kinds of situations, or do they just happen by accident?
 
 
 
 
 
PrivateLadyEscorts.com
Beautiful girls in your city want you
28
Updates / Re: CWP 1.9 — Can we build a community-reported status for the main components?
« Last post by alexander999 on August 23, 2026, 12:47:55 PM »
It seems that all the fixes are being done with the help of AI. Nobody really knows what works and what doesn’t, and there is no complete testing of the components after changes are made.

It would be really great if the developers released the source code of this panel on GitHub. I think that within a month, the community would modify this panel and fix absolutely everything that is currently not working.
29
CWP API / API: account/udp always returns "Unauthorized action" although accout_upd is gra
« Last post by Watchdog on August 23, 2026, 08:39:32 AM »
CWP version: 1.9
OS: AlmaLinux release 8.10 (Cerulean Leopard)
API: external API on port 2304, JSON


Summary

An API key with Account / UPD granted is refused on /v1/account with
action=udp. Every other action on the same key and the same Account function
works. CWP's own debug log shows it resolving the request to accout_upd — the grant
that is switched on — and refusing it anyway, with Unauthorized2 action rather than
the usual Unauthorized action.

Steps to reproduce

1. Create an API key in API Manager. Grant Account ADD, UPD, DEL, LIST, SUSP, UNSP.
2. Call /v1/account with action=list — succeeds.
3. Call /v1/account with action=udp for an existing account — fails.

Code: [Select]
curl -sk https://SERVER:2304/v1/account \
  -d "key=KEY" -d "action=udp" -d "user=USERNAME" \
  -d "email=user@example.com" -d "package=@12" \
  -d "inode=0" -d "openfiles=150" -d "processes=40"

Expected

{"status":"OK"}, with the account's inode / open-file / process limits updated.

Actual

Code: [Select]
{"status":"Error","msj":"Unauthorized action KEY"}

From /var/log/cwp/cwp_api.log (debug=1), key masked

A successful call in the same session — note it ends with a return: clause:

Code: [Select]
2026-08-23 08:09:25  authorized
2026-08-23 08:09:25  Key:<KEY>, action:changepack_udp, ip:<CLIENT> return:{status:OK,format:JSON}
2026-08-23 08:09:25  {status:OK} -> {key:<KEY>,action:udp,user:USERNAME,adds:null,package:8}

The failing call, one second later, same key, same source address:

Code: [Select]
2026-08-23 08:09:26  Unauthorized2 action
2026-08-23 08:09:26  Key:<KEY>, action:accout_upd, ip:<CLIENT>
2026-08-23 08:09:26  Error

Two things stand out:

  • The action it checked is accout_upd — exactly the permission API Manager saves
    for the Account / UPD checkbox (value="accout_upd" in
    mod_reseller_apimanager.html), and exactly the one that is granted.
  • It logs Unauthorized2 action, not Unauthorized action, and the line
    carries no return: clause where every authorised call carries one. That looks like a
    second authorisation check which the grant alone does not satisfy.

Ruled out

  • The grant. Account ADD, UPD, DEL, LIST, SUSP and UNSP are all on in the grid.
  • The key. The same key succeeds in the same second on packages/list
    (pack_list), changepack/udp (changepack_udp) and
    accountdetail/list (detailaccount_list).
  • The request. It matches the Interactive Documentation for account/udp
    field for field: user, email, package with the documented
    @ prefix, inode, openfiles, processes. Omitting
    email produces a different, correct error, so the request is being parsed.
  • A stale saved key. Toggling Account / UPD off, saving, on, saving again changes
    nothing.
  • A missing companion grant. Adding Account Quota / LIST, Quota limit / LIST and
    Metadata Account / LIST changes nothing.
  • The source address. The refused call comes from the same IP as the calls that
    succeed, in the same second.

Impact

account/udp is the only endpoint that sets a per-account inode, open-file or process
limit — Account Quota and Quota limit have no update action, and those three are not package
properties, so packages/add and packages/udp cannot carry them. With this
call refused there is no way to change those limits on an existing account through the API.

This affects my WHMCS module using the endpoint.

Question

Is accout_upd the permission this endpoint actually requires, and what is the second
check that logs Unauthorized2? If the endpoint wants a grant that API Manager does
not expose, that would explain the behaviour.
30
Updates / CWP 1.9 — Can we build a community-reported status for the main components?
« Last post by Xweb on August 23, 2026, 12:36:01 AM »


Hello everyone,

I would like to make another attempt to bring some clarity to the current status of CWP releases.

I previously raised a similar topic during the 1.8 release, asking whether we could have a clearer distinction between issues that are fixed, partially fixed, still open, under testing, or not yet verified.

I am not opening this thread to criticize the CWP team or to replace the official changelog. The official changelog is useful and remains the authoritative source for what has been changed in each release.

However, as releases continue to arrive, it is becoming increasingly difficult for administrators to understand the real-world status of individual components, especially across different operating systems.

For example, when a changelog says that something has been "fixed" or "improved", there are still some practical questions:

  • Has the fix actually been verified by users?
  • Is the component fully working, or only partially?
  • Does the behaviour differ between AlmaLinux and Rocky Linux?
  • Does it differ between EL8 and EL9?
  • Was the underlying service tested, or only the CWP UI?
  • Are there known regressions that are not mentioned in the changelog?
  • Has restore actually been tested, rather than only backup creation?

I think the community could help build a useful picture here.


What I would like to collect

Please report only things that you have personally tested or observed.

Please do not report a component as "Working" simply because you have not encountered a problem with it.

If you have not tested something, please use Not tested.

Please include:

Code: [Select]
CWP version:
OS / distribution:
OS version:

YUM/DNF Manager:          Working / Partial / Not working / Not tested
Firewall:                 Working / Partial / Not working / Not tested
ModSecurity:              Working / Partial / Not working / Not tested
SSL / AutoSSL:            Working / Partial / Not working / Not tested
DNS:                      Working / Partial / Not working / Not tested
Apache / Nginx:            Working / Partial / Not working / Not tested
PHP / PHP-FPM:            Working / Partial / Not working / Not tested
MariaDB / MySQL:          Working / Partial / Not working / Not tested
Postfix:                  Working / Partial / Not working / Not tested
Dovecot:                  Working / Partial / Not working / Not tested
FTP:                      Working / Partial / Not working / Not tested

Local backup:             Working / Partial / Not working / Not tested
Remote/FTP backup:        Working / Partial / Not working / Not tested
Backup notification:      Working / Partial / Not working / Not tested
Backup report:            Working / Partial / Not working / Not tested
Restore:                  Working / Partial / Not working / Not tested

Existing websites after update:
Working / Partial / Problems

Database-dependent websites:
Working / Partial / Problems

Did these functions work correctly before your last CWP update?
YES / NO / UNKNOWN


For any Partial or Not working result, please briefly describe the actual symptom.

For example:

Code: [Select]
YUM Manager: Not working
Symptom: infinite loading, no content displayed.

Firewall: Not working
Symptom: page loads indefinitely.

MariaDB: Working
Existing websites: Working


Production-impacting issues

I would also particularly like to collect reports where an update resulted in an actual production impact, such as:

  • websites becoming unavailable;
  • MariaDB/MySQL stopping or becoming inaccessible;
  • PHP/PHP-FPM problems affecting existing websites;
  • mail services becoming unavailable;
  • DNS problems;
  • SSL/AutoSSL failures;
  • existing accounts becoming inaccessible.

For these reports, it would be useful to include:

Code: [Select]
CWP version before:
CWP version after:
OS / distribution:
OS version:
Component affected:
What happened:
Was the underlying service affected, or only the CWP UI?
Was manual intervention required?


Backup and restore

I would especially like to keep backup and restore information separate.

A backup job reporting "successful" does not necessarily mean that restore has been tested successfully.

Therefore, if possible, please distinguish between:

  • local backup creation;
  • remote/FTP backup;
  • backup notification email;
  • completeness of the backup report;
  • account-level success/failure reporting;
  • restore;
  • restore of an existing backup created by a previous CWP version.

For example, if backup creation works but restore has never been tested, please report:

Code: [Select]
Backup: Working
Restore: Not tested

rather than considering the entire backup system "Working".


Please also report successful results

This is important.

I am not looking only for problems.

If you have upgraded successfully and the components above are working correctly, please report that as well.

Positive reports are just as useful as negative reports because they can help us understand whether a problem is specific to a particular OS, CWP release, configuration, or component.

Likewise, if something works correctly on AlmaLinux 8 but not on AlmaLinux 9, or on Rocky Linux but not AlmaLinux, that information is extremely valuable.

Please do not upgrade a production server just to participate in this thread.

If you have not tested something, simply mark it as "Not tested".


What I hope we can achieve

Ideally, over time we could build a simple community status list for the different CWP versions and operating systems.

For example:

Code: [Select]
CWP 1.9 / AlmaLinux 9

YUM Manager:       ?
Firewall:          ?
ModSecurity:       ?
SSL / AutoSSL:     ?
DNS:               ?
Apache / Nginx:    ?
PHP / PHP-FPM:     ?
MariaDB / MySQL:   ?
Postfix:           ?
Dovecot:           ?
FTP:               ?

Local Backup:      ?
Remote Backup:     ?
Backup Report:     ?
Notification:      ?
Restore:           ?

The same information could then be collected for other combinations, for example:

Code: [Select]
CWP 1.9 / AlmaLinux 8
CWP 1.9 / Rocky Linux 8
CWP 1.9 / Rocky Linux 9
CWP 1.8 / AlmaLinux 8
CWP 1.8 / AlmaLinux 9
...

The purpose would simply be to understand where a component has been actually tested and what administrators are experiencing in real-world environments.


This would not be an official CWP certification and would not replace the official changelog or official testing.

It would simply be a community evidence log showing what administrators are actually seeing in real-world environments.

I think this could be useful for everyone, including the CWP team, because it would help distinguish between:

Fixed → Verified → Partially working → Still broken → Not tested

rather than having all of these situations represented only by a generic "fixed" or "improved" entry in the changelog.

Thanks to everyone willing to contribute, whether your experience has been positive or negative.
Pages: 1 2 [3] 4 5 ... 10