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.
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.
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
- 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.
During the upgrade process, settings.py was being overwritten with only the DATABASES
section preserved, causing loss of INSTALLED_APPS and other configurations. This resulted
in the 'aiScanner' app not being recognized after upgrade.
Fixed by:
- Improving the regex pattern to more accurately match only the DATABASES dictionary
- Adding re.DOTALL flag to handle multi-line DATABASES configuration
- Ensuring all other settings including INSTALLED_APPS are preserved during upgrade
This resolves the RuntimeError about aiScanner.status_models.ScanStatusUpdate not having
an explicit app_label.
