head	1.25;
access;
symbols
	SHIELA_1_1_7:1.25
	SHIELA_1_1_6:1.24
	SHIELA_1_1_5:1.24
	SHIELA_1_1_4:1.23
	SHIELA_1_1_3:1.23
	SHIELA_1_1_2:1.23
	SHIELA_1_1_1:1.23
	SHIELA_1_1_0:1.23
	SHIELA_1_0_4:1.21
	SHIELA_1_0_3:1.18
	SHIELA_1_0_2:1.16
	SHIELA_1_0_1:1.14
	SHIELA_1_0_0:1.13
	SHIELA_0_9_2:1.5
	SHIELA_0_9_1:1.2
	SHIELA_0_9_0:1.1.1.1
	vendor:1.1.1;
locks; strict;
comment	@# @;


1.25
date	2006.07.20.08.17.11;	author rse;	state Exp;
branches;
next	1.24;
commitid	aQSB5U4vj5FkFzFr;

1.24
date	2005.01.12.20.46.14;	author rse;	state Exp;
branches;
next	1.23;

1.23
date	2004.05.05.13.18.47;	author rse;	state Exp;
branches;
next	1.22;

1.22
date	2004.05.05.13.11.43;	author rse;	state Exp;
branches;
next	1.21;

1.21
date	2002.12.23.14.46.15;	author rse;	state Exp;
branches;
next	1.20;

1.20
date	2002.12.23.14.45.17;	author rse;	state Exp;
branches;
next	1.19;

1.19
date	2002.12.23.14.08.38;	author rse;	state Exp;
branches;
next	1.18;

1.18
date	2002.12.23.13.10.56;	author rse;	state Exp;
branches;
next	1.17;

1.17
date	2002.12.23.12.08.35;	author rse;	state Exp;
branches;
next	1.16;

1.16
date	2002.12.23.09.13.41;	author rse;	state Exp;
branches;
next	1.15;

1.15
date	2002.12.23.09.05.47;	author rse;	state Exp;
branches;
next	1.14;

1.14
date	2002.12.23.08.50.34;	author rse;	state Exp;
branches;
next	1.13;

1.13
date	2002.12.22.17.37.28;	author rse;	state Exp;
branches;
next	1.12;

1.12
date	2002.12.22.17.20.45;	author rse;	state Exp;
branches;
next	1.11;

1.11
date	2002.12.22.15.01.17;	author rse;	state Exp;
branches;
next	1.10;

1.10
date	2002.12.22.11.10.43;	author rse;	state Exp;
branches;
next	1.9;

1.9
date	2002.12.22.11.06.50;	author rse;	state Exp;
branches;
next	1.8;

1.8
date	2002.12.21.11.00.17;	author rse;	state Exp;
branches;
next	1.7;

1.7
date	2002.12.21.09.42.57;	author rse;	state Exp;
branches;
next	1.6;

1.6
date	2002.12.21.09.20.28;	author rse;	state Exp;
branches;
next	1.5;

1.5
date	2002.08.19.19.10.38;	author rse;	state Exp;
branches;
next	1.4;

1.4
date	2001.12.31.15.00.32;	author rse;	state Exp;
branches;
next	1.3;

1.3
date	2001.05.04.13.25.18;	author rse;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.10.16.40.26;	author rse;	state Exp;
branches;
next	1.1;

1.1
date	2000.06.18.14.30.45;	author rse;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2000.06.18.14.30.45;	author rse;	state Exp;
branches;
next	;


desc
@@


1.25
log
@Adjust copyright messages for new year 2006 and upgrade build environment.
@
text
@##
##  OSSP shiela - CVS Access Control and Logging Facility
##  Copyright (c) 2000-2006 Ralf S. Engelschall <rse@@engelschall.com>
##  Copyright (c) 2000-2006 The OSSP Project <http://www.ossp.org/>
##
##  This file is part of OSSP shiela, an access control and logging
##  facility for Concurrent Versions System (CVS) repositories
##  which can be found at http://www.ossp.org/pkg/tool/shiela/.
##
##  This program is free software; you can redistribute it and/or
##  modify it under the terms of the GNU General Public  License
##  as published by the Free Software Foundation; either version
##  2.0 of the License, or (at your option) any later version.
##
##  This program is distributed in the hope that it will be useful,
##  but WITHOUT ANY WARRANTY; without even the implied warranty of
##  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
##  General Public License for more details.
##
##  You should have received a copy of the GNU General Public License
##  along with this file; if not, write to the Free Software
##  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
##  USA, or contact Ralf S. Engelschall <rse@@engelschall.com>.
##
##  shiela.pod: manual page (syntax: POD)
##

