Naming conventions

Host naming is the kind of thing that seems trivial for the first ten machines and becomes unfixable at forty. This scheme is published in full — the tokens below are pseudonymized, but the structure is exactly the one in use, and it is the part worth copying.

The format

[location]-[function]-[NN]

Three parts, always all three, always in that order.

Part	Meaning	Examples
location	Where the machine physically is	hq (home site), us, eu (rented VPS)
function	What it does, environment always explicit	pve, tns, prod-mail, prod-siem
NN	Two digits, always padded	01, 02

So:

hq-pve-01           hypervisor node 1, at home
us-gateway-01       primary public gateway, US
eu-gateway-01       standby public gateway, Europe
hq-prod-siem-01     production security monitoring VM, at home
hq-tns-01           high-integrity storage, at home

Why each part earns its place

Location first because it is the thing you most need to know before you type a command. A destructive command on a machine in a rented datacenter and the same command on a machine in the next room have very different recovery stories. Sorting a host list alphabetically groups by location, which is the grouping that matters when something is on fire.

Environment inside the function token, always explicit. An earlier version of this scheme allowed the environment to be implied when it was “obvious”. Nothing is obvious at 2 a.m. prod in the name is cheap insurance.

Two digits, always. 01 rather than 1, so that sorting works and so that reaching ten machines does not reorder your entire inventory.

What changed from the first attempt

The scheme was revised once, and the revision is instructive:

Original	Revised	Reason
{env}-{function}-{index}	[location]-[function]-[NN]	No location token at all. Once machines existed in three places, the name could not tell you where a host was
Auto-generated	Deliberately assigned	Generated names encode nothing a human needs
Environment sometimes implied	Environment always explicit	See above

The old-format names still appear in older documents. The current rule is that a name without a location token is stale by definition and must not be reused, even when copying content from a document that still contains one.

DNS

Internal and public names are two separate records, not one record that resolves differently depending on where you ask.

files.internal.example.net     internal only, never resolvable outside
files.example.net              public, via the gateway relay

Same function word. The internal marker is simply dropped for the public name.

The rule that matters, and the one worth writing into your own notes: if you are about to create a public DNS record containing the internal marker, stop. That is nearly always a mistake, and it is the kind that publishes something you meant to keep inside.

Storage naming

Datasets are named for the service that owns them, on whichever storage tier that service was assigned. Every dataset belongs to exactly one tier — there is no undifferentiated pool, deliberately, because “where does this live” should never be a question with two plausible answers.

The general lesson

The specific tokens here do not matter. Three things do:

1. Encode what you need before acting, not what is easy to generate.
2. Never allow an implied field. The one you leave out is the one that causes the incident.
3. Write down the scheme somewhere authoritative, and check names against it before creating anything — including when copying from an older document of your own, which is where stale names actually come from.