YAU.POC/yau-plant-assistant
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Withdraw the auth.yokogawa.tech request - it blocks nothing yet

Browse source 
Raised as an item for Dan, which was premature. It blocks exactly one thing: a
demo from a control-room PC. Development and the Phase 8 eval both run from
outside the VNet, where auth.yokogawa.tech resolves normally, and the demo it
would block cannot happen until the Azure OpenAI account lands anyway.

The finding stays in verify.sh as information rather than a failure, so it is
in front of whoever prepares that demo instead of failing every run until then.

Also worth recording: this was inferred from lin001 resolving against 10.0.0.5,
not tested on cicore1. Same DC and same zone, so very likely identical, but it
has not been confirmed on the machine it concerns.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Claude 2026-08-27 15:16:48 +10:00
parent 8d4d731832
commit b4c20324f5
2 changed files with 8 additions and 48 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
REQUESTS.md
View file

@ -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

11
scripts/verify.sh
View file

@ -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"