=pod

=head1 NAME

B<OSSP shiela> - Access Control and Logging Facility for CVS

=head1 VERSION

B<OSSP shiela>

=head1 DESCRIPTION

B<OSSP shiela> is an access control and logging facility for use with
the I<Concurrent Versions System> (CVS). It is intended to be hooked
into CVS's processing through the C<$CVSROOT/CVSROOT/>I<xxx>C<info>
callbacks. This way B<OSSP shiela> provides access control on a path and
branch basis to particular repository users and user groups.

Additionally, repository operations are monitored, accumulated and
logged. The lookout of logging messages can be configured individually
on a module path and branch basis and messages can be both saved to
files and/or delivered by email.

=head1 CONFIGURATION

The whole configuration of B<OSSP shiela> takes place in a single
configuration file. Per default this is C<$CVSROOT/CVSROOT/shiela.cfg>
where C<$CVSROOT> is either the environment variable C<CVSROOT> from the
users environment or the one implicitly provided by CVS because of the
scope of C<CVS/Root> files or because of an active B<-d> CVS command
line option. But one can also override the location of the configuration
file with the B<OSSP shiela> command line option B<--config>.

This file uses a C-style syntax which is described by the following
grammar rooted at I<config>:

  config    ::= directive
              | config directive
  directive ::= name ';'
              | name args ';'
  args      ::= arg
              | args arg
  arg       ::= '{' config '}'
              | m/[^ \t\n]+/

Or in words: a configuration consists of one or more directives, every
directive has a leading name, zero or more arguments and is terminated with a
semicolon. And an argument can be either a plain word (one or more
non-whitespace characters) or a complete sub-configuration enclosed in braces.
So, the syntax has only one recursion and this way is rather simple but still
powerful enough.

But this is only the general structure as understood by B<OSSP shiela>'s parser.
For semantical reasons only a particular structure is allowed to be created
with the syntax. This is described in the following.

=head2 Environment Configuration

The last configuration block is optional and for setting the run-time
environment. This configuration block has to be of the following
structure:

 Environment {
     [Setenv <variable> <value>; [...]]
     [Program sendmail <path>;]
     [Program cvs <path>;]
     [Program diff <path>;]
     [Program xdelta <path>;]
     [Program uuencode <path>;]
 };

The individual parts of this are:

=over 4

=item B<Setenv E<lt>variableE<gt> E<lt>valueE<gt>;>

This sets (and overrides) a environment variable with a particular
value. A common use is to set the environment variable C<PATH>, so the
path arguments on B<Program> configuration lines can be non-absolute
paths.

=item B<Program sendmail E<lt>pathE<gt>;>

This overrides the path to the F<sendmail> executable. Per default
B<OSSP shiela> determines this automatically through the inherited C<$PATH>
variable. Use this either if you have B<Sendmail> not in C<$PATH> or if you
have multiple B<Sendmail> instances installed. The F<sendmail> executable
is mandatory for the operation of B<OSSP shiela>.

=item B<Program cvs E<lt>pathE<gt>;>

This overrides the path to the F<cvs> executable. Per default B<OSSP shiela>
determines this automatically through the inherited C<$PATH> variable.
Use this either if you have B<CVS> not in C<$PATH> or if you have multiple
B<CVS> instances installed. The F<cvs> executable is mandatory for the
operation of B<OSSP shiela>.

=item B<Program diff E<lt>pathE<gt>;>

This overrides the path to the F<diff> executable. Per default B<OSSP
shiela> determines this automatically through the inherited C<$PATH>
variable. Use this either if you have B<GNU Diffutils> not in C<$PATH>
or if you have multiple B<GNU Diffutils> instances installed. The
F<diff> executable is required for the operation of B<OSSP shiela>
if change summary information on text files is used in reports (see
C<details> in C<Content>).

=item B<Program xdelta E<lt>pathE<gt>;>

