systools v6_1 -0 -g current |__cmdbin v1_1 -2 -g current | |__cmdbincmd v1_1 -2 -g current | |__cmdbingen v1_1 -2 -g current | |__cmdbinutl v1_1 -2 -g current | |__perl v5_004 -2 -g current |__cmdscripts v1_1 -0 -g current | |__cmdscriptsbase v1_1 -0 -g current | |__cmdscriptsctrl v1_1 -0 -g current | |__cmdscriptsguid v1_1 -0 -g current | |__cmdscriptslgrp v1_1 -0 -g current | |__cmdscriptshell v1_1 -0 -g current | |__cmdscriptsuser v1_1 -0 -g current | |__shells v3_1 -2 -g current | | |__bash v2_03 -2 | | |__tcsh v6_09 -2 | |__template_home v1_3 -0 -g current | |__login v1_6 -0 -g current | | |__setpath v1_9 -0 -g current | | |__setterm v1_3 -0 -g current | | |__setxwin v1_12 -2 -g current | | |__Info v1_5a -0 -g current | |__shrc v1_9 -2 -g current |__systoolsutl v1_2 -0 -g currentWhere each of the product names above refers you to a brief page about the product.
The documentation is currently in DCD3.5, The older versions of systools are documented in DCD3.4,
If you have an old version of systools (pre-v6_0) installed, you will want to take care that your /usr/local/systools/library files don't get removed by any uncurrent or unconfigure actions. Since the new systools product is NULL-flavored, and the old versions of systools were flavored, the installation and declaration of the new version of systools will not undeclare the old version(s). This is beneficial since it keeps your existing /usr/local/systools/library files intact, but it also means that you will have the old systools product(s) and the new NULL-flavored version declared current in most cases. To eliminate the current declaration for all old systools versions, while avoiding their uncurrent or unconfigure actions, we recommend that you convert your current.chain file to old.chain in the data-base directory for systools, using the following steps:
1) Obtain the database and systools product information: $ ups list systools -aKdatabase:+ "/fnal/ups/db" "systools" "v6_1" "NULL" "" "current" "/fnal/ups/db" "systools" "v4_3" "SunOS+5" "" "current" 2) Using the information from the first field, convert the current.chain file to old.chain: $ cd /fnal/ups/db (wherever your database resides) $ cd systools $ sed -e "s/ *= *current/ = old/" <current.chain >old.chain $ mv current.chain current.chain.save 3) If you have already installed the latest version of systools, redeclare it from old to current: $ ups declare systools v6_1 -0 -c $ ups undeclare systools -0 -o 4) Verify that the changes look right, and clean up: $ ups list systools -aKdatabase:+ "/fnal/ups/db" "systools" "v6_1" "NULL" "" "current" "/fnal/ups/db" "systools" "v4_3" "SunOS+5" "" "old" $ rm current.chain.save
Systools and its dependent products are now meant to be installed from a regular account, not root, with a command like:
upd install systools v6_1 -G -c [-z <your_database>]
Note that you must specify the database if it's not first in $PRODUCTS.
After installation, the following command must be issued as root to make the cmd command and its associated scripts usable:
ups InstallAsRoot systools [-z <your_database>]
The InstallAsRoot action copies scripts and executables into the proper directories, with root ownership and the required permissions. If there are already files in the target directories, the files will be copied with a suffix of '.NEW'. This can happen when new component products of systools are installed. In most cases, the '.NEW' files can be renamed without the suffix, but you may need to merge the existing and new files if you've made customizations.
Nota Bene: There is a problem with ups versions prior to v4_5_1 which prevents the execution of the InstallAsRoot actions on Linux platforms. The recommended approach is to install ups version v4_5_1 or later, but you can work around this problem by issuing the following series of commands instead of the normal 'ups InstallAsRoot systools' command:
/bin/sh `$UPS_DIR/bin/ups InstallAsRoot systoolsutl -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdbincmd -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdbingen -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdbinutl -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdbin -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscriptsbase -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscriptsctrl -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscriptsguid -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscriptslgrp -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscriptshell -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscriptsuser -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot cmdscripts -s 2>&1 | cut -f 8 -d' '` /bin/sh `$UPS_DIR/bin/ups InstallAsRoot systools -s 2>&1 | cut -f 8 -d' '`
Note that although the new versions of systools are NULL-flavored, the cmdbin components are platform-specific, and must be installed for each flavor you wish to support. You may repeat the install and InstallAsRoot commands specifying the flavor (for either cmdbin or systools product):
upd install systools v6_1 -G -c [-z <your_database>] -H <flavor> ups InstallAsRoot systools -H <flavor>
For systems with an old version of systools (pre-v6_0) already installed, there is a convert script meant to be executed via the command:
ups ConvertAsRoot systools
The ConvertAsRoot action is provided as an aid in upgrading old systools library functions to the new upsII/systools v6_1 system. Its purpose is to copy existing systools files from the old /usr/local/systools/library directory to the new target directory, and make necessary changes so that they can work with the new ups/systools scheme. There is no guarantee that the edits made by this routine are sufficient or even completely correct, since the original scripts may have virtually anything in them.
After conversion, the original files will be marked with the suffix '.CONV'. These converted scripts should be compared with the new files which are part of the systools packages, and the differences merged. Normally, the functions.CONV file is simply renamed as functions. The sys.env file has numerous improvements, however, so the sys.env.CONV file must be examined and the appropriate variables set in the new sys.env file, paying particular attention to the SHADOW, YPDIR, and YPMAKE values.
The final step in finishing the conversion from pre-v6_0 systools to v6_1 is to move the old cmd executables out of the way. We recommend that they be replaced with a script which reminds the users that systools must now be setup before use:
# mv /usr/local/bin/cmd /usr/local/bin/cmd.old
# echo "echo You must setup systools to use cmd" > /usr/local/bin/cmd
# chmod +x /usr/local/bin/cmd
Remember that one or the other of the preceding actions must be done for each /usr/local/bin directory in your cluster, if you have multiple copies, e.g. for different flavors.
If you have previously installed systools v6_0 (which had to be done as root), you will likely run into permission problems installing systools, cmdbin, and cmdscripts, and see messages like this:
unable to make directory /fnal/ups/prd/cmdbin/v1_1/OSF1+V4:
No such file or directory
upd install failed.
In this case, you will need to change the ownership of the product directories, and the database directories and chain files for the systools, cmdbin, and cmdscripts products to something owned and/or writable by the non-root account you will use to install systools.
The following text explains the differences between the systools v6_1 and systools v6_0 releases.
The need to be root to install systools has been eliminated. The "Promote" actions which were formerly part of the Configure stanzas have been moved to "InstallAsRoot" actions. Some minor difficulties with permissions and file ownership will be encountered if systools v6_0 has previously been installed as root, and you wish to install v6_1 or future versions from a normal account. In this case, you will need to change the ownership of the product directories, and the database directories and chain files for the systools, cmdbin, and cmdscripts products to something owned and/or writable by the non-root account you wish to use to install systools.
The systools, cmdbin, and cmdscripts products no longer have overlaid component products. The table files have been extensively reworked to accomodate this change, which makes applying updates straightforward.
As a result of the above, all of the systools component products, including cmdscripts, have new version numbers. If you have previously installed cmdscripts v1_0 (as part of systools v6_0), you will have to manually reconcile file changes between v1_0's $CMDSCRIPTS_DIR/library v1_1's $CMDSCRIPTS_DIR/library directories, primarily for the functions and sys.env files, and the files in the $CMDSCRIPTS_DIR/library/*.work directories. We expect to avoid this nuisance in the future.
Systools can now be installed without immediately declaring it current (via the -G -c combination). You will need to follow the printed instructions to resolve the chains, but be warned that there are a good number of commands to be issued in this case.
The adduser logic no longer appends the ",O." string to the password, which only SGI would recognize and behaved badly in mixed NIS domains. Adduser is now consistent in the handling of variable testing (using "x$XXX" rather than x"$XXX" as it was in some places).
There is now support for a sys.env.$NODE file. Such a file will be sourced by sys.env if it's owned by root, and is not world-writable.
The obtain function has been rewritten to work with new security requirements. Its use is restricted to the fnal domain.
The cmd executable exec'ing of the requested function has been modified to eliminate a race-condition security risk.
The shells product has been added as a dependency.
Last modified: March 28, 2000