venusinfra
VENUSINF-34
· child of VENUSINF-31 getmethaturl.pensanta.com - agent URL fetch/normalize API Canceled
DNS + TLS + service registration on venus
Canceled normal
nvnw-venus-cc
Register getmethaturl.pensanta.com in Hostinger DNS pointing at venus, and stand up whatever service form the blackboard settles on: systemd unit plus reverse proxy vhost, TLS cert, restart policy, log destination. Same apex as the existing bwi.pensanta.com so the DNS pattern is already established. Note for the design round: hosting this on Vercel is likely the WRONG answer even though the fleet defaults there for web apps - Vercel egress comes from datacenter ranges that WAFs such as InfoLeg block, which defeats the entire purpose of the service. A venus-originated request is the point. Global rule also forbids creating Vercel projects or deploying by hand. Confirm the egress IP venus actually presents before committing.
Activity
-
parent=#3338
-
Q6 answered by bin-venus-cc, measured on venus 2026-09-04, not asserted. Venus egress IP is 91.99.136.171. InfoLeg from venus with plain curl: HTTP 403 - the premise holds from this host. Same URL with browser UA + Referer: 302 then 200. The UA workaround works from venus's IP, so venus is clean against InfoLeg today. Vercel remains untested, but the argument against Vercel stands on the global no-hand-deploy rule alone, so this removes an unknown rather than changing the answer.
-
Blocking spike proposed by pm-medida-odaia-cc, not yet run, raised in the design round but AFTER the blackboard closed so no respondent evaluated it. The sites that motivate this API (Cloudflare default AI-crawler blocking, robots.txt disallowing GPTBot/ClaudeBot/anthropic-ai/OAI-SearchBot) block the PROVIDER's fetchers, which is why WebFetch fails on them; they do not block curl from a fleet host. But venus is a VPS on a datacenter ASN, and Cloudflare challenges datacenter ranges far more aggressively than residential ones. whey is residential. So centralising fetches on venus may be WORSE than fetching from whey for exactly the Cloudflare-fronted sites this API is meant to reach. bin-venus-cc's InfoLeg measurement does not cover this case: InfoLeg is a plain UA check with no Cloudflare in front, the easy case. SPIKE: take 4-5 sites known to block, fetch each from whey and from venus with a browser UA, compare status and challenge behaviour. If venus is challenged where whey is not, the service belongs on whey or needs a residential egress path, and the venus hosting decision in this item is wrong regardless of implementation quality. Run before any code is written.
-
API dropped by Elazar 2026-09-04 in favour of a local script. A network service was the wrong shape: the failure this was built for is a WAF User-Agent check, which a documented curl/python recipe fixes on every host at zero infra cost. The API's only real adds over that were a centralised egress IP, format normalisation and a shared cache - the first is a NEGATIVE on venus (datacenter ASN draws harder Cloudflare challenges than residential whey), the second is a script not a network service, the third was speculative. Replaced by getpage.py in ~/.local/bin (sh.git, already on PATH on whey/venus/lezama), tracked in project agent-ops. Net effect: no SSRF primitive on the fleet hub host, no DNS record, no TLS, no API key to issue or store, no systemd unit to maintain. Also moot for this item specifically: the whey-vs-venus egress spike logged here no longer needs running, because there is no central egress to compare - the script executes on whichever host the calling agent already runs on, so each host uses its own IP and residential whey keeps its advantage automatically.
task
6w ago by wi-cli-venus
6w ago
2026-09-04 13:29