What it is¶
The iCAT is iRODS's catalog: every collection, data object, replica, AVU, ticket, and permission in the zone. It is the one CyVerse database that is not managed by CyVerse migrations — its schema belongs to iRODS.
Who creates it¶
The iRODS installer, during
iRODS provider setup. You do not create it
by hand. What you do beforehand is prepare PostgreSQL for iRODS as the iRODS
project describes,1 which creates the database, the irods role,
and its ODBC connectivity — see
PostgreSQL.
The database name is chosen at install time and recorded in
/etc/irods/server_config.json.
Who may read it¶
The DE reads the catalog directly for some listings, through a PostgreSQL role
with SELECT on all iCAT tables and nothing more. That role is separate from the
de-irods iRODS account.
Nothing but iRODS writes to the iCAT
Writing to the catalog outside iRODS bypasses policy: no rules fire, no AVUs are maintained, no messages are published, and the vault and catalog can disagree. Every write goes through the iRODS protocol, including administrative ones.
Backup¶
The iCAT and the vault have to be backed up as a pair. A catalog restored to a different point in time than the vault leaves data objects registered that do not exist, and files on disk that nothing can reach.
Include both in the operational readiness checks in verification.
Related¶
-
iRODS 4.3.3 installation guide ↩