# bin
The contents of my bin dir. Useful when I crash, burn, corrupt, despoil, savage, or ravage my system. 


## Notes

* `~/bin` is the primary git repo on `bigfish`; `clown` has a Syncthing copy for execution only.


## SSH Ext
ssh -p 48217 aaron@hoffer.hopto.org

## MCP server

`mcpserve` starts the Desktop Commander MCP server via `npx @wonderwhy-er/desktop-commander@latest`
and writes stderr logs to `~/log/mcpserve.log`.

To expose it from another host over SSH, add an SSH alias such as:

    Host clown-mcp
      HostName clown
      User aaron

Then point Codex at it with an MCP entry like:

    [mcp_servers.clown]
    command = "ssh"
    args = ["clown-mcp", "mcpserve"]

This repo only provides the `mcpserve` wrapper; the Desktop Commander package is downloaded by `npx`
when the command runs.

## Claude Code and Codex wrappers

`claude` and `codex` in `~/bin` resolve the real binary outside `~/bin` and exec it.
This keeps the wrapper predictable and avoids self-invocation.


## Colima scripts

### Fix mixed OCI/Docker v2 image manifest format

Docker 24+ with Colima's containerd-snapshotter enabled stores images in containerd's
OCI format. Base layers pulled from Docker Hub arrive as OCI, while new build layers
get Docker v2 types from the Docker build API. The result is a mixed-manifest image
that skopeo cannot convert to docker-archive format, breaking CI Twistlock scans.

Fix: disable containerd-snapshotter in `~/.colima/default/colima.yaml`:

    docker:
      features:
        containerd-snapshotter: false

Then restart Colima and prune stale snapshotter images before rebuilding:

    colima restart
    docker system prune -a --volumes -f

After the prune, rebuild and repush. The resulting image will have a clean Docker
Schema v2 manifest with all layers as `application/vnd.docker.image.rootfs.diff.tar.gzip`.

Verify with:

    skopeo inspect --raw docker://<registry>/<image>:<tag> \
      | python3 -m json.tool | grep mediaType


## Future Enhancements

### Cross-tool lock awareness in cx scripts

`acquire_lock` in `cx.lib` uses a lock name (`build` or `deploy`) to create
`/tmp/<name>-<project-hash>.lock`. Because the names differ, `cxdeploy` can
run concurrently with `qb`, which creates a race: if `cxdeploy` calls
`docker save` while `qb` is mid-`buildx --load` on the same tag, the saved
image can be corrupt or wrong-platform, causing `exec format error` in k8s.

Ideas:

- Add a `check_lock` helper that tests for a conflicting lock name without
  acquiring it. `cxdeploy` could call `check_lock build` and abort (or wait)
  if a build is in progress.
- Alternatively, give `acquire_lock` an optional list of lock names to treat
  as conflicts, so a deploy can refuse to start while any listed lock is held.
- A simpler convention: `cxdeploy` could check for any `/tmp/build-<hash>.lock`
  before proceeding and print a clear warning rather than silently racing.


Colima, amd64, QEMU, and docker
The Colima QEMU VM has no bridged network — it's only reachable via SSH. The 192.168.5.1 IP is internal to the VM and not routable from the Mac. So we set up an SSH tunnel using the Lima-generated SSH config (which has the identity key, dynamic port 60953, etc.) to forward localhost:6443 on the Mac through to 127.0.0.1:6443 inside the VM, where the kube-apiserver is listening.
Now your kubeconfig just needs to point at https://127.0.0.1:6443.

How to grab the rancher config
colima ssh -p rke2-amd64 -- sudo cat /etc/rancher/rke2/rke2.yaml > ~/.kube/rke2-colima.yaml

Problem: kubectl on the MacBook couldn't reach the RKE2 API server running inside a Colima QEMU VM.
Root cause: QEMU mode doesn't expose a routable IP by default. The VM's internal IP (192.168.5.1) wasn't reachable from the Mac — the only way in was via SSH, which Colima manages internally through Lima.
Dead ends we hit along the way:

SSH tunnel on port 6443 worked briefly, but Rancher Desktop's limactl was already bound to 127.0.0.1:6443, so our traffic was hitting the wrong cluster. That caused both the TLS CA mismatch and the auth failures — we were authenticating against Rancher Desktop with RKE2 creds.
The tunnel approach was also inherently fragile (processes dying, port conflicts).

What actually fixed it:
Set network.address: true in ~/.colima/rke2-amd64/colima.yaml and restarted the VM. This uses socket_vmnet to give the VM a real routable IP (192.168.106.2), making the API server directly reachable. Then we pointed the kubeconfig cluster at https://192.168.106.2:6443 with --insecure-skip-tls-verify (fine for dev) and it connected cleanly.