| |
|
|
|
2 CONFIGURATION DATABASE
2.1 Purpose of the VCCDB
The main idea of a VLT common configuration database (VCCDB) is to have a single centralized configuration definition for the whole network, from which all host-based files can be derived, and from which configuration data can be queried by engineering interfaces and applications at run-time.
The SQL-based database of the Access and Configuration Control (ACC) module has been chosen for this purpose, since it contains - apart from other data - all information that are relevant for environment configuration. 1
To set up such a database, please refer to the dedicated ACC documentation for details [4].
2.2 On-line Configuration Access
The vcc tools can work with or without a VCCDB, but the functionality without it will be very limited. Some of the tools and programs will not work at all. The ACC database is queried for configuration information at run-time.
In order to access the VCCDB at run-time, you have to set the shell-variable ACC_HOST to the host on which the database server is running, e.g.:
After that the configuration information is taken from that VCCDB.
If you wish to work without VCCDB, then you must not define the shell-variable ACC_HOST and, so that no access will take place.
Note that none of the tools and functions described in this manual ever writes into the VCCDB. Only ACC facitlities are intended to write to the database.
2.3 System Configuration Files
7 Global configuration files can be derived automatically from the VCCDB. Such a feature will be added in a future release. For the time being, these files shall still be edited by hand.
The following table shows which files are needed for which type of environment, and in which manual pages detailed information about their contents can be found:
2.3.1 exports (HP) or dfstab (SUN)
All LCUs that boot from the WS must have an entry in this file to allow NFS mounting. Note that an additional command is necessary to commit any changes in the file.
2.3.2 hosts
All nodes, WS and LCU, must have an entry in this file to establish the mapping between host-names and IP-addresses.
2.3.3 services
From the communication point of view, each environment is identified by the node on which is running and a TCP/IP port number. The same number can be used on different nodes for the same type of environment. Currently we use:
2.3.4 logLCU.config
To establish the assignment between LCU and WS environment to which logs shall be sent.
2.3.5 lqs.boot
Each LCU needs to know from which host it has to boot and which are the other environments: CCSs and QSEMUs (an LCU should not talk directly to other LCUs). If LCU(s) need to communicate with more WS environments than the assigned boot environment, then the file "$VLTDATA/config/lqs.boot" must be created and edited. The standard file in "$VLTROOT/vw/bin/$CPU/lqs.boot" can be taken as template. Otherwise the installed default is enough.
2.3.6 RtapEnvList
Each CCS (RTAP) environment needs to know where other CCS, QSEMU, LCC environments are located, they can be both local or remote to the WS. RtapEnvList provides such a mapping.
2.3.7 CcsEnvList
This is the equivalent of RtapEnvList for CCS-Lite Environment. It also uses the same sintax. A template is installed in $VLTROOT/config/CcsEnvList.
2.3.8 .rhosts
The LCU performs during start-up remote-shell accesses to the booting WS under the user-name `vx'. In order to enable that, the node-name of the LCU must be stated in the file ~vx/.rhosts, i.e. in the home-directory of user vx..
1In the JUL95/DEC95 release a prototype of the VCCDB was implemented as Rtap database. Such implementation is no more available. The shell-variable VLT_VCCENV shall not be defined any longer.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|