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
Scripts / Re: Script or api to create user
« on: February 28, 2025, 09:45:02 PM »more detailed instructions can be found here
http://wiki.centos-webpanel.com/cwp-account-api
Oops! That page can’t be found.
It looks like nothing was found at this location. Maybe try a search above?
2
Varnish / Re: How to install varnish cache on centos [CWP]
« on: February 15, 2025, 12:14:00 AM »
am on rocky 8.10
how i fix this ? it still works but cfg not there like it was
how i fix this ? it still works but cfg not there like it was

3
Updates / new Monit cfg
« on: February 15, 2025, 12:04:00 AM »Quote
set daemon 300 # Check services at 5-minute intervals
with start delay 45 # Wait 45 seconds before starting checks
set log syslog # Log output to syslog
set logfile /var/log/monit.log # Additionally log to a specific file
set pidfile /var/run/monit.pid # Define PID file location
set idfile /var/.monit.id # Monit ID file location
set statefile /var/.monit.state # Monit state file location
set mailserver localhost # Mailserver for sending alerts
set alert your email # Alert email address
set eventqueue
basedir /var/monit # Event queue directory
slots 100 # Number of slots in the event queue
# HTTP interface settings
set httpd port 2812 and
use address localhost # Only listen on localhost
allow localhost # Allow connections from localhost
allow admin:xxxxxx # Use a strong password and consider using HTTPS
ssl enable
pemfile /etc/pki/tls/private/hostname.pem # Correct path to SSL certificate
# Include additional configuration files
include /etc/monit.d/*
# Apache monitoring
check process apache with pidfile /var/run/httpd/httpd.pid
start program = "/usr/bin/systemctl start httpd.service" with timeout 15 seconds
stop program = "/usr/bin/systemctl stop httpd.service"
# Nginx monitoring
check process nginx_service with pidfile /var/run/nginx.pid
start program = "/usr/bin/systemctl start nginx.service" with timeout 15 seconds
stop program = "/usr/bin/systemctl stop nginx.service"
# System monitoring
check system localhost
if loadavg (1min) > 4 then alert
if loadavg (5min) > 2 then alert
if memory usage > 75% then alert
if swap usage > 25% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert
4
Nginx / Re: How to update NGINX version to version 1.26.2
« on: February 14, 2025, 10:47:21 PM »
force update nginx-1.26.3-1.el8.ngx.x86_64
Quote
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
sudo cp -r /etc/nginx/conf.d /etc/nginx/conf.d.backup
Quote
sudo dnf update -y
Quote
sudo dnf remove nginx -y
Quote
sudo dnf install -y epel-release
sudo dnf install -y https://nginx.org/packages/centos/8/x86_64/RPMS/nginx-1.26.3-1.el8.ngx.x86_64.rpm
Quote
nginx -v
Quote
sudo cp /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf
sudo cp -r /etc/nginx/conf.d.backup /etc/nginx/conf.d
Quote
sudo systemctl restart nginx










5
Other / Re: i have problem with users panel login page it show to me failed cwp alma linux9
« on: February 14, 2025, 09:32:14 PM »
Yes, the value for SHA_CRYPT_MAX_ROUNDS can matter depending on the context in which you're using it.
SHA_CRYPT_MAX_ROUNDS specifies the number of rounds to be used by the SHA-crypt algorithm when hashing passwords. This value affects the computational cost required to produce the hash. Here's a brief comparison:
5000 Rounds: Lower computational cost, faster hash generation.
10000 Rounds: Higher computational cost, slower hash generation.
A higher number of rounds generally means increased security because it takes more time and effort to compute the hash, making it more resistant to brute-force attacks. However, it also means that legitimate operations involving hashing (like user authentication) will take slightly longer.
In summary, increasing the rounds improves security at the cost of performance. If your system can handle the additional computational load without significant impact on user experience, 10000 rounds would provide better security.
The best setup for SHA_CRYPT_MAX_ROUNDS largely depends on your priorities between security and performance. Here’s a bit of a framework to help you decide:
If Security is Your Main Concern:
Set SHA_CRYPT_MAX_ROUNDS to a higher value, like 10000. This increases the complexity and time it takes for an attacker to crack the password hashes, enhancing security.
Be aware that this will also slightly increase the time taken to authenticate users.
If Performance is Your Main Concern:
Set SHA_CRYPT_MAX_ROUNDS to a lower value, such as 5000. This reduces the computational load and speeds up the authentication process, but it might be less secure compared to higher rounds.
Balanced Approach:
You might opt for a middle ground, like 7500, to balance both security and performance.
Additional Considerations:
Server Capabilities: Ensure your server can handle the chosen number of rounds without significantly impacting overall performance.
User Experience: Consider the impact on user login times and ensure it’s within acceptable limits.
Ultimately, there's no one-size-fits-all answer—it depends on your specific needs and the environment in which you're operating. If security is paramount and your infrastructure can handle it, go for the higher number of rounds. If performance is critical, you might need to compromise a bit on the number of rounds.
To assess your server's performance with different SHA_CRYPT_MAX_ROUNDS settings, you can follow these steps:
Benchmark Current Performance: Before making any changes, benchmark your server's current performance. You can use tools like sysbench or openssl to measure the time it takes to hash passwords with the current settings.
Test Different Settings: Change the SHA_CRYPT_MAX_ROUNDS value to the desired number (e.g., 5000, 7500, 10000) and run the same benchmark tests again. This will give you a comparative view of how each setting impacts performance.
Monitor System Metrics: While running the benchmarks, monitor system metrics such as CPU usage, memory usage, and I/O operations. Tools like top, htop, vmstat, and iostat can be useful for this purpose.
Analyze Results: Compare the benchmark results and system metrics for each setting. Look for any significant increases in resource usage or decreases in performance.
Evaluate User Experience: If possible, perform real-world tests by having users log in during off-peak hours to see if there is a noticeable impact on login times.
Make an Informed Decision: Based on the benchmark results and user experience evaluation, choose the setting that provides an acceptable balance between security and performance.
There are several benchmarking tools you can use to assess your server's performance. Here are some of the most recommended ones:
Sysbench: A versatile benchmarking tool for evaluating CPU, memory, I/O, and database performance.
openssl: Useful for cryptographic performance testing, including password hashing.
wrk: A modern, high-performance HTTP benchmarking tool that leverages multi-threading to generate high workloads.
Jmeter: An open-source application for load testing and performance measurement, supporting various protocols like HTTP, SOAP, and FTP.
K6: A popular open-source load testing tool written in Go, supporting HTTP, gRPC, and WebSocket.
Autocannon: A high-performance HTTP benchmarking tool that can test the load capacity of web applications.
Tsung: An open-source tool for stress testing and benchmarking web servers, capable of simulating thousands of users.
iostat: Useful for monitoring system input/output device loading by observing the device and partition I/O statistics.
top: A command-line tool that provides a dynamic real-time view of a running system.
htop: An interactive process viewer for Unix systems, providing a more user-friendly interface than top.
1. Sysbench
To benchmark CPU performance:
bash
sysbench --test=cpu --cpu-max-prime=20000 run
To benchmark memory performance:
bash
sysbench --test=memory run
2. OpenSSL
To benchmark SHA-256 hashing performance:
bash
openssl speed sha256
3. Wrk
To benchmark HTTP performance:
bash
wrk -t12 -c400 -d30s http://yourserver.com/index.html
-t12: 12 threads
-c400: 400 connections
-d30s: 30 seconds duration
4. Jmeter
To perform an HTTP load test:
Open Jmeter.
Create a Thread Group and set the number of users (threads) and loop count.
Add an HTTP Request sampler with your target URL.
Run the test and analyze the results in the Summary Report listener.
5. K6
To run a simple load test:
js
import http from 'k6/http';
import { sleep } from 'k6';
export let options = {
vus: 10, // virtual users
duration: '30s',
};
export default function () {
http.get('http://yourserver.com/index.html');
sleep(1);
}
Run the test with:
bash
k6 run script.js
6. Autocannon
To benchmark HTTP performance:
bash
autocannon -c 100 -d 30 -p 10 http://yourserver.com
-c 100: 100 connections
-d 30: 30 seconds duration
-p 10: 10 pipelining factor
7. Tsung
To perform a stress test:
Create a Tsung XML configuration file with the desired settings.
Start the test with:
bash
tsung start -f tsung.xml
8. Iostat
To monitor I/O statistics:
bash
iostat -x 5
-x: extended statistics
5: update interval in seconds
9. Top
To monitor system processes in real-time:
bash
top
10. Htop
To monitor system processes with a more user-friendly interface:
bash
htop
SHA_CRYPT_MAX_ROUNDS specifies the number of rounds to be used by the SHA-crypt algorithm when hashing passwords. This value affects the computational cost required to produce the hash. Here's a brief comparison:
5000 Rounds: Lower computational cost, faster hash generation.
10000 Rounds: Higher computational cost, slower hash generation.
A higher number of rounds generally means increased security because it takes more time and effort to compute the hash, making it more resistant to brute-force attacks. However, it also means that legitimate operations involving hashing (like user authentication) will take slightly longer.
In summary, increasing the rounds improves security at the cost of performance. If your system can handle the additional computational load without significant impact on user experience, 10000 rounds would provide better security.
The best setup for SHA_CRYPT_MAX_ROUNDS largely depends on your priorities between security and performance. Here’s a bit of a framework to help you decide:
If Security is Your Main Concern:
Set SHA_CRYPT_MAX_ROUNDS to a higher value, like 10000. This increases the complexity and time it takes for an attacker to crack the password hashes, enhancing security.
Be aware that this will also slightly increase the time taken to authenticate users.
If Performance is Your Main Concern:
Set SHA_CRYPT_MAX_ROUNDS to a lower value, such as 5000. This reduces the computational load and speeds up the authentication process, but it might be less secure compared to higher rounds.
Balanced Approach:
You might opt for a middle ground, like 7500, to balance both security and performance.
Additional Considerations:
Server Capabilities: Ensure your server can handle the chosen number of rounds without significantly impacting overall performance.
User Experience: Consider the impact on user login times and ensure it’s within acceptable limits.
Ultimately, there's no one-size-fits-all answer—it depends on your specific needs and the environment in which you're operating. If security is paramount and your infrastructure can handle it, go for the higher number of rounds. If performance is critical, you might need to compromise a bit on the number of rounds.
To assess your server's performance with different SHA_CRYPT_MAX_ROUNDS settings, you can follow these steps:
Benchmark Current Performance: Before making any changes, benchmark your server's current performance. You can use tools like sysbench or openssl to measure the time it takes to hash passwords with the current settings.
Test Different Settings: Change the SHA_CRYPT_MAX_ROUNDS value to the desired number (e.g., 5000, 7500, 10000) and run the same benchmark tests again. This will give you a comparative view of how each setting impacts performance.
Monitor System Metrics: While running the benchmarks, monitor system metrics such as CPU usage, memory usage, and I/O operations. Tools like top, htop, vmstat, and iostat can be useful for this purpose.
Analyze Results: Compare the benchmark results and system metrics for each setting. Look for any significant increases in resource usage or decreases in performance.
Evaluate User Experience: If possible, perform real-world tests by having users log in during off-peak hours to see if there is a noticeable impact on login times.
Make an Informed Decision: Based on the benchmark results and user experience evaluation, choose the setting that provides an acceptable balance between security and performance.
There are several benchmarking tools you can use to assess your server's performance. Here are some of the most recommended ones:
Sysbench: A versatile benchmarking tool for evaluating CPU, memory, I/O, and database performance.
openssl: Useful for cryptographic performance testing, including password hashing.
wrk: A modern, high-performance HTTP benchmarking tool that leverages multi-threading to generate high workloads.
Jmeter: An open-source application for load testing and performance measurement, supporting various protocols like HTTP, SOAP, and FTP.
K6: A popular open-source load testing tool written in Go, supporting HTTP, gRPC, and WebSocket.
Autocannon: A high-performance HTTP benchmarking tool that can test the load capacity of web applications.
Tsung: An open-source tool for stress testing and benchmarking web servers, capable of simulating thousands of users.
iostat: Useful for monitoring system input/output device loading by observing the device and partition I/O statistics.
top: A command-line tool that provides a dynamic real-time view of a running system.
htop: An interactive process viewer for Unix systems, providing a more user-friendly interface than top.
1. Sysbench
To benchmark CPU performance:
bash
sysbench --test=cpu --cpu-max-prime=20000 run
To benchmark memory performance:
bash
sysbench --test=memory run
2. OpenSSL
To benchmark SHA-256 hashing performance:
bash
openssl speed sha256
3. Wrk
To benchmark HTTP performance:
bash
wrk -t12 -c400 -d30s http://yourserver.com/index.html
-t12: 12 threads
-c400: 400 connections
-d30s: 30 seconds duration
4. Jmeter
To perform an HTTP load test:
Open Jmeter.
Create a Thread Group and set the number of users (threads) and loop count.
Add an HTTP Request sampler with your target URL.
Run the test and analyze the results in the Summary Report listener.
5. K6
To run a simple load test:
js
import http from 'k6/http';
import { sleep } from 'k6';
export let options = {
vus: 10, // virtual users
duration: '30s',
};
export default function () {
http.get('http://yourserver.com/index.html');
sleep(1);
}
Run the test with:
bash
k6 run script.js
6. Autocannon
To benchmark HTTP performance:
bash
autocannon -c 100 -d 30 -p 10 http://yourserver.com
-c 100: 100 connections
-d 30: 30 seconds duration
-p 10: 10 pipelining factor
7. Tsung
To perform a stress test:
Create a Tsung XML configuration file with the desired settings.
Start the test with:
bash
tsung start -f tsung.xml
8. Iostat
To monitor I/O statistics:
bash
iostat -x 5
-x: extended statistics
5: update interval in seconds
9. Top
To monitor system processes in real-time:
bash
top
10. Htop
To monitor system processes with a more user-friendly interface:
bash
htop
6
Updates / Re: MariaDB update problem CWP7PRO
« on: February 14, 2025, 06:59:03 AM »
it is MariaDB Server version: 11.2.6-MariaDB - MariaDB Server but say on panel MySQL version: 15.2 but in phpMyAdmin version: 11.2.6-MariaDB
7
Installation / Re: Alma linux 8 fresh install script error
« on: February 10, 2025, 10:52:48 PM »you got do this to fix it . i run into this over the weekend take me 24 hours to find what going on after changeing mirrs after mirr... cwp cant update software keep us in out of date software so you got fix the installer .... "nano cwp-el8-latest" the installer and change it ..
did few changes make your own they wont fix it![]()
cant post it The following error or errors occurred while posting this message:
The message exceeds the maximum allowed length (20000 characters).
got to make your own codeCode: [Select]nano cwp-el8-latest
am on MySQL version: 15.2 need few more changes
https://shorturl.at/0JMLl here what i did not right but it works running
8
Installation / Re: Alma linux 8 fresh install script error
« on: February 10, 2025, 10:32:41 PM »
you got do this to fix it . i run into this over the weekend take me 24 hours to find what going on after changeing mirrs after mirr... cwp cant update software keep us in out of date software so you got fix the installer .... "nano cwp-el8-latest" the installer and change it ..
did few changes make your own they wont fix it
cant post it The following error or errors occurred while posting this message:
The message exceeds the maximum allowed length (20000 characters).
got to make your own code
did few changes make your own they wont fix it


The message exceeds the maximum allowed length (20000 characters).
got to make your own code

Code: [Select]
nano cwp-el8-latest
9
Updates / Re: MariaDB update problem CWP7PRO
« on: February 10, 2025, 09:52:45 PM »
I force MySQL version: 15.2
10
How to / Re: Anyone have a How TO Guide for setting up & using Cloudflare with CWP?
« on: February 10, 2025, 09:48:49 PM »
am on Cloudflare ip dns and run Cloudflare mod and Cloudflare CDN
11
CentOS-WebPanel Bugs / Re: Cron issue
« on: February 10, 2025, 09:43:46 PM »
it works but about what php running the back end some times got to restart it make it work....
12
Information / Re: CWP Support Site Not Working
« on: February 10, 2025, 09:40:09 PM »
Several features are broken, including the installer, which uses outdated software. Hopefully, recent updates will address these issues.
13
I can build it / Re: CWP Custom CodeEditor (Based on Ace Editor)
« on: February 03, 2025, 02:45:34 AM »
thanks going test it out
14
CloudLinux / Re: Cloud Linux Installer
« on: December 28, 2024, 09:37:36 PM »
Cloud Linux 9.5 i paid $122 from cpanel
dont need old php but they are try to install.
dont need old php but they are try to install.
15
CloudLinux / Re: Cloud Linux Installer
« on: December 28, 2024, 09:24:24 PM »
ack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_sort.lo Zend/zend_multibyte.lo Zend/zend_ts_hash.lo Zend/zend_stream.lo Zend/zend_iterators.lo Zend/zend_interfaces.lo Zend/zend_exceptions.lo Zend/zend_strtod.lo Zend/zend_gc.lo Zend/zend_closures.lo Zend/zend_float.lo Zend/zend_string.lo Zend/zend_signal.lo Zend/zend_generators.lo Zend/zend_virtual_cwd.lo Zend/zend_ast.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_default_classes.lo Zend/zend_inheritance.lo Zend/zend_smart_str.lo Zend/zend_cpuinfo.lo Zend/zend_execute.lo main/internal_functions_cli.lo main/fastcgi.lo sapi/cgi/cgi_main.lo -lcrypt -lcrypt -lrt -lrt -lm -lsystemd -lxml2 -lz -llzma -lm -lxml2 -lz -llzma -lm -lxml2 -lz -llzma -lm -lcrypt -lxml2 -lz -llzma -lm -lxml2 -lz -llzma -lm -lxml2 -lz -llzma -lm -lcrypt -o sapi/cgi/php-cgi
Generating phar.php
Generating phar.phar
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
clicommand.inc
directorytreeiterator.inc
pharcommand.inc
directorygraphiterator.inc
invertedregexiterator.inc
phar.inc
Build complete.
Don't forget to run 'make test'.
PHP 5.4 is not installed,Please install if you have application that uses it
[root@dal src]#
Generating phar.php
Generating phar.phar
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
clicommand.inc
directorytreeiterator.inc
pharcommand.inc
directorygraphiterator.inc
invertedregexiterator.inc
phar.inc
Build complete.
Don't forget to run 'make test'.
PHP 5.4 is not installed,Please install if you have application that uses it
[root@dal src]#