Brian's Waste of Time

bdsh: A dsh-alike for me

Brian McCallister — Sun, 01 Feb 2026 00:00:00 +0000

I finally put enough of a bow-tie on bdsh</a> that I can use it as a daily tool. WOO HOO! I have long wanted a dsh</a> which did a few additional things, and now I have them. In honor of dsh's backronym ambiguity, I am not sure if bdsh is "better (distributed|dancer's) shell", "Brian's (distributed|dancer's) shell", or "BreakDancer's Shell". Regardless, I am super happy with this little tool :-) So, what does it do differently?

First, it has the idea of a consensus view for the outputs frmo each host. When running it builds and displays a consensus view of the most common line-by-line output, with drill down into where it differs. This is probably best illustrated with a demo:

This demo shows running cowsay across three hosts, rendering the unified output view, and drilling down into a difference.

Second, notice it is running in tmux</code>. This lets you switch over to the windows and see them, and critically if something there requires interaction, you can interacta common thing I use it for is bdsh :bsd -- sudo "sh -c 'freebsd-update fetch && freebsd-update install; pkg update && pkg upgrade'"</code> which wants input on updates. You can circumvent this, but FreeBSD makes you feel guilty when you do.</side-note>. If you are doing this across hundreds of hosts, not so great, but I am ususally doing it across a reasonable number, so is actually useful. I also added a heuristic to detect if it thinks a given host is waiting on input, and changing the status indactor to a little blinking keyboard:

Window 0 in tmux is the unified output rendering process. When it thinks input is desired it does the little kwyboard icon and tells you the window number, so you can jump to it quickly. That window 0 process will exit on q</code> but the actual invocations will continue in their windows, exiting their window when they finish, and cleaning up tmux.

Finally, in these examples I list the hosts to execute on, but it can pull from a hosts file at ~/.config/bdsh/hosts</code>, from a shell command, or script, etc. You can read about it</a>. The format of output here is just line delimited hostnames with optional tags, in the form:

hati.brianm.dev         :bsd    :cloud</span></span>
h0001.brianm.dev        :arch   :cloud</span></span>
h0002.brianm.dev        :arch   :cloud</span></span>
</span>
pancake.home            :bsd    :home</span></span>
freki.home              :bsd    :home</span></span>
badb.home               :bsd    :home</span></span>
v0003.home              :arch   :home</span></span>
v0004.home              :arch   :home</span></span>
</span>
m0001.home              :bsd    :home</span></span>
m0002.home              :bsd    :home</span></span>
</span>
m0003.barn              :bsd    :barn</span></span>
m0004.barn              :bsd    :barn</span></span></code></pre>
Where you can filter on tags, like: bdsh :bsd:home -- do_stuff</code> which AND</code>s or bdsh :barn,:cloud -- do_stuff</code> which OR</code>s. Of course, you can combine them as well, with AND</code> binding tighter. With no filter, everything is selected.</p>
Currently bdsh</code> is packaged for homebrew (brew install brianm/tools/bdsh</code>) and arch (bdsh in AUR</a>), but I'll probably publish a deb soon, and once I think it is stable, and if there is evidence of anyone besides myself using it, see if I can get a port/pkg merged for FreeBSD. Source</a>, basic docs</a>, and more docs</a> all on github, Apache-2.0 licensed.</p>



D&D (prep) with Claude Code
Brian McCallister — Sun, 11 Jan 2026 00:00:00 +0000
I have teenage kids, and they are possibly dorkier than me, which is awesome. Since the pandemic, we have had a D&D game going, off and on, with some of their friends and friends' parents. It's been super fun. I am, however, the perma-DM. I am 99% fine with this, as I love</em> the world building aspects which the DM gets to lean more heavily into than players.</p>
Sometime this past year I started doing my session prep in Claude Code. It started with discussing ideas for arcs and settings, and rapidly turned into shockingly useful session prep. While I am impressed by frontier models' ability to program, I am in awe</em> of their ability to help plan and prep D&D because this is very much about predicting human behavior, setting up interesting situations and being ready for what real people may do in them. That Claude can make rustc sing is nice, that it can make my players</em> sing was unexpected.</p>
I have, for a long time, been keeping my notes in Obsidian</a> and git (private GH repo), laid out more or less like:</p>
├── encounters</span></span>
│   ├── agadol_ambush.md</span></span>
│   ├── Audience with Kerral.md</span></span>
│   └── [more, elided ...]</span></span>
├── factions</span></span>
│   ├── Arjun.md</span></span>
│   ├── Tollkeepers.md</span></span>
│   └── [more elided ...]</span></span>
├── ideas</span></span>
│   ├── beechport_arc_ideas.md</span></span>
│   ├── The Red Dragon.md</span></span>
│   └── [more, elided ...]</span></span>
├── npc</span></span>
│   ├── Agustin.md</span></span>
│   ├── Chalan.md</span></span>
│   └── [and more, elided...]</span></span>
├── pc</span></span>
│   ├── Borin - Notes.md</span></span>
│   ├── Ethex - Notes.md</span></span>
│   ├── Nameless - Notes.md</span></span>
│   └── Ragux - Notes.md</span></span>
├── places</span></span>
│   ├── Aurum.md</span></span>
│   ├── Beechport.md</span></span>
│   └── [and more, elided ...]</span></span>
└── sessions</span></span>
    ├── [and more elided ...]</span></span>
    ├── Session 026 - 2026-01-03.md</span></span>
    └── Session 027 - 2026-01-17.md</span></span></code></pre>
Claude took to this structure like, well, a coding agent to a tree of markdown :-) I have long described myself as working best when I can "pair think" -- put me at a whiteboard with another programmer and I, at least, am more than 2x as effective. Cannot vouch for any given pair-thinker, but this seems to be common enough that I suspect the sum is greater than the parts.</side-note> Rubber ducking, even with Jonathan Aquino's excellent assistance</a>, Thank you for that video, Jon, I still use it!</side-note> just is not the same. Turns out DM planning works this way to, and Claude is a good enough pair-thinker that the results are great.</p>
Mechanically, I fire up a claude-code web session to plan the next session and just let thoughts wander all over. I let claude organize what we come up with into NPC, Faction Idea, or Session files as it makes sense, then iterate on key things for the next session. I generally have a bunch of "here is other stuff going on" in a per-arc doc (beechport_arc_ideas.md</code> above, for example), which act as a catch all for "this might happen, and I think here are some things that might fall out of it..." type thoughts. The arc-doc is the big picture context for the next session of planning, and it will refer to key NPCs, places, factions, etc.</p>
Historically I used something similar to the Lazy DM approach</a>, but have been trying Brennan Lee Mulligan's toy approach</a> lately. In both cases, Claude has been able to take a description of the materials I want at the table and produce them well enough to almost just use.</p>
As I mentioned, the thing that has most impressed me is in encounter planning. Claude is surprisingly good at predicting what players will do in given situations, estimating the time for a given encounter, estimating the difficulty, highlighting things which will likely have an emotional impact on a specific player, etc. It can predict good beats to highlight aspects of individual characters even, and help set opportunities for specific individuals to showcase some aspect of themselves. It sometimes gets confused between NPCs and PCs, and will optimize to allow an NPC to shine, but it course corrects on this well enough.</p>
The main thing that burnt me early was when Claude would go off the rails Is it still hallucination if the thing it is hallucinating is completely imaginary and poorly defined in the first place?</side-note> on aspects of the world or players and I didn't bother to correct it, because, who cares. Later when it referred to past notes the misunderstandings started magnifying and the overall quality as a planning partner deteriorated greatly. Spending time getting on the same page, and getting Claude to record it in the various docs, was well</em> worth it, as now it makes really good connections without help.</p>


Fun With HTTP Caching
Brian McCallister — Sat, 27 Dec 2025 00:00:00 +0000
The two fun problems in computer science: cache invalidation, naming things, and off-by-one errors. Today I want to talk about the first one.</p>
I've been working on Epithet</a>, an SSH certificate authority Really, an agent, a CA, and policy server</side-note> that makes certificate-based authentication easy. Part of the system involves a "discovery" endpoint where clients learn which hosts the CA handles. The question: how do you cache this efficiently while still allowing updates to propagate?</p>
The policy server component provides a discovery endpoint for this, which serves a simple JSON document:</p>
{</span>"matchPatterns"</span>: [</span>"*.example.com"</span>,</span> "prod-*"</span>]}</span></span></code></pre>
This content rarely changes, only when you add a new host pattern</em> to your policy, generally. But when it does change, you want clients to pick it up reasonably quickly. My first implementation used aggressive caching:</p>
w.</span>Header</span>().</span>Set</span>(</span>"Cache-Control"</span>,</span> "max-age=31536000, immutable"</span>)</span></span></code></pre>
Cache it forever! The URL is content-addressed (/d/{hash}</code>), so if the content changes, the hash changes, and you get a new URL. Problem solved, right?</p>
Not quite. The client learns the discovery URL from a Link</code> header in other responses:</p>
Link: </d/abc123>; rel="discovery"</span></span></code></pre>
But the client caches this URL. If the server starts returning a different</em> URL in the Link header, the client won't notice until... when exactly?</p>
The discovery document at /d/abc123</code> is immutable and cached forever. The client has no reason to re-fetch it. And it has no reason to make other requests that would reveal the new Link header. We've created an immortal cache entry.</p>
The obvious fix: use ETag</code> and If-None-Match</code> for cache revalidation.</p>
w.</span>Header</span>().</span>Set</span>(</span>"Cache-Control"</span>,</span> "max-age=300"</span>)</span>  // 5 minutes</span></span>
w.</span>Header</span>().</span>Set</span>(</span>"ETag"</span>,</span> `"`</span> +</span> hash</span> +</span> `"`</span>)</span></span>
</span>
if</span> r.Header.</span>Get</span>(</span>"If-None-Match"</span>)</span> ==</span> expectedETag {</span></span>
    w.</span>WriteHeader</span>(http.StatusNotModified)</span></span>
    return</span></span>
}</span></span></code></pre>
This works: after 5 minutes, the client revalidates. If the content hasn't changed, it gets a quick 304. If it has, it gets the new content.</p>
But there's a wrinkle. I want to support deploying discovery documents to a CDN or static file server (probably S3 fronted by a CDN, to be honest). If we rely on each of these URLs sending a 404 or a redirect then we need to either update every URL ever published when we make a change (to redirect to the new location), maintain a very long chain of redirects, or rely on out of band behavior if they start 404'ing (know to go fetch something which will include the new Link header). YUCK.</p>
So, a layer of indirection solves everything, right? What if we separate "what's the current discovery document?" from "what's in that document?"</p>

