Nemcio/CyberPanel
1
0
Fork 0
mirror of https://github.com/usmannasir/cyberpanel.git synced 2026-05-07 07:15:53 +02:00
Code Issues Packages Projects Releases Wiki Activity

Remove to-do folder from repository

Browse Source
This commit is contained in:
master3395
2026-02-15 00:03:28 +01:00
parent a4385d55c2
commit 99f51a813b
19 changed files with 0 additions and 1376 deletions
Download Patch File Download Diff File Expand all files Collapse all files

120
to-do/AWS-CURSOR-REMOTE-SSH-SETUP.md
View File

@@ -1,120 +0,0 @@
# AWS EC2 + Cursor Remote-SSH – Full Setup Guide
Use this guide to get **aws-server** (3.144.171.128) working with Cursor Remote-SSH.
Do the steps in order. Everything is copy-paste ready.
---
## 1. Windows SSH config
**File:** `C:\Users\kimsk\.ssh\config`
- Open the file in Notepad or Cursor.
- Find the `Host aws-server` block and replace it entirely with the block below (or add it if missing).
- Use **straight double quotes** `"`, not curly quotes. Path uses forward slashes to avoid issues.
**Exact block to use (port 22 – default):**
```
Host aws-server
HostName 3.144.171.128
User ec2-user
Port 22
IdentityFile "D:/OneDrive - v-man/Priv/VPS/Cyberpanel.pem"
```
- Save and close.
- If you later confirm SSH on the instance is on port 2222, change `Port 22` to `Port 2222` and add an inbound rule for 2222 in the Security Group (see step 3).
---
## 2. AWS Security Group – allow SSH (port 22)
1. **AWS Console** → **EC2** → **Instances**.
2. Select the instance whose **Public IPv4** is **3.144.171.128**.
3. Open the **Security** tab → click the **Security group** name (e.g. `sg-xxxxx`).
4. **Edit inbound rules** → **Add rule**:
- **Type:** SSH
- **Port:** 22
- **Source:** **My IP** (recommended) or **Anywhere-IPv4** (`0.0.0.0/0`) for testing only.
5. **Save rules**.
If you use port 2222 on the instance, add another rule: **Custom TCP**, port **2222**, source **My IP** (or **Anywhere-IPv4** for testing).
---
## 3. Start SSH on the instance (fix “Connection refused”)
You must run commands on the instance without using SSH from your PC. Use one of these.
### Option A: EC2 Instance Connect (simplest)
1. **EC2** → **Instances** → select the instance (3.144.171.128).
2. Click **Connect**.
3. Open the **EC2 Instance Connect** tab → **Connect** (browser shell).
In the browser terminal, run:
```bash
sudo systemctl status sshd
sudo systemctl start sshd
sudo systemctl enable sshd
sudo ss -tlnp | grep 22
```
You should see `sshd` listening on port 22. Then close the browser and try Cursor.
### Option B: Session Manager
1. **EC2** → **Instances** → select the instance → **Connect**.
2. Choose **Session Manager** → **Connect**.
3. Run the same commands as in Option A.
### Option C: SSH is on port 2222
If you know SSH was moved to 2222 on this instance:
1. In the Security Group, add an **inbound rule**: **Custom TCP**, port **2222**, source **My IP** (or **Anywhere-IPv4** for testing).
2. In your SSH config, set `Port 2222` for `aws-server` (see step 1).
3. Test (see step 4).
---
## 4. Test from Windows
Open **PowerShell** and run:
```powershell
ssh -i "D:/OneDrive - v-man/Priv/VPS/Cyberpanel.pem" -o ConnectTimeout=10 -o StrictHostKeyChecking=accept-new ec2-user@3.144.171.128
```
- If it asks for a host key, type `yes`.
- If you get a shell prompt, SSH works. Type `exit` to close.
- If you get **Connection refused**: SSH is not listening on 22 (or 2222); repeat step 3 (Instance Connect / Session Manager) and ensure `sshd` is running and listening on the port you use.
- If you get **Connection timed out**: Security Group is still blocking the port; recheck step 2 and that you edited the security group attached to this instance.
---
## 5. Connect from Cursor
1. In Cursor: **Ctrl+Shift+P** (or **Cmd+Shift+P** on Mac) → **Remote-SSH: Connect to Host**.
2. Choose **aws-server** (or type `aws-server`).
3. Wait for the remote window to open. Cursor AI (Chat, Composer) works in that window as usual.
---
## Checklist
- [ ] SSH config has the `aws-server` block with correct `IdentityFile` and `Port` (22 or 2222).
- [ ] Security Group has an inbound rule for the SSH port (22 or 2222) from My IP (or 0.0.0.0/0 for testing).
- [ ] `sshd` is running on the instance (started via Instance Connect or Session Manager).
- [ ] `ssh ... ec2-user@3.144.171.128` works in PowerShell.
- [ ] Cursor **Connect to Host** → **aws-server** succeeds.
---
## If it still fails
- **Connection refused** → Instance side: start/enable `sshd` and confirm it listens on the port you use (step 3).
- **Connection timed out** → Network: open that port in the instance’s Security Group (step 2).
- **Permission denied (publickey)** → Wrong key or user: confirm the .pem is the one for this instance and the user is `ec2-user` (Amazon Linux) or `ubuntu` (Ubuntu AMI).

57
to-do/EMAIL-LIMITS-DEPLOY-CHECKLIST.md
View File

@@ -1,57 +0,0 @@
# Email Limits Fix – Deploy Checklist
Use this after pulling the Email Limits fixes in this repo so that https://your-panel/email/EmailLimits works (controller registers, email list loads, configure section works).
## Files that are part of the fix
| File | Purpose |
|------|--------|
| `mailServer/mailserverManager.py` | Passes controller JS to template; allows getEmailsForDomain for emailForwarding |
| `mailServer/templates/mailServer/EmailLimits.html` | Inline controller in footer_scripts (no static file dependency) |
| `mailServer/static/mailServer/mailServer.js` | EmailLimitsNew controller + guard for `$scope.emails` |
| `mailServer/static/mailServer/emailLimitsController.js` | Standalone controller + PNotify check fix |
## Option A: Deploy script (recommended)
**Run from anywhere** (use the full path to the script so the shell can find it):
```bash
sudo bash /home/cyberpanel-repo/deploy-email-limits-fix.sh
```
Or from repo root:
```bash
cd /home/cyberpanel-repo && sudo bash deploy-email-limits-fix.sh
```
- Script auto-detects repo at `/home/cyberpanel-repo` if run from another directory.
- Default CyberPanel path: `/usr/local/CyberCP`.
- Override: `sudo bash /home/cyberpanel-repo/deploy-email-limits-fix.sh /path/to/repo /usr/local/CyberCP`.
- Skip restart: `sudo RESTART_LSCPD=0 bash /home/cyberpanel-repo/deploy-email-limits-fix.sh`.
## Option B: Manual copy + restart
On the server, from the repo root (e.g. `/home/cyberpanel-repo`):
```bash
CP_DIR=/usr/local/CyberCP
cp -f mailServer/mailserverManager.py "$CP_DIR/mailServer/"
cp -f mailServer/templates/mailServer/EmailLimits.html "$CP_DIR/mailServer/templates/mailServer/"
cp -f mailServer/static/mailServer/mailServer.js "$CP_DIR/mailServer/static/mailServer/"
cp -f mailServer/static/mailServer/emailLimitsController.js "$CP_DIR/mailServer/static/mailServer/"
sudo systemctl restart lscpd
```
## After deploy
1. Hard refresh the Email Limits page: **Ctrl+Shift+R** (or Cmd+Shift+R).
2. Open **Email Limits**, choose a **website**, then check that **email account** dropdown fills and **Configure Email Limits** appears and works.
## If it still fails
- Confirm the four files above are present under `$CP_DIR` and were updated (check timestamps).
- Check panel/Python logs and browser console for `[$controller:ctrlreg]` or JS errors.
- Ensure `lscpd` (or the process serving the panel) was restarted after copying.

108
to-do/EMAIL-LIMITS-LIVE-SERVER-CHECKLIST.md
View File

