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

cleanup

Browse source
This commit is contained in:
Frank Harris 2026-07-02 18:11:32 -05:00
parent a49371c3dd
commit 251af10faf
1190 changed files with 12636 additions and 12476 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/decisions/COMPANION_PROGRAMS_DESIGN.md
View file

@ -19,8 +19,8 @@ Note: the repository currently uses `Agent_Linux` on disk, not `Agent-Linux`.
Relevant files:
- `Agent_Linux/ogp_agent.pl`
- `Agent-Windows/ogp_agent.pl`
- `Agent_Linux/gsp_agent.pl`
- `Agent-Windows/gsp_agent.pl`
- `Panel/includes/lib_remote.php`
- `Panel/modules/gamemanager/mini_start.php`
- `Panel/modules/gamemanager/home_handling_functions.php`
@ -55,9 +55,9 @@ Both agents use `screen` as the shared runtime backend.
Linux:
- `create_screen_id(SCREEN_TYPE_HOME, $home_id)` creates names like `OGP_HOME_000000123`.
- `create_screen_id(SCREEN_TYPE_HOME, $home_id)` creates names like `GSP_HOME_000000123`.
- `create_screen_cmd(...)` returns a `screen -d -m -t ... -S ...` command.
- `create_screen_cmd_loop(...)` creates a generated shell script named like `OGP_HOME_000000123_startup_scr.sh`, then runs that script inside `screen`.
- `create_screen_cmd_loop(...)` creates a generated shell script named like `GSP_HOME_000000123_startup_scr.sh`, then runs that script inside `screen`.
- The generated shell script loops/restarts the server when autorestart is enabled.
- The script checks for `SERVER_STOPPED` before respawning.
@ -157,7 +157,7 @@ That flow is now present in the current agent files. Any companion system should
Current PID tracking exists but is inconsistent:
- The agents write their own `ogp_agent.pid`.
- The agents write their own `gsp_agent.pid`.
- FastDownload has `fd.pid`.
- Scheduler has `scheduler.pid`.
- Linux game server child PIDs are discovered from the screen PID with `pgrep -P`.
@ -196,7 +196,7 @@ There is no dedicated companion stdout/stderr log path today.
The clearest current companion behavior is Windows-only.
In `Agent-Windows/ogp_agent.pl`, `create_screen_cmd_loop(...)` generates `_serverStart.bat`. That generated batch file contains:
In `Agent-Windows/gsp_agent.pl`, `create_screen_cmd_loop(...)` generates `_serverStart.bat`. That generated batch file contains:
```bat
if exist "_alsoRun.bat" call "_alsoRun.bat"
@ -407,7 +407,7 @@ Payload should contain fully resolved, validated data:
"key": "bec",
"enabled": true,
"delay_seconds": 30,
"working_dir": "/home/ogp_agent/OGP_User_Files/123/BEC",
"working_dir": "/home/gsp_agent/GSP_User_Files/123/BEC",
"command": "Bec.exe",
"args": ["-f", "Config.cfg"],
"stdout_log": "bec.out.log",
@ -427,12 +427,12 @@ Recommended approach:
- Use separate `screen` sessions per companion.
- Session naming:
- Game: `OGP_HOME_000000123`
- Companion: `OGP_COMPANION_000000123_bec`
- Game: `GSP_HOME_000000123`
- Companion: `GSP_COMPANION_000000123_bec`
- Write companion runtime state under an agent-controlled path outside the game FTP/file-manager root.
- Start delayed companions through a small agent-owned delay wrapper:
- Linux: `screen -d -m -S OGP_COMPANION_... bash -lc 'sleep 30; cd ...; exec ...'`
- Windows/Cygwin: `screen -d -m -S OGP_COMPANION_... cmd /Q /C "timeout /t 30 ... && cd /d ... && ..."`
- Linux: `screen -d -m -S GSP_COMPANION_... bash -lc 'sleep 30; cd ...; exec ...'`
- Windows/Cygwin: `screen -d -m -S GSP_COMPANION_... cmd /Q /C "timeout /t 30 ... && cd /d ... && ..."`
This avoids blocking game startup. The Panel can show the game as `STARTING`/`ONLINE` independently while companion statuses move through `PENDING`, `STARTING`, `RUNNING`, or `FAILED`.
@ -693,7 +693,7 @@ Linux can use:
Recommended Linux companion launch:
```text
screen -d -m -S OGP_COMPANION_<home_id>_<key> bash -lc '<agent-owned wrapper>'
screen -d -m -S GSP_COMPANION_<home_id>_<key> bash -lc '<agent-owned wrapper>'
```
Use an agent-owned wrapper or direct fork/exec to record PID and redirect logs.
@ -714,7 +714,7 @@ Current `_alsoRun.bat` depends on WMIC in some XML. WMIC is not reliable on all
Recommended Windows companion launch:
```text
screen -d -m -S OGP_COMPANION_<home_id>_<key> cmd /Q /C "<agent-owned wrapper.bat>"
screen -d -m -S GSP_COMPANION_<home_id>_<key> cmd /Q /C "<agent-owned wrapper.bat>"
```
The wrapper should record the Windows PID or enough process/session information for cleanup.

10
docs/decisions/SCHEDULER_ACTIONS_DESIGN.md
View file

@ -42,8 +42,8 @@ Panel remote/API integration:
Agent scheduler implementation:
- `Agent_Linux/ogp_agent.pl`
- `Agent-Windows/ogp_agent.pl`
- `Agent_Linux/gsp_agent.pl`
- `Agent-Windows/gsp_agent.pl`
### Current database tables used
@ -97,7 +97,7 @@ Customer task creation path:
2. User selects a game server and action.
3. Panel validates the five CRON fields using `checkCronInput()`.
4. Panel calls `build_cron_scheduler_command()`.
5. The command is built as a `wget` callback to `ogp_api.php`.
5. The command is built as a `wget` callback to `gsp_api.php`.
6. Panel sends the whole CRON line to the agent through `scheduler_add_task()`.
7. Agent appends the task line to `scheduler.tasks`.
8. Agent restarts its scheduler process.
@ -112,11 +112,11 @@ Admin task creation path:
Current scheduled API callback examples:
```text
wget -qO- "<panel>/ogp_api.php?gamemanager/stop&token=<token>&ip=<ip>&port=<port>&mod_key=<mod_key>" --no-check-certificate > /dev/null 2>&1
wget -qO- "<panel>/gsp_api.php?gamemanager/stop&token=<token>&ip=<ip>&port=<port>&mod_key=<mod_key>" --no-check-certificate > /dev/null 2>&1
```
```text
wget -qO- "<panel>/ogp_api.php?server_content/run_scheduled_action&token=<token>&home_id=<home_id>&action=<action>&options=<json>" --no-check-certificate > /dev/null 2>&1
wget -qO- "<panel>/gsp_api.php?server_content/run_scheduled_action&token=<token>&home_id=<home_id>&action=<action>&options=<json>" --no-check-certificate > /dev/null 2>&1
```
### How tasks execute

12
docs/decisions/STEAM_WORKSHOP_DESIGN.md
View file

@ -155,7 +155,7 @@ Relevant methods:
There are two Workshop paths:
1. Legacy agent RPC:
- Panel method: `OGPRemoteLibrary::steam_workshop(...)`
- Panel method: `GSPRemoteLibrary::steam_workshop(...)`
- Agent subroutine: `steam_workshop_without_decrypt(...)`
- Runs SteamCMD in a screen update session.
- Generates post-install shell snippets that edit a config file.
@ -172,20 +172,20 @@ The second path is cleaner for future Server Content work because it is manifest
Linux agent:
- File: `Agent_Linux/ogp_agent.pl`
- File: `Agent_Linux/gsp_agent.pl`
- SteamCMD path constants:
- `AGENT_RUN_DIR/steamcmd`
- `steamcmd.sh`
- `check_steam_cmd_client` downloads and installs SteamCMD if missing.
- `steam_cmd_without_decrypt` creates a SteamCMD runscript and runs it in a screen update session.
- `steam_workshop_without_decrypt` creates a SteamCMD runscript containing `workshop_download_item` lines and runs it in a screen update session.
- `get_workshop_mods_info` reads `.ogpmod` files from `AGENT_RUN_DIR/WorkshopModsInfo`.
- `get_workshop_mods_info` reads `.gspmod` files from `AGENT_RUN_DIR/WorkshopModsInfo`.
Windows/Cygwin agent:
- File: `Agent-Windows/ogp_agent.pl`
- File: `Agent-Windows/gsp_agent.pl`
- SteamCMD path constants:
- `/OGP/steamcmd`
- `/GSP/steamcmd`
- `steamcmd.exe`
- `steam_cmd_without_decrypt` uses Cygwin path conversion for `force_install_dir`.
- `steam_workshop_without_decrypt` uses Cygwin path conversion for the mods path and the SteamCMD runscript.
@ -692,7 +692,7 @@ Example:
"manifest_version": 2,
"job_uuid": "uuid",
"home_id": 123,
"home_path": "/home/ogp_agent/OGP_User_Files/123",
"home_path": "/home/gsp_agent/GSP_User_Files/123",
"provider": "steam",
"action": "install_update",
"strategy": "dayz_mod_folder",