checksetup.pl - A do-it-all upgrade and installation script for Bugzilla.
./checksetup.pl [--help|--check-modules]
./checksetup.pl [SCRIPT [--verbose]] [--no-templates|-t]
[--make-admin=user@domain.com]
Name of script to drive non-interactive mode. This script should define an %answer hash whose keys are variable names and the values answers to all the questions checksetup.pl asks. For details on the format of this script, do perldoc checksetup.pl and look for the "RUNNING CHECKSETUP NON-INTERACTIVELY" section.
Display this help text
Only check for correct module dependencies and quit afterward.
Makes the specified user into a Bugzilla administrator. This is in case you accidentally lock yourself out of the Bugzilla administrative interface.
Don't compile the templates at all. Existing compiled templates will remain; missing compiled templates will not be created. (Used primarily by developers to speed up checksetup.) Use this switch at your own risk.
Output results of SCRIPT being processed.
Hey, what's this?
checksetup.pl is a script that is supposed to run during installation time and also after every upgrade.
The goal of this script is to make the installation even easier. It does this by doing things for you as well as testing for problems in advance.
You can run the script whenever you like. You MUST run it after you update Bugzilla, because it will then update your SQL table definitions to resync them with the code.
You can see all the details of what the script does at "How Checksetup Works".
There should be no need for Bugzilla Administrators to modify this script; all user-configurable stuff has been moved into a local configuration file called localconfig. When that file in changed and checksetup.pl is run, then the user's changes will be reflected back into the database.
However, developers often need to modify the installation process. This section explains how checksetup.pl works, so that you know the right part to modify.
checksetup.pl runs through several stages during installation:
Note that all the table definitions are stored in "ABSTRACT_SCHEMA" in Bugzilla::DB::Schema.
resolution, bug_status, etc.) using "bz_populate_enum_tables" in Bugzilla::DB.$webservergroup in localconfig.
The function that does this is "fix_all_file_permissions" in Bugzilla::Install::Filesystem.
fielddefs table, using "populate_field_definitions" in Bugzilla::Field.The code for this is in "update_table_definitions" in Bugzilla::Install::DB.
editbugs, admin, and so on. This is "update_system_groups" in Bugzilla::Install.We also can make somebody an admin at this step, if the user specified the --make-admin switch.
Sometimes you'll want to modify the database. In fact, that's mostly what checksetup does, is upgrade old Bugzilla databases to the modern format.
If you'd like to know how to make changes to the datbase, see the information in the Bugzilla Developer's Guide, at: http://www.bugzilla.org/docs/developer.html#sql-schema
Also see "Schema Modification Methods" in Bugzilla::DB and "Schema Information Methods" in Bugzilla::DB.
To operate checksetup non-interactively, run it with a single argument specifying a filename that contains the information usually obtained by prompting the user or by editing localconfig.
The format of that file is as follows:
$answer{'db_host'} = 'localhost';
$answer{'db_driver'} = 'mydbdriver';
$answer{'db_port'} = 0;
$answer{'db_name'} = 'mydbname';
$answer{'db_user'} = 'mydbuser';
$answer{'db_pass'} = 'mydbpass';
$answer{'urlbase'} = 'http://bugzilla.mydomain.com/';
(Any localconfig variable or parameter can be specified as above.)
$answer{'ADMIN_EMAIL'} = 'myadmin@mydomain.net';
$answer{'ADMIN_PASSWORD'} = 'fooey';
$answer{'ADMIN_REALNAME'} = 'Joel Peshkin';
$answer{'SMTP_SERVER'} = 'mail.mydomain.net';
$answer{'NO_PAUSE'} = 1
NO_PAUSE means "never stop and prompt the user to hit Enter to continue, just go ahead and do things, even if they are potentially dangerous." Don't set this to 1 unless you know what you are doing.