diff --git a/REQUESTS.md b/REQUESTS.md index bf5fba3..1c73afe 100644 --- a/REQUESTS.md +++ b/REQUESTS.md @@ -5,9 +5,6 @@ is blocking: as at **21 August 2026** the assistant runs end to end on `lin001` resolution, the data translator, document search, all four answer lanes, the rulebook, the working panel and the logbook are all live and were exercised by hand on the host. -**Item 4 was found on 27 August 2026 while verifying item 2 and is the smallest of the -four — one DNS record — but it blocks the operator demo completely.** - **Item 2 was delivered on 27 August 2026 and is closed** — it is kept below as a record of what was asked for and what arrived. What is still missing is the AI model itself and real plant data. Both depend on someone outside this project and neither can be hurried at the @@ -22,7 +19,6 @@ Item 3 needs the owner of the `imh` historian, who is not yet identified. | 1 | Azure OpenAI account, 3 deployments | The two AI steps — classifying the question, wording the answer | Phases 6, 8; the safety review | | 2 | ~~Three public DNS records + DC pinpoint records~~ | Reaching the assistant by name from a control-room PC | **Delivered 27 Aug 2026 — closed** | | 3 | Read-only login to the `imh` historian | Real plant figures instead of stand-ins | Phases 4, 5; every data answer | -| 4 | One more DC pinpoint record: `auth.yokogawa.tech` | Signing in from a control-room PC at all | Phase 7; any operator demo | --- @@ -128,47 +124,6 @@ when a person outside this project opens a browser. It also depends on two diffe --- -## 4. One more pinpoint record on the DC: `auth.yokogawa.tech` - -### What is needed - -**`auth.yokogawa.tech` → `10.0.0.17`** on the domain controller, the same treatment -`ai.yokogawa.tech` and `influx.yokogawa.tech` already have. Contact: **Daniel Watson**. - -Nothing else. No public record — `auth.yokogawa.tech` already resolves publicly and works. - -### What it is for - -Signing in. The DC is authoritative for a `yokogawa.tech` zone that contains pinpoint -records only, so from inside the VNet every name **not** in that zone is NXDOMAIN — not -forwarded to public DNS. `ai` and `influx` are in it. `auth` is not. - -An operator at `cicore1` therefore gets: `ai.yokogawa.tech` resolves to `10.0.0.17`, Caddy -answers, Authelia redirects the browser to `https://auth.yokogawa.tech/?rd=...`, and the -browser cannot resolve it. The assistant is reachable and cannot be logged into. - -### Why it was not caught earlier - -Every other service behind Authelia is reached from the internet, where `auth` resolves -normally. `influx.yokogawa.tech` is the one exception with a pinpoint record, and LAN -traffic to it uses the **bypassed** API paths — `^/api/v2/write`, `^/api/v2/query`, -`^/health` — which never touch the portal. `ai.yokogawa.tech` is the first thing on this -host that a LAN client must interactively sign in to. - -Duo is unaffected: Authelia calls the Duo API server-side from `lin001`, so the browser -never needs to reach `duosecurity.com`. - -### How to confirm it is fixed - -On the SCADA machine, before opening a browser: - -``` -nslookup ai.yokogawa.tech → 10.0.0.17 -nslookup auth.yokogawa.tech → 10.0.0.17 (NXDOMAIN today; this is the request) -``` - ---- - ## 3. A read-only login to the `imh` historian ### What is needed diff --git a/scripts/verify.sh b/scripts/verify.sh index 3b9c081..4ebccfe 100644 --- a/scripts/verify.sh +++ b/scripts/verify.sh @@ -59,12 +59,17 @@ head_ "Public endpoints - expect 302 to the auth portal" # says nothing about whether they work from a browser. The check reports the # two cases separately rather than calling both a failure. # auth.yokogawa.tech is in this list because every one of the others redirects -# to it. A hostname that resolves and answers is still unusable if the portal it -# sends the browser to does not resolve - which is exactly the case on the LAN. +# to it: a hostname that resolves and answers is still unusable if the portal it +# sends the browser to does not resolve. That is the case on the LAN today, and +# it is reported as information, NOT a failure - it blocks an operator demo from +# a control-room PC and nothing else. Development and the eval run from outside +# the VNet, where auth resolves normally. Promote it to a failure when a demo +# from cicore1 is actually being prepared. for host in lf.yokogawa.tech cube.yokogawa.tech api.yokogawa.tech ai.yokogawa.tech auth.yokogawa.tech; do if ! getent hosts "$host" >/dev/null 2>&1; then if [ "$host" = "auth.yokogawa.tech" ]; then - bad "auth.yokogawa.tech does not resolve from inside the VNet - every gated hostname redirects here, so nobody on the LAN can sign in. Needs a DC pinpoint record -> 10.0.0.17 (REQUESTS.md item 4)" + printf ' ?? auth.yokogawa.tech does not resolve from inside the VNet. Every gated hostname redirects here, so nobody on the LAN can sign in until the DC gets a pinpoint record -> 10.0.0.17. Not a blocker for anything but a demo from a control-room PC. +' else printf ' ?? %s does not resolve FROM THIS HOST (no DC pinpoint record) - check it from outside the VNet ' "$host"