Recent Posts

Pages: [1] 2 3 ... 10
1
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
2
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.
3
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.
4


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.
5
Hi,

Please update to the latest version that was released today

I did the update but still not working.

CWPpro version: 1.9

Distro Name: AlmaLinux release 8.10 (Cerulean Leopard)
Kernel Version: 4.18.0-553.154.1.el8_10.x86_64
Platform: x86_64 Dedicated
6
DNS Manager / Where are the people who actually enjoy life outside the screen?
« Last post by jeffvv on August 22, 2026, 06:31:36 PM »
Has anyone else noticed how forums like this are full of advice and troubleshooting, but barely anyone talks about just finding someone to grab a drink with or share a spontaneous adventure?
 
 
 
 
 
FixDim.com
She's not virtual
7
Information / CWP 1.9 has been released!
« Last post by cHAp on August 22, 2026, 05:37:12 PM »
I just noticed that version 1.9 has been released following version 1.8. According to the changelog, the following fixes and updates were included in version 1.9:

ADMIN UPDATES & FIXES
– Backup system improvements
– PHP version adjustments: 8.3 for el7; 8.4 and 8.5 for el8 and el9
– Enhanced API security

USER UPDATES & FIXES
– Backup system improvements
– Security improvements
– Spam annihilator module
– WordPress tool module
– Improvements to the DNS editing module

Source: https://control-webpanel.com/changelog#1773753427572-9bf81bf4-f2d2
8
Ever bumped into someone in the most random spotlike a late-night grocery run or a half-empty trainand ended up having a surprisingly fun time together?
 
 
 
 
 
FixDim.com
Find a girl who wants the same as you
9
Updates / File Manager
« Last post by alexander999 on August 22, 2026, 11:53:05 AM »
Hi.
Please fix the text editor in the file manager; it's not very convenient to edit online when the line numbers are in the wrong place. It's in the main admin panel.
CWPpro version: 1.9
Distro Name: AlmaLinux release 9.8 (Olive Jaguar)
10
Hi,
Can someone explain how a developer can release an update without writing about the changes and fixes?
Recovery doesn't work. Version 1.9
Distro Name: AlmaLinux release 9.8 (Olive Jaguar)
Pages: [1] 2 3 ... 10