Nemcio/CyberPanel
1
0
Fork 0
mirror of https://github.com/usmannasir/cyberpanel.git synced 2026-02-27 17:00:45 +01:00
Code Issues Packages Projects Releases Wiki Activity

Remove to-do folder

Browse Source
This commit is contained in:
master3395
2026-02-17 01:01:34 +01:00
parent adc2de08b8
commit bb8454d3f0
18 changed files with 0 additions and 1013 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
to-do/CYBERCP-GIT-PULL-CONFLICTS-V2.5.5-DEV.md
View File

@@ -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).

26
to-do/DEPLOY-BEFORE-PUSH-V2.5.5-DEV.md
View File

@@ -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 <master3395@users.noreply.github.com>" && git push origin v2.5.5-dev
```

53
to-do/DEPLOY-MYSQL-MANAGER-TO-SERVER.md
View File

@@ -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.

64
to-do/FIREWALL-LOAD-CHANGES.md
View File

@@ -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.

113
to-do/HTTP-500-AFTER-GIT-SYNC-RECOVERY.md
View File

@@ -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`.

36
to-do/INSTALL-MODULES-DESIGN.md
View File

@@ -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.

121
to-do/INSTALL-UPGRADE-AUDIT.md
View File

@@ -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).

51
to-do/MARIADB-CLIENT-NO-SSL-INSTALL-UPGRADE.md
View File

@@ -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.

49
to-do/PHPMYADMIN-404-AFTER-UPGRADE.md
View File

@@ -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.

44
to-do/PHPMYADMIN-MARIADB-VERSION-MISMATCH.md
View File

@@ -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.

45
to-do/PLUGINS-INSTALLED-GRID-VERIFY.md
View File

@@ -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/<plugin_name>/`.
- 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/<plugin_name>/`, or
- `/home/cyberpanel-plugins/<plugin_name>/`
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.

44
to-do/PLUGINS-TEMPLATE-DEPLOY.md
View File

@@ -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.

41
to-do/RAINLOOP-TO-SNAPPYMAIL-RENAME.md
View File

@@ -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.

21
to-do/REMOVED-UNUSED-INSTALL-FOLDERS.md
View File

@@ -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.

37
to-do/SUPPORTED-OS-INSTALL-UPGRADE.md
View File

@@ -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`.

48
to-do/UPGRADE-MODULES-DESIGN.md
View File

@@ -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.

119
to-do/WHITELIST-RM-UPGRADE_LOGS-SECURITY-ALERT.md
View File

@@ -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
<!-- Allow CyberPanel upgrade cleanup: rm -rf /home/cyberpanel/upgrade_logs -->
<rule id="100001" level="0">
<if_sid>100002</if_sid>
<match>rm -rf /home/cyberpanel/upgrade_logs</match>
<description>Whitelist: CyberPanel upgrade log cleanup (expected)</description>
</rule>
```
If your “suspicious command” rule has a different `<rule id>`, 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
<rule id="100001" level="0">
<match>rm -rf /home/cyberpanel/upgrade_logs</match>
<description>Whitelist: CyberPanel upgrade log cleanup</description>
</rule>
```
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
<!-- Whitelist CyberPanel upgrade cleanup -->
<group name="local,syscheck,">
<rule id="100001" level="0">
<match>rm -rf /home/cyberpanel/upgrade_logs</match>
<description>Whitelist: CyberPanel upgrade_logs cleanup (lscpd/upgrade)</description>
</rule>
</group>
```
If the alert is from a different rule (e.g. “suspicious command” or “syscheck”), you may need to set `<if_sid>` 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.

38
to-do/fix-phpmyadmin-mariadb-version-on-server.md
View File

@@ -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.