@celilo/e2e 0.16.1 → 0.17.1

package/config/socks/startup.sh

@@ -34,6 +34,13 @@ esac
 ip route del default 2>/dev/null || true
 ip route add default via "$GATEWAY"
 
+# An explicit resolver from the caller wins over the vantage default. The proxy
+# is what resolves names for a SOCKS5 client — a browser hands it the hostname
+# and never resolves it itself — so a test driving a browser at a name only the
+# fleet's own resolver knows has to say so here. Modelling a real device: one
+# on the internal zone is handed the fleet's resolver, not a fixed stub.
+NAMESERVER="${NAMESERVER_OVERRIDE:-$NAMESERVER}"
+
 # Bypass docker's embedded resolver — point directly at the in-network
 # DNS so split-horizon and the namecheap simulator both behave correctly.
 echo "nameserver $NAMESERVER" > /etc/resolv.conf

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celilo/e2e",
-  "version": "0.16.1",
+  "version": "0.17.1",
   "description": "E2E test infrastructure for Celilo-deployed applications. Provides a simulated internet with DNS hierarchy, ACME server, firewalls, and target machines in Docker.",
   "type": "module",
   "main": "./src/index.ts",
@@ -37,10 +37,10 @@
     "README.md"
   ],
   "dependencies": {
-    "@celilo/capabilities": "^2.0.0",
+    "@celilo/capabilities": "^2.4.0",
     "@celilo/cli-display": "^0.2.0",
     "@celilo/event-bus": "^0.6.0",
-    "@celilo/terraform-fake": "^0.3.0",
+    "@celilo/terraform-fake": "^0.3.1",
     "yaml": "^2.8.0",
     "zod": "^3.24.1"
   },

package/registry-server/package.json

@@ -8,7 +8,7 @@
     "start": "bun run src/index.ts",
     "dev": "bun --watch src/index.ts",
     "build:binary": "bun build --compile --target=bun-linux-x64 --outfile=dist/celilo-registry-server src/index.ts",
