Recent Posts
21
Suggestions / Re: Eye icon
« Last post by overseer on September 11, 2026, 02:58:44 AM »Do you mean the browser-provided one on the initial login screen for root (admin panel) or the user panel? Or when manually setting a password for a user/e-mail account/DB user?
22
Information / Re: The impact of AI tools and our commitment to CWP
« Last post by overseer on September 11, 2026, 02:56:32 AM »THANK YOU!
23
MySQL / Re: Could not connect: Connection refused (internal server error 500)
« Last post by overseer on September 11, 2026, 02:54:25 AM »Follow the link in your other thread to update to MariaDB 10.11 LTS version.
If after upgrading you are still experiencing problems, you can also try User Accounts -> Fix Permissions.
And last I checked, /scripts/mysql_pwd_reset is sadly outdated and you need to use a more modern method of setting the MariaDB root password:
https://www.digitalocean.com/community/tutorials/how-to-reset-your-mysql-or-mariadb-root-password
If after upgrading you are still experiencing problems, you can also try User Accounts -> Fix Permissions.
And last I checked, /scripts/mysql_pwd_reset is sadly outdated and you need to use a more modern method of setting the MariaDB root password:
https://www.digitalocean.com/community/tutorials/how-to-reset-your-mysql-or-mariadb-root-password
24
CentOS 9 Problems / Re: monit giving error (Execution failed | Does not exist) for mysql
« Last post by overseer on September 11, 2026, 02:49:17 AM »Please follow Sandeep's guide to upgrade to MariaDB 10.11 LTS version:
https://www.alphagnu.com/topic/22-install-mariadb-1011-in-centos-stream-9-almalinux-9-rockylinux-9/
https://www.alphagnu.com/topic/22-install-mariadb-1011-in-centos-stream-9-almalinux-9-rockylinux-9/
25
CentOS 9 Problems / monit giving error (Execution failed | Does not exist) for mysql
« Last post by zeejdeej on September 11, 2026, 01:22:04 AM »i have enabled monit service but its giving the following error for mysql.
Process 'mysql'
status Execution failed | Does not exist
monitoring status Monitored
monitoring mode active
on reboot start
how to fix it ? can anybody guide me as mysql keep crashing and i want to put mysql service in monit for auto restart.
i am using cwp pro on Distro Name: AlmaLinux release 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: 8.3.29 Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
is there a safe way to upgrade MySql version without loosing existing data ? kindly suggest
Process 'mysql'
status Execution failed | Does not exist
monitoring status Monitored
monitoring mode active
on reboot start
how to fix it ? can anybody guide me as mysql keep crashing and i want to put mysql service in monit for auto restart.
i am using cwp pro on Distro Name: AlmaLinux release 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: 8.3.29 Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
is there a safe way to upgrade MySql version without loosing existing data ? kindly suggest
26
MySQL / Could not connect: Connection refused (internal server error 500)
« Last post by zeejdeej on September 11, 2026, 12:42:16 AM »hello,
i keep getting Could not connect: Connection refused (internal server error 500) on all sites including cwp admin and user panel and after restart everything works fine. what could be the issue if anyone faced this issue before in cwp . how to fix it ?
this is what i get when i try to access cwp admin panel. all other hosted websites show internal server error 500 . but everything is fine after mysql server restart .
-----------------------------------------------------------------------------------------
Trying to start mysql server, please wait!
Try to restart Control Web Panel with command: sh /scripts/restart_cwpsrv
**Check your MySQL root password in: /usr/local/cwpsrv/htdocs/resources/admin/include/db_conn.php and /root/.my.cnf
You can reset the MySQL root password fast with this command: /scripts/mysql_pwd_reset -q
Could not connect: Connection refused
i keep getting Could not connect: Connection refused (internal server error 500) on all sites including cwp admin and user panel and after restart everything works fine. what could be the issue if anyone faced this issue before in cwp . how to fix it ?
this is what i get when i try to access cwp admin panel. all other hosted websites show internal server error 500 . but everything is fine after mysql server restart .
-----------------------------------------------------------------------------------------
Trying to start mysql server, please wait!
Try to restart Control Web Panel with command: sh /scripts/restart_cwpsrv
**Check your MySQL root password in: /usr/local/cwpsrv/htdocs/resources/admin/include/db_conn.php and /root/.my.cnf
You can reset the MySQL root password fast with this command: /scripts/mysql_pwd_reset -q
Could not connect: Connection refused
27
DNS Manager / Meet a girl who'll surprise and delight
« Last post by 500wordsessay on September 10, 2026, 11:03:40 PM »28
Information / Re: New security issue? 09.09.2026
« Last post by y0 on September 10, 2026, 09:28:02 PM »this might help https://github.com/sminozzi/casino-seo-poisoning-guide
hacker probably still has an access to server through infected/fake process and/or cronjobs, Ive used gemini to solve this problem
you can start with checking who is connected to your server right now with following command:
you will see something like this:
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2927707/nginx: work
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2975254/dovecot/ima
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2212967/dovecot/ima
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2945502/sshd: root
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2928151/cwpsrv: wor
look for "cwpserv" and "sshd". other ones like dovecot, nginx etc are usually fine, if *IP* is unknown to you then I suggest you to kill the connection and ban the IP
then you can check for deleted processes:
hacker probably still has an access to server through infected/fake process and/or cronjobs, Ive used gemini to solve this problem
you can start with checking who is connected to your server right now with following command:
Code: [Select]
netstat -antp | grep -E "ESTABLISHED|LISTEN"you will see something like this:
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2927707/nginx: work
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2975254/dovecot/ima
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2212967/dovecot/ima
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2945502/sshd: root
tcp 0 0 *IP*:*PORT* *IP*:*PORT* ESTABLISHED 2928151/cwpsrv: wor
look for "cwpserv" and "sshd". other ones like dovecot, nginx etc are usually fine, if *IP* is unknown to you then I suggest you to kill the connection and ban the IP
then you can check for deleted processes:
Code: [Select]
ls -al /proc/*/exe 2> /dev/null | grep 'deleted'if have any output then its probably is infected process which was used by hacker to get access, use gemini or w/e AI for further steps, you need to find where this process came from and delete files29
Backup / Re: NEW Backup (beta) / Restore Account -> Does not list accounts to restore
« Last post by DA_MAN on September 10, 2026, 06:42:18 PM »I have done quite a bit more troubleshooting on this and can confirm that the S3 restore problem occurs before CWP ever attempts to connect to the S3 server.
My setup is AlmaLinux 9.8 using the New Backup (beta) system. Local restore is working now, but S3 restore still does not populate the Frequency, Backup, or User Accounts fields.
The S3 storage is a Garage S3-compatible server. Backups to it are working normally.
I verified the following:
* The backup archives are present in the S3 bucket in the expected structure, for example:
`full/daily/Sunday/accounts/user.tar.gz`
* Using the same endpoint, bucket, region, access key and secret key stored in CWP's backup configuration, `aws s3 ls` successfully lists the bucket, directories and account backup files.
* CWP itself successfully uploads backups to this same S3 bucket.
* The CWP AJAX request for `searchbackupaccount` returns HTTP 200, but the response is only 5 bytes when S3 is selected. The equivalent Local request returns 82 bytes and the restore selections populate normally.
* There are no corresponding errors recorded in the CWP backup `errors` or `restore` SQLite tables.
* I ran tcpdump while selecting the S3 restore source. CWP made no connection at all to the configured S3 server.
* I then traced the CWP PHP-FPM process. During the S3 restore request CWP reads `/usr/local/cwp/.conf/backup_config.sqlite` and checks that the AWS CLI is installed with `which aws`.
* CWP finds `/usr/bin/aws`, but it never executes an `aws` command after that check.
* Since no AWS command is executed and no network connection is made to the S3 server, the restore code appears to stop locally before it ever attempts to enumerate the S3 bucket.
I also compared the working Local backup configuration with the S3 configuration and tested the few potentially relevant differences. Changing `S3_PATH` from an empty value to the database default of `0` made no difference. I also tested `DEFAULUSERBACKUP=0` instead of `1`, with no difference. Both values were restored to their original settings after testing.
At this point I don't believe this is an S3 credentials, permissions, endpoint, network, or AWS CLI problem. All of those work when tested directly, and CWP is successfully writing backups to the same bucket.
It appears that the New Backup (beta) S3 restore discovery code is returning before it ever attempts to access S3.
Hopefully this additional information will help locate the problem.
My setup is AlmaLinux 9.8 using the New Backup (beta) system. Local restore is working now, but S3 restore still does not populate the Frequency, Backup, or User Accounts fields.
The S3 storage is a Garage S3-compatible server. Backups to it are working normally.
I verified the following:
* The backup archives are present in the S3 bucket in the expected structure, for example:
`full/daily/Sunday/accounts/user.tar.gz`
* Using the same endpoint, bucket, region, access key and secret key stored in CWP's backup configuration, `aws s3 ls` successfully lists the bucket, directories and account backup files.
* CWP itself successfully uploads backups to this same S3 bucket.
* The CWP AJAX request for `searchbackupaccount` returns HTTP 200, but the response is only 5 bytes when S3 is selected. The equivalent Local request returns 82 bytes and the restore selections populate normally.
* There are no corresponding errors recorded in the CWP backup `errors` or `restore` SQLite tables.
* I ran tcpdump while selecting the S3 restore source. CWP made no connection at all to the configured S3 server.
* I then traced the CWP PHP-FPM process. During the S3 restore request CWP reads `/usr/local/cwp/.conf/backup_config.sqlite` and checks that the AWS CLI is installed with `which aws`.
* CWP finds `/usr/bin/aws`, but it never executes an `aws` command after that check.
* Since no AWS command is executed and no network connection is made to the S3 server, the restore code appears to stop locally before it ever attempts to enumerate the S3 bucket.
I also compared the working Local backup configuration with the S3 configuration and tested the few potentially relevant differences. Changing `S3_PATH` from an empty value to the database default of `0` made no difference. I also tested `DEFAULUSERBACKUP=0` instead of `1`, with no difference. Both values were restored to their original settings after testing.
At this point I don't believe this is an S3 credentials, permissions, endpoint, network, or AWS CLI problem. All of those work when tested directly, and CWP is successfully writing backups to the same bucket.
It appears that the New Backup (beta) S3 restore discovery code is returning before it ever attempts to access S3.
Hopefully this additional information will help locate the problem.
30
Information / The impact of AI tools and our commitment to CWP
« Last post by josemnunez on September 10, 2026, 03:23:12 PM »Dear Community:
We would like to share an open update regarding the current security landscape we are managing.
Over the past few months, the hosting and control panel ecosystem has seen a dramatic rise in vulnerability reports and automated scanning activity. With the proliferation of AI-driven tools, cybersecurity firms, independent researchers, and malicious actors alike are leveraging AI to conduct massive audits and identify attack vectors at unprecedented speeds. This situation is not unique to CWP; it affects the entire industry.
In light of this new landscape, we want to reassure you about our ongoing efforts:
Rapid response and mitigation: We analyze every report we receive—whether from security firms or the community—and deploy patches as quickly as possible.
Continuous core development: The CWP development team works daily to reinforce the code and adapt our defenses to neutralize these modern, AI-powered automated scanning methods.
Gratitude to the community: Your role is vital. We want to thank all the users and administrators who remain vigilant and actively collaborate with us.
We remind you of the importance of keeping your servers and services updated to the latest available version. If you detect any anomalous behavior, bugs, or potential security flaws, please notify us immediately through official channels so we can assess the issue with the highest priority.
Thank you for your continued support and trust as we work to strengthen the platform every day.
We would like to share an open update regarding the current security landscape we are managing.
Over the past few months, the hosting and control panel ecosystem has seen a dramatic rise in vulnerability reports and automated scanning activity. With the proliferation of AI-driven tools, cybersecurity firms, independent researchers, and malicious actors alike are leveraging AI to conduct massive audits and identify attack vectors at unprecedented speeds. This situation is not unique to CWP; it affects the entire industry.
In light of this new landscape, we want to reassure you about our ongoing efforts:
Rapid response and mitigation: We analyze every report we receive—whether from security firms or the community—and deploy patches as quickly as possible.
Continuous core development: The CWP development team works daily to reinforce the code and adapt our defenses to neutralize these modern, AI-powered automated scanning methods.
Gratitude to the community: Your role is vital. We want to thank all the users and administrators who remain vigilant and actively collaborate with us.
We remind you of the importance of keeping your servers and services updated to the latest available version. If you detect any anomalous behavior, bugs, or potential security flaws, please notify us immediately through official channels so we can assess the issue with the highest priority.
Thank you for your continued support and trust as we work to strengthen the platform every day.
