nearxos
0375b20bb4
- Added configuration options for requiring human approval before applying LLM-generated MCP patches. - Updated Docker setup to include skills directory. - Integrated skills management into the backend, allowing for procedural guides and skill matching. - Refactored database initialization to apply Alembic migrations. - Enhanced task approval process to handle MCP patch applications with optional approval. - Introduced new schemas for skills and updated existing APIs to support skills functionality. This commit lays the groundwork for improved agent capabilities and better management of MCP development processes.
2.7 KiB
2.7 KiB
id, name, description, priority, rule_ids, match
| id | name | description | priority | rule_ids | match | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| vessel-dns-portal | Vessel DNS and captive portal | Crew/business DNS slowness, ship-dns upstream timeouts, captive portal auth, RADIUS, and hairpin portal access on GeneseasX stacks. | 85 |
|
|
Vessel DNS and captive portal
Architecture (typical GeneseasX)
- pfSense is the DNS gateway for crew/business — redirects UDP/53 per segment.
- Do NOT hand crew/business the Docker VM IP (
10.20.30.222) as DNS directly. - ship-dns container on Docker VM resolves upstream; misconfigured primary = multi-second delays.
- Captive portal on CREW VLAN: pfSense CP + RADIUS back to Docker stack.
Crew DNS slow (ship-dns)
Known root cause: primary upstream unreachable from Docker VM → every query waits full timeout before fallback.
| Symptom | Likely cause |
|---|---|
| ~3s per lookup | Primary (e.g. 1.1.1.1) blocked; fallback works after timeout |
| Fast after fix | Primary 8.8.8.8, secondary 9.9.9.9, dns_timeout=2 |
Investigation order:
- Docker VM:
docker ps— ship-dns container healthy - Docker VM: time lookups per upstream (
dig @1.1.1.1,@8.8.8.8,@9.9.9.9) - ship-dns config: primary/secondary/timeout, worker concurrency
- pfSense: crew/business DNS redirect points at pfSense, not Docker IP
Persistence warning: in-place edits inside ship-dns container revert on image recreate. Fixes belong in the image/build, not only docker cp.
Captive portal / crew internet
Flow: crew device → pfSense captive portal → RADIUS auth → Docker RADIUS/portal containers.
| Symptom | Check |
|---|---|
| Portal page won't load | Hairpin / NAT reflection: crew → pfSense:443 → Docker portal |
| Auth fails | RADIUS reachability (auth/acct ports) to Docker stack |
| Authenticated but no service | Missing pass rules on CREW for new services (e.g. VoIP added later) |
Investigation order:
- pfSense: captive portal zone status, CREW floating + interface rules
- pfSense: 443 portal redirect, NAT reflection, RADIUS pass rules to Docker
- Docker VM: portal + RADIUS container health and logs on failed auth
pfSense interface roles (confirm live)
- CREW (
vtnet2): isolated, captive portal, floating rules - Business (
vtnet3): restrictive pass (DNS/HTTPS/SIP) - Management (
vtnet4): usually permissive
Evidence to capture
- Per-upstream DNS timing from Docker VM
- ship-dns effective resolver settings
- pfSense CP + RADIUS rule list
- Portal/RADIUS container logs for failed login attempts