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.