[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7 Administrative utilities

These tools are used by the GNATS administrator as part of the periodic maintenance and configuration of GNATS. See section GNATS Administration.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7.1 Adding another database

To initialize a new GNATS database:

  1. Add a line for the new database in the ‘databases’ file (see section Where GNATS lives.
  2. Run mkdb, using
     
    mkdb database
    

    where database is the database you specified in the ‘databases’ file. mkdb creates the database directory and populates it with the directories ‘pending’, ‘gnats-queue’ and ‘gnats-adm’. A full set of sample configuration files is copied to the ‘gnats-adm’ directory.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7.2 Adding a problem category

To add new categories to the database:

  1. Add a line to for each new category to the ‘categories’ file in the gnats-adm directory of the database. See section The categories file.
  2. Run mkcat If applicable. If create-category-dirs is set to false in the database ‘dbconfig’ file, you need to create category directories with mkcat. mkcat creates a subdirectory under the database directory for any new categories which appear in the ‘categories’ file.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7.3 Removing a problem category

To remove a category from the database:

  1. Remove the Problem Reports from the subdirectories corresponding to the categories you wish to remove, or assign the PRs to new categories. All PRs for a given category reside in a subdirectory of the database directory, with the same name as the category.
  2. Run rmcat using
     
    rmcat category [ category… ]
    

    where category is the category you wish to remove. You can specify as many categories as you wish as long as each category has no PRs associated with it. rmcat removes the directory where the Problem Reports for that category had been stored.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7.4 Regenerating the index

If your ‘index’ file becomes corrupted, or if you need a copy of the current index for some reason, use

 
gen-index [ -n | --numeric ]
          [ -d databasename | --database=databasename ]
          [ -o filename | --outfile=filename ]
          [ -i | --import ] [ -e | --export ]
          [ -h | --help] [ -V | --version ]

With no options, gen-index generates an index that is sorted by the order that the categories appear in the ‘categories’ file. The index is generated in plaintext or binary format according to the value of binary-index in the ‘dbconfig’ file (see section Index file description). The results are printed to standard output. The options are:

-n
--numeric

Sorts index entries numerically.

-d databasename
--database=databasename

Specifies the database to index. If this option is left out, gen-index attempts to index the database with name taken from the the GNATSDB environment variable, and if that is undefined, the default database, as set when GNATS was built (usually default).

-o filename
--outfile=filename

Places output in filename rather than sending it to standard output.

-i
--import

Import the existing index file instead of re-indexing the database.

-e
--export

Force plaintext output.

-h
--help

Prints the usage for gen-index.

-V
--version

Prints the version number for gen-index.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7.5 Checking database health

The ‘check-db’ script is useful for performing periodic checks on database health. It accepts the following options:

-d databasename
--database=databasename

Determines the database which to operate on.

--all-databases

Check all GNATS databases on the system. This option takes precedence over the --database option.

If no option is given, the default database is checked.

During its operation, check-db first attempts to lock database. If this is not possible, it repeats the locking attempts for five minutes; if it fails, it sends a mail message notifying the administrator of the failure and exits.

Once the database is locked, the script searches the database for lock files that are more than 24 hours old. Any old lock files are reported to the administrator in a mail message.

After checking for old lock files, it calls gen-index (see section Regenerating the index) and compares the results with the current ‘index’ file of the database; any inconsistencies are reported to the administrators in a mail message.

After checking the index file for inconsistencies, the script unlocks the database and exits.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.7.6 Managing user passwords

Older versions of GNATS, up to and including version 3.x, stored user passwords in plaintext in the ‘gnatsd.user_access’ files. Version 4 has the options of storing the password as MD5 or standard DES crypt() hashes (as most UNIX versions do in the system password files) as well as in plaintext. Since the password strings require a prefix to indicate how they are encrypted, one is forced to convert the old password files to a new format when upgrading to GNATS version 4. See section Upgrading from older versions.

The gnats-pwconv tool takes care of converting the old password files to the new format:

 
gnats-pwconv [ -c | --crypt ] [ -m | --md5 ] [ -p | --plaintext ]
         [ -h | --help] [ -V | --version ] INFILE [OUTFILE]

Unless the --version or --help options are given, exactly one encryption method must be specified, as well as an input file. The output file parameter is optional. If one is not specified, results will be printed on standard output.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]

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