Next: databases file, Up: Management [Contents][Index]
See 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 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.
Next: databases file, Up: Management [Contents][Index]