This overrides the path to the F<xdelta> executable. Per default B<OSSP
shiela> determines this automatically through the inherited C<$PATH>
variable. Use this either if you have B<XDelta> not in C<$PATH> or if
you have multiple B<XDelta> instances installed. The F<xdelta>
executable is required for the operation of B<OSSP shiela> if change
summary information on binary files is used in reports (see C<summary>
in C<Content>).

=item B<Program uuencode E<lt>pathE<gt>;>

This overrides the path to the F<uuencode> executable. Per default
B<OSSP shiela> determines this automatically through the inherited
C<$PATH> variable. Use this either if you have B<GNU Sharutils> not in
C<$PATH> or if you have multiple B<GNU Sharutils> instances installed.
The F<uuencode> executable is required for the operation of B<OSSP
shiela> if change summary information on binary files is used in reports
(see C<summary> in C<Content>).

=back

=head2 Project Configuration

The first configuration block is for the project to which the repository
belongs to. The configuration block has to be of the following structure:

 Project {
     Tag <string>;
     Name <string>;
     Contact <email>;
     Home <url>;
     Users {
         User <userid> <username> <email>;
         [...]
     };
     [Groups {
         Group <groupid> <groupname> { <userid> [...] };
         [...]
     };]
 };

The individual parts of this are:

=over 4

=item B<Tag E<lt>stringE<gt>;>

A short tag for the project. This usually is the abbreviation
of the project name and should be only a few characters long.
Example: C<Tag FOO;>

=item B<Name E<lt>stringE<gt>;>

The name of the project. This usually is the full name and
not an abbreviation. But it should be only a few words.
Example: C<Name "The FOO Project";>

=item B<Contact E<lt>emailE<gt>;>

The Email address under which the project can be contacted.
Example: C<Contact foo@@foo.dom;>

=item B<Home E<lt>urlE<gt>;>

The URL under which the project home can be found.
Example: C<Home http://www.foo.dom/;>

=item B<User E<lt>useridE<gt> E<lt>usernameE<gt> E<lt>emailE<gt>;>

A user/member of the project. The E<lt>useridE<gt> has correspond to a Unix
user id and should match the entry in the C<passwd> database. The E<lt>usernameE<gt>
is the real name of the user and E<lt>emailE<gt> is the Email address
under which the user can be contacted. Every user which should
have access to the repository has to be configured this way.
Example: C<User foo "Mr. Foo" foo@@foo.dom;>

=item B<Group E<lt>groupidE<gt> E<lt>groupnameE<gt> { E<lt>useridE<gt> [...] };>

A group of project members. This is optional and does not correspond to any
Unix groups, i.e., there is no requirement that one defines groups of users
and even if one defines one, they are used to make access control lists more
readable only.  The E<lt>groupidE<gt> is a single word, E<lt>groupnameE<gt> is
a description text of the group and the E<lt>useridE<gt> arguments have to
correspond to users which are configured with B<User> directives.
Example: C<Group team "FOO Development Team" { foo bar quux };>

=back

=head2 Repository Configuration

The second configuration block is for the repository and its modules.  The
configuration block has to be of the following structure:

 Repository {
     Tag <string>;
     Name <string>;
     Contact <email>;
     Home <url>;
     Host <hostname>;
     Path <path>;
     History <path>;
     Modules {
         Module <modulepath> <modulename> {
             [Acl <filepath> [!]<userid>[:<groupid>] [...];]
             [...]
             [Log <filepath> <reportid>:<target> [...];]
             [...]
         };
         [...]
     };
 };

The individual parts of this are:

=over 4

=item B<Tag E<lt>stringE<gt>;>

A short tag for the repository. This usually is the abbreviation of the
repository name or can be also just the same as the project tag.  It should be
only a few characters long.
Example: C<Tag FOO;>

=item B<Name E<lt>stringE<gt>;>

The name of the repository. This usually is the full name and not an
abbreviation. But it should be only a few words.
Example: C<Name "FOO CVS Repository";>

=item B<Contact E<lt>emailE<gt>;>

The Email address under which the repository administrator can be contacted.
Example: C<Contact cvsmaster@@foo.dom;>

=item B<Home E<lt>urlE<gt>;>

The URL under which the repository home can be found.
Alternatively this just can be the URL of the project.
Example: C<Home http://cvs.foo.dom/;>

=item B<Host E<lt>hostnameE<gt>;>

The canonical hostname on which the repository resides.  This should be the
same FQDN which usually is used for SSH connections, etc.
Example: C<Host cvs.foo.dom;>

