Database Setup
Registry requires a SQL database, Postgres and MariaDB/MySQL are supported. If there is no local preference, Postgres is recommended. The database configuration should be placed in local/config/database.php. A sample file is available in app/config/database.php.dist. Supported versions are defined in Registry Minimum Versions and Requirements.
The database name cannot have a dot (.) in it, see this Github issue for more details.
For new deployments on Postgres 15+, a schema usage pattern must be selected. Either define a private schema for Registry (which can be selected using the schema entry in the Database configuration) or grant all permissions on the public schema to the Registry database user (GRANT all ON SCHEMA public TO username). (The latter should only be used for databases that are dedicated to COmanage with no untrusted users.)
For MySQL, be sure to set quoteIdentifiers to true. This is not required for MariaDB.
Install Database Schema
Install the database schema as follows:
$ cd $REGISTRY/app $ ./bin/cake database [lots of SQL output...] Database schema update successful
The -n flag (which shows what changes to the schema would be made without making them) cannot be used before the initial database setup is complete.
Setup Command
Setup Command performs various initialization tasks, including creation of the COmanage CO and registration of the first administrative user. The username should correspond to the authenticated identifier returned for the initial administrator (eg: populated into $REMOTE_USER).
$ cd $REGISTRY/app $ ./bin/cake setup Given Name of initial platform administrator > Family Name of initial platform administrator > Username of initial platform administrator > [...] Done
The initial administrator information can also be provided via command line arguments.
setup [--admin-given-name <name>] [--admin-family-name <name>] [--admin-username <username>]
Cron
Registry Job Command is used to process tasks ("Registry Jobs") that take more time to complete than is available in a normal web page load, or that need to be run periodically without active intervention. While Job Commands can be run synchronously from the command line, the more common approach is to queue Jobs for automatic processing. Queued Jobs are processed by Job Runners, which are triggered via cron.
A typical cron entry will look something like this:
# Run the Job Queue for all COs 0/5 * * * * cd /path/to/registry-source/app && ./bin/cake job -q -r -c all
This will launch a Queue Runner every 5 minutes that will process all Jobs (up to the maximum configured) in all COs.
Multi-tenant and large deployments will probably want to customize this entry to allow for parallel processing via multiple Queue Runners. See the Registry Job Command documentation for more details. Queue Runners can also be from multiple servers, or even servers dedicated just to Queue Runners (and that do not run the web interface).
The cron command should run as the web server user in order to avoid problems with file permissions.