@@ -1,108 +0,0 @@
# Email Limits – Live Server Checklist (vs upstream v2.4.4)
## Upstream v2.4.4 behaviour
In [usmannasir/cyberpanel at v2.4.4](https://github.com/usmannasir/cyberpanel/tree/v2.4.4):
- **Template**: `mailServer/templates/mailServer/EmailLimits.html` exists and uses `ng-controller="EmailLimitsNew"` and `{$ … $}` bindings.
- **Routes**: `mailServer/urls.py` has `EmailLimits` and `SaveEmailLimitsNew`.
- **Controller**: The **`EmailLimitsNew` controller is not present** in `static/mailServer/mailServer.js`. Upstream `mailServer.js` ends at “List Emails” and has no `EmailLimitsNew` block.
So on a stock v2.4.4 install, the Email Limits page will show raw `{$ selectedEmail $}` and “Could not connect to server” because the Angular controller is never registered.
---
## How it is loaded in v2.4.4
1. **Base template** (`baseTemplate/templates/baseTemplate/index.html`) loads one script bundle:
- `{% static 'mailServer/mailServer.js' %}?v={{ CP_VERSION }}`
(in the “Additional Scripts” block at the bottom of the body.)
2. **Email Limits template** only provides content; it does **not** load any extra script in upstream. It expects `EmailLimitsNew` to come from `mailServer.js`, but that controller is missing in v2.4.4.
3. **Backend**: `mailServer/views.py` → `EmailLimits`, `SaveEmailLimitsNew`; `mailServer/mailserverManager.py` → `EmailLimits()`, `SaveEmailLimitsNew()`.
---
## Files that must be on the live server
Use the paths below relative to the CyberPanel app root (e.g. `/usr/local/CyberCP/` or your repo root). Django static files may be served from `STATIC_ROOT` after `collectstatic`; templates and Python files must be in the app directories.
### 1. Python / URLs / views (same as upstream + your tweaks)
| Path | Purpose |
|------|--------|
| `mailServer/urls.py` | Must include `EmailLimits` and `SaveEmailLimitsNew` routes. |
| `mailServer/views.py` | Must define `EmailLimits` and `SaveEmailLimitsNew` and call manager. |
| `mailServer/mailserverManager.py` | Must implement `EmailLimits()` and `SaveEmailLimitsNew()` and render `mailServer/EmailLimits.html` with `websiteList` and `status`. |
### 2. Template (must load the controller script)
| Path | Purpose |
|------|--------|
| `mailServer/templates/mailServer/EmailLimits.html` | Must extend `baseTemplate/index.html`, contain `ng-controller="EmailLimitsNew"`, and **include the script tag** that loads `emailLimitsController.js` at the top of `{% block content %}`. |
### 3. Base template (unchanged from upstream for Email Limits)
| Path | Purpose |
|------|--------|
| `baseTemplate/templates/baseTemplate/index.html` | Must load `{% static 'mailServer/mailServer.js' %}` in the same script block as other app JS (no `load_email_limits_controller` needed). |
### 4. Static files (at least one of the two options)
**Option A – Use main bundle (repo’s `mailServer.js` with controller)**
| Path | Purpose |
|------|--------|
| `static/mailServer/mailServer.js` | Must define `app` (e.g. `window.app` or `angular.module('CyberCP')`) at the top and register `app.controller('EmailLimitsNew', ...)`. |
| `mailServer/static/mailServer/mailServer.js` | Same as above if you use app static dirs. |
**Option B – Use standalone controller (recommended so it works even if `mailServer.js` is old)**
| Path | Purpose |
|------|--------|
| `static/mailServer/emailLimitsController.js` | Standalone script that registers `EmailLimitsNew` on the CyberCP module. |
| `mailServer/static/mailServer/emailLimitsController.js` | Same file under the app’s `static` dir. |
The Email Limits template in this repo loads `emailLimitsController.js` at the top of the content block, so the controller is registered on the Email Limits page even if the live server still has an older `mailServer.js` without `EmailLimitsNew`.
---
## Quick verification on the live server
Run from the CyberPanel app root (e.g. `/usr/local/CyberCP/`):
```bash
# 1. Template must contain the controller script and ng-controller
grep -l "emailLimitsController.js" mailServer/templates/mailServer/EmailLimits.html && \
grep -l "EmailLimitsNew" mailServer/templates/mailServer/EmailLimits.html && \
echo "Template OK" || echo "Template MISSING or WRONG"
# 2. Standalone controller script must exist (at least one location)
([ -f static/mailServer/emailLimitsController.js ] || [ -f mailServer/static/mailServer/emailLimitsController.js ]) && \
echo "emailLimitsController.js OK" || echo "emailLimitsController.js MISSING"
# 3. mailServer.js (if you rely on it for Email Limits) must define EmailLimitsNew
grep -q "EmailLimitsNew" static/mailServer/mailServer.js 2>/dev/null || grep -q "EmailLimitsNew" mailServer/static/mailServer/mailServer.js 2>/dev/null && \
echo "mailServer.js has EmailLimitsNew" || echo "mailServer.js has NO EmailLimitsNew (use emailLimitsController.js)"
# 4. Routes
grep -q "EmailLimits" mailServer/urls.py && echo "URLs OK" || echo "URLs MISSING"
```
After deploying, run:
```bash
python3 manage.py collectstatic --noinput
# Restart your app server (e.g. LiteSpeed / Gunicorn)
```
Then hard-refresh the Email Limits page (Ctrl+Shift+R).
---
## Summary
- **Upstream v2.4.4**: Email Limits template and routes exist; **controller is missing** from `mailServer.js`, so the page is broken by default.
- **This repo**: Adds `EmailLimitsNew` in `mailServer.js` and a standalone `emailLimitsController.js`, and the Email Limits template loads `emailLimitsController.js` so the page works even with an old `mailServer.js`.
- **Live server**: Ensure the template, URLs, views, manager, base template, and either the updated `mailServer.js` or `emailLimitsController.js` (or both) are present as in this checklist, then run `collectstatic` and restart the app.

83
to-do/FIREWALL-BANNED-IPS-DATABASE-AND-BAN-PERMANENTLY.md
View File

@@ -1,83 +0,0 @@
# Firewall Banned IPs: Database Storage and "Ban IP Permanently" Fix
## Summary
- **Issue:** "Ban IP Permanently" from SSH Security Analysis did not show up in Firewall Management > Banned IPs.
- **Cause:** `addBannedIP` only wrote to a JSON file, while `getBannedIPs` tried the database first. When the `BannedIP` model was available, the list was read from the database (empty), so dashboard bans (stored only in JSON) did not appear.
- **Fix:** Primary storage is now the **database** (`BannedIP` model). `addBannedIP` saves to the database first; JSON file is used only when the model is unavailable (fallback). **JSON is used only for export/import**, not for primary storage.
## Storage Policy
| Use case | Storage |
|-----------------------|----------------|
| Adding a ban | Database first, JSON fallback only if DB unavailable |
| Listing banned IPs | Database first, JSON fallback only if DB unavailable |
| Export Banned IPs | Output in **JSON format** (from DB or JSON store) |
| Import Banned IPs | Input in **JSON format**; writes to DB or JSON store |
Bans are **not** stored in a JSON file for normal operation when the database is available.
## Code Changes
1. **`firewall/firewallManager.py` – `addBannedIP`**
- Tries to save to the `BannedIP` database model first.
- Only uses the JSON file when the model cannot be imported (e.g. migrations not run).
- Applies the firewall rule in both paths; rolls back the DB or JSON record if the firewall command fails.
2. **`firewall/migrations/0001_initial.py`** (new)
- Creates the `firewall_bannedips` table and indexes for the `BannedIP` model.
- Ensures the table exists after deploy.
## Deployment (Server)
1. **Copy updated code** from this repo to the panel (e.g. `/usr/local/CyberCP/`), including:
- `firewall/firewallManager.py`
- `firewall/models.py` (must define `BannedIP`)
- `firewall/migrations/0001_initial.py`
2. **Run migrations** so the banned IPs table exists:
```bash
cd /usr/local/CyberCP
sudo -u cyberpanel /usr/local/CyberCP/bin/python manage.py migrate firewall
```
If you see "table already exists" for `firewall_bannedips`, the table was created earlier; ensure `firewall.models` defines `BannedIP` and is in `INSTALLED_APPS`.
3. **Restart the panel** (e.g. lscpd / gunicorn) so the new code is loaded.
4. **Optional – one-time sync:** If you had bans only in the JSON file and want them in the DB, use **Firewall > Banned IPs > Export Banned IPs**, then **Import Banned IPs** with that file after migrations are applied (so imports go to the database).
## Verification
- Click "Ban IP Permanently" on an IP in **Dashboard > SSH Security Analysis**.
- Open **Firewall > Banned IPs** and confirm that IP appears in the list (from the database).
- Export/Import should still use JSON format for the file; listing and adding use the database when available.
## Run and test in the browser
**Done for you (on this machine):**
1. **Deployed** `firewall/firewallManager.py` to `/usr/local/CyberCP/firewall/`.
2. **Restarted** the panel backend: `systemctl restart lscpd` (lscpd is **active**).
3. Panel is listening on **port 2087** (e.g. `https://YOUR_SERVER_IP:2087`).
**Manual browser test:**
1. Open the CyberPanel URL (e.g. `https://207.180.193.210:2087` or `https://localhost:2087`). Accept the certificate warning if needed.
2. Log in as admin.
3. **Dashboard:** Scroll to **SSH Security Analysis**. If there is an alert (e.g. "Root Login Attempts Detected"), click **Ban IP Permanently** on one of the IPs (e.g. the "Top IP").
4. Confirm the success message (e.g. "IP address … has been permanently banned … You can manage it in the Firewall > Banned IPs section").
5. Go to **Firewall** (left menu) → **Banned IPs** tab.
6. **Verify:** The IP you just banned appears in the table (IP ADDRESS, REASON e.g. "Brute force attack detected from SSH Security Analysis", EXPIRES "Never", STATUS ACTIVE).
7. Optionally: **Export Banned IPs** → download JSON; **Import Banned IPs** → upload that JSON to confirm export/import still use JSON format.
**Quick API check (optional, from server):**
```bash
# After logging in in the browser, get session cookie or use a session ID, then:
curl -k -s -X POST 'https://127.0.0.1:2087/firewall/addBannedIP' \
-H 'Content-Type: application/json' \
-H 'Cookie: sessionid=YOUR_SESSION_ID' \
-H 'X-CSRFToken: YOUR_CSRF_TOKEN' \
-d '{"ip":"203.0.113.99","reason":"Test ban","duration":"permanent"}'
# Then open Firewall > Banned IPs and confirm 203.0.113.99 appears.
```

21
to-do/FTP-QUOTA-BROWSER-TEST-CHECKLIST.md
View File

@@ -1,21 +0,0 @@
# FTP Quota Management – Browser Test Checklist
Use after deploying latest code. Open: `/ftp/quotaManagement`
## 1. Page load – status
- **Pure-FTPd stopped:** Yellow warning "Pure-FTPd is not running. Please enable Pure-FTPd first (Server Status → Services)..." and Enable button disabled/hidden.
- **Pure-FTPd running, quota on:** Green "FTP Quota system is already enabled"; button disabled.
- **Pure-FTPd running, quota off:** Blue info and enabled "Enable FTP Quota System" button.
## 2. Click Enable
- If FTP was running: success message and UI switches to "already enabled". No "Pure-FTPd did not start" error.
- If FTP was stopped: API returns "Pure-FTPd is not running. Please enable Pure-FTPd first...".
## 3. Table
- Quotas table loads; Refresh works.
## 4. One-time fix on server (if needed)
```bash
sudo sed -i 's/^Quota.*/Quota 100000:100000/' /etc/pure-ftpd/pure-ftpd.conf
sudo systemctl start pure-ftpd
```

25
to-do/FTP-QUOTAS-TABLE-FIX.md
View File

@@ -1,25 +0,0 @@
# FTP Quotas Table Fix
## Problem
- **URL:** https://207.180.193.210:2087/ftp/quotaManagement
- **Error:** `(1146, "Table 'cyberpanel.ftp_quotas' doesn't exist")`
The `FTPQuota` model in `websiteFunctions/models.py` uses `db_table = 'ftp_quotas'`, but the table had never been created in the database.
## Solution
1. **SQL:** `sql/create_ftp_quotas.sql` – `CREATE TABLE IF NOT EXISTS ftp_quotas` with columns and FKs to `loginSystem_administrator` and `websiteFunctions_websites`.
2. **Deploy script:** `deploy-ftp-quotas-table.sh` – Copies the SQL to `/usr/local/CyberCP/sql/` and runs it using Django’s DB connection (no password on command line).
## Deploy (already run)
```bash
sudo bash /home/cyberpanel-repo/deploy-ftp-quotas-table.sh
```
## Manual run (if needed)
From repo root:
```bash
sudo bash deploy-ftp-quotas-table.sh [REPO_DIR] [CP_DIR]
```
Default `CP_DIR` is `/usr/local/CyberCP`.
After deployment, reload `/ftp/quotaManagement` in the browser.

201
to-do/INSTALL-UPGRADE-DOWNGRADE-COMMANDS.md
View File

@@ -1,201 +0,0 @@
# CyberPanel Install, Upgrade, and Downgrade Commands
Reference for all standard and branch-specific install/upgrade/downgrade commands (master3395 fork and upstream).
---
## Installation logs (v2.4.4 / v2.5.5-dev)
When you run the installer (cyberpanel.sh or install.py), logs are written to:
| Log | Location | Description |
|-----|----------|--------------|
| Installer script | `/var/log/CyberPanel/install.log` | Messages from cyberpanel.sh (print_status) |
| Installer output | `/var/log/CyberPanel/install_output.log` | Full stdout/stderr of the Python installer (tee) |
| Python installer | `/var/log/installLogs.txt` | Detailed log from install.py (installLog module) |
To inspect after a failed install:
```bash
tail -100 /var/log/CyberPanel/install_output.log
tail -100 /var/log/installLogs.txt
```
**If you see ERR_CONNECTION_TIMED_OUT** when opening the panel URL: the install may have failed before LiteSpeed was set up, or ports are blocked. Ensure ports **8090** (panel) and **7080** (LSWS admin) are open in the server firewall and in your cloud security group (e.g. AWS). Re-run the installer after pulling the latest fixes so the install can complete.
---
## Fresh install
### One-liner (official / upstream)
```bash
sh <(curl https://cyberpanel.net/install.sh)
```
### One-liner with sudo (if not root)
```bash
curl -sO https://cyberpanel.net/install.sh && sudo bash install.sh
# or
curl -sL https://cyberpanel.net/install.sh | sudo bash -s --
```
### Install from master3395 fork (this repo)
**Stable:**
```bash
curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/stable/cyberpanel.sh | sudo bash -s --
```
**Development (v2.5.5-dev):**
```bash
curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/v2.5.5-dev/cyberpanel.sh | sudo bash -s -- -b v2.5.5-dev
```
### Install with branch/version options
```bash
# Download script first (recommended so -b/-v work reliably)
curl -sL -o cyberpanel.sh https://raw.githubusercontent.com/master3395/cyberpanel/v2.5.5-dev/cyberpanel.sh
chmod +x cyberpanel.sh
sudo bash cyberpanel.sh [OPTIONS]
```
**Options:**
| Option | Example | Description |
|--------|---------|-------------|
| `-b BRANCH` / `--branch BRANCH` | `-b v2.5.5-dev` | Install from branch or tag |
| `-v VER` / `--version VER` | `-v 2.5.5-dev` | Version (script adds `v` prefix as needed) |
| `--mariadb-version VER` | `--mariadb-version 10.11` | MariaDB: `10.11`, `11.8`, or `12.1` |
| `--auto` | `--auto` | Non-interactive (still asks MariaDB unless `--mariadb-version` is set) |
| `--debug` | `--debug` | Debug mode |
**Examples:**
```bash
sudo bash cyberpanel.sh # Interactive
sudo bash cyberpanel.sh -b v2.5.5-dev # Development branch
sudo bash cyberpanel.sh -v 2.5.5-dev # Same as above (v prefix added)
sudo bash cyberpanel.sh -v 2.4.4 # Install 2.4.4
sudo bash cyberpanel.sh -b main # From main branch
sudo bash cyberpanel.sh -b a1b2c3d4 # From specific commit hash
sudo bash cyberpanel.sh --mariadb-version 10.11 # MariaDB 10.11
sudo bash cyberpanel.sh --mariadb-version 12.1 # MariaDB 12.1
sudo bash cyberpanel.sh --auto --mariadb-version 11.8 # Fully non-interactive, MariaDB 11.8
sudo bash cyberpanel.sh --debug # Debug
```
---
## Upgrade (existing CyberPanel)
### One-liner upgrade to latest stable
```bash
bash <(curl -sL https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/cyberpanel_upgrade.sh)
```
### Upgrade to a specific branch/version (upstream)
```bash
bash <(curl -sL https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/cyberpanel_upgrade.sh) -b v2.5.5-dev
bash <(curl -sL https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/cyberpanel_upgrade.sh) -b 2.4.4
```
### Upgrade using master3395 fork
```bash
sudo bash <(curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/stable/cyberpanel_upgrade.sh) -b v2.5.5-dev
```
Or download then run:
```bash
curl -sL -o cyberpanel_upgrade.sh https://raw.githubusercontent.com/master3395/cyberpanel/v2.5.5-dev/cyberpanel_upgrade.sh
chmod +x cyberpanel_upgrade.sh
sudo bash cyberpanel_upgrade.sh -b v2.5.5-dev
```
**Upgrade options:**
| Option | Example | Description |
|--------|---------|-------------|
| `-b BRANCH` / `--branch BRANCH` | `-b v2.5.5-dev` | Upgrade to this branch/tag |
| `--no-system-update` | (optional) | Skip full `yum/dnf update -y` (faster if system is already updated) |
**Examples:**
```bash
sudo bash cyberpanel_upgrade.sh -b v2.5.5-dev
sudo bash cyberpanel_upgrade.sh -b 2.4.4
sudo bash cyberpanel_upgrade.sh -b stable
sudo bash cyberpanel_upgrade.sh -b v2.5.5-dev --no-system-update
```
---
## Downgrade
Downgrade is done by running the **upgrade** script with the **older** branch/version.
### Downgrade to 2.4.4 (or another older version)
```bash
sudo bash <(curl -sL https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/cyberpanel_upgrade.sh) -b 2.4.4
```
Or with master3395 fork:
```bash
curl -sL -o cyberpanel_upgrade.sh https://raw.githubusercontent.com/master3395/cyberpanel/stable/cyberpanel_upgrade.sh
chmod +x cyberpanel_upgrade.sh
sudo bash cyberpanel_upgrade.sh -b 2.4.4
```
### Downgrade from v2.5.5-dev to stable
```bash
sudo bash cyberpanel_upgrade.sh -b stable
```
---
## Pre-upgrade (download upgrade script only)
From the interactive menu: **Option 5 – Pre-Upgrade**.
Or manually:
```bash
# Download latest upgrade script to /usr/local/
curl -sL -o /usr/local/cyberpanel_upgrade.sh https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/cyberpanel_upgrade.sh
chmod 700 /usr/local/cyberpanel_upgrade.sh
# Run when ready
sudo /usr/local/cyberpanel_upgrade.sh -b v2.5.5-dev
```
---
## Quick reference
| Action | Command |
|--------|---------|
| **Install (official)** | `sh <(curl https://cyberpanel.net/install.sh)` |
| **Install stable (master3395)** | `curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/stable/cyberpanel.sh \| sudo bash -s --` |
| **Install v2.5.5-dev** | `curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/v2.5.5-dev/cyberpanel.sh \| sudo bash -s -- -b v2.5.5-dev` |
| **Upgrade to v2.5.5-dev** | `sudo bash <(curl -sL https://raw.githubusercontent.com/master3395/cyberpanel/stable/cyberpanel_upgrade.sh) -b v2.5.5-dev` |
| **Upgrade to 2.4.4** | `sudo bash <(curl -sL .../cyberpanel_upgrade.sh) -b 2.4.4` |
| **Downgrade to 2.4.4** | Same as upgrade: `... cyberpanel_upgrade.sh -b 2.4.4` |
---
## Notes
- Run as **root** or with **sudo**; if using `curl | sudo bash`, use `bash -s --` and put branch/options after `--` so they are passed to the script.
- MariaDB version can be set at install with `--mariadb-version 10.11`, `11.8`, or `12.1`.
- Upgrade script branch: `-b v2.5.5-dev`, `-b 2.4.4`, `-b stable`, or `-b <commit-hash>`.

34
to-do/MARIADB-11.8-LTS-UPGRADE.md
View File

@@ -1,34 +0,0 @@
# MariaDB 11.8 LTS and 12.1
## Summary
CyberPanel install and upgrade support **MariaDB 11.8 LTS** (default) or **12.1**. User can choose at install/upgrade time; **downgrade is supported** (e.g. 12.1 → 11.8 by re-running upgrader with `--mariadb-version 11.8`).
- **New installs:** `--mariadb-version 11.8|12.1` (default 11.8); `install.py` and `venvsetup.sh` pass it through.
- **Upgrades:** `cyberpanel_upgrade.sh --mariadb-version 11.8|12.1` or interactive prompt; writes `/etc/cyberpanel/mariadb_version` for `upgrade.py`.
- **Downgrade:** Run upgrader again with the desired version (e.g. `--mariadb-version 11.8` to switch from 12.1 to 11.8). Repo and packages will target the chosen version.
- **cyberpanel_upgrade.sh:** Uses `MARIADB_VER` (default 11.8) in `MariaDB.repo` baseurl and writes `/etc/cyberpanel/mariadb_version`.
- **plogical/upgrade.py:** `fix_almalinux9_mariadb()` reads `/etc/cyberpanel/mariadb_version` (default 11.8) and runs `mariadb_repo_setup` with that version.
- **UI (Database upgrade):** `databases/databaseManager.py` offers 10.6, 10.11, **11.8** for manual upgrade.
- **mysqlUtilities.UpgradeMariaDB:** Repo baseurl uses `versionToInstall` (e.g. 11.8).
## Testing
From repo root:
- Shell (upgrader argument parsing and repo URL logic):
`./test/upgrader_mariadb_version_test.sh`
- Python (mariadb_version file read and downgrade):
`python3 test/test_upgrade_mariadb_version.py`
Both 11.8 and 12.1 paths are tested; downgrade (12.1 → 11.8) is explicitly verified.
## References
- `cyberpanel_upgrade.sh`: MARIADB_VER, --mariadb-version, /etc/cyberpanel/mariadb_version
- `plogical/upgrade.py`: fix_almalinux9_mariadb() reads mariadb_version file
- `install/install.py`: --mariadb-version, preFlightsChecks.mariadb_version
- `install/venvsetup.sh`: MARIADB_VER prompt, --mariadb-version to install.py
- `install/universal_os_fixes.py`: setup_mariadb_repository() 11.8
- `databases/databaseManager.py`: mysqlversions 10.6, 10.11, 11.8
- `plogical/mysqlUtilities.py`: UpgradeMariaDB() baseurl for RHEL

88
to-do/MARIADB_INSTALLATION_FIXES.md
View File

@@ -1,88 +0,0 @@
# MariaDB Installation Fixes
## Issues Fixed
### 1. MariaDB-server-compat Package Conflict
**Problem**: `MariaDB-server-compat-12.1.2-1.el9.noarch` was conflicting with MariaDB 10.11 installation, causing transaction test errors.
**Solution**:
- Enhanced compat package removal with multiple aggressive removal attempts
- Added `--allowerasing` flag to dnf remove commands
- Added dnf exclude configuration to prevent compat package reinstallation
- Verification step to ensure all compat packages are removed before installation
**Files Modified**:
- `cyberpanel-repo/plogical/upgrade.py` - `fix_almalinux9_mariadb()` function
- `cyberpanel-repo/install/install.py` - `installMySQL()` function
### 2. MySQL Command Not Found Error
**Problem**: After MariaDB installation failed, the `changeMYSQLRootPassword()` function tried to use the `mysql` command which didn't exist, causing `FileNotFoundError`.
**Solution**:
- Added verification that MariaDB binaries exist before attempting password change
- Added check for mysql/mariadb command availability
- Added MariaDB service status verification before password change
- Added wait time for MariaDB to be ready after service start
**Files Modified**:
- `cyberpanel-repo/install/install.py` - `changeMYSQLRootPassword()` function
- `cyberpanel-repo/install/install.py` - `installMySQL()` function
### 3. MariaDB Installation Verification
**Problem**: Installation was proceeding even when MariaDB wasn't actually installed successfully.
**Solution**:
- Added binary existence check after installation
- Added service status verification
- Added proper error handling and return values
- Installation now fails gracefully if MariaDB wasn't installed
**Files Modified**:
- `cyberpanel-repo/plogical/upgrade.py` - `fix_almalinux9_mariadb()` function
- `cyberpanel-repo/install/install.py` - `installMySQL()` function
## Changes Made
### upgrade.py
1. **Enhanced compat package removal**:
- Multiple removal attempts (dnf remove, rpm -e, individual package removal)
- Added `--allowerasing` flag
- Added dnf exclude configuration
- Verification step
2. **Improved MariaDB installation**:
- Added `--exclude='MariaDB-server-compat*'` to dnf install command
- Added fallback with `--allowerasing` if conflicts occur
- Added binary existence verification after installation
- Proper error handling and return values
### install.py
1. **Enhanced compat package removal** (same as upgrade.py)
2. **Improved installation verification**:
- Check for MariaDB binaries after installation
- Verify service is running before password change
- Added wait time for service to be ready
- Proper error handling
3. **Improved password change function**:
- Verify mysql/mariadb command exists before attempting password change
- Better error messages
- Graceful failure handling
## Testing Recommendations
1. Test on clean AlmaLinux 9 system
2. Test with existing MariaDB-server-compat package installed
3. Test with MariaDB 10.x already installed
4. Test with MariaDB 12.x already installed
5. Verify MariaDB service starts correctly
6. Verify mysql/mariadb commands are available
7. Verify password change succeeds
## Notes
- The fixes maintain backward compatibility
- All changes include proper error handling
- Installation now fails gracefully with clear error messages
- Compat package removal is more aggressive to handle edge cases

132
to-do/OLD-REPO-CHECKLIST-BEFORE-REMOVAL.md
View File

@@ -1,132 +0,0 @@
# What Was in the Old cyberpanel-fix Repo – Pre-Removal Checklist
Before removing `/home/cyberpanel-fix-backup-20260202`, verify the merged repo has everything you need.
---
## 1. Files ONLY in cyberpanel-repo (not in old fix) ✅
These are in the merged repo and were not in the old fix:
| File | Purpose |
|------|---------|
| `commit_and_push.sh`, `commit_changes.py`, `push_fix.py`, `push_fix.sh` | Dev/utility scripts |
| `fix_todo_git.py`, `remove_todo.py`, `remove_todo_from_git.sh` | Git helpers |
| `olves issue -1654: Hostname SSL setup...` | Patch file (typo in filename) |
| `pluginHolder/patreon_verifier.py.bak`, `plugin_access.py.bak` | Backups |
| `pluginHolder/templates/pluginHolder/plugins.html.backup` | Template backup |
| `static/userManagment/modifyUser.html` | UI change |
| `to-do/PLUGIN-DEFAULT-REMOVAL-2026-02-01.md` | Notes |
| `to-do/REPO-MERGE-2026-02-02.md` | Merge notes |
**Action:** None. These are already in the merged repo.
---
## 2. Files COPIED from old fix into repo ✅
These were only in the old fix and were copied into repo during the merge:
| File | Purpose |
|------|---------|
| `cyberpanel_clean.sh` | Clean install script |
| `cyberpanel_complete.sh` | Complete install script |
| `cyberpanel_simple.sh` | Simple install script |
| `cyberpanel_standalone.sh` | Standalone install script |
| `fix_installation_issues.sh` | Installation fixes |
| `install_phpmyadmin.sh` | phpMyAdmin installer |
| ~~`simple_install.sh`~~ | Removed – use official install.sh one-liner |
| `INSTALLER_SUMMARY.md` | Installer docs |
| `UNIVERSAL_OS_COMPATIBILITY.md` | OS compatibility docs |
| `to-do/MARIADB_INSTALLATION_FIXES.md` | MariaDB fixes |
**Action:** Confirm these exist in `/home/cyberpanel-repo/`.
---
## 3. Files that DIFFER – repo is the intended version
The merged repo keeps the **cyberpanel-repo** versions. Old fix had older or different logic.
### CyberCP/settings.py
- **Repo:** `emailMarketing` is commented out (install via Plugin Store)
- **Old fix:** `emailMarketing` was in `INSTALLED_APPS`
**Check:** Plugin Store for emailMarketing works; no need for it in core install.
### CyberCP/urls.py
- **Repo:** `path('emailMarketing/', ...)` is commented out
- **Old fix:** `path('emailMarketing/', ...)` was active
**Check:** Same as above; emailMarketing via Plugin Store.
### plogical/mailUtilities.py
- **Repo:** DNS fallback logic – falls back to **local DNS** when external API fails
- **Old fix:** Returns empty `[]` when external API fails; no local fallback
**Check:** Hostname SSL / rDNS works when cyberpanel.net API is down or unreachable.
### emailMarketing/meta.xml
- **Repo:** version `1.0.1`, category `Email`
- **Old fix:** version `1.0.0`
### examplePlugin/meta.xml
- **Repo:** version `1.0.1`, category `Utility`
- **Old fix:** version `1.0.0`
**Check:** Plugin Store shows correct versions and categories.
---
## 4. PluginHolder / Plugin Store (in repo)
The merged repo has:
- Collapsible help sections
- Freshness badges (NEW/Stable/Unstable/STALE)
- Activate All / Deactivate All
- Updated categories and premium docs
- Version 2.1.0 in the help footer
**Check:** `/plugins/help/` and `/plugins/installed` behave as expected.
---
## 5. Quick verification commands
```bash
# Copied files exist
ls -la /home/cyberpanel-repo/cyberpanel_clean.sh \
/home/cyberpanel-repo/fix_installation_issues.sh \
/home/cyberpanel-repo/install_phpmyadmin.sh
# Symlink works
ls -la /home/cyberpanel-fix
# Should show: cyberpanel-fix -> cyberpanel-repo
# Live deployment
ls -la /usr/local/CyberCP/pluginHolder/templates/pluginHolder/help.html
# Should have collapsible sections and version 2.1.0
```
---
## 6. Safe to remove when
- [ ] Plugin Store loads and filters work
- [ ] Plugin Development Guide (help) shows collapsible sections and 2.1.0
- [ ] Hostname SSL / rDNS works (or you accept no local DNS fallback)
- [ ] emailMarketing is installed via Plugin Store, not core (if used)
- [ ] Install scripts (`cyberpanel_clean.sh`, etc.) are present and used as needed
---
## Remove backup
```bash
rm -rf /home/cyberpanel-fix-backup-20260202
```
---
**Created:** 2026-02-02

62
to-do/OPENLITESPEED-VERSION-INSTALL-UPGRADE.md
View File

@@ -1,62 +0,0 @@
# OpenLiteSpeed and LSWS Version Used by CyberPanel (Install & Upgrade)
**Updated:** OLS target 1.8.5+ (LiteSpeed repo); LSWS fallback 6.3.4.
## Summary
- **Install:** OpenLiteSpeed is installed via the **OS package manager** (no fixed version in code), then optionally replaced by CyberPanel’s **custom static binary** (based on **OpenLiteSpeed 1.8.5 – v2.0.5**).
- **Upgrade:** The CyberPanel **upgrade script does not change the OpenLiteSpeed version**. It only updates **LiteSpeed Enterprise** version references. During upgrade, **custom OLS binaries** (same 1.8.5-based build) are (re)installed if OLS is present.
---
## Install
1. **Package install**
- `install/install.py` → `installLiteSpeed(ent=0)` → `install_package('openlitespeed')`.
- So the **base** install is whatever **openlitespeed** version the distro provides (yum/dnf or apt). There is **no fixed OLS version** in the installer for this step.
2. **Custom binary (optional)**
- Right after that, `installCustomOLSBinaries()` runs (in both `install/install.py` and `plogical/upgrade.py`).
- It downloads a **static binary** from `https://cyberpanel.net/` (e.g. `openlitespeed-phpconfig-x86_64-rhel8-static`) and replaces `/usr/local/lsws/bin/openlitespeed`.
- Comments in code state this is **OpenLiteSpeed 1.8.5** (upgrade.py) or **1.8.5 – v2.0.5** (install.py). The download URLs do not include a version; the binary is a fixed build hosted by CyberPanel.
So on **install**, you get either:
- **Distro OLS** (version = whatever the OS repo has), or
- **CyberPanel custom OLS** (based on **1.8.5 / v2.0.5** static build) if the custom binary install succeeds.
---
## Upgrade
1. **cyberpanel_upgrade.sh**
- Fetches **LiteSpeed Enterprise** latest version from:
- `LSWS_Latest_URL="https://cyberpanel.sh/update.litespeedtech.com/ws/latest.php"`
- Parses `LSWS_Stable_Version` from the `LSWS_STABLE` line.
- Uses `LSWS_Stable_Version` only to **sed**-replace hardcoded Enterprise version strings (e.g. `lsws-5.3.8`, `lsws-5.4.2`, `lsws-5.3.5`) in `/usr/local/CyberCP/serverStatus/serverStatusUtil.py`.
- So the **upgrade script does not install or upgrade OpenLiteSpeed**; it only updates **Enterprise** version references.
2. **plogical/upgrade.py**
- During upgrade, if OpenLiteSpeed is present (`/usr/local/lsws/bin/openlitespeed` exists), it runs:
- `Upgrade.installCustomOLSBinaries()`
- That (re)installs the **same custom static OLS binary** (1.8.5-based, from cyberpanel.net). So **upgrade** does not pull a “new” OLS version from upstream; it only refreshes CyberPanel’s custom binary if OLS is in use.
---
## References (in repo)
| What | Where |
|------|--------|
| OLS package install (no version) | `install/install.py` → `install_package('openlitespeed')` in `installLiteSpeed()` |
| Custom OLS binary (1.8.5 / 1.8.5–v2.0.5) | `install/install.py` and `plogical/upgrade.py` → `installCustomOLSBinaries()` and `BINARY_CONFIGS` comments |
| LSWS version used in upgrade (Enterprise only) | `cyberpanel_upgrade.sh` → `LSWS_Latest_URL`, `LSWS_Stable_Version`, and sed to `serverStatusUtil.py` |
| Custom OLS on upgrade | `plogical/upgrade.py` → `if os.path.exists('/usr/local/lsws/bin/openlitespeed'): Upgrade.installCustomOLSBinaries()` |
---
## Short answers
- **What OpenLiteSpeed version does install use?**
Package: **distro default**. If custom binary is used: **OpenLiteSpeed 1.8.5 (or 1.8.5–v2.0.5)** static build from cyberpanel.net.
- **What OpenLiteSpeed version does upgrade use?**
Upgrade does **not** change OLS version from upstream. It only (re)installs the **same custom 1.8.5-based** binary when OLS is present. **LiteSpeed Enterprise** version is the one fetched from `cyberpanel.sh/update.litespeedtech.com/ws/latest.php` and written into `serverStatusUtil.py`.

24
to-do/PANEL-ACCESS-PLUGIN-STORE.md
View File

@@ -1,24 +0,0 @@
# Panel Access plugin – store distribution
**Panel Access (Custom Domain)** is a normal plugin. It is **not** in the core repo’s `INSTALLED_APPS` or main URLs.
## Install on a server
1. **From zip (repo)**
- Build zip: from repo root, `zip -r panelAccess.zip panelAccess -x "panelAccess/__pycache__/*" -x "*.pyc"`
- In CyberPanel: **Plugins → Store** (or upload zip), install **Panel Access (Custom Domain)**.
- Or copy `panelAccess/` to `/usr/local/CyberCP/panelAccess/`, add `'panelAccess'` to `CyberCP/settings.py` `INSTALLED_APPS` (after `'emailPremium',`), and add
`path('plugins/panelAccess/', include('panelAccess.urls')),` to `CyberCP/urls.py` before the generic `path('plugins/', include('pluginHolder.urls'))`, then restart lscpd.
2. **From plugin store (GitHub)**
- Add the `panelAccess` folder to the **cyberpanel-plugins** repo (e.g. `master3395/cyberpanel-plugins`) so it appears in the store.
- Users then install via **Plugins → Store** like Memcache Manager or Contabo Auto Snapshot.
## URLs
- Settings page: **/plugins/panelAccess/**
- Same as **Settings** from **Plugins → Installed** for Panel Access.
## Zip location
- `panelAccess.zip` can be generated in the repo root and committed or published for one-off installs.

13
to-do/PLUGIN-DEFAULT-REMOVAL-2026-02-01.md
View File

@@ -1,13 +0,0 @@
# Plugin Default Removal - 2026-02-01
## Summary
CyberPanel repository no longer requires any plugins by default. Plugins are installed by users from the [Plugin Store](https://github.com/master3395/cyberpanel-plugins) via the CyberPanel Plugin Manager.
## Changes
- **settings.py**: Removed `emailMarketing` from `INSTALLED_APPS`
- **urls.py**: Commented out `emailMarketing` route (plugin installer adds it when plugin is installed)
## Plugin Installation
Users install plugins from: https://github.com/master3395/cyberpanel-plugins
The plugin installer adds apps to `INSTALLED_APPS` and URL routes when plugins are installed via the Plugin Store UI.

45
to-do/PURE-FTPD-QUOTA-SYNTAX-FIX.md
View File

@@ -1,45 +0,0 @@
# Pure-FTPd Quota Syntax Fix (2026-02-04)
## Problem
Pure-FTPd failed to start with:
```
/etc/pure-ftpd/pure-ftpd.conf:35:1: syntax error line 35: [Quota ...].
```
## Cause
The config used `Quota yes`, but Pure-FTPd expects **`Quota maxfiles:maxsize`** (e.g. `Quota 1000:10` for 1000 files and 10 MB). The value is not a boolean.
## Fix applied
### On the server
- `/etc/pure-ftpd/pure-ftpd.conf`: line 35 set to `Quota 100000:100000` (high default so MySQL per-user quotas apply).
- Service started successfully: `systemctl start pure-ftpd`.
### In the repo
- **install/pure-ftpd/pure-ftpd.conf** and **install/pure-ftpd-one/pure-ftpd.conf**: `Quota yes` → `Quota 100000:100000`.
- **websiteFunctions/website.py** (`enableFTPQuota`): sed/echo now write `Quota 100000:100000` instead of `Quota yes` (or tabs).
## One-time fix on server (if "Enable" still breaks it)
Run on the server as root (copy script from repo or run inline):
**Option A – script (repo root: `fix-pureftpd-quota-once.sh`):**
```bash
sudo bash /path/to/fix-pureftpd-quota-once.sh
```
**Option B – inline:**
```bash
sudo sed -i 's/^Quota.*/Quota 100000:100000/' /etc/pure-ftpd/pure-ftpd.conf
# If TLS 1 is set but cert missing, disable TLS:
sudo sed -i 's/^TLS[[:space:]]*1/TLS 0/' /etc/pure-ftpd/pure-ftpd.conf
sudo systemctl start pure-ftpd
```
Then deploy the latest panel code so "Enable" uses the correct Quota syntax.
## Code safeguards (enableFTPQuota)
- **Backup before modify**: Timestamped backup of `pure-ftpd.conf` and `pureftpd-mysql.conf` before any change.
- **Safety net before restart**: If the Quota line is not valid (`Quota maxfiles:maxsize`), it is corrected to `Quota 100000:100000` so Pure-FTPd never gets an invalid line on restart.
## Reference
- Upstream: https://github.com/jedisct1/pure-ftpd/blob/master/pure-ftpd.conf.in (comment: "Quota 1000:10").
- `pure-ftpd --help`: `-n --quota <opt>`.

38
to-do/REPO-MERGE-2026-02-02.md
View File

@@ -1,38 +0,0 @@
# CyberPanel Repo Merge – 2026-02-02
## Summary
`cyberpanel-repo` and `cyberpanel-fix` have been merged into a single working directory.
## What Was Done
1. **Unique files copied from cyberpanel-fix into cyberpanel-repo:**
- `cyberpanel_clean.sh`
- `cyberpanel_complete.sh`
- `cyberpanel_simple.sh`
- `cyberpanel_standalone.sh`
- `fix_installation_issues.sh`
- `install_phpmyadmin.sh`
- ~~`simple_install.sh`~~ (removed; use official install.sh)
- `INSTALLER_SUMMARY.md`
- `UNIVERSAL_OS_COMPATIBILITY.md`
- `to-do/MARIADB_INSTALLATION_FIXES.md`
2. **cyberpanel-fix backup:** Renamed to `cyberpanel-fix-backup-20260202`
3. **Symlink created:** `cyberpanel-fix` → `cyberpanel-repo`
- Paths like `/home/cyberpanel-fix/` now resolve to `/home/cyberpanel-repo/`
## Single Source of Truth
Use **`/home/cyberpanel-repo`** (or `/home/cyberpanel-fix` via symlink) for all CyberPanel development and deployment.
## Backup Location
The previous cyberpanel-fix tree is preserved at:
`/home/cyberpanel-fix-backup-20260202`
You can remove it after confirming everything works:
```bash
rm -rf /home/cyberpanel-fix-backup-20260202
```

77
to-do/REVERSE-PROXY-DOMAIN-CSRF.md
View File

@@ -1,77 +0,0 @@
# CyberPanel Behind a Reverse Proxy (Custom Domain)
When you put a **custom domain** in front of the panel (e.g. `https://panel.example.com` → proxy → `http://127.0.0.1:2087`), two things often break if the proxy is not configured for them:
1. **403 on POST requests** (e.g. Ban IP, form submissions) — **CSRF verification failed**
2. **Charts / some UI not loading** — backend may treat the request as different from “direct” IP:port access
With **IP:port** everything works because the browser and the backend agree on the same host.
---
## Why it breaks
- The **browser** sends `Origin` / `Referer` with the **public URL** (e.g. `https://panel.example.com`).
- The **proxy** often forwards the request with **Host** set to the **backend** (e.g. `127.0.0.1:2087` or `207.180.193.210:2087`).
- **Django** checks CSRF by comparing the request’s **Referer/Origin** to the request’s **Host**. They don’t match → **403 Forbidden** and the body says *“CSRF verification failed. Request aborted.”*
So: **domain in the browser, backend host in `Host`** → CSRF fails and POSTs (like Ban IP) get 403.
---
## Fix option 1: Panel Access (recommended, no env vars)
Use the built-in **Panel Access** page to add your custom domain(s):
1. In CyberPanel go to **Plugins → Panel Access (Custom Domain)**.
2. Enter your public origin(s), one per line (e.g. `https://panel.example.com`, `http://panel.example.com`).
3. Click **Save**.
4. Restart the CyberPanel backend so Django picks up the change, e.g.:
```bash
systemctl restart lscpd
```
Origins are stored in a config file (by default `/home/cyberpanel/panel_csrf_origins.conf`). They are merged with any `CSRF_TRUSTED_ORIGINS` set via environment. No hardcoded domains; safe for GitHub.
**OpenLiteSpeed proxy (optional):** On the same page you can enable **“Also add domain in OpenLiteSpeed (reverse proxy to panel)”**. When you save, the panel will create a proxy vhost for each domain so the panel is reachable at that domain (e.g. `http://panel.example.com`) without manual OLS configuration. This only configures HTTP (port 80); for HTTPS use Manage SSL or your own certificate. The proxy forwards to the panel backend (default `https://127.0.0.1:2087`). Override with the `PANEL_BACKEND_URL` environment variable if your panel listens elsewhere.
---
## Fix option 2: Environment variable
In `CyberCP/settings.py`, `CSRF_TRUSTED_ORIGINS` is also built from the environment variable **`CSRF_TRUSTED_ORIGINS`** (comma‑separated list of origins).
When you run the panel behind a custom domain, you can set that variable to your **public** origin(s), for example:
```bash
export CSRF_TRUSTED_ORIGINS="https://panel.example.com,http://panel.example.com"
```
Then start (or restart) the CyberPanel backend. Where to set it depends on how you run the panel:
- **systemd (lscpd)**: add to `[Service]` in `/etc/systemd/system/lscpd.service`:
```ini
Environment="CSRF_TRUSTED_ORIGINS=https://panel.example.com,http://panel.example.com"
```
Then run `systemctl daemon-reload` and `systemctl restart lscpd`.
- **Supervisor / other**: set in the program’s `environment` or equivalent.
- **Manual run**: export in the same shell before starting the app.
Use your real domain; no need to add anything to the repo. This keeps the codebase generic for GitHub.
---
## Optional: proxy Host header
Some backends only “recognise” the panel when **Host** is the backend address (e.g. IP:port). In that case the proxy is often configured to **override** Host to that address so the initial HTML and routing work. That is why the **same** proxy setup can make the **page** load but **POSTs** fail: Referer stays the public domain, Host is the backend → CSRF fails. Fixing CSRF with `CSRF_TRUSTED_ORIGINS` (as above) addresses that.
---
## Summary
| Symptom | Cause | Fix (generic, repo‑friendly) |
|----------------------|--------------------------------|--------------------------------|
| 403 on Ban IP / POST | CSRF fail (Referer vs Host) | **Panel Access**: Plugins → Panel Access (Custom Domain), add your origin(s), save, then restart lscpd. Or set `CSRF_TRUSTED_ORIGINS` env and restart backend. |
| Charts / UI not loading | Can be session/Host/static | Ensure session cookies and static URLs work; CSRF fix above helps POSTs; adjust proxy if needed |
No domain is hardcoded in the repo. Use the Panel Access page or the `CSRF_TRUSTED_ORIGINS` environment variable for your own domain(s).

83
to-do/RUNTIME-VS-REPO-2.5.5-DEV.md
View File

@@ -1,83 +0,0 @@
# Runtime vs Repo: What Belongs in cyberpanel-repo for 2.5.5-dev
## Goal
When users upgrade to **our** (master3395) 2.5.5-dev, the panel should look and behave the same. That means **default** look-and-feel and behavior must be defined in the repo, not only “generated” on the server.
---
## What is “runtime generated”?
On the live server, after install/upgrade you have:
1. **From the repo (clone/copy)**
All app code, templates, static sources, migrations, `version.txt`, default `settings.py`, etc.
→ This **should** be in the repo (and already is).
2. **Generated at install/upgrade**
- Python venv under `/usr/local/CyberCP/bin`, `lib`, `lib64`
- `collectstatic` output under `/usr/local/CyberCP/public/static`
- `version` table and `baseTemplate_cyberpanelcosmetic` row (if created by code/migrations)
- `lscpd` binary copy, symlinks, etc.
→ The **sources** that produce these (e.g. static sources, migrations) **should** be in the repo.
3. **Per-server / preserved**
- `CyberCP/settings.py` — upgrade **merges** only the `DATABASES` section from the old server; the rest (e.g. `INSTALLED_APPS`) comes from the **new** clone.
- `baseTemplate/static/baseTemplate/custom/` (custom CSS files)
- DB row `baseTemplate_cyberpanelcosmetic.MainDashboardCSS` (custom dashboard CSS)
- `.git/`, phpMyAdmin config, SnappyMail data, etc.
→ **Defaults** that define “how 2.5.5-dev looks” should be in the repo; **per-server overrides** stay on the server.
---
## What we need in the repo so 2.5.5-dev “looks the same”
- **Templates, static sources, JS/CSS**
Already in repo (e.g. `baseTemplate/`, `static/`). No change needed for “same look” unless you change the design.
- **Default `settings.py`**
Already in repo. Upgrade keeps DB credentials from the server and uses repo for everything else (e.g. `INSTALLED_APPS`).
So 2.5.5-dev behavior is driven by the repo’s `settings.py`.
- **Version**
`baseTemplate/views.py` has `VERSION = '2.5.5'`, `BUILD = 'dev'`. Repo’s `version.txt` is `{"version":"2.5.5","build":"dev"}`.
Upgrade also writes version into the DB. So version “same as 2.5.5-dev” is already defined in the repo.
- **Default “look” (cosmetic)**
- Code already creates a default `CyberPanelCosmetic` row with **empty** `MainDashboardCSS` if none exists (`baseTemplate/context_processors.py`, `plogical/httpProc.py`, `loginSystem/views.py`).
- If **your live server** has custom dashboard CSS (in DB or in `baseTemplate/static/baseTemplate/custom/`), that is **your** customization.
- To make “our 2.5.5-dev” ship with that same look as default, you have two options:
1. **Data migration**
Add a baseTemplate data migration that does:
- `CyberPanelCosmetic.objects.get_or_create(pk=1, defaults={'MainDashboardCSS': '<your default CSS>'})`
so every new/upgraded install gets that default look.
2. **Static default**
Put the CSS in a static file under `baseTemplate/static/` and include it in the base template so the default theme matches your live server.
- **Migrations**
All schema (and optional data) migrations must be in the repo so every 2.5.5-dev install/upgrade runs the same schema and, if you add it, the same default cosmetic data.
---
## What should **not** be in the repo
- **Secrets**: DB password, `SECRET_KEY`, API keys.
Keep in `settings.py` only placeholders or env reads; real values stay on the server (or in config.php / env per your rules).
- **User data**: sites, users, mail, backups.
These are per-server.
- **Generated artifacts**: venv, `collectstatic` output, compiled binaries.
Repo holds the **source**; install/upgrade generates these on the server.
---
## Summary
- **Yes:** “Runtime generated” **defaults** that define how 2.5.5-dev looks and behaves **should** be reflected in the repo (templates, static sources, migrations, default cosmetic logic or data).
- **Already in repo:** App code, default settings structure, version, static sources, migrations. So 2.5.5-dev upgrades already get the same **code** and **default look** (empty custom CSS).
- **Optional:** If your live server has a **specific** custom look (e.g. custom dashboard CSS), and you want that to be the **default** for everyone on 2.5.5-dev, add it to the repo via a data migration or default static CSS as above.
No change is **required** for “same look” unless you want to ship a non-empty default cosmetic (e.g. your current dashboard CSS) as part of 2.5.5-dev.

76
to-do/V2.5.5-DEV-BRANCH-COMPATIBILITY.md
View File

@@ -1,76 +0,0 @@
# v2.5.5-dev Branch Compatibility Check
**Date:** 2026-02-04
**Branches compared:** [v2.5.5-dev](https://github.com/master3395/cyberpanel/tree/v2.5.5-dev) vs [v2.4.4](https://github.com/master3395/cyberpanel/tree/v2.4.4) vs [stable](https://github.com/master3395/cyberpanel/tree/stable)
---
## 1. Will your v2.5.5-dev changes work?
**Yes.** The Ban IP / Firewall Banned IPs changes on v2.5.5-dev are self-contained and consistent:
| Component | Status |
|-----------|--------|
| **plogical/firewallUtilities.py** | `blockIP` / `unblockIP` use `result == 1` for success; log file path is `/usr/local/CyberCP/data/blocked_ips.log` (writable by `cyberpanel`). |
| **plogical/processUtilities.py** | When running as root, `executioner` uses `normalExecutioner` return value (1 = success, 0 = fail). |
| **firewall/firewallManager.py** | `addBannedIP` uses `FirewallUtilities.blockIP`; ACL and errors return JSON with `error_message` and `error`; rollback on block failure. |
| **firewall/views.py** | `addBannedIP` parses JSON body and calls `fm.addBannedIP(userID, request_data)`. |
| **firewall/urls.py** | Routes `getBannedIPs`, `addBannedIP`, `modifyBannedIP`, `removeBannedIP`, `deleteBannedIP`, `exportBannedIPs`, `importBannedIPs` are present. |
| **baseTemplate/views.py** | `blockIPAddress` uses `FirewallUtilities.blockIP` (no subprocess). |
| **baseTemplate (homePage + system-status.js)** | Ban IP calls `/firewall/addBannedIP` with `ip`, `reason`, `duration`; shows server `error_message` in notifications. |
**Deployment requirements (already applied on your server):**
- `/usr/local/CyberCP/data` owned by `cyberpanel:cyberpanel` (for `banned_ips.json` and `blocked_ips.log`).
- Deploy updated files from v2.5.5-dev into `/usr/local/CyberCP/` and restart `lscpd`.
---
## 2. Does v2.5.5-dev have all functions from v2.4.4 and stable?
**Summary:**
- **v2.5.5-dev has more than v2.4.4 and stable** in terms of features (Banned IPs, FTP quotas, email limits, user management, bandwidth management, etc.). It is a development branch built on top of the same base.
- **v2.5.5-dev is missing a few items that exist only on stable** (backports or stable-only fixes). Nothing critical for the Ban IP feature; mainly scripts and tests.
### v2.5.5-dev has everything from v2.4.4 that matters
- v2.4.4 is older (fewer commits). v2.5.5-dev contains the same core apps (firewall, baseTemplate, loginSystem, backup, etc.) plus many additions.
- **Firewall:** v2.4.4 has no Banned IPs routes; v2.5.5-dev adds the full Banned IPs feature (getBannedIPs, addBannedIP, modify, remove, delete, export, import).
### v2.5.5-dev vs stable
- **Stable has ~86 files that differ from v2.5.5-dev**, including:
- **run_migration.py** – present on stable, **not** on v2.5.5-dev (migration helper).
- **test_firewall_blocking.py** – test script on stable.
- **rollback_phpmyadmin_redirect.sh** – rollback script on stable.
- **install/**, **plogical/** (e.g. mysqlUtilities, upgrade, backup, sslUtilities), **pluginInstaller** – some fixes/improvements on stable that may not be in v2.5.5-dev.
- **v2.5.5-dev has 3652+ files changed vs stable** – it has many more features (user management, website functions, bandwidth, FTP quotas, email limits, Banned IPs, etc.).
So:
- **Feature parity:** v2.5.5-dev has **all the main functions** from v2.4.4 and **adds** Banned IPs and other features. It does **not** lack core features that v2.4.4 or stable have.
- **Stable-only extras:** Stable has a few **extra** scripts/fixes (e.g. `run_migration.py`, `rollback_phpmyadmin_redirect.sh`, some plogical/install changes). If you need those, you can cherry-pick or merge from stable into v2.5.5-dev.
---
## 3. Directory layout comparison
| In stable, not in v2.5.5-dev (by name) | In v2.5.5-dev, not in stable |
|----------------------------------------|------------------------------|
| emailMarketing (or different layout) | bin, docs, modules, public, sql, test, to-do |
| examplePlugin | (v2.5.5-dev has more structure) |
| guides | |
| scripts | |
| testPlugin | test (different name) |
Your current repo (v2.5.5-dev) includes `emailMarketing`, `websiteFunctions`, `firewall`, `baseTemplate`, etc. The diff is mostly naming (e.g. test vs testPlugin) and stable having a few extra scripts/docs.
---
## 4. Recommendation
1. **Use v2.5.5-dev as-is for Ban IP and current features** – the changes are consistent and will work with the deployment steps above.
2. **Periodically merge or cherry-pick from stable** into v2.5.5-dev if you want stable’s migration script, phpMyAdmin rollback script, and any plogical/install fixes.
3. **You do have all the functions from v2.4.4 and stable** in the sense of core product behavior; v2.5.5-dev adds more (Banned IPs, etc.) and is only missing some optional stable-only scripts/fixes.

89
to-do/V2.5.5-DEV-FIXES-AND-DEPLOY.md
View File

@@ -1,89 +0,0 @@
# v2.5.5-dev: Fixes and Deploy Guide
This document lists fixes included in **v2.5.5-dev** and how to deploy them on a CyberPanel server.
---
## Version and cache busting
- **baseTemplate:** `CP_VERSION` in `baseTemplate/templates/baseTemplate/index.html` now uses `CYBERPANEL_FULL_VERSION` from context (from `baseTemplate/views.py`: `VERSION = '2.5.5'`, `BUILD = 'dev'`), so static URLs use `?v=2.5.5.dev` and cache busting matches the branch.
---
## 1. Email Limits page
- **Issue:** Raw Angular bindings (`{$ selectedEmail $}`) and `EmailLimitsNew` controller not registered.
- **Files:** `mailServer/mailserverManager.py`, `mailServer/templates/mailServer/EmailLimits.html`, `mailServer/static/mailServer/mailServer.js`, `mailServer/static/mailServer/emailLimitsController.js`, and mirrored under `static/mailServer/`.
- **Deploy:**
```bash
sudo bash /home/cyberpanel-repo/deploy-email-limits-fix.sh
```
- **Details:** See `to-do/EMAIL-LIMITS-DEPLOY-CHECKLIST.md`.
---
## 2. FTP Create Account page
- **Issue:** After selecting a website, the “FTP Account Details” form (username, password, path, quota) did not appear.
- **Files:** `ftp/templates/ftp/createFTPAccount.html` (inline script + polling + Angular scope sync), `ftp/static/ftp/ftp.js`, `static/ftp/ftp.js`, `public/static/ftp/ftp.js`.
- **Deploy:**
```bash
sudo bash /home/cyberpanel-repo/deploy-ftp-create-account-fix.sh
```
- **After deploy:** Hard-refresh `/ftp/createFTPAccount` (Ctrl+Shift+R).
---
## 3. FTP Quota Management page
- **Issue:** `(1146, "Table 'cyberpanel.ftp_quotas' doesn't exist")` on `/ftp/quotaManagement`.
- **Files:** `sql/create_ftp_quotas.sql`, `websiteFunctions/models.py` (FTPQuota model already present).
- **Deploy:**
```bash
sudo bash /home/cyberpanel-repo/deploy-ftp-quotas-table.sh
```
- **Details:** See `to-do/FTP-QUOTAS-TABLE-FIX.md`.
---
## 4. mailUtilities indentation fix
- **File:** `plogical/mailUtilities.py` (indentation fix in DNS query try/except block).
- **Deploy:** Copy to `/usr/local/CyberCP/plogical/mailUtilities.py` and restart lscpd if needed.
---
## Deploy all fixes (in order)
Run on the server (e.g. from repo root):
```bash
sudo bash deploy-email-limits-fix.sh
sudo bash deploy-ftp-create-account-fix.sh
sudo bash deploy-ftp-quotas-table.sh
```
Then hard-refresh the FTP Create Account page in the browser. No need to restart lscpd after the FTP quotas table script (it only runs SQL).
---
## Files changed / added in v2.5.5-dev (fixes)
| Path | Description |
|------|-------------|
| `baseTemplate/templates/baseTemplate/index.html` | CP_VERSION from CYBERPANEL_FULL_VERSION |
| `mailServer/` (Email Limits) | Controller, template, getEmailsForDomain permission |
| `ftp/templates/ftp/createFTPAccount.html` | Inline fallback + polling for details form |
| `ftp/static/ftp/ftp.js`, `static/ftp/ftp.js`, `public/static/ftp/ftp.js` | showFTPDetails, select2/change handlers |
| `websiteFunctions/models.py` | FTPQuota model (table created via sql script) |
| `sql/create_ftp_quotas.sql` | CREATE TABLE ftp_quotas |
| `plogical/mailUtilities.py` | DNS block indentation fix |
| `deploy-email-limits-fix.sh` | Deploy Email Limits fix |
| `deploy-ftp-create-account-fix.sh` | Deploy FTP Create Account template |
| `deploy-ftp-quotas-table.sh` | Create ftp_quotas table |
---
## Optional (not committed by default)
- **CyberCP/urls.py:** If `emailMarketing` is commented out for local runserver, leave it uncommitted or revert before pushing so production keeps the route.