Setting up OID server
What release should you use?
It can be any BaBar production release starting from 10.2.3 and up, or any test release starting from 11.3.0 and up.
ACE/TAO CORBA is required on machines where compilation of OID server software is to be performed. See Required Software for BaBar Computing for more details.
It's also required to have the CORBA Name Server (ACE/TAO implementation) running before starting the OID Server.
Where do I find installation files?
These files are located in the BdbCondRemote package.
What do I install?
Binaries for the OID server and its management utility:
Installing OID server
Because the same installation of the OID server may be used to serve multiple federations at the same time, the installation is performed in two phases:
Choose a machine where the OID server is to be installed and run. Here is a list of suggested requirements for configuring this machine:
- The OID server is a multithreaded application and it may benefit from using multiple CPUs. By default, the server will run with four active threads, although this can be tuned by passing the corresponding run-time parameter to the server's binary. Performance tests indicate that the maximum server performance (up to 4 kHz requests) and CPU utilization (up to 75% in total) is achieved on a 4-CPU machine with no more than 10 server's threads.
- It's advisable to have this machine close to an AMS server(s) where the corresponding Condition/DB is residing for performance reasons.
- The installation must be done either on a local or an NFS mounted disk of this machine. Never install the server on an AFS file system (to avoid token expiration problem). This is because the server will write the log file while running.
Create a directory where the installation of the server will be performed. This directory will contain the binaries of the server and its management utility, supporting and management scripts (see above).
For example:mkdir /u1/oidserver cd /u1/oidserver
Create the following directories in this directory:
Binaries for the server, its management utility and supporting scripts.
Server configuration files. There will be two files for each federation served by this installation. See the federation specific phase for more details.
Log file of the management operations (start, stop, and so on). When the first management operation on the server is done the activity.log file will be automatically created in this directory. This will be the only file in this directory.
Log files for the server. This directory will have a dedicated sub directory for every federation to be served by this installation. See the federation specific phase for more details.
Temporary files created by the server. This directory will have a dedicated sub directory for every federation to be served by this installation. See the federation specific phase for more details.
Example:mkdir bin config journal log tmp chmod 0777 bin config journal log tmp
Make sure the binaries for the server and its management utility are built. If not, check the BdbCondRemote package from CVS and build all its targets:gmake CdbCondRemote.all
Copy the following files into the bin directory of the installation area:cp <source directory>/BdbCondROIDServerApp bin/ cp <source directory>/BdbCondRemoteCmd bin/
Copy two supporting scripts from the CVS or the corresponding release where the BdbCondRemote package is located (these scripts are not built in normal sense) into the bin/ sub-directory of the installation.
Example:cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/get_gree_kb bin/ cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/wrap_oidserver bin/
Copy five management scripts from the CVS, or the corresponding release, where the BdbCondRemote package is located (these scripts are also not built in normal sense) into the main directory where the installation is performed.
Example:cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/oidserver_monitor ./ cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/oidserver_restart ./ cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/oidserver_start ./ cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/oidserver_statistics ./ cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/oidserver_status ./ cp $BFDIST/release/$BFCURRENT/BdbCondRemote/oid/oidserver_stop ./
Make sure that the copied binaries and scripts get "x" (executable) access mode for a UNIX account that is meant to run and manage the server.chmod +x bin/* chmod +x ./oidserver_*
Federation specific phase:
Choose a short (nick-)name for a federation to be served by this installation.
Create the following directories for a federation using its nickname.mkdir log/<federation> mkdir tmp/<federation>
Example:mkdir log/test mkdir tmp/test
Make sure an account under which the OID server and its management scripts are to be run has full access to these directories.chmod 0777 log/<federation> chmod 0777 tmp/<federation>
Create a simple text file and put the corresponding BOOT file name for the federation at the following location:config/<federation>.bootfile
Example:echo $OO_FD_BOOT > config/test.bootfile
Determine the value of the IOR of an instance of the CORBA Name Server that will be used to support the corresponding federation. Put the value (as single string) of this server's IOR into the following text file:config/<federation>.ns_ior
For easier management, in case the CORBA Name Server gets restarted, you can use a symbolic link onto a file with the actual IOR of the Name Server. Here is how it can be done at SLAC:ln -s /nfs/oprserv01/u1/TAO/TAO_NS.ior config/test.ns_ior
The following step involves some manual work in order to modify the oidserver_ scripts copied into the root directory of the installation. Look in this script and modify each occurrence of:case <federation>:
to list the current federation as a recognized one.
Modify the oidserver_ scripts to specify the location and host name where this installation is performed. This will allow you to run the scripts using the fully qualified path without doing the "cd" into the installation directory to run the scripts.
Who to contact for problem resolution?
In case of problems, contact Igor Gaponenko.
BaBar Public Site | SLAC | News | Links | Who's Who | Contact Us
Page Owner: Jacek Becla
Last Update: June 13, 2002