GSP/Panel
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update dix

Browse source
This commit is contained in:
Frank Harris 2026-06-06 14:21:58 -05:00
parent e921a49d5b
commit 11691a5876
11 changed files with 1108 additions and 54 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/agents/LINUX_AGENT.md
View file

@ -106,6 +106,24 @@ Useful configuration and runtime areas:
The agent also maintains screen logs and helper scripts inside its runtime area.
## Remote Git Self-Update
The Linux agent exposes the admin-only `component_update` XML-RPC method. The Panel update page uses this to queue a Git-based Linux agent update.
Flow:
1. Panel sends an encrypted payload containing repo URL, branch, source folder, optional Git path, optional backup path, and optional admin post-update command.
2. Agent validates the payload.
3. Agent writes `gsp_component_update_<timestamp>.sh` under the agent run directory.
4. The updater script runs detached in `screen`.
5. The script clones the configured branch into staging.
6. It copies only the configured Linux agent source folder, usually `Agent_Linux`.
7. It preserves `Cfg/`, `ServerFiles/`, `Schedule/`, logs, screen logs, `steamcmd/`, `startups/`, temporary folders, backups, and PID files.
8. It validates the updated `ogp_agent.pl` with `perl -c`.
9. It restarts `ogp_agent.service` through `systemd` if available, otherwise uses the existing `screen` startup fallback.
The agent returns `queued` immediately with the log path `gsp_component_update.log`. A queued response means the updater launched; check the log for final success/failure.
## Linux-Specific Notes
- The Linux agent uses `screen` and `sudo_exec_without_decrypt`.

17
docs/agents/WINDOWS_AGENT.md
View file

@ -123,6 +123,23 @@ Relevant functions:
The Windows scheduler implementation should remain aligned with the Linux scheduler implementation so the Panel can treat both the same way.
## Remote Git Self-Update
The Windows agent exposes the same admin-only `component_update` XML-RPC method as the Linux agent. In this repository the Windows agent is explicitly Cygwin-based, so the first implementation uses a Cygwin-compatible detached shell updater rather than a separate native PowerShell service wrapper.
Flow:
1. Panel sends an encrypted payload containing repo URL, branch, Windows agent source folder, optional Git path, optional backup path, and optional admin post-update command.
2. Agent validates the request and writes `gsp_component_update_<timestamp>.sh` under the current agent run directory, usually `/OGP`.
3. The updater runs detached in `screen`.
4. The updater clones the configured branch into staging.
5. It copies only the configured Windows agent source folder, usually `Agent-Windows`.
6. It preserves `Cfg/`, `ServerFiles/`, `Schedule/`, logs, screen logs, `steamcmd/`, `startups/`, temporary folders, backups, and PID files.
7. It validates `ogp_agent.pl` with `perl -c`.
8. It restarts the agent using the existing Cygwin/screen fallback.
The immediate response is `queued` with the agent-side log path `gsp_component_update.log`.
## Windows-Specific Notes
- Path conversion between Cygwin and native Windows paths matters during startup.

18
docs/architecture/API_REFERENCE.md
View file

