Short Contents
**************

Wydawca
1 Introduction to Wydawca
2 Operation Overview
3 How to invoke `wydawca'.
4 How to Configure `wydawca'.
5 `Wydawca' configuration file.
6 `Wydawca' invocation summary.
7 How to Report a Bug
Appendix A GNU Free Documentation License
Concept Index


Table of Contents
*****************

Wydawca
1 Introduction to Wydawca
2 Operation Overview
  2.1 Operation Modes
3 How to invoke `wydawca'.
4 How to Configure `wydawca'.
  4.1 Configuration file syntax
    4.1.1 Comments
    4.1.2 Pragmatic Comments
    4.1.3 Statements
    4.1.4 Preprocessor
  4.2 General Settings
  4.3 User Privileges
  4.4 Daemon Configuration
  4.5 TCP Wrappers
  4.6 Locking Configuration
  4.7 Syslog Configuration Directives
  4.8 SQL Databases
  4.9 Dictionaries
    4.9.1 SQL Dictionary
      4.9.1.1 Project-owner: an SQL Implementation
      4.9.1.2 Project-uploader: an SQL Implementation
    4.9.2 Built-in Dictionary
    4.9.3 External Dictionary
  4.10 Archivation
  4.11 Distribution Spool
  4.12 Distribution Verification
  4.13 Statistics
  4.14 Mail Notification
    4.14.1 Mailer
    4.14.2 Message Templates
    4.14.3 Statistic Reports
    4.14.4 Event Notification
5 `Wydawca' configuration file.
6 `Wydawca' invocation summary.
7 How to Report a Bug
Appendix A GNU Free Documentation License
  A.1 ADDENDUM: How to use this License for your documents
Concept Index


Wydawca
*******

This edition of the `Wydawca Manual', last updated 6 January 2010,
documents Wydawca Version 2.1.

1 Introduction to Wydawca
*************************

Let's begin with a short synopsis. Suppose you run a developer's site,
like, e.g. <gnu.org>. You have two "distribution URLs": <ftp.gnu.org>,
which distributes stable versions of the software, and <alpha.gnu.org>,
which distributes alpha and pre-test versions. Now, package maintainers
need to have a way of uploading their packages to one of these sites.
This is done using the "Automated FTP Upload" method, as described in
*note Automated FTP Uploads: (maintain)Automated FTP Uploads.  The
following is a short summary of it: there is an FTP "upload site",
which has two "source directories", each one corresponding to a certain
distribution URL. For example,

Source Directory              Distribution Site
-------------------------------------------------------------------------- 
`/incoming/ftp'               <ftp.gnu.org>
`/incoming/alpha'             <alpha.gnu.org>

Now, if maintainer of the project `foo' wishes to make a release of the
stable version `foo-1.0.tar.gz', he first creates a detached signature
`foo-1.0.tar.gz.sig'. Then he creates a special "directive" file, which
contains information about where the distributed tarball must be
placed, and clear-signs it using his PGP key, thus obtaining the file
`foo-1.0.tar.gz.directive.asc'. Finally, he uploads these three files
(a "triplet") to the upload site, storing them into the directory
`/incoming/ftp'.

   From now on, it is the responsibility of a "release submission
daemon" to scan the source directories, gather the triplets, verify
them, and to move any files that had  successfully passed verification
to their distribution sites.

   `Wydawca' is such a release submission daemon. It is able to handle
any number of `source/destination' pairs (called "spools") in real
time, and offers an extensible logging and mail notification mechanism,
allowing both package maintainers and site administrators to be
immediately notified about any occurring problems.

   `Wydawca' supports version 1.1 of directory file, as described in
*note Standalone directives: (maintain)FTP Upload Directive File - v1.1.

   The program is written entirely in C, is highly effective and
consumes little resources.

2 Operation Overview
********************

Usually, `wydawca' is installed on the machine that receives release
uploads. It may be run either periodically as a cron-job, or as a
standalone daemon. It supposes that both upload and distribution
directories are accessible in the local file system hierarchy. If that
is not the case (e.g. if upload and distribution sites are handled by
different machines), one of them should be mounted using NFS. Future
versions will contain special provisions for that case.

   A configuration file defines a set of "spools", i.e. pairs of upload
and corresponding distribution directories. In `wydawca' terminology,
upload directories are also called "source", and distribution
directories - "destination" directories. The configuration file also
supplies all the information necessary to access user and project
databases.

   When started, `wydawca' scans each source directory and prepares a
list of files found there. Then, it compacts this list by looking for
"directive files" and re-arranging list members in "triplets". A
"directive file" is a special file that must be supplied with each
upload and that contains directive regarding the placement of the
uploaded files. A "triplet" is a standard entity, consisting of three
files: a clear-signed directive file, a file to be distributed, and a
detached signature of the latter.  In some special cases, a
clear-signed directive file alone is valid.  This happens when it
contains only "standalone directives", as described in *note Standalone
directives: (maintain)FTP Upload Directive File - v1.1.

   Each "incomplete" triplet, i.e. a triplet missing one or more
necessary files, is then verified by checking if the modification date
of its oldest file is older than a predefined amount of time (*note
file-sweep-time: general.). If so, the triplet is considered "expired",
and all its files are removed. This gives users the possibility to
restart interrupted or otherwise broken uploads later.

   After completing these preliminary stages, `wydawca' analyzes the
directive file and extracts the project name from it. Using this name
as a key, it looks up in the "project dictionary" a list of users
authorized to make uploads for this project. This list contains user
names and their corresponding public PGP keys. `Wydawca' tries to
verify the directive file using each PGP key from this list, until a
matching key is found, or the list in exhausted. In the latter case, the
triplet is rejected. Otherwise, the key and its owner are remembered
for the next step.

   In this step, the uploaded file and its detached signature are
verified. If they do not match the public key obtained in the previous
step, the triplet is rejected.

   Finally, directives from the directive file are executed. On this
stage of the processing, the uploaded files are actually moved to their
destination directories, requested symbolic links are created, etc.

2.1 Operation Modes
===================

The program has two operation modes: `cron mode' and `daemon mode'.

   In "cron mode", `wydawca' runs in foreground and exits when it is
done with processing all required spools. By default it processes all
configured spools, unless a subset of them is specified in the command
line. This is called "cron mode", because this is the usual way for
`wydawca' to be used as a cron job.

   In "daemon mode", `wydawca' detaches itself from the controlling
terminal and runs in the background, listening on a preconfigured
socket. The socket implements the TCPMUX protocol(1) and operates as
follows:

   After establishing connection, the remote party (the "client") sends
the spool tag followed by a CRLF pair. The server scans its
configuration for a spool that has the requested ID. If no such spool
is found, the server replies with the string `- Unknown service name',
followed by a CRLF pair and closes the connection.

   If a matching spool is found, the server replies with `+'
acknowledgment, immediately followed by an optional message of
explanation, and terminated with a CRLF. Upon receiving this
acknowledgment, the client sends the user name of the user who did the
upload. The following sample transaction illustrates this:

     C: stable
     S: +OK. URL ftp://ftp.domain.net
     C: smith

   When the user name is received, the server schedules a "job" for
processing all triplets submitted by the given user to the given spool.

   ---------- Footnotes ----------

   (1) RFC 1078 (http://www.rfc-editor.org/rfc/rfc1078.txt).

3 How to invoke `wydawca'.
**************************

`Wydawca' gets all information it needs from its "configuration file"
(*note wydawca.rc::). The default configuration file is
`SYSCONFDIR/wydawca.rc', but if it is located elsewhere, you can
specify its new location with the `--config-file' (`-c') command line
option.

   If you wish to check your configuration file for syntax errors, use
`--lint' (`-t') command line option. When given this option, `wydawca'
prints all diagnostics on its standard error and exits with code 0 if
the file is OK, or 1 otherwise.

   Normally, `wydawca' attempts to detect automatically whether it is
run from an interactive console, and if so it prints its diagnostics on
the standard error. Otherwise, the diagnostics is directed to the
`syslog', using the facility given in the `syslog-facility'
configuration file statement (*note syslog::). Two options are provided
if you wish to disable this autodetection: the option `--syslog'
instructs the program to print all diagnostics via `syslog', and the
option `--stderr' (or `-e') instructs it to print everything on the
standard error.

   The operation mode is configured in the configuration file. If the
latter configures daemon mode, you can still instruct `wydawca' to run
as a cron job by the `--cron' command line option. This may be needed,
for example, to schedule a daily `wydawca' run when the main daemon
instance is already running.

   Usually `wydawca' attempts to process all the configured spools. You
may instruct it to process only a subset of these by using the
following options:

`--spool=TAG'
`-S TAG'
     Process only spool with the given tag.

`--source=DIR'
`-s DIR'
     Process only spool with DIR as the source directory.

   Any number of these options may be supplied, e.g.:

     $ wydawca --spool=ftp --spool=test --source=/home/ftp/test-upload

   The `--debug' (`-d') option tells the program to increase its
debugging level by 1. The "debugging level" determines amount of
information the program reports when it runs. Default level is 0, which
means that only errors and other critical conditions are reported.
Raising it may be necessary when debugging new configurations. Each
`-d' option raises the level by one, so you can say `wydawca -dd' to
obtain level 2, for example. The maximum debugging level (currently it
is 4) prints an impractically big amount of information, and is useful
mainly for `wydawca' developers.

   Yet another debugging facility is the `--dry-run' (`-n') option. It
instructs `wydawca' to avoid doing any modifications to the disk
contents, and to print a verbose description of any actions it would
have taken. It sets the debugging level to 1 and directs the
diagnostics output to the standard error, as if `--debug --stderr'
options were given. You can raise debugging level further by supplying
additional `--debug' options. The `--dry-run' option is useful when
testing new configurations, for example:

     $ wydawca -c new.cfg --dry-run

   In addition, the two usual informational options are available as
well: `--help' (`-h') prints a short usage summary, and `--version'
(`-v') prints program version number.

4 How to Configure `wydawca'.
*****************************

Upon startup, `wydawca' reads its settings from the "configuration
file" `wydawca.rc'. By default it is located in $SYSCONFIDR (i.e., in
most cases `/usr/local/etc', or `/etc'), but an alternative location
may be specified using `--config' command line option (*note
config-file: starting.).

   If any errors are encountered in the configuration file, the program
reports them on its error output and exits with a non-zero status.

   To test the configuration file without starting the server use
`--lint' (`-t') command line option. It causes `wydawca' to check
configuration file for syntax errors and other inconsistencies and to
exit with status 0 if no errors were detected, and withs status 1
otherwise.

   Before parsing, configuration file is preprocessed using `m4' (*note
Preprocessor::). To see the preprocessed configuration without actually
parsing it, use `-E' command line option. To avoid preprocessing it, use
`--no-preprocessor' option.

   The rest of this section describes the configuration file syntax in
detail. You can receive a concise summary of all configuration
directives any time by running `wydawca --config-help'.

4.1 Configuration file syntax
=============================

Wydawca configuration file consists of statements and comments.

   There are three classes of lexical tokens: keywords, values, and
separators. Blanks, tabs, newlines and comments, collectively called
"white space" are ignored except as they serve to separate tokens. Some
white space is required to separate otherwise adjacent keywords and
values.

4.1.1 Comments
--------------

"Comments" may appear anywhere where white space may appear in the
configuration file. There are two kinds of comments: single-line and
multi-line comments. "Single-line" comments start with `#' or `//' and
continue to the end of the line:

     # This is a comment
     // This too is a comment

   "Multi-line" or "C-style" comments start with the two characters
`/*' (slash, star) and continue until the first occurrence of `*/'
(star, slash).

   Multi-line comments cannot be nested. However, single-line comments
may well appear within multi-line ones.

4.1.2 Pragmatic Comments
------------------------

