MCP-Ubuntu: Skill for Claude Code

Ubuntu update cycle

This encodes a workflow refined over many real update rounds on Nic's three home-lab servers, including mistakes made and fixed along the way. The steps below aren't arbitrary process for its own sake — each one exists because skipping it caused a real problem at least once. Read references/lessons-learned.md if you want the war stories behind a given step.

Servers: Plex (192.168.0.61), Portal (192.168.0.116), PostgreSQL (192.168.0.134) — full details, roles, and per-host health checks in references/servers.md. Use ubuntu_list_servers if you need to confirm the current inventory hasn't changed.

The workflow

1. Check

Call ubuntu_check_updates on all three servers with refresh_cache: true. Nic's standing preference is a fresh apt-get update every time, not a cached read — a stale cache can under-report what's actually pending. Checking is read-only and safe to run in parallel on all three regardless of which install strategy you use next.

If a check comes back with a refresh_warning (an apt lock held by a concurrent process, e.g. unattended-upgrades running its own scan), don't trust that result — retry once to get a clean read before deciding there's nothing to do.

If nothing is pending anywhere, say so and stop — no need to touch the rest of this workflow or write a change doc for a no-op check.

2. Choose an execution strategy

Default: canary-then-parallel. Run the full install→verify sequence on Plex alone first (it has the lowest blast radius — a media server, not the production database). Once Plex comes back healthy, run Portal and PostgreSQL together in parallel. This means a bad update surfaces on one low-stakes box before it ever touches the other two.

Full parallel: only when Nic explicitly asks for speed ("in parallel", "minimize the time", "hit all three at once"). Say plainly that you're skipping the staged safety margin because he asked for it — don't do this silently. It's a reasonable trade for routine security patches (glibc, Python, kernel point releases) but worth naming out loud each time, since he may not want it for something riskier.