INFRA Signal 432
Setup a simple web server with bozohttpd on NetBSD
↗
Illustration only Photo by Albert Stoynov on Unsplash
A step-by-step guide shows how to run the lightweight bozohttpd server on NetBSD via inetd, add TLS with acme-client, and automate certificate renewal.
NetBSD operators can deploy a minimal HTTP service without a full-featured daemon, reducing footprint and configuration complexity. The instructions also integrate automated Let's Encrypt certificates, which is essential for secure production sites. Knowing the required permission tweaks and cron job prevents common failures in certificate renewal and HTTPS startup.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
bozohttpd is launched by inetd, with separate entries for HTTP and HTTPS in /etc/inetd.conf.
TLS certificates are obtained with acme-client, stored under /etc/openssl with strict 600/700 permissions, and renewed via a daily root cron job.
Hosting multiple domains uses a shared key/certificate pair defined in acme-client.conf with alternative names, and symlinks simplify file placement.
THE READ
What the cluster adds up to.
The guide replaces a traditional persistent web daemon with bozohttpd, which is invoked by inetd for each incoming connection. This model reads TLS certificates on every request, so performance is modest but acceptable for low-traffic sites. Engineers adopting it must edit /etc/inetd.conf and reload inetd to activate the service.
Initial setup requires installing doas (if not present), configuring the HTTP entry in inetd, and placing site files under /var/www. Starting the server is as simple as restarting inetd, which means no separate init script is needed. The cost is a one-time edit to inetd.conf and ensuring the web root directory has appropriate ownership.
Enabling HTTPS adds several steps: installing the acme-client package, creating directories for challenges and private keys, writing a domain-specific acme-client.conf, and running acme-client to fetch certificates. After obtaining the certs, the key file must be owned by root:wheel and set to mode 600, while the private key directory is limited to mode 700. A daily cron entry under root runs acme-client to keep the certificates fresh, adding a small maintenance overhead.
The per-connection spawning model means bozohttpd is not suited for high-throughput workloads; each request incurs process start-up cost. HTTPS entries in inetd must run as root to access the private key, which expands the attack surface compared to a non-privileged daemon. Adding more sites requires a shared certificate or additional inetd lines, and the guide only covers a shared-key approach.
From an operational perspective, the configuration is straightforward but relies on correct DNS, proper file permissions, and a functioning cron scheduler. Misconfiguration of inetd or acme-client.conf will prevent the server from starting or serving TLS, so validation steps (dig, ls of cert files) are essential. Overall, the method offers a lightweight, easily scriptable web service for NetBSD environments, provided its performance limits and permission requirements are respected.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER