Postfix SASL PLAIN auth fails with "No worthy mechs found" on
RHEL/AlmaLinux because cyrus-sasl-plain is not installed by default.
- Add cyrus-sasl-plain to postfix install in install.py
- Auto-install in configureRelayHost() for existing servers
- Add to upgrade.py setupSieve() for existing installations
lscpd worker runs as user lscpd, not cyberpanel. The webmail.conf file
(containing master user credentials) was unreadable by lscpd, causing
master auth to silently fail and fall back to empty password auth.
Also fix ownership on existing installs during upgrade.
- Replace free text input with folder dropdown for move-to-folder rules
- Auto-prefix INBOX. namespace to folder names in sieve scripts
- Strip INBOX. prefix when parsing sieve scripts back to rules
- Make upgrade setupSieve() regexes more flexible to handle config variations
- Add os.makedirs for conf.d directory in both install and upgrade
- Validate ManageSieve config with both inet_listener and service checks
- Add home directory (CONCAT) to dovecot-sql.conf.ext user_query so sieve
can locate script storage per user
- Add sieve/sieve_dir plugin settings to dovecot.conf templates
- Add lda_mailbox_autocreate/autosubscribe so fileinto creates missing folders
- Update setupSieve() upgrade function to patch all three on existing installs
On Ubuntu, the install creates /etc/pki/dovecot/ directories but never
populates them with certs. Postfix main.cf references these paths for
STARTTLS. Without them, inbound STARTTLS fails and external mail servers
(Gmail etc.) drop the connection, preventing mail delivery.
Security fixes:
- Escape plain text body to prevent XSS via trustAsHtml
- Add SSRF protection to image proxy (block private IPs, require auth)
- Sanitize Content-Disposition filename to prevent header injection
- Escape Sieve script values to prevent script injection
- Escape IMAP search query to prevent search injection
Install/upgrade fixes:
- Move setupWebmail() call to after Dovecot is installed (was running
before doveadm existed, silently failing on every fresh install)
- Make setupWebmail() a static method callable from install.py
- Fix upgrade idempotency: always run dovecot.conf patching and
migrations even if webmail.conf already exists (partial failure recovery)
Frontend fixes:
- Fix search being a no-op (was ignoring results and just reloading)
- Fix loading spinner stuck forever on API errors (add errback)
- Fix unread count decrementing on already-read messages
- Fix draft auto-save timer leak when navigating away from compose
- Fix composeToContact missing signature and auto-save
- Fix null subject crash in reply/forward
- Clear stale data when switching accounts
- Fix attachment part_id mismatch between parser and downloader
Backend fixes:
- Fix Sieve _read_response infinite loop on connection drop
- Add login check to apiSaveDraft
- Fix apiSSO() resetting selected account to first one on every call,
now preserves previously selected account if still valid
- Fix webmail.conf ownership to use cyberpanel:cyberpanel (Django runs
as cyberpanel user, not nobody)
- Add error notifications when SSO or folder loading fails
Adds master passdb config to dovecot.conf templates, setupWebmail() to
the installer and upgrade paths to generate credentials and create
/etc/dovecot/master-users and /etc/cyberpanel/webmail.conf automatically.
The upgrade path is idempotent and patches existing dovecot.conf if needed.
Rebuilt module fixes NULL pointer dereference in apply_headers() when
OLS generates error responses (4xx/5xx). The get_req_var_by_id() call
for DOC_ROOT crashed because request variables aren't initialized
during error response generation. Fix adds status code guard to skip
header processing for error responses.
New hashes for all 3 platforms after fixing the bug where VHosts with
SSL context but missing listener map entries served the wrong cert.
rhel9: 04921afbad94e7ee69bc93a73985e318df93f28b2b0d578447b0ef43dc6e3818
ubuntu: ae2564742f362d3e34ea814dff37edeb8f8b73ae9ca1484ba78e2453a3987429
rhel8: 855b6bccb4a7893914506a07185cffd834bd31a7f7c080b5b4190283def7fa3e
The previous string replace only matched 'adminEmails root@localhost'
exactly. On fresh OLS installs where adminEmails may have a different value
or different spacing, the replace would silently fail and Auto-SSL config
would never be injected. Use re.sub to match the adminEmails line regardless
of its value.
The string replace matched only 'adminEmails' keyword instead of the
full existing line 'adminEmails root@localhost', causing
the remaining ' root@localhost' to trail onto the acmeEmail
line and break ACME account registration.
Universal binaries with all features config-driven (PHPConfig API, Origin
Header Forwarding, ReadApacheConf with Portmap, Auto-SSL ACME v2,
ModSecurity ABI compatibility). Updates install, upgrade, and modSec paths.
- Update cyberpanel_ols module URLs to use /binaries/ path structure
- Update SHA256 checksums for all platforms (rhel8, rhel9, ubuntu)
- Enable RHEL 8 module support (was previously disabled)
- Module version 2.2.0 with Phase 2 features
- Fix checkOwnership() to return explicit 0 instead of None when checking child domain ownership
This resolves permission failures for non-admin ACL users trying to manage child domains
- Improve fetchChildDomainsMain() with more robust child domain filtering
Changed from .filter(alais=0) to .all() with explicit check to prevent silent failures
- Add error logging with traceback to fetchChildDomainsMain() for better debugging
These changes allow non-admin users with proper ACL permissions to view and manage
child domains for websites they own.
The container health check was failing because Docker Compose v1 and v2
use different naming conventions:
- v1: project_service_1 (underscores)
- v2: project-service-1 (hyphens)
Changes:
1. Replaced hardcoded container name formatting with fuzzy matching
2. Added find_container_by_service() helper method for dynamic lookup
3. Updated monitor_deployment() to use dynamic container discovery
4. Container names are now found by normalizing and matching patterns
This fixes "Containers failed to reach healthy state" errors during
n8n deployment from CyberPanel UI.
Ticket References: XKTFREZUR, XCGF2HQUH
1. Set NODE_ENV=development for n8n Docker deployments to resolve Origin
header validation failures.
2. Remove ineffective "RequestHeader set Origin" from vhost configuration
since OpenLiteSpeed cannot override browser Origin headers anyway.
This is required due to an OpenLiteSpeed architectural limitation - OLS
cannot override browser Origin headers, which n8n v1.87.0+ strictly
validates in production mode. Apache and Nginx can override Origin headers
and work in production mode, but this is not possible with OpenLiteSpeed.
Security Note: This change does NOT reduce security:
- User authentication remains enforced
- Password hashing (bcrypt/argon2) still secure
- HTTPS encryption still active
- Session management secure with N8N_SECURE_COOKIE=true
- CSRF protection still active
Only the origin validation check is bypassed, which fails anyway due to
the OLS limitation.
Ticket References: XKTFREZUR, XCGF2HQUH
This commit resolves issues where the OWASP CRS toggle in ModSecurity settings
would appear to flip back to OFF even when installation succeeded, and improves
detection of manually installed OWASP CRS rules.
Issues Fixed:
1. Toggle not updating immediately after installation/uninstallation
2. Manual OWASP installations to rules.conf not detected by toggle
3. Silent installation failures without detailed error logging
Changes:
firewall/static/firewall/firewall.js:
- Update toggle state immediately after successful installation (getOWASPAndComodoStatus(true))
- Update toggle state after failed installation to show correct OFF state
- Provides instant visual feedback instead of requiring page refresh
firewall/firewallManager.py (getOWASPAndComodoStatus):
- Expand detection logic to check both httpd_config.conf AND rules.conf
- Detect manual OWASP installations (Include/modsecurity_rules_file with owasp/crs-setup)
- Case-insensitive pattern matching for better compatibility
plogical/modSec.py (setupOWASPRules):
- Add specific error logging for each installation step failure
- Log detailed messages: directory creation, download, extraction, configuration
- Helps diagnose: network issues, missing tools (wget/unzip), permission problems
Impact:
- Toggle correctly reflects OWASP CRS state after enable/disable operations
- Manual installations following external tutorials now detected correctly
- Installation failures are logged with specific error messages for debugging
- Improves UX by eliminating perception that "toggle keeps flipping back"
Fixes: OWASP CRS toggle UI bug
Related: Community thread https://community.cyberpanel.net/t/4-mod-security-rules-packages/133/8
Related: Ticket #GTPDPO7EV
This commit resolves the issue where CyberPanel attempts to configure email/DKIM settings
even when email services were explicitly disabled during custom installation, causing
hostname SSL setup and website creation to fail with "No such file or directory: '/etc/postfix/main.cf'" errors.
Changes:
- Added emailServicesInstalled() utility function to check for /home/cyberpanel/postfix marker
- OnBoardingHostName(): Wrap email operations (issueSSLForMailServer, postfix commands) with checks
- OnBoardingHostName(): Allow hostname setup to complete without email services
- issueSSLForMailServer(): Add early return if email services not installed
- issueSSLForMailServer(): Verify /etc/postfix directory exists before operations
- issueSSLForMailServer(): Check /etc/postfix/main.cf exists before reading
- setupAutoDiscover(): Add early return if email services not installed
- setupAutoDiscover(): Check /etc/postfix/main.cf exists before accessing
- mailUtilities.configureOpenDKIM(): Verify main.cf exists before configuration
Impact:
- Hostname SSL setup now completes successfully without email components
- Website creation works correctly on custom installs without email
- No more file not found errors for /etc/postfix/main.cf
- Graceful degradation: operations skip email setup with log messages
Fixes: Custom installation hostname SSL 404 error
Fixes: Website creation DKIM failure on custom installs
Related: Ticket #RMKRFFGKC
- Verify lscgctl works after running lssetup
- Retry with more slices (-c 10) if first attempt fails
- Add detailed logging to debug setup issues
- Add time.sleep() to give lssetup time to initialize
- Provide clear error messages if setup fails
- Pass --io parameter to lscgctl with bytes/sec value
- Convert ioLimitMBPS from MB/s to bytes/s for lscgctl
- Update log message to include I/O limit information
- Add note about systemd io controller delegation requirement
- Add test to verify LiteSpeed Containers is actually configured
- Check for 'You must configure LiteSpeed' error in lscgctl output
- Run lssetup with proper flags when configuration is needed
- Fixes issue where lscgctl exists but LiteSpeed Containers not configured
Detect RHEL 8, AlmaLinux 8, Rocky Linux 8, and CloudLinux 8 systems and provide
clear instructions when cgroups v2 needs manual enablement.
These systems have cgroups v2 backported to kernel 4.18 but it's disabled by
default. When detected without cgroups v2 enabled, the system now:
1. Detects RHEL 8 family by checking /etc/redhat-release
2. Verifies if cgroups v2 is mounted (checks 'mount' output for 'cgroup2')
3. If not enabled, logs detailed instructions:
- grubby command to add kernel parameter
- Reboot instruction
- Verification command
- Clear step-by-step guide
Changes:
- _check_rhel8_cgroups_v2(): New method for RHEL 8 family detection
- _ensure_cgroups_enabled(): Calls RHEL 8 check before general checks
- check_cgroup_support(): Returns RHEL 8 status in support dict
- rhel8_family: bool (detected RHEL 8 family)
- rhel8_needs_enablement: bool (cgroups v2 not mounted)
- os_name: str (full OS name from release file)
OS Support Status:
✅ Ubuntu 20.04+ - Native cgroups v2 (kernel 5.4+)
✅ RHEL/Alma/Rocky 9+ - Native cgroups v2 (kernel 5.14+)
⚠️ RHEL/Alma/Rocky/CloudLinux 8 - Needs manual enable (kernel 4.18 backported)
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.
