CyberPanel previously added _dmarc at the apex (p=none) in two code paths and _dmarc on every child subdomain, which conflicts with a single externally managed policy (e.g. Cloudflare) and violates RFC 7489 (one TXT RRset per name). Comment out automatic DMARC creation so operators set one record at _dmarc.<apex> only.
- dnsUtilities: correct createDNSRecordCloudFlare argument order (priority, ttl)
- vhostConfs/ApacheVhosts: OLSLBConf uses real docRoot and acme-challenge path for child vhosts (vhRoot is parent domain)
- virtualHostUtilities: defer ChildDomains save until after SSL/Apache; cleanup ORM row on failure; createDomain CLI exits 0/1 with 1,/0, stdout
- websiteFunctions: submitDomainCreation waits on subprocess and returns failure JSON on error
When removing a child domain, matching only the apex label (e.g. vscode)
left mail.* and www.* (and MX/TXT/DMARC) records in the parent zone.
Normalize record names to FQDN under the zone and delete the subdomain
FQDN plus any names under it.
Raise default CYBERCP_MANAGED_APPS version cache TTL to 3600s to match
Manage Applications inventory behavior and reduce cold DNF fetches.
Refresh application_page_meta and synced manageServices static assets.
Align updateContainer with the panel (name vs containerName), pull new
images before removing the old container, and sync the Containers model
after a successful update. getContainerList now shows live Config.Image
so tags match Docker. Add notification-center progress for updates,
guard overlapping requests, and return new_image on success.
Add modular application packages with backup-aware install/upgrade/downgrade,
DNF-backed version lists with TTL caching, and HTML bootstrap for faster loads.
Improve the version picker (labels, selection state, background meta refresh) and
route applicationMeta through shared page meta cache. Update static assets and
cache buster for manageServices.js. Repository also includes related updates to
serviceManager, upgrade tooling, website functions, and user management from this
development tree.
Wire RabbitMQ into app management UI/actions, optional fresh-install flag handling, and upgrade-safe marker/service reconciliation so new installs and upgrades can expose it reliably.
- POST /plugins/api/delete-source/<name>/ removes copies under plugin source paths only
- Require safe plugin id, block if still installed under CyberCP; symlink-aware paths
- Clear state file, informCyberPanelRemoval, invalidate store cache
- UI: Delete local copy in grid/table/store; two-step confirm; amber button style
- Enrich store JSON with has_local_source and builtin
- Honor downloadAndUpgrade return value; exit 1 instead of printing Upgrade Completed
- Restart lscpd if code update fails so panel is reachable on old tree
- CYBERPANEL_UPGRADE_CLONE_ATTEMPTS (default 2) for transient clone errors
- On rmtree failure, move /usr/local/CyberCP aside instead of aborting when possible
- Export CYBERPANEL_UPGRADE_CLONE_ATTEMPTS from 08_main_upgrade.sh
- Parse git origin; show fork block only when not usmannasir/cyberpanel
- Always fetch official upstream branch tip; fetch fork tip when fork
- Notecheck: fork installs vs fork tip; official vs upstream tip
- Template: tracking branch, optional fork rows, drift info; clarify warning
- views: remote_display, branch_ref, fork_remote_commit, upstream_commit,
short SHAs, GitHub commit URLs, notecheck_compare_remote, local_behind_official
- template: installation grid, full-width meta rows, i18n upgrade note,
info notice when local differs from official upstream on dev
Official usmannasir/cyberpanel origin still uses upstream v2.5.5-dev tip;
forks now resolve latest commit from origin owner/repo so local HEAD can
match Latest Commit without false upgrade notices.
- getBannedIPs: append AutoBanLog rows (latest per IP) not already in DB/JSON
- Skip expired timed bans; tag rows with ban_source autoBanSecurityAlerts
- removeBannedIP/deleteBannedIP: handle synthetic id ablog-<pk> via unban by IP
- Harden meta.xml sync (cache-bust, no CDN downgrade); ZIP meta fallback; fail if version stuck
- Invalidate plugin store cache after successful upgrade
- Add modify_timestamp for browser-local DD.MM.yyyy / 24h display via toLocaleString
- Upgrades table: Your Version column before New Version; freshness uses timestamp when present
- Add plogical/phpmyadmin_utils.ensure_phpmyadmin_signin_bridge: restore
phpmyadminsignin.php and tmp/ if missing (fixes 404 on /phpmyadmin/phpmyadminsignin.php).
- Call from databases phpMyAdmin page, fetchDetailsPHPMYAdmin, install, and upgrade PMA paths.
- install/upgrade: use makedirs(..., exist_ok=True) for phpmyadmin/tmp instead of mkdir.
- pluginInstaller: run migrate when migrations/ contains modules OR enable_migrations;
use CyberCP venv python; --noinput for migrate; log non-zero exits.
Use session userID -> Administrator email for subscription checks, activation persistence, and paid-plugin access when Django auth user is not populated.
Render next cache update in Norwegian format and mark overdue cache clearly while triggering background refresh from Installed view when cache metadata is expired.
Inject a lightweight fetch hook into settings pages to call store-activation after successful plugin activation responses, reducing premium relock risk after upgrades.
- Use lscpd.0.4.0 on Alma 9/10 and RHEL-family VERSION_ID 9/10
- daemon-reload + retry systemctl start lscpd in setupLSCPDDaemon
- 04_after_install: _restart_lscpd_safe + libxcrypt-compat on EL10 prereqs
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.
- 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.
- Install python-dotenv in virtual environment during CyberPanel setup
- Fixes Django's inability to load .env file on AlmaLinux 8
- Resolves "Access denied for user 'cyberpanel'@'localhost'" errors
- Added to all installation paths (normal, DEV, and after_install)
This ensures Django can properly load database credentials from .env file
on AlmaLinux 8 systems where python-dotenv was missing.
- Updated OS detection logic to include CentOS Stream and Red Hat Enterprise Linux.
- Added support for AlmaLinux 9 and 10, as well as Debian 11, 12, and 13.
- Improved error messages to reflect the expanded list of supported operating systems.
- Adjusted package management handling for Debian to treat it as Ubuntu for compatibility.
