# 2026-09-18 Alibaba Cloud host bootstrap evidence

## Scope

This is real cloud deployment evidence for the owner-authorized first test Cell.
It is **not** W13-b/P1 or production acceptance: the Go binary still has no
production ARI/SIP/ExternalMedia/call-execution path, and no real provider call
was initiated from this host. The host later ran a separately isolated,
mock-only Asterisk/PJSIP/PJSUA2/ARI compatibility stack; those results are
recorded in the W09 evidence documents below.

- Region: `cn-beijing`
- Instance: `i-2zeb69p1fo75r92wplbz`
- Status: `Running`
- Image: `debian_13_6_x64_20G_alibase_20260828.vhd` (Debian 13)
- Type/charge: `ecs.e-c1m1.large`, `PostPaid`, owner-selected `SpotAsPriceGo`
- Zone: `cn-beijing-g`
- EIP: `123.56.71.98`, allocation `eip-2zeevfsaxzwuue2szy7xb`, `InUse` by the
  instance
- Security group: `sg-2zed6d5vmcvojt7zek4r`
- SSH key: existing `mac_ed25519`, matching the required rogee public key
- Release binary SHA-256: `6047a9a6a1f52db52e326167f1f50a17d8c46c34b34327294657d35c87d10cf9`

The initial `RunInstances` request was rejected for insufficient balance. After
account eligibility was restored, the same persisted request/client token
passed `DryRun` and was applied. No second EIP, unrelated instance, or new key
pair was used.

## Host hardening

- Host ED25519 key was scanned twice and was stable at
  `SHA256:k1OBPlQcjYo5DqO2sbvcJEpdoqKNuWZHBreHSVB24pQ`; the stale EIP entry was
  replaced only after confirming the EIP was now attached to this new instance.
- User `rogee` (UID 1000) was created with only the required public key.
- `PasswordAuthentication no`, `KbdInteractiveAuthentication no`,
  `PermitRootLogin no`, public-key authentication, and `AllowUsers rogee` were
  applied and `sshd -t` passed.
- Root SSH login was rejected after the hardening reload.
- Subsequent host commands used SSH as `rogee` and the restricted sudoers file;
  no root command was used after final hardening.
- Existing security-group rules were inspected. TCP 22 is open for the
  required administration path; UDP/SIP/RTP rules are limited to the recorded
  provider/diagnostic source IPs and no `0.0.0.0/0` UDP rule was added.

## Release smoke

The release binary was copied over SSH to `/opt/sip-go-agent/sip-go-agent` and
local/remote SHA-256 matched. On the Debian host, both commands completed in
explicit `mock` mode and returned valid JSON:

```text
SIP_GO_AGENT_MODE=mock ... /opt/sip-go-agent/sip-go-agent agent
SIP_GO_AGENT_MODE=mock ... /opt/sip-go-agent/sip-go-agent dispatcher
```

The smoke only proves the binary, directories, permissions, SQLite/file spool
startup, and non-production mode on the real host. It does not prove mTLS
Dispatcher/Agent interop, a management-approved static artifact, production
Asterisk loading, Agent ARI/RTP/PCMA integration, AI suppliers, OSS/MQ, or a
phone call.

## Isolated mock compatibility follow-up

Docker was installed on this host for an isolated mock-only Asterisk container.
The pinned Asterisk 22.10.1 image was transferred from the local cache because
Docker Hub was unreachable from the host. The container was loopback-restricted
for ARI/SIP publication and used no provider credentials. Runtime results:

- `docs/evidence/20260918-w09-ari-runtime.md`
- `docs/evidence/20260918-w09-sip-ari.md`
- `docs/evidence/20260918-w09-sip-rtp-ari.md`

These documents prove only the disposable mock compatibility layers and do not
change the host's production or real-provider status.

## Resource state and cleanup

The instance and EIP remain running/attached for the next explicitly authorized
step. Spot interruption can terminate the host and does not migrate calls.
Do not stop/delete the instance or release/unbind the fixed EIP without a
separate user cleanup instruction.