diff --git a/to-do/AWS-CURSOR-REMOTE-SSH-SETUP.md b/to-do/AWS-CURSOR-REMOTE-SSH-SETUP.md deleted file mode 100644 index b62b92e8e..000000000 --- a/to-do/AWS-CURSOR-REMOTE-SSH-SETUP.md +++ /dev/null @@ -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). diff --git a/to-do/EMAIL-LIMITS-DEPLOY-CHECKLIST.md b/to-do/EMAIL-LIMITS-DEPLOY-CHECKLIST.md deleted file mode 100644 index 779548dab..000000000 --- a/to-do/EMAIL-LIMITS-DEPLOY-CHECKLIST.md +++ /dev/null @@ -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. diff --git a/to-do/EMAIL-LIMITS-LIVE-SERVER-CHECKLIST.md b/to-do/EMAIL-LIMITS-LIVE-SERVER-CHECKLIST.md deleted file mode 100644 index 70fc18670..000000000 --- a/to-do/EMAIL-LIMITS-LIVE-SERVER-CHECKLIST.md +++ /dev/null @@ -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. diff --git a/to-do/FIREWALL-BANNED-IPS-DATABASE-AND-BAN-PERMANENTLY.md b/to-do/FIREWALL-BANNED-IPS-DATABASE-AND-BAN-PERMANENTLY.md deleted file mode 100644 index 47337a507..000000000 --- a/to-do/FIREWALL-BANNED-IPS-DATABASE-AND-BAN-PERMANENTLY.md +++ /dev/null @@ -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. -``` diff --git a/to-do/FTP-QUOTA-BROWSER-TEST-CHECKLIST.md b/to-do/FTP-QUOTA-BROWSER-TEST-CHECKLIST.md deleted file mode 100644 index f9250e0fd..000000000 --- a/to-do/FTP-QUOTA-BROWSER-TEST-CHECKLIST.md +++ /dev/null @@ -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 -``` diff --git a/to-do/FTP-QUOTAS-TABLE-FIX.md b/to-do/FTP-QUOTAS-TABLE-FIX.md deleted file mode 100644 index 99f3160ea..000000000 --- a/to-do/FTP-QUOTAS-TABLE-FIX.md +++ /dev/null @@ -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. diff --git a/to-do/INSTALL-UPGRADE-DOWNGRADE-COMMANDS.md b/to-do/INSTALL-UPGRADE-DOWNGRADE-COMMANDS.md deleted file mode 100644 index ccec277aa..000000000 --- a/to-do/INSTALL-UPGRADE-DOWNGRADE-COMMANDS.md +++ /dev/null @@ -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 `. diff --git a/to-do/MARIADB-11.8-LTS-UPGRADE.md b/to-do/MARIADB-11.8-LTS-UPGRADE.md deleted file mode 100644 index 5946fb548..000000000 --- a/to-do/MARIADB-11.8-LTS-UPGRADE.md +++ /dev/null @@ -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 diff --git a/to-do/MARIADB_INSTALLATION_FIXES.md b/to-do/MARIADB_INSTALLATION_FIXES.md deleted file mode 100644 index f133868d3..000000000 --- a/to-do/MARIADB_INSTALLATION_FIXES.md +++ /dev/null @@ -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 diff --git a/to-do/OLD-REPO-CHECKLIST-BEFORE-REMOVAL.md b/to-do/OLD-REPO-CHECKLIST-BEFORE-REMOVAL.md deleted file mode 100644 index 906cf1be3..000000000 --- a/to-do/OLD-REPO-CHECKLIST-BEFORE-REMOVAL.md +++ /dev/null @@ -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 diff --git a/to-do/OPENLITESPEED-VERSION-INSTALL-UPGRADE.md b/to-do/OPENLITESPEED-VERSION-INSTALL-UPGRADE.md deleted file mode 100644 index 5846b78d1..000000000 --- a/to-do/OPENLITESPEED-VERSION-INSTALL-UPGRADE.md +++ /dev/null @@ -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`. diff --git a/to-do/PANEL-ACCESS-PLUGIN-STORE.md b/to-do/PANEL-ACCESS-PLUGIN-STORE.md deleted file mode 100644 index 34949d496..000000000 --- a/to-do/PANEL-ACCESS-PLUGIN-STORE.md +++ /dev/null @@ -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. diff --git a/to-do/PLUGIN-DEFAULT-REMOVAL-2026-02-01.md b/to-do/PLUGIN-DEFAULT-REMOVAL-2026-02-01.md deleted file mode 100644 index 302845ded..000000000 --- a/to-do/PLUGIN-DEFAULT-REMOVAL-2026-02-01.md +++ /dev/null @@ -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. diff --git a/to-do/PURE-FTPD-QUOTA-SYNTAX-FIX.md b/to-do/PURE-FTPD-QUOTA-SYNTAX-FIX.md deleted file mode 100644 index 09dba530a..000000000 --- a/to-do/PURE-FTPD-QUOTA-SYNTAX-FIX.md +++ /dev/null @@ -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 `. diff --git a/to-do/REPO-MERGE-2026-02-02.md b/to-do/REPO-MERGE-2026-02-02.md deleted file mode 100644 index 9497772be..000000000 --- a/to-do/REPO-MERGE-2026-02-02.md +++ /dev/null @@ -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 -``` diff --git a/to-do/REVERSE-PROXY-DOMAIN-CSRF.md b/to-do/REVERSE-PROXY-DOMAIN-CSRF.md deleted file mode 100644 index ba71d956f..000000000 --- a/to-do/REVERSE-PROXY-DOMAIN-CSRF.md +++ /dev/null @@ -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). diff --git a/to-do/RUNTIME-VS-REPO-2.5.5-DEV.md b/to-do/RUNTIME-VS-REPO-2.5.5-DEV.md deleted file mode 100644 index d272848f7..000000000 --- a/to-do/RUNTIME-VS-REPO-2.5.5-DEV.md +++ /dev/null @@ -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': ''})` - 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. diff --git a/to-do/V2.5.5-DEV-BRANCH-COMPATIBILITY.md b/to-do/V2.5.5-DEV-BRANCH-COMPATIBILITY.md deleted file mode 100644 index 733f3c90a..000000000 --- a/to-do/V2.5.5-DEV-BRANCH-COMPATIBILITY.md +++ /dev/null @@ -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. diff --git a/to-do/V2.5.5-DEV-FIXES-AND-DEPLOY.md b/to-do/V2.5.5-DEV-FIXES-AND-DEPLOY.md deleted file mode 100644 index b58f4721a..000000000 --- a/to-do/V2.5.5-DEV-FIXES-AND-DEPLOY.md +++ /dev/null @@ -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.