As described in Getting Started / Configuration, you may use the -g and specify a YAML file for setting properties to your XNAT instance. An example YAML configuration file, which contains all currently supported operations is below:
siteConfig : siteDescriptionText : "Welcome to the XNAT 1.7 sandbox server!\n\nPlease enjoy your stay :)" siteDescriptionType : Text enableCsrfToken : false pipelines : DicomToNifti : path : "/data/xnatdev/pipeline/catalog/mricron/DicomToNifti.xml" anon : file : sample_anon.das dataTypes : sessions : [DX, MG, NM, OPT, OT, US, XA] YGTSS : singularName : 'Yale Global Tic Severity Scale Assessment' code : 'YGTSS' xsiType : 'xnat_a:ygtssData' YBOCS : singularName : 'Yale-Brown Obsessive-Compulsive Scale Assessment' code : 'YBOCS' xsiType : 'xnat_a:ybocsData' searches : [collegeSubjects, multipleMR, PETsBefore2010, unknownDateMRs] images : - user : xnat name : dcm2niix version : 1.4 type : docker commands : - name : dcm2niix wrappers : - name : dcm2niix-scan uniqueAlias : dcm2niix
Each of the top level elements "siteConfig", "pipelines", "anon", "dataTypes", "searches", and "images" are optional, and may be omitted or included independently of each other.
Under siteConfig, you can specify key-value pairs of configuration that will be passed in one REST POST to /xapi/siteConfig.
Under the pipelines setting, you can specify one or more XNAT pipelines to be registered to your XNAT instance. The first child level under "pipelines", specifies the name of the pipeline. XNAT Populate will take this and look for a pipeline YAML file in the ./pipelines folder (here it would look for DicomToNifti.yaml). There is currently no REST API to register pipelines, so what the script does instead is:
Under anon, you can specify one of two child elements "url", or "file". If "url" is specified, sitewide anonymization will be set up with the response from the URL provided. If instead "file" is specified, the contents of the anon script file (in the current directory) will be used for anonymization at the site level.
This section is broken up into 'sessions', which is a simple array of modality codes to set up the corresponding XNAT data type. The above config would set up DX sessions, MG sessions, NM sessions, and so on. Additionally, you can specify data types with a singularName, pluralName (defaults to singularName + s if left out), code, and xsiType. The above config would set up the xnat_a:ygtssData and xnat_a:ybocsData data types (available but not set up in default XNAT).
This is a simple array of stored searches which will be POSTed to the site. The XML files defining the stored searches can be found in the stored_searches folder (and must be in there to be picked up here).
The 'images' referred to here are images for process containerization supported by the XNAT Container Services plugin. Shown above is how to specify the xnat/dcm2niix:1.4 docker image, along with its dcm2niix command and dcm2niix-scan wrapper. The 'uniqueAlias' field on the wrapper is a shortcut name that should be unique across all command wrappers. It is then used when referencing what command wrapper to execute so that the full image/command/wrapper hierarchy doesn't need to be listed in the YAML for each container launch. On site setup, XNAT Populate will attempt to pull the specified images if they are not already installed.