Run it on your own OpenBSD box
Four steps from a stock OpenBSD system to a managed router — two of them a single command each. No account, no sales call, no waiting on us. OgmaProtect is in early access (v0.5.5) while the pre-1.0 hardening programme completes.
Before you start
- OpenBSD 7.9 (base system) on the router — any amd64 hardware OpenBSD supports, from a small fanless board to a rack server. Prefer not to build your own? Pre-order a ready-built appliance.
- A reachable package mirror — the usual
installurlis fine, because the install pulls two dependencies. Installing onto a box with no mirror? Put those two on it first, orpkg_addwill stop rather than continue without them. - Shell access with
doas(or root) on the router. - A browser on your management machine. That's the whole client — no agents, no cloud account.
Then:
- Get the package — download it and verify the signature.
- Install it with
pkg_add. - Bring it up with one
bootstrapcommand. - Log in and change the one-time password.
What gets installed beyond OpenBSD base
Two packages, both from the OpenBSD ports mirror you already trust for the base
system. They are declared in the package, so pkg_add resolves them
itself — there is nothing for you to install first, and nothing arrives that is not
named here:
databases/sqlite3— the configuration, revision and user stores.www/p5-CGI— used by the web tier, which runs as CGI underhttpdandslowcgi.
If either cannot be resolved, pkg_add fails and installs
nothing — you never end up with a partly-installed box that breaks later.
One exception worth knowing, because it is the only place software reaches your box
without an explicit step from you: if CGI.pm is still missing when
bootstrap runs — an offline install, or a box where Perl modules came
from CPAN rather than packages — the provisioner tries to fetch it, pkg_add
first and CPAN second, and warns you if both fail. On a normal install it is already
present and that step does nothing.
1 · Get the package
The package, the source tarball, a signed manifest and its detached signature are all a direct download. Three things happen on the download page, and it carries the commands for each:
- Install our signing key — once per box, before anything else.
pkg_addrefuses unsigned packages by default and will refuse ours until the key is on the box. It comes from a DNS record on a separate domain, at a separate provider from the download, so no single compromised account can hand you both a forged package and the key that vouches for it. - Download the five files — onto the router itself.
- Verify them — including the one thing most people get wrong about
reading
signifyoutput.
Free to use under the small-business terms; licensed beyond them.
2 · Install
In the directory you downloaded and verified into.
doas pkg_add ./ogmaprotect-0.5.5.tgz pkg_add lays down the binaries, the rc.d scripts and the config templates,
and — deliberately — enables and starts nothing. OpenBSD packages must not, and this one
does not. The box is not usable yet; step 3 is what makes it so.
3 · Bring it up
The single command between an installed package and a working HTTPS login.
doas ogmaprotect-setup bootstrap It enables and starts the 16 daemons in the order they require, then provisions the box: a per-host TLS certificate, the first administrator, the httpd/slowcgi chroot, a fail-closed firewall — and the web front end last, so the management plane never binds before the firewall is loaded.
Safe to re-run. It also runs again on every boot, which is how the managed
/etc files and the chroot survive an OS upgrade
(sysmerge/syspatch) that reverts them.
What bootstrap does, in full
It provisions a per-host TLS certificate with the machine's real addresses in the
subjectAltName (so https://<ip>/ loads), mints the first
administrator, populates the httpd/slowcgi chroot, writes /etc/httpd.conf,
sets up audit-log rotation, loads a fail-closed firewall, and starts the web front end
last.
Order matters once: ogmaprotect_netd configures the interfaces and exposes the
control socket the auth plane requires, so it starts first and ogmaprotect_authd
last. You do not type that order out — bootstrap reads it from the
inventory the package installs, so it cannot drift from the daemons on the box, and it
refuses to record a boot order at all unless every rc.d script is present.
Prefer to do it by hand? The package MESSAGE records the full enable block,
in order, along with the manual admin-creation step. Follow it there rather than a list
copied into a second document — that is what goes stale between releases.
4 · Log in
bootstrap mints a one-time admin password and writes it to the
machine console — and nowhere else: not to syslog, not to a file, not to
the process list. Read it there, then sign in as admin at:
https://<this-host>/ogmaprotect/ You are required to change the password before anything else is reachable. Add per-user MFA under Users. That is the install finished.
If the login page does not come up
The provisioner holds httpd back until an administrator exists — the web UI is never served without an account. If you created the admin after the provisioner ran, start the web plane directly:
doas rcctl start ogmaprotect_setup A certificate name warning is expected on first contact: the firstboot cert carries the box's IP addresses, so name the box on the identity page to regenerate one with a hostname.
Upgrading
Two commands you run when it suits you, and a manual path for a box with no route to the internet. Upgrades are forward-only, so the pre-upgrade snapshot is your only way back — the product path takes it for you and refuses to install if it cannot.
The product path. Press Check now on System → Control, or read the Update: line here:
doas ogmaprotectctl status Stage whenever convenient. It downloads the release the verified manifest names and checks it with signify against the key shipped in the package. Nothing is installed yet:
doas ogmaprotectctl update stage Apply in the window you choose. It re-verifies the staged package, takes the pre-upgrade snapshot, installs, asserts the installed version, and reboots after a cancellable delay:
OGMACTL_CONFIRM=1 doas ogmaprotectctl update apply Changed your mind? doas ogmaprotectctl update discard throws the staged bytes away. The same two steps are buttons on the System → Control card.
By name, from the hosted repository. pkg_add verifies the signature inside the package itself and refuses an unsigned or tampered one. The second path entry must stay — it is where the dependencies come from:
doas env PKG_PATH="https://ogmaprotect.com/pkg/%c/packages/%a/:installpath" pkg_add -u ogmaprotect The manual path, step by step
1 — Check the box is in a clean state. Both must come back clean; a pending restore or a schema complaint is a reason to stop, not to push on:
doas ogmaprotectctl status
doas ogmaprotectctl schema Confirm — or let revert — any pending change first. An apply still inside its auto-revert window is reverted when the daemons restart.
2 — Verify the new release exactly as you did the first one. An upgrade is where a substituted artifact would do the most damage; the procedure is on the download page.
3 — Stop the daemons, in reverse boot order — everything else first, ogmaprotect_netd last. The list is read from what is actually running rather than typed out:
for s in $(rcctl ls started | grep '^ogmaprotect_' | grep -v '^ogmaprotect_netd$'); do
doas rcctl stop "$s"
done
doas rcctl stop ogmaprotect_netd 4 — Snapshot your state. This is the rollback:
doas tar czf /root/ogma-snap-$(date +%F).tgz -C /var/db/ogmaprotect .
The -C matters: on an appliance image /var/db/ogmaprotect is a
symlink, so archiving the path itself captures the link and none of your state. Copy the
snapshot off the box.
5 — Install in place. From the downloaded file, or by name with the repository command above:
doas pkg_add -r ./ogmaprotect-0.5.5.tgz 6 — Start back up, boot order this time: ogmaprotect_netd first, ogmaprotect_authd last.
doas rcctl start ogmaprotect_netd
for s in $(rcctl ls on | grep '^ogmaprotect_' | grep -vE '^(ogmaprotect_netd|ogmaprotect_authd)$'); do
doas rcctl start "$s"
done
doas rcctl start ogmaprotect_authd Then confirm every daemon came back:
doas ogmaprotectctl status Why the snapshot is not optional
Canonical configuration carries a per-fragment schema version and upgrades are forward-only: a newer build reads an older box's configuration and re-stamps it; an older build refuses a fragment newer than it can read. Downgrading is not supported, so the pre-upgrade snapshot is the rollback — an exported backup bundle is not a downgrade path.
Restore it and you also restore credentials and secrets to their snapshot values.
Restore the rendered /etc files alongside it if you ever roll back —
nothing re-renders them from configuration at boot.
If a daemon does not come back, ogmaprotectctl status gives per-daemon
liveness and ogmaprotectctl schema names any fragment newer than the build
can read, along with the remedy.
What early access means: the product is pre-1.0 and the audit-derived hardening programme is still landing. You get every release as it ships, and a direct channel to the engineers — and we get operators who tell us the truth. Production use within the license terms is yours to judge; we are straight about where things stand.