RHEL 9 binaries use '-rhel' suffix instead of '-rhel9':
- openlitespeed-phpconfig-x86_64-rhel (not rhel9)
- cyberpanel_ols_x86_64_rhel.so (not rhel9.so)
Updated URLs in install and upgrade modules to use correct filenames.
Ubuntu systems were incorrectly being detected as rhel9. Added explicit
Ubuntu/Debian check at the beginning of detectBinarySuffix() before
checking for RHEL-based distributions.
This ensures Ubuntu and Debian systems are properly identified and use
the correct binaries from the ubuntu/ directory instead of rhel9/.
Update OS detection and binary distribution to support separate binaries
for AlmaLinux/RHEL 8 and 9. The new structure uses:
- rhel8/ directory for AlmaLinux/RHEL 8.x binaries
- rhel9/ directory for AlmaLinux/RHEL 9.x binaries
- ubuntu/ directory for Ubuntu/Debian binaries
Changes:
- Enhanced detectBinarySuffix() to distinguish between RHEL 8 and 9
- Updated binary URLs to use new directory structure
- Updated ModSecurity checksums for all OS variants
- Applied changes to install, upgrade, and ModSecurity modules
This ensures proper ABI compatibility by providing OS-specific builds
with correct glibc and library dependencies for each platform.
Handle the scenario where users install ModSecurity after CyberPanel is already
installed with custom OpenLiteSpeed binaries.
Problem:
- When users click "Install ModSecurity" in CyberPanel UI, the system used
package manager (yum/apt) to install stock ModSecurity
- Stock ModSecurity is NOT ABI-compatible with custom OLS binaries
- This causes immediate server crashes (segfaults) when installed
Solution:
- Detect if custom OLS binary is already installed before installing ModSecurity
- If custom OLS detected, download compatible ModSecurity from cyberpanel.net
- If stock OLS detected, use package manager as usual
Implementation:
- isCustomOLSBinaryInstalled(): Detects custom OLS by scanning binary for markers
- detectBinarySuffix(): Determines Ubuntu vs RHEL binaries needed
- installCompatibleModSecurity(): Downloads, verifies, and installs compatible ModSecurity
- Modified installModSec(): Main entry point - routes to compatible installer if needed
User flow:
1. User with custom OLS clicks "Install ModSecurity" in UI
2. System detects custom OLS binary is installed
3. System writes "Detected custom OpenLiteSpeed binary" to install log
4. System downloads OS-specific compatible ModSecurity from cyberpanel.net
5. System verifies SHA256 checksum
6. System backs up any existing ModSecurity
7. System installs compatible version with OLS restart
8. User sees "ModSecurity Installed (ABI-compatible version).[200]"
Safety features:
- Checksum verification before installation
- Automatic backup of existing ModSecurity
- Graceful OLS restart with timeout handling
- Detailed logging to /home/cyberpanel/modSecInstallLog
This prevents server crashes when users install ModSecurity after custom OLS
binaries are already deployed.
Implement automatic detection and update of ModSecurity when upgrading to custom OpenLiteSpeed binaries.
Problem:
- Stock ModSecurity modules are NOT ABI-compatible with custom OLS binaries
- Using stock ModSecurity with custom OLS causes server crashes (segfaults)
- Custom OLS has different memory layout and function signatures
- ModSecurity must be rebuilt against custom OLS headers
Solution:
- Detect if custom OLS binary is installed (check for PHPConfig markers)
- Detect if ModSecurity is currently installed
- Automatically download and install ABI-compatible ModSecurity
- Verify checksums before installation
- Backup existing ModSecurity before replacing
Implementation:
- isCustomOLSBinaryInstalled(): Detects custom OLS by scanning binary for markers
- installCompatibleModSecurity(): Downloads OS-specific compatible ModSecurity
- handleModSecurityCompatibility(): Orchestrates the compatibility check and update
- Integrated into upgrade process after custom binary installation
Binary URLs:
- RHEL/AlmaLinux: https://cyberpanel.net/mod_security-compatible-rhel.so
- Ubuntu/Debian: https://cyberpanel.net/mod_security-compatible-ubuntu.so
Checksums:
- RHEL SHA256: db580afc431fda40d46bdae2249ac74690d9175ff6d8b1843f2837d86f8d602f
- Ubuntu SHA256: 115971fcd44b74bc7c7b097b9cec33ddcfb0fb07bb9b562ec9f4f0691c388a6b
Safety features:
- Checksum verification before installation
- Automatic backup of existing ModSecurity
- Graceful OLS restart with timeout handling
- Non-fatal errors allow upgrade to continue
This prevents server crashes for existing CyberPanel users who have ModSecurity
installed when they upgrade to custom OpenLiteSpeed binaries.
- Change N8N_HOST to 0.0.0.0 (internal bind address, not domain)
- Simplify VHost extraHeaders to ONLY set Origin header
- Remove duplicate X-Forwarded-* headers (OLS adds these automatically)
- Remove N8N_ALLOWED_ORIGINS and N8N_ALLOW_CONNECTIONS_FROM (not needed)
The key issue was duplicate X-Forwarded-Host headers. OpenLiteSpeed proxy
contexts automatically add X-Forwarded-* headers, so explicitly setting
them creates duplicates that cause n8n validation to fail.
Only the Origin header needs explicit configuration in extraHeaders.
This works with the patched OLS binary (MD5: b9c65aa2563778975d0d2361494e9d31)
that forwards Origin headers from the client.
- Changed from pinned version 1.86.1 to latest
- Requires OpenLiteSpeed binaries with Origin header forwarding support
- Compatible with n8n 1.87.0+ which has strict Origin validation
Note: This requires the OpenLiteSpeed binary that includes the Origin
header forwarding patch in the proxy module. The patch is available
in the CyberPanel OpenLiteSpeed distribution.
- Pin n8n to version 1.86.1 to avoid Origin header validation issues
- Change N8N_HOST from 0.0.0.0 to domain for better compatibility
- Add N8N_PROXY_HOPS=1 to fix X-Forwarded-For errors
- Add N8N_ALLOWED_ORIGINS and N8N_ALLOW_CONNECTIONS_FROM for future compatibility
- Fix SetupN8NVhost to remove malformed Origin header setting
n8n versions 1.87.0+ introduced strict Origin header validation that is
incompatible with OpenLiteSpeed proxy (which doesn't forward Origin headers).
Version 1.86.1 works correctly with OLS and SSE push backend.
Implement safety checks to verify custom OpenLiteSpeed binaries work before committing to them:
Verification checks:
- Check library dependencies with ldd to detect missing libraries
- Test binary execution with -v flag to ensure it can run
- Detect issues like wrong binary type (ubuntu vs rhel) for the OS
Rollback mechanism:
- Automatically restore original binary from backup if verification fails
- Remove incompatible custom module
- Continue installation with standard OLS if custom binary fails
This prevents installation failures and system downtime when:
- Wrong binary type is downloaded due to OS detection issues
- Library dependencies are missing
- Binary cannot execute on the target system
Changes:
- Added verifyCustomBinary() method to check dependencies and execution
- Added rollbackCustomBinary() method to restore from backup
- Updated installCustomOLSBinaries() to verify and rollback on failure
- Applied to both install/installCyberPanel.py and plogical/upgrade.py
Benefits:
- Zero downtime: System falls back to working binary automatically
- Better error reporting: Shows which libraries are missing
- Safer upgrades: Users won't be left with broken installations
Add OS detection logic to download correct OpenLiteSpeed binaries based on system type:
- Ubuntu/Debian systems: Download binaries with libcrypt.so.1 (GLIBC 2.35)
- RHEL/AlmaLinux/Rocky 8+/9+: Download binaries with libcrypt.so.2 (GLIBC 2.34)
This fixes the "libcrypt.so.2: cannot open shared object file" error that occurred
when Ubuntu systems tried to use RHEL-compiled binaries.
Changes:
- Added detectBinarySuffix() method to both installCyberPanel.py and upgrade.py
- Updated binary URLs to use https://cyberpanel.net with OS-specific suffix
- Module URL: cyberpanel_ols_x86_64_{ubuntu|rhel}.so
- Binary URL: openlitespeed-phpconfig-x86_64-{ubuntu|rhel}
Binary compatibility matrix:
- Ubuntu 20.04/22.04/24.04, Debian 10+, CentOS 7 → ubuntu binaries
- AlmaLinux 8+/9+, Rocky 8+/9+, RHEL 8+/9+, OpenEuler → rhel binaries
Separate acme.sh certificate issuance and installation steps to ensure
domain configurations are properly stored. Previously, combining --issue
with --cert-file/--key-file/--fullchain-file in a single command caused
acme.sh to skip storing domain configs, breaking automatic renewals and
requiring manual certificate recreation for domain aliases.
- Ensure /home/cyberpanel directory exists with proper permissions before download
- Set directory permissions to 755 to allow application write access
- Refactor SCP/SFTP fallback logic to work regardless of debug mode
- Add better status messages during download process
- MySQL restore may return warnings that don't indicate actual failure
- Database restoration verification is handled by subsequent password operations
- Improves reliability of compressed backup restoration
- Changed from checking exit code to verifying file existence and size
- Resolves issue where successful mysqldump was incorrectly reported as failed
- Ensures backup file is created and not empty before marking as successful
- Added configurable compression for database backups using gzip streaming
- Implemented auto-detection in restore function for compressed and uncompressed formats
- Added performance optimizations including --single-transaction and --extended-insert
- Created configuration file for gradual feature rollout with safe defaults
- Added helper functions for checking system capabilities and configuration
- Included comprehensive test suite to verify backward compatibility
- Maintained 100% backward compatibility with existing backup infrastructure
- Implement timestamp-based filename verification (Method 1)
- Add file size validation with 1KB minimum requirement (Method 2)
- Filter to only check today's backup directory for accuracy (Method 3)
- Add optional SHA256 checksum verification for integrity (Method 5)
- Use find command with size filter for efficient SSH verification
- Fallback to SFTP with comprehensive file validation
- Enhanced logging for all verification steps and failures
- Remove unused 'Yesterday' variable that was never used
- Prevents false positives from old backup files
- Detects corrupted/incomplete backups via size check
- Fix inverted .find() logic that sent notifications when backups SUCCEEDED
- Add 'status': 'failed' field required by platform API
- Change HTTP to HTTPS for BackupFailedNotify endpoint
- Add comprehensive error handling and logging
- Add 30-second timeout on API requests
- Properly handle actualDomain vs site.domain.domain cases
- Introduced memory and processing time limits to prevent system overload during bandwidth calculations.
- Added error handling for file operations and improved logging for better traceability.
- Implemented batch processing of log lines to manage memory usage effectively.
- Updated methods to safely parse log data and handle large files, ensuring robust performance.
- Refactored code for clarity and maintainability, including the addition of helper functions for file size and memory limit settings.
- Updated settings.py to include PhpMyAdminAccessMiddleware for enhanced access control.
- Modified phpmyadminsignin.php to check user session and redirect to the login page if not authenticated.
- Changed PHP symlink from version 8.0 to 8.3 in various scripts to ensure compatibility with the latest PHP version.
- Updated documentation links in the FAQ to point to the new community support page.
- Added checks and fixes for MariaDB installation issues specific to AlmaLinux 9.
- Enhanced the installation script to support additional PHP versions and improve overall installation reliability.
- Implement directory integrity checks to detect missing CyberPanel components
- Add automatic recovery by cloning fresh repository when essential directories are lost
- Create database credential recovery with automatic password reset capability
- Update all service configurations (FTP, PowerDNS, Postfix, Dovecot) when password is reset
- Add service restart functionality to apply new configurations
- Preserve existing configuration files during recovery process
- Handle both Ubuntu (root password) and CentOS (separate password) database configurations
This ensures upgrades can complete successfully even when /usr/local/CyberCP is completely lost.
- Remove CSF menu item from sidebar navigation
- Disable CSF-related URL endpoints in firewall module
- Update upgrade process to automatically remove CSF and restore firewalld
- Archive CSF template and configuration files
- Clean up CSF references in settings and upgrade scripts
CSF (ConfigServer Security & Firewall) is shutting down on August 31, 2025.
This commit removes CSF integration and ensures firewalld is restored as the
default firewall solution during upgrades.
Fixes#1473
The issue was that restoreCriticalFiles was restoring the OLD settings.py from backup
which didn't have new apps like 'aiScanner' in INSTALLED_APPS.
Solution:
- Modified restoreCriticalFiles to skip settings.py restoration
- Keep the NEW settings.py from the fresh clone (which has aiScanner in INSTALLED_APPS)
- Only update the DATABASES section with saved credentials from backup
- This preserves all new app registrations while maintaining database connectivity
This properly fixes the RuntimeError about aiScanner.status_models.ScanStatusUpdate
not being in INSTALLED_APPS after upgrades.
usmannasir
Master3395