Configuration and service templates

templates/ contains source-controlled files intended to be copied, rendered, or installed by a separate deployment or administrative step.

Contents

• config/odoo18/ contains an Odoo 18 configuration template.
• systemd/odoo18/ contains the PMISuite 18 runtime, full-update, and selected-module install/update service templates with installation/maintenance instructions.
• systemd/backup/odoo18/ contains units for the current primary Odoo 18 backup workflow, including backup_odoo18_dbs@.service for explicit registry instance selection. Legacy Odoo 12 units live in _pmiregistry.
• systemd/backup/pmis-backup-latest.service provides the latest-backup service unit.
• systemd/rsync/ contains the generic latest-backup .service.in input template.
• nginx/ contains a synthetic example; deployment-specific Nginx configuration, full-history rsync units, and their timers live in _pmiregistry.

A file in this directory is not a deployed file. Editing a template does not update /etc/systemd/system, an instance configuration, or a running service. Deployment ownership and destination paths are defined by the consuming runbook or script, not by this directory alone.

The Odoo 12 backup script and matching unit files are maintained under /srv/pmiverse/_pmiregistry/. Their retained implementation is separate from the shared Odoo 18 producer.

Active shared inputs used directly from this checkout belong in ../config/. Executable operational and integration logic belongs in ../scripts/ or ../tools/.

Odoo 18 backup service selection

For a setup with one registered Odoo 18 instance per server, keep using backup_odoo18_dbs.service and backup_odoo18_dbs.timer. The service runs the backup script without an instance argument, so the script selects the unique Odoo 18 instance matching the server's short hostname. The timer schedules that ordinary service daily at 02:00 in the system's timezone; Persistent=true allows a missed run to execute when the timer becomes active again.

backup_odoo18_dbs@.service is an optional systemd service template for selecting a particular registry instance. It is useful when one server has several Odoo 18 instances and the script cannot select one uniquely from the hostname alone. It does not replace the existing service or timer automatically.

The text between @ and .service is the instance ID. Systemd replaces %i inside the template with that text:

These synthetic examples illustrate per-instance selection. The ID must match a row in PMIVERSE_INSTANCE_REGISTRY in /srv/pmiverse/_pmiregistry/config/pmiverse.conf, and that row's host must match the local short hostname or the service's PMIS_BACKUP_HOST environment override. The script gets database aliases, filestore and backup paths, and PostgreSQL connection defaults from that row. Selecting an ID does not connect to that server through SSH; the service runs the producer on the local machine.

The template runs as user/group pmisuite18. Its Type=oneshot means systemd runs one backup job and waits for it to finish, rather than keeping a daemon running. After=network.target sets startup ordering, but does not guarantee network connectivity. Instances using another operating-system account need an appropriate service override.

The @.service template has no schedule or [Install] section. The existing backup_odoo18_dbs.timer starts only the ordinary service, not any named instance. To adopt the template, separately install it and configure a timer whose Unit= selects the desired instantiated service. No matching backup_odoo18_dbs@.timer is supplied. Jobs sharing a backup root must run sequentially because the producer rejects overlapping runs.

Remote backup roots are configured by the registry, typically under /srv/pmiverse/_pmisuite18/data/backups/. Host-specific folders such as backups/backup-a/ and backups/backup-b/ are local full-history rsync destinations on the restore server. See the backup runbook for the registry format, dry-run previews, and rollout details.

Template changes can affect future deployments and service behavior. Review the applicable backup or deployment documentation in the docs portal, validate rendered units before installation, and do not assume that changing a template changes an existing host.