-    "test": "bun test"
+    "test": "bun test --timeout 30000"
   },
   "devDependencies": {
     "bun-types": "latest",

package/scripts/stage-apt-repo.ts

@@ -98,7 +98,9 @@ export function stageAptRepo(repoRoot: string, pkgDir: string): boolean {
 
   const debs = readdirSync(distDir).filter((f) => f.endsWith('.deb') && f.includes(version));
   for (const deb of debs) {
-    cpSync(join(distDir, deb), join(pool, deb));
+    // `force` explicit: a rebuilt .deb at the same version must replace the
+    // one already pooled, or build-infra serves stale bytes.
+    cpSync(join(distDir, deb), join(pool, deb), { force: true });
   }
 
   console.log(

package/src/module-host.ts

@@ -48,7 +48,6 @@ export function parseModuleHost(statusOutput: string): ModuleHost | null {
   // both, and a raw match silently finds nothing.
   const lines = statusOutput
     .split('\n')
-    // biome-ignore lint/suspicious/noControlCharactersInRegex: stripping ANSI is the point
     .map((line) => line.replace(/\x1b\[[0-9;]*m/g, '').replace(/^[\s│|]+/, ''));
 
   for (const line of lines) {

package/src/router-swap.ts

@@ -102,7 +102,21 @@ export function forwardedPorts(listing: string): string[] {
   return [...new Set(ports)].sort();
 }
 
-/** The DHCP pool's advertised DNS servers, read back off the device. */
+/**
+ * The DHCP pool's advertised DNS servers, read back off the device.
+ *
+ * Queries the pool INSTANCE (`…Pool.1.`), not the collection (`…Pool.`). The
+ * simulator answers the collection form with `{"Objects":[]}` — no error, just
+ * an empty list — so the collection form reads as "the router advertises no DNS
+ * servers" whatever is actually configured. Both `greenwave` and `axon` write
+ * through `Device.DHCPv4.Server.Pool.1.`
+ * (`modules/greenwave/scripts/isp-router-functions.ts:153`), so this reads back
+ * exactly where the module wrote.
+ *
+ * Nothing called this until `e2e/tests/provider-arrival-backfill.test.ts`, which
+ * is how the mismatch survived: against the collection form an assertion fails
+ * identically whether the router was configured or not.
+ */
 export async function routerDhcpDnsServers(
   net: NetworkHandle,
   device: RouterDevice,
@@ -115,7 +129,7 @@ export async function routerDhcpDnsServers(
   );
   const listed = await net.exec(
     'fw-isp',
-    `curl -sk 'https://${greenwaveRouterIp()}/cgi/cgi_get?Object=Device.DHCPv4.Server.Pool.' -b /tmp/dhcp-cookies`,
+    `curl -sk 'https://${greenwaveRouterIp()}/cgi/cgi_get?Object=Device.DHCPv4.Server.Pool.1.' -b /tmp/dhcp-cookies`,
   );
   return listed.stdout;
 }

package/src/socks-proxy.ts

@@ -22,6 +22,19 @@ export interface SocksProxyOptions {
    *   zones via the firewall.
    */
   vantage?: SocksProxyVantage;
+  /**
+   * Resolver the proxy should use instead of the vantage's baked default.
+   *
+   * The PROXY resolves names for a SOCKS5 client: chromium configured with
+   * `socks5://` sends the hostname and never resolves it itself. A test driving
+   * a browser at a name only the fleet's own resolver knows — anything on a
+   * private ingress — therefore has to point the proxy at that resolver.
+   *
+   * More faithful rather than less: the rig's baked stub answers a fixed
+   * split-horizon table, whereas a device on the internal zone is handed the
+   * fleet's resolver. Pass the deployed resolver's DNS-ingress address.
+   */
+  nameserver?: string;
 }
 
 export interface SocksProxyHandle {
@@ -69,8 +82,22 @@ const VANTAGE_CONFIGS: Record<SocksProxyVantage, VantageConfig> = {
   },
 };
 
-function containerNameFor(projectName: string, vantage: SocksProxyVantage): string {
-  return `${projectName}-socks-${vantage}`;
+/**
+ * Deterministic per (project, vantage, resolver).
+ *
+ * The resolver is part of the identity because a proxy is REUSED by name: two
+ * calls differing only in `nameserver` would otherwise silently share one
+ * container, and the second would resolve through the first's resolver. That
+ * failure looks like a DNS bug in the fleet, which is the worst possible place
+ * for it to look like anything.
+ */
+function containerNameFor(
+  projectName: string,
+  vantage: SocksProxyVantage,
+  nameserver?: string,
+): string {
+  const suffix = nameserver ? `-dns-${nameserver.replace(/\./g, '-')}` : '';
+  return `${projectName}-socks-${vantage}${suffix}`;
 }
 
 /**
@@ -85,7 +112,7 @@ export async function startSocksProxy(
   const vantage = options.vantage ?? 'isp-external';
   const cfg = VANTAGE_CONFIGS[vantage];
   const networkName = `${projectName}_${cfg.network}`;
-  const containerName = containerNameFor(projectName, vantage);
+  const containerName = containerNameFor(projectName, vantage, options.nameserver);
 
   // Reuse existing container if one is running for this project + vantage
   const existing = inspectContainer(containerName);
@@ -113,6 +140,7 @@ export async function startSocksProxy(
         `--ip ${cfg.ip}`,
         '--cap-add NET_ADMIN',
         `-e VANTAGE=${vantage}`,
+        ...(options.nameserver ? [`-e NAMESERVER_OVERRIDE=${options.nameserver}`] : []),
         '-p 127.0.0.1::1080',
         PROXY_IMAGE,
       ].join(' '),

package/src/types.ts

@@ -182,6 +182,20 @@ export class CeliloCommandError extends Error {
  */
 export interface ProxyOptions {
   vantage?: 'isp-external' | 'internal';
+  /**
+   * Resolver the proxy should use, overriding the vantage's baked default.
+   *
+   * The proxy is what actually resolves names: a browser configured with
+   * `socks5://` hands the HOSTNAME to the proxy and never resolves it itself.
+   * So a test driving a browser at a name only the fleet's own resolver knows
+   * — anything on a private ingress — must point the proxy at that resolver.
+   *
+   * This is more faithful, not less: the rig's baked stub answers a fixed
+   * split-horizon table, whereas a real device on the internal zone is handed
+   * the fleet's resolver by DHCP. Pass the deployed resolver's DNS-ingress
+   * address here to model that.
+   */
+  nameserver?: string;
 }
 
 export interface SocksProxyHandle {