Pragmatic comments are similar to usual single-line comments, except
that they cause some changes in the way the configuration is parsed.
Pragmatic comments begin with a `#' sign and end with the next physical
newline character. Wydawca version 2.1, understands the following
pragmatic comments:

`#include <FILE>'
`#include FILE'
     Include the contents of the file FILE. If FILE is an absolute file
     name, both forms are equivalent. Otherwise, the form with angle
     brackets searches for the file in the "include search path", while
     the second one looks for it in the current working directory
     first, and, if not found there, in the include search path.

     The default include search path is:

       1. `PREFIX/share/wydawca/2.1/include'

       2. `PREFIX/share/wydawca/include'

     where PREFIX is the installation prefix.

     New directories can be appended in front of it using `-I'
     (`--include-directory') command line option (*note
     include-directory: Preprocessor.).

`#include_once <FILE>'
`#include_once FILE'
     Same as `#include', except that, if the FILE has already been
     included, it will not be included again.

`#line NUM'
`#line NUM "FILE"'
     This line causes `wydawca' to believe, for purposes of error
     diagnostics, that the line number of the next source line is given
     by NUM and the current input file is named by FILE.  If the latter
     is absent, the remembered file name does not change.

`# NUM "FILE"'
     This is a special form of `#line' statement, understood for
     compatibility with the C preprocessor.

   In fact, these statements provide a rudimentary preprocessing
features. For more sophisticated ways to modify configuration before
parsing, see *note Preprocessor::.

4.1.3 Statements
----------------

A "simple statement" consists of a keyword and value separated by any
amount of whitespace. Simple statement is terminated with a semicolon
(`;').

   Examples of simple statements:

     daemon yes;
     pidfile /var/run/wydawca.pid;

   A "keyword" begins with a letter and may contain letters, decimal
digits, underscores (`_') and dashes (`-').  Examples of keywords are:
`group', `file-sweep-time'.

   A "value" can be one of the following:

number
     A number is a sequence of decimal digits.

boolean
     A boolean value is one of the following: `yes', `true', `t' or
     `1', meaning "true", and `no', `false', `nil', `0' meaning "false".

unquoted string
     An unquoted string may contain letters, digits, and any of the
     following characters: `_', `-', `.', `/', `@', `*', `:'.

quoted string
     A quoted string is any sequence of characters enclosed in
     double-quotes (`"'). A backslash appearing within a quoted string
     introduces an "escape sequence", which is replaced with a single
     character according to the following rules:

     Sequence             Replaced with
     \a                   Audible bell character (ASCII 7)
     \b                   Backspace character (ASCII 8)
     \f                   Form-feed character (ASCII 12)
     \n                   Newline character (ASCII 10)
     \r                   Carriage return character (ASCII
                          13)
     \t                   Horizontal tabulation character
                          (ASCII 9)
     \v                   Vertical tabulation character
                          (ASCII 11)
     \\                   A single backslash (`\')
     \"                   A double-quote.

     Table 4.1: Backslash escapes

        In addition, the sequence `\NEWLINE' is removed from the
     string. This allows to split long strings over several physical
     lines, e.g.:

          "a long string may be\
           split over several lines"

        If the character following a backslash is not one of those
     specified above, the backslash is ignored and a warning is issued.

        Two or more adjacent quoted strings are concatenated, which
     gives another way to split long strings over several lines to
     improve readability. The following fragment produces the same
     result as the example above:

          "a long string may be"
          " split over several lines"

        Depending on the context, the contents of a quoted string may be
     subject to "meta-variable interpretation". During this process,
     any sequence

          ${VAR}

     where VAR is the name of a defined meta-variable, is replaced with
     the value of the variable. This sequence is called "meta-
     reference". For example, if the meta-variable `user' has the value
     `smith', then the string

          "where user = '${user}'"

     becomes

          "where user = 'smith'"

        If the name of the variable consists of a single character, the
     curly braces around it may be omitted. Thus, `${u}' and `$u' are
     equivalent.

        If VAR is not defined, the meta-reference is left unchanged.

        The special sequence `$-' causes removal of it and any character
     following it. Most often it is used as a next-to-last character on
     a line, right before the newline. In this position it causes the
     removal of the trailing newline, similar to `dnl' in `m4'.  *Note
     Triplet Listings: listings, for a detailed description and
     examples of `$-' use.

        To insert a literal `$' character in a string that is subject to
     meta-variable interpretation, duplicate it: `$$'.

        The exact set of defined meta-variables and their values depend
     on the context and are discussed in detail below.

  Here-document
        A "here-document" is a special construct that allows to
     introduce strings of text containing embedded newlines.

        The `<<WORD' construct instructs the parser to read all the
     following lines up to the line containing only WORD, with possible
     trailing blanks. Any lines thus read are concatenated together
     into a single string. For example:

          <<EOT
          A multiline
          string
          EOT

        Body of a here-document is interpreted the same way as
     double-quoted string, unless WORD is preceded by a backslash (e.g.
     `<<\EOT') or enclosed in double-quotes, in which case the text is
     read as is, without interpretation of escape sequences.

        If WORD is prefixed with `-' (a dash), then all leading tab
     characters are stripped from input lines and the line containing
     WORD. Furthermore, if `-' is followed by a single space, all
     leading whitespace is stripped from them. This allows to indent
     here-documents in a natural fashion. For example:

          <<- TEXT
              All leading whitespace will be
              ignored when reading these lines.
          TEXT

        It is important that the terminating delimiter be the only
     token on its line. The only exception to this rule is allowed if a
     here-document appears as the last element of a statement. In this
     case a semicolon can be placed on the same line with its
     terminating delimiter, as in:

          help-text <<-EOT
                  A sample help text.
          EOT;

  list
        A "list" is a comma-separated list of values. Lists are
     enclosed in parentheses. The following example shows a statement
     whose value is a list of strings:

          alias (test,null);

        In any case where a list is appropriate, a single value is
     allowed without being a member of a list: it is equivalent to a
     list with a single member. This means that, e.g.

          alias test;

     is equivalent to

          alias (test);

  time interval specification
        The "time interval specification" is a string that defines an
     interval, much the same way we do this in English: it consists of
     one or more pairs `number'-`time unit'. For example, the following
     are valid interval specifications:

          "1 hour"
          "2 hours 35 seconds"
          "1 year 7 months 2 weeks 2 days 11 hours 12 seconds"

     The pairs can occur in any order, however unusual it may sound to a
     human ear, e.g. `2 days 1 year'. If the `time unit' is omitted,
     seconds are supposed.


   A "block statement" introduces a logical group of statements. It
consists of a keyword, followed by an optional value, and a sequence of
statements enclosed in curly braces, as shown in the example below:

     spool download {
       source /home/ftp/incoming/ftp;
       destination /home/ftp/pub;
     }

   The closing curly brace may be followed by a semicolon, although
this is not required.

4.1.4 Preprocessor
------------------

Before parsing its configuration file, `wydawca' preprocesses it. The
built-in preprocessor handles only file inclusion and `#line'
statements (*note Pragmatic Comments::), while the rest of traditional
preprocessing facilities, such as macro expansion, is supported via
`m4', which is used as an external preprocessor.

   The detailed description of `m4' facilities lies far beyond the
scope of this document. You will find a complete user manual in *note
GNU M4 manual: (m4)Top.  For the rest of this subsection we assume the
reader is sufficiently acquainted with `m4' macro processor.

   The external preprocessor is invoked with `-s' flag, which instructs
it to include line synchronization information in its output. This
information is then used by the parser to display meaningful
diagnostic. An initial set of macro definitions is supplied by the
`pp-setup' file, located in `$PREFIX/share/wydawca/VERSION/include'
directory (where VERSION means the version of Wydawca package).

   The default `pp-setup' file renames all `m4' built-in macro names so
they all start with the prefix `m4_'. This is similar to GNU m4
`--prefix-builtin' options, but has an advantage that it works with
non-GNU `m4' implementations as well.

   Additional control over the preprocessor is provided via the
following command line options:

`--define=NAME[=VALUE]'
`-DNAME[=VALUE]'
     Define the preprocessor symbol NAME as having VALUE, or empty.

`--include-directory=DIR'
`-IDIR'
     Add DIR to the list of directories searched for preprocessor
     include files.

`--no-preprocessor'
     Disable preprocessor.

`--preprocessor=COMMAND'
     Use COMMAND instead of the default preprocessor.

4.2 General Settings
====================

 -- Config: foreground bool
     If BOOL is `yes', run in foreground. *Note foreground: invocation.

 -- Config: single-process bool
     Configure single process mode. Normally `wydawca' spawns
     subprocesses for handling incoming connections and spool jobs.
     This is disabled if BOOL is `yes' (a so-called "single-processs
     mode"). This mode is designed for debugging purposes. Do not use
     it in production environments, because it severely impairs
     performance.

 -- Config: umask value
     Set the default umask. The VALUE argument must be an octal number.

 -- Config: file-sweep-time time
     Consider triplet expired if its oldest file was created more than
     TIME seconds ago. *Note time interval specification::, for the
     syntax of TIME.

     This parameter may also be set for each spool individually. *Note
     file-sweep-time: spool.

 -- Config: gpg-homedir dir
     Set default GPG home directory. The keys for signing outgoing
     messages are looked up in this directory. *Note gpg-sign:
     statreports, and *note gpg-sign: event notification.

4.3 User Privileges
===================

`Wydawca' refuses to run with the root privileges. You should configure
its user privileges by using `user' and, optionally, `group' statements
in its configuration file:

 -- Config: user name
     Run with UID and GID of the user NAME.

 -- Config: group list
     Retain the supplementary groups from the LIST. The latter must
     contain group names. For example:

          group (nogroup, ftp);

4.4 Daemon Configuration
========================

Statements in this section configure the daemon mode.

 -- Config: daemon bool
     Enable daemon mode.

 -- Config: listen url
     Define a socket to listen on. Allowed values for URL are:

    inet://IP:PORT
          Listen on IPv4(1). address IP. IP may be given either in a
          dotted quad notation or as a symbolic host name. PORT is
          either a decimal port name, or a service name from
          `/etc/services'.

    local://FILE
    file://FILE
    unix://FILE
          Listen on the UNIX socket file FILE, which is either an
          absolute or relative file name.

 -- Config: all-spools name
     Declare a special service name, which will be treated as a request
     to process all spools.

 -- Config: wakeup-interval time
     Specifies the wake-up interval for the daemon. If no connections
     are requested during TIME, the server will wake up and sweep all
     the configured spools. It is useful for periodical removal of
     expired triplets. See also `file-sweep-time' statement (*note
     file-sweep-time: general.).

     *Note time interval specification::, for the syntax of TIME.

 -- Config: pidfile file
     Store master process PID in FILE. Default pidfile location is
     `LOCALSTATEDIR/run/wydawca.pid'.

   ---------- Footnotes ----------

   (1) Support for IPv6 will be added in future versions.

4.5 TCP Wrappers
================

Access to the socket specified in `listen' statement is controlled by
the `tcp-wrapper' block statement:

 -- Config: tcp-wrapper { ... }
          tcp-wrapper {
            enable ARG:BOOLEAN;
            daemon NAME:STRING;
            allow-table FILE:STRING;
            deny-table FILE:STRING;
            allow-syslog-priority PRIO:STRING;
            deny-syslog-priority PRIO:STRING;
          }

   This statement is available only if `wydawca' was compiled with
support for TCP wrappers.

 -- Config: tcp-wrapper: enable bool
     Enable or disable the use of TCP wrappers.

 -- Config: tcp-wrapper: daemon name
     Set the "daemon name". It is the name before the colon in the
     access control file, that marks the line controlling access to
     `wydawca'. The default is `wydawca'.

 -- Config: tcp-wrapper: allow-table file
     File name of the positive access control file. By default
     `/etc/hosts.allow'.

 -- Config: tcp-wrapper: deny-table file
     File name of the negative access control file. By default
     `/etc/hosts.deny'.

 -- Config: tcp-wrapper: allow-syslog-priority prio
     Log allowed accesses via the given `syslog' priority.

 -- Config: tcp-wrapper: deny-syslog-priority prio
     Log denied accesses via the given `syslog' priority.

   Allowed values for PRIO in the `allow-syslog-priority' and
`deny-syslog-priority' statements are: `emerg', `alert', `crit', `err',
`warning', `notice', `info', and `debug'.

4.6 Locking Configuration
=========================

To avoid a possibility of two `wydawca' instances handling the same
triplet, `wydawca' "locks" the spool before processing it. This is done
by creating a "lock file". The parameters of the locking subsystem are
configured via the `locking' statement:

 -- Config: locking { ... }
          locking {
            enable ARG:BOOLEAN;
            directory DIR:STRING;
            expire-time TIME:INTERVAL;
            timeout TIME:INTERVAL;
          }

 -- Config: locking: enable bool
     Enable or disable locking. By default it is enabled.

 -- Config: locking: directory dir
     Sets directory for lock files. Make sure DIR is writable for the
     user (or group) `wydawca' runs at (*note user privileges::.

     The default directory is `LOCALSTATEDIR/lock/wydawca'.

 -- Config: locking: expire-time time
     Sets expiration interval for lock files. An existing lock file
     older than TIME is considered stale and removed.

     *Note time interval specification::, for the syntax of TIME.

 -- Config: locking: timeout time
     Timeout for acquiring locks. If a lock file cannot be acquired
     during this time, `wydawca' reports error and exits.

     *Note time interval specification::, for the syntax of TIME.

4.7 Syslog Configuration Directives
===================================

Unless told otherwise, `wydawca' uses `syslog' to print its diagnostic
messages. By default, the program uses the `local1' facility. The
`syslog' statement allows to change that:

 -- Config: syslog { ... }
          syslog {
            facility local1;
            tag wydawca;
            print-priority yes;
          }

 -- Config: syslog: facility name
     Configures the syslog facility to use. Allowed values are: `auth',
     `authpriv', `cron', `daemon', `ftp', `local0' through `local7',
     and `mail'. These names are case-insensitive and may be optionally
     prefixed with `log_' (case-insensitive as well).

 -- Config: syslog: tag string
     This statement sets the "syslog tag", a string identifying each
     message issued by the program. By default, the name of the program
     (`wydawca') is used.

 -- Config: syslog: print-priority bool
     In addition to priority segregation, provided by `syslog', you can
     instruct `wydawca' to prefix each syslog message with its
     priority. To do so, set:

          print-priority yes;

4.8 SQL Databases
=================

Several statements in configuration file may need to access an SQL
database. `Wydawca' is able to use any number of databases
simultaneously, the only restriction being that they must be `MySQL'
databases (this restriction will be removed in future releases).

   A database is defined using `sql' block statement:

 -- Config: sql ID { ... }
          sql ID {
            config-file FILE;
            config-group GROUP;
            host HOSTNAME;
            database DBNAME;
            user USERNAME;
            password STRING;
            ssl-ca STRING;
          }

     Here, ID is a string uniquely identifying this database. It is
     used by other configuration statements (e.g. by dictionaries, see
     the next section) to refer to this database.

 -- Config: sql: config-file NAME
     Set the name of the SQL configuration file to read.

 -- Config: sql: config-group NAME
     Set the name of the group in the SQL configuration file, from
     where to read configuration options.

   The statements above allow to keep all security-sensitive
information, such as SQL username and password, in an external
configuration file and thus to relax permission requirements for
`wydawca.rc'. The exact format of such external configuration file
depends on the flavor of SQL DBMS in use.  As of version 2.1 `wydawca'
supports only `MySQL', so the configuration file is what is called
"option file" in `MySQL' parlance (*note Using Option Files:
(mysql)option-files.).

   For example, suppose your `wydawca.rc' contains the following:

     sql default {
       config-file /etc/wydawca.mysql;
       config-group wydawca;
     }

Then, the `/etc/wydawca.mysql' would contain the actual parameters for
accessing the database, e.g.:

     [wydawca]
     socket = /var/db/mysql.sock
     database = savane
     user = savane
     pass = guessme

   Another way to specify database credentials is by using the
statements described below. If you prefer this way, you will have to
tighten the permissions of `wydawca.rc' so that no third person could
see the SQL password. The recommended permissions are `0600'.

 -- Config: sql: host HOSTNAME[:PORT-OR-SOCKET]
     Set the hostname or IP address of the host running the database.
     Optional PORT-OR-SOCKET specifies port number (for TCP
     connections) or socket name (for UNIX sockets) to use. In the
     latter case, the HOSTNAME and the colon may be omitted. If,
     however, it is present, it must be `localhost'.

 -- Config: sql: database name
     Specifies the database name.

 -- Config: sql: user name
     Sets the database user name.

 -- Config: sql: password string
     Sets the password for accessing the database.

 -- Config: sql: ssl-ca file
     Sets the pathname to the certificate authority file, if you wish
     to use a secure connection to the server via SSL.

An example `sql' statement follows:

     sql default {
       host project.database.com:3306;
       database savane;
       user root;
       password guessme;
     }

   It is possible to combine both methods, e.g.:

     sql default {
       config-file /etc/wydawca.sql;
       host project.database.com:3306;
       database savane;
     }

   Then, `wydawca' will attempt to obtain the missing information
(username and password, in this case) from the `/etc/wydawca.sql' file.

4.9 Dictionaries
================

A "dictionary" defines the ways to retrieve user information necessary
to verify the submission. This information can be, for example, the
user's PGP key or his permissions on a project.

   A dictionary is defined in configuration file using the following
syntax:

 -- Config: dictionary { ... }
          dictionary DICT-ID {
            type TYPE;
            query STRING;
            params (PARAM1,PARAM2,...);
          }

   The `dictionary' statement can appear either in the global scope of
the configuration file, or inside a `spool' statement (*note spool::).
Global definitions affect all directory pairs in the configuration
file, and ones inside a `directory' statement override them for that
particular spool.

   There are two dictionaries, identified by the value of DICT-ID tag:

project-owner
     Keeps email addresses and real names of administrators (or
     "owners") of a project. It may return any number of rows, each one
     consisting of two columns: an email address and a user name, in
     this order.

project-uploader
     Keeps system user names, real names, emails and GPG keys of the
     users that are allowed to make uploads for the project.

   The sub-statements of `dictionary' are:

 -- Config: dictionary: type name
     Defines the type of this dictionary. NAME is one of the following:

    builtin
          The data are supplied in the configuration file.

    sql
          Retrieve data from an SQL database. Currently only `MySQL' is
          supported.

    external
          Retrieve data using an external program. This dictionary type
          is reserved for future use.

     See below for a detailed description of these dictionary types.

 -- Config: dictionary: query string
     Sets the query used for retrieving the data. The STRING is subject
     to meta-variable interpretation (*note meta-interpretation::). The
     following meta-variables are defined:

    `p'
    `project'
          The system name of the project for which the triplet is
          submitted. It is defined as the value of directive
          `directory', or, in case this value contains slashes, the
          shortest initial prefix of that value, not containing slashes.

    `spool'
          The name of the distribution spool where this upload
          originates (*note spool::).

    `url'
          The URL of the spool, as set in the `url' statement of the
          `spool' block (*note url: spool.).

    `dir'
          Directory (relative to the project distribution root) where
          the files are going to be uploaded.

    `dest-dir'
          Spool destination directory (*note destination: spool.).

    `source-dir'
          Spool source directory (*note source: spool.).

    `u'
    `user'
    `user:name'
          The system name of the user that submitted the triplet. This
          is defined only for `project-owner' dictionaries.

    `comment'
          The value of the `comment' field from the directive file.

 -- Config: dictionary: params (param1, param2, ...)
     Supplies additional parameters.

4.9.1 SQL Dictionary
--------------------

Dictionaries of `sql' type retrieve information from an SQL database
(as of version 2.1, only `MySQL' databases are supported).

   The `query' statement supplies the SQL query to execute. Normally,
it should be a `SELECT' query.

   The `params' statement must supply a single parameter - the
identifier of one of the preceding `sql' blocks (*note sql::), which
determines database name and user credentials needed to access it.

   The following sub-nodes contain sample definitions for the `sql'
dictionaries. They are based on the database structure used in `Savane'
system (http://gna.org/projects/savane).

4.9.1.1 Project-owner: an SQL Implementation
............................................

Retrieve email addresses and real names of administrators (or "owners")
of a project. It may return any number of rows, each one consisting of
two columns: an email address and a user name, in this order.

     dictionary project-owner {
       type sql;
       params (default);
       query   "SELECT user.email, user.realname "
               "FROM user,user_group,groups "
               "WHERE user_group.user_id=user.user_id "
               "AND user_group.group_id=groups.group_id "
               "AND user_group.admin_flags = 'A' "
               "AND groups.unix_group_name = '${project}'";
     }

4.9.1.2 Project-uploader: an SQL Implementation
...............................................

This dictionary assumes that the `user' table has a special column,
`upload_flags', whose value is `Y' for those users who can do uploads
for this project:

     dictionary project-uploader {
       type sql;
       params (default);
       query   "SELECT user.email, user.realname "
               "FROM user,user_group,groups "
               "WHERE user_group.user_id=user.user_id "
               "AND user_group.group_id=groups.group_id "
               "AND user_group.upload_flags = 'Y' "
               "AND groups.unix_group_name = '${project}'";
     }

4.9.2 Built-in Dictionary
-------------------------

"Builtin dictionaries" are small dictionaries that keep all data in
their `params' list. They are designed mainly for testing purposes.

   Look ups in builtin dictionaries are performed as follows: The
`query' value is expanded (*note query::). The resulting value is used
as a "key" for lookup in `params' list.  The list scanned as follows:

  1. INIT

     Let I be the index of the current element in `params'.  Set I to 0.

  2. GETEL

     Get the Ith element.

  3.  If it begins with a slash, interpret it as "comparison type
     indicator". Its possible values are:

    /exact
          Exact comparison. The key must be exactly equivalent to the
          dictionary field.

    /fnmatch
          Dictionary field is treated as an "fnmatch globbing pattern".
          *Note globbing pattern: (glob(7))globbing pattern.

    /regex
          Dictionary field is treated as a regular expression.  Unless
          configured otherwise by flags (see below), POSIX extended
          regular expressions are used (*note Extended regular
          expressions: (sed)Extended regexps.).

     If that word ends with a comma, the characters following it are
     "flags", defining the type of matching. Allowed flags are:

     Flag          Meaning
     --------------------------------------------------------------------- 
     i             Ignore case
     b             Use basic regular expressions

     For example, the string `/exact,i' specifies case-insensitive
     exact comparison, the string `/regex,bi' specifies
     case-insensitive basic regular expression matching, etc.

     Go to step `INCR'.

  4. COMP

     Compare the element with the key, using currently selected
     comparison method.

  5.  If the element matches the key, add elements `I+1' through `I+N'
     to the result set. The value for N is selected as follows:

     Dictionary                                             N
     --------------------------------------------------------------------- 
     project-owner                                          2
     project-uploader                                       4

  6.  Set `I = I + N'

  7. INCR

     Set `I = I + 1'.

  8. LOOP

     If I is greater than the number of elements in `param', then stop.
     Otherwise, go to step `GETEL'.

   For example, the following defines the `project-owner' dictionary,
containing data for projects `foo' and `bar':

     dictionary project-owner {
       type builtin;
       query "${project}";
       params ("/exact",
               "foo", "foo-owner@domain.net", "Foo Admin",
               "bar", "smith@other.net", "John Smith");
     }

4.9.3 External Dictionary
-------------------------

As of version 2.1 this dictionary is not yet implemented.

4.10 Archivation
================

There may be cases when project maintainers need to overwrite existing
distributed files with another ones, having the same names.  (Note,
however, that this practice is not encouraged). In that case, `wydawca'
needs to first "archive" the already existing file, and then put the
new one in its place. Moreover, the directive file format allows
maintainers to explicitly require archivation of their existing files.

   `Wydawca' supports two basic archivation methods: to a `tar' file,
and to a separate directory. The method to be used is configured using
`archive' statement. This statement can appear either in the global
scope, in which case it affects all spools, or within a `spool' block
(*note spool::), where it affects only the given spool.

 -- Config: archive type
          archive TYPE {
            name FILE-OR-DIR;
            backup TYPE;
          }

     The TYPE argument specifies the archivation type:

    none
          Disable archivation.

    tar
          Add to a `tar' archive.

    directory
          Store file in a separate directory.

 -- Config: archive: name file-or-dir
     Specify the name of the tar archive (if type `tar' is used) or
     destination directory (if type `directroy' is used).

   If the archivation type tar is used, the `name' statement sets the
full name of the tar archive to use, e.g.:

     archive tar {
       name /var/spool/uploads/archive.tar;
     }

   The file being archived is appended to the archive using `tar -r'
(*note Appending Files to an Archive: (tar)appending files.). Any
archived instance can subsequently be retrieved using GNU tar
`--occurrence' option (*note Multiple Files with the Same Name:
(tar)multiple.).

 -- Config: tar-program name
     By default, `wydawca' will search for `tar' binary in your search
     path. If you wish to use a particular binary, you may specify its
     full file name using `tar-program' statement.

   The `directory' archivation type means that archive copies will be
stored in a directory specified by the `name' statement.  If it begins
with a slash (i.e. represents an absolute file name), an exact copy of
the distribution directory hierarchy will be created under it. For
example, given this configuration:

     archive directory {
       name /var/backups/gnu;
     }

all files from `/home/ftp/gnu/tar' will be archived in
`/var/backups/gnu/tar', and files from `/home/ftp/gnu/tar/old' will be
archived in `/var/backups/gnu/tar/old', etc.

   If the directory name does not begin with a slash, it will be created
under the corresponding distribution directory. For example, the
following archivation settings:

     archive directory {
       name .archive;
     }

mean that files from `/home/ftp/gnu/tar' will be archived in the
directory `/home/ftp/gnu/tar/.archive', files from
`/home/ftp/gnu/tar/old' -- in `/home/ftp/gnu/tar/.archive/old', etc.

 -- Config: archive: backup type
     When using the `directory' archivation type, it may happen that the
     archive file with the same name as the one about to be created
     already exists. This statement specifies how to handle the
     existing copy, in other words, how to "backup" it. The TYPE
     argument corresponds to the `version-control' Emacs variable. The
     following table describes its possible values:

    `t'
    `numbered'
          Always make numbered backups.

    `nil'
    `existing'
          Make numbered backups of files that already have them, simple
          backups.  of the others.

    `never'
    `simple'
          Always make simple backups.


     If no backup method is given, `existing' is assumed

   Signature files (i.e. the ones ending with `.sig') are usually
located in the same directory as the files they sign. To enforce this
rule, `wydawca' implements "implicit signature archivation" facility.
It works as follows. When archivation of FILE is requested by `archive:
FILE' statement in the directive file (*note Standalone directives:
(maintain.info)FTP Upload Directive File - v1.1.), `wydawca' also
checks if the file named `FILE.sig' exists. If so, it is archived along
with `FILE'.

 -- Config: archive-signatures bool
     If implicit signature archivation is not needed, use the
     `archive-signatures' statement to disable it, e.g.:

          archive-signatures no;

4.11 Distribution Spool
=======================

A "distribution spool" defines the location of the source directory and
the corresponding distribution (or "destination") directory. It may
also set archivation type, various dictionaries and notifications for
that directory, thus overriding the global settings.

   The `spool' block statement defines a distribution spool:

 -- Config: spool tag { ... }
          spool TAG {
            url URL;
            alias (ALIASES);
            source DIR;
            destination DIR;
            file-sweep-time INTERVAL;
            dictionary { ... }
            archive { ... }
            notify-event { ... }
          }

     The TAG argument defines a unique identifier for this spool. It
     will be used in log messages, timers (*note spool-timers::) and in
     meta-variable interpretation (*note meta-interpretation::).

 -- Config: spool: alias list
     Defines a list of "aliases", i.e. alternative tag names for this
     spool.

 -- Config: spool: url string
     Defines download URL, associated with this spool. Its value may be
     used as `${url}' meta-variable in mail notifications.

 -- Config: spool: source dir
     Specifies the location of the source directory.

 -- Config: spool: destination dir
     Specifies the type and location of the destination directory. The
     DIR argument must be either an absolute name of a directory on the
     local file system, or a special URL. `Wydawca' version 2.1
     supports two destination URL schemes:

    file://DIR-NAME
    dir://DIR-NAME
          Equivalent to DIR-NAME alone. Defines a destination directory
          located on the local file system.

    null:
          Defines a "null upload spool". Null spools implement all tests
          described in *note overview::, but do not do any actual
          copying. The uploaded files are simply removed after checks
          are over. Null spools are useful mainly for diagnostic
          purposes.

   The following statements, if present, override the corresponding
global definitions for this spool.

 -- Config: spool: archive { ... }
     Configure spool-specific archivation. *Note archivation::, for its
     description.

 -- Config: spool: dictionary tag { ... }
     Configure spool-specific dictionary. *Note dictionaries::, for a
     detailed discussion of this statement.

 -- Config: spool: file-sweep-time time
     Set expiration time for triplets in this spool. A triplet is
     considered expired if its oldest file was created more than TIME
     seconds ago. This statement overrides the global `file-sweep-time'
     setting (*note file-sweep-time: general.).

 -- Config: spool: notify-event { ... }
     Configure spool-specific event notification. *Note notification::,
     for a detailed discussion of this statement.

   The `source' and `destination' statements are mandatory.

   For example, the following definition says that valid uploads to
`/home/ftp/incoming/ftp' should be transferred to `/home/ftp/gnu':

     spool ftp {
      url ftp://ftp.gnu.org.ua;
      source /home/ftp/incoming/ftp;
      destination /home/ftp/gnu;
     }

This spool defines no particular archivation type, dictionary or
notifications, so it will inherit these settings from the global
configuration.

   The following example shows the same spool, that additionally sets
its own archivation method:

     spool ftp {
      url ftp://ftp.gnu.org.ua;
      source /home/ftp/incoming/ftp;
      destination /home/ftp/gnu;
      archive directory {
        name .archive;
        backup numbered;
      }
     }

4.12 Distribution Verification
==============================

After the submission has been verified, `wydawca' may also run an
additional check to verify whether the main file (normally, a tarball)
is OK to be distributed. To set up such "distribution verification",
add the following statement either in the global scope, or within a
`spool' declaration:

 -- Config: check-script TEXT
 -- Config:spool: check-script TEXT
     Define the distribution verification script. The TEXT must be a
     valid `sh' program. It is executed without arguments, in a
     temporary directory which contains a copy of the main distribution
     file. The script can refer to the following environment variables:

      -- Check Environment: WYDAWCA_SPOOL
          Spool tag.

      -- Check Environment: WYDAWCA_SOURCE
          Spool source directory, as set by the `source' statement
          (*note tag: spool.).

      -- Check Environment: WYDAWCA_DEST
          Spool destination directory (*note destination: spool.).

      -- Check Environment: WYDAWCA_URL
          Spool URL (*note url: spool.).

      -- Check Environment: WYDAWCA_TRIPLET_BASE
          Base name of the triplet.

      -- Check Environment: WYDAWCA_DIST_FILE
          File name of the main distribution file.

     Apart from these, the script inherits `wydawca' environment.

     The submission is accepted only if the script returns 0. Otherwise,
     it is rejected and the `check-failure' event (*note event
     notification::) is generated.

     In case of non-zero return, the script may return additional
     diagnostics on the standard output. This diagnostics will be
     available for use in notification messages via the `check:diagn'
     meta-variable.

     Additionally, the actual return code of the script, in decimal, is
     available in the `check:result' meta-variable. If the script
     terminates on a signal, the value of this variable is `SIG+N',
     where N is the signal number.

   If both global and spool `check-script's are defined, `wydawca'
executes both scripts as if they were connected by a logical `&&', i.e.
per-spool script is executed only if the global one returned success
(`0'). The submission is accepted only if both scripts returned `0'.

   Since the script usually contains several lines, the `config-script'
value is usually supplied using a here-document construct (*note
here-document::).

   The following example illustrates the use of `config-script' to
catch possible security holes in the distributed `Makefile.in' files(1)

       check-script <<EOT
     case ${WYDAWCA_DIST_FILE} in
     *.tar|*.tar.*)
       if tar -xOf ${WYDAWCA_DIST_FILE} --occurrence=1 \
           --wildcards --no-wildcards-match-slash '*/Makefile.in' | \
           grep -q 'perm -777'; then
         fmt <<_EOF_
     The top-level Makefile.in in ${WYDAWCA_DIST_FILE} changes mode of
     all the directories below the build tree to 777 before creating
     the tarball. This constitutes a security hole (see CVE-2009-4029[1],
     for more details).

     Please, rebuild the package using a newer Automake (at least v. 1.11.1)
     and resubmit.
     _EOF_
         cat <<_EOF_
     --
     [1] http://article.gmane.org/gmane.comp.sysutils.autotools.announce/131
     _EOF_
         exit 1
       fi
       ;;
     *)
       ;;
     esac

     exit 0
     EOT;

   ---------- Footnotes ----------

   (1) See
`http://article.gmane.org/gmane.comp.sysutils.autotools.announce/131'.

4.13 Statistics
===============

At the end of the run, `wydawca' prints a detailed statistics of its
execution on the diagnostic channel `info'.  The statistics is printed
only if at least one of its items is not zero.  The following example
illustrates what you might get if you configured full statistics output:

     errors: 0
     warnings: 2
     bad signatures: 0
     access violation attempts: 0
     complete triplets: 6
     incomplete triplets: 2
     bad triplets: 0
     expired triplets: 0
     triplet successes: 6
     files uploaded: 12
     files archived: 2
     symlinks created: 0
     symlinks removed: 0

   Each item in this statistics is configurable, and a unique
configuration keyword is associated with it. The statistics items and
their corresponding keywords are described in the table below:

`errors'
     Any error that occurred during the run.

`warnings'
     Any warning condition occurred during the run.

`bad-signatures'
     A PGP signature not matches the public key for the user that
     issued it.

`access-violations'
     A user is attempting to upload files for some project, but it is
     not authorized to do so.

`complete-triplets'
     A complete triplet is registered.

`incomplete-triplets'
     An incomplete triplet is registered, i.e. such that misses one or
     more of its files. Notice, that a directive file alone is counted
     as a complete triplet, provided that its signature verifies
     correctly and that it does not contain `file' directive.

`bad-triplets'
     A triplet contains files owned by different users.

`expired_triplets'
     A triplet has expired.

`triplet_success'
     A triplet is processed successfully

`uploads'
     An upload is processed successfully. An upload is defined as a
     move of a file and its detached signature from the source to the
     destination directory.

`archives'
     An archivation is performed

`symlinks'
     A symlink is created.

`rmsymlinks'
     A symlink is removed.

 -- Config: statistics list
     The amount of information included in the statistics summary is
     configured using the `statistics' statement. This statement takes
     a list of arguments, each one being one of the keywords, described
     above. For example, the following statement causes only the
     information about errors and warnings to be printed:

          statistics (errors, warnings);

     The output produced looks like:

          errors: 0
          warnings: 2

     A special keyword `none' can be used to suppress this output
     altogether (which is the default), as in

          statistics none;

     Another special keyword is `all'. It enables full statistics
     output. This keyword may also be followed by any number of
     statistics keywords, which are in this case _excluded_ from the
     summary. For example, to output all statistics, except errors and
     warnings one would set:

          statistics (all, errors, warnings);

4.14 Mail Notification
======================

While running, `wydawca' keeps track of certain events occurring, such
as, for example, broken PGP signatures or file uploads attempted by
unauthorized users. The utility can notify, via email, project
administrators about any of those events that concern their projects.
Additionally, the system administrator can choose to obtain via email
the execution statistics, described in the previous section.

   The sender email address for these notifications is set using the
`from-address' statement.

 -- Config: from-address address
     Set sender address for outgoing mails. E.g.:

          from-address ftp-uploads@gnu.org.ua;

   It is not strictly necessary to specify the sender address. In the
absence of `from-address' statement, the sender email will be
constructed from the name of the user `wydawca' runs as (*note user
privileges::) and the full domain name of the machine it runs at.

 -- Config: admin-address email
     Sets the admin email address or addresses. The statistics
     notifications and any notifications configured to be sent to admins
     will be forwarded to this address. The EMAIL argument is either a
     RFC 822 email address, or a list of such addresses. For example,
     the following statement configures a single admin address:

          admin-address root@gnu.org.ua;

     The example below illustrates how to configure multiple addresses:

          admin-address "root@gnu.org.ua,ftp-adm@gnu.org.ua";

     Yet another way to configure them is:

          admin-address (root@gnu.org.ua, ftp-adm@gnu.org.ua);

4.14.1 Mailer
-------------

To send messages, `wydawca' uses a special logical entity called a
"mailer". It is set in the configuration file using `mailer' keyword.

 -- Config: mailer url
     Set mailer URL.

   A mailer URL consists of a scheme specification, followed by `://'
separator and additional data. The URLs supported by Wydawca version
2.1 are described in the table below. As usual, square brackets
indicate optional parts:

smtp://HOST[:PORT]
     Use an SMTP server on HOST to relay messages. The HOST part is
     either an IP address in dotted-quad notation or as a symbolic host
     name. In the latter case, DNS system is be used to resolve it.
     Optional PORT specifies port number or symbolic name (as defined
     in `/etc/services'). It defaults to 25. For example:

          mailer smtp://remote.server.net:24;

sendmail://PROGNAME
     Use sendmail-compatible program PROGNAME. "Sendmail-compatible"
     means that the program must be able to read an RFC-822 message
     from its standard input and must support the following command
     line options:

    `-oi'
          Do not treat `.' as message terminator.

    `-f ADDR'
          Use ADDR as the sender address.

    `-t'
          Get recipient addresses from the message.

     Example:

          mailer sendmail:///usr/sbin/exim;

sendmail:
     This is a special form of the `sendmail' mailer. It uses the
     `sendmail' binary from the `_PATH_SENDMAIL' macro in your
     `/usr/include/paths.h'. It is the default mailer.

prog://PROGNAME?QUERY
     A "prog" mailer. This is a generalization of `sendmail' mailer
     that allows to use arbitrary external programs as mailers.

     The full file name of the program is given in PROGNAME part.  The
     QUERY part is a list of arguments, separated by `&' signs.
     Arguments may contain the following macro-substitutions:

    `${sender}'
          Expands to the sender email address.

    `${rcpt}'
          Expands to the recipient email addresses.

          The program PROGNAME must read an RFC-822 message from its
          standard input.

          An example of `prog' mailer definition:

               mailer "prog:///bin/nullmail?localhost&-F${sender}&${rcpt}

          When sending a mail, `wydawca' will invoke:

               /bin/nullmail localhost -FSENDER RCPT

          where SENDER means the sender address, and RCPT stands for
          the recipient email address.

    `| PROG ARGS..'
          Equivalent to the `prog' mailer, described above, but written
          in a more natural fashion. In this notation, the example
          definition above becomes:

               mailer "|/bin/nullmail localhost -F${sender} ${rcpt}"


4.14.2 Message Templates
------------------------

Each notification message is build from a message template, by
expanding meta-variables (*note meta-interpretation::) within it.  The
message text may be specified either in place within the configuration
directive it belongs to (*note notification::), or defined by
`define-message' statement.

 -- Config: define-message name text
     Define message NAME to be TEXT. This message can be referred to
     from other configuration statements by `@NAME' notation.

   The message text must be formatted as a valid RFC-822 message, i.e.
it must consist of two parts, message headers and body, separated by a
single empty line. Therefore TEXT is usually a "here-document"
construct (*note here-document::). For example:

     define-message my-message <<EOT
     From: Wydawca
     Subject: test

     This is a test message.
     EOT;

   If you do not wish to supply any headers (which is unlikely, because
a mail should at least have a `Subject' header), simply begin the
message text with an empty line, like this:

     define-message my-message <<EOT

     This is a test message.
     EOT;

4.14.3 Statistic Reports
------------------------

 -- Config: mail-statistics { ... }
     The `mail-statistics' statement configures the statistic reports
     sent to the system administrator.

          mail-statistics {
            message TEXT-OR-ID;
            statistics ITEM-LIST;
            gpg-sign KEY;
          }

 -- Config: mail-statistics: message text-or-id
     Define the message text. The argument is either the message text
     template, or a reference to a template previously defined by a
     `define-message' (*note templates::). The reference syntax is:

          message @NAME;

     where NAME is the message name as used in `define-message'.

 -- Config: mail-statistics: statistics item-list
     The argument is a list of statistics keywords as described in
     *note statistics::. A report will be sent only if statistics
     counters for at least one of the requested categories are not
     zero. For example, the following statement requires sending
     notifications only if there occurred any errors or access violation
     attempts, or any bad signature was uploaded:

          statistics (errors, access-violations, bad-signatures);

 -- Config: mail-statistics: gpg-sign key
     If this statement is present, the message will be signed using the
     supplied GPG KEY. The key is looked up in the GPG home directory
     (*note gpg-homedir::).

   The statistics message is sent to addresses configured by
`admin-address' statement (*note admin-address: notification.).

   The meta-variables available for use in statistics reports are:

Variable               Replaced with
-------------------------------------------------------------------------- 
date                   Current date and time in the current locale.
stat:errors            Number of errors detected.
stat:warnings          Number of warnings reported.
stat:bad_signatures    Number of bad signatures detected.
stat:access_violations Number of access violation attempts.
stat:complete_triplets Number of complete triplets processed.
stat:incomplete_tripletsNumber of incomplete triplets left  in the source
                       directory.
stat:bad_triplets      Number of bad triplets seen.
stat:expired_triplets  Number of expired triplets.
stat:triplet_success   Number of successfully processed triplets.
stat:uploads           Number of successful uploads.
stat:archives          Number of archivations performed.
stat:symlinks          Number of symbolic links created.
stat:rmsymlinks        Number of symbolic links removed.
stat:check-failures    Number of verification failures (*note
                       verification::).

   The following special variables, called "timers", are replaced with
the real or CPU time (in seconds) used while processing a certain task:

timer:wydawca:real     Real time spent in `wydawca' main code.
timer:wydawca:system   System CPU time spent in `wydawca' main code.
timer:wydawca:user     User CPU time spent in `wydawca' main code.
timer:TAG:real         Real time spent processing the TAG spool.
timer:TAG:system       System CPU time spent processing the TAG spool.
timer:TAG:user         User CPU time spent processing the TAG spool.

   An example definition of the admin notification template follows:

     mail-statistics {
       statistics (errors,warnings,bad_signatures,
                   access_violations);
       message <<EOT
     Subject: Wydawca stats

     This is to notify you that my run on ${date}
     caused the following results:

     errors ............................. ${stat:errors}
     warning ............................ ${stat:warnings}
     bad signatures ..................... ${stat:bad_signatures}
     access violation attempts .......... ${stat:access_violations}

     Timings:
     Real ............................... ${timer:wydawca:real} \
     (${timer:releases:real} + \
     ${timer:alpha:real} + \
     ${timer:test:real})
     System ............................. ${timer:wydawca:system} \
     (${timer:releases:system} + \
     ${timer:alpha:system} + \
     ${timer:test:system})
     User ............................... ${timer:wydawca:user} \
     (${timer:releases:user} + \
     ${timer:alpha:user} + \
     ${timer:test:user})

     Regards,
     Wydawca
     EOT;
     }

4.14.4 Event Notification
-------------------------

A number of "events" are tracked during the execution. Any of them can
be used to trigger an email notification of any party concerned: the
system administrator, project administrators, the user that initiated
the upload, or any other recipients, specified by their email
addresses. These notifications are configured using the `notify-event'
statement:

 -- Config: notify-event { ... }
          notify-event {
            event EV-ID;
            recipient WHO;
            message TEXT-OR-ID;
            gpg-key KEY;
          }

 -- Config: notify-event: event ev-id
     Send notification when the event EV-ID occurs. The following table
     describes the available EV-IDs:

    success
          Successful upload.

    bad-ownership
          An unauthorized user attempted to upload files for their
          project.

    bad-directive-signature
          The directive signature does not match the public key of the
          uploader.

    bad-detached-signature
          The detached signature does not match the public key of the
          uploader.

    check-failure
          Distribution verification failed. *Note verification::, for a
          detailed description.

 -- Config: notify-event: recipient who
     Determines who should receive the notification. The following
     values for WHO are allowed:

    `read'
    `message'
          Read recipients from the `To', `Cc' and `Bcc' headers of the
          message.

    `admin'
          The system administrator, as defined in `admin-address'
          statement (*note admin-address: notification.).

    `owner'
          Administrators of the project for which the files where
          uploaded. Their addresses are retrieved from the
          `project-owner' dictionary (*note dictionaries::).

    `user'
          User name of the user who uploaded files.

 -- Config: notify-event: message text-or-id
     Define the message text. The argument is either the message text
     template, or a reference to a template previously defined by a
     `define-message' (*note templates::).

 -- Config: notify-event: gpg-sign key
     If this statement is present, the message will be signed using the
     supplied GPG KEY. The key is looked up in the GPG home directory
     (*note gpg-homedir::).

   For example, the following two statements instruct `wydawca' to
email notifications about any `bad-directive-signature' event to
project administrators and to the user who did the upload, using two
different templates:

     notify-event {
       event bad-directive-signature;
       recipient user;
       message @usermsg;
     }

     notify-event {
       event bad-directive-signature;
       recipient owner;
       message @ownermsg;
     }

   The following macro-variables may be used in templates for these
notifications:

Variable               Replaced with
-------------------------------------------------------------------------- 
project                Project system name.
url                    URL of the distribution site.
spool                  Name of the spool (*note spool::).
dir                    Directory (relative to the project distribution
                       root) where the files where uploaded.
dest-dir               Value of the `destination' keyword.
source-dir             Value of the `source' keyword.
triplet:dist           File name of the main distribution file.
triplet:sig            File name of the detached signature file.
triplet:dir            File name of the directive file.
triplet:ls:full        A full listing of the uploaded triplet(1).
triplet:upload         Listing of the uploaded files (see below).
triplet:ls:dist        Listing of the main distribution file (see below).
triplet:ls:sig         Listing of the detached signature file (see
                       below).
triplet:ls:dir         Listing of the directive file (see below).
user                   System name of the user who uploaded the triplet.
user:name              System name of the user who uploaded the triplet.
user:real-name         Real name of the user who uploaded the triplet.
user:email             Email of the user who uploaded the triplet.
email:admin            Full(2). email address of the systems
                       administrator, as set by the `admin-address'
                       (*note admin-address: notification.).
email:owner            Full email address of the project administrator
                       ("owner").
email:user             Full email address of the user who did the
                       upload. Not to be confused with `user:email'.
check:result           Code returned by external checker, in decimal.
                       *Note check:result: verification, for a detailed
                       description.
check:diagn            Diagnostics text returned by external checker.
                       *Note verification::, for a detailed description.

   The following "timers" (*note spool-timers::) are defined:

Variable               Replaced with
-------------------------------------------------------------------------- 
timer:wydawca:real     Real time spent in `wydawca' main code.
timer:wydawca:system   System CPU time spent in `wydawca' main code.
timer:wydawca:user     User CPU time spent in `wydawca' main code.
timer:triplet:real     Real time spent processing this triplet.
timer:triplet:system   System CPU time spent processing this triplet.
timer:triplet:user     User CPU time spent processing this triplet.
timer:spool:real       Real time spent while processing this spool.
timer:spool:system     System CPU time spent while processing this spool.
timer:spool:user       User CPU time spent while processing this spool.

   "Listings" referred to in the table above, are similar to those
produced by the `ls' command, and include information on file
permissions, ownership, size and modification date. For example, here
is a possible `${triplet:ls:full}' listing:

     -rw-r--r-- gray users 2707278 2007-09-06 22:14:35 tar-1.18.tar.gz
     -rw-r--r-- gray users     189 2007-09-06 22:14:35 tar-1.18.tar.gz.sig
     -rw-r--r-- gray user       62 2007-09-06 22:14:35 tar-1.18.tar.gz.directive.asc

   The following example shows how to configure success notification
for the user. Notice the use of the `$-' after `${triplet:ls:upload}':
it removes the newline character after it and thus allows for more
natural indentation of the next line. Without it, the expanded message
would have contained two newlines after the full listing: one produced
by `${triplet:ls:upload}' and the second one taken verbatim from the
message template.

     notify-event {
       event success;
       recipient user;
       message <<EOT
     Subject: Upload of ${project} successful

     Upload of ${project} to ${url}/${dir} finished successfully.
     Files uploaded:

     ${triplet:ls:upload}$-

     Resource usage: ${timer:triplet:real}/${timer:wydawca:real}r \
     ${timer:triplet:user}/${timer:wydawca:user}u \
     ${timer:triplet:system}/${timer:wydawca:system}s

     Regards,
     Wydawca
     The Project Submission Robot
     EOT;
     }

   ---------- Footnotes ----------

   (1) It is equivalent to:
     ${triplet:ls:dist}
     ${triplet:ls:sig}
     ${triplet:ls:dir}

   (2) "Full" here means an email address with eventual personal part

5 `Wydawca' configuration file.
*******************************

This chapter summarizes the configuration statements. For each
statement, a reference to its detailed description is provided.

     # Enable daemon mode.
     # *Note daemon::.
     daemon ARG:BOOLEAN;

     # Start in foreground even in daemon mode.
     # *Note foreground: general.
     foreground ARG:BOOLEAN;

     # Do not spawn subprocesses.
     # *Note single-process: general.
     single-process ARG:BOOLEAN;

     # Set wake-up interval.
     # *Note wakeup-interval: general.
     wakeup-interval TIME:STRING;

     # Set pid file name.
     # *Note pidfile: general.
     pidfile FILE:STRING;

     # Run with UID and GID of this user.
     # *Note user privileges::.
     user NAME:STRING;

     # Retain these supplementary groups:
     # *Note user privileges::.
     group ARG:LIST OF STRING;

     # Configure locking
     # *Note locking::.
     locking {
       # Enable or disable locking.
       enable ARG:BOOLEAN;

       # Set directory for lock files.
       directory DIR:STRING;

       # Define lock expiration interval.
       expire-time TIME:INTERVAL;

       # Locking timeout.
       timeout TIME:INTERVAL;
     }

     # Listen on this address.
     # *Note listen: daemon.
     listen SOCKET:SOCK-ADDR;

     # Configure TCP wrappers.
     # *Note tcp-wrapper::.
     tcp-wrapper {
       # Enable TCP wrapper access control. Default is `yes'.
       enable ARG:BOOLEAN;

       # Set daemon name for TCP wrapper lookups. Default is program name.
       daemon NAME:STRING;

       # Use FILE for positive client address access control.
       # (default: `/etc/hosts.allow').
       allow-table FILE:STRING;

       # Use FILE for negative client address access control.
       # (default: `/etc/hosts.deny').
       deny-table FILE:STRING;

       # Log host allows at this syslog priority.
       allow-syslog-priority PRIO:STRING;

       # Log host denies at this syslog priority.
       deny-syslog-priority PRIO:STRING;
     }

     # Set mailer URL.
     # *Note mailer::.
     mailer URL:STRING;

     # Set admin email address.
     # *Note admin-address: notification.
     admin-address EMAIL:STRING;

     # Set sender email address.
     # *Note from-address: notification.
     from-address EMAIL:STRING;

     # Define file sweep time.
     # *Note file-sweep-time: general.
     file-sweep-time TIME:INTERVAL;

     # Set tar invocation command line.
     # *Note tar-program: archivation.
     tar-program PROG:STRING;

     # Set umask.
     # *Note umask: general.
     umask MASK:OCTAL;

     # Control implicit signature archivation.
     # *Note archive-signatures: archivation.
     archive-signatures ARG:BOOLEAN;

     # Print these stats at the end of each run.
     # *Note statistics::.
     statistics ITEMS:STRING;

     # Service names that request scanning all spools.
     # *Note all-spools: daemon.
     all-spools ARG:LIST OF STRING;

     # GPG home directory.
     # *Note gpg-homedir::.
     gpg-homedir ARG:STRING;

     # Define SQL database.
     # *Note sql::.
     sql ID:STRING {
       # Set the name of the configuration file to read.
       config-file NAME:STRING;
       # Set the name of the configuration file group to use.
       config-group NAME:STRING;

       # Set SQL server hostname or IP address.
       host HOST:STRING;

       # Set database name.
       database DBNAME:STRING;

       # Set SQL user name.
       user NAME:STRING;

       # Set SQL user password.
       password ARG:STRING;

       # File name of the Certificate Authority (CA) certificate.
       ssl-ca FILE:STRING;
     }

     # Configure syslog logging.
     # *Note syslog::.
     syslog {
       # Set syslog facility.
       facility NAME:STRING;

       # Tag syslog messages with this string.
       tag STRING:STRING;

       # Prefix each message with its priority.
       print-priority ARG:BOOLEAN;
     }

     # Define message text.
     # *Note templates::.
     define-message IDENT:STRING TEXT:STRING;

     # Set up archivation.
     # *Note archivation::.
     archive TYPE:STRING {
       # Name of archive file or directory.
       name FILE-OR-DIR:STRING;

       # Define backup type.
       # *Note backup-methods::.
       backup TYPE:STRING;
     }

     # Send statistics.
     # *Note statreports::.
     mail-statistics {
       # Message text.
       message TEXT:STRING;

       # Send mail if one or more of these items are set.
       statistics ITEMS:STRING;

       # Sign message with this key.
       gpg-sign KEY:STRING;
     }

     # Configure notification.
     # *Note notification::.
     notify-event {
       # Event on which to notify.
       event EV-ID:STRING;

       # Notify this recipient.
       recipient WHO:STRING;

       # Text of the notification or identifier of
       # a defined message template.
       message TEXT-OR-ID:STRING;

       # Sign message with this key.
       gpg-sign KEY:STRING;
     }

     # Define data dictionary.
     # *Note dictionaries::.
     dictionary IDENT:STRING {
       # Dictionary type.
       type TYPE:STRING;

       # Query template.
       query STRING:STRING;

       # Set dictionary parameters.
       params ARG:LIST OF STRING;
     }

     # Define distribution spool.
     # *Note spool::.
     spool TAG:STRING {
       # URL corresponding to this spool.
       url ARG:STRING;

       # Aliases.
       alias ARG:LIST OF STRING;

       # Source directory.
       source DIR:STRING;

       # Destination directory.
       destination DIR:STRING;

       # Define file sweep time.
       file-sweep-time TIME:INTERVAL;

       # Define data dictionary.
       # See above.
       dictionary IDENT:STRING { ... }

       # Set up archivation.
       archive TYPE:STRING { ... }

       # Configure notification.
       notify-event { ... }
     }

6 `Wydawca' invocation summary.
*******************************

This chapter presents a short reference of all `wydawca' command line
options, in alphabetical order.

`--config-file=FILE'
`-c FILE'
     Use FILE instead of the default configuration file.

     *Note The `--config-file' option: config-file.

`--cron'
     Run in cron mode. *Note cron: starting.

     *Note The `--syslog' option: stderr.

`--debug'
`-d'
     Increase debugging level by 1.

     *Note The `--debug' option: debug.

`--define=NAME[=VALUE]'
`-DNAME[=VALUE]'
     Define the preprocessor symbol NAME as having VALUE, or empty.
     *Note Preprocessor::.

`--dump-grammar-trace'
     Dump configuration grammar traces. This is useful for debugging
     `wydawca' configuration file parser.

`--dump-lex-trace'
     Dump lexical analyzer traces. This is useful for debugging
     `wydawca' configuration file parser.

`--dry-run'
`-n'
     "Dry-run mode": do nothing, print almost everything. This option
     implies `--debug --stderr'.

     *Note The dry-run mode: dry-run.

`--stderr'
`-e'
     Log to the standard error.

     *Note The `--stderr' option: stderr.

`--spool=TAG'
`-S TAG'
     Process only spool with the given tag. *Note spool selection::.

`--source=DIR'
`-s DIR'
     Process only spool with DIR as the source directory.  *Note spool
     selection::.

`--syslog'
     Log all diagnostics to syslog.

     *Note The `--syslog' option: stderr.

`--force'
     Force start-up, even if if the PID file already exists.

`--foreground'
     Remain in the foreground. This is mostly for debugging `wydawca'.

`--include-directory=DIR'
`-I DIR'
     Add DIR to include search path.

     *Note #include: Pragmatic Comments. *Note Preprocessor::.

`--lint'
`-t'
     Parse configuration file, report any errors on the standard error
     and exit with code 0, if the syntax is OK, and with code 1
     otherwise.

     *Note The `--lint' option: lint.

`--no-preprocessor'
     Disable preprocessor. *note Preprocessor::.

`--preprocessor=COMMAND'
     Use COMMAND instead of the default preprocessor. *note
     Preprocessor::.

`--single-process'
     Serialize job invocations by not forking subprocesses for each job.
     _Do not use this option in production environment_.

`--source=NAME'
`-sNAME'
     Process only the spool with the given source name. This option may
     be given multiple times, to select several spools by their source
     names.

`--spool=TAG'
`-STAG'
     Process only spool with the given tag. This option may be given
     multiple times, to select several spools by their tag names.

`--help'
`-h'
     Print a concise usage summary and exit.

`--version'
`-v'
     Print the program version and exit.

7 How to Report a Bug
*********************

Email bug reports to <bug-wydawca@gnu.org.ua>.

   As the purpose of bug reporting is to improve software, please be
sure to include a detailed information when reporting a bug. The minimum
information needed is:

   * Program version you use (see the output of `wydawca --version'.

   * A description of the bug.

   * Conditions under which the bug appears.

   * It is often helpful to send the contents of `config.log' file
     along with your bug report. This file is created after running
     `./configure' in `wydawca' source root directory.

Appendix A GNU Free Documentation License
*****************************************

                      Version 1.2, November 2002

     Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
     51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA

     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

  0. PREAMBLE

     The purpose of this License is to make a manual, textbook, or other
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.

     This License is a kind of "copyleft", which means that derivative
     works of the document must themselves be free in the same sense. It
     complements the GNU General Public License, which is a copyleft
     license designed for free software.

     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does. But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book. We
     recommend this License principally for works whose purpose is
     instruction or reference.

  1. APPLICABILITY AND DEFINITIONS

     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it
     can be distributed under the terms of this License. Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein. The
     "Document", below, refers to any such manual or work. Any member
     of the public is a licensee, and is addressed as "you". You accept
     the license if you copy, modify or distribute the work in a way
     requiring permission under copyright law.

     A "Modified Version" of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.

     A "Secondary Section" is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.

     The "Invariant Sections" are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in
     the notice that says that the Document is released under this
     License. If a section does not fit the above definition of
     Secondary then it is not allowed to be designated as Invariant.
     The Document may contain zero Invariant Sections. If the Document
     does not identify any Invariant Sections then there are none.

     The "Cover Texts" are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License. A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.

     A "Transparent" copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images
     composed of pixels) generic paint programs or (for drawings) some
     widely available drawing editor, and that is suitable for input to
     text formatters or for automatic translation to a variety of
     formats suitable for input to text formatters. A copy made in an
     otherwise Transparent file format whose markup, or absence of
     markup, has been arranged to thwart or discourage subsequent
     modification by readers is not Transparent.  An image format is
     not Transparent if used for any substantial amount of text. A copy
     that is not "Transparent" is called "Opaque".

     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and
     standard-conforming simple HTML, PostScript or PDF designed for
     human modification. Examples of transparent image formats include
     PNG, XCF and JPG. Opaque formats include proprietary formats that
     can be read and edited only by proprietary word processors, SGML or
     XML for which the DTD and/or processing tools are not generally
     available, and the machine-generated HTML, PostScript or PDF
     produced by some word processors for output purposes only.

     The "Title Page" means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page. For
     works in formats which do not have any title page as such, "Title
     Page" means the text near the most prominent appearance of the
     work's title, preceding the beginning of the body of the text.

     A section "Entitled XYZ" means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
     To "Preserve the Title" of such a section when you modify the
     Document means that it remains a section "Entitled XYZ" according
     to this definition.

     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document. These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.

  2. VERBATIM COPYING

     You may copy and distribute the Document in any medium, either
     commercially or noncommercially, provided that this License, the
     copyright notices, and the license notice saying this License
     applies to the Document are reproduced in all copies, and that you
     add no other conditions whatsoever to those of this License. You
     may not use technical measures to obstruct or control the reading
     or further copying of the copies you make or distribute. However,
     you may accept compensation in exchange for copies. If you
     distribute a large enough number of copies you must also follow
     the conditions in section 3.

     You may also lend copies, under the same conditions stated above,
     and you may publicly display copies.

  3. COPYING IN QUANTITY

     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document's license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover. Both covers must also clearly
     and legibly identify you as the publisher of these copies. The
     front cover must present the full title with all words of the
     title equally prominent and visible. You may add other material on
     the covers in addition.  Copying with changes limited to the
     covers, as long as they preserve the title of the Document and
     satisfy these conditions, can be treated as verbatim copying in
     other respects.

     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.

     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a
     machine-readable Transparent copy along with each Opaque copy, or
     state in or with each Opaque copy a computer-network location from
     which the general network-using public has access to download
     using public-standard network protocols a complete Transparent
     copy of the Document, free of added material.  If you use the
     latter option, you must take reasonably prudent steps, when you
     begin distribution of Opaque copies in quantity, to ensure that
     this Transparent copy will remain thus accessible at the stated
     location until at least one year after the last time you
     distribute an Opaque copy (directly or through your agents or
     retailers) of that edition to the public.

     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of
     copies, to give them a chance to provide you with an updated
     version of the Document.

  4. MODIFICATIONS

     You may copy and distribute a Modified Version of the Document
     under the conditions of sections 2 and 3 above, provided that you
     release the Modified Version under precisely this License, with
     the Modified Version filling the role of the Document, thus
     licensing distribution and modification of the Modified Version to
     whoever possesses a copy of it. In addition, you must do these
     things in the Modified Version:

       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of
          previous versions (which should, if there were any, be listed
          in the History section of the Document). You may use the same
          title as a previous version if the original publisher of that
          version gives permission.

       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.

       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.

       D. Preserve all the copyright notices of the Document.

       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.

       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.

       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document's
          license notice.

       H. Include an unaltered copy of this License.

       I. Preserve the section Entitled "History", Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on
          the Title Page. If there is no section Entitled "History" in
          the Document, create one stating the title, year, authors,
          and publisher of the Document as given on its Title Page,
          then add an item describing the Modified Version as stated in
          the previous sentence.

       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on. These may be placed in the
          "History" section.  You may omit a network location for a
          work that was published at least four years before the
          Document itself, or if the original publisher of the version
          it refers to gives permission.

       K. For any section Entitled "Acknowledgements" or "Dedications",
          Preserve the Title of the section, and preserve in the
          section all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.

       L. Preserve all the Invariant Sections of the Document,
          unaltered in their text and in their titles. Section numbers
          or the equivalent are not considered part of the section
          titles.

       M. Delete any section Entitled "Endorsements". Such a section
          may not be included in the Modified Version.

       N. Do not retitle any existing section to be Entitled
          "Endorsements" or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     If the Modified Version includes new front-matter sections or
     appendices that qualify as Secondary Sections and contain no
     material copied from the Document, you may at your option
     designate some or all of these sections as invariant. To do this,
     add their titles to the list of Invariant Sections in the Modified
     Version's license notice.  These titles must be distinct from any
     other section titles.

     You may add a section Entitled "Endorsements", provided it contains
     nothing but endorsements of your Modified Version by various
     parties--for example, statements of peer review or that the text
     has been approved by an organization as the authoritative
     definition of a standard.

     You may add a passage of up to five words as a Front-Cover Text,
     and a passage of up to 25 words as a Back-Cover Text, to the end
     of the list of Cover Texts in the Modified Version. Only one
     passage of Front-Cover Text and one of Back-Cover Text may be
     added by (or through arrangements made by) any one entity. If the
     Document already includes a cover text for the same cover,
     previously added by you or by arrangement made by the same entity
     you are acting on behalf of, you may not add another; but you may
     replace the old one, on explicit permission from the previous
     publisher that added the old one.

     The author(s) and publisher(s) of the Document do not by this
     License give permission to use their names for publicity for or to
     assert or imply endorsement of any Modified Version.

  5. COMBINING DOCUMENTS

     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination
     all of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.

     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy. If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.

     In the combination, you must combine any sections Entitled
     "History" in the various original documents, forming one section
     Entitled "History"; likewise combine any sections Entitled
     "Acknowledgements", and any sections Entitled "Dedications". You
     must delete all sections Entitled "Endorsements."

  6. COLLECTIONS OF DOCUMENTS

     You may make a collection consisting of the Document and other
     documents released under this License, and replace the individual
     copies of this License in the various documents with a single copy
     that is included in the collection, provided that you follow the
     rules of this License for verbatim copying of each of the
     documents in all other respects.

     You may extract a single document from such a collection, and
     distribute it individually under this License, provided you insert
     a copy of this License into the extracted document, and follow
     this License in all other respects regarding verbatim copying of
     that document.

  7. AGGREGATION WITH INDEPENDENT WORKS

     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of
     a storage or distribution medium, is called an "aggregate" if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation's users beyond what the individual
     works permit.  When the Document is included an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.

     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document's Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.

  8. TRANSLATION

     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections. You may include a
     translation of this License, and all the license notices in the
     Document, and any Warranty Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers. In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.

     If a section in the Document is Entitled "Acknowledgements",
     "Dedications", or "History", the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.

  9. TERMINATION

     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided for under this License. Any other
     attempt to copy, modify, sublicense or distribute the Document is
     void, and will automatically terminate your rights under this
     License. However, parties who have received copies, or rights,
     from you under this License will not have their licenses
     terminated so long as such parties remain in full compliance.

 10. FUTURE REVISIONS OF THIS LICENSE

     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time. Such new
     versions will be similar in spirit to the present version, but may
     differ in detail to address new problems or concerns. See
     `http://www.gnu.org/copyleft/'.

     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License "or any later version" applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation. If the
     Document does not specify a version number of this License, you
     may choose any version ever published (not as a draft) by the Free
     Software Foundation.

A.1 ADDENDUM: How to use this License for your documents
========================================================

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.2
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
       A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

   If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:

         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.

   If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

   If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.

Concept Index
*************

This is a general index of all issues discussed in this manual

#include:                                      See 4.1.2.    (line  341)
#include_once:                                 See 4.1.2.    (line  361)
#line:                                         See 4.1.2.    (line  366)
/etc/hosts.allow:                              See 4.5.      (line  731)
/etc/services:                                 See 4.4.      (line  671)
access-violations, statistics:                 See 4.13.     (line 1514)
admin:                                         See 4.14.4.   (line 1891)
admin-address:                                 See 4.14.     (line 1601)
alias:                                         See 4.11.     (line 1304)
all, statistics:                               See 4.13.     (line 1569)
all-spools:                                    See 4.4.      (line  684)
allow-syslog-priority:                         See 4.5.      (line  740)
allow-table:                                   See 4.5.      (line  732)
archivation methods:                           See 4.10.     (line 1167)
archivation, defined:                          See 4.10.     (line 1160)
archive <1>:                                   See 4.11.     (line 1336)
archive:                                       See 4.10.     (line 1167)
archive-signatures:                            See 4.10.     (line 1272)
archives, statistics:                          See 4.13.     (line 1541)
authpriv, syslog facility:                     See 4.7.      (line  801)
backup:                                        See 4.10.     (line 1239)
bad-detached-signature:                        See 4.14.4.   (line 1874)
bad-directive-signature:                       See 4.14.4.   (line 1870)
bad-ownership:                                 See 4.14.4.   (line 1866)
bad-signatures, statistics:                    See 4.13.     (line 1510)
bad-triplets, statistics:                      See 4.13.     (line 1527)
block statement:                               See 4.1.3.    (line  558)
boolean value:                                 See 4.1.3.    (line  403)
builtin:                                       See 4.9.      (line  960)
builtin dictionary:                            See 4.9.2.    (line 1071)
c, -c short option, described:                 See 3.        (line  208)
check-failure:                                 See 4.14.4.   (line 1878)
check-script:                                  See 4.12.     (line 1391)
check:diagn:                                   See 4.14.4.   (line 1962)
check:result:                                  See 4.14.4.   (line 1960)
command line options:                          See 6.        (line 2274)
comment:                                       See 4.9.      (line 1009)
Comments in a configuration file:              See 4.1.1.    (line  317)
comments, pragmatic:                           See 4.1.2.    (line  335)
complete-triplets, statistics:                 See 4.13.     (line 1518)
config-file:                                   See 4.8.      (line  844)
config-file, --config-file option, described:  See 3.        (line  208)
config-file, --config-file option, summary:    See 6.        (line 2277)
config-group:                                  See 4.8.      (line  847)
config-help, --config-help option, introduced: See 4.        (line  299)
configuration file statements:                 See 4.1.3.    (line  384)
configuration statements, reference:           See 5.        (line 2032)
cron mode:                                     See 2.1.      (line  171)
cron, --cron option, described:                See 3.        (line  229)
cron, --cron option, summary:                  See 6.        (line 2283)
cron, syslog facility:                         See 4.7.      (line  801)
d, -d short option, described:                 See 3.        (line  251)
D, -D short option, introduced:                See 4.1.4.    (line  599)
daemon <1>:                                    See 4.5.      (line  727)
daemon:                                        See 4.4.      (line  666)
daemon mode:                                   See 2.1.      (line  177)
daemon, syslog facility:                       See 4.7.      (line  801)
database:                                      See 4.8.      (line  888)
database, MySQL:                               See 4.8.      (line  821)
database, SQL:                                 See 4.8.      (line  821)
date:                                          See 4.14.3.   (line 1776)
debug, --debug option, described:              See 3.        (line  251)
debug, --debug option, summary:                See 6.        (line 2288)
define, --define option, introduced:           See 4.1.4.    (line  599)
define, --define option, summary:              See 6.        (line 2294)
define-message:                                See 4.14.2.   (line 1710)
defining source and distribution directories:  See 4.11.     (line 1280)
deny-syslog-priority:                          See 4.5.      (line  743)
deny-table:                                    See 4.5.      (line  736)
dest-dir:                                      See 4.14.4.   (line 1938)
destination:                                   See 4.11.     (line 1315)
destination directory:                         See 2.        (line  122)
detached signature <1>:                        See 2.        (line  158)
detached signature:                            See 1.        (line   85)
dictionaries:                                  See 4.9.      (line  923)
dictionary <1>:                                See 4.11.     (line 1340)
dictionary <2>:                                See 4.9.      (line  931)
dictionary:                                    See 2.        (line  148)
dir:                                           See 4.14.4.   (line 1937)
directory:                                     See 4.6.      (line  769)
directory, archivation:                        See 4.10.     (line 1187)
directory, destination:                        See 2.        (line  122)
directory, distribution:                       See 2.        (line  122)
directory, source <1>:                         See 2.        (line  122)
directory, source:                             See 1.        (line   75)
directory, upload:                             See 2.        (line  122)
distribution directory:                        See 2.        (line  122)
distribution directory, defining:              See 4.11.     (line 1280)
distribution spool:                            See 4.11.     (line 1280)
distribution verification:                     See 4.12.     (line 1384)
dry-run, --dry-run option, described:          See 3.        (line  261)
dry-run, --dry-run option, summary:            See 6.        (line 2307)
dump-grammar-trace, --dump-grammar-trace option, summary:See 6.
                                                             (line 2299)
dump-lex-trace, --dump-lex-trace option, summary:See 6.      (line 2303)
e, -e short option, described:                 See 3.        (line  219)
E, -E short option, introduced:                See 4.        (line  294)
email:admin:                                   See 4.14.4.   (line 1954)
email:owner:                                   See 4.14.4.   (line 1955)
email:user:                                    See 4.14.4.   (line 1958)
enable <1>:                                    See 4.6.      (line  766)
enable:                                        See 4.5.      (line  724)
errors, statistics:                            See 4.13.     (line 1504)
escape sequence:                               See 4.1.3.    (line  411)
event:                                         See 4.14.4.   (line 1860)
event notification:                            See 4.14.4.   (line 1844)
existing, backup method:                       See 4.10.     (line 1252)
expire-time:                                   See 4.6.      (line  775)
expired triplet:                               See 2.        (line  141)
expired-triplets, statistics:                  See 4.13.     (line 1530)
external:                                      See 4.9.      (line  967)
external dictionary:                           See 4.9.3.    (line 1155)
facility:                                      See 4.7.      (line  801)
FDL, GNU Free Documentation License:           See Appendix A.
                                                             (line 2406)
file-sweep-time <1>:                           See 4.11.     (line 1344)
file-sweep-time:                               See 4.2.      (line  632)
force, --force option, summary:                See 6.        (line 2334)
foreground:                                    See 4.2.      (line  618)
foreground, --foreground option, summary:      See 6.        (line 2337)
from-address:                                  See 4.14.     (line 1591)
ftp, syslog facility:                          See 4.7.      (line  801)
gpg-homedir:                                   See 4.2.      (line  640)
gpg-sign <1>:                                  See 4.14.4.   (line 1909)
gpg-sign:                                      See 4.14.3.   (line 1767)
group:                                         See 4.3.      (line  655)
h, -h short option, described:                 See 3.        (line  272)
help, --help option, described:                See 3.        (line  272)
help, --help option, summary:                  See 6.        (line 2376)
here-document:                                 See 4.1.3.    (line  487)
host:                                          See 4.8.      (line  881)
I, -I short option, introduced:                See 4.1.4.    (line  603)
implicit signature archivation:                See 4.10.     (line 1262)
include-directory, --include-directory option, introduced:See 4.1.4.
                                                             (line  603)
include-directory, --include-directory option, summary:See 6.
                                                             (line 2340)
incomplete triplet:                            See 2.        (line  141)
incomplete-triplets, statistics:               See 4.13.     (line 1521)
introduction:                                  See 1.        (line   69)
invocation <1>:                                See 6.        (line 2274)
invocation:                                    See 3.        (line  208)
lint, --lint option, described:                See 3.        (line  214)
lint, --lint option, introduced:               See 4.        (line  288)
lint, --lint option, summary:                  See 6.        (line 2346)
list:                                          See 4.1.3.    (line  527)
listen:                                        See 4.4.      (line  669)
listing, triplet:                              See 4.14.4.   (line 1982)
local0 through local7, syslog facilities:      See 4.7.      (line  801)
locking:                                       See 4.6.      (line  758)
m4:                                            See 4.1.4.    (line  573)
mail notification:                             See 4.14.     (line 1580)
mail, syslog facility:                         See 4.7.      (line  801)
mail-statistics:                               See 4.14.3.   (line 1738)
mailer:                                        See 4.14.1.   (line 1620)
mailer URL:                                    See 4.14.1.   (line 1626)
message <1>:                                   See 4.14.4.   (line 1886)
message:                                       See 4.14.3.   (line 1748)
message template:                              See 4.14.2.   (line 1703)
meta-interpretation:                           See 4.1.3.    (line  450)
meta-variables:                                See 4.1.3.    (line  450)
meta-variables in admin notifications:         See 4.14.3.   (line 1774)
multi-line comments:                           See 4.1.1.    (line  325)
MySQL databases:                               See 4.8.      (line  821)
n, -n short option, described:                 See 3.        (line  261)
name:                                          See 4.10.     (line 1191)
never, backup method:                          See 4.10.     (line 1257)
nil, backup method:                            See 4.10.     (line 1252)
no-preprocessor, --no-preprocessor option, defined:See 4.1.4.
                                                             (line  608)
no-preprocessor, --no-preprocessor option, introduced:See 4. (line  294)
no-preprocessor, --no-preprocessor option, summary:See 6.    (line 2354)
none, archivation:                             See 4.10.     (line 1181)
none, statistics:                              See 4.13.     (line 1564)
notification message template:                 See 4.14.2.   (line 1703)
notify-event <1>:                              See 4.14.4.   (line 1852)
notify-event:                                  See 4.11.     (line 1350)
numbered, backup method:                       See 4.10.     (line 1248)
operation:                                     See 2.        (line  114)
operation mode:                                See 2.1.      (line  169)
overview:                                      See 2.        (line  114)
owner:                                         See 4.14.4.   (line 1895)
p:                                             See 4.9.      (line  978)
params:                                        See 4.9.      (line 1013)
password:                                      See 4.8.      (line  894)
PGP <1>:                                       See 2.        (line  148)
PGP:                                           See 1.        (line   85)
PGP key:                                       See 4.9.      (line  923)
PGP signature:                                 See 4.13.     (line 1511)
pidfile:                                       See 4.4.      (line  697)
pp-setup:                                      See 4.1.4.    (line  584)
pragmatic comments:                            See 4.1.2.    (line  335)
preprocessor:                                  See 4.1.4.    (line  573)
preprocessor, --preprocessor option, defined:  See 4.1.4.    (line  611)
preprocessor, --preprocessor option, summary:  See 6.        (line 2357)
print-priority:                                See 4.7.      (line  812)
project <1>:                                   See 4.14.4.   (line 1933)
project:                                       See 4.9.      (line  978)
project-owner <1>:                             See 4.9.1.1.  (line 1035)
project-owner:                                 See 4.9.      (line  945)
project-uploader:                              See 4.9.      (line  951)
project-uploader-sql:                          See 4.9.1.2.  (line 1053)
query:                                         See 4.9.      (line  974)
quoted string:                                 See 4.1.3.    (line  411)
read:                                          See 4.14.4.   (line 1886)
recipient:                                     See 4.14.4.   (line 1883)
release submission daemon:                     See 1.        (line   94)
rmsymlinks, statistics:                        See 4.13.     (line 1547)
Savane:                                        See 4.9.1.    (line 1028)
signature files, archivation:                  See 4.10.     (line 1262)
signature, detached <1>:                       See 2.        (line  158)
signature, detached:                           See 1.        (line   85)
simple statements:                             See 4.1.3.    (line  384)
simple, backup method:                         See 4.10.     (line 1257)
single-line comments:                          See 4.1.1.    (line  317)
single-process:                                See 4.2.      (line  621)
single-process, --single-process option, summary:See 6.      (line 2361)
source:                                        See 4.11.     (line 1312)
source directory <1>:                          See 2.        (line  122)
source directory:                              See 1.        (line   75)
source directory, defining:                    See 4.11.     (line 1280)
source, --source option, summary:              See 6.        (line 2365)
source-dir:                                    See 4.14.4.   (line 1940)
spool <1>:                                     See 4.14.4.   (line 1936)
spool <2>:                                     See 4.11.     (line 1288)
spool:                                         See 2.        (line  122)
spool, --spool option, described:              See 3.        (line  239)
spool, --spool option, summary:                See 6.        (line 2320)
sql <1>:                                       See 4.9.      (line  963)
sql:                                           See 4.8.      (line  829)
SQL databases:                                 See 4.8.      (line  821)
sql dictionary:                                See 4.9.1.    (line 1018)
ssl-ca:                                        See 4.8.      (line  897)
stat:access_violations:                        See 4.14.3.   (line 1781)
stat:archives:                                 See 4.14.3.   (line 1789)
stat:bad_signatures:                           See 4.14.3.   (line 1780)
stat:bad_triplets:                             See 4.14.3.   (line 1784)
stat:check-failures:                           See 4.14.3.   (line 1792)
stat:complete_triplets:                        See 4.14.3.   (line 1782)
stat:errors:                                   See 4.14.3.   (line 1778)
stat:expired_triplets:                         See 4.14.3.   (line 1786)
stat:incomplete_triplets:                      See 4.14.3.   (line 1783)
stat:rmsymlinks:                               See 4.14.3.   (line 1791)
stat:symlinks:                                 See 4.14.3.   (line 1790)
stat:triplet_success:                          See 4.14.3.   (line 1787)
stat:uploads:                                  See 4.14.3.   (line 1788)
stat:warnings:                                 See 4.14.3.   (line 1779)
statement, block:                              See 4.1.3.    (line  558)
statement, simple:                             See 4.1.3.    (line  384)
statements, configuration file:                See 4.1.3.    (line  384)
statistics <1>:                                See 4.14.3.   (line 1757)
statistics:                                    See 4.13.     (line 1481)
stderr, --stderr option, described:            See 3.        (line  219)
stderr, --stderr option, summary:              See 6.        (line 2314)
string, quoted:                                See 4.1.3.    (line  411)
string, unquoted:                              See 4.1.3.    (line  407)
success:                                       See 4.14.4.   (line 1863)
symlinks, statistics:                          See 4.13.     (line 1544)
syslog:                                        See 4.7.      (line  794)
syslog priority, printing in diagnostics:      See 4.7.      (line  812)
syslog tag, configuring:                       See 4.7.      (line  807)
syslog, --syslog option, described:            See 3.        (line  219)
syslog, --syslog option, summary:              See 6.        (line 2283)
syslog, configuration:                         See 4.7.      (line  789)
t, -t short option, described:                 See 3.        (line  214)
t, backup method:                              See 4.10.     (line 1248)
tag:                                           See 4.7.      (line  807)
tar, archivation:                              See 4.10.     (line 1184)
tar-program:                                   See 4.10.     (line 1208)
tcp-wrapper:                                   See 4.5.      (line  711)
templates, notification messages:              See 4.14.2.   (line 1703)
Time Interval Specification:                   See 4.1.3.    (line  544)
timeout:                                       See 4.6.      (line  781)
timer:spool:real:                              See 4.14.4.   (line 1977)
timer:spool:system:                            See 4.14.4.   (line 1978)
timer:spool:user:                              See 4.14.4.   (line 1979)
timer:TAG:real:                                See 4.14.3.   (line 1801)
timer:TAG:system:                              See 4.14.3.   (line 1802)
timer:TAG:user:                                See 4.14.3.   (line 1803)
timer:triplet:real:                            See 4.14.4.   (line 1974)
timer:triplet:system:                          See 4.14.4.   (line 1975)
timer:triplet:user:                            See 4.14.4.   (line 1976)
timer:wydawca:real <1>:                        See 4.14.4.   (line 1970)
timer:wydawca:real:                            See 4.14.3.   (line 1799)
timer:wydawca:system <1>:                      See 4.14.4.   (line 1972)
timer:wydawca:system:                          See 4.14.3.   (line 1799)
timer:wydawca:user <1>:                        See 4.14.4.   (line 1973)
timer:wydawca:user:                            See 4.14.3.   (line 1800)
timers <1>:                                    See 4.14.4.   (line 1968)
timers:                                        See 4.14.3.   (line 1796)
triplet listing:                               See 4.14.4.   (line 1982)
triplet, expired:                              See 2.        (line  141)
triplet, incomplete:                           See 2.        (line  141)
triplet-success, statistics:                   See 4.13.     (line 1533)
triplet:dir:                                   See 4.14.4.   (line 1943)
triplet:dist:                                  See 4.14.4.   (line 1941)
triplet:ls:dir:                                See 4.14.4.   (line 1948)
triplet:ls:full:                               See 4.14.4.   (line 1944)
triplet:ls:sig:                                See 4.14.4.   (line 1947)
triplet:ls:upload:                             See 4.14.4.   (line 1945)
triplet:sig:                                   See 4.14.4.   (line 1942)
type:                                          See 4.9.      (line  958)
u:                                             See 4.9.      (line 1003)
umask:                                         See 4.2.      (line  629)
upload directory:                              See 2.        (line  122)
upload site:                                   See 1.        (line   75)
uploads, statistics:                           See 4.13.     (line 1536)
url <1>:                                       See 4.14.4.   (line 1935)
url:                                           See 4.11.     (line 1308)
URL, mailer:                                   See 4.14.1.   (line 1626)
user <1>:                                      See 4.14.4.   (line 1900)
user <2>:                                      See 4.9.      (line 1003)
user <3>:                                      See 4.8.      (line  891)
user:                                          See 4.3.      (line  652)
user:email:                                    See 4.14.4.   (line 1953)
user:name:                                     See 4.14.4.   (line 1951)
user:real-name:                                See 4.14.4.   (line 1952)
v, -v short option, described:                 See 3.        (line  272)
verification:                                  See 4.12.     (line 1384)
version, --version option, described:          See 3.        (line  272)
version, --version option, summary:            See 6.        (line 2380)
version-control Emacs variable:                See 4.10.     (line 1239)
wakeup-interval:                               See 4.4.      (line  688)
warnings, statistics:                          See 4.13.     (line 1507)
WYDAWCA_DEST:                                  See 4.12.     (line 1405)
WYDAWCA_DIST_FILE:                             See 4.12.     (line 1414)
WYDAWCA_SOURCE:                                See 4.12.     (line 1401)
WYDAWCA_SPOOL:                                 See 4.12.     (line 1398)
WYDAWCA_TRIPLET_BASE:                          See 4.12.     (line 1411)
WYDAWCA_URL:                                   See 4.12.     (line 1408)