A pointer</strong> (/d/current</code>) that says "the current discovery is at /d/abc123</code>"</li>
The content</strong> (/d/abc123</code>) which is truly immutable</li>
</ul>
The pointer can have a short cache lifetime. The content can be cached forever. When the content changes:</p>

Deploy new content at /d/xyz789</code></li>
Update the pointer to redirect to /d/xyz789</code></li>
Clients' cached pointers expire after 5 minutes</li>
They fetch the pointer, get redirected to the new content</li>
Old content at /d/abc123</code> can stay around (or be garbage collected later)</li>
</ol>
The built-in policy server is in Go, so the redirect handler is trivial:</p>
func</span> NewDiscoveryRedirectHandler</span>(</span>hash</span> string</span>)</span> http</span>.</span>HandlerFunc</span> {</span></span>
    return func</span>(</span>w</span> http</span>.</span>ResponseWriter</span>,</span> r</span> *</span>http</span>.</span>Request</span>) {</span></span>
        w.</span>Header</span>().</span>Set</span>(</span>"Cache-Control"</span>,</span> "max-age=300"</span>)</span></span>
        w.</span>Header</span>().</span>Set</span>(</span>"Location"</span>,</span> "/d/"</span>+</span>hash)</span></span>
        w.</span>WriteHeader</span>(http.StatusFound)</span></span>
    }</span></span>
}</span></span></code></pre>
The content handler remains unchanged with immutable caching:</p>
w.</span>Header</span>().</span>Set</span>(</span>"Cache-Control"</span>,</span> "max-age=31536000, immutable"</span>)</span></span></code></pre>
The Link header now always points to /d/current</code>:</p>
w.</span>Header</span>().</span>Set</span>(</span>"Link"</span>,</span> "</d/current>; rel=</span>\"</span>discovery</span>\"</span>"</span>)</span></span></code></pre>
HTTP caches handle this beautifully:</p>

Client requests /d/current</code></li>
Gets 302 redirect to /d/abc123</code> with max-age=300</code></li>
Follows redirect, gets content with immutable</code></li>
Both responses are cached appropriately</li>
After 5 minutes, the redirect expires</li>
Next request fetches /d/current</code> again</li>
Might get same redirect (cache hit on content) or new one</li>
</ol>
The content-addressed URLs can be served from anywhere: a CDN, S3, a static file server. They never need invalidation logic. The redirect endpoint is the only "dynamic" part, and it's just returning a Location header.</p>
The final implementation is about 10 lines of code. Most of the work was figuring out the right design :-)</p>
The best part: this doesn't mandate a specific implementation. The contract between client and server is just "respect HTTP caching headers."</p>
A policy server could:</p>

Use this same redirect pattern</li>
Use ETag with conditional requests</li>
Use a short max-age</code> without immutable</code></li>
Some other scheme entirely</li>
</ul>
As long as the server sets appropriate Cache-Control</code> headers and the client respects them, it works. The client just uses a standard RFC 7234 compliant HTTP cache (in my case, github.com/gregjones/httpcache</code></a>.</p>
Sometimes the best solution is realizing HTTP already solved your problem decades ago.</p>
Want to try Epithet? Check out the GitHub repo</a>.</em></p>


Kong + CUE
Brian McCallister — Mon, 08 Dec 2025 00:00:00 +0000
Kong</a> is my go-to CLI parser in go, so I used it for epithet</a>. It has pretty good built-in configuration handling, I appreciate how it lines up config values with CLI flags by basically treating config as a serialized tree of it's structs. This is great for simple things, but for epithet I needed slightly more complex mapping, with dynamic keys (user identities) and such. I wanted to keep the core of its model though as it's really nice.</p>
So, I wrote a thing to configure it using CUE</a>. CUE seems complicated if you read its docs, because it dives straight into it's prolog-y evaluation roots, but you can basicaly ignore that for simple use cases (and then use it for hairy ones). It turns out I really liked this, so extracted it to a library, meet kongcue</a>.</p>
It works mostly like the built-in Kong config mechanism, except it happily handles YAML, JSON, and CUE syntax, unifies across multiple files elegantly, and allows me to treat validation issues as configuration</em> issues (with useful error messages, lone and column pointers, etc) if you use a config file, or fallback to kong's flag based errors if you don't use a config file. It can also simply generate a CUE schema file for artbitrary config documentation and validation!</p>
Example time! Let's take a small hello-world style kong app</a>:</p>
package</span> main</span></span>
</span>
import</span> (</span></span>
	"</span>fmt</span>"</span></span>
</span>
	"</span>github.com/alecthomas/kong</span>"</span></span>
	"</span>github.com/brianm/kongcue</span>"</span></span>
)</span></span>
</span>
func</span> main</span>() {</span></span>
	var</span> c</span> cli</span></span>
	ktx</span> :=</span> kong.</span>Parse</span>(</span>&</span>c, kongcue.</span>AllowUnknownFields</span>(</span>"messy"</span>))</span></span>
	ktx.</span>FatalIfErrorf</span>(ktx.</span>Run</span>(c))</span></span>
}</span></span>
</span>
type</span> cli</span> struct</span> {</span></span>
	Name</span>      string</span>            `default:"world" help:"The name of the person to greet"`</span></span>
	Stuff</span>     bool</span>              `required:"" help:"A required flag, about stuff"`</span></span>
</span>
	Greet</span>     GreetCmd</span>          `cmd:"" help:"Issue a greeting"`</span></span>
	Depart</span>    DepartCmd</span>         `cmd:"" help:"Issue a valediction"`</span></span>
</span>
	Config</span>    kongcue</span>.</span>Config</span>    `default:"./example.{yml,json,cue}" sep:";" help:"Config file paths"`</span></span>
	ConfigDoc</span> kongcue</span>.</span>ConfigDoc</span> `cmd:"" help:"Print config schema"`</span></span>
</span>
	message</span> string</span></span>
}</span></span>
</span>
type</span> GreetCmd</span> struct</span> {</span></span>
	Excited</span> int</span> `default:"0" help:"How excited are you to see this person?"`</span></span>
}</span></span>
</span>
func</span> (</span>g </span>GreetCmd</span>)</span> Run</span>(</span>c</span> *</span>cli</span>)</span> error</span> {</span></span>
	// elided</span></span>
}</span></span>
</span>
type</span> DepartCmd</span> struct</span> {</span></span>
	Sadness</span> int</span> `help:"How sad are you to be leaving?" required:""`</span></span>
}</span></span>
</span>
func</span> (</span>g </span>DepartCmd</span>)</span> Run</span>(</span>c</span> *</span>cli</span>)</span> error</span> {</span></span>
	// elided</span></span>
}</span></span></code></pre>
It has a couple sub-commands, some flags, all of it is just demo-ware. Note the lines:</p>
	Config    kongcue.Config</span>    `default:"./example.{yml,json,cue}" sep:";" help:"Config file paths"`</span></span>
	ConfigDoc kongcue.ConfigDoc</span> `cmd:"" help:"Print config schema"`</span></span></code></pre>
These set up configuration handling, and a sub-command to dump the schema and documentation! This does what it looks like, globs across the possible config file names, loads all that match, etc. The schema part is nifty, as it generats config docs, effectively. Invoke example config-doc</code> and you get:</p>
// Configuration schema for validating config files.</span></span>
//</span></span>
// This schema is written in CUE, a configuration language that</span></span>
// validates and defines data. Learn more at https://cuelang.org</span></span>
//</span></span>
// To validate your config file against this schema:</span></span>
//   1. Save this schema to a file (e.g., schema.cue)</span></span>
//   2. Run: cue vet -d '#Root' schema.cue your-config.yaml</span></span>
//</span></span>
// Fields marked with ? are optional. Fields without ? are required.</span></span>
#Root:</span> close</span>({</span></span>
	// The name of the person to greet</span></span>
	name?:</span> string</span></span>
	// A required flag, about stuff</span></span>
	stuff:</span> bool</span></span>
	// Issue a greeting</span></span>
	greet?: #Greet</span></span>
	// Issue a valediction</span></span>
	depart?: #Depart</span></span>
	messy?:</span>  _</span></span>
})</span></span>
#Depart:</span> close</span>({</span></span>
	// How sad are you to be leaving?</span></span>
	sadness:</span> int</span></span>
})</span></span>
#Greet:</span> close</span>({</span></span>
	// How excited are you to see this person?</span></span>
	excited?:</span> int</span></span>
})</span></span></code></pre>
While this is a bit obscure, it is not that hard to follow even if you are not familiar with CUE's schema/constraint declarations.</p>
If you invoke it with a bad config file, you get a nice config error:</p>
kongcue/example</span> on  main ❯ cat bad.yml</span></span>
name:</span> "test"</span></span>
stuff:</span> "walrus"</span></span>
kongcue/example</span> on  main ❯</span></span>
kongcue/example</span> on  main ❯ go build</span> &&</span> ./example</span> --config</span> ./bad.yml</span></span>
example:</span> error: stuff: conflicting values "walrus" and bool</span> (mismatched</span> types string and bool</span>):</span></span>
                    /Users/brianm/src/github.com/brianm/kongcue/example/bad.yml:2:8</span></span>
kongcue/example</span> on  main ❯</span></span></code></pre>
Without a config file (default is not present, none specified) it gives you CLI oriented errors:</p>
kongcue/example</span> on  main ❯ ./example</span></span>
example:</span> error: missing flags:</span> --stuff</span></span>
kongcue/example</span> on  main ❯</span></span></code></pre>
It has a simple escape hatch for non-CLI compatible config sections, which you see in the above example:</p>
	ktx</span> :=</span> kong.</span>Parse</span>(</span>&</span>c, kongcue.</span>AllowUnknownFields</span>(</span>"messy"</span>))</span></span></code></pre>
