From f4746cb39bcc4dc0c44d5167fea5353665600599 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 27 Aug 2026 15:40:35 +1000 Subject: [PATCH] Drop the auth check, and say what each hostname is for 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 --- caddy/ai-routes.caddy | 20 ++++++++++++++++++++ scripts/verify.sh | 16 ++-------------- 2 files changed, 22 insertions(+), 14 deletions(-) diff --git a/caddy/ai-routes.caddy b/caddy/ai-routes.caddy index 6a18884..22e6e3d 100644 --- a/caddy/ai-routes.caddy +++ b/caddy/ai-routes.caddy @@ -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 diff --git a/scripts/verify.sh b/scripts/verify.sh index 4ebccfe..d2003e9 100644 --- a/scripts/verify.sh +++ b/scripts/verify.sh @@ -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 + 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")