diff --git a/to-do/CYBERCP-GIT-PULL-CONFLICTS-V2.5.5-DEV.md b/to-do/CYBERCP-GIT-PULL-CONFLICTS-V2.5.5-DEV.md deleted file mode 100644 index 55134e4a3..000000000 --- a/to-do/CYBERCP-GIT-PULL-CONFLICTS-V2.5.5-DEV.md +++ /dev/null @@ -1,63 +0,0 @@ -# CyberCP git pull conflicts on v2.5.5-dev (server at /usr/local/CyberCP) - -## Why Git asks to "remove" or "move" files - -When you run `git pull --ff-only origin v2.5.5-dev` in `/usr/local/CyberCP`, Git can block for two reasons: - -### 1. Modified files (would be overwritten by merge) - -- **Meaning:** You have **local changes** in tracked files (e.g. `CyberCP/settings.py`, `baseTemplate/views.py`, …). The remote branch also changed those files. Git will not overwrite your working tree without you deciding what to do with your changes. -- **So:** You must either **commit** or **stash** (or discard) those local changes before the pull can apply. - -### 2. Untracked files (would be overwritten by merge) - -- **Meaning:** You have **untracked** files/dirs at paths where the **incoming** branch (v2.5.5-dev) **adds** files. For example: `panelAccess/`, `baseTemplate/static/baseTemplate/assets/mobile-responsive.css`, `sql/create_ftp_quotas.sql`, etc. Git will not overwrite untracked content, so it refuses to merge and says "Please move or remove them." -- **So:** You must **move or remove** those untracked paths so Git can write the version from the repo there. - -## Are all these files on v2.5.5-dev? - -- **Yes.** The branch `v2.5.5-dev` on `master3395/cyberpanel` contains: - - All the modified paths (canonical versions). - - All the "untracked" paths (e.g. `panelAccess/`, `mobile-responsive.css`, `readability-fixes.css`, `emailLimitsController.js`, `create_ftp_quotas.sql`, `firewall/migrations/0001_initial.py`, `install/ols_binaries_config.py`, etc.). -- So the **repo** is the source of truth; the server just needs to be brought in line with it. You can confirm by cloning fresh: `git clone -b v2.5.5-dev https://github.com/master3395/cyberpanel.git` and listing those paths. - -## Safe way to sync the server to v2.5.5-dev - -If you are **ok discarding all local and untracked changes** in `/usr/local/CyberCP` and making it exactly match `origin/v2.5.5-dev`: - -```bash -cd /usr/local/CyberCP - -# Optional: backup current state -tar -czf /root/cybercp-backup-before-sync-$(date +%Y%m%d-%H%M%S).tar.gz . - -# Reset tracked files to current HEAD and remove untracked/ignored files -git fetch origin -git checkout v2.5.5-dev -git reset --hard origin/v2.5.5-dev -git clean -fd - -# Ensure you're up to date (should already be after reset) -git pull --ff-only origin v2.5.5-dev -``` - -After this, **Current** in Version Management should match **Latest** (commit `c24f067e` or whatever is the tip of `origin/v2.5.5-dev`). - -## If you need to keep local changes - -- **Tracked changes:** Stash first, then pull, then re-apply: - ```bash - cd /usr/local/CyberCP - git stash push -m "before sync v2.5.5-dev" - # move or remove the untracked paths listed by Git (e.g. backup then delete) - git pull --ff-only origin v2.5.5-dev - git stash pop - ``` -- **Untracked files:** Back them up to another directory (e.g. `/root/cybercp-untracked-backup/`) before removing or moving them, then run the pull. - -## Upgrade script sync step - -The upgrade script’s `Sync_CyberCP_To_Latest()` runs `git fetch`, `checkout`, and `git pull --ff-only`. If the server has local or untracked conflicts like above, that pull will keep failing until you either: - -- Run the "safe way" (reset + clean) on the server once, or -- Change the script to use `git reset --hard origin/$Branch_Name` and `git clean -fd` so the install is forced to match the remote (only do this if you intend the install to always mirror the repo with no local edits). diff --git a/to-do/DEPLOY-BEFORE-PUSH-V2.5.5-DEV.md b/to-do/DEPLOY-BEFORE-PUSH-V2.5.5-DEV.md deleted file mode 100644 index 60ebf62c2..000000000 --- a/to-do/DEPLOY-BEFORE-PUSH-V2.5.5-DEV.md +++ /dev/null @@ -1,26 +0,0 @@ -# Deploy Locally Before Push (v2.5.5-dev) - -## Rule -**Always deploy to the local CyberPanel installation before pushing to v2.5.5-dev.** - -When deploying and pushing changes: - -1. **First: Deploy locally** - Copy all modified/relevant files from the repo to `/usr/local/CyberCP`, preserving directory structure. - -2. **Then: Commit and push** - Stage the same files, commit (author: `master3395`), and push to `origin v2.5.5-dev`. - -## Order -1. Deploy → 2. Commit → 3. Push - -Never push to v2.5.5-dev without deploying to `/usr/local/CyberCP` first. - -## Example -```bash -# 1. Deploy -cp /home/cyberpanel-repo/path/to/file /usr/local/CyberCP/path/to/ - -# 2. Commit and push -cd /home/cyberpanel-repo && git add ... && git commit -m "..." --author="master3395 " && git push origin v2.5.5-dev -``` diff --git a/to-do/DEPLOY-MYSQL-MANAGER-TO-SERVER.md b/to-do/DEPLOY-MYSQL-MANAGER-TO-SERVER.md deleted file mode 100644 index beca2ceca..000000000 --- a/to-do/DEPLOY-MYSQL-MANAGER-TO-SERVER.md +++ /dev/null @@ -1,53 +0,0 @@ -# Deploy MySQL Manager fixes to the server (e.g. 207.180.193.210) - -## Why you still see no data - -- The URL **https://207.180.193.210:2087** is the **remote server** (or your server’s public IP). It is **not** “localhost.” -- Our earlier deploy commands ran on the machine where the repo lives. If that machine is **not** the one serving 207.180.193.210, then the panel you open in the browser is still running the **old** code and old `databases.js`. -- Seeing **`{$ Slow_queries $}`** (literal text) and empty processes means the **Mysqlmanager** controller or the updated JS is not running on the server that serves that URL. - -## Fix: run the deploy on the server that serves 207.180.193.210 - -You must copy the updated files into CyberPanel **on the same machine** that serves https://207.180.193.210:2087 (i.e. where `/usr/local/CyberCP` is used by the panel). - -### Option A – You have the repo on that server (e.g. at `/home/cyberpanel-repo`) - -SSH to **207.180.193.210** (or the host that serves that IP) and run: - -```bash -# Path to repo on THAT server (change if different) -REPO=/home/cyberpanel-repo - -cp "$REPO/plogical/mysqlUtilities.py" /usr/local/CyberCP/plogical/ -cp "$REPO/databases/views.py" /usr/local/CyberCP/databases/ -cp "$REPO/databases/static/databases/databases.js" /usr/local/CyberCP/databases/static/databases/ -cp "$REPO/static/databases/databases.js" /usr/local/CyberCP/static/databases/ -# LiteSpeed serves /static/ from public/static/ – must deploy here or the browser gets the old file -mkdir -p /usr/local/CyberCP/public/static/databases -cp "$REPO/static/databases/databases.js" /usr/local/CyberCP/public/static/databases/ - -# Restart panel so changes are used -systemctl restart lscpd - -echo "MySQL Manager deploy done. Hard-refresh the MySQL Manager page (Ctrl+Shift+R)." -``` - -### Option B – Repo is only on another machine (e.g. your dev box) - -1. Copy the **four files** from the machine that has the repo to **207.180.193.210** (e.g. with `scp` or `rsync`): - - `plogical/mysqlUtilities.py` - - `databases/views.py` - - `databases/static/databases/databases.js` - - `static/databases/databases.js` - -2. On **207.180.193.210**, run the same `cp` commands as in Option A, using the paths where you put those files instead of `$REPO`. - -3. Restart the panel: - `systemctl restart lscpd` - -### After deploy - -- Open **https://207.180.193.210:2087/dataBases/MysqlManager** -- Do a **hard refresh**: **Ctrl+Shift+R** (or Cmd+Shift+R on Mac) so the browser doesn’t use cached `databases.js`. - -If you still see no data, open the browser **Developer Tools (F12) → Console** and note any red errors (e.g. `ctrlreg` or 404 for `databases.js`), then share that message. diff --git a/to-do/FIREWALL-LOAD-CHANGES.md b/to-do/FIREWALL-LOAD-CHANGES.md deleted file mode 100644 index 187e100e1..000000000 --- a/to-do/FIREWALL-LOAD-CHANGES.md +++ /dev/null @@ -1,64 +0,0 @@ -# Firewall Rules & Banned IPs – Making Sure Changes Load - -If Firewall Rules or Banned IPs don’t show the latest UI (Modify buttons, Per-page dropdown, Search, etc.), do the following. - -## 1. Sync firewall JavaScript (when you change firewall JS) - -The panel can serve `firewall/firewall.js` from the **firewall app** (`firewall/static/firewall/firewall.js`) or from **static/** after collectstatic. The cache-buster uses the newest mtime from: - -- `firewall/static/firewall/firewall.js` -- `static/firewall/firewall.js` -- `public/static/firewall/firewall.js` - -So that the query param updates when any of these change. - -**After editing `firewall/static/firewall/firewall.js`, sync copies so all paths are up to date:** - -```bash -# From repo root -mkdir -p static/firewall public/static/firewall -cp firewall/static/firewall/firewall.js static/firewall/ -cp firewall/static/firewall/firewall.js public/static/firewall/ -``` - -## 2. Templates - -The firewall **HTML** comes from the **firewall app** template: - -- `firewall/templates/firewall/firewall.html` - -Django loads it when you open the firewall page. There is no separate copy under `static/` or `baseTemplate/` for that page. So any change in `firewall/templates/firewall/firewall.html` is used as long as the running app is your repo (or a deploy that includes this file). - -## 3. Where CyberPanel stores files (production) - -- **Production root:** `/usr/local/CyberCP` – the full repo (including `firewall/`, `baseTemplate/`, etc.) lives here after install/upgrade. -- **Upgrade sync:** `upgrade_modules/09_sync.sh` runs from that directory (`git fetch` / checkout / pull). After sync, it copies **baseTemplate** static and **firewall** static into `public/static/` so LiteSpeed serves the latest dashboard and firewall JS. -- **Firewall code:** `firewall/templates/firewall/firewall.html` and `firewall/static/firewall/firewall.js` under `/usr/local/CyberCP`. LiteSpeed serves `/static/firewall/firewall.js` from `public/static/firewall/firewall.js`, which is updated by the upgrade script. - -## 4. Production (e.g. `/usr/local/CyberCP`) – manual deploy - -If the panel runs from an **installed** path (e.g. `/usr/local/CyberCP`), that directory is often a copy of the repo. Then: - -- Replace or update the firewall app there with your repo version: - - `firewall/templates/firewall/firewall.html` - - `firewall/static/firewall/firewall.js` -- If the installer or deploy uses `static/` or `public/static/`, copy the same `firewall.js` there too (as in step 1). -- Restart the app server (e.g. Gunicorn/LiteSpeed) so Django and static file serving use the new files. - -## 5. Browser cache - -The script tag uses a cache-buster: -`?v={{ CP_VERSION }}&fw={{ FIREWALL_STATIC_VERSION }}&cb=4` - -- Do a **hard refresh**: Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac). -- Or clear cache for the panel site and reload. - -## 6. Quick checklist - -- [ ] `firewall/static/firewall/firewall.js` has the latest code. -- [ ] Synced to `static/firewall/firewall.js` and `public/static/firewall/firewall.js` (see step 1). -- [ ] `firewall/templates/firewall/firewall.html` has the latest markup (Modify buttons, modals, Per page dropdown). -- [ ] If using an installed path, copy updated firewall app (and static copies) there and restart the server. -- [ ] Hard refresh (or clear cache) in the browser. - -After this, Firewall Rules and Banned IPs should load the correct layout and Modify buttons. diff --git a/to-do/HTTP-500-AFTER-GIT-SYNC-RECOVERY.md b/to-do/HTTP-500-AFTER-GIT-SYNC-RECOVERY.md deleted file mode 100644 index f82eb4c92..000000000 --- a/to-do/HTTP-500-AFTER-GIT-SYNC-RECOVERY.md +++ /dev/null @@ -1,113 +0,0 @@ -# HTTP 500 after git sync – recovery steps - -## Cause - -After running `git reset --hard origin/v2.5.5-dev` and `git clean -fd` in `/usr/local/CyberCP`, the **repo’s** `CyberCP/settings.py` replaced the **server’s** production `settings.py`. The repo file has different (or placeholder) database credentials and config, so the app can’t connect to the DB or behaves incorrectly → **500** on `/base/` and elsewhere. - -## 1. Restore production `settings.py` - -Use one of these options. - -### A. From your tarball backup (recommended) - -You created a backup before sync, e.g.: - -`/root/cybercp-backup-before-sync-YYYYMMDD-HHMMSS.tar.gz` - -Restore only `settings.py`: - -```bash -cd /root -# List to find the exact backup name -ls -la cybercp-backup-before-sync-*.tar.gz - -# Restore CyberCP/settings.py (tarball was created from /usr/local/CyberCP so paths start with . or ./) -BACKUP=$(ls -t cybercp-backup-before-sync-*.tar.gz 2>/dev/null | head -1) -if [ -n "$BACKUP" ]; then - tar -xzf "$BACKUP" -C /usr/local/CyberCP ./CyberCP/settings.py 2>/dev/null || \ - tar -xzf "$BACKUP" -C /usr/local/CyberCP CyberCP/settings.py 2>/dev/null - echo "Restored settings.py from $BACKUP" -else - echo "No backup found in /root" -fi -``` - -If the archive has no leading `./`, try: - -```bash -tar -xzf "$BACKUP" -C /usr/local/CyberCP --strip-components=0 CyberCP/settings.py -# or -tar -xzf "$BACKUP" -C /tmp cp CyberCP/settings.py && mv /tmp/CyberCP/settings.py /usr/local/CyberCP/CyberCP/ -``` - -### B. From upgrade script backup (if a previous upgrade ran) - -The upgrade script backs up to `/tmp/cyberpanel_settings_backup.py`: - -```bash -if [ -f /tmp/cyberpanel_settings_backup.py ]; then - cp /tmp/cyberpanel_settings_backup.py /usr/local/CyberCP/CyberCP/settings.py - echo "Restored settings.py from /tmp" -fi -``` - -### C. If you have no backup - -Edit `/usr/local/CyberCP/CyberCP/settings.py` and set the **DATABASES** section to match your server: - -- Same DB name, user, and password as used before the sync (e.g. from another backup or from the MySQL/MariaDB config your install used). - -## 2. Restart CyberPanel / LiteSpeed - -So the app loads the restored config: - -```bash -systemctl restart lscpd -# or, depending on setup: -# systemctl restart lsws -``` - -Wait a few seconds, then try https://207.180.193.210:2087/ and https://207.180.193.210:2087/base/ again. - -## 3. If 500 persists – get the real error - -Run: - -```bash -# Application log (Django/CyberPanel) -tail -100 /home/cyberpanel/error-logs.txt - -# LiteSpeed / WSGI errors -tail -100 /usr/local/lscp/logs/error.log - -# If present -tail -100 /usr/local/CyberCP/logs/cyberpanel.log -journalctl -u lscpd -n 50 --no-pager -``` - -Then run Django check and migrate: - -```bash -cd /usr/local/CyberCP -source /usr/local/CyberCP/bin/activate # if venv exists -python manage.py check -python manage.py migrate --noinput -``` - -Fix any errors reported (e.g. missing DB user, wrong password, or migrations). - -## 4. Future syncs – keep production settings - -Before running `git reset --hard` again: - -1. Back up `settings.py`: - ```bash - cp /usr/local/CyberCP/CyberCP/settings.py /root/cyberpanel_settings_production.py - ``` -2. After sync, restore it: - ```bash - cp /root/cyberpanel_settings_production.py /usr/local/CyberCP/CyberCP/settings.py - systemctl restart lscpd - ``` - -Or add a small script that does sync then restores `settings.py` and restarts `lscpd`. diff --git a/to-do/INSTALL-MODULES-DESIGN.md b/to-do/INSTALL-MODULES-DESIGN.md deleted file mode 100644 index 55eb861de..000000000 --- a/to-do/INSTALL-MODULES-DESIGN.md +++ /dev/null @@ -1,36 +0,0 @@ -# Install modularization design - -## Overview -- **cyberpanel.sh**: Modular loader; sources `install_modules/00_common.sh` … `09_parse_main.sh`. When `install_modules/` is missing (e.g. one-liner), downloads modules from GitHub. -- **install.sh**: Wrapper that detects OS, checks disk; if repo has `cyberpanel.sh` + `install_modules/`, runs local loader; else downloads `cyberpanel.sh` and runs it. -- **install/venvsetup.sh**: Loader that sources `install/venvsetup_modules/01_*` … `05_*`. Original kept as `install/venvsetup_monolithic.sh`. - -## install_modules/ (repo root) -| Module | Lines | Content | -|--------|-------|---------| -| 00_common.sh | ~418 | Globals, log_message, print_status, show_banner, detect_os, fix_static_file_permissions, fix_post_install_issues | -| 01_verify_deps.sh | ~129 | verify_installation, install_dependencies | -| 02_install_core.sh | ~390 | install_cyberpanel, check_cyberpanel_installed, cleanup_existing_cyberpanel, install_cyberpanel_direct (part 1) | -| 03_install_direct.sh | ~411 | install_cyberpanel_direct_cont | -| 04_fixes_status.sh | ~210 | apply_fixes, _port_listening, show_status_summary | -| 05_menus_main.sh | ~328 | show_main_menu, show_fresh_install_menu, show_commit_selection, show_version_selection, show_installation_preferences | -| 06_menus_update.sh | ~247 | show_update_menu, show_reinstall_menu, show_system_status | -| 07_menus_advanced.sh | ~273 | show_advanced_menu, show_error_help, show_fix_menu, show_clean_menu, show_logs_menu, show_diagnostics | -| 08_actions.sh | ~317 | start_upgrade, start_force_reinstall, start_preupgrade, start_reinstall, start_installation | -| 09_parse_main.sh | ~247 | parse_arguments, detect_installation_mode, create_standard_aliases, main | - -All modules kept under 500 lines. Loader: `cyberpanel.sh`. Backup: `cyberpanel_install_monolithic.sh`. - -## install/venvsetup_modules/ -| Module | Content | -|--------|---------| -| 01_vars_install_required.sh | Vars, safe_pip_install, license_validation, special_change, system_tweak, install_required | -| 02_memcached_main.sh | memcached_installation, redis_installation, check_provider, check_*, interactive_*, main_install | -| 03_main_run_pip.sh | main_install_run, pip_virtualenv | -| 04_after_install.sh | after_install | -| 05_argument_main.sh | argument_mode, main flow (check_OS, install_required, pip_virtualenv, system_tweak, main_install) | - -Loader: `install/venvsetup.sh`. Backup: `install/venvsetup_monolithic.sh`. Refactor: `main_install` calls `main_install_run()` for size split. - -## install/ (Python and other files) -- **install/install.py**, **install/installCyberPanel.py**, etc. are unchanged; they are used by the shell installer and may be split in a future pass (e.g. into Python packages) if needed for the 500-line rule. diff --git a/to-do/INSTALL-UPGRADE-AUDIT.md b/to-do/INSTALL-UPGRADE-AUDIT.md deleted file mode 100644 index 19abd4aad..000000000 --- a/to-do/INSTALL-UPGRADE-AUDIT.md +++ /dev/null @@ -1,121 +0,0 @@ -# CyberPanel Install & Upgrade Setup – Audit (v2.5.5-dev) - -This document summarizes the install/upgrade flow, required local files, and verification that everything is in place. - ---- - -## 1. Install paths - -### 1.1 Modular install (`cyberpanel.sh` + `install_modules/`) - -- **Entry:** `cyberpanel.sh` -- **Branch for module download:** From `-b`/`--branch` or `CYBERPANEL_BRANCH`; default `stable`. -- **Required local dir:** `install_modules/` with: - - `00_common.sh`, `01_verify_deps.sh`, `02_install_core.sh`, `03_install_direct.sh`, `04_fixes_status.sh`, `05_menus_main.sh`, `06_menus_update.sh`, `07_menus_advanced.sh`, `08_actions.sh`, `09_parse_main.sh` -- **Flow:** Sources all 10 modules, then calls `main "$@"`. -- **Status:** All 10 files present in repo. - -### 1.2 Simplified install (`install.sh`) - -- **Entry:** `install.sh` (sh) -- **Purpose:** Disk check, OS detection, then typically invokes full installer (e.g. `cyberpanel.sh` or monolithic). -- **Status:** Present; branch default `v2.5.5-dev`. - -### 1.3 Monolithic install (`cyberpanel_install_monolithic.sh`) - -- **Entry:** `cyberpanel_install_monolithic.sh` -- **Uses:** `install/install.py` (and `install/install_utils.py`). Requires `install/install.py` on disk. -- **Status:** `install/install.py` and `install/install_utils.py` present. - -### 1.4 Install Python entry (`install/install.py`) - -- **Used by:** Modular and monolithic install flows. -- **Requires:** `/root/.my.cnf` (created by install), `_ensure_mariadb_client_no_ssl()` for local MariaDB (writes `cyberpanel-client.cnf`, Debian `99-cyberpanel-client.cnf`). -- **Status:** MariaDB client no-SSL logic present; required files created at runtime. - ---- - -## 2. Upgrade paths - -### 2.1 Modular upgrade (`cyberpanel_upgrade.sh` + `upgrade_modules/`) - -- **Entry:** `cyberpanel_upgrade.sh` -- **Branch for module download:** From `-b`/`--branch`; default `stable` when downloading; when run from repo uses local `upgrade_modules/`. -- **Required local dir:** `upgrade_modules/` with: - - `00_common.sh`, `01_variables.sh`, `02_checks.sh`, `03_mariadb.sh`, `04_git_url.sh`, `05_repository.sh`, `06_components.sh`, `07_branch_input.sh`, `08_main_upgrade.sh`, `09_sync.sh`, `10_post_tweak.sh`, `11_display_final.sh` -- **Flow:** - 1. `Set_Default_Variables` → clears logs, sets `Branch_Name` (from cyberpanel.net unless overridden), `cd /root/cyberpanel_upgrade_tmp` - 2. `Check_Root`, `Check_Server_IP`, `Check_OS`, `Check_Provider`, `Check_Argument` → can set `Branch_Name` (`-b`/`--branch`), `Git_User_Override` (`-r`/`--repo`), MariaDB version, backup flags - 3. Optionally `Pre_Upgrade_Branch_Input` - 4. MariaDB version prompt if not set via args - 5. `Pre_Upgrade_Setup_Git_URL` → sets `Git_Content_URL`, `Git_Clone_URL` (default `master3395`, or CN `qtwrk`) - 6. `Pre_Upgrade_Setup_Repository` → OS-specific repos + MariaDB install/upgrade + `Ensure_MariaDB_Client_No_SSL` - 7. `Pre_Upgrade_Setup_Git_URL` (see 04) - 8. `Pre_Upgrade_Required_Components` → downloads `requirments.txt`/`requirments-old.txt`, `plogical/upgrade.py` into `/root/cyberpanel_upgrade_tmp`, venv/pip, recovery - 9. `Main_Upgrade` → ensures `ols_binaries_config.py`, **cd to dir containing upgrade.py**, runs `$CP_PYTHON upgrade.py $Branch_Name` (fallback venv if needed) - 10. `Sync_CyberCP_To_Latest` → git sync in `/usr/local/CyberCP` - 11. `Post_Upgrade_System_Tweak` → watchdog, requirments cleanup, lsphp fix, etc. - 12. `Post_Install_Display_Final_Info` -- **Status:** All 12 modules present. `08_main_upgrade.sh` now explicitly cd’s to directory containing `upgrade.py` before running it. - -### 2.2 Remote files (modular upgrade) - -Downloaded from `Git_Content_URL`/`Branch_Name` (e.g. `https://raw.githubusercontent.com/master3395/cyberpanel/v2.5.5-dev/`): - -| Remote path | Used by | In repo? | -|-------------|---------|----------| -| `requirments.txt` | 06_components, 08 fallback, monolithic | Yes (root) | -| `requirments-old.txt` | 06 (fallback), 08 fallback, monolithic | Yes (root) | -| `install/ols_binaries_config.py` | 08 (ensure before upgrade.py) | Yes | -| `plogical/upgrade.py` | 06 (downloaded to `/root/cyberpanel_upgrade_tmp`) | Yes | -| `CPScripts/watchdog.sh` | 10_post_tweak | Yes | -| `install/litespeed/httpd_config.xml` | 06 (sed in upgrade.py for CN) | Yes | - -All required remote files exist in the repo. - -### 2.3 Monolithic upgrade (`cyberpanel_upgrade_monolithic.sh`) - -- **Entry:** `cyberpanel_upgrade_monolithic.sh` -- **Flow:** Inlines logic equivalent to variables, checks, repository (including MariaDB client no-SSL), download requirements, upgrade.py run (with cd to dir containing upgrade.py), sync, post-tweak, display. -- **Status:** Same remote URLs; repo contains all referenced files. MariaDB client no-SSL block added at end of repository section. - ---- - -## 3. Cross-cutting checks - -### 3.1 Branch and Git user - -- **Default Git user:** `master3395` (04_git_url.sh; 08_main_upgrade exports `CYBERPANEL_GIT_USER`). -- **Branch:** From `-b`/`--branch` or from cyberpanel.net version in `Set_Default_Variables`; v2.5.5-dev use `-b v2.5.5-dev`. - -### 3.2 MariaDB client no-SSL (ERROR 2026) - -- **Install:** `install/install.py` → `/root/.my.cnf` + `_ensure_mariadb_client_no_ssl()` (RHEL + Debian). -- **Upgrade modular:** `03_mariadb.sh` defines `Ensure_MariaDB_Client_No_SSL`; `05_repository.sh` calls it at end of `Pre_Upgrade_Setup_Repository`; `03` also calls it at end of `Pre_Upgrade_CentOS7_MySQL`. -- **Upgrade monolithic:** Inline block at end of `Pre_Upgrade_Setup_Repository`. -- See **to-do/MARIADB-CLIENT-NO-SSL-INSTALL-UPGRADE.md** for full coverage. - -### 3.3 upgrade.py working directory - -- **Modular:** `08_main_upgrade.sh` now cd’s to `/root/cyberpanel_upgrade_tmp` (or `/usr/local/CyberCP` if upgrade.py there) before running `upgrade.py`, so the script is always run from the directory that contains it. -- **Monolithic:** Same idea (cd to dir containing upgrade.py before running). - ---- - -## 4. Summary - -| Item | Status | -|------|--------| -| install_modules/ (10 files) | Present | -| upgrade_modules/ (12 files) | Present | -| install/install.py, install_utils.py | Present | -| install/ols_binaries_config.py | Present | -| plogical/upgrade.py | Present | -| requirments.txt, requirments-old.txt | Present (root) | -| CPScripts/watchdog.sh | Present | -| install/litespeed/httpd_config.xml | Present | -| Git default master3395, Branch from -b | Correct | -| MariaDB client no-SSL (install + upgrade) | Applied in all paths | -| upgrade.py run from correct cwd (modular) | Fixed (cd before run) | - -**Conclusion:** Install and upgrade setup have all required local files. Modular upgrade now explicitly changes to the directory containing `upgrade.py` before running it. MariaDB client no-SSL is applied on install and on every upgrade path (modular and monolithic). diff --git a/to-do/MARIADB-CLIENT-NO-SSL-INSTALL-UPGRADE.md b/to-do/MARIADB-CLIENT-NO-SSL-INSTALL-UPGRADE.md deleted file mode 100644 index aaaf074d3..000000000 --- a/to-do/MARIADB-CLIENT-NO-SSL-INSTALL-UPGRADE.md +++ /dev/null @@ -1,51 +0,0 @@ -# MariaDB Client No-SSL (ERROR 2026 Fix) – Install and Upgrade Coverage - -This document summarizes where the MariaDB client “no SSL” configuration is applied so that **install** and **upgrade** both work when the server has `have_ssl=DISABLED` (avoids `ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it`). - -## What gets applied - -- **`[client]`** with **`ssl=0`** and **`skip-ssl`** in: - - `/etc/my.cnf.d/cyberpanel-client.cnf` (RHEL/AlmaLinux/CentOS) - - `/etc/mysql/mariadb.conf.d/99-cyberpanel-client.cnf` (Debian/Ubuntu, when that directory exists) - - Optionally appended to **`/etc/my.cnf`** if it has no `[client]` section - -## Install path - -| Location | What happens | -|----------|----------------| -| **install/install.py** | Writes `/root/.my.cnf` with `[client]` including `ssl=0` and `skip-ssl`. When `remotemysql == 'OFF'`, calls `_ensure_mariadb_client_no_ssl()` which creates `/etc/my.cnf.d/cyberpanel-client.cnf` (RHEL) and `/etc/mysql/mariadb.conf.d/99-cyberpanel-client.cnf` (Debian/Ubuntu). | - -So every **fresh install** (local MariaDB) gets the client no-SSL config. - -## Upgrade path (modular: `cyberpanel_upgrade.sh` + `upgrade_modules/`) - -| Module | What happens | -|--------|----------------| -| **03_mariadb.sh** | Defines **`Ensure_MariaDB_Client_No_SSL()`** (writes `cyberpanel-client.cnf`, optional `[client]` in `my.cnf`, and Debian `99-cyberpanel-client.cnf`). Called at end of **`Pre_Upgrade_CentOS7_MySQL`** when that path runs. | -| **05_repository.sh** | After all OS-specific repository and MariaDB install/upgrade logic (CentOS, AlmaLinux 9, Ubuntu/Debian, openEuler), calls **`Ensure_MariaDB_Client_No_SSL`** once. Every RHEL/DNF path also writes `cyberpanel-client.cnf` and optional `my.cnf` [client] inline; Ubuntu/Debian get the fix via this single call. | - -So every **modular upgrade** run applies the client no-SSL config on all supported OSes. - -## Upgrade path (monolithic: `cyberpanel_upgrade_monolithic.sh`) - -| Location | What happens | -|----------|----------------| -| **Pre_Upgrade_Setup_Repository** | Each RHEL/DNF branch already creates `/etc/my.cnf.d/cyberpanel-client.cnf` with `ssl=0` and `skip-ssl` and optionally appends `[client]` to `/etc/my.cnf`. At the **end** of the same function (after Ubuntu and openEuler blocks), a single block runs that: creates `cyberpanel-client.cnf`, appends `[client]` to `my.cnf` if missing, and creates `/etc/mysql/mariadb.conf.d/99-cyberpanel-client.cnf` on Debian/Ubuntu. | - -So every **monolithic upgrade** run also ensures the client no-SSL config on all paths. - -## Verification - -After install or upgrade: - -```bash -mariadb -e "SELECT 1" -# or -mariadb -e "SELECT @@version;" -``` - -If these work without `ERROR 2026`, the client no-SSL configuration is in effect. - -## Manual fix (if needed) - -See **to-do/fix-phpmyadmin-mariadb-version-on-server.md** for a manual one-off fix on a single server. diff --git a/to-do/PHPMYADMIN-404-AFTER-UPGRADE.md b/to-do/PHPMYADMIN-404-AFTER-UPGRADE.md deleted file mode 100644 index f334cc4fd..000000000 --- a/to-do/PHPMYADMIN-404-AFTER-UPGRADE.md +++ /dev/null @@ -1,49 +0,0 @@ -# phpMyAdmin 404 After Upgrade - -## Symptom - -After upgrading with: - -```bash -sh <(curl -s https://raw.githubusercontent.com/usmannasir/cyberpanel/v2.5.5-dev/preUpgrade.sh ...) -b v2.5.5-dev --mariadb-version 11.8 -``` - -opening **https://YOUR_IP:2087/phpmyadmin/** (or the panel’s “phpMyAdmin” link) returns **404 Not Found**. - -## Cause - -The upgrade step that installs phpMyAdmin (`download_install_phpmyadmin`) can fail without stopping the upgrade (e.g. network, or extract/mv path mismatch). The panel then has no `/usr/local/CyberCP/public/phpmyadmin/` directory, so the web server returns 404 for `/phpmyadmin/`. - -## Fix on the server - -Run the fix script **as root** on the panel server (e.g. 207.180.193.210): - -```bash -# From the repo (if you have it on the server): -cd /home/cyberpanel-repo -sudo bash fix-phpmyadmin.sh - -# Or one-liner (download and run from repo): -sudo bash -c 'curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/v2.5.5-dev/fix-phpmyadmin.sh | bash' -``` - -Or run the same logic via Python: - -```bash -sudo /usr/local/CyberCP/bin/python -c " -import sys; sys.path.insert(0, '/usr/local/CyberCP') -import os; os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'CyberCP.settings') -from plogical.upgrade import Upgrade -Upgrade.download_install_phpmyadmin() -" -sudo chown -R lscpd:lscpd /usr/local/CyberCP/public/phpmyadmin -``` - -Then reload **https://YOUR_IP:2087/phpmyadmin/** (or use Databases → phpMyAdmin in the panel). - -## Repo changes - -- **fix-phpmyadmin.sh** – Script to install/fix phpMyAdmin on the server (run as root). -- **plogical/upgrade.py** – `download_install_phpmyadmin()`: - - Resolves extracted folder with `glob` (handles `phpMyAdmin-*-all-languages` or `phpMyAdmin-*`). - - Verifies that `public/phpmyadmin` exists after install and raises if missing so the upgrade step is not silent. diff --git a/to-do/PHPMYADMIN-MARIADB-VERSION-MISMATCH.md b/to-do/PHPMYADMIN-MARIADB-VERSION-MISMATCH.md deleted file mode 100644 index 9b5962cbf..000000000 --- a/to-do/PHPMYADMIN-MARIADB-VERSION-MISMATCH.md +++ /dev/null @@ -1,44 +0,0 @@ -# phpMyAdmin vs CLI MariaDB Version Mismatch - -## Why SSH / `mariadb -V` Shows 11.8 While phpMyAdmin Shows 10.11 - -Two main causes: - -### 1. **Different connection target (most common)** - -- **CLI** (`mariadb -V`, `mariadb -e "SELECT @@version;"`) uses the default connection: usually the **main** MariaDB instance (e.g. port 3306 or default socket). -- **phpMyAdmin** previously used host **`localhost`** (hardcoded). With `localhost`, the PHP MySQL client connects via the **default Unix socket**, not necessarily the same as the main instance. -- If you have (or had) **two** MariaDB instances (e.g. main on 3306 and a second on 3307 from `mysqld_multi`, or an old 10.11 still running), the CLI can hit 11.8 while PHP’s default socket pointed at the 10.11 instance. - -### 2. **Client vs server version** - -- `mariadb -V` prints the **client** version (e.g. 11.8). The upgrade script banner also used that for “Database (MariaDB): 11.8”. -- The **server** version is what phpMyAdmin shows. If the server was still 10.11 (e.g. wrong service restarted or second instance), phpMyAdmin correctly showed 10.11. - -## Fix applied in code - -- The panel now passes **host** (and port) from `/etc/cyberpanel/mysqlPassword` into the phpMyAdmin signon form. -- When the stored host is `localhost`, we send **`127.0.0.1`** so phpMyAdmin connects via **TCP to port 3306** (the main instance), not the default socket. -- So after deploy, phpMyAdmin should show the same MariaDB version as the CLI (the main 11.8 server). - -## Verification on the server - -Run as root: - -```bash -# Server version (what phpMyAdmin should show after fix) -mariadb -e "SELECT @@version;" - -# Listeners (only one MariaDB should be on 3306) -ss -tlnp | grep 3306 - -# Processes (check for duplicate mysqld/mariadbd) -ps aux | grep -E 'mariadb|mysqld' -``` - -If `SELECT @@version` shows 11.8 but phpMyAdmin still showed 10.11 before the fix, it was almost certainly a different connection (socket vs 127.0.0.1:3306 or a second instance). After the code change and a fresh phpMyAdmin login, it should report 11.8. - -## If two instances exist - -- Stop the old 10.11 instance (e.g. `mysqld_multi stop 1` if using `mysqld1` on 3307, or disable its service). -- Ensure only the 11.8 service (e.g. `mariadb.service`) is running and listening on 3306. diff --git a/to-do/PLUGINS-INSTALLED-GRID-VERIFY.md b/to-do/PLUGINS-INSTALLED-GRID-VERIFY.md deleted file mode 100644 index 4a27ec166..000000000 --- a/to-do/PLUGINS-INSTALLED-GRID-VERIFY.md +++ /dev/null @@ -1,45 +0,0 @@ -# Plugins Installed Grid – Install and Verify - -## How install works - -1. **Grid "Install" button** - - Tries **local install** first: plugin must exist under `/home/cyberpanel/plugins/` or `/home/cyberpanel-plugins/` (with `meta.xml`). - - If the API returns **404** or **"Plugin source not found"**, the UI automatically retries **store install** (download from GitHub `master3395/cyberpanel-plugins` and install). - -2. **Store install** - - Used from the Store view or as fallback when local source is missing. - - Downloads the plugin from GitHub and runs the same installer (extract, pre_install, settings/URLs, inform CyberPanel, collectstatic, post_install). - -3. **"Installed" status** - - A plugin is considered installed if the **directory** exists: `/usr/local/CyberCP//`. - - If that directory exists but `meta.xml` is missing, the UI still shows "Installed". On load of `/plugins/installed`, the backend tries to restore `meta.xml` from source (if source exists). - -## Making sure all grid plugins install correctly - -- **Local source** - Put plugin folders (each with `meta.xml`) in: - - `/home/cyberpanel/plugins//`, or - - `/home/cyberpanel-plugins//` - Then use **Install** in the grid; local install will be used. - -- **No local source** - Click **Install** in the grid; if local source is not found, the UI falls back to **store install** (GitHub). Ensure the plugin exists in `master3395/cyberpanel-plugins` (main branch). - -- **Already installed but broken** - If a plugin directory exists under `/usr/local/CyberCP/` but `meta.xml` was missing, opening **Plugins → Installed** will try to copy `meta.xml` from source into the installed folder so version/update checks work. - -## Quick checks on the server - -```bash -# Installed plugin dirs -ls -la /usr/local/CyberCP/ | grep -E '^d' - -# Local source (grid uses these for local install) -ls -la /home/cyberpanel/plugins/ 2>/dev/null || true -ls -la /home/cyberpanel-plugins/ 2>/dev/null || true - -# Ensure meta.xml exists for an installed plugin (e.g. premiumPlugin) -ls -la /usr/local/CyberCP/premiumPlugin/meta.xml -``` - -After code changes, restart Gunicorn (or the CyberPanel app server) so the updated pluginHolder views and JS are used. diff --git a/to-do/PLUGINS-TEMPLATE-DEPLOY.md b/to-do/PLUGINS-TEMPLATE-DEPLOY.md deleted file mode 100644 index ea6e20cc8..000000000 --- a/to-do/PLUGINS-TEMPLATE-DEPLOY.md +++ /dev/null @@ -1,44 +0,0 @@ -# Deploy and verify latest Plugins template on server - -## 1. Check if server has the latest template - -On the server (207.180.193.210), run: - -```bash -grep -q "installedFilterBtnAll" /usr/local/CyberCP/pluginHolder/templates/pluginHolder/plugins.html && echo "LATEST: Yes (Show / Installed only / Active only present)" || echo "LATEST: No (run deploy below)" -``` - -## 2. Deploy latest template to the server - -**Option A – Run on the server (repo already on server)** - -If the cyberpanel repo is on the same machine (e.g. at `/home/cyberpanel-repo`): - -```bash -sudo bash /home/cyberpanel-repo/pluginHolder/deploy-plugins-template.sh -``` - -**Option B – Copy from this machine to the server** - -From your dev machine (where the repo lives): - -```bash -scp /home/cyberpanel-repo/pluginHolder/templates/pluginHolder/plugins.html root@207.180.193.210:/usr/local/CyberCP/pluginHolder/templates/pluginHolder/plugins.html -ssh root@207.180.193.210 "systemctl restart lscpd" -``` - -Then on the server, verify: - -```bash -ssh root@207.180.193.210 'grep -q "installedFilterBtnAll" /usr/local/CyberCP/pluginHolder/templates/pluginHolder/plugins.html && echo "LATEST: Yes" || echo "LATEST: No"' -``` - -## 3. Verify in the browser - -1. Open: https://207.180.193.210:2087/plugins/installed#grid -2. Ensure **Grid View** is selected. -3. You should see two rows under the view toggle: - - **Show:** [All] [Installed only] [Active only] - - **Sort by:** [Name A–Å] [Type] [Date (newest)] - -If you see **Show:** and the three filter buttons, you are on the latest template. diff --git a/to-do/RAINLOOP-TO-SNAPPYMAIL-RENAME.md b/to-do/RAINLOOP-TO-SNAPPYMAIL-RENAME.md deleted file mode 100644 index d25676683..000000000 --- a/to-do/RAINLOOP-TO-SNAPPYMAIL-RENAME.md +++ /dev/null @@ -1,41 +0,0 @@ -# RainLoop → SnappyMail rename - -## Summary -RainLoop has been replaced by SnappyMail. All **operational** paths and the install template folder now use SnappyMail. References to "rainloop" remain only where we **migrate from** old installs (2.4.4 → 2.5.5). - -## Changes made - -### Repo folder -- **`install/rainloop/`** renamed to **`install/snappymail/`** -- Template file still `cyberpanel.net.ini` (SnappyMail uses same format). - -### Code updated to SnappyMail paths -- **plogical/mailUtilities.py** — Template path `/usr/local/CyberCP/install/snappymail/cyberpanel.net.ini`; all data paths `/usr/local/lscp/cyberpanel/snappymail/...`. -- **install/install.py** — chown and mkdir use `snappymail`; commented blocks updated for consistency. -- **plogical/acl.py** — `chown ... /usr/local/lscp/cyberpanel/snappymail`. -- **plogical/upgrade.py** — Operational chown and backup path use snappymail. - -### Left as-is (intentional) -- **Migration logic** in `plogical/upgrade.py`, `upgrade_modules/10_post_tweak.sh`, and `cyberpanel_upgrade_monolithic.sh` still uses the **source** path `/usr/local/lscp/cyberpanel/rainloop/data` when upgrading from 2.4.4: they check for old rainloop data and rsync it to `/usr/local/lscp/cyberpanel/snappymail/data/`. That "rainloop" path must stay so existing servers upgrading from RainLoop get their data migrated. - -## Upgrade to 2.5.5-dev: migrate ALL links to SnappyMail - -On upgrade, the following ensure every RainLoop reference becomes SnappyMail: - -1. **Data migration** (existing): rsync from `/usr/local/lscp/cyberpanel/rainloop/data` to `.../snappymail/data`, and update `include.php` paths. - -2. **Replace all rainloop path/URL in migrated data**: After rsync, every config file under `snappymail/data` (`.ini`, `.json`, `.php`, `.cfg`) is scanned and any occurrence of: - - `/usr/local/lscp/cyberpanel/rainloop/data` → `.../snappymail/data` - - `/rainloop/` → `/snappymail/` - - `rainloop/data` → `snappymail/data` - is replaced. So stored links and paths in SnappyMail configs point to SnappyMail. - -3. **HTTP redirect /rainloop → /snappymail**: In `/usr/local/CyberCP/public/.htaccess` a 301 redirect is added (or ensured once) so that: - - `/rainloop`, `/rainloop/`, `/rainloop/anything` → `/snappymail/...` - Old bookmarks and shared links keep working. - -Implemented in: `plogical/upgrade.py` (`migrateRainloopToSnappymail`), `upgrade_modules/10_post_tweak.sh`, `cyberpanel_upgrade_monolithic.sh`. - -## Result -- New installs and day-to-day operations use only SnappyMail paths. -- Upgrades from versions that had RainLoop: data migrated, all config links updated to snappymail, and /rainloop URLs redirect to /snappymail. diff --git a/to-do/REMOVED-UNUSED-INSTALL-FOLDERS.md b/to-do/REMOVED-UNUSED-INSTALL-FOLDERS.md deleted file mode 100644 index 468491b5e..000000000 --- a/to-do/REMOVED-UNUSED-INSTALL-FOLDERS.md +++ /dev/null @@ -1,21 +0,0 @@ -# Removed Unused install/ Folders - -## Summary -Unused config folders under `install/` were removed; only the folders actually referenced by the codebase remain. - -## Removed - -### install/email-configs -- **Reason:** Never referenced. All code uses `install/email-configs-one` (e.g. `install/install.py`, `plogical/mailUtilities.py`, `mailServer/mailserverManager.py`). -- **Removed:** 2025-02-15. - -### install/php-configs -- **Reason:** Never referenced. Code uses `install/phpconfigs` (no hyphen) only: - - `plogical/installUtilities.py`: `shutil.copytree("phpconfigs", ...)` and `include phpconfigs/php*.conf` - - `install/litespeed/conf/httpd_config.conf` and `serverStatus/litespeed/conf/httpd_config.conf`: `include phpconfigs/php53.conf` etc. -- **Note:** `php-configs` contained `php.ini` and `www.conf` (different purpose); `phpconfigs` contains `php53.conf` … `php80.conf` (LiteSpeed PHP version includes). -- **Removed:** 2025-02-15. - -## Still in use -- `install/email-configs-one/` — mail configs used by install and mail utilities. -- `install/phpconfigs/` — LiteSpeed PHP version include configs used by install and httpd_config. diff --git a/to-do/SUPPORTED-OS-INSTALL-UPGRADE.md b/to-do/SUPPORTED-OS-INSTALL-UPGRADE.md deleted file mode 100644 index 30f13d349..000000000 --- a/to-do/SUPPORTED-OS-INSTALL-UPGRADE.md +++ /dev/null @@ -1,37 +0,0 @@ -# Install/Upgrade Support Matrix (v2.5.5-dev) - -This document summarizes how install and upgrade **detect and handle** each OS in the support table. It does **not** guarantee that every combination has been tested; it reflects what the code paths are. - -## Summary - -| OS family | Detection | Install/upgrade path | Notes | -|-----------|-----------|----------------------|--------| -| **AlmaLinux 10, 9, 8** | `AlmaLinux-8/9/10` in `/etc/os-release` | 9/10 → `AlmaLinux9` (dnf, repo fixes, venv). 8 → `CentOS` + version 8. | Explicit branches for 9/10 (EPEL, MariaDB, python3-venv). | -| **CentOS 7** | `CentOS Linux 7` in os-release | `CentOS` + version 7. | Legacy; EOL. Uses yum, requirments-old.txt. | -| **CloudLinux 9, 8** | `CloudLinux 7/8/9` in os-release | Normalized to `CentOS` + version. Same as RHEL family. | Version from VERSION_ID (e.g. 8 → 8, 9 → 9). | -| **Debian 13, 12, 11** | `Debian GNU/Linux 11/12/13` in os-release | Treated as **Ubuntu** (`Server_OS=Ubuntu`). Version 11/12/13 from VERSION_ID. | Uses **requirments-old.txt** (not requirments.txt). No Debian-specific package blocks; gets generic apt install. install_utils has Debian 13 package mappings. | -| **RHEL 9, 8** | `Red Hat Enterprise Linux` in os-release | Normalized to `CentOS` + version 8 or 9. | Same repo/package logic as CentOS 8/9. RHEL repo names differ; AlmaLinux-specific repo fixes do not run for RHEL. | -| **RockyLinux 9, 8** | `Rocky Linux` in os-release | Normalized to `CentOS`; version 8 or 9. | Same as CentOS 8/9 (EPEL, MariaDB, venv for 9/10). | -| **Ubuntu 24.04, 22.04, 20.04** | `Ubuntu 24.04` etc. in os-release | Explicit branches for 22/24 (packages, python3-venv). 20 → specific fixes. 18 → minimal. | 24.04: externally-managed-environment handled. Uses **requirments.txt** for 22 and 24. | - -## Do we *know* it works on all of them? - -- **Code coverage:** Detection and branching exist for all listed OSes. AlmaLinux 8/9/10, Ubuntu 18/20/22/24, Debian 11/12/13, CentOS 7/8/9, Rocky, RHEL, CloudLinux, and openEuler have explicit or normalized paths. -- **No automated proof:** There is no CI in this repo that runs install or upgrade on each OS. “Works” is based on: - - Manual and community testing - - Code review of detection and branches -- **RHEL:** Uses the same code path as CentOS (RedHat → CentOS). RHEL 9 uses different repo IDs than AlmaLinux; if repo issues appear on RHEL 9, RHEL-specific repo handling may be needed. -- **Debian 11/12/13:** Share the “Ubuntu” path and use **requirments-old.txt**. install_utils has Debian 13 (Trixie) package mappings. No Debian-version-specific blocks in the upgrade script. -- **CentOS 7:** Marked legacy/EOL; still in the script with yum and old requirements. - -## Recommendations - -1. **Staging:** Test install and upgrade on a non-production VM for your chosen OS before production. -2. **CI (optional):** Add a test matrix (e.g. GitHub Actions or other CI) that runs install and/or upgrade on a subset of OSes (e.g. AlmaLinux 9, Ubuntu 22.04, Debian 12) to catch regressions. -3. **Docs:** Keep this file (or a short “Supported platforms” section) in sync with the script when adding or dropping OS versions. - -## Where to look in the repo - -- **Upgrade OS detection:** `cyberpanel_upgrade.sh` (lines ~160–187), `Server_OS_Version` (~187), and branches for `CentOS`/`AlmaLinux9`/`Ubuntu`/`openEuler`. -- **Install OS detection:** `install/install.py` (`preFlightsChecks.detect_os`, `get_distro`), and `install/install_utils.py` (Debian/Ubuntu version and package helpers). -- **Requirements choice:** `cyberpanel_upgrade.sh` `Download_Requirement()`: uses `requirments.txt` for version 22, 24, 9, 10; else `requirments-old.txt`. diff --git a/to-do/UPGRADE-MODULES-DESIGN.md b/to-do/UPGRADE-MODULES-DESIGN.md deleted file mode 100644 index 6ae78cc17..000000000 --- a/to-do/UPGRADE-MODULES-DESIGN.md +++ /dev/null @@ -1,48 +0,0 @@ -# CyberPanel Upgrade Script - Modular Layout for Debugging - -## Goal - -Split `cyberpanel_upgrade.sh` into modules under `upgrade_modules/` so each file is under 500 lines and easier to debug. - -## Directory Layout - -- `upgrade_modules/00_common.sh` - Debug_Log, Debug_Log2, Branch_Check, Check_Return, Regenerate_Cert, Retry_Command (DONE) -- `upgrade_modules/01_variables.sh` - Set_Default_Variables (DONE) -- `upgrade_modules/02_checks.sh` - Check_Root, Check_Server_IP, Check_OS, Check_Provider, Check_Argument -- `upgrade_modules/03_mariadb.sh` - Pre_Upgrade_CentOS7_MySQL, Maybe_Backup_MariaDB_Before_Upgrade, Backup_MariaDB_Before_Upgrade, Migrate_MariaDB_To_UTF8 -- `upgrade_modules/04_git_url.sh` - Pre_Upgrade_Setup_Git_URL -- `upgrade_modules/05_repository.sh` - Pre_Upgrade_Setup_Repository (~490 lines) -- `upgrade_modules/06_components.sh` - Download_Requirement, Pre_Upgrade_Required_Components -- `upgrade_modules/07_branch_input.sh` - Pre_Upgrade_Branch_Input -- `upgrade_modules/08_main_upgrade.sh` - Main_Upgrade -- `upgrade_modules/09_sync.sh` - Sync_CyberCP_To_Latest -- `upgrade_modules/10_post_tweak.sh` - Post_Upgrade_System_Tweak -- `upgrade_modules/11_display_final.sh` - Post_Install_Display_Final_Info, _br, _bl, _b - -## Line Ranges in Current Script - -- 00_common: 99-106, 237-263, 264-337 -- 01_variables: 27-98 -- 02_checks: 107-148, 149-206, 207-236, 352-399 -- 03_mariadb: 425-520 -- 04_git_url: 400-424 -- 05_repository: 521-1011 -- 06_components: 1012-1298 -- 07_branch_input: 1299-1311 -- 08_main_upgrade: 1312-1649 -- 09_sync: 1650-1688 -- 10_post_tweak: 1691-2023 -- 11_display_final: 2024-2118 - -## Main Script After Refactor - -1. Root check, Sudo_Test -2. If upgrade_modules/ exists: source each 00-11; else (one-liner) download modules from GitHub by branch and source -3. Set_Default_Variables, Check_Root, Check_Server_IP, Check_OS, Check_Provider, Check_Argument -4. Branch and MariaDB prompts -5. Pre_Upgrade_Setup_Repository, Pre_Upgrade_Setup_Git_URL, Pre_Upgrade_Required_Components -6. Main_Upgrade, Sync_CyberCP_To_Latest, Post_Upgrade_System_Tweak, Post_Install_Display_Final_Info - -## Status - -Done: 00_common.sh, 01_variables.sh. Remaining: create 02-11 and refactor main script to loader. diff --git a/to-do/WHITELIST-RM-UPGRADE_LOGS-SECURITY-ALERT.md b/to-do/WHITELIST-RM-UPGRADE_LOGS-SECURITY-ALERT.md deleted file mode 100644 index eeeb1606c..000000000 --- a/to-do/WHITELIST-RM-UPGRADE_LOGS-SECURITY-ALERT.md +++ /dev/null @@ -1,119 +0,0 @@ -# Security alert: `rm -rf /home/cyberpanel/upgrade_logs` - -## Is this an issue? - -**No.** This is **expected behavior** from the CyberPanel upgrade process, not a sign of compromise. - -## What’s going on - -- Your security product (e.g. OSSEC, Wazuh, or similar) flagged: - - **Command:** `sudo ... /bin/rm -rf /home/cyberpanel/upgrade_logs` - - **Context:** `PWD=/tmp/lscpd`, `USER=root` -- The CyberPanel daemon (**lscpd**) runs upgrade-related tasks. The upgrade logic uses `/home/cyberpanel/upgrade_logs` as the path for upgrade logs (see `plogical/upgrade.py`: `LogPathNew = '/home/cyberpanel/upgrade_logs'`). Cleaning that path (file or directory) before or after an upgrade is normal so the next run starts from a clean state. -- So this command is the **panel cleaning its own upgrade logs**, not an attacker. - -## Why does it look “suspicious”? - -- Security tools often treat **any** `rm -rf` as “dangerous” because it can delete a lot if misused. -- They also flag “system file access” or “writes/deletes under /home” to catch abuse. -- Here, the path is a **known, fixed** CyberPanel path and the process is **root from lscpd** (expected for the panel). So the alert is a **false positive** for “suspicious command” in this context. - -## Why “my own local files” look suspicious - -- “Local files” in the alert usually means “commands or file operations on this machine.” The product isn’t saying your personal files are malicious; it’s saying the **behavior** (e.g. `rm -rf` on a path under `/home`) matches a **rule** that can indicate compromise. -- In this case the “local” actor is **CyberPanel itself** (lscpd/upgrade), so the behavior is legitimate. - -## What you can do - -1. **Treat as expected:** No need to change passwords or hunt for backdoors solely because of this alert. -2. **Whitelist/tune the rule:** In your security product, add an exception or rule so that this specific command (or pattern) when run by root from the lscpd context is not reported, e.g.: - - Command pattern: `rm -rf /home/cyberpanel/upgrade_logs` - - Or: allow `rm -rf` for paths under `/home/cyberpanel/` when the process is lscpd/upgrade-related. -3. **Keep monitoring:** Continue to review real suspicious activity (e.g. unknown scripts, unexpected `rm -rf /` or `rm -rf /home/*`). - -## Summary - -- **Not a compromise** – normal CyberPanel upgrade cleanup. -- **“Suspicious”** only in the generic sense (rm -rf + /home); in context it’s the panel’s own operation. -- **Action:** Whitelist or tune the alert for this known-good case; no need to panic or “fix” the panel for this. - ---- - -## Whitelist / rule examples (stop this specific case being reported) - -Use the example that matches your product. After editing config, restart the agent/manager as indicated. - -### OSSEC - -Allow this command so it is not reported as suspicious. - -**1. Local rule to ignore this command** - -Create or edit a local rule file (e.g. `/var/ossec/etc/rules/local_rules.xml`) and add: - -```xml - - - 100002 - rm -rf /home/cyberpanel/upgrade_logs - Whitelist: CyberPanel upgrade log cleanup (expected) - -``` - -If your “suspicious command” rule has a different ``, replace `100002` with that rule’s ID (so this rule only applies when that one fires). If you’re not sure, you can use a broader override that matches the command and sets level 0: - -```xml - - rm -rf /home/cyberpanel/upgrade_logs - Whitelist: CyberPanel upgrade log cleanup - -``` - -Restart OSSEC: - -```bash -systemctl restart ossec -# or -/var/ossec/bin/ossec-control restart -``` - -**2. (Optional) Decoder to tag sudo rm** - -In `/var/ossec/etc/decoders/local_decoder.xml` you can add a decoder so the command is clearly identified; the rule above is enough to stop the alert. - -### Wazuh - -**1. Local rule to not alert on this command** - -Append to `/var/ossec/etc/rules/local_rules.xml` (Wazuh keeps OSSEC-style paths): - -```xml - - - - rm -rf /home/cyberpanel/upgrade_logs - Whitelist: CyberPanel upgrade_logs cleanup (lscpd/upgrade) - - -``` - -If the alert is from a different rule (e.g. “suspicious command” or “syscheck”), you may need to set `` to that rule’s ID so this rule only overrides that case. - -Restart Wazuh: - -```bash -systemctl restart wazuh-agent -# On manager: -systemctl restart wazuh-manager -``` - -**2. (Optional) Broader CyberPanel cleanup** - -To allow any `rm -rf` under `/home/cyberpanel/` when the process is from lscpd/upgrade, you’d need a rule that matches both the command pattern and (if available) the process or PWD. That’s product-specific; the rule above is the minimal, safe whitelist for the exact command you saw. - -### Other products (generic) - -- **Fail2ban / custom script:** If the alert is generated by a script that parses `auth.log` or `secure`, add an exception when the log line contains both `rm -rf` and `/home/cyberpanel/upgrade_logs`. -- **SIEM / cloud:** Add an exception or filter so that events with command `rm -rf /home/cyberpanel/upgrade_logs` and user `root` (and optionally process/source indicating lscpd) are not escalated. - -Once the whitelist is in place, future runs of that CyberPanel cleanup will no longer trigger this specific alert. diff --git a/to-do/fix-phpmyadmin-mariadb-version-on-server.md b/to-do/fix-phpmyadmin-mariadb-version-on-server.md deleted file mode 100644 index b679bb53e..000000000 --- a/to-do/fix-phpmyadmin-mariadb-version-on-server.md +++ /dev/null @@ -1,38 +0,0 @@ -# Fix phpMyAdmin Showing 10.11 When 11.8 Is Installed - -## 1. Fix CLI SSL error and see real server version - -Run as root on the server: - -```bash -# Allow mariadb client to connect without SSL (avoids ERROR 2026 when server has have_ssl=DISABLED) -mkdir -p /etc/my.cnf.d -printf '[client]\nssl=0\nskip-ssl\n' > /etc/my.cnf.d/cyberpanel-client.cnf -# If client still requires SSL, add [client] to main my.cnf (only if not already present) -grep -q '^\[client\]' /etc/my.cnf 2>/dev/null || echo -e "\n[client]\nssl=0\nskip-ssl" >> /etc/my.cnf - -# Now this should work and show the *actual* server version on 3306 -mariadb -e "SELECT @@version;" -``` - -- If it shows **11.8.x**: the server is 11.8; phpMyAdmin should show 11.8 after you **log out, clear cookies for :2087, then log in again via CyberPanel → Databases → phpMyAdmin**. -- If it still shows **10.11.x**: the process on 3306 is still 10.11. Force the 11.8 service to take over: - -```bash -systemctl stop mariadb -sleep 3 -systemctl start mariadb -mariadb -e "SELECT @@version;" -``` - -If it still shows 10.11, check: - -```bash -rpm -q MariaDB-server -ss -tlnp | grep 3306 -systemctl status mariadb -``` - -## 2. phpMyAdmin config (already correct on your server) - -Your `config.inc.php` already has `host = '127.0.0.1'` and `port = '3306'`. Once the server on 3306 is 11.8 and you log in again via the panel, phpMyAdmin will show 11.8.