[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following procedure covers an upgrade from all GNATS 3 versions newer than 3.108. If your installation is an older 3.10x version, or even the ancient 3.2 version, you need to review the ‘UPGRADING.old’ file in the GNATS distribution before carrying out the steps detailed here.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Although almost all of the GNATS internals have been redesigned and
rewritten for GNATS 4, little has changed in the format and
structure of the database data. The only change that needs to be taken
into account when upgrading is the fact that the database index format
is binary in a default installation of GNATS 4. Thus, you will
need to regenerate your database index by using the gen-index
tool. In addition, if your old GNATS installation was so-called
“release-based”, you need to make some simple modifications to the
database setup file ‘dbconfig’. See below for details.
Apart from building and installing new binaries, the major changes which impinge on the upgrade procedure are all on the configuration side. The main database configuration file, ‘dbconfig’, is far more complex and powerful than the old ‘config’ file, and while the installation process creates a sensible set of default values which are similar to GNATS 3.11x’s defaults, you still need to migrate any changes you may have made to your own local configuration.
Another aspect which needs consideration are remote submitter sites.
Such sites either need to be instructed to upgrade their locally
installed copies of the GNATS user tools (send-pr
,
edit-pr
and query-pr
), or they should be given access
through interfaces such as Gnatsweb.
Since the GNATS network daemon has been completely reworked, with an entirely new command set, all network-based interfaces, such as Gnatsweb and TkGnats need to be upgraded to versions that support GNATS 4. The ‘contrib’ directory of this distribution contains some third-party interfaces, and the ‘README’ file contains pointers to where you can obtain the newest versions of these tools.
This document only deals with upgrading GNATS itself. Third-party tools should have separate upgrading instructions in their distributions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
send-pr
, query-pr
etc.) The
locations of these may vary, but in a default GNATS 3 installation,
the database(s) reside under ‘/usr/local/share/gnats’, the
executables are located in ‘/usr/local/libexec/gnats’ and the
user tools reside in ‘/usr/local/bin’.
--enable-gnats-default-db
option when running configure
,
in order to set the default database to be one of your already existing
GNATS 3 databases.
gnatsd
. There is one ‘gnatsd.conf’ for each database. In
GNATS 4, these files have been replaced by a single file named
‘gnatsd.host_access’ which contains settings that apply across all
the databases on the server. This file is located in the same directory
as the ‘databases’ file. You need to combine the host access
settings from all your GNATS 3 databases and add them to the
‘gnatsd.host_access’ file. Note that you are no longer able to
control host access on a per-database basis. Optionally, you may delete
the old ‘gnatsd.conf’ files. See section Controlling access to GNATS databases.
--enable-gnats-default-db
configure option
got a default ‘dbconfig’ installed. This default file contains
field definitions etc. which makes this version of GNATS behave
almost exactly like older versions. Copy this default file to the
‘gnats-adm’ directories of any other GNATS databases that
you may have on your host before you proceed to migrate your old
configuration settings.
The following is a list of the configuration directives that may be present in a ‘config’ file and their counterparts (if any) in GNATS 4.
This setting has no counterpart in GNATS 4, since GNATS no longer needs to know its own mail address.
This setting is now set in the ‘responsible’ file in the ‘gnats-adm’ directory of your database(s).
GNATS 4 has no concept of a named ‘site’, so this directive is obsolete.
Obsolete, since it relates to GNATS_SITE.
The GNATS 4 ‘dbconfig’ file has separate configuration
sections for each defined field. Field defaults are set with the
default
keyword in these sections. See section The ‘dbconfig’ file.
Controlled by the notify-about-expired-prs
setting in the
‘dbconfig’ file.
Controlled by the send-submitter-ack
setting in the
‘dbconfig’ file.
The default submitter is now always the first entry in the ‘submitters’ file of your database.
Controlled by the keep-all-received-headers
setting in the
‘dbconfig’ file.
Controlled by the debug-mode
setting in the ‘dbconfig’ file.
Controlled by the settings business-day-hours
and
business-week-days
in the ‘dbconfig’ file.
The default category for PRs that arrive without one is now the first category listed in the ‘categories’ file of your database.
After your are done migrating the settings, you may optionally delete the old ‘config’ files. Since there are many more configuration settings available in the GNATS 4 ‘dbconfig’ file, you should take some time to review them all before proceeding. See section The ‘dbconfig’ file.
If your old GNATS installations was release-based, i.e. it included the fields Quarter, Keywords and Date-Required, you need to define those fields in the ‘dbconfig’ file by following the instructions in Supporting old GNATS “release-based” fields.
crypt()
and MD5 passwords (see section Controlling access to GNATS databases). You need to translate your old
‘gnatsd.user_access’ files to the new format by using the
gnats-pwconv
tool which was installed in the
‘EXEC-PREFIX/libexec/gnats’ directory, typically
‘/usr/local/libexec/gnats’. See section Managing user passwords.
gnats
. Then run the gen-index
command for each of your databases. See Administrative Utilities for details on how to use
gen-index
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Chad Walstrom on March 3, 2015 using texi2html 1.82.