@ -55,6 +55,7 @@ Panel module
| `start_fastdl` / `stop_fastdl` / `restart_fastdl` / `fastdl_status` | FastDL service management | `fast_download` | Source/GoldSrc web distribution support. |
| `scheduler_*` methods | Task list and task CRUD | `cron` | Agent-owned scheduler implementation. |
| `agent_restart` | Restart the agent itself | Admin maintenance | Node maintenance action. |
| `component_update` | Queue a Git-based agent code update | Update module | Admin-only. Uses encrypted XML-RPC, validates repo/branch/source/destination, launches a detached updater, preserves agent config/runtime/server data, and returns queued status plus an agent log path. |
| `shell_action` | Run a shell action in a controlled way | Advanced agent operations | Should remain tightly permissioned. |
| `send_steam_guard_code` | Submit Steam Guard code | Steam authenticated installs | Used for authenticated SteamCMD workflows. |
| `steam_workshop` / `get_workshop_mods_info` | Workshop-related helper calls | Workshop/content flows | Active in current module work, but still being consolidated. |
@ -140,6 +141,23 @@ Panel
-> refresh dedicated preformatted log panel via AJAX
```
### Remote Agent Component Update
```text
Panel update page
-> component_update(payload)
Agent
-> validate repo, branch, source folder, destination
-> write detached updater script
-> return queued + log path
Updater script
-> clone/fetch repository into staging
-> copy Agent_Linux or Agent-Windows folder only
-> preserve Cfg, ServerFiles, Schedule, logs, steamcmd, startups, pid files
-> validate ogp_agent.pl
-> restart agent through systemd or screen fallback
```
## Error Handling Notes
- Do not treat query failure as a start failure by itself.

10
docs/development/CODEX_GUIDE.md
View file

@ -124,6 +124,16 @@ This file is the first stop for future Codex sessions working in this repository
3. Check the user/admin content pages.
4. Check whether the action should be treated as install, update, or uninstall.
### Debug Panel or Agent updates
1. Read `docs/modules/UPDATE.md`.
2. Check `Panel/modules/update/update.php`.
3. Check `Panel/modules/administration/panel_update.php`.
4. Check `Panel/includes/lib_remote.php` for the `component_update` wrapper.
5. Check both `Agent_Linux/ogp_agent.pl` and `Agent-Windows/ogp_agent.pl` for the `component_update` RPC.
6. Remember that local Panel/Website updates and remote agent updates both clone a configured Git branch into staging and copy only configured component folders.
7. Never let updater logic delete server homes, game install folders, user data, agent `Cfg/`, logs, uploads, backups, or runtime PID files.
## Things Already Investigated
The repository has already been mapped in these areas:

58
docs/modules/UPDATE.md
View file

@ -26,6 +26,14 @@ The admin page stores these settings in the Panel settings table:
- `gsp_update_branch`
- `gsp_update_repo_root`
- `gsp_update_panel_path`
- `gsp_update_website_path`
- `gsp_update_panel_source_path`
- `gsp_update_linux_agent_source_path`
- `gsp_update_windows_agent_source_path`
- `gsp_update_website_source_path`
- `gsp_update_git_path`
- `gsp_update_backup_path`
- optional admin-only post-update commands per component
- `gsp_update_backup_before`
Defaults:
@ -34,6 +42,11 @@ Defaults:
- Branch: `Panel-unstable`
- Repository Root: `/var/www/html/GSP`
- Panel Path: `/var/www/html/GSP/Panel`
- Website Path: `/var/www/html/GSP/Website`
- Panel Source Folder: `Panel`
- Linux Agent Source Folder: `Agent_Linux`
- Windows Agent Source Folder: `Agent-Windows`
- Website Source Folder: `Website`
- Backup Before Update: enabled
Important implementation note:
@ -41,6 +54,7 @@ Important implementation note:
- `gsp_update_settings()` and `gsp_validate_update_settings()` are defined at top level in `Panel/modules/administration/panel_update.php`.
- These helpers must not be nested inside another function. A previous bad edit placed `gsp_update_settings()` inside `gsp_get_git_commit()`, which caused a fatal error when the update page called the helper before `gsp_get_git_commit()` had ever executed.
- If the update page throws `Call to undefined function gsp_update_settings()`, first verify the deployed `Panel/modules/administration/panel_update.php` matches the repository version and that this helper exists near the top of the file before `gsp_panel_update_section()` is called.
- `gsp_do_configured_git_update()` must also remain top-level. A bad edit placed it inside `gsp_do_update()`, so `/home.php?m=update` called an undefined function until a legacy GitHub update path happened to execute first.
## Update Flow
@ -54,6 +68,49 @@ Important implementation note:
8. Run module updates/post-update hooks.
9. Write version metadata and `LAST_UPDATE.txt`.
## Component Updates
The update page can update selected components from one repository:
- Panel files
- Website files
- Linux agents
- Windows/Cygwin agents
Local Panel/Website updates clone the configured repository into a temporary checkout and copy only the configured component source folder into the configured destination path. Protected folders and files are not overwritten:
- `includes/config.inc.php`
- `Cfg/`
- `ServerFiles/`
- `Schedule/`
- `logs/`
- `screenlogs/`
- `cache/`
- `tmp/`
- `uploads/`
- `backups/`
- `steamcmd/`
- `startups/`
- PID files
Remote agent updates use the encrypted Panel-Agent XML-RPC channel and the `component_update` RPC. The agent writes a detached updater script, clones the repo to staging, backs up the current agent code, copies only the configured agent source folder, validates `ogp_agent.pl`, then restarts through `systemd` when available or the existing `screen` fallback.
Remote update status is queued/asynchronous. The first response confirms that the update was accepted and gives the agent-side log path.
Remote updates require PHP XML-RPC on the Panel host. If the extension is missing, the update page still loads and reports a clean `missing_xmlrpc` error when a remote agent update is requested.
## Smoke Tests
Useful validation commands:
```bash
php -l Panel/modules/administration/panel_update.php
php -l Panel/modules/update/update.php
php -l Panel/includes/lib_remote.php
php Panel/modules/update/tests/update_config_smoke.php
perl -c ogp_agent.pl # run from each installed agent directory with dependencies present
```
## Diagnostics
Apache and SSL checks are diagnostics only. Missing SSL certificates do not block Panel updates.
@ -68,6 +125,7 @@ The old repeated SSL vhost disable buttons are not part of the primary update pa
## Repair Notes
- The update page fatal `Call to undefined function gsp_update_settings()` means the deployed `Panel/modules/administration/panel_update.php` is missing the top-level helper or is not the current repository copy.
- The update page fatal `Call to undefined function gsp_do_configured_git_update()` means the configured Git update helper is missing or nested inside another helper in the deployed `panel_update.php`.
- `Panel/modules/update/update.php` only loads `Panel/modules/administration/panel_update.php` and calls `gsp_panel_update_section()`.
- The configured update action uses `git clone --depth 1 --branch <configured branch> <configured repository source> <temporary checkout>`.
- Clone failures are logged to `logs/update_trace.log` with the configured repository source and branch.

16
docs/modules/update.md
View file

@ -43,13 +43,27 @@ Panel update and patch management.
## Missing Functionality
- clearer update history and rollback guidance
- richer update history and rollback guidance
- live progress polling for asynchronous remote agent updates
## Suggested Future Improvements
- keep admin-only and document carefully
- add status polling for `component_update` logs after the agent has restarted
## Recommendation
- Keep
## Current GSP Additions
The primary update implementation lives in `Panel/modules/administration/panel_update.php` and is exposed by `Panel/modules/update/update.php`.
Current update targets:
- Panel files
- Website files
- Linux agents
- Windows/Cygwin agents
The updater uses a single configured Git repository with component source folders such as `Panel`, `Website`, `Agent_Linux`, and `Agent-Windows`. Remote agents are updated through the encrypted `component_update` XML-RPC method and preserve hosted game data and agent configuration folders.