Wydawca (split by chapter):   Section:   Chapter:FastBack: Intro   Up: Top   FastForward: starting   Contents: Table of ContentsIndex: Concept Index

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

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



Standalone directives.


RFC 1078.


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):   Section:   Chapter:FastBack: overview   Up: overview   FastForward: starting   Contents: Table of ContentsIndex: Concept Index