This allows the messy</code> thing in the example config, even though it does not appear in the kong struct tree.</p>
name</span>:</span> "Brian"</span></span>
stuff</span>:</span> true</span></span>
depart</span>:</span></span>
  sadness</span>:</span> 3</span></span>
messy</span>:</span></span>
  woof</span>:</span> "meow"</span></span>
  splat</span>:</span> 7</span></span></code></pre>
The kongcue.AllowUnknownFields("messy")</code> tells it to just accept anything in the messy</code> value. At some point I'll add a mechanism to define a schema for these, but for now it just relies on deserializing to structs erroring out.</p>
The cue.Value</code> for the config tree is made available as a kong binding, so you can get it in whatever command you need to pull additional values from. This allows epithet policy configs like:</p>
users</span>:</span></span>
  alice@example.com</span>: [</span>admin</span>,</span> eng</span>]</span></span>
  bob@example.com</span>: [</span>eng</span>]</span></span>
  charlie@example.com</span>: [</span>ops</span>]</span></span>
  diana@example.com</span>: [</span>admin</span>,</span> ops</span>]</span></span></code></pre>
which can be defined nicely in CUE, but not naturally kong's cli constraints.</p>
For a more complex, and real, schema generated from epithet, take a look at epithet's:</p>
// Configuration schema for validating config files.</span></span>
//</span></span>
// This schema is written in CUE, a configuration language that</span></span>
// validates and defines data. Learn more at https://cuelang.org</span></span>
//</span></span>
// To validate your config file against this schema:</span></span>
//   1. Save this schema to a file (e.g., schema.cue)</span></span>
//   2. Run: cue vet -d '#Root' schema.cue your-config.yaml</span></span>
//</span></span>
// Fields marked with ? are optional. Fields without ? are required.</span></span>
#Root:</span> close</span>({</span></span>
	// Print version information</span></span>
	version?:</span> bool</span></span>
	// Increase verbosity (-v for debug, -vv for trace)</span></span>
	verbose?:</span> int</span></span>
	// Path to log file (supports ~ expansion)</span></span>
	log_file?:</span> string</span></span>
	// Disable TLS certificate verification (NOT RECOMMENDED)</span></span>
	insecure?:</span> bool</span></span>
	// Path to PEM file with trusted CA certificates</span></span>
	tls_ca_cert?:</span> string</span></span>
	// Start the epithet agent (or use 'agent inspect' to inspect state)</span></span>
	agent?: #Agent</span></span>
	// Invoked during ssh invocation in a 'Match exec ...'</span></span>
	match?: #Match</span></span>
	// Run the epithet CA server</span></span>
	ca?: #Ca</span></span>
	// Run the policy server with OIDC-based authorization</span></span>
	policy?: #Policy</span></span>
	// Authentication commands (OIDC, SAML, etc.)</span></span>
	auth?: #Auth</span></span>
})</span></span>
#Agent:</span> close</span>({</span></span>
	// Match patterns</span></span>
	match?: [...</span>string</span>]</span></span>
	// CA URL (repeatable, format: priority=N:https://url or https://url)</span></span>
	ca_url?: [...</span>string</span>]</span></span>
	// Authentication command</span></span>
	auth?:</span> string</span></span>
	// Per-request timeout for CA requests</span></span>
	ca_timeout?:</span> int</span></span>
	// Circuit breaker cooldown for failed CAs</span></span>
	ca_cooldown?:</span> int</span></span>
	// Start the epithet agent</span></span>
	start?: #AgentStart</span></span>
	// Inspect broker state (certificates, agents)</span></span>
	inspect?: #AgentInspect</span></span>
})</span></span>
#AgentInspect:</span> close</span>({</span></span>
	// Broker socket path (overrides config-based discovery)</span></span>
	broker?:</span> string</span></span>
	// Output in JSON format</span></span>
	json?:</span> bool</span></span>
})</span></span>
#AgentStart:</span> close</span>({})</span></span>
#Auth:</span> close</span>({</span></span>
	// Authenticate using OIDC/OAuth2 (Google Workspace, Okta, Azure AD, etc.)</span></span>
	oidc?: #AuthOidc</span></span>
})</span></span>
#AuthOidc:</span> close</span>({</span></span>
	// OIDC issuer URL (e.g., https://accounts.google.com)</span></span>
	issuer:</span> string</span></span>
	// OAuth2 client ID</span></span>
	client_id:</span> string</span></span>
	// OAuth2 client secret (optional if using PKCE)</span></span>
	client_secret?:</span> string</span></span>
	// OAuth2 scopes (comma-separated)</span></span>
	scopes?: [...</span>string</span>]</span></span>
})</span></span>
#Ca:</span> close</span>({</span></span>
	// URL for policy service</span></span>
	policy:</span> string</span></span>
	// Path to ca private key</span></span>
	key?:</span> string</span></span>
	// Address to listen on</span></span>
	listen?:</span> string</span></span>
})</span></span>
#Match:</span> close</span>({</span></span>
	// Remote host (%h)</span></span>
	host:</span> string</span></span>
	// Remote port (%p)</span></span>
	port:</span> int</span></span>
	// Remote user (%r)</span></span>
	user:</span> string</span></span>
	// Connection hash (%C)</span></span>
	hash:</span> string</span></span>
	// ProxyJump configuration (%j)</span></span>
	jump?:</span> string</span></span>
	// Broker socket path</span></span>
	broker?:</span> string</span></span>
})</span></span>
#Policy:</span> close</span>({</span></span>
	// Address to listen on</span></span>
	listen?:</span> string</span></span>
	// OIDC issuer URL</span></span>
	oidc_issuer?:</span> string</span></span>
	// OIDC audience (client ID)</span></span>
	oidc_audience?:</span> string</span></span>
	// CA public key (URL, file path, or literal SSH key)</span></span>
	ca_pubkey?:</span> string</span></span>
	// Default certificate expiration (e.g., 5m)</span></span>
	default_expiration?:</span> string</span></span>
	users?:</span>              _</span></span>
	defaults?:</span>           _</span></span>
	hosts?:</span>              _</span></span>
})</span></span></code></pre>
It's not good</em> docs, but it directly generated from the code, so it is at least accurate, and close to free :-)</p>
I think the CUE website does a pretty bad job of explaining its value, to be honest. It's a darned useful tool even in the small. The website just hides that basic usefulness behind piles of articles of the "look at all the really powerful stuff it can do" for advanced cases.</p>


Setting up Epithet as of v0.1.7
Brian McCallister — Sun, 30 Nov 2025 00:00:00 +0000
The Goal</h2>
We want to set up a real epithet</a> system, end to end, and use it. Because everything is self hosted, there are a number of steps:</p>

Install epithet on your local Mac</li>
Configure an SSO provider</li>
Set up CA and Policy services</li>
Configure the epithet agent</li>
Create a cloud-init config for new VMs to rely on the CA</li>
Actually SSH to the VM!</li>
Run epithet as a daemon</li>
Cleaning up config and playing around

</li>
</ol>
Prerequisites</h2>
Have tofu</code> and awscli</code> installed. Make sure you have configured awscli</code>. You will need to run this on a machine capable of spawning a web browser you interract with, so if you are doing it on a VM or such, do it under X (or Wayland, VNC, etc). The article assumes you are on a Mac, because I am, but it should adapt alright if you are on a flavor of linux or whatnot. I have not tried any of this on Windows yet. If it works, let me know!</p>
Install epithet on your local machine</h2>
As mentioned, I'm working on a Mac, and use Homebrew, so this article is kind of oriented around that:</p>
brew install epithet-ssh/tap/epithet</span></span></code></pre>
If you are not on a mac, or not using homebrew, you will need to build and install it yourself. Clone epithet</a> and check out v0.1.7</code> which is the version this article is written against. It's implemented in Go, so you'll need that installed. You can build it with make</code>:</p>
git clone https://github.com/epithet-ssh/epithet/</span></span>
cd epithet</span></span>
git checkout v0.1.7</span></span>
make epithet # or just `make` if you want to run the tests</span></span></code></pre>
If you built it youself, put the binary somewhere on your $PATH</code>. If you don't have it on your $PATH</code>, later stuff we do will be trickier, and changing the examples to use the full path is an exercise left to you.</p>
Configure an SSO provider</h2>
We'll use Google for SSO, but you could as easily use Microsoft, Apple, AWS (Cognito), Facebook, Github, Gitlab, Okta, Yahoo!, Keycloak, Authentik, and so on. OIDC/OAuth2 is pretty widespread nowadays, and you don't need a full IDP (ie, a full SCIM provider) for Epithet, just someone to provide identity at the other end of OIDC. I'm using Google because GMail is widely used, so it is useful for many people.</p>

Go to Google Cloud Console</a></li>
Select or create a project</li>
Navigate to APIs & Services → Credentials</li>
Configure a consent screen</li>
Add a name for your App, I used "Epithet Demo"</li>
For Audience, if you are using Google Workspace you can make it Internal and be good to go. If using general GMail, then make it External. I am making this demo External.</li>
This dropped me on a screen with a "Create OAuth Client" -- which I picked. If you are getting there differently it is fine, you need to create an OAuth Client/Credential.</li>
Choose Application type: I use Universal Windows Platform (UWP). Despite the name, it is not limited to Windows apps, and it does PKCE. "Desktop App" does not support PKCE, so you need to embed the OAuth secret in the agent config. The internet tells me this is fine, and secure, and the secret is not really a secret. I want to just use PKCE, so I use UWP here.</li>
Enter a name: I used "Epithet Agent"</li>
If you are using UWP you will need to include a Store ID, I don't believe it is used anywhere. I used "epithet-demo"</li>
Click Create</li>
Make note of the Client ID.</li>
Select the "Audience" tab on the left.</li>
In the "Test Users" section add a couple users (email addresses) who you want to be able to use the app. I added a couple google accounts I have, a general public one which I am using to set up this demo, and a Workspace email that I actually use for things. I set up two so that I can configure different policies for them later. If you created an "Internal" app type earlier, you can skip this step -- your Workspace users should be able to use the app automagically.



