Legacy Vultr OpenBSD Installer

The primary OpenBSD installer is now provider-neutral:

doas perl install/openbsd-install.pl

This document remains as a Vultr-specific reference for Vultr DNS and cloud firewall steps.

Run from a cloned repository:

doas ksh install/openbsd-vultr-install.ksh

The installer is interactive. It asks for:

• Primary domain.
• Shop domain, usually shop.<domain>.
• Site name.
• Admin username and password.
• SSH port.
• CIDR allowed to reach SSH through pf.
• Whether to include www.<domain> in the certificate and httpd alias.

Vultr DNS Walkthrough

The installer pauses until these Vultr account-side steps are complete:

1. In Vultr DNS, create a DNS zone for the domain.
2. At the registrar, set the authoritative nameservers to:

• ns1.vultr.com
• ns2.vultr.com

1. In the Vultr DNS zone, add:

• A @ <server IPv4>
• AAAA @ <server IPv6> when the instance has public IPv6
• A shop <server IPv4> for the rights shop
• AAAA shop <server IPv6> when IPv6 is enabled
• CNAME www <domain> when using the www alias

1. In Vultr Cloud Firewall, use default-deny inbound rules and allow only:

• TCP SSH from your admin CIDR
• TCP 80 from the internet for ACME and HTTP-to-HTTPS redirect
• TCP 443 from the internet for the public site, admin UI, and shop

1. Attach that Vultr firewall group to the OpenBSD instance.

The shop hostname is first-party and uses the main CMS database/config, not contributor-site provisioning.

The installer also writes local pf rules. Vultr firewall and OpenBSD pf should both be in place; the cloud firewall limits traffic before it reaches the server, and pf enforces the host boundary.

Files Installed

/usr/local/www/desertcms/          root-owned application code
/etc/desertcms.conf                root:_desertcms 0640 app config
/etc/rc.d/desertcms_slowcgi        rc.d service for admin CGI
/etc/httpd.conf                    generated httpd config
/etc/acme-client.conf              generated ACME config
/etc/pf.conf                       generated host firewall
/var/desertcms/                    _desertcms-owned data
/var/desertcms/originals/          private photo originals
/var/desertcms/backups/            compressed backups
/var/desertcms/themes/             editable theme copy
/var/www/htdocs/desert-archive/    generated public webroot
/var/www/acme/                     ACME HTTP challenge root
/var/www/run/desertcms.sock        slowcgi socket visible inside httpd chroot

Existing /etc/httpd.conf, /etc/acme-client.conf, /etc/pf.conf, /etc/desertcms.conf, and /etc/rc.d/desertcms_slowcgi files are backed up with a timestamp before being replaced.

Services

The installer enables and starts:

rcctl enable pf
rcctl enable httpd
rcctl enable desertcms_slowcgi

It validates:

pfctl -nf /etc/pf.conf
httpd -n

Then it runs:

acme-client -v <domain>

If ACME fails because DNS has not propagated yet, wait for DNS, then rerun:

doas acme-client -v example.com
doas httpd -n
doas rcctl restart httpd

The generated certificate request includes shop.<domain> as an alternative name on the primary domain certificate. Configure Stripe to send webhooks to:

https://shop.example.com/stripe/webhook

Security Defaults

• Inbound traffic is blocked by default in pf.
• SSH is allowed only from the CIDR entered during install.
• HTTP and HTTPS are the only public services.
• App code is root-owned under /usr/local/www/desertcms.
• Writable data is isolated under /var/desertcms.
• Public output is isolated under /var/www/htdocs/desert-archive.
• Original photos are never under the webroot.
• The shop serves only /, /checkout, /success, /cancel, and /stripe/webhook through the main /etc/desertcms.conf.
• Admin runs through slowcgi as _desertcms.
• TLS uses OpenBSD acme-client.