=item B<Path E<lt>pathE<gt>;>

The filesystem path on the repository host under which the repository resides.
This usually is equal to the C<$CVSROOT> variable.
Example: C<Path /e/foo/cvs;>

=item B<History E<lt>pathE<gt>;>

The filesystem path where the B<OSSP shiela> history file is written to.  Do not
confuse this with the CVS C<history> file. The B<OSSP shiela> history file logs
only B<OSSP shiela> commits and can be used to reconstruct commit operations later.
Example: C<History CVSROOT/shiela.log;>

=item B<Module E<lt>modulepathE<gt> E<lt>modulenameE<gt> { ... };>

This defines a module with the top-level path E<lt>modulepathE<gt>,
i.e., the modules stays under the directory C<$CVSROOT/>I<modulepath>/.
The E<lt>modulenameE<gt> is just a description text for the module.
The access control and logging parameters are controlled by B<Acl> and
B<Log> directives enclosed in the third argument of B<Module>.
Example: C<Module CVSROOT "CVS Administrative Files" { ... };>

=item B<Acl E<lt>filepathE<gt> [!]E<lt>useridE<gt>[:E<lt>groupidE<gt>] [...];>

This defines an access control list for
C<$CVSROOT/>E<lt>modulepathE<gt>/E<lt>filepathE<gt>.  It ensures that a
repository operation to this path can only be done by the specified
users/groups.

The argument E<lt>filepathE<gt> can be either a full path (e.g.
"C<subdir1/subdir2/file>"), or a shell wildcard pattern (e.g.
"C<subdir1/*.c>") or even a regular expression (e.g. "C<m/^[a-z].*\.[ch]/>").
Additionally E<lt>filepathE<gt> can be extended with "C<:>I<branchname>" to
restrict the operation to both a particular path and a branch.

The following arguments describe the user and groups which are allowed (or
disallowed if argument is prefixed with C<!>).  The E<lt>useridE<gt> and
E<lt>groupidE<gt> strings have to correspond to configured users and groups
(see B<User> and B<Group> directives) or can be given as "C<*>" (which means
"any").  So, a specification of "C<foo>" means the user C<foo>, "C<*:bar>"
means any user of group C<bar> and "C<*:*>" means any user of any group.
Similarly, nobody can be expressed as C<!*:*>.

