sam/dev_arc_aws
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Verify Telnet and RDP remote-desktop paths end-to-end through guacd

Browse source 
Closes the last Phase 5 coverage gap: ran a real telnetd (via socat) and a real
xrdp server (with the libguac-client-rdp plugin), created telnet/rdp
remote_desktop integrations, and confirmed guacd negotiated both connections
and returned real Guacamole protocol instructions over /api/guacamole. All three
protocols (VNC, telnet, RDP) now verified against the identical route code.

Documentation only; no code changes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BbJV5nm8KPVH1oNJYKpnoF
This commit is contained in:
Claude 2026-06-19 16:08:16 +00:00
parent a2af06f925
commit 92640d0777
No known key found for this signature in database
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
TERMIX_MIGRATION.md
View file

@ -128,7 +128,7 @@ One real bug was caught and fixed during this verification: `openExecStream()` o
One real bug was caught and fixed during this browser verification: the page initially called `client.connect()` with no arguments while the tunnel URL already had `token=...&integrationId=...` appended, producing a malformed `...&integrationId=1?undefined` URL and an `ECONNREFUSED`-style failure. Root cause (confirmed by reading `Guacamole.WebSocketTunnel`'s source): it always appends its own `"?" + data` itself. Fixed by passing a bare tunnel URL and moving the query data into the `client.connect(data)` call.
**Documented gaps**:
- Telnet was not verified — no real telnet server could be installed in this sandbox (`telnetd`/`inetutils-telnetd` 404'd against the available `apt` mirror snapshot). RDP was not verified either (no real RDP target was available); only the VNC path has a live, browser-confirmed end-to-end test. The route code path is identical across all three protocols (same `ClientConnection`/`guacd` flow, differing only in the `connection.type` and per-protocol settings), so this is a coverage gap rather than a known defect.
- ~~Telnet and RDP were not verified~~ **(now done)**: with the `apt` mirror cooperating on a later attempt, both paths were verified end-to-end through the exact same `/api/guacamole` route. **Telnet**: ran a real `inetutils-telnetd` (bridged to a listening port via `socat`), created a `remote_desktop`/`telnet` integration, and drove the websocket — guacd logged `Telnet connection successful` and returned real Guacamole instructions (`4.size,...`). **RDP**: ran a real `xrdp` server (after installing the `libguac-client-rdp0` plugin guacd needs), created a `remote_desktop`/`rdp` integration, and confirmed guacd negotiated the connection and returned a `4.size,1.0,4.1024,3.768` display surface. All three protocols (VNC from the original pass, plus telnet and RDP now) are confirmed against the identical code path. All test artifacts (guacd, telnetd/socat, xrdp, test user, test backend/DB) were cleaned up afterward.
- ~~`guacd` is not yet added to a `docker-compose.yml`~~ **(now done)**: `docker-compose.yml` gained a `guacd` service (`guacamole/guacd:1.5.5`, no published port — only the backend reaches it on the compose network), the backend service now sets `ARCHNEST_GUACD_HOST=guacd`/`ARCHNEST_GUACD_PORT=4822` + `ARCHNEST_GUAC_CRYPT_KEY` and `depends_on: [guacd]`, and `backend/.env.example` documents the `ARCHNEST_GUACD_*` vars for local dev. Verified the compose file parses cleanly via `docker compose config` (the Docker daemon isn't running in this sandbox, so an actual `up` was not performed).
- All test artifacts (test `guacd`/`vncserver` processes, test backend instance, test DB, tokens, temp files, Playwright scripts) were cleaned up afterward.