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

Drop the auth check, and say what each hostname is for

Browse source 
Leaving the auth.yokogawa.tech note in verify.sh was a standing nudge towards a
fourth name, which is the opposite of what this host needs. Removed.

In its place, the thing that was actually missing: a list, where the Caddy
blocks live, of which hostname serves what and which one a control-room PC
needs. lin001 is shared and already carries a dozen *.yokogawa.tech services -
the cost of a name is not the DNS change, it is that nobody else can tell what
it is for. Notes that cube.yokogawa.tech is the one nothing depends on.

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

20
caddy/ai-routes.caddy
View file

@ -15,6 +15,26 @@
# DNS is not managed on this host. Each hostname needs an A record ->
# 20.211.144.151 before Caddy can issue a certificate. Ask Dan.
#
# DO NOT ADD A HOSTNAME THIS PROJECT IS NOT BLOCKED WITHOUT. lin001 is shared,
# already carries a dozen *.yokogawa.tech services, and other people have to
# work out which name serves what. The cost of a name is not the DNS change, it
# is the attribution problem it leaves behind. Prefer a path route under a name
# that already exists - which is what /ask under ai.yokogawa.tech is.
#
# What this project owns, and what each one is for:
#
# ai.yokogawa.tech the operator's screen, and /ask behind it. The ONLY one
# a control-room PC needs, and the only one with a DC
# pinpoint record.
# api.yokogawa.tech ai-api direct. Used by the eval runner and, at Phase 9,
# by the /docs endpoints - whose publisher rule is scoped
# to THIS hostname. Not used by the operator's browser.
# cube.yokogawa.tech Cube's playground and REST API, for an engineer
# hand-verifying a measure. ai-api reaches Cube
# container-to-container and never by hostname, so
# nothing breaks if this one is dropped.
# lf.yokogawa.tech Langfuse - traces, prompts, eval runs.
#
# DONE 2026-08-27: ai, api and cube .yokogawa.tech all resolve to
# 20.211.144.151, and the DC carries the pinpoint record
# ai.yokogawa.tech -> 10.0.0.17 for the Azure hairpin (same treatment as

14
scripts/verify.sh
View file

@ -58,22 +58,10 @@ head_ "Public endpoints - expect 302 to the auth portal"
# and cube do not. So on this host those three do not resolve at all, and that
# 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. 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
for host in lf.yokogawa.tech cube.yokogawa.tech api.yokogawa.tech ai.yokogawa.tech; do
if ! getent hosts "$host" >/dev/null 2>&1; then
if [ "$host" = "auth.yokogawa.tech" ]; then
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"
fi
continue
fi
code=$(curl -s -o /dev/null -w '%{http_code}' -I "https://$host" --max-time 10 || echo "000")