Keeping Track

Node:GNATS configuration, Next:databases file, Up:Management

Overview of GNATS configuration

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 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 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 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 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 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 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 The addresses file.
states: Lists the possible states for Problem Reports, typically ranging from open to closed. See 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 The classes file.
gnatsd.user_access: Specify the access levels for different users to your database. See 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 the send-pr.conf file.