process_content - Manage the tasks of moving files from the staging area to the server area
process_content [ -t num ] [ -T file ] [ -c file ] mirror_group
process_content is the third of three stages that run on the server end of the release manager. It is used to relocate files from the staging area into the web server content areas, doing some minimal adjustment to CGI paths in the process (the majority of path normalization should be done at packaging time, on the client side).
Though the process_content tool reads from the same mirror specification as the other two stages, it uses a minimal amount of data from external sources. It expects to be invoked within the directory that is to be processed; the listing file (usually called weblist or Weblist) is expected to be in the current working directory, and all files referred to within are taken to be relative paths.
weblist
Weblist
process_content does not remove any of the files it delivers. They are copied, not renamed. The deploy_content (see deploy_content) tool cleans up the staging area after a successful invocation of this tool. If run by itself from a command-line, the user will be responsible for cleaning up.
process_content requires that a mirror group be specified on the command-line. This group name uniquely identifies a group of one or more servers that handle a given externally-visible hostname. In addition to this required value, the following options are recognized:
Specify a tracing level to be used for diagnostics (see the -T option below). The value is used internally as a bit-mask, so a value of 5 is in fact specifying the combination of 1 and 4, while exluding 2. Currently, only the first four bits are used. (A detailed description of what each bit does will soon follow.)
Specifiy the file that diagnostics are written to. Not to be confused with the general tool logfile, which generally only notes the very high-level events. If not specified, and a non-zero value for -t is specified, this will default to ``rlsmgrd-trace'' in the same logging directory as other logs are written to.
Instruct the tool to read configuration from the specified file rather than the Oracle database. This is meant mainly for debugging and for mirror groups that contain only one host. This is not a good idea for mirror groups with two or more hosts, as the database is specifically utilized so as to avoid configurations diverging from one host to the next. (Description of the configuration file format will be added later.)
In order to read configuration data from the Oracle RDBMS, the tool must have a database name/address, and a user ID and password. It would be insecure to pass these either on the command-line or via environment variables. To that end, if the tool attempts to use the Oracle data source (in the absence of a -c option, above) then it looks for a control file in the same directory as the tool itself resides in. The name of the control file must be the mirror group name as passed on the command line, with a suffix of ``.rc'' added.
.rc
The file itself should contain only one or two lines. The first line should be of the form:
username:password
The password should not be encrypted. The second line, if specified, should be the database name. If this is not specified, the value of the environment variable ORACLE_SID is used. It is assumed that the environment variable ORACLE_HOME is already set.
This specification will be used by all release manager tools located in the same directory.
Where $TOOL_DIR is the directory in which the tool is installed, the files that provide Oracle information, for the sake of connecting to the Oracle server. This file is not referenced if the -c option is passed.
$TOOL_DIR
rlsmgrd, deploy_content
Randy J. Ray
To install IMS::ReleaseMgr, copy and paste the appropriate command in to your terminal.
cpanm
cpanm IMS::ReleaseMgr
CPAN shell
perl -MCPAN -e shell install IMS::ReleaseMgr
For more information on module installation, please visit the detailed CPAN module installation guide.