Prerequisites and platforms¶
Platform¶
PEART targets Linux. The binaries are static, pure-Go and cross-compiled for linux/amd64 and
linux/arm64, so they run without a runtime to install. macOS and the BSDs work for local development;
a production deployment is Linux, because the sidecar isolation and the systemd hardening described here
are Linux mechanisms.
System users¶
A direct install uses three distinct system users, one per process, so filesystem permissions are a second line behind the architectural boundaries:
peartfor the internal surface,peart-portalfor the portal, a separate user that never reads the evidence directory or the key,peart-renderfor the rendering sidecar.
Directories¶
The data lives under /var/lib/peart (database, evidence, renditions, reports, and the shared work
directory the renderer uses). Configuration lives under /etc/peart. The master key lives at
/etc/peart/master.key, outside the data directory on purpose, so a backup of the data can never
contain it. The configuration page lists every path.
The rendering sidecar¶
The sidecar runs WeasyPrint under Python, so it needs Python 3 and WeasyPrint's own native dependencies. On Debian and Ubuntu, these are the packages PEART's own container image installs, which makes them the tested set rather than a guess:
sudo apt-get install --no-install-recommends \
python3 python3-venv \
libpango-1.0-0 libpangoft2-1.0-0 libharfbuzz0b fonts-dejavu-core
fonts-dejavu-core is not optional in practice: a PDF rendered on a host with no font at all comes out
blank where the text should be. On another distribution the names differ (the Pango, HarfBuzz and a base
font package); the set is the same.
The container path needs none of this on the host, because the image carries it.
A reverse proxy for TLS¶
PEART's own HTTP servers do not terminate TLS. A production deployment sits behind a reverse proxy that terminates TLS in front of the two surfaces; the TLS page covers this. Have a proxy (nginx, Caddy, or an edge like Cloudflare) available.