Vulcan Runtime Configuration

Vulcan allows database access in several modes on a single computer as well as access to various services. The means of access to a database is controlled through a cascading group of configuration files. A production system will include three configuration files, client.conf, vulcan.conf, and server.conf, all located in the installation directory. If policies for all users of that system are the same, there is no reason to create other configuration files.

A development system may need to provide different environments for different users. This document describes using configuration files for such an environment.

When a client starts, Vulcan attempts to find an appropriate configuration file for that client first by translating the environmental variable "VULCAN" in the client context. The translation should be the name of a configuration files. If that fails, Vulcan then looks for specific filenames in specific locations:

When running in a development environment, users should have private configuration files that control which vulcan they use. Those files can be specific to a working area (i.e. ./vulcan.conf) or specific to a user (i.e. ~/.vulcan.conf).

A typical private configuration file might look like this:

# /home/harrison/.vulcan.conf
# use my own development vulcan
RootDirectory /home/harrison/vulcan/install
# get the rest of the configuration information there
include $(root)/client.conf

$(root) equates to the RootDirectory. In a production system, this would default to the installation directory and need not be defined explicitly. In a development system, where different users want different copies of Vulcan, the initial configuration file should define RootDirectory appropriately.

The configuration file for the development vulcan might look like this:

Aside from the final include statement, this file contains only directions for handling various databases by name. The name may be further qualified or totally replaced in the line that begins 'filename'. The line that begin 'provider' indicate which types of access can be used. $0 represents the entire database name string as presented. $1 represents the first segment. $2 represents the remainder of the input database name string. For example if the name presented is "firebird:/databases/foo.fdb" which is caught by this database block:

In this case, the installation support three providers, engine8 which is local service, remote, and services which provides access to the services API. Each provider declaration names the specific library that is the provider. The local service also names the lock table that provider will use.