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.

siteConfig

Under siteConfig, you can specify key-value pairs of configuration that will be passed in one REST POST to /xapi/siteConfig.

pipelines

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:

  1. It prepares URL-encoded body with "eventSubmit_doAdd" = "Add" and sets various path values in the body to the value of 'path' in the YAML. These are the two parameters necessary to set up the pipeline.
  2. It checks the key-value pairs under the pipeline in the setup YAML (shown above) other than 'path', and adds them to the body.
  3. It POSTs the body to $server/app/action/ManagePipelines.

anon

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.

dataTypes

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).

searches

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).

images

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.