4.1 Overview of GNATS configuration

See section Where GNATS lives.

GNATS has two, well, actually three, different kinds of configuration file. The site-wide configuration files determine overall behaviour across all the databases on your machine, while the database-specific configuration files determine how GNATS behaves when dealing with a specific database. In addition, there is a single file that needs to be set up for the send-pr tool to work properly. These files can be edited at any time — the next time a GNATS tool is invoked, the new parameters will take effect.

These are the site-wide configuration files used by GNATS:

databases

Specifies database names and their associated parameters, such as in which directory they are located. This file is used by the GNATS clients to determine the location of a database referred to by name. See section The databases file.

defaults

This directory contains the set of default per-database configuration files used when a new database is created with mkdb.

gnatsd.host_access

Controls access levels for the different machines that will do lookups in the databases on this machine. See section GNATS access control.

gnatsd.user_access

Controls user access levels for the databases on this server. The settings apply to all databases (there is also a database-specific user access level file). See section GNATS access control.

The database-specific configuration is determined by the following files in the ‘gnats-adm’ subdirectory of the database directory.

dbconfig

Controls most aspects of how GNATS behaves when dealing with your database. See section The dbconfig file.

categories

The list of categories that GNATS accepts as valid for the Category field, and the maintainers responsible for each category. Update this file whenever you have a new category, or whenever a category is no longer valid. You must also update this file whenever responsibility for a category changes, or if a maintainer is no longer valid. See section The categories file.

responsible

An alias list mapping names to their associated mailing addresses. The names in this list can have multiple email addresses associated with them. If a responsible user does not show up in this list, they are assumed to be a user local to the system. This list is not associated with just the responsible user field; all email addresses are mapped through this file whenever mail is sent from GNATS. See section The responsible file.

submitters

Lists sites from whom GNATS accepts Problem Reports. The existence of this file is mandatory, although the feature it provides is not; see The submitters file.

addresses

Mappings between submitter IDs and submitters’ e-mail addresses. Use of this file is optional. If you get Problem reports where the Submitter field is not filled in, GNATS will use entries in this file to try to derive the submitter ID from the e-mail headers. See section The addresses file.

states

Lists the possible states for Problem Reports, typically ranging from open to closed. See section The states file.

classes

Lists the possible classes of Problem Report. This provides an easy way to have “subcategories”, for example by setting up classes such as sw-bug, doc-bug, change-request etc. See section The classes file.

gnatsd.user_access

Specify the access levels for different users to your database. See section GNATS access control.

The last file in this menagerie is the send-pr configuration file ‘send-pr.conf’. This file contains some defaults that need to be known in order for send-pr to work. The file needs to be present on all hosts where send-pr is to be used. See section the ‘send-pr.conf’ file.

This document was generated by Chad Walstrom on March 3, 2015 using texi2html 1.82.