view release on metacpan or  search on metacpan

rlsmgr/process_content  view on Meta::CPAN

#                   $group
#                   $trace
#                   $tfile
#                   $cmd
#
#   Environment:    None.
#
#   Returns:        Success:    1
#                   Failure:    0
#
##############################################################################
sub setPermissions
{
    my ($mode, @targets) = @_;

    my ($target, $Mode);

    for my $target (@targets)
    {
        $Mode = $mode;
        $Mode |= 0111 if (-d $target);
        if (! chmod($Mode, $target))
        {
            carp "setPermissions chmod failed for $target: $mode: $!\n"
                if (! $trace);
            write_log_line($tfile,
                           sprintf("$cmd [$$] chmod failed for $target: ".
                                   "0%03o: $!", $Mode))
                if ($trace & 2);
            return 0;
        }
        if (! chown($owner, $group, $target))
        {
            carp "setPermissions chown failed for $target: $!\n"
                if (! $trace);
            write_log_line($tfile, "$cmd [$$] chown failed for $target: $!")
                if ($trace & 2);
            return 0;
        }
    }

    1;
}

sub SetPermissions  { setPermissions(0664, @_) }
sub SetxPermissions { setPermissions(0775, @_) }

__END__

=head1 NAME

process_content - Manage the tasks of moving files from the staging area to the server area

=head1 SYNOPSIS

process_content [ B<-t> I<num> ] [ B<-T> I<file> ] [ B<-c> I<file> ] mirror_group

=head1 DESCRIPTION

B<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 B<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 C<weblist> or C<Weblist>) is
expected to be in the current working directory, and all files referred to
within are taken to be relative paths.

B<process_content> does not remove any of the files it delivers. They are
copied, not renamed. The B<deploy_content> (see L<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.

=head1 OPTIONS

B<process_content> requires that a I<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:

=over

=item B<-t I<num>>

Specify a tracing level to be used for diagnostics (see the B<-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.)

=item B<-T I<file>>

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 B<-t> is specified, this
will default to ``rlsmgrd-trace'' in the same logging directory as other logs
are written to.

=item B<-c I<file>>

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.)

=back

=head1 CONFIGURATION SPECIFICATION

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 B<-c> option, above) then it looks for a control file in the same directory