This chapter presents step-by-step procedures for a variety of VOB-maintenance tasks.
This section presents a procedure for moving a VOB storage directory to another location, either on the same host or on another host with the same architecture. (To move a VOB to a host of a different architecture, see “Moving a VOB (Different Architecture)”.) For clarity, we use an example:
The current location of the VOB storage directory to be moved is /vobstore/libpub.vbs, on a host named sol.
The VOB is mounted by client hosts at /proj/libpub.
The new location for the VOB storage directory is /src_2/vobstore/libpub.vbs. We consider two cases: (1) the new location is also on sol; (2) the new location is on another host, named ccsvr04.
To move the VOB, follow these steps:
Determine whether the VOB has any nonlocal storage pools.
% cleartool lspool -long -vob /proj/libpub | \ egrep '(^pool|link)' pool "cdft" pool "ddft" pool "sdft" pool "s_2" (remote storage pool) pool storage link target pathname "/net/ccsvr04/ccase_pools/s_2" (this pathname must be valid on new VOB host and on all client hosts)Verify the validity of pathnames to nonlocal pools—Moving a VOB storage directory does not move any of its remote storage pools. You must make sure that the VOB's new host will access each remote storage pool using the same “global pathname” as the VOB's current host:
If you are moving the VOB to another location on the same host, the validity of remote storage pool global pathnames is assured.
If you are moving the VOB to a different host, log in to that host and verify that all the remote storage pool global pathnames are valid on that host.
Deactivate the VOB—On each host where it is currently active, this command deactivates it:
% cleartool umount /proj/libpub
Back up the VOB storage directory—Use the procedure in “Backing Up a VOB” (or in “Backing Up a VOB with Remote Storage Pools”).
Lock the VOB—Do this as the root user on the host where the VOB storage directory resides:
% rlogin sol -l root Password: <enter root password> # cleartool lock -vob /vobstore/libpub.vbs Locked versioned object base "/vobstore/libpub.vbs".
Copy the VOB storage directory—Make sure that the desired parent directory of the target location exists and is writable. Then, copy the entire VOB storage directory tree (but not remote storage pools) to the new location.
Same host:
<verify that `/src_2/vobstore' already exists> # cd /vobstore # tar -cf - libpub.vbs | ( cd /src_2/vobstore ; tar -xBpf -) (-B option is not necessary (and not supported) on HP-UX systems)(To relocate a VOB storage directory within the same disk partition, you can use a simple mv command.)
Different host:
<verify that `/src_2/vobstore' already exists on remote host `ccsvr04'> # cd /vobstore # tar -cf - libpub.vbs | rsh ccsvr04 'cd /src_2/vobstore ; tar -xBpf -' (-B option is not necessary (and not supported) on HP-UX systems)
Note: On some systems, the “remote shell” command has another name (for example, remsh).
Ensure that the “old” VOB cannot be reactivated—Remove it from the ClearCase storage registries:
# cleartool rmtag -vob -all /proj/libpub # cleartool unregister -vob /vobstore/libpub.vbs
This prevents reactivation by ClearCase Release 2 client hosts. If your network also includes client hosts running ClearCase Release 1, prevent them from reactivating the VOB by moving aside the VOB storage directory:
# mv /vobstore/libpub.vbs /vobstore/libpub.vbs.OLD
Terminate the “old” VOB's server processes—Search the process table for the vob_server and vobrpc_server processes that manage the “old” VOB. Use ps -ax or ps -ef, and search for “libpub.vbs”. Use kill(1) to terminate any such processes.
Register the VOB at its new location—This example assumes that you are moving a public VOB, requiring entry of a password.
# cleartool register -vob /net/ccsvr04/src_2/vobstore/libpub.vbs # cleartool mktag -vob -public -tag /proj/libpub \ /net/ccsvr04/src_2/vobstore/libpub.vbs Vob tag registry password: <enter password>If your network has several network regions, see “Ensuring the VOB's Global Accessibility” for a discussion of adjustments and additional registry entries you may need to make.
Reactivate the VOB—On all client hosts:
% cleartool mount /proj/libpub
Unlock the VOB.
# rlogin ccsvr04 Password: <enter root password> # cleartool unlock -vob /src_2/vobstore/libpub.vbs Unlocked versioned object base "/src_2/vobstore/libpub.vbs".
Delete the old VOB storage directory—Be sure to first verify that the VOB can be accessed.
# rlogin sol Password: <enter password> # rm -fr /vobstore/libpub.vbs (or `libpub.vbs.OLD')
This section presents a procedure for moving a VOB storage directory to a host with a different architecture. This includes converting the binary-format files that implement the VOB database. (To move a VOB to a host of the same architecture, or to another location on the same host, see “Moving a VOB (Same Architecture)”.) For clarity, we use an example:
The current location of the VOB storage directory to be moved is /vobstore/libpub.vbs, on a host named sol.
The VOB is mounted by client hosts at /proj/libpub.
The new location for the VOB storage directory is /src_2/vobstore/libpub.vbs on host ccsvr04, whose architecture differs from sol's.
To move the VOB, follow these steps:
Determine whether the VOB has any nonlocal storage pools.
% cleartool lspool -long -vob /proj/libpub | egrep '(^pool|link)' pool "cdft" pool "ddft" pool "sdft" pool "s_2" (remote storage pool) pool storage link target pathname "/net/ccsvr04/ccase_pools/s_2" (this pathname must be valid on new VOB host and on all client hosts)Verify the validity of pathnames to nonlocal pools—Moving a VOB storage directory does not move any of its remote storage pools. You must make sure that the VOB's new host will access each remote storage pool using the same “global pathname” as the VOB's current host:
If you are moving the VOB to another location on the same host, this is assured.
If you are moving the VOB to a different host, log in to that host and verify that all the remote storage pool global pathnames are valid on that host.
Deactivate the VOB—On each host where it is currently active, this command deactivates it:
% cleartool umount /proj/libpub
Back up the VOB storage directory—Use the procedure in “Backing Up a VOB” (or in “Backing Up a VOB with Remote Storage Pools”).
Dump the VOB's database to ASCII dump files—Do this as the root user on the host where the VOB storage directory resides. Don't lock the VOB beforehand—the reformatvob command does this automatically).
This command marks the VOB database as invalid. The VOB cannot be used for development work until it is processed by a reformatvob –load command.
Copy the VOB storage directory—First, make sure that the desired parent directory of the target location exists and is writable. Then, copy the entire VOB storage directory tree (but not remote storage pools) to the new location.
<verify that `/src_2/vobstore' already exists on remote host `ccsvr04'> # cd /vobstore # tar -cf - libpub.vbs | rsh ccsvr04 'cd /src_2/vobstore \ ; tar -xBpf -' (-B option is not necessary (and not supported) on HP-UX systems)Note: On some systems, the “remote shell” command has another name (for example, remsh). Ensure that the “old” VOB cannot be reactivated—Remove it from the ClearCase storage registries:
# cleartool rmtag -vob -all /proj/libpub # cleartool unregister -vob /vobstore/libpub.vbs
This prevents reactivation by ClearCase Release 2 client hosts. If your network also includes client hosts running ClearCase Release 1, prevent them from reactivating the VOB by moving aside the VOB storage directory:
# mv /vobstore/libpub.vbs /vobstore/libpub.vbs.OLD
Terminate the “old” VOB's server processes—Search the process table for the vob_server and vobrpc_server processes that manage the “old” VOB. Use ps -ax or ps -ef, and search for “libpub.vbs”. Use kill(1) to terminate any such processes.
On the new VOB host, recreate the VOB database from the ASCII dump files—Do this as the root user:
# rlogin ccsvr04 Password: <enter root password> # cleartool reformatvob -load /src_2/vobstore/libpub.vbs \ <warning message> Reformat versioned object base "/src_2/vobstore/libpub.vbs"? [no] yes cleartool: Warning: Renamed old database directory to "/src_2/vobstore/libpub.vbs/db.01.27". cleartool: Warning: Please remove this database backup when you are satisfied with the reformat. Loading database... Dumped schema version is nn ... 73 pass 2 actions performed. Done. Checking for VOB tag registry entry... cleartool: Warning: VOB tag entry not found for versioned object base "/src_2/vobstore/libpub.vbs". cleartool: Warning: Use the mktag command to create a registry entry.
Create a tag for the VOB at its new location—The reformatvob command has already created an entry in the VOB object registry; you must create an entry in the VOB-tag registry.
# cleartool mktag -vob -public -tag \ /proj/libpub/net/ccsvr04/src_2/vobstore/libpub.vbs Vob tag registry password: <enter password>
If your network has several network regions, see “Ensuring the VOB's Global Accessibility” for a discussion of adjustments and additional registry entries you may need to make.
Reactivate the VOB—On all client hosts:
# cleartool mount /proj/libpub
Delete the backup VOB database—This backup was created by reformatvob –load in Step #5. It is a datestamped subdirectory of the VOB storage directory. For example, it might be named /src_2/vobstore/libpub.vbs/db.01.27 (“01.27” means “January 27”).
# rm -fr /src_2/vobstore/libpub.vbs/db.01.27
Delete the old VOB storage directory—Be sure to first verify that the VOB can be accessed.
# rlogin sol Password: <enter root password> # rm -fr /vobstore/libpub.vbs (or `libpub.vbs.OLD')
In general, you should approach the removal of source data from VOB storage with extreme caution. Removing entire elements, using rmelem, is particularly dangerous:
Even if an element is no longer needed for the next release, you may still need it to reproduce and maintain previous releases.
rmelem expunges the element's name from all directory versions in which it was ever cataloged. This “erasing of history” means that the element will not appear in listings or comparisons of old directory versions.
Making a mistake can be costly—there is a procedure for recovering from backup an element that was deleted mistakenly (or in haste), but it's cumbersome. (See “Restoring a Single Element From Backup”.)
If you need to remove old data in order to conserve disk space, it is far better to remove individual versions of elements, rather than entire elements. The rmver command makes it easy to remove versions that you probably won't ever need again. (Another approach is to manipulate storage pools—see “Creating Additional VOB Storage Pools”.)
By default, rmver removes only “uninteresting” versions:
versions that are unrelated to branching: not located at a branch point, and not the first or last version on a branch
versions that have no meta-data annotations: version labels, attributes, or hyperlinks
The ClearCase examples directory includes a script that safely removes all “uninteresting” versions of a specified element. This script is located in /usr/atria/examples/rmver_all. It is particularly useful for deleting automatically-created derived object versions that are no longer needed. (Many organizations check in derived objects regularly, as part of an automated “nightly build” process.)
The following commands illustrate the “before” and “after” of version removal with the rmver_all script.
% cleartool lsvtree -all ct+register.1 ct+register.1@@/main ct+register.1@@/main/0 ct+register.1@@/main/1 ct+register.1@@/main/2 (V2.BL2.1, V1.1.4.BL3, V2.BL2) ct+register.1@@/main/3 (RGYWORK_BASE) ct+register.1@@/main/rgywork ct+register.1@@/main/rgywork/0 ct+register.1@@/main/rgywork/1 ct+register.1@@/main/rgywork/2 ct+register.1@@/main/rgywork/3 ct+register.1@@/main/4 ct+register.1@@/main/5 (V2.BL3) ct+register.1@@/main/6 ct+register.1@@/main/7 ct+register.1@@/main/8 ct+register.1@@/main/9 (V2.BL4_PRINT, V2.BL4) % /usr/atria/examples/rmver_all/rmver_all ct+register.1 Removed these versions of "ct+register.1": /main/rgywork/1 /main/rgywork/2 /main/1 /main/4 /main/6 /main/7 /main/8 % cleartool lsvtree -all ct+register.1 ct+register.1@@/main ct+register.1@@/main/0 ct+register.1@@/main/2 (V2.BL2.1, V1.1.4.BL3, V2.BL2) ct+register.1@@/main/3 (RGYWORK_BASE) ct+register.1@@/main/rgywork ct+register.1@@/main/rgywork/0 ct+register.1@@/main/rgywork/3 ct+register.1@@/main/5 (V2.BL3) ct+register.1@@/main/9 (V2.BL4_PRINT, V2.BL4) |
If you mistakenly delete an element with rmelem, you can restore it from a backup tape, using the procedure presented in this section.
The overall procedure for restoring an element is:
Unmount the VOB whose element has been deleted.
Restore the “old” VOB storage directory from the backup medium to a temporary location on disk.
Use clearcvt_ccase to “copy” the element from the old VOB to the temporary VOB.
Unmount the old VOB.
Remount the real VOB.
Use clearcvt_ccase to “copy” the element from the temporary VOB to the real VOB.
Delete the “old” VOB and the temporary VOB.
As an example, suppose that file element util.c has inadvertently been deleted from directory /vobs/proj/src. The VOB-tag is /vobs/proj, and the VOB storage directory is /vobstore/proj.vbs on the local host. Here's how a VOB's owner can restore the element from a backup tape.
Unmount the VOB whose element has been deleted—This is essential, because two copies of the same VOB must never be active at the same time.
% cleartool umount /vobs/proj
Remove the VOB's storage registry entries—These entries would prevent use of an old version of the same VOB.
% cleartool rmtag -vob /vobs/proj % cleartool unregister -vob /vobstore/proj.vbs
Terminate the VOB's server processes—Search the process table for the ClearCase vob_server and vobrpc_server processes that manage that VOB. Use ps -ax or ps -ef, and search for “/vobstore/proj.vbs”; use kill(1) to terminate any such processes. (Only the root user can kill a vobrpc_server process.)
Restore the “old” VOB storage directory—Suppose that the backup tape was created with tar. Restore the “old” VOB to a temporary location, not to its original location.
% cd /usr/tmp % tar -xf /dev/tape
This restores the VOB storage directory tree as /usr/tmp/proj.vbs.
Register and mount the “old” VOB—As in the preceding step, use a temporary mount point, not the original mount point.
% cleartool register -vob /usr/tmp/proj.vbs % cleartool mktag -vob -tag /tmp/oldvob /usr/tmp/proj.vbs % mkdir /tmp/oldvob % cleartool mount /tmp/oldvob
Create a new temporary VOB and mount it—Be sure not to give this VOB a public VOB-tag.
% cleartool mkvob -nc -tag /tmp/newtmpvob /usr/tmp/newtmpvob.vbs Created versioned object base. . . % mkdir /tmp/newtmpvob % cleartool mount /tmp/newtmpvob
“Copy” the element: old VOB to temporary VOB—Use the clearcvt_ccase program to make a complete copy of the element.
(Create conversion script in “old” VOB) (set a view configured with the default config spec) % cleartool setview dfl % cd /tmp/oldvob/src % clearcvt_ccase util.c Converting element "util.c" ... Extracting element history ... . . Creating script file cvt_dir/cvt_script ... (Create conversion script in temporary VOB) % cd /tmp/newtmpvob % /tmp/oldvob/src/cvt_dir/cvt_script Converting files from /tmp/oldvob/src to . . . Checked in "./util.c" version "/main/3". Checked in "./." version "/main/2".Unmount and unregister the old VOB—This corresponds to the work done in Steps #1 and #2.
% cd / % cleartool umount /tmp/oldvob % cleartool rmtag -vob /tmp/oldvob % cleartool unregister -vob /usr/tmp/proj.vbs
Terminate the old VOB's server processes—This is similar to Step #3. This time, search the process table for a vob_server and/or vobrpc_server invoked with “/usr/tmp/proj.vbs”.
Reregister and remount the real VOB—This time, make a public VOB-tag.
% cleartool register -vob /vobstore/proj.vbs % cleartool mktag -vob -public -tag /vobs/proj /vobstore/proj.vbs Vob tag registry password: <enter password> % cleartool mount /vobs/proj
“Copy” the element: temporary VOB to original VOB—Use the clearcvt_ccase program to make a complete copy of the element.
(Create conversion script in “old” VOB) % cd /tmp/newtmpvob % clearcvt_ccase util.c Converting element "util.c" ... Extracting element history ... . . Creating script file cvt_dir/cvt_script ... (Create conversion script in temporary VOB) % cd /vobs/proj/src % /tmp/newtmpvob/cvt_dir/cvt_script Converting files from /tmp/newtmpvob to . . . Checked in "./util.c" version "/main/3". Checked in "./." version "/main/5".Unmount the temporary VOB—This corresponds to the work done in Step #6.
% cd / % cleartool umount /tmp/newtmpvob
Delete the temporary VOB—Use rmvob, which automatically removes the VOB's registry entries and terminates all of its server processes.
% cleartool rmvob /usr/tmp/newtmpvob.vbs Remove versioned object base "/usr/tmp/newtmpvob.vbs" [no] yes Removed versioned object base "/usr/tmp/newtmpvob.vbs".
If a VOB is threatening to fill up its disk partition, you may want to rework the VOB's storage pools. The VOB database (db subdirectory) must be physically located within the VOB storage directory, but any or all of its storage pools can be remote. In the extreme case, you might “abandon” the VOB's d fault storage pools, and transfer all of the VOB's file system data to other disk partitions and/or remote hosts.
The host on which you create a new storage pool need not have ClearCase installed. It can have any hardware/software architecture, but the pool must be NFS-accessible at the same pathname from all ClearCase hosts (for example, /net/ccsvr02/ccase_pools/do_3). See “Default, Local, and Remote Storage Pools” for additional information.
| Note: The ClearCase network region facility does not apply here. The pathname of a remote storage pool must be truly “global”. |
When deciding which host(s) to use for new storage pools, consider that usage patterns vary with the kind of storage pool:
Source pools—These pools store the most precious data: the checked-in versions of file elements. Traffic involving these pools is relatively light, but data integrity is very important. (See “Caution on Remote Source Pools” below.) The ideal location for such pools is a robust file server, with a large capacity and frequent, reliable data backups.
Cleartext pools—These pools will probably get the heaviest traffic (assuming that many of your file elements are stored in delta and/or compressed format). But the data in cleartext pools is completely expendable, since ClearCase can reconstruct it at any time. The ideal location for such pools is a machine with a fast file system.
Derived object pools—These pools can grow to be quite large, depending on the number of active configurations (three new development projects, two old releases in maintenance, and so on). Anticipate the storage requirements in the new pool for each active configuration; make sure the disk partition can handle the total storage requirement.
The principal tools for working with storage pools are:
We recommend that you keep source storage pools local, within the VOB storage directory. This strategy optimizes data integrity—a single disk partition will contain all of the VOB's essential data. It will also simplify backup/restore procedures. This concern typically overrides performance considerations, since losing a source pool means that developers must recreate the lost versions.
The following example shows how to create a new, remote source storage pool, and then reassign all the current and future elements in a particular directory to the new pool.
Create the new storage pool—Be careful to specify a global pathname for the remote pool.
% cd /vobs/bgr % cleartool mkpool -source -ln \ /net/ccsvr02/ccase_pools/bgrsrc2 bgrsrc2 Comments for "bgrsrc2": remote source storage pool . Created pool "bgrsrc2".
Reassign existing file elements to the new pool—In this example, we reassign all the file elements in a particular development subdirectory.
% cd libbgr % cleartool find . -type f -exec 'cleartool chpool -force\ bgrsrc2 $CLEARCASE_PN' Changed pool for "./Makefile" to "bgrsrc2". Changed pool for "./errmsg.c" to "bgrsrc2". Changed pool for "./fork3.c" to "bgrsrc2". Changed pool for "./get.c" to "bgrsrc2". Changed pool for "./getcwd.c" to "bgrsrc2". . . Changed pool for "./stint.h" to "bgrsrc2". Changed pool for "./strut.c" to "bgrsrc2".
Reassign the directory element to the new pool, too—This will cause all newly-created file (and directory) elements in this directory to use the new pool, also.
% cleartool chpool bgrsrc2 . Changed pool for "." to "bgrsrc2".
There is no built-in command for moving an existing storage pool. ClearCase routines perform standard UNIX operations to access storage pools and the data containers within them. Thus, you can move a storage pool in this way:
Determine the location of the storage pool—Use the lspool command:
% cleartool lspool -long -vob /vobs/bgr d_aux pool "d_aux" . . pool storage global pathname "/net/ccsvr01/vobstore/bgr.vbs/d/d_aux"Lock the VOB—This will prevent any new shared DOs from being placed in the storage pool while you are working on it:
% cleartool lock -vob /vobs/bgr Locked versioned object base "/net/ccsvr01/vobstore/bgr.vbs".
Copy the contents of the storage pool—The storage pool is a standard UNIX directory. You can copy its contents to a new location using cp, rcp, tar, or other commands. For example:
% rlogin ccsvr01 % mkdir -p /vobstore_2/DO_pools % cp -r /vobstore/bgr.vbs/d/d_aux /vobstore_2/DO_pools
Replace the old storage pool with a symbolic link—Move the old storage pool aside, then create the link in its place.
% cd /vobstore/bgr.vbs/d % mv d_aux d_aux.MOVED % ln -s /net/ccsvr01/vobstore_2/DO_pools/d_aux d_aux
Be sure the text of the symbolic link is a globally-valid pathname to the new storage pool location.
Unlock the VOB.
% cleartool unlock -vob /vobs/bgr Unlocked versioned object base "/net/ccsvr01/vobstore/bgr.vbs".
Remove the old storage pool—When you have verified that the storage pool is working well in its new location, you can remove the old pool:
% rm -fr /vobstore/bgr.vbs/d/d_aux.MOVED
Chapter 10 discusses the standard maintenance procedures established for each host when ClearCase is installed there. There are two typical motivations for adjusting a VOB host's default procedures for storage pool scrubbing:
Not enough space—The disk partitions in which VOB storage pools reside may be chronically filling up. This would indicate adoption of a more aggressive scrubbing strategy.
Not enough time—The scrubber utility may be taking too much time to complete, interfering with other overnight activities, such as nightly software builds. This would indicate adoption of a less aggressive scrubbing strategy.
You may find it necessary to do some experimentation. For example, adjusting scrubbing to take place less frequently may cause disk-space problems that you had not previously experienced. Before making any scrubbing adjustments on a VOB host, be sure to analyze its /usr/adm/atria/log/scrubber_log file. The scrubber manual page explains how to read this file.
The following sections present some simple examples of adjusting the way VOB storage pools are scrubbed.
By default, scrubber allows data containers of zero-referenced derived objects to remain in their storage pools for 4 days (96 hours). If DOs are filling up a VOB's disk partition, you might shorten this “grace period”. Here's a command that causes a VOB's default DO storage pool (ddft) to be emptied of unneeded data containers every day (that is, every 24 hours):
% cleartool mkpool -update -vob VOB-tag -age 24 ddft Updated pool "ddft". |
Suppose that the adjustment in the preceding section is not enough to keep the disk partition from filling up. You might decide to invoke the scrubber utility more often: during the work day as well as overnight. To minimize the impact on users during the work day, you might pinpoint the scrubbing—perhaps to the DOs created in a particular directory, /vobs/proj/reorg:
Determine the directory's current DO storage pool assignment—You will need to clean up this storage pool.
% cd /vobs/proj % cleartool describe -long reorg@@ directory element "reorg@@": . . ... derived pool: ddft (this directory uses the VOB's default DO storage pool)Assign the directory to a separate storage pool—This will enable pinpoint control of scrubbing, which can be invoked on a per-pool basis:
% cd /vobs/proj % cleartool mkpool -derived new_do_pool Comments for "new_do_pool": pool for DOs created in /vobs/proj/reorg . Created pool "new_do_pool". % cleartool chpool new_do_pool reorg Changed pool for "reorg" to "new_do_pool".
Determine the location of the VOB storage directory—You'll need the pathname of the VOB's storage directory for scrubber. Use lsvob to determine the pathname:
% cleartool lsvob /vobs/proj * /vobs/proj /net/ccsvr03/vobstore/proj.vbs
Have the new storage pool scrubbed thoroughly and often—There are many ways to accomplish this. You might take advantage of the fact the default maintenance procedure invokes a script named /usr/atria/config/cron/ccase_local.day once a day (as part of the 4:30 am regimen). You can create or modify this script to set up several at(1) jobs:
% su Password: <enter root password> # vi /usr/atria/config/cron/ccase_local.day <add these lines:> CMD="/usr/atria/etc/scrubber -e -p new_do_pool \ /net/ccsvr03/vobstore/proj.vbs" echo $CMD | at 10:00 echo $CMD | at 13:00 echo $CMD | at 15:00 echo $CMD | at 18:00 <save the file and end the edit session> # exit %The scrubber utility will be invoked four times during the work day on the derived object storage pool new_do_pool. The -e option to scrubber empties the pool of all zero-referenced DOs.
Clean up the old DO storage pool—The chpool command in Step #2 does not move existing DO data containers; it only affects where a new DO's data container will be stored. Accordingly, you should clean up the old storage pool:
% /usr/atria/etc/scrubber -e -p ddft \ /net/ccsvr03/vobstore/proj.vbs
 | Caution: Depending on how ClearCase is installed, the directory /usr/atria/config/cron may or may not actually be local to a particular host. If two or more hosts share the same /usr/atria/config/cron directory, you may need to have the “local” script perform conditional processing, based on the hostname. Alternatively, you can use a completely separate mechanism to invoke supplementary maintenance procedures. |
If the 4:30 am scrubbing regimen takes too long (perhaps spilling over into the work day). you might make the starting time earlier. Alternatively, you might change the way that scrubber is invoked, so that it takes less time to run. Both these alternatives involve a change to /usr/atria/config/cron; hence, the “Caution” paragraph above applies in this situation, too. Here's how you might revise scrubbing to process DO pools only, leaving cleartext pools alone:
% su
Password: <enter root password>
# vi /usr/atria/config/cron/
revise this line ...
$ATRIA_DIR/etc/scrubber -f -a
... to read:
$ATRIA_DIR/etc/scrubber -f -a -k do
|