Database Distribution: System Files

local.config

This csh script is sourced by scripts such as run_import.sh to set up the SRT and DBMauto environments. Normally there is only one configuration file per site, although there may be more, for example is a site is both a Master and a Slave.

For sh and bash users the file will have to be modified. Change lines from:-

  set switch value

to:-

  switch=value
  export switch    
  ( on bash you can abbreviate this to:
       export switch=value )

The local configuration file starts by defining a set variables that define:-

The code base i.e. $SRT_DIST
The base release i.e. development
The SRT setup up file.
The Test Release directory (if there is one).

Initial values for these variables are taken from the environment during priming but may be adjusted as required. If your setup scripts are in a non-standard place then you can by-pass these variables and hack your version of launch.csh (.or .sh) replacing the section that starts:-


    ###  Load the configuration file.

replacing them with the code you need to set up MINOS.

local config also defines :-

The Database environment ENV_TSQL_*

It is essential, both for importing and exporting, that a Database account with write access is selected with the ENV_TSQL_* variables. These are primed with the ENV_TSQL_UPDATE_* variables, or set to "???" if those variables are not defined while priming. Make sure that local.config only lists one database, the default might be to have 2 with "temp" as the first, in which case the updates will go into "temp"!!

The remainder of the configuration file contains the following entries to configure DBMauto:-

dbm_host is the name of the local host. It is used to identify checksum reports. If undefined the system will use the hostname but installers should replace this with something more appropriate e.g.:-
dbm_update_names is a space separated list of update_names (i.e feeds between databases) e.g.:- although, for Slave sites it is always:- hat selects a single standard feed from the FNAL database.
dbm_mode is the mode of operation. This must be either:- or:-
dbm_command_options will be primed to the import options:- --EnableSQL --Table *,\!DBUVA*,\!DCS*,\!PULSER*" --EnableSQL allows SQL fixups to be applied. The --Table option is used to select or reject tables. In this case it disables updates to any DBUVA*, DCS* and PULSER* tables as these are not of general interest. Individual site managers may choose to adjust what tables are imported. If enabling tables that have been disabled, it may be necessary to get updates using the Database Priming system. If you include the '!' character, it must be preceded by a backslash
After changing the --Table option you should review the
```
  analyse_checksum.filter
```
of the Distribution Validation System
For export mode dbm_command_options should be set to a string containing a comma separated list of tables to be exported e.g.:-
--Table=* e.g.:- --Table=*,\!DBU*,DBUSUM* The above exports all tables except those starting DBU unless they are DBUSUM*.
dbm_work_dir is the work directory where update files are stored and should be
```
    top_dir/work
```
dbm_publish_dir is the public directory where update files are stored. The collaboration standard publish directory is This is fine if you have AFS. If not you will need a way of copying the data across to a directory that you can access. The method we have chosen is rsync. See Distributing Update Files.
dbm_heartbeat_freq is the frequency with which summaries are mailed to the contact list. After a summary has been sent out a counter in a context file is set to heartbeat_freq and then counts down each time the cron job runs and when it reaches zero, sends mail again. For example, if the cron job runs hourly, and heartbeat_freq is set to 24, summaries will be mailed once a day.
dbm_contact_list to a space separated list of email address. Please don't leave as the default, Nick really doesn't want to be the contact for every distribution. If you include the '@' character, it must be preceded by a backslash e.g.:-
Set dbm_coordinator_list to a space separated list of email address. This list will be used as part of the Distribution Validation System. For now leave this set to:-

run_import.sh

This is a cron job script used to import data into the local database.

run_checksum.sh

This is a cron job script that is part of the Distribution Validation System. It carries out a checksum analysis of the local database and sends the results to the dbm_coordinator_list.

FNAL_import.context

This is a file read by run_import.sh to determine what update to take next and when to send heartbeat mail

Here is a typical .context file:-

Hearbeat No:           19
Update No:             146

run_export.sh scripts also use .context files although these have a further two lines. For example-

Heartbeat No:          19
Update No:             146
Export last date:      2003-01-09 12:32:24
Export previous date:  2003-01-09 11:18:15

DBMauto supports a second type of Heartbeat: clock synchronised, that reports at a specified time of day rather than after a specified number of program executions. The advantage is that it appears at the same time day even if, for some reason, the cron job has run less frequently (or more frequently). This format looks like:-

Heartbeat No:          At: 01:00:00  Next: 2006-05-20 01:00:00

It gives the time of day (At:) and when the next report is due (Next:). To switch to this form simply change your context file to this format but follow the data and time syntax exactly or it will not be recognised and will continue to use program execution counting.

Note that date/times all are in UTC.

After priming or repriming the database change the update number to the value corresponding to the priming update set you used.

FNAL_import.log

This contains a log of the imports into the local database. For Master sites there is a corresponding log of exports. Note that date/times all are in UTC.