Example: C<Acl foo-src/*:FOO_1_0 *:core !badboy;>

=item B<Log E<lt>filepathE<gt> E<lt>reportidE<gt>:E<lt>targetE<gt> [...];>

This defines a logging operation for
C<$CVSROOT/>E<lt>modulepathE<gt>/E<lt>filepathE<gt>. It produces one or more
logging messages.  The E<lt>reportidE<gt> has to correspond to the defined
reports (see B<Report> directive). To disable logging one can use "C<none>" as
the E<lt>reportidE<gt> (and leave out the ":E<lt>targetE<gt>" part).

The occurrence of the logging message depends how the specified report is
defined (by C<Report>). After it is produced it is send to E<lt>targetE<gt>
which can be either an Email address of the form I<user>C<@@>I<domain> or a
filesystem path.

Example: C<Log * mail:foo-cvs@@foo.dom file:CVSROOT/commit.log;>

=back

=head2 Logging Configuration

The third configuration block is for the log message creation. The
configuration block has to be of the following structure:

 Logging {
     Reports {
         Report <reportid> {
             Content <contentid> [...];
             [Details <type>:<arg>;]
             [Prefix <string>;]
         };
         [...]
     };
 };

The individual parts of this are:

=over 4

=item B<Report E<lt>reportidE<gt> { ... };>

This defines a report with the identification name E<lt>reportidE<gt> for use
with B<Log> directives. How the report message is constructed is defined with
other directives in its second argument.

=item B<Content E<lt>contentidE<gt> [...];>

This defines the report contents and contents order. That is the contents is
created top to bottom by concatenating one or more content blocks which are
specified by one or more E<lt>contentidE<gt> arguments.

The available content blocks are:
C<title>: a two line title header,
C<rule>: a horizontal rule,
C<header>: a four line repository and user summary header,
C<files>: a table of added/modified/removed/touched files,
C<log>: the log message as types in by the user,
C<summary>: a table summarizing the amount of changes to each file,
and C<details>: commit operation details (depend on B<Details> directive);

Example: C<Content title rule header files log summary rule details;>

=item B<Details E<lt>typeE<gt>:E<lt>argE<gt>;>

This configures how the details (see B<Content> directive) actually look.  The
following type/argument combinations are currently supported: "C<patch:plain>"
(the default) which produces a long details text consisting of concatenated
patching shell commands for reproducing the change; "C<patch:mime>" which produces the same contents as
"C<patch:plain>", but instead of just concatenating the individual scripts,
it encapsulates them into MIME attachments (which is useful when the
E<lt>targetE<gt> of a B<Log> directive is an Email address only); and
"C<url:>I<url>" which produces just an URL per modified file by expanding
"C<%s>" (the file path relative to C<$CVSROOT>), "C<%V>" (the old revision)
and "C<%v>" (the new revision).

Example: C<Details url:http://cvs.foo.dom/cvsweb.cgi?%s&r1=%V&r2=%v;>

=item B<Prefix E<lt>stringE<gt>;>

This configures that every line of the generated report message is
prefixed with E<lt>stringE<gt>.

Example: C<Prefix "  ";>

=back

=head1 EXAMPLE

The following example shows a fictive but reasonable configuration for a
sample FOO project:

 #   override the run-time environment
 Environment {
     Setenv  PATH     /bin:/usr/bin:/sbin:/usr/sbin;
     Program sendmail /e/foo/sw/bin/sendmail;
     Program cvs      /e/foo/sw/bin/cvs;
     Program diff     /e/foo/sw/bin/diff;
     Program xdelta   /e/foo/sw/bin/xdelta;
     Program uuencode /e/foo/sw/bin/uuencode;
 };

 #   define the project and its users
 Project {
     Tag     FOO;
     Name    "The FOO Project";
     Contact foo@@foo.dom;
     Home    http://www.foo.dom/;
     Users {
         User foo  "Mr. Foo"  foo@@foo.dom;
         User bar  "Mr. Bar"  bar@@bar.dom;
         User quux "Mr. Quux" quux@@quux.dom;
     };
     Groups {
         Group core  "FOO Core Team"      { foo };
         Group devel "FOO Developer Team" { bar quux };
     };
 };

 #   define the repository and its modules
 Repository {
     Tag     FOO;
     Name    "FOO CVS Master Repository";
     Contact foo@@foo.dom;
     Home    http://cvs.foo.dom/;
     Host    cvs.foo.dom;
     Path    /e/foo/cvs;
     History CVSROOT/shiela.log;
     Modules {
         Module CVSROOT "CVS Administrative Files" {
             Acl passwd  *:core;
             Acl modules *:core *:devel;
             Acl *       *:core;
             Log passwd  none;
             Log modules mail.patch:foo-cvs@@foo.dom file:CVSROOT/commit.log;
             Log *       mail.patch:foo-core@@foo.dom;
         };
         Module foo-adm "FOO Administration" {
             Acl * *:core;
             Log * mail.patch:foo-core@@foo.dom file:CVSROOT/commit.log;
         };
         Module foo-src "FOO Source" {
             Acl *:VENDOR  foo;
             Acl *:FOO_1_0 *:core;
             Acl *         *:core *:devel;
             Log *:VENDOR  mail.url:foo-cvs@@foo.dom file:CVSROOT/commit.log;
             Log *         mail.url:foo-cvs@@foo.dom file:CVSROOT/commit.log;
         };
     };
 };

 #   define the logging details
 Logging {
     Reports {
         Report mail.patch {
             Prefix "  ";
             Content title rule header files log summary rule details;
             Details patch:mime;
         };
         Report mail.url {
             Prefix "  ";
             Content title rule header files log summary rule details;
             Details url:http://cvs.foo.dom/cvsweb.cgi/%s?r1=%V&r2=%v;
         };
         Report file {
             Content rule file header files log summary;
         };
     };
 };

=head1 HISTORY

There were the scripts C<log_accum.pl> and C<commit_prep.pl> (originally
written by David Hampton E<lt>hampton@@cisco.comE<gt> and Greg A. Woods
E<lt>woods@@planix.comE<gt>) and the script C<cvs_acls.pl> (originally
written by David G. Grubbs E<lt>dgg@@ksr.comE<gt>), as distributed
with the official CVS version. These scripts over the years were
enhanced and adjusted by lots of people for various free software
projects. For instance Peter Wemm E<lt>peter@@freebsd.orgE<gt> derived
variants of these scripts for the FreeBSD project, Roy Fielding
E<lt>fielding@@apache.orgE<gt> did a similar job for the Apache webserver
project and Ralf S. Engelschall E<lt>rse@@engelschall.comE<gt> did it for
the initial CVS repository of the OpenSSL project.

But for the OSSP project Ralf S. Engelschall
E<lt>rse@@engelschall.comE<gt> wanted a solution which was cleaned up
from the ground and which both is more easily to integrate into CVS
and uses the features of the latest CVS versions (especially those of
the enhanced CVS variant from him). So in April 2000 he decided to
rewrite the functionality of C<log_accum.pl>, C<commit_prep.pl> and
C<cvs_acls.pl> from scratch. The result is B<OSSP shiela>.

The name B<OSSP shiela> was chosen just by coincidence and has no
related meaning. It was just that while the program was written,
a code-name was needed. And because Engelschall's first baby was
forthcoming and Ralf and Daniela Engelschall reviewed lots of names, one
of the names Ralf liked was B<Shiela>. So the code-name became B<OSSP
shiela> and as it is often with code-names, they remain forever... ;)

=head1 LOCATIONS

=over 4

=item B<http://www.ossp.org/pkg/tool/shiela/>

Here you can find the official B<OSSP shiela> homepage.

=item B<http://cvs.ossp.org/pkg/tool/shiela/>

Here you can find the latest B<OSSP shiela> development sources.

=item B<ftp://ftp.ossp.org/pkg/tool/shiela/>

Here you can find the latest B<OSSP shiela> release versions as
distribution tarballs.

=back

=head1 SEE ALSO

cvs(1).

=head1 AUTHOR

 Ralf S. Engelschall
 rse@@engelschall.com
 www.engelschall.com

=cut

@


1.24
log
@Adjust copyright messages for new year 2005.
@
text
@d3 2
a4 2
##  Copyright (c) 2000-2005 Ralf S. Engelschall <rse@@engelschall.com>
##  Copyright (c) 2000-2005 The OSSP Project <http://www.ossp.org/>
@


1.23
log
@remove trailing whitespaces
@
text
@d3 2
a4 2
##  Copyright (c) 2000-2004 Ralf S. Engelschall <rse@@engelschall.com>
##  Copyright (c) 2000-2004 The OSSP Project <http://www.ossp.org/>
@


1.22
log
@Bump year in copyright messages for 2003 and 2004
@
text
@d36 1
a36 1
B<OSSP shiela> 
@


1.21
log
@bump to version 1.0.4 for release
@
text
@d3 2
a4 2
##  Copyright (c) 2000-2002 Ralf S. Engelschall <rse@@engelschall.com>
##  Copyright (c) 2000-2002 The OSSP Project <http://www.ossp.org/>
@


1.20
log
@bump to version 1.0.4 for release
@
text
@d36 1
a36 1
B<OSSP shiela> 1.0.4 (23-Dec-2002)
@


1.19
log
@1. Added "Setenv <variable <value>" configuration command to
"Environment" configuration section which allows one to set
environment variables like PATH, etc. This especially allows now
non-absolute paths on "Program" configuration commands.

2. Fixed indentation on "Content files" report part.
@
text
@d36 1
a36 1
B<OSSP shiela> 1.0.3 (23-Dec-2002)
@


1.18
log
@bump to version 1.0.3 for release
@
text
@d91 1
d103 7
d419 1
@


1.17
log
@mention the details about the CVS version with RSE patches applied
@
text
@d36 1
a36 1
B<OSSP shiela> 1.0.2 (23-Dec-2002)
@


1.16
log
@bump to version 1.0.2 for release
@
text
@d534 4
@


1.15
log
@Fixed typos in manual pages.
@
text
@d36 1
a36 1
B<OSSP shiela> 1.0.1 (22-Dec-2002)
@


1.14
log
@flush pending changes
@
text
@d316 1
a316 1
Similarily, nobody can be expressed as C<!*:*>.
d328 1
a328 1
The occurance of the logging message depends how the specified report is
d508 1
a508 1
The name B<OSSP shiela> was choosen just by coincidence and has no
@


1.13
log
@bump for release
@
text
@d36 1
a36 1
B<OSSP shiela> 1.0.0 (22-Dec-2002)
@


1.12
log
@polishing text
@
text
@d36 1
a36 1
B<OSSP shiela> 0.9.3 (22-Dec-2002)
@


1.11
log
@cleanup version stuff
@
text
@d498 1
a498 1
the OpenSSL project.
d504 1
a504 1
the enhanced CVS variant from OSSP). So in April 2000 he decided to
@


1.10
log
@remove trailing whitespaces
@
text
@d36 1
a36 1
B<OSSP shiela> 0.9.3 (21-Dec-2002)
@


1.9
log
@Fully reimplemented the "Content" "details" (the change summary in
reports). It now supports both textual (via diff(1)) and binary
(via xdelta(1)) file changes. Additionally each change report part
is now a small executable shell-script which can passed through
/bin/sh for reproducing the patch locally. This way, especially
binary change reports are more meaningsful and consistent with the
textual change reports.
@
text
@d11 2
a12 2
##  modify it under the terms of the GNU General Public  License 
##  as published by the Free Software Foundation; either version 
d20 1
a20 1
##  You should have received a copy of the GNU General Public License 
d28 1
a28 1
=pod 
d277 1
a277 1
The filesystem path on the repository host under which the repository resides.  
d302 1
a302 1
users/groups. 
d331 1
a331 1
filesystem path. 
d345 1
a345 1
             Content <contentid> [...]; 
d367 1
a367 1
specified by one or more E<lt>contentidE<gt> arguments. 
d369 2
a370 2
The available content blocks are: 
C<title>: a two line title header, 
d397 1
a397 1
This configures that every line of the generated report message is 
d521 1
a521 1
Here you can find the official B<OSSP shiela> homepage. 
@


1.8
log
@Finally really use the "Environment" configuration section to find
"cvs" and "sendmail" directly and add a "Program" sub-command to it
for easier extension of the "Environment" section in the future.

Additionally, replace more "Shiela" occurrences with "OSSP shiela".
@
text
@d94 1
d106 3
a108 2
variable. Use this either if you have Sendmail not in C<$PATH> or if you
have multiple Sendmail instances installed.
d114 3
a116 2
Use this either if you have CVS not in C<$PATH> or if you have multiple
CVS instances installed.
d122 15
a136 2
variable. Use this either if you have GNU Diffutils not in C<$PATH> or
if you have multiple GNU Diffutils instances installed.
d142 5
a146 2
C<$PATH> variable. Use this either if you have GNU Sharutils not in
C<$PATH> or if you have multiple GNU Sharutils instances installed.
d383 1
a383 1
following type/argument combinations are currently supported: "C<diff:plain>"
d385 3
a387 3
"C<cvs diff>" outputs; "C<diff:mime>" which produces the same contents as
"C<diff:plain>", but instead of just concatenating the individual difference
texts, it encapsulates them into MIME attachments (which is useful when the
d414 1
d450 2
a451 2
             Log modules mail.diff:foo-cvs@@foo.dom file:CVSROOT/commit.log;
             Log *       mail.diff:foo-core@@foo.dom;
d455 1
a455 1
             Log * mail.diff:foo-core@@foo.dom file:CVSROOT/commit.log;
d470 1
a470 1
         Report mail.diff {
d473 1
a473 1
             Details diff:mime;
@


1.7
log
@Consistently switch to the "OSSP shiela" branding.
@
text
@d84 47
d385 1
a385 1
=head2 Environment Configuration
d387 2
a388 3
The last configuration block is optional and for setting the run-time
environment. This configuration block has to be of the following
structure:
d390 1
d392 4
a395 2
     CVS <path>;
     Sendmail <path>;
a397 25
The individual parts of this are:

=over 4

=item B<CVS E<lt>pathE<gt>;>

This overrides the path to the CVS executable. Per default B<OSSP shiela>
determines this automatically through the inherited C<$PATH> variable.
Use this either if you have CVS not in C<$PATH> or if you have multiple
CVS instances installed.

=item B<Sendmail E<lt>pathE<gt>;>

This overrides the path to the Sendmail executable. Per default
B<OSSP shiela> determines this automatically through the inherited C<$PATH>
variable. Use this either if you have Sendmail not in C<$PATH> or if you
have multiple Sendmail instances installed.

=back

=head1 EXAMPLE

The following example shows a fictive but reasonable configuration for a
sample FOO project:

a463 6
 };

 #   override the run-time environment
 Environment {
     CVS      /e/foo/sw/bin/cvs;
     Sendmail /e/foo/sw/bin/sendmail;
@


1.6
log
@Fix the "invalid file specification `<absolute path>' for access
control" issue by using Cwd::realpath to resolve the absolute path
instead of calling `pwd`.

Additionally, bump version.
@
text
@d2 1
a2 1
##  Shiela - CVS Access Control and Logging Facility
d4 1
d6 3
a8 3
##  This file is part of Shiela, an access control and logging
##  facility for Concurrent Versions System (CVS) repositories 
##  which can be found at http://www.ossp.org/pkg/shiela/.
d25 1
a25 1
##  shiela.pod: Shiela manual page (syntax: POD)
d32 1
a32 1
B<Shiela> - Access Control and Logging Facility for CVS
d36 1
a36 1
B<OSSP Shiela> 0.9.3 (21-Dec-2002)
d40 2
a41 2
B<Shiela> is an access control and logging facility for use with the
I<Concurrent Versions System> (CVS). It is intended to be hooked
d43 2
a44 2
callbacks. This way B<Shiela> provides access control on a path
and branch basis to particular repository users and user groups.
d49 1
a49 1
files and/or delivered by Email.
d53 1
a53 1
The whole configuration of B<Shiela> takes place in a single
d59 1
a59 1
file with the B<Shiela> command line option B<--config>.
d80 1
a80 1
But this is only the general structure as understood by B<Shiela>'s parser.
d217 3
a219 3
The filesystem path where the B<Shiela> history file is written to.  Do not
confuse this with the CVS C<history> file. The B<Shiela> history file logs
only B<Shiela> commits and can be used to reconstruct commit operations later.
d355 1
a355 1
This overrides the path to the CVS executable. Per default B<Shiela>
d363 1
a363 1
B<Shiela> determines this automatically through the inherited C<$PATH>
d468 1
a468 1
C<cvs_acls.pl> from scratch. The result is B<Shiela>.
d470 6
a475 6
The name B<Shiela> was choosen just by coincidence and has no related
meaning. It was just that while the program was written, a code-name
was needed. And because Engelschall's first baby was forthcoming and
Ralf and Daniela Engelschall reviewed lots of names, one of the names
Ralf liked was B<Shiela>. So the code-name became B<Shiela> and as it is
often with code-names, they remain forever... ;)
d481 1
a481 1
=item B<http://www.ossp.org/pkg/shiela/>
d483 1
a483 1
Here you can find the official B<Shiela> homepage. 
d485 1
a485 1
=item B<ftp://ftp.ossp.org/pkg/shiela/>
d487 1
a487 2
Here you can find the latest B<Shiela> release versions as
distribution tarballs.
d489 1
a489 1
=item B<:pserver:anonymous@@cvs.ossp.org:/e/ossp/cvs>, module B<shiela>
d491 2
a492 1
Here you can find the latest B<Shiela> development version.
@


1.5
log
@Switched to the OSSP devtool build environment
and upgraded to GNU shtool 1.6.1 and GNU autoconf 2.53.
@
text
@d35 1
a35 1
B<OSSP Shiela> 0.9.2 (19-Aug-2002)
@


1.4
log
@bump copyright years
@
text
@d35 1
a35 1
B<OSSP Shiela> 0.9.2 (05-May-2001)
@


1.3
log
@Update for Shtool 1.5.3 and new version
@
text
@d3 1
a3 1
##  Copyright (c) 2000 Ralf S. Engelschall <rse@@engelschall.com>
@


1.2
log
@   *) Upgraded to GNU shtool 1.5.2-pre.
      [Ralf S. Engelschall]

   *) Added --with-perl=PATH and --with-cvs=PATH Autoconf options
      to allow one to force the use of particular programs.
      [Ralf S. Engelschall]

   *) Added $(DESTDIR) support for "make install".
      [Ralf S. Engelschall]
@
text
@d35 1
a35 1
B<OSSP Shiela> 0.9.1 (27-Jun-2000)
@


1.1
log
@Initial revision
@
text
@d35 1
a35 1
B<OSSP Shiela> 0.9.0 (18-Jun-2000)
@


1.1.1.1
log
@Import of OSSP Shiela

@
text
@@