![[image of the Head of a GNU]](/graphics/gnu-head-sm.jpg)
|
|
Wydawca |
Release Submission Daemon |
Sergey Poznyakoff |
Wydawca (split by chapter): 
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 supplies also 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 contains instructions 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 directives3.
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 (see file-sweep-time). 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 searches in the project
dictionary for 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.
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. It watches for
the incoming uploads using one or both of the following methods.
On modern GNU/Linux systems wydawca uses inotify API
(see monitoring file system events in inotify man page),
which enables it to react on each upload immediately after a
complete triplet is uploaded and to clean up unfinished or incomplete
uploads. This is a preferred mode of operation.
On other systems, the daemon can be configured to listen on a socket for upload notifications. This method can also be used together with inotify, should the need be. This feature uses the TCPMUX protocol4 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 login name of the user who did the upload5. 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 in the given spool.
The user name requirement is retained for backward compatibility. In fact, it is not used, so that any word can be sent instead.
Wydawca (split by chapter):
This document was generated on January 6, 2021 using makeinfo.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.