![]() |
Installing the QEF System on UNIX and Windows. |
![]() |
![]() |
The Q-Tree can be installed anywhere there is 10 to 15 megabytes
of disk space available. The actual size of the installation
depends on the platform and the version of the product.
If you are using qef on a single system, the conventional locations to install the Q-Tree are /usr/qtree or /usr/local/qtree. If you expect to be using more than one version of the Q-Tree use a name that incorporates the Q-Tree release number as in /usr/local/qtree/8.4. If you are planning to install the Q-Tree for multiple platforms then the installation directory name should include both the release number and the type of the system, as in /usr/qtree/8.4/linux2_0i. The Q-Tree includes a program sysnm that prints out a canonical version of the system name that you can use in your $PATH settings. For example, you could use the following shell expression /qtree/8.4/`sysnm` to map to where the Q-Tree is installed. sysnm outputs the type of the system by mapping the output of uname into a standard form. This naming scheme is recommended, however, it does require that you can find sysnm before you know the location of the Q-Tree, which may raise problems if users have login scripts that are shared by all platforms. A possible solution is offered below in the Creating Lclqtree section below. The value of sysnm for the current distribution can be determined by looking at the relinfo file in the distribution directory. The first line will look something like: Qtree(full) 8.4.6(567) - Linux-2.0.34-i686(linux2_0i)The sysnm value appears after the configuration name in parentheses (e.g., linux2_0i in the above example). In the documentation that follows the location of the Q-Tree is referred to as <newqtree>. |
![]() |
If you are not updating an existing copy of the Q-Tree, this
warning may be ignored until such time as you are.
If updating an existing Q-Tree, one should take measures to ensure that any modifications that have been made to the existing installation are preserved. The Q-Tree is designed to store all volatile files in its data/ directory and the installation process will not over-write any existing files in that directory. However, there are a few files that are not in data/ that might be modified locally to facilitate use, such as:
The following is a possible way of protecting such files: % cd $QTREE # chdir to the root of the Q-Tree % rls -sf -yrelinfo | ct # find files younger than the # relinfo file and save list in a cut file % pa -n # note the cut file index for future use % vi `pa -n` # edit cut file to examine its contents and to # to remove any files that need not be protectedNow the installation is performed as described below. Once that process has completed, the saved copies (as named in the ct/pa file created above) can be examined to incorporate any required local changes. |
![]() |
The QEF installation on a Windows system is done using
a conventional Windows install. Change into the directory containing
the distribution image and run the setup.exe program. This program
will ask you a series of question and install the software on your
computer.
![]() |
![]() |
This text appears in the Readme.txt file of a distribution, the
x_db database x-qmisc, and this appendix.
The non-Microsoft versions of QEF product is distributed as a compressed (if possible) tar file. When the tar file is uncompressed and untarred, it creates a directory called Qtree.install that contains the following files:
To run Install, you will have to provide the following information:
Install will prompt the user for the above settings when required. Alternatively they can be specified via flags. Information and advice on the settings of the above is given below. |
![]() |
The Install program is usually started in the Qtree.install directory. It may be invoked from a remote directory by providing the name of the distribution directory using the -D flag. Install's basic processing consists of:
Install should be run as the user who is to own the Q-Tree files. This should not be root.
|
![]() |
The command: Install -x will list and explain Install's options and flags. A response of '?' to any prompt will explain the prompt and the possible or required responses to the prompt. You will be asked if a step is to be skipped if a file that would be created already exists. If the file does not exist, the step will be performed unconditionally. |
![]() |
To install the system, Install is run in the Qtree.install
directory.
In the following, [#] refers to notes that follow the listing.
% ./Install # install the product Note: A response of `?' to any prompt will explain that prompt and any valid or required responses. A response of EOF (i.e., usually ^D) will cause the program to exit. |
Licence text is displayed |
QEF ADVANCED SOFTWARE INCORPORATED ELECTRONIC END USER LICENSE AGREEMENT FOR THE QEF SOFTWARE PROCESS AUTOMATION SYSTEM ... Distribution directory=dir/Qtree.install |
prompt for new qtree name |
Enter name of destination directory: <newqtree><Enter> + tar -xf dir/Qtree.install/bin.tar [1] |
prompt for manlink |
Name directory to be symlinked to man: <Enter> + tar -xf dir/Qtree.install/man.tar [2] |
prompt for datalink |
Name directory to be symlinked to data: <Enter> |
prompt for qd server host/port |
Enter qdsrv host/port setting: gobo/6631 + <newqtree>/bin/dirsetup -shgobo -sp6631 |
creation of demo licence |
+ connecting to qdsrv Adding Demo(1) 2000/06/13 [4] |
Notes on above |
|
![]() |
|
<newqtree> | See Section 1. |
<manlink> | This directory will require about 3 Megabytes. If possible it is desirable to have a single man directory shared by all the Q-tree installations. This is done by specifying to Install, via the -m flag or when prompted, the <manlink> directory to be symbolically linked to <newqtree>/man. Typically this would be the man directory of another previously installed Q-Tree. |
<datalink> |
The data directory (see <Q>/data(x-qef)) will initially require
less than a Megabyte, but it contains log files and databases
that will grow considerably, thus a minimum of 3 Megabytes of
available space is recommended. This directory should be shared
by as many installations as possible. This is done by specifying
via the -d flag or when prompted, the <datalink> directory to
be symbolically linked to <newqtree>/data.
Typically this would
be the data directory for the host that runs qdsrv,
as named by
QDSRV_HOST and as initialized by the QDSRV_settings>.
|
QDSRV_settings | This setting should be `/' separated catenation of the name of the host that runs qdsrv and the port number used by clients to connect to that server, for example `localhost/6631'. If there has been a previously installed Q-Tree, these settings should be the same as those used on that system. Note that all systems on the local network can use the same qdsrv. When doing the first installation, the name of the current host should be used so that qdsrv can be run as soon as the traits file has been installed. (This will be required to support the creation of the 60 day demo licence created on the first installation.) The settings can be changed at a later date by editing <newqtree>/data/traits.ext. |
![]() |
To use the newly installed system:
% export QTREE=<newqtree> % export PATH=<newqtree>:$PATH # equivalent csh commands left as exercise for the readerFor more information on starting to use the QEF system, see Chapter 3. |
||
Starting qdsrv |
Once the Q-Tree has been installed,
if the current host is the one that will run qdsrv
(i.e., QDSRV_HOST)
the bootstrap process should be modified
to start qdsrv.
# Add following to appropriate boot script <newqtree>/bin/qdsrv -QThe above command should be added to the appropriate start up scripts, such as /etc/rc.d/rc.local or its equivalent. The -Q flag specifies that the path of the invoked program up to but not including /bin is taken to be the setting of $QTREE, a step that is required as it may not have be previously set. To halt the server when shutting down or rebooting the system, add the command: <newqtree>/bin/qdmgt -Q quitto the appropriate location on your system. On systems that use a SysV init scheme, the command: % x-qefeg -M rc.d/qdsrv #!/bin/sh # # description: Starts and stops the qdsrv # processname: qdsrv # ...will output a shell script suitable for inclusion in /etc/rc.d/init.d and the /etc/rc.d/rc[1-5].d directories.
|
||
qdsrv host.qtree variable |
The remote execution program qremote needs to know the
location of the Q-Tree for its target host.
This is done by retrieving the qdsrv variable host.qtree,
thus once a Q-Tree is installed, this variable should be set
as in:
% qdmgt vset host.qtree <newqtree> |
![]() |
Some of the files in <newqtree>/data may need modification. The company.cf file should be edited to make the appropriate settings, but this is optional. | ||||
data/traits.ext |
The <newqtree>/data/traits.ext should be examined particularly
with respect to the settings of: LD_LIBRARY_PATH
(if required),
LM_LICENSE_FILE (if required),
STD_PATH, and BuildPath.
The latter two are set in <newqtree>/lib/traits.vrs, but may need
to be modified in the traits.ext to conform with the local system.
|
||||
dirsetup dotqtree database | To facilitate setting up new QEF users, the dirsetup database dotqtree should be localized. See Appendix C: New User Setup. | ||||
lib/sysvrs/*.vrs |
The qvrs file for the system might need to be modified
to reflect local or site dependent settings.
The file used for the current system is named and displayed by:
% qvrs -Ps # name and display the sysvrs file <newqtree>/lib/sysvrs/linux2.vrs: # SID @(#)linux2.vrs 7.4 - 00/02/18 ...Before this file is modified it is recommended that a copy be created using: % upd -ic <newqtree>/lib/sysvrs/linux2.vrs - cp <newqtree>/lib/sysvrs/linux2.vrsNote that some of the settings (e.g., GccLibDir) use @(trait Var). The trait function retrieves the setting for Var from the traits database. Any new, possibly site dependent settings should be made in the traits database and incorporated into the sysvrs.vrs file using the trait function. |
||||
lib/envset |
The lib/envset file is used to set the necessary environment
variables when qremoteing to the host.
As such it may be necessary to modify this file to correct the
contained qremote set.
This file as distributed has settings for $PATH,
$LD_LIBRARY_PATH, and $LM_LICENSE_FILE using values
retrieved from the traits database.
To change:
# make backup copy of the current version % upd -ic `pathto qt/lib/envset` % ed `pathto qt/lib/envset` # edit as required |
![]() |
The installed Q-Tree will contain three setuid files. The owner of these files should be the owner of the data directory and its files. The setuid programs are:
|
![]() |
This section addresses the problem of determining the location
of the Q-Tree in a system independent way as might be required
in a login shell script.
One possible mechanism to avoid the problem is to create symbolic links with a universally used name such as /usr/local/qtree to the appropriate directory on each system or host that needs it, however, that approach obscures important information that might be needed in the build record. As discussed in Section 1, if sysnm may be required to name the $QTREE to be used on a system. However, sysnm itself and the database it uses have to be located. In the following solutions, a new file will be created for each and every platform that will be using the Q-Tree. This file must have the same basename on all platforms. Furthermore it must be either rooted or always in the default $PATH for each platform (e.g., could be /bin on one system or /usr/bin on another). There are two possible schemes for resolving the problem of determining the appropriate value of $QTREE at login or in an rsh command:
Option 2a provides a sh script that can be used to map other products or systems and allows the user more control on the Q-Tree release to be used. Both the option 1 and 2a scripts can be implemented to be system independent, so that the same script can be used on all platforms. Option 2b has the same advantages as 2a, other than system independence. If has the advantage that the database can be changed without the needing to modified Lclsysnm itself, whereas options 1 and 2a will require fixing the shell scripts if the database changes. |
||
Option 1: Lclqtree Sh Script |
A shell script that simply outputs an appropriate $QTREE setting
for the host is created.
The commands:
% x-qefeg -M Lclqtree > Lclqtree % chmod +x Lclqtree # make it executablewill create such a script. The generated script offers alternative implementations that use case statements based on hostname or uname. Use of these alternatives can produce a platform independent script that can be shared by all systems. If this option is employed, the users add: export QTREE=`Lclqtree` export PATH=$QTREE/bin:$PATHor the equivalent csh commands to their .profile or .login file. |
||
Option 2a: Lclsysnm Sh Script |
A shell script that simply outputs the system type
for the host is created.
The commands:
% x-qefeg -M Lclsysnm > Lclsysnm % chmod +x Lclsysnm # make it executablewill create such a script. The generated script offers alternative implementations that use case statements based on hostname or uname. Use of these alternatives can produce a platform independent script that can be shared by all systems. If this option is employed, the users add: SYSNM=`Lclsysnm` export QTREE=/p/opt/qtree/8.4/$SYSNM export PATH=$QTREE/bin:$PATHor the equivalent csh commands to their .profile or .login file. An alternative name for the shell script may be used, provided it is the same for all platforms. |
||
Option 2b: Lclsysnm Binary |
If this historic option is chosen,
sysnm is copied to the appropriate directory patching in
the pathname for the system database.
The basename of the copy must end with "sysnm" (e.g., Lclsysnm) as the last five letters are checked to determine the default flag. sysnm is a link to system which implies the -n flag. system uses a database called $QTREE/data/sysnames.tab to map the host platform's uname -srm fields to names for the system. See the comments at the beginning of that file for a description of the mapping and the various names. Given that sysnm need to locate this database before $QTREE is set, the default pathname for the database is embedded in the program itself starting at the ninth character of a 100 character array. The first eight characters of the array are "@HERE@:=". To embed the name of the database in the system binary, use the following command: % setbytes -i `fnd sysnm` -o lclsysnm \ 8+`fndstr @HERE@:= sysnm` \ "<newqtree>/data/sysnames.tab\0" % chmod +x lclsysnm % ./lclsysnm -x # check patch - -f description name DB % ./lclsysnm # check program can read databaseSee system(1) for a fuller description of the above.
|
||
The default $QTREE | The default $QTREE is set at compile time, however it is done in such a way that it can be changed. The brave installer can change the default $QTREE using a technique similar to the above using the power of the Q-Tree tool set as described in DefaultQtree(x-qmisc). | ||
The relinfo File |
When the Q-Tree is installed, the relinfo file should have the
most recent modification time.
This fact is used when doing a re-installation as illustrated by the
Warning section in Section 1.
If in the course of normal use and/or modification,
any file of the Q-Tree (other than in data/) is changed or
a new file is created, it should be done in a way that will change
its last modification time.
touch or untouch may be used to ensure that the
file is younger than the relinfo file.
|
x010.qh - 1.23 - 00/05/30 |
![]() ![]() ![]() ![]() ![]() |