Brain

# GLPI Bot Runner Implementation Implemented a v1 GLPI bot workflow on `svc-auto` with a trusted execution backend and live GLPI, docs, and `brain` integration. ## Deployment - Host: `svc-auto` - Path: `/home/svc-admin/docker/glpi-bot-runner` - Service: `glpi-bot-runner` - Architecture doc: `docs/architecture/glpi-bot-runner.md` ## What it does - Authenticates to GLPI v2 with OAuth password grant - Polls GLPI tickets in category `Automation > Homelab Bot` - Requires `homelab-bot` assignment via TeamMember role `assigned` - Posts a claimed follow-up - Moves the ticket to `In Progress` - Parses a structured YAML bot spec from the ticket body - Executes only trusted built-in actions - Writes a Markdown artifact into the homelab documentation repo - Stores a matching memory in `brain` - Posts a professional completion-style follow-up - Moves the ticket to `Solved` on success or `Pending` on blocked/invalid work ## Current execution mode `EXECUTOR_MODE=trusted_dispatch` Supported actions now verified in live tickets: - `http_check` - `docker_compose_remote` - `path_exists` - `docker_container_check` - `systemd_remote` The dispatcher does not execute arbitrary shell from ticket text. `docker_compose_remote` is constrained by host, path, and action allowlists. ## Files - `/home/svc-admin/docker/glpi-bot-runner/docker-compose.yml` - `/home/svc-admin/docker/glpi-bot-runner/.env` - `/home/svc-admin/docker/glpi-bot-runner/app/` - `/home/svc-admin/docker/glpi-bot-runner/templates/` - `/home/svc-admin/homelab-doc-sync/homelab-documentation-system/docs/architecture/glpi-bot-runner.md` ## GLPI structure created - Category: `Automation` - Category: `Automation > Homelab Bot` - Followup template: `Bot Claimed - Homelab` - Followup template: `Bot Blocked - Homelab` - Followup template: `Bot Completion - Homelab` ## Operational decisions and fixes - GLPI v2 ticket creation needs `category: {id: 2}`; using `itilcategories_id` did not populate the category field the runner filters on. - `GLPI_ALLOWED_STATUS_IDS` was tightened to `1` so already-claimed tickets are not reprocessed every poll cycle. - `path_exists` and `systemd_remote` now force host execution over SSH instead of using the local-container fast path. - `systemd_remote` uses `sudo -n` and `systemctl --no-pager` for unattended execution. - `svc-auto` needed `22/tcp` allowed from the runner bridge subnet `172.23.0.0/16` so SSH-based same-host actions could reach the host from the container. - `svc-auto` also needed its local `~/.ssh/id_ed25519.pub` added to `authorized_keys` so the runner container's mounted key could authenticate back to the host. - `workflow.py` was fixed to import `ExecutionResult` in the exception path. ## Validation Validated live against GLPI and the runner. - Ticket `3` proved the lifecycle and artifact path in pending mode. - Ticket `4` proved invalid specs are blocked cleanly. - Ticket `5` executed a real `http_check` action, posted follow-ups, wrote `docs/generated/glpi-bot/ticket-5.md`, stored a `brain` memory, and moved to `Solved`. - Ticket `11` executed `docker_compose_remote` successfully and moved to `Solved`. - Ticket `12` executed `path_exists` successfully and moved to `Solved`. - Ticket `14` executed `docker_container_check` successfully and moved to `Solved`. - Ticket `15` executed `systemd_remote` successfully and moved to `Solved`. - Ticket `13` captured the pre-fix `systemd_remote` failure mode and remains a useful artifact for the earlier local-container/SSH routing issue. ## Next step Add more trusted actions as explicit handlers rather than allowing arbitrary command execution from ticket text.