</li>
</ol>
You can test the configuration using the epithet auth oidc</code> command:</p>
echo "" | epithet -vvv auth oidc --issuer=https://accounts.google.com --client-id=<OAUTH_CLIENT_ID> 3>/dev/null</span></span></code></pre>
Note, use your</em> client id, not the <OAUTH_CLIENT_ID></code> placeholder. Also note the echo "" |</code> at the beginning and 3>/dev/null</code> at the end: these are for epithet's auth plugin protocol, which expects input on stdin and to write state to FD 3. This should pop up the authentication flow and if you log in will let you know it was successful and show you the auth token.</p>
In my case, it was successful, so I am moving on!</p>
Set up CA and Policy services</h2>
These are generally low volume things which are more or less perfect use cases for FaaS platforms. Because AWS is the most popular I made Lambda wrappers for epithet's built in basic CA and Policy services. Start by cloning the repo</a> for them, which contains the terraform (tofu) configs to actually set them up (as well as the wrapper code if you want to play with it). I set it up as a template repo, so you can use the "Use this template" to clone it in Github if you like. Make sure to set the privacy to "Private" if you do -- it can</em> be public, but Github will complain about you checking in your OAuth Client ID if you do.</p>
git clone https://github.com/epithet-ssh/epithet-aws epithet-demo</span></span>
cd epithet-demo</span></span></code></pre>Configuring the Policy Server</h3>
Now, let's do some basic configuration for the deployment. We do this with some terraform variables, created and edit terraform/terraform.tfvars</code>:</p>
aws_region     = "us-east-1"</span></span>
project_name   = "epithet-demo"</span></span></code></pre>
I am using us-east-1</code> for the demo (unofficial designated demo region) and picked a name (epithet-demo</code>).</p>
Now we need to make a basic policy for the Policy service. It should be in config/policy.yaml</code>. I'm going to use:</p>
# CA public key is loaded from SSM Parameter Store at runtime</span></span>
# This placeholder satisfies config validation</span></span>
ca_public_key</span>:</span> "placeholder - loaded from SSM"</span></span>
</span>
oidc</span>:</span></span>
  issuer</span>:</span> "https://accounts.google.com"</span></span>
  audience</span>:</span> "<OAUTH_CLIENT_ID>"</span></span>
</span>
users</span>:</span></span>
  "brianm@skife.org"</span>: [</span>"wheel"</span>]</span></span>
  "brian.mccallister@gmail.com"</span>: [</span>"dev"</span>]</span></span>
</span>
defaults</span>:</span></span>
  allow</span>:</span></span>
    arch</span>: [</span>"dev"</span>,</span> "wheel"</span>]</span></span>
  expiration</span>:</span> "5m"</span></span>
</span>
#hosts:</span></span>
#  "prod-*.example.com":</span></span>
#    allow:</span></span>
#      deploy: ["dev"]</span></span>
#    expiration: "2m"</span></span></code></pre>
Let's talk about what it does and how it works.</p>
The Policy server needs the CA's public key in ca_public_key</code> as it validates requests that come with it (the CA signs them using the CA private key). For the Lambda wrapper we load the public key from AWS's config service (SSM) so the actual configuration value is ignored.</p>
The oidc</code> section needs to know the provider URL (issuer</code>) and the client id (called audience</code> here, for OIDC reasons). Put your client id for the audience</code> attribute.</p>
The users</code> section configures allowed users. The built-in Policy
server uses static configurations, so it needs to know which users are
allowed to use it, up front. Additionally, it uses a group-style
matching system and assumes that "remote-user == principal". For demo
purposes I use two groups, wheel</code> and dev</code>, but that choice is
arbitrary. It also has no</em> relationship to actual unix groups on the
hosts -- it is purely used internally for matching users to principals
in the policy server. I configured two users so I can mess around later and experiment.</p>
The defaults</code> section establishes defaults for host configuration. In this case it gives the arch</code> principal to anyone in the dev</code> or wheel</code> group, unless overridden for a specific host. We also set up a 5 minute expiration for certificates.</p>
Finally, the hosts</code> section lets you do per-host configration. It is a map of host-glob -> config. I have it commented out for now, but am leaing it as a reminded for playing around later.</p>
This overall config means that, assuming one of the users authenticates successfully (which it checks), it will issue a cert for any remote host and remote user with the arch</code> principal. I used that principal because I am going to use Arch Linux cloud images to test things, and those provision the arch</code> user by default.</p>
Deploy the services</h3>
I am not</em> going to step through setting up a new AWS acount for you, so I'll prefix this next section by saying -- have an AWS account, and have the aws-cli configured to use it!</p>
make init</span></span>
make apply</span></span></code></pre>
Watch tofu set up a pile of stuff in AWS:</p>

API Gateway for CA</li>
API Gateway for Policy</li>
IAM policies</li>
Secret to hold the private key</li>
SSM to hold the public key</li>
S3 bucket to keep certificate log in</li>
Other stuff, look in terraform/</code> of the repo you cloned for everything. I believe there are 32 things total it sets up.

