Hey,
For the Cloud 7 venue, we are trying to reach the Epiphan Pearl from the Mac mini.
IP details:
When we enter http://11.0.6.76 in the browser on the Mac mini, the Epiphan web interface cannot be reached. However, when we connect a laptop to port 24 of the same switch, that laptop can reach the Epiphan at the same IP address.
This suggests a VLAN, routing, or switch-port configuration difference affecting the Mac mini path. Please investigate why the Mac mini cannot reach 11.0.6.76 while a laptop connected to switch port 24 can.
UPDATE 2026-09-08 (correction of the previous comment): on-site testing shows Chrome AND Safari on the Mac mini both fail to reach 11.0.6.76, while a Windows computer on the same network reaches it fine. Terminal ping and curl from the Mac mini still work (curl gets the Pearl-2 401 login challenge).
That pattern (terminal works, all GUI browsers fail, other computers work) is the macOS Local Network privacy permission, not HTTPS-First and not the network. Since macOS 15, GUI apps are blocked from LAN IP addresses until the user allows them per app. The unified log on turbo-pancake-76 confirms the LocalNetwork privacy subsystem intercepting com.google.Chrome connections during our tests. No system proxy is configured.
Fix on the Mac mini: System Settings > Privacy & Security > Local Network > enable Google Chrome and Safari. If they are not listed, open Chrome, browse to http://11.0.6.76, and click Allow on the local network prompt. Then reload; expect the Basic auth login for realm Pearl-2 TSKB03679. Type http:// explicitly (the Pearl has no HTTPS).
For Citymesh: the network is confirmed fine, no action needed on their side; the blocker is a macOS privacy setting on the Mac mini.
CONFIRMED FIXED on site 2026-09-08: enabling the browser under System Settings > Privacy & Security > Local Network on the Mac mini restored access to the Epiphan Pearl-2 web interface at http://11.0.6.76. Root cause was the macOS Local Network privacy permission, not the network. Citymesh needs no action; the network was fine. Documented in the hydraepiphan runbook (docs/runbooks/epiphan-pearl2-access.md). Closing.
Ran the tests Citymesh asked for, remotely via hydracluster exec on turbo-pancake-76 (node-adf19775), 2026-09-08.
Ping from the Mac mini terminal to the Epiphan (11.0.6.76): SUCCESS. 4/4 packets, 0% loss, avg 0.55 ms, TTL 64 (same L2 segment).
HTTP from the Mac mini to http://11.0.6.76/: SUCCESS. The Pearl answers with 401 Unauthorized, WWW-Authenticate: Basic realm="Pearl-2 TSKB03679", Server: Apache. That is the Epiphan web interface responding correctly; it just wants credentials.
HTTPS to https://11.0.6.76/: NO RESPONSE (connection fails). The Pearl does not serve HTTPS.
Conclusion: the network path Mac mini -> Epiphan is fine. The original symptom was almost certainly browser behavior: Safari on macOS 26 upgrades http:// to https:// (HTTPS-First), and the Pearl has no HTTPS, so the page appears unreachable. A browser that falls back to plain HTTP (or typing http:// explicitly and accepting the fallback) reaches the interface and gets the Basic-auth login prompt.
Proposed reply to Citymesh (Dutch):
Bedankt voor het nakijken. We hebben de tests uitgevoerd op de Mac mini:
Voor ons is het netwerkgedeelte hiermee bevestigd in orde. Bedankt!