# cd /u
# for X in httpd papyrus sample
> do
> find ~$X -exec chown $X {} \;
> find ~$X -exec chgrp papyrus {} \;
> find ~$X -exec chmod 0770 {} \;
> done
The group permissions provide
a minimum level of protection to the system,
as explained in the next section.
Controlling damage from program bugs is another important consideration. Unfortunately, the user/group protection scheme is only good for confining damage within the whole group. If you have afs set up, you might want to set up ACLs appropriately to prevent conference A's invocations from damaging B's directories.
The scripts run.sh and stop.sh are useful for bringing up or shutting down the httpd processes individually. Stop.sh greps the right httpd line from ps -ef output. The other way to bring up the server processes is to insert the following lines into /etc/inittab:
httpd:2:respawn:/usr/httpd/bin/httpd -r /usr/papyrus/etc/root sample:2:once:/usr/papyrus/etc/run.sh sampleand type
# init q
Papyrus uses a third set of processes, one per conference, to overcome a peculiar problem. By default, the httpd server waits for every descendent process to complete before responding to the client. Some operations, such as paper ranking, however take a sufficiently long time in the current implementation to justify an asynchronous return to the user. The only way to do this is to delegate the asynchronous operations to an independent process group, by communicating the necessary commands to an independently initiated pipe shell process.
I used npsh, short for netpipe shell, with ports 8199, 8299 etc for this purpose, invoked by hand under the papyrus user id:
$ (npsh 8399 &)The netpipes were a quick solution at the time of PACT'96. For better security, it is preferable to use local IPC or Unix domain sockets:
$ (upsh ~sample/log/pipe &)where upsh is short for Unix pipe shell. The BKGND variable must be correspondingly defined accordingly in the conference configuration file ~sample/etc/config.
I preferred a slightly different approach for two reasons. First, while www.pact96.ibm.com is visible from outside the corporate firewall, not all internal routers are aware of this host. This means the machine is inaccessible to many via email, including myself. We therefore used an outside site, pact96@cs.colostate.edu, to forward mail to our machine, and it appeared impractical to create multiple forwarding accounts on the outside site. Similar "routing problems" could arise at other installations. Second, people often hear of conferences by word of mouth, and send in requests for "Calls for Papers" as well as submissions addressed simply to httpd@yourserver.com, which requires slightly intelligent handling.
The mail filter is therefore centralized using .forward file in each conference home directory to reroute mail to papyrus@www.pact96.ibm.com, where a single filter-rules file handles the email for all conferences hosted on the system. The disadvantage is that conference name must be generally included in the Subject line for the messages to be handled correctly, ex:
Subject: Sample call for paperswhere Sample is the name of the conference. Unidentified mail is classified as "UFO" and returned to the sender with a short note listing the allowed Subject phrases to choose from.
If you use Papyrus to handle only one conference, you may comment the "ufo" line in ~papyrus/.elm/filter-rules and uncomment the "save" line below it. This will disable the automatic response, and instead simply save the email in the ufo folder.
The root login menu contains a feature called proxy, that allows you to masquerade as one of your users without needing to use their passwords. This is for letting you walk users through the menus, because each class of users has a different set of menus, and you will need to be able to reproduce their problems in order to fix them.
This is a conference-independent structure and cannot be changed without affecting all conferences hosted on a given system.
The questionnaire can be modified individually for each conference or journal, so long as the changes are also reflected in the scoring and reporting scripts kept in ~sample/bin. The awk tools that were used in evolving the PACT'96 questionnaire are to be found in ~papyrus/reviewer/misc.
There is little reason to convert the scoring and reporting scripts to C. The programs are run infrequently on individual reviews, except when the chairs invoke ranking or report generation. The latter case involves compiling from several hundred review and detailed comments files, so even a compiled program would be limited by the disk accesses. The asynchronous mechanism provides the chairs upto-date status on the progress, alleviating any cause for panic.