</li>
</ol>
When it is finished it will spit out a bunch of information for you:</p>
ca_public_key = <sensitive></span></span>
ca_public_key_command = "aws ssm get-parameter --name /epithet-demo-9230323c/ca-public-key --query Parameter.Value --output text"</span></span>
ca_public_key_parameter = "/epithet-demo-9230323c/ca-public-key"</span></span>
ca_secret_arn = "arn:aws:secretsmanager:us-east-1:378899212612:secret:epithet-demo-9230323c-ca-key-encO9c"</span></span>
ca_secret_name = "epithet-demo-9230323c-ca-key"</span></span>
ca_url = "https://ir6kilkap3.execute-api.us-east-1.amazonaws.com/"</span></span>
cert_archive_bucket = "epithet-demo-9230323c-cert-archive"</span></span>
cert_archive_bucket_arn = "arn:aws:s3:::epithet-demo-9230323c-cert-archive"</span></span>
policy_url = "https://e2np6k2uj5.execute-api.us-east-1.amazonaws.com"</span></span>
region = "us-east-1"</span></span></code></pre>
Save this info somewhere, you will need the CA URL later, and you may want to poke around the S3 bucket where info about issued certs is stored, or look at the various logs.</p>
But we are not done, we need to actually make the CA key and upload it:</p>
make setup-ca-key</span></span></code></pre>
We have to create the key pair after we provision everything else because we need the Secret and SSM to be created in AWS before we can put the private and public keys in them respectively.</p>
You can test if the CA is running by issuing a GET to it, it should return the public key:</p>
epithet-demo took 3s [!?] on  main ❯ xh GET https://ir6kilkap3.execute-api.us-east-1.amazonaws.com/</span></span>
HTTP/2.0 200 OK</span></span>
apigw-requestid: U35tYhMyoAMEcRw=</span></span>
content-length: 81</span></span>
content-type: text/plain</span></span>
date: Sun, 30 Nov 2025 20:03:46 GMT</span></span>
</span>
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIiLCOTQVHFqu7zP5j3KCjrfYavXqk7wasuckA6QvQgP</span></span>
</span>
epithet-demo [!?] on  main ❯</span></span></code></pre>
I should probably put the same kind of smoke test on the policy server, now that I think about it.</p>
Despite having made a pile of AWS resources, most of them are cheap and idle, so for a couple of users authenticating a few times a day, it should cost under a dollar a month. Sometimes the cloud is kind of cool.</p>
Configure the epithet agent</h2>
Okay, we have the system up, let's configure our agent to use it! Epithet uses ~/.epithet/</code> for its various configs and running stat. Yes, this is not XDG style. I am open to XDG, but this seems simpler and is not totally unexpected.</p>
cd ~/.epithet</span></span>
$EDITOR ./config</span></span></code></pre>
Add content like:</p>
ca-url      <Your CA URL></span></span>
match       *</span></span>
auth        epithet auth oidc --issuer https://accounts.google.com --client-id <YOUR OAUTH CLIENT ID></span></span>
</span></code></pre>
This config is fine for testing, for now, but the match *</code> line is not something we'll want to leave in long term -- it is telling epithet that it should be used for every</em> attempted connection, which we probably don't want. Once we have a VM or three to try against, we'll constrain it down.</p>
We also need to tell SSH to use epithet, to do this we drop a line in ~/.ssh/config</code>:</p>
Include ~/.epithet/run/*/ssh-config.conf</span></span></code></pre>
Do this somewhere near the top, and definitely before anywhere you might set up an ssh agent socket.</p>
Now, to debug we will start the agent manually -- run:</p>
epithet -vvv agent</span></span></code></pre>
You should get some debug log output.</p>
Create a cloud-init config for new VMs to rely on the CA</h2>
cloud-init</h3>
So the easiest way I have found for basic setup of a new vm is cloud-init</code>, every major distribution and provider supports it, including my favorite, vm-bhyve</a> (which is not really a major provider, but what I use to manage VMs on my machines).</p>
We'll make a user-data config for cloud-init</code> which configures sshd to respect our CA key. Make a file named user-data</code> in your current directory which contains:</p>
#cloud-config</span></span>
resize_rootfs</span>:</span> True</span></span>
manage_etc_hosts</span>:</span> localhost</span></span>
write_files</span>:</span></span>
  -</span> path</span>:</span> /etc/ssh/epithet_ca.pub</span></span>
    content</span>:</span> |</span></span>
      ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIiLCOTQVHFqu7zP5j3KCjrfYavXqk7wasuckA6QvQgP</span></span>
    owner</span>:</span> root:root</span></span>
    permissions</span>:</span> '0644'</span></span>
</span>
  -</span> path</span>:</span> /etc/ssh/sshd_config.d/100-epithet.conf</span></span>
    content</span>:</span> |</span></span>
      TrustedUserCAKeys /etc/ssh/epithet_ca.pub</span></span>
    owner</span>:</span> root:root</span></span>
    permissions</span>:</span> '0644'</span></span></code></pre>
But instead of using the public key for my CA (ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIiLCOTQVHFqu7zP5j3KCjrfYavXqk7wasuckA6QvQgP</code>) use the one for your</em> CA.</p>
This creates two files in /etc/ssh/</code> -- one with the public key, and one which tells sshd to trust that public key.</p>
A VM</h3>
Okay, so we have a CA, an agent, and some cloud-init config, but we still need a server to use it on. Since we have used AWS so far, let's keep using it. Sadly, EC2 is pretty painful for basic VM setup nowadays. That said, we'll do it.</p>
For this, I am going to set up in a region I never use, so that I have to do things from scratch. Clean slate makes for good demo. If you have a VPC you like, which allows SSH ingress, then you can skip the setup for the most part and just spin up your instance there. If not, hang on, we have some AWS to do.</p>
I am going to us us-east-2</code> because I have never used it before. If you pick a different region you will need to find the Arch AMI for that region. You can find them at arch-ami-list.drzee.net</a>. For us-east-2</code> the AMI is ami-0c87f4f769e675bf8</code>.</p>
If you are in bash or a regular sh:</p>
# Create a default VPC (if one doesn't exist)</span></span>
aws ec2 create-default-vpc --region us-east-2</span></span>
</span>
# Create security group for SSH</span></span>
sg_id=$(aws ec2 create-security-group \</span></span>
  --region us-east-2 \</span></span>
  --group-name ssh-access \</span></span>
  --description "SSH access" \</span></span>
  --query 'GroupId' --output text)</span></span>
</span>
# Allow inbound SSH</span></span>
aws ec2 authorize-security-group-ingress \</span></span>
  --region us-east-2 \</span></span>
  --group-id $sg_id \</span></span>
  --protocol tcp \</span></span>
  --port 22 \</span></span>
  --cidr 0.0.0.0/0</span></span>
</span>
# Launch the instance</span></span>
instance_id=$(aws ec2 run-instances \</span></span>
  --region us-east-2 \</span></span>
  --image-id ami-0c87f4f769e675bf8 \</span></span>
  --instance-type t3.micro \</span></span>
  --security-group-ids $sg_id \</span></span>
  --user-data file://./user-data \</span></span>
  --query 'Instances[0].InstanceId' --output text)</span></span>
</span>
# Wait for it to be running</span></span>
aws ec2 wait instance-running --region us-east-2 --instance-ids $instance_id</span></span>
</span>
# Get the public IP</span></span>
ip=$(aws ec2 describe-instances \</span></span>
  --region us-east-2 \</span></span>
  --instance-ids $instance_id \</span></span>
  --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)</span></span>
</span>
echo $ip</span></span></code></pre>
If you are in fish, like me:</p>
# Create a default VPC (if one doesn't exist)</span></span>
aws ec2 create-default-vpc --region us-east-2</span></span>
</span>
# Create security group for SSH</span></span>
set sg_id (aws ec2 create-security-group \</span></span>
  --region us-east-2 \</span></span>
  --group-name ssh-access \</span></span>
  --description "SSH access" \</span></span>
  --query 'GroupId' --output text)</span></span>
</span>
# Allow inbound SSH</span></span>
aws ec2 authorize-security-group-ingress \</span></span>
  --region us-east-2 \</span></span>
  --group-id $sg_id \</span></span>
  --protocol tcp \</span></span>
  --port 22 \</span></span>
  --cidr 0.0.0.0/0</span></span>
</span>
# Launch the instance</span></span>
set instance_id (aws ec2 run-instances \</span></span>
  --region us-east-2 \</span></span>
  --image-id ami-0c87f4f769e675bf8 \</span></span>
  --instance-type t3.micro \</span></span>
  --security-group-ids $sg_id \</span></span>
  --user-data file://./user-data \</span></span>
  --query 'Instances[0].InstanceId' --output text)</span></span>
</span>
# Wait for it to be running</span></span>
aws ec2 wait instance-running --region us-east-2 --instance-ids $instance_id</span></span>
</span>
# Get the public IP</span></span>
set ip (aws ec2 describe-instances \</span></span>
  --region us-east-2 \</span></span>
  --instance-ids $instance_id \</span></span>
  --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)</span></span>
</span>
echo $ip</span></span></code></pre>
Note that when we made this VM we did not</em> give it a public key. The only</em> way to access it is via a certificate it trusts!</p>
Actually SSH to the VM!</h2>
Given the above, we can ssh in:</p>
ssh arch@$ip</span></span></code></pre>
It should pop a browser which asks you to log in, which you should do. When everything authenticates you should be back in ssh, and be able to connect:</p>
epithet-demo [!?] on  main ❯ ssh arch@$ip</span></span>
       .</span></span>
      / \</span></span>
     /   \</span></span>
    /^.   \     Arch Linux AMI (std)</span></span>
   /  .-.  \    https://archlinux.org/</span></span>
  /  (   ) _\</span></span>
 / _.~   ~._^\</span></span>
/.^         ^.\ TM</span></span>
[arch@ip-172-31-46-139 ~]$</span></span></code></pre>
Yea!</p>
If you look over at the agent there will be a bunch of debug output showing what it did.</p>
If you log out (or open a new terminal) you can inspect the state of the epithet agent:</p>
epithet inspect</span></span></code></pre>
Which will show you the ssh agent sockets it has running and the certs it has:</p>
Broker State</span></span>
============</span></span>
</span>
Socket: /Users/brianm/.epithet/run/d6d98793bf4b428a/broker.sock</span></span>
Agent Dir: /Users/brianm/.epithet/run/d6d98793bf4b428a/agent</span></span>
Match Patterns: [*]</span></span>
</span>
Agents (1)</span></span>
-----------</span></span>
  8fea92165cf18c9783b9b4e9b30ac50c559dd352</span></span>
    Socket: /Users/brianm/.epithet/run/d6d98793bf4b428a/agent/8fea92165cf18c9783b9b4e9b30ac50c559dd352</span></span>
    Expires: 2025-11-30T13:45:52-08:00 (valid, 2m17s)</span></span>
    Certificate: SHA256:cadNJy5p6U7h/tfExl5M5GYZ/kJMpFoPEwf7dvFmGss</span></span>
</span>
Certificates (1)</span></span>
-----------------</span></span>
  [0]</span></span>
    Fingerprint: SHA256:cadNJy5p6U7h/tfExl5M5GYZ/kJMpFoPEwf7dvFmGss</span></span>
    Identity: brianm@skife.org</span></span>
    Principals: [arch]</span></span>
    Valid: 2025-11-30T13:39:52-08:00 to 2025-11-30T13:45:52-08:00 (valid, 2m17s)</span></span>
    Extensions:</span></span>
      permit-agent-forwarding</span></span>
      permit-pty</span></span>
      permit-user-rc</span></span>
    Policy (HostUsers):</span></span>
      *: [arch]</span></span></code></pre>
The cert will expire in a few minutes, but the auth state should last as long as google doesn't want you to reauthenticate and you don't stop the agent. The auth state, certs, etc are all kept only in memory so killing the agent will wipe them out. No big deal, start the agent again and you can reauthenticate!</p>
Run epithet as a daemon</h2>
If you installed via homebrew, it also added a homebrew service. You can enable the homebrew service via:</p>
brew services start epithet</span></span></code></pre>
You can then stop it with stop</code> instead of start, and so on. You need to restart it when you change the config, epithet agent does not pick up on config changes automagically.</p>
Cleaning up config and playing around</h2>
Okay, so now you have a system, go play. The first thing I suggest doing is changing the match statement in ~/.epithet/config</code> to match against just your VM and restarting the agent.</p>
My config now looks like:</p>
ca-url      https://ir6kilkap3.execute-api.us-east-1.amazonaws.com/</span></span>
match       18.220.139.216</span></span>
match       54.190.23.91</span></span>
auth        epithet auth oidc --issuer https://accounts.google.com --client-id <abc123,etc>.apps.googleusercontent.com</span></span></code></pre>
Notice I have two match</code> lines, that is because I spun up a second VM. The match line is used to short circuit what epithet tries to get a certificate for. In my actual day-to-day config it looks like:</p>
ca-url      https://<REDACTED>/</span></span>
match       *.home</span></span>
match       *.barn</span></span>
match       *.brianm.dev</span></span>
auth        /opt/homebrew/bin/epithet auth oidc --issuer https://accounts.google.com --client-id <REDACTED></span></span></code></pre>
Which relies on wildcard matching. Our fooling around VMs don't have useful names to match on, so there we go. Alternately, you could have the policy server reject them, which will also cause matches to fail, but that is a different (and not yet written) article.</p>
To change the policy server config you can edit the config/policy.yaml</code> file and redeploy it via make apply</code>.</p>
When you are done playing, if you want to tear down what we set up, you can run make destroy</code> to tear down the resources tofu made. You'll need to stop your VMs yourself</strong> (aws --region us-east-2 ec2 terminate-instances --instance-ids $instance_id</code>)-- tofu didn't make them for you, it doesn't know about them.</p>
Debugging</h3>
I can hope</em> everything went smoothly for you, but it may not have. If it didn't go smoothly, I have found Claude Code to be extremely</em> good at helping debug terraform/aws stuff. In the repo with the the terraform resources there is a CLAUDE.md</code> and MCP server specs (.mcp.json</code>) for AWS and Terraform respectively. While I used Tofu, not Terraform, the MCP server knows both. If you don't have uv</code> installed, install it (brew install uv</code>) and the MCP servers will work. Fire up claude and ask it to help you debug your issues.</p>


Epithet, v2, Briefly - Part 1
Brian McCallister — Fri, 28 Nov 2025 00:00:00 +0000
I last talked about epithet</a> two years ago, in 2023</a>, when I started kicking around ideas to make it general purpose. I'm pleased with how it's turned out, so I want to start talking about some of the design decisions. I dare not document</em> it yet, for fear someone may use it, but that's probably coming.</p>
Even though it never had a proper 1.0, I am calling this v2 in my head as it is not at all compatible with the previous iteration, and is so much better. The big pieces are the same shape: an Agent, a CA, and a Policy service:</p>
</p>
Agent</h2>
The agent handles authenticating you, obtaining certificates, and deciding which certificate to use for a given connection. It uses a small policy protocol to match certificates against connections based on target host and remote username. Authentication is handled by a plugin system, so you can have arbitrary authenticators. There's a built-in OIDC authenticator, and I imagine I'll add SAML at some point.</p>
Policy Service</h2>
The Policy Service is the brains of the system. It receives authentication and connection information and decides (1) whether to issue a cert, (2) which principals to put on the cert, (3) the cert parameters (expiration, extensions, etc), and (4) a matching policy telling the agent which connections this cert can be used for.</p>
CA</h2>
The CA has access to the CA private key, so I want it to be as simple as possible. As such it delegates decision making about certificates to the policy service and merely issues certs as instructed.</p>
So what's changed and why?</h1>
That looks pretty similar to two years ago, but there are a few key changes I'll dive into over a few posts. Today, the big reasons for the changes:</p>

I want to be able to issue a certificate which allows someone (or some process) to ssh into a specific host as a specific user only, rather than a more wide-open certificate with all of the user's principals. Imagine, if you will, a piece of deployment automation. We want it to be able to ssh as deploy@prod-*.example.com</code> for the next ten minutes. Allowing this should be triggered by a workflow -- either automatically by inspecting if it should</em> be deploying right now, or via a human workflow such as a response in Slack, and so on.</li>
I don't want to bake in assumptions about how identities, principals, and hosts map to each other. The unix-group style set of principals from the previous version is reasonable for many use cases, but not all. It's overkill for simple cases (my personal stuff) and not powerful enough for the hard cases (see above).</li>
I want to coexist better with non-epithet ssh scenarios. Previously users had to carefully craft Match</code> blocks in their ssh config to only use epithet when appropriate. Worse, if the CA or policy server was down</em>, users would need to edit their ssh config to use a fallback. The last</em> thing you want to do in a SEV is edit ssh config.</li>
</ol>


Notes on setting up vm-bhyve
Brian McCallister — Sat, 04 May 2024 00:00:00 +0000
I'm replacing my general/util server at home and want to manage VMs on the new host with vm-bhyve</code></a>. Setting it up is well documented, but running linux VMs still steers folks towards grub, which is not really great. These are just my notes (for later, after I forget) on using cloud images and uefi. This is a supplement to the docs, not a replacement!</p>
I created a template, creatively named brian-linux.conf</code>:</p>
loader="uefi"</span></span>
cpu=2</span></span>
memory=4G</span></span>
network0_type="virtio-net"</span></span>
network0_switch="public"</span></span>
disk0_type="nvme"</span></span>
disk0_dev="sparse-zvol"</span></span>
disk0_name="disk0"</span></span></code></pre>
I'm running on ZFS, so can use sparse-zvol</code> for storage to make disk space only soft allocated, letting me overcommit.</p>
Now, the commands to make things happy and run some cloud images:</p>
# Additional dependencies for vm-bhyve</span></span>
pkg</span> install cdrkit-genisoimage</span>    # to use cloud-init</span></span>
pkg</span> install qemu-tools</span>            # to use cloud images</span></span>
pkg</span> install bhyve-firmware</span>        # to use uefi</span></span>
</span>
# Download some cloud images to use for our VMs</span></span>
vm</span> img https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-uefi-cloudinit-r0.qcow2</span></span>
vm</span> img http://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img</span></span>
</span>
vm</span> create</span>                               \ </span># C-k off comments if you copy this</span></span>
    -t</span> brian-linux</span>                      \ </span># our template, from above</span></span>
    -i</span> noble-server-cloudimg-amd64.img</span>  \ </span># the cloud image</span></span>
    -s</span> 50G</span>                              \ </span># disk size override</span></span>
    -c</span> 4                                \ </span># cpu count override</span></span>
    -m</span> 32G</span>                              \ </span># memory override</span></span>
    -C</span> -k</span> ~brianm/.ssh/id_rsa.pub</span>       \ </span># cloud-init ssh pubkey</span></span>
    v0001</span>                                 # vm name</span></span></code></pre>
Docs cover these, but reminding myself of how I configured it beyond defaults:</p>
vm</span> switch vlan public</span> 4</span>     # use vlan 4 for VMs</span></span>
vm</span> set console=tmux</span>         # tmux for console access</span></span></code></pre>
Nice side effect of using cloud-init</code> is that it logs the DHCP assigned IP address as well, so I can fire up the console and go search for it (C-b C-[ C-s Address</code>)! Probably should write a script to extract it, to be honest.</p>


Alfred Alias Hack
Brian McCallister — Thu, 08 Feb 2024 00:00:00 +0000
I live by Alfred</a> as a launcher and all around insta-utility thing. I also live by whatever terminal I am currently using. Switching from Terminal.app</code> to iTerm.app</code> was easy enough in Alfred, just need to hit the down arrow after trying to launch it 2-3 times and it picks up that ⌘-spc t e r</code> means iTerm.app</code> not Terminal.app</code> and we're off to the races. This works as iTerm nicely has t e r</code> in it, so Alfred picks it up as I type t e r</code>.</p>
Ghostty.app</code> does not</em> include t e r</code> so I have been launching iTerm, quitting iTerm, launching Ghostty, on repeat, all the time. So, the hack to convince Alfred that ⌘-spc t e r</code> means "launch ghostty" (as I have given up on reprogramming my fingers) is as follows:</p>
Create an app alias (in the Finder, right click on Ghostty.app -> Make Alias) and name it "Ter Ghostty.app". This makes a special "MacOS Alias file", not a symlink. Fire up Alfred Preferences and tell it to also search com.apple.alias-file</code> files. This is buried in Default Results -> Advanced</code>. You can drag and drop the newly created alias file into the list to do it, or type carefully.</p>
At that point, Alfred will see the alias and start showing it for default results, and with a few iterations will pick up on th efact that ⌘-spc t e r</code> means Ter Ghostty.app</code> not iTerm.app</code> or so forth:</p>
</p>
This is also useful for any other case where you want to change a default your fingers have memorized (Chrome -> Safari, Vim -> Emacs, Notes -> Obsidian, and maybe someday, Emacs -> Zed).</p>


Ghostty, emacsclient, and terminfo
Brian McCallister — Sun, 04 Feb 2024 00:00:00 +0000
I've been lucky enough to get into the Ghostty</a> beta, and am very happy with it o far. I ran into one real hiccup, and I know</em> I'll forget how I fixed it when I set up my next laptop, so leaving a note for myself (and anyone else who hits it).</p>
Ghostty uses a custom terminfo, xterm-ghostty</code>, and does not</em> install it to the system or user, but specifies a TERMINFO=/Applications/Ghostty.app/Contents/Resources/terminfo</code> environment variable in the process for Ghostty itself. This mostly</em> works great, but not in cases where something started outside Ghostty cares about the terminal capabilities -- such as an emacs daemon :-(</p>
When I started, I was using an emacs daemon controlled by homebrew services</a> as I more or less forget everything about launchd shortly after doing anything with it. Homebrew is clever</em> and replaces the launchd plist every time you start the service, so you cannot edit, boo. I get it, keeps people from breaking things, but boo. So, Step 1, stop using homebrew services to interface to launchd to start my emacas daemon.</p>
Step 2: add my own launchd plist thingie at ~/Library/LaunchAgents/ghostty.emacs.plist</code>. It is derived from the one homebrew uses, which is derived form the venerable mxcl version:</p>
<?</span>xml</span> version</span>=</span>"1.0"</span> encoding</span>=</span>"UTF-8"</span>?></span></span>
<!</span>DOCTYPE</span> plist</span> PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"></span></span>
<</span>plist</span> version</span>=</span>"1.0"</span>></span></span>
  <</span>dict</span>></span></span>
    <</span>key</span>>EnvironmentVariables</</span>key</span>></span></span>
    <</span>dict</span>></span></span>
      <</span>key</span>>TERMINFO</</span>key</span>></span></span>
      <</span>string</span>>/Applications/Ghostty.app/Contents/Resources/terminfo/</</span>string</span>></span></span>
    </</span>dict</span>></span></span>
    <</span>key</span>>KeepAlive</</span>key</span>></span></span>
    <</span>true</span>/></span></span>
    <</span>key</span>>Label</</span>key</span>></span></span>
    <</span>string</span>>ghostty.emacs</</span>string</span>></span></span>
    <</span>key</span>>LimitLoadToSessionType</</span>key</span>></span></span>
    <</span>array</span>></span></span>
      <</span>string</span>>Aqua</</span>string</span>></span></span>
      <</span>string</span>>Background</</span>string</span>></span></span>
      <</span>string</span>>LoginWindow</</span>string</span>></span></span>
      <</span>string</span>>StandardIO</</span>string</span>></span></span>
      <</span>string</span>>System</</span>string</span>></span></span>
    </</span>array</span>></span></span>
    <</span>key</span>>ProgramArguments</</span>key</span>></span></span>
    <</span>array</span>></span></span>
      <</span>string</span>>/opt/homebrew/opt/emacs/bin/emacs</</span>string</span>></span></span>
      <</span>string</span>>--fg-daemon</</span>string</span>></span></span>
    </</span>array</span>></span></span>
    <</span>key</span>>RunAtLoad</</span>key</span>></span></span>
    <</span>true</span>/></span></span>
  </</span>dict</span>></span></span>
</</span>plist</span>></span></span></code></pre>
I changed the label and added the EnvironmentVariables</code> section setting TERMINFO</code>. I stopped the brew service for emacs, started this one, and voila, emacsclient works again: launchctl load -w ~/Library/LaunchAgents/ghostty.emacs.plist</code> :-)</p>
This feels like a somewhat hacky fix, and I think the better way is probably to install the terminfo file for the local user, the way kitty</a> does -- but I want to grok why Mitchell is not</em> doing that before I muck with that!</p>


Epithet, Briefly
Brian McCallister — Thu, 30 Nov 2023 00:00:00 +0000
Since Bob asked</a>, I'm cleaning up a system to make using short-lived ssh certificates easy, simple, and secure.</p>
The gist is to use a custom ssh-agent which, in turn, uses some modern authn service (OIDC, Keycloak, Okta, Google Sign-In, etc) to authenticate you. It then passes that auth token up to a CA which relies on a policy service to verify the auth token and respond with cert params (time, principals, extensions, whatever is needed). The CA uses the policy provided attributes to generate a short lived cert, which it gives back to the agent. Voila, you can access things for a couple minutes.</p>
</p>
There is a real sequence diagram of what is going on in the repo</a>.</p>
CA</h2>
The CA is dirt simple and is the only thing that will ever see the CA private key. The same CA service should be usable by more or less anyone, maybe with some variety in terms of where the private key is stored, but that is it.</p>
The CA receives an opaque auth token + pubkey from the agent and responds with a cert. The existing implementation uses a policy service to decide whether to issue the cert, and what attributes to give it.</p>
The actual CA was kept as simple as possible, because it is a CA. You don't want to muck with it much.</p>
Policy</h2>
The policy service consumes the opaque auth tokens from the CA and reponds with basic info, assuming the auth is valid:</p>
{</span></span>
    "identity"</span>:</span>"brianm@skife.org"</span>,</span></span>
    "principals"</span>:[</span>"oncall_fluffy"</span>,</span> "oncall_wibble"</span>,</span> "wheel"</span>],</span></span>
    "expiration"</span>:</span>"2m"</span>,</span></span>
    "extensions"</span>: {</span></span>
        "permit-pty"</span>:</span>true</span>,</span></span>
        "permit-port-forwarding"</span>:</span>true</span></span>
    }</span></span>
}</span></span></code></pre>
The policy server (single endpoint, takes a post with the context for the request) is nice as it can be dynamic and make use of risk models and various other signals to decide what to do: eg, "is it a deploy server asking for a key? Is there actually a deploy in progress matching the identity requesting the cert? Okay, give it a 5 minute cert" on the sophisticated side; simply checking an OIDC token for validity on the simpler side.</p>
Agent</h2>
The ssh agent generates a new keypair on startup and never lets the private key leave memory. It has a small GRPC API over a domain socket for interfacing with authentication mechanisms, such as a helper to simply feed it tokens over stdin</a> for simple cases. We popped a browser (or used a cli tool</a>) to do the Okta dance.</p>
Michael</a> and I made this at a previous company. We spun up the CA in one lambda function, the policy server in another, and authed against Okta. I want it for my own stuff now and it doesn't look like anyone there is maintaining it anymore, so I have been bringing it back to life.</p>


SSH Certificate Notes
Brian McCallister — Wed, 29 Nov 2023 00:00:00 +0000
There are lots of tutorials out there, but I want to compile my notes so if I walk away from playing with them again for a few years, I can pick it up again!</p>
SSH Keys for different things are all the same (modulo chosen algo type)</h2>
User keys, host keys, CA keys -- they are all the same. Don't let ssh-keygen</code> docs, with all of its options and whatnot, convince you otherwise.</p>
Use AuthorizedPrincipalsFile</code> to manage access</h2>
Don't go and create a local user account for everyone who may be accessing the host, just have a shared local user, probably even root</code>, where you differentiate who did what using the identity on the cert they authed with.</p>
AuthorizedPrincipalsFile</code> is a file that lists the allowed principals for a given local user. Use groups</em> as principals, not individual users, and list the groups which may use the local user in the file for the given local user. The groups an actual user is in are then added to that user's cert.</p>
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u</span></span></code></pre>
The %u</code> is the normal user placeholder, so /etc/ssh/auth_principals/root</code> would control the principals that may log in as root</code>. The file takes one principal per line. Copilot really</em> wants me to add that you can use wildcards in the file, but that idea is making me queasy. Principals as groups sounds better to me.</p>
The overall sshd_config</code> looks something like:</p>
Port {{ port }}</span></span>
Protocol 2</span></span>
AcceptEnv LANG LC_*</span></span>
LoginGraceTime 120</span></span>
</span>
UsePAM no </span></span>
PasswordAuthentication no</span></span>
IgnoreRhosts yes</span></span>
PubkeyAuthentication yes</span></span>
</span>
HostKey {{ path }}/ssh_host_ed25519_key</span></span>
TrustedUserCAKeys {{ path }}/ca.pub</span></span>
AuthorizedPrincipalsFile {{ path }}/auth_principals/%u</span></span></code></pre>Testing with sshd</h2>
You can run sshd as a normal user, as long as you only try to log in as that same user.</p>
Invocation looks like, /opt/homebrew/sbin/sshd -d -D -f /tmp/my_ssh/sshd_config</code>. This will start it without forking behavior, process a single login, and give us debug output.</p>
The sshd_config may need StrictModes no</code> depending on the directories in play and the permissions on them.</p>
Various invocations</h2>
ssh with weird agent socket</h3>
Given I am doing this to test agent + cert muckery, invoking ssh to talk to the sshd mentioned above looks like:</p>
ssh</span> -v \</span></span>
    -o</span> UserKnownHostsFile=/dev/null</span> \</span></span>
    -o</span> StrictHostKeyChecking=no</span> \</span></span>
    -F</span> /dev/null</span> \</span></span>
    -l</span> $USER</span> \</span></span>
    -o</span> IdentityAgent=/path/to/agent.sock</span> \</span></span>
    -p 2222 \</span></span>
    localhost</span></span></code></pre>
Same, but for a local cert instead of agent (assuming user_key</code> is the private key, and has user_key.pub</code> and user_key-cert.pub</code> alongside it):</p>
ssh</span> -v \</span></span>
    -o</span> UserKnownHostsFile=/dev/null</span> \</span></span>
    -o</span> StrictHostKeyChecking=no</span> \</span></span>
    -F</span> /dev/null</span> \</span></span>
    -l</span> $USER</span> \</span></span>
    -i</span> path/to/user_key</span> \</span></span>
    -p 2222 \</span></span>
    localhost</span></span></code></pre>Given a CA key, generate a user cert locally</h3>
ssh-keygen</span> -s</span>  path/to/ca</span> -I</span> wobble</span> -n</span> {{ principals }} .path/to/user_key</span></span></code></pre>
Add a comma seperated (no spaces) list of the principals (groups) for {{ principals }}</code> in that invocation (needs to align with the auth principals on sshd). The -I</code> is basically irrevalent for testing purposes, is just a cert identifier.</p>


Using More FreeBSD
Brian McCallister — Fri, 17 Nov 2023 00:00:00 +0000
I do some volunteer sysadmining for a local non-profit, mostly network management and related things. Between there, and my home setup, I have gradually moved from defaulting to Ubuntu back towards FreeBSD over the last year. Nothing wrong with Ubuntu, but I kept finding FreeBSD to simply be a little bit easier and a lot better documented</a>. For a dev box, I'll stick with linux—all the tooling optimizes there first, in particular the container ecosystem is too useful to walk away from. For sysadmin'y stuff though, FreeBSD is where it's at. At a minimum, it's rc system</a> is much easier to work with than systemd :-)</p>
My general toolkit for running anything is a pair of refurbished HP Prodesks</a> sharing a CARP virtual interface</a> using devd</a> events if I need to do anything on failover. It's shockingly easy and just works.</p>
(side note: I tested 14.0-RELEASE on a pair of them and discovered that if a server is hosting a VIP and needs to to use</em> that virtual IP when it is the backup, say to find DNS</a>, you need to disable net.inet.ip.source_address_validation</code> in sysctl</a>, but then it works fine. I probably shouldn't do this, but I'll sort that out later.)</p>
(side note 2: With those old HP Prodesks, you need to go into the BIOS and disable UEFI (switch to use "legacy boot" for the FreeBSD install to work). You don't need to for Ubuntu.)</p>


Home DNS with Unbound and NSD
Brian McCallister — Sun, 12 Nov 2023 00:00:00 +0000
I recently redid the DNS on my home network, moving from dnsmasq</a> to Unbound</a>
and NSD</a>. Unbound acts as the DNS server the network uses, and Unbound hosts losts local zones for my search domains. For reasons, this is really across two sites: our home, and a barn we own a few miles away. Because I am a dork, I have things at both sites :-)</p>
My network controller has a built in DNS server which assigns a local domain, a la brians-laptop.local</code> to anything which gets a DHCP lease. I wanted to be able to respect these, but also assign a diferent domain to statically assigned things on the network, such as printers and our NAS. For these I set up a .home</code> and .barn</code> respectively, for things in the home and in the barn. Those zones are hosted on NSD, with a config like:</p>
# /usr/local/etc/nsd/nsd.conf</span></span>
server</span>:</span></span>
    ip-address</span>:</span> 127.0.0.1</span></span>
    port</span>:</span> 53530</span></span>
zone</span>:</span></span>
    name</span>:</span> home</span></span>
    zonefile</span>:</span> "home.zone"</span></span>
zone</span>:</span></span>
    name</span>:</span> barn</span></span>
    zonefile</span>:</span> "barn.zone"</span></span></code></pre>
Note that NSD is only listening on 127.0.0.1</code> and on port 53530. It should only ever be queried from the unbound instance on the same host (which is using port 53).</p>
The zone files referenced are just stubs, not really correct, but they don't need to be :-)</p>
; /usr/local/etc/nsd/home.zone</span></span>
$ORIGIN home. </span>; 'default' domain as FQDN for this zone</span></span>
$TTL </span>600</span> ; default time-to-live for this zone</span></span>
</span>
home.   IN  SOA     ns.home. noc.dns.icann.org. (</span></span>
        16</span>          ;Serial</span></span>
        7200</span>        ;Refresh</span></span>
        3600</span>        ;Retry</span></span>
        1209600</span>     ;Expire</span></span>
        3600</span>        ;Negative response caching TTL</span></span>
)</span></span>
</span>
; The nameserver that are authoritative for this zone.</span></span>
                        NS      ns.home.</span></span>
nas.home.       A       192.168.2.114</span></span>
printer.home.   A       192.168.2.140</span></span>
m0001.home.     A       192.168.2.101</span></span>
m0002.home.     A       192.168.2.102</span></span></code></pre>
and the barn:</p>
$ORIGIN barn. </span>; 'default' domain as FQDN for this zone</span></span>
$TTL </span>600</span> ; default time-to-live for this zone</span></span>
</span>
barn.   IN  SOA     ns.barn. noc.dns.icann.org. (</span></span>
        17</span>          ;Serial</span></span>
        7200</span>        ;Refresh</span></span>
        3600</span>        ;Retry</span></span>
        1209600</span>     ;Expire</span></span>
        3600</span>        ;Negative response caching TTL</span></span>
)</span></span>
</span>
; The nameserver that are authoritative for this zone.</span></span>
                NS      ns.barn.</span></span>
m0003.barn.     A       192.168.81.101</span></span>
m0004.barn.     A       192.168.81.102</span></span>
dvr.barn.       A       192.168.81.110</span></span></code></pre>
With NSD up and running, I set up Unbound to make use of those local zones. It runs on the same instance as NSD, and is configured ot use it for those domains:</p>
# /usr/local/etc/unbound/unbound.conf</span></span>
server</span>:</span></span>
    # This is a CARP interface, which apparently </span></span>
    # requires explicitely listing</span></span>
    interface</span>:</span> 192.168.2.100</span></span>
    interface</span>:</span> 0.0.0.0</span></span>
    do-not-query-localhost</span>:</span> no</span></span>
    access-control</span>:</span> 192.168.0.0/16 allow</span></span>
</span>
    local-zone</span>:</span> "home" nodefault</span></span>
    domain-insecure</span>:</span> "home"</span></span>
</span>
    local-zone</span>:</span> "barn" nodefault</span></span>
    domain-insecure</span>:</span> "barn"</span></span>
</span>
stub-zone</span>:</span></span>
    name</span>:</span> "home."</span></span>
    stub-addr</span>:</span> 127.0.0.1@53530</span></span>
</span>
stub-zone</span>:</span></span>
    name</span>:</span> "barn."</span></span>
    stub-addr</span>:</span> 127.0.0.1@53530</span></span>
</span>
forward-zone</span>:</span></span>
    name</span>:</span> "local."</span></span>
    forward-addr</span>:</span> 192.168.1.1</span></span></code></pre>
Unbound is set up to listen on all interfaces, but because I am using a CARP</a> interface as well, it seems to require seperately listing that one to avoid confusions. The two local zones are configured to be insecure (no DNSSEC) and to forward to the NSD instance as a stub-zone</code> for each domain, respectively.</p>
The dynamically assigned .local</code> domain is forwarded to the router to pick up the names of things which get DHCP leases via the forward-zone</code> block.</p>
Finally, to make it all work, I hand out three search domains on DHCP, .local</code>, .home</code>, and .barn</code>. This is DHCP code 119 with a value local,home,barn</code>, for future reference.</p>
Deployment wise, this is running on two servers in each location, with each server running both NSD and Unbound. The CARP interface is used to provide a single IP address for the DNS servers, and the DHCP server is configured to hand out that IP address as the DNS server for the network.</p>
Fun fact along the way: I learned emacs has a mode for zone files which automatically increments serial</code> when you save. Handy!</p>


20 Years of Wasting Time!
Brian McCallister — Sat, 11 Nov 2023 00:00:00 +0000
I cannot let 2023 go past without writing anything</em> given it is 20 years of this blog, but an update to Hugo broke things, and getting it to work was just annoying. So I got frustrated enough making Hugo do what I wanted that I ported over to Zola</a> and here we go, I am able to update again!</p>
Along the way I took a moment to add all the posts from my original blosxom based blog to the archive</a>, which makes me happy. Really, I want to post about the home DNS setup I did, but that will have to wait until tomorrow :-) For now, I want to push this and see if the deploy works!</p>
Happy 2023!</p>


Blog CD Pipeline with AWS CodePipeline
Brian McCallister — Wed, 22 Nov 2017 17:09:31 -0800
Jumped out of order from my earlier checklist</a> and set up some automagic build and deploy. I'd wanted an excuse to try out CodePipeline</a>, so this was it!</p>
So, how does this blog work? It is deployed to an S3 bucket (skife.org</a>) with CloudFront in front of it. CloudFront is set up to use the free SNI certs to provide TLS. Previously, I pushed manually via s3cmd</a>, which worked well with some incantation fiddling.</p>
I won't write a full CodeBuild and CodeDeploy tutorial, Amazon has that well covered, but a couple bits were funny to work out, so will talk about those.</p>
First, CodePipeline needs to trigger things. This is important as CodeBuild has no mechanism (which I could find) to only care about particular branches. CodeBuild really just does builds (kind of). Conceptually, do everything through CodePipeline and other stuff is just steps which react to the pipeline.</p>
Given this is a static site, the build step just builds a tarball:</p>
version</span>:</span> 0.2</span></span>
</span>
phases</span>:</span></span>
  install</span>:</span></span>
    commands</span>:</span></span>
      -</span> wget https://github.com/gohugoio/hugo/releases/download/v0.31/hugo_0.31_Linux-64bit.deb</span></span>
      -</span> dpkg -i ./hugo_0.31_Linux-64bit.deb</span></span>
  build</span>:</span></span>
    commands</span>:</span></span>
      -</span> hugo</span></span>
      -</span> tar -C public -cvzf skife.org.tgz .</span></span>
artifacts</span>:</span></span>
  files</span>:</span></span>
    -</span> skife.org.tgz</span></span></code></pre>
Nothing fancy here, but having the artifact for CodePipeline to pass around is important.</p>
My first pass just had the deploy at the end of the build, but I want to be able to insert some basic tests before I deploy new versions. Just things like link verification, HTML5 validation, and maybe running stuff like Lighthouse</a> against a test instance before letting it out. The test part :-) Because of this, I wanted to seperate build from deploy. It turns out "deploy by copying into an S3 bucket" is not a thing CodeDeploy</a> has any concept for.</p>
So my "deploy" is just another CodeBuild build:</p>
version</span>:</span> 0.2</span></span>
phases</span>:</span></span>
  build</span>:</span></span>
    commands</span>:</span></span>
      -</span> tar -xf skife.org.tgz</span></span>
      -</span> rm skife.org.tgz</span></span>
      -</span> aws s3 sync . s3://skife.org --acl public-read --cache-control public,max-age=600</span></span></code></pre>
You can feed one build to another, it doesn't mind. When I configured the second build I had to set it up with an output artifact or CodePipeline wouldn't let me add it. After I saved the CodePipeline changes, I could go back and remove that output. The other decent path is probably to set up a Lambda function that takes apart the tarball and copies things over... but this build approach seems simpler.</p>
I tried to put a cloudfront invalidation into the last step as well, but the version of the aws cli on the build image is old and it is not supported. I'll sort that out later. Once I do, will change max-age to max-age=31536000 or so and add something like:</p>
-</span> aws cloudfront create-invalidation --distribution-id E1DTTO3T6ZPN9M --paths / /index.html /404.html /archive.html /index.xml</span></span></code></pre>
to the build commands, and voila!</p>


Knock, knock. This thing still on?
Brian McCallister — Sat, 18 Nov 2017 17:09:31 -0800
I've attempted to wake this blog up a couple times, but between Jekyll</a> changing, Pygments</a> changing, and whatnot, it has been more pain than any given post seemed worth. I've recently had three folks independently chastise me for no longer writing, however, and three is a magic number.</p>
So, this is basically just a test post as I try converting over to Hugo</a>. Jekyll resisted hard enough that I declared bankruptcy. We'll try this one. If I get annoyed at it, Gutenberg</a> is next on the list. Torsten</a> says nice things about it :-)</p>
All my old posts should be exactly where I left them</a>, no sense breaking URLs.</p>
For a test post I need to include some code, that being most of the point of this thig, so some Rust from wsf</a>.</p>
impl</span> From</span><hyper</span>::</span>error</span>::</span>Error</span>></span> for</span> CliError</span> {</span></span>
    fn</span> from</span>(err</span>:</span> hyper</span>::</span>error</span>::</span>Error</span>)</span> -></span> CliError</span> {</span></span>
        CliError</span>::</span>Http</span>(err)</span></span>
    }</span></span>
}</span></span></code></pre>
So far, so good.</p>


Build with Hugo</li>

Code is pretty</li>

Ensure Atom/RSS is sane</li>

Add some kind of commenting (staticman</a>?)</li>

Better favicon</li>
</ul>
Off to deploy and see if this thing works!</p>

Brian's Waste of Time

bdsh: A dsh-alike for me

D&D (prep) with Claude Code

Fun With HTTP Caching

Kong + CUE

Setting up Epithet as of v0.1.7

Configuring the Policy Server</h3> Now, let's do some basic configuration for the deployment. We do this with some terraform variables, created and edit terraform/terraform.tfvars</code>:</p>

Create a cloud-init config for new VMs to rely on the CA</h2>

Epithet, v2, Briefly - Part 1

CA</h2> The CA has access to the CA private key, so I want it to be as simple as possible. As such it delegates decision making about certificates to the policy service and merely issues certs as instructed.</p>

Notes on setting up vm-bhyve

Alfred Alias Hack

Ghostty, emacsclient, and terminfo

Epithet, Briefly

Policy</h2> The policy service consumes the opaque auth tokens from the CA and reponds with basic info, assuming the auth is valid:</p>

SSH Certificate Notes

SSH Keys for different things are all the same (modulo chosen algo type)</h2> User keys, host keys, CA keys -- they are all the same. Don't let ssh-keygen</code> docs, with all of its options and whatnot, convince you otherwise.</p>

Using More FreeBSD

Home DNS with Unbound and NSD

20 Years of Wasting Time!

Blog CD Pipeline with AWS CodePipeline

Knock, knock. This thing still on?

CA</h2>
The CA has access to the CA private key, so I want it to be as simple as possible. As such it delegates decision making about certificates to the policy service and merely issues certs as instructed.</p>

SSH Keys for different things are all the same (modulo chosen algo type)</h2>
User keys, host keys, CA keys -- they are all the same. Don't let `ssh-keygen</code> docs, with all of its options and whatnot, convince you otherwise.</p>`