Building, Automation and Virtual Machines on OpenBSD Handbook

Manage OpenBSD with Ansible

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Ansible can manage OpenBSD over SSH, but most modules require a packaged Python interpreter on each managed node. Privileged tasks also require an explicit doas(1) policy. This guide prepares one node, proves unprivileged operation, adds controlled privilege elevation, and runs an idempotent package example.

Ansible is not an OpenBSD base-system component. The controller, ansible-core, and collections have their own support cycles. Confirm their current OpenBSD notes before upgrading an automation environment.

Build Third-Party Software from Ports

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

OpenBSD binary packages are the preferred way to install third-party software. Use the ports tree to build a maintained port with a documented flavor, test a local patch, or develop a port. It is not a general substitute for supported packages.

This guide builds one existing port from a ports tree that matches the installed OpenBSD branch. Building arbitrary upstream source outside the ports framework bypasses OpenBSD package metadata, patches, dependency tracking, and update handling.

Build OpenBSD from Source

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Building OpenBSD from source is a development or -stable maintenance workflow. It is not the supported way to move from one release to the next, and a custom kernel is not a routine optimization or hardening step. Normal systems should use signed release upgrades, syspatch(8) , and binary packages.

The authoritative build order is maintained in release(8) and the official source-build FAQ. This guide explains the safety boundaries around that order. Read the current primary instructions completely before executing a build.

Plan a Docker Workload Migration to OpenBSD

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Docker images assume an OCI runtime and Linux kernel interfaces. OpenBSD does not provide a native Docker Engine or a base-system OCI container runtime, and a Linux container image cannot run directly as an OpenBSD process. Migration therefore begins with the workload’s actual requirements rather than with a command intended to reproduce Docker syntax.

OpenBSD packages, base-system daemons, pledge(2) , unveil(2) , filesystem chroots, and vmm(4) solve different problems. None is a drop-in Docker replacement. This guide selects the smallest accurate deployment model and identifies when the workload should remain on Linux.