BES Configuration File

From OPeNDAP Documentation
Revision as of 23:32, 1 October 2009 by PatrickWest (talk | contribs) (Suggested Solution)

1 Current Problem

Currently, any modules that the BES loads adds information to the one BES configuration file. This causes problems in many scenarios.

  • Development work where you have to do a 'make install' many times, which over-writes the BES configuration file
  • Upgrading the BES, the install over-writes the configuration file

2 Suggested Solution

  1. The BES configuration file holds only the information for the BES, no loaded modules
  2. Add new keywords in the configuration file to include other configuration files, like what Apache HTTPD does
    • include conf.d/*.conf - we would do something similar to this
    • allow regular expression matching of files I think globbing is good enough - no need for full on regexes.
    • allow for a direct include
    • allow multiple includes
    • recommend that they leave the include line alone, and rename conf files if they don't want them installed (like with Apache HTTPD)
    • Modify the behavior for BES.modules, or have a new keyword like "Add BES.modules", or BES.addModules=nc and keep the BES.nc.module=<path_to_so> Right, because the current keyword does it all in one shot and we need a new keyword to allow the information to be built up over several lines from several files.
  3. When doing an install, don't install a new configuration file, but update the one that is there, if need be. Same with the install target to make, only make changes that need to be made.
    • Perhaps a script that gets run to update the BES configuration file with any changes needed

Do not edit an existing configuration file as part of make install. Install a replacement file that, maybe, is built from the existing file using a new name. So read bes.conf and use that to build bes.conf.new that is then copied to the new directory. We can include a special target to do the 'dangerous' operation of moving the bes.conf.new to bes.conf so our automated builds run more smoothly, but sysadmins will balk at having 'make install' modify their configuration(s)