I recently noticed that I had lost RTSP credentials for one of my IP cameras. They weren’t in my password manager nor anywhere else I could think of, but the camera was currently configured and streaming in Surveillance Station. If it was streaming, then Surveillance Station must have had credentials stored somewhere.

With a bit of trial and error and some LLM assistance, I recovered the credentials as follows (Synology 7.3.2, your volume might change):

sqlite3 --readonly /volume1/@appstore/SurveillanceStation/system.db \
  "SELECT name, hostname, port, username, password FROM camera;"

The password is prefixed with a $ and is then (inexplicably) encoded twice in base 64.

On that particular Mac, the disk is 2TB and I am only allocating 1.5TB to Time Machine over Samba. That’s why the error isn’t particularly surprising at first glance. What’s surprising is that /nix on the Mac was using almost 1TB and is excluded from Time Machine, in addition to a few other things (VMs, cache directories, etc.). As a result, the Samba share should have easily fit what I needed to back up (plus keep some older copies).

Puzzled, I started investigating. LLMs couldn’t pinpoint the exact issue, but helped me realize that a single Time Machine backup had grown to occupy the full 1.5TB. Once I discovered that Time Machine mounts the backup image as a file system under /Volumes/Backup of <hostname>, I pointed the great Disk Inventory X at it to take a look at what was eating my backup space. Here’s the result:

The whole backup is about 540GB, of which 524GB are from container/snapshot.

I later found issue #404 in the container repository, where multiple users report the same issue. To prevent this from happening again, you can exclude the container state from your Time Machine backups as follows:

tmutil addexclusion ~/Library/Application\ Support/com.apple.container

Unfortunately, I tried and failed to recover space from the existing bloated backup, so I just deleted it and started from scratch.

Although Tailscale can run within the VM itself, I prefer to run its Android app in ChromeOS. This way, the VM never sees the raw Tailscale credentials and, if running multiple VMs, they can all share network access.

Under the hood, all VM traffic already flows through the host, enabling Tailscale routing. In addition, the NixOS Baguette image delegates DNS resolution to the host, as follows:

ln -sf /run/resolv.conf /etc/resolv.conf

maitred takes care of populating the /run/resolv.conf file as the host’s network configuration changes:

Mar 17 10:26:43 baguette-nixos maitred[412]: Received request to update VM resolv.conf

Activating and de-activating Tailscale correctly updates the resolv.conf file. With Tailscale enabled, it will look as follows:

nameserver 100.100.100.100
search [redacted].ts.net

The search configuration allows using ping <hostname> or ssh <hostname> from the VM without specifying the Tailnet FQDN (something that wasn’t working in crostini). Queries outside the Tailnet go through the host’s DNS configuration.

The most noticeable improvement comes from og:image, which adds an image on top of the page title:

The OpenGraph image for this post.

Ideally, I’d dynamically generate all images when running jekyll build. However, the image generation plugin converts an SVG to webp through imagemagick, which isn’t available in the Cloudflare builder. As a (ugly) workaround, I pre-generate each image and commit it to the repository.

In addition, each post now also includes OpenGraph tags for:

1. Its modified time.
2. Its section (e.g., micros).
3. Its tags (if any).

Cloudflare builders expose the URL for previews through the CF_PAGES_URL environmental variable. We can make Jekyll aware of it through this build_cloudflare.sh script:

configs="_config.yml"

if [ -n "${CF_PAGES_URL:-}" ]; then
  echo "url: $CF_PAGES_URL" > _cf_url.yml
  configs="${configs},_cf_url.yml"
fi

bundle exec jekyll build --config "$configs"

To run it, set the script as the build command in your Cloudflare Workers and Pages configuration.

From the human.json protocol:

human.json is a lightweight protocol for humans to assert authorship of their site content and vouch for the humanity of others.

It looks like claude-code does a git fetch at startup, which requires SSH if the repository was cloned that way. To fix it, set this environmental variable:

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

From the manual:

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: Equivalent of setting DISABLE_AUTOUPDATER, DISABLE_BUG_COMMAND, DISABLE_ERROR_REPORTING, and DISABLE_TELEMETRY

I haven’t tried scoping it down to one of these variables, let me know if you do! Meanwhile, this should also prevent claude-code from asking for feedback during a session.

Although the problem was real, my post felt overly negative, not constructive, and wrong. Instead of publishing it, I just opened an issue in cloudflare-docs.

The maintainers have now kindly fixed the issue. Anyone can use any Ruby version in a Cloudflare Pages build. If the worker doesn’t have that version available, it will automatically download it and compile it (in which case, the build might take a bit longer).

As for me, this means I can pin my .ruby_version to one that is cached in nixpkgs so that I can quickly start writing on low-powered devices.

To add a .p12 certificate to ChromeOS’ certificate manager:

1. Navigate to chrome://certificate-manager
2. → “Your certificates”
3. → “View imported certificates from ChromeOS”
4. → “Import and bind”
5. Select your certificate from the file picker
6. Enter your certificate’s password

“Import and bind” stores the certificate on the device’s Trusted Platform Module (TPM).

It might be possible to also store the certificate on a Yubikey through the Personal Identity Verification (PIV) app and then use it on a Chromebook through the Smart Card Connector and a middleware. I haven’t tried this approach yet, but I hear it is tricky on non-enterprise devices.