Python Programming Language

Home Search Download Documentation
Help News Community SIGs
Special interest groups
About SIGs
Retired SIGs
SIG creation
For SIG coordinators
Email Us
[email protected]

SIG Coordinator Resource Guide

Each PSA SIG coordinator has at their disposal:

These resources are available on, under the name of the SIG. The SIG coordinator has remote control of them, with email- and web-mediated administrative authority of the mailing list, and special group privileges, invocable within anonymous-ftp, to control the contents of the sig directory. Both facilities are keyed on a single password, which is assigned to the SIG coordinator.

Mailman controls

Using the SIG password, the coordinator can administer most attributes of the sig maillist, including the subscribership. To change list options, visit:<sig-name>

To change a subscriber's options, visit the listinfo page for the sig:<sig-name>

and click on or enter the user's address to go to the options page for the user. You can then us the list administrators password to authorize option changes or unsubscription of the user.

Finally, the list administrative db:<sig-name>

contains the current set of requests, if any, pending administrative judgement and decision. Web Documents and The .ht Template File

The SIG password also enables the SIG coordinator to change the contents of their SIG web directory via anonymous ftp. The following describes the organization and formatting considerations of the web pages, and the procedure to upload and otherwise change the contents of the web directory. Web Documents Organization and Formatting

The web pages are located at While it's nice to be able to delegate authoring of pages to people outside the site, those people need to keep in mind a couple of constraints on the format of their pages:

  • The pages are mirrored at other sites
  • We maintain a regular page layout, via a preprocessing arrangement

The mirroring requires that all links going from one page to another within the web site not presume anything about the location of the root of the hierarchy. That is, they should be relative links, strictly within the hierarchy.

The regular page layout entails producing your pages as template files, rather than regular html. (We conventionally qualify the template files with ".ht", instead of ".html".) It also requires processing your files after you've uploaded them to the host, which is provide for with an exported make command, as described below.

The tempate file which you produce is basically html, but with the document header and footer mostly excluded. The standard header and footer are incorporated by processing your template file with a local utility, to produce the corresponding, regularly formatted ".html" result. This utility puts on the header and footer, including things like a handy-dandy quick-jump bar, link and border colors which indicate the category of the page (general vs psa vs documentation), and so forth - all using relative URL paths, so their integrity is preserved on the mirror sites.

The relative links situation should be fairly self explanatory - examine the source of some existing documents in the mainstream of the hierarchy for examples. To construct your own .ht files, see the Python Web Maintenance document, particularly the section concerning the template format, for details.

The following topics describe how to gain access privileges to upload your documents to your SIG directory, and to run the procedure to produce .html documents from .ht ones.

SIG Web Directory Controls

Using the SIG password, the coordinator can change the contents of their web directory via anonymous ftp. The arrangement entails use of anonymous ftp groups, together with a batch-processing mechanism. Below are detailed instructions.

Getting Group Access Privileges
Do an anonymous ftp login to
Change directories to your sigs dir - i'll use the progenv-sig for example:
ftp> cd /pub/
250 CWD command successful.

Invoke the group access, in two steps:

Specify the group:

ftp> quote site group progenvsig
200 Request for group progenvsig accepted.

(Note that you use the SIG name excluding the '-' dash.)

Specify the password:

ftp> quote site gpass progenv-sig-password 200 Request for access to group progenvsig accepted.

(Note that a successful GROUP command must come immediately before a successful GPASS command - so you must redo the GROUP command if you do an unsuccessful GPASS, and need to reattempt it.

The anonymous-ftp group privileges enables you to upload to the SIG directory. However, you are not able to overwrite anything - you have to use a special site-exec command, sigjob, to remove existing files, first, and then you can do a regular ftp put to put your new version in place. This command, described below, also enables you to process .ht template files, converting them to site-conformant .html files.

The sigjob Command

The sigjob site command is necessary for a few reasons.

  • We need a safe way to provide overwrite and deletion capability, and the anonymous ftp mechanism is not sufficient.
  • We need to make the mechanism for processing the standardized web page format (see above) externally available.

quote site exec sigjob <command> [<args>]
Puts the command on a job queue. The command is executed in your SIG directory, and the results are registered in a log file in the directory, named .done.
quote site exec sigjoblog [num]
Show the current contents of the log file, or the last num lines, when specified.

The sigs jobs daemon checks for and processes jobs immediately, but asynchronously, so the results will show up in the log file shortly after your submission of the command returns.

There is a small set of sigjob commands currently available.

quote site exec sigjob make [html-files]
Convert any fresh .ht files to their corresponding html equivalent. Without any arguments, processes all .ht files newer than their .html versions.

quote site exec sigjob rm files
Get the specified files out of your SIG dir - typically, so you can put new ones in their place. (The anonymous ftp group permissions do not enable you to overwrite existing files. Once the file is out of the way, however, you can do a regular ftp put to put your new version in place.)

The files are not actually deleted - they are put in a "trashcan" so we can recover them, even if they didn't exist before the last (daily) system backup.

quote site exec sigjob echo stuff and whatnot
Echo a line into the log file, so you can see that the process is really happening. (See the sigjoblog command, above, for the means to review the log file.)

quote site exec sigjob purge-log
Reinit the jobs log file, to empty it out.

The sigjobs daemon is watching the jobs queue continuously, so you should see results from your commands fairly immediately - use the sigjoblog site command to check the log for results.

This system is growing. Please send suggestions and questions to [email protected].