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.
1
PHP / Re: PHP-FPM Won't install zlib says missing dependency zlib-dir
« on: Today at 09:32:39 PM »
Zlib support in PHP just is not enabled by default.
If you want use it, you will need to configure PHP --with-zlib[=DIR], it's a requirement.
See: https://www.php.net/manual/en/zlib.installation.php
So, check if your compilation is enabling zlib in config.log, if that file have --with-zlib parameter:
# grep zlib /path/to/your/configure/config.log
Regards,
Netino
If you want use it, you will need to configure PHP --with-zlib[=DIR], it's a requirement.
See: https://www.php.net/manual/en/zlib.installation.php
So, check if your compilation is enabling zlib in config.log, if that file have --with-zlib parameter:
# grep zlib /path/to/your/configure/config.log
Regards,
Netino
2
CentOS-WebPanel Bugs / Re: CWP Cronjob Killing Server
« on: Today at 09:18:42 PM »I have been fighting with this problem for days. Seems to have started after a few rounds of software and security updates a few days ago. I have finally narrowed the issue down but have not come up with a permanent fix. I think only CWP can provide the fix.
Also, I fully admit, this could be something I caused. Just yet to determine where or what.
CWPpro version: 1.8
Operating System: AlmaLinux 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
FTP version: 1.0.52
SSH Port: 4000
MySql Port: 3306
Web Servers: nginx-apache
Problem: After the CWP cronjob runs, the permissions on Mariadb are modified rendering the server unusable. No websites, no webmail, no service at all.
Testing: To recreate problem that forced me to manually fix the dead CWP server (after determining the what was triggering the issue), run # bash /etc/cron.daily/cwp.
Output: However, the PHP warning seems benign.
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
(...)
The path "/no-debug-non-zts-20190902/" is the internal extension directory path and ABI/API build identifier for PHP 7.4 Non-Thread Safe (NTS) without Zend Debugger. The date 20190902 represents the release API date for PHP 7.4.
But php71 uses "no-debug-non-zts-20170718/", seems you tried to upgrade php use by cwpsrv?
Don't try to do that.
In the repository of your choice, try installing libicu-devel:
# dnf install libicu-devel
Or install from the Remi repository:
libicu69-devel-69.1-4.el8.remi.x86_64
Or, if nothing works, try directly downloading the package binary: php71-php-intl-7.1.33-32.el8.remi.x86_64.rpm, and install it in that directory
Regards,
Netino
3
Other / Re: Something is intercepting bots and loading a different page for them.
« on: August 13, 2026, 04:42:38 AM »I’m facing a very strange issue.
(...)
You are a very brave man.
We all need to be constantly paranoid to keep any web server secure.
It is practically unfeasible these days to keep a web server exposed to the internet—using closed-source software like CWP—without ModSecurity, Coraza, or similar tools.
Avoid doing this unless you know exactly what you are doing or want to deal with big major headaches involving clients.
Therefore, enable ModSecurity and use a WAF like Comodo (specifically with the latest updates available for the 'sminozzi' user) or OWASP CRS4, and always monitor your logs to keep your rules up to date.
Regards,
Netino
4
E-Mail / Re: Cannot Access emails in Roundcube 1.5.8
« on: August 02, 2026, 04:28:06 PM »
Try accessing it, where it results in another error, and immediately check your server logs with the command:
See if there's anything unusual, and post it here.
(But protect your privacy, and avoid posting anything specific to you, such as your address or domain.)
Code: [Select]
# tail -30 /usr/local/cwpsrv/logs/access_log
See if there's anything unusual, and post it here.
(But protect your privacy, and avoid posting anything specific to you, such as your address or domain.)
5
Updates / Re: CWP Cannot be Installed in Alma 8 - Devel repo Issue
« on: August 02, 2026, 03:58:42 PM »With AL8 modsec is not working, but ill check what you said, but not even the php is working, and i mean the only php working is the one for the panel, php version switch and php-fpm cannot been installed in alma linux 8, is not working, everything is broke.
What are your Webservers choice? (Apache only, nginx only, Apache<->nginx, etc.)
There is a problem with Modsecurity-nginx conector, it's a headache to fix.
The problem is with Modsecurity-nginx connector, must be downgraded.
It is a serious problem, and the bug only appears under specific conditions—specifically, when rendering large pages exceeding 500 KB.
I contacted the developers of the ModSecurity-Nginx connector last year and opened an issue because the bug was cutting off part of the page, and they fixed it. But it looks like there was a regression problem, and the bug has been reintroduced. There’s no other option; if you’re using Nginx, you have to downgrade.
The ModSecurity-nginx connector eats up a portion of the resulting HTML page.
If your CWP have a few sites, not problem. But if your server have dozen of sites, CWP ends up completely broken, unreadable.
I spent three days, to find the problem.
But the problem is specific to Modsecurity-nginx connector, if you use nginx only web server.
Modsecurity for Apache is all ok, normally. Or it should be working normally; the problem many people are experiencing lies with the CWP interface for ModSecurity, not with ModSecurity for Apache itself.
Regards,
Netino
6
Updates / Re: cwpsrv 1.24.0-2 Update
« on: July 29, 2026, 01:04:44 AM »
Did update both of my servers and both shows cwpsrv-1.24.0-2.x86_64 still mod security does not load and firewall too is dead (maybe its disabled but I used this one in security / firewall manager). Mod security works in background I receive emails about blocked IP's, did have some problems but managed to fix sites to come online.
There are some errors which js ajax scripts loads in gui which are missing or pointing to folder which does not exist, and one of those I wrote before today after creating symlink to file loads ok php version switcher and mod security.
Out of several servers, I have only one experiencing this issue. I’ve already discovered that the digital certificate installed by CWP is invalid. I reinstalled it (copying the same link from another server), but the landing page remains completely broken, making it virtually unusable.
If you check the logs, there is a file that isn't being found, even though the file is actually there:
Code: [Select]
MY.IP.ADD.RES - root [28/Jul/2026:21:19:33 -0300] "GET /cwp_0130303030302250e53d34b52eb95ed7/admin/design/charts/sparklines/jquery.sparkline.js HTTP/1.1" 404 1010 https://my_server.com:2031/cwp_013030303032250e53d34b52eb95ed7/admin/index.php?chk=y Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36
The files are here:
Code: [Select]
-rw-r----- 1 root root 125947 set 27 2017 /usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparkline/jquery.sparkline.js
-rw-r----- 1 root root 125947 ago 22 2017 /usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparklines/jquery.sparkline.js
Notice that the path is different; it has '/plugins' in the middle, which prevents it from being found.But creating a symbolic link for charts -> plugins/charts in /usr/local/cwpsrv/htdocs/admin/design/ does not solve the problem.
This is definitely a bug in CWP.
7
Updates / Re: cwp service failed
« on: July 28, 2026, 04:47:49 AM »
This is a bug from the CWP newer version.
Try to do this, I think is more simple:
Regards,
Netino
Try to do this, I think is more simple:
Code: [Select]
# [[ -e "/etc/pki/tls/certs/hostname.crt" ]] || ln -s /etc/pki/tls/certs/hostname.{cert,crt}
Regards,
Netino
8
Other / Re: root ssh authorized_keys file has been deleted and password login allowed
« on: July 23, 2026, 09:41:40 PM »
The issue arises from how the CWP `temp_hacker_check` script handles SSH keys during its daily cleanup process: the script is poorly coded and removes SSH keys for a specific list of users—including the `operator` user, which shares the same home directory as the `root` user (`/root`).
When it deletes the contents of the `operator` user's `.ssh` directory, it inadvertently deletes the contents of `/root/.ssh` as well.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the `operator` user's home directory:
The `operator` user is a standard user created by Linux long ago, specifically for backups. It is created with the same user ID as *root* (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers several days ago; it is working well, and the `root` user's SSH keys are no longer being deleted.
Avoid altering the script itself, as your changes could be overwritten in the future by new updates to the `temp_hacker_check` script.
There is no need to disable SSH; simply run the command above.
SSH is your best ally for server administration and is very secure, provided you properly protect your keys.
Best regards,
Netino
When it deletes the contents of the `operator` user's `.ssh` directory, it inadvertently deletes the contents of `/root/.ssh` as well.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the `operator` user's home directory:
Code: [Select]
# usermod -d /root/operator operator
The `operator` user is a standard user created by Linux long ago, specifically for backups. It is created with the same user ID as *root* (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers several days ago; it is working well, and the `root` user's SSH keys are no longer being deleted.
Avoid altering the script itself, as your changes could be overwritten in the future by new updates to the `temp_hacker_check` script.
There is no need to disable SSH; simply run the command above.
SSH is your best ally for server administration and is very secure, provided you properly protect your keys.
Best regards,
Netino
9
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« on: July 09, 2026, 11:41:57 PM »
The issue with the 'temp_hacker_check' script's SSH key removal process is that the script is poorly coded; it removes SSH keys for a specific list of users, including the 'operator' user, which shares the same home directory as the 'root' user (/root).
By deleting the contents of the .ssh directory from 'operator' user, it inadvertently deletes the contents of /root/.ssh.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the 'operator' user's home directory:
The 'operator' user is a standard user created by Linux long ago specifically for backups. It is created with the same user ID as root (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers six days ago; it is working well, and the 'root' user's SSH keys are no longer being deleted.
Regards,
Netino
By deleting the contents of the .ssh directory from 'operator' user, it inadvertently deletes the contents of /root/.ssh.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the 'operator' user's home directory:
Code: [Select]
# usermod -d /root/operator operatorThe 'operator' user is a standard user created by Linux long ago specifically for backups. It is created with the same user ID as root (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers six days ago; it is working well, and the 'root' user's SSH keys are no longer being deleted.
Regards,
Netino
10
Other / Re: The CWPpro version 0.9.8.1239 update destroyed sshd and .ssh.
« on: July 02, 2026, 07:20:03 AM »
Same here.
Deleted ~/.ssh/ from all of my servers.
I'm using Alma8.
Shocked, because I'm was thinking I was hacked all my servers.
Regards,
Netino
Deleted ~/.ssh/ from all of my servers.
I'm using Alma8.
Shocked, because I'm was thinking I was hacked all my servers.
Regards,
Netino
11
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« on: June 18, 2026, 02:11:21 AM »
Guys,
I had these problems with an eval($_POST['shell']) type attack in the logs, in the admin area, two years ago (Jun/07/2024).
It was saving an error.php file in an area restricted to the admin, and running it.
In other words, somehow CWP was allowing files to be saved in the admin's restricted area.
I informed the CWP team, but I haven't received any feedback, and I don't know if it was resolved or not.
So, I proposed a temporary solution of restricting access to the admin area with the nginx server password, because the 'cwpsrv' process is actually 'nginx'.
This attack is very similar to the one that happened two years ago, so I have reason to believe that this attack is related to the attack from that time.
But since then, after restricting the admin area, I haven't had any more problems of this type.
So, if you are having problems even after updating to the new version of CWP, and have still suffered attacks, I recommend that you restrict the admin area with the nginx password.
You and your users will still be able to use CWP, as long as you have the specified password.
This doesn't solve the problem, but it brings much more peace of mind to day-to-day use until there is time to discover and fix the real problem.
To restrict the admin area, run this script:
You can choose any password you want, but choose wisely.
Regards,
Netino
I had these problems with an eval($_POST['shell']) type attack in the logs, in the admin area, two years ago (Jun/07/2024).
It was saving an error.php file in an area restricted to the admin, and running it.
In other words, somehow CWP was allowing files to be saved in the admin's restricted area.
I informed the CWP team, but I haven't received any feedback, and I don't know if it was resolved or not.
So, I proposed a temporary solution of restricting access to the admin area with the nginx server password, because the 'cwpsrv' process is actually 'nginx'.
This attack is very similar to the one that happened two years ago, so I have reason to believe that this attack is related to the attack from that time.
But since then, after restricting the admin area, I haven't had any more problems of this type.
So, if you are having problems even after updating to the new version of CWP, and have still suffered attacks, I recommend that you restrict the admin area with the nginx password.
You and your users will still be able to use CWP, as long as you have the specified password.
This doesn't solve the problem, but it brings much more peace of mind to day-to-day use until there is time to discover and fix the real problem.
To restrict the admin area, run this script:
Code: [Select]
if [[ ! -e /usr/local/cwpsrv/conf/include/security.conf ]]; then
read -p "Install additional authentication layer to CWP? (Y/n): " -r
echo # (optional) move to a new line
if [[ $REPLY =~ ^[Ss]$ ]]; then
# To create additional password to use cwpsrv
# It will work on the block ports 2031 e 2087:
# Replace XY.XW.XZ.XX with any IP address if you want restrict a IP adresses, or delete 'allow' lines
# Creating the file /usr/local/cwpsrv/conf/include/security.conf with the following content:
echo "Creating additional authentication layer to cwpsrv..."
IP_REMOTO_ATUAL=$(w -i| grep root | cut -d' ' -f10| head -1)
cat << EOT > /usr/local/cwpsrv/conf/include/security.conf
satisfy any;
allow XY.XW.XZ.XX;
allow 127.0.0.1;
deny all;
auth_basic "Protected site";
auth_basic_user_file /usr/local/cwpsrv/conf/htpasswd;
EOT
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!! Now creating the password to additional authentication layer to CWP server !!!!"
echo " ( You can choose any password you want )"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "root:"$(openssl passwd -apr1) > /usr/local/cwpsrv/conf/htpasswd
if [[ $? -eq 0 ]]; then
echo "Password sucessfully configured!"
else
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!.....ALERT.......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "There was some problem, and was not possible to configure the password, you must verify the problem!"
fi
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
fi
fi
read -p "Press [enter] to restart cwpsrv"
/scripts/restart_cwpsrv
You can choose any password you want, but choose wisely.
Regards,
Netino
12
SSL / Re: Recommended acme.sh cron for CWP AutoSSL renewals?
« on: May 26, 2026, 11:48:42 PM »
I'm using the following syntax in my scripts, and they're working::
The "bash" part is not necessary because the script "/root/.acme.sh/acme.sh" already has execute permission.
Regards,
Netino
Code: [Select]
# /root/.acme.sh/acme.sh --home /root/.acme.sh/cwp_certs
\___________________/ \_____________________/
^ ^
This is the program part This is home directory part
The "bash" part is not necessary because the script "/root/.acme.sh/acme.sh" already has execute permission.
Regards,
Netino
13
Nginx / Re: Nginx uploads fail after every package update on CWP / AlmaLinux 8
« on: May 25, 2026, 11:45:32 PM »try to add the custom "chown", "chmod" commands to:
/etc/cron.daily/cwp
right after:Code: [Select]/usr/local/cwp/php71/bin/php -d max_execution_time=1000000 -q /usr/local/cwpsrv/htdocs/resources/admin/include/cron.phpto fix the permissions after the daily cwp update.
I prefer my approach but yours also works.
But this issue happens to someone else? I have it on all my servers.
Yes, I'm having the same problem, and I'm resolving it with `chown` when it occurs. I even removed `/var/lib/nginx` from the installation, but then I needed to do some CWP migrations, and everything went back to square one. So, I'll make time to study and use your approach.
14
Installation / Re: Best solution for migrate active server from Centos 7 to another distro
« on: November 05, 2025, 12:13:23 AM »You could try to ELevate the system, but Sandeep (a CWP dev) recommends against it (it can introduce inexplicable oddities). The best course is to install a fresh AlmaLinux 8 system and use CWP Migration to move all accounts, sites, and e-mails over to the new server. If you are very knowledgeable, you could try to manually migrate to AlmaLinux 8 or 9:
I would agree with this solution, but this simply would not work in OpenVZ, OpenVirtuozzo, or alike systems.
He needs to know their system.
Or put the details here.
Regards,
Netino
15
PHP / Re: PHP Warning: PHP Startup: Unable to load dynamic library 'intl'
« on: July 03, 2025, 12:43:04 AM »
It is claiming about 'libicui18n.so.60' shared object file.
This is a too old library, and seems not available in any package to AL9, that uses GLIBC_2.34.
I think you will need to compile and install libicu 60.3 manually.
This is a too old library, and seems not available in any package to AL9, that uses GLIBC_2.34.
I think you will need to compile and install libicu 60.3 manually.
