<<

checksetup.pl

NAME

checksetup.pl - A do-it-all upgrade and installation script for Bugzilla.

SYNOPSIS

 ./checksetup.pl [--help|--check-modules]
 ./checksetup.pl [SCRIPT [--verbose]] [--no-templates|-t]
                 [[email protected]]

OPTIONS

SCRIPT

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.

--help

Display this help text

--check-modules

Only check for correct module dependencies and quit afterward.

--make-admin[email protected]

Makes the specified user into a Bugzilla administrator. This is in case you accidentally lock yourself out of the Bugzilla administrative interface.

--no-templates (-t)

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.

--verbose

Output results of SCRIPT being processed.

DESCRIPTION

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".

MODIFYING CHECKSETUP

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.

How Checksetup Works

checksetup.pl runs through several stages during installation:

  1. Checks if the required and optional perl modules are installed, using "check_requirements" in Bugzilla::Install::Requirements.
  2. Creates or updates the localconfig file, using "update_localconfig" in Bugzilla::Install::Localconfig.
  3. Checks the DBD and database version, using "bz_check_requirements" in Bugzilla::DB.
  4. Creates the Bugzilla database if it doesn't exist, using "bz_create_database" in Bugzilla::DB.
  5. Creates all of the tables in the Bugzilla database, using "bz_setup_database" in Bugzilla::DB.

    Note that all the table definitions are stored in "ABSTRACT_SCHEMA" in Bugzilla::DB::Schema.

  6. Puts the values into the enum tables (like resolution, bug_status, etc.) using "bz_populate_enum_tables" in Bugzilla::DB.
  7. Creates any files that Bugzilla needs but doesn't ship with, using "update_filesystem" in Bugzilla::Install::Filesystem.
  8. Creates the .htaccess files if you haven't specified not to in localconfig. It does this with "create_htaccess" in Bugzilla::Install::Filesystem.
  9. Updates the system parameters (stored in data/params), using "update_params" in Bugzilla::Config.
  10. Pre-compiles all templates, to improve the speed of Bugzilla. It uses "precompile_templates" in Bugzilla::Template to do this.
  11. Fixes all file permissions to be secure. It does this differently depending on whether or not you've specified $webservergroup in localconfig.

    The function that does this is "fix_all_file_permissions" in Bugzilla::Install::Filesystem.

  12. Populates the fielddefs table, using "populate_field_definitions" in Bugzilla::Field.
  13. This is the major part of checksetup--updating the table definitions from one version of Bugzilla to another.

    The code for this is in "update_table_definitions" in Bugzilla::Install::DB.

  14. Creates the system groups--the ones like editbugs, admin, and so on. This is "update_system_groups" in Bugzilla::Install.
  15. Creates all of the user-adjustable preferences that appear on the "General Preferences" screen. This is "update_settings" in Bugzilla::Install.
  16. Creates an administrator, if one doesn't already exist, using "create_admin" in Bugzilla::Install.

    We also can make somebody an admin at this step, if the user specified the --make-admin switch.

  17. Creates the default Classification, Product, and Component, using "create_default_product" in Bugzilla::Install.

Modifying the Database

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: https://www.bugzilla.org/docs/developer.html#sql-schema

Also see "Schema Modification Methods" in Bugzilla::DB and "Schema Information Methods" in Bugzilla::DB.

RUNNING CHECKSETUP NON-INTERACTIVELY

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'} = '[email protected]';
 $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.

SEE ALSO

<<