THE SUP SOFTWARE UPGRADE PROTOCOL























                          Carnegie Mellon University
                          School of Computer Science

                                 Steven Shafer
                                 Mary Thompson

                               8 September 1989









  The  SUP  system  is  a  set  of  programs  for maintaining a set of files in
identical versions across a network of cooperating machines.  It runs under the
Mach operating system.
1. Introduction
  The  SUP System is a set of programs that provide for collections of files to
be maintained in identical  versions  across  a  number  of  machines.    These
programs are:

SUP             The "client" program, run by users or system maintainers, which
                initiates the upgrade activity  on  a  machine  requesting  the
                latest  version of a collection of files.  SUP will normally be
                run as a daemon, firing up once  each  night  (week,  etc.)  to
                upgrade the specified file collections.

SUPFILESRV      The  "file  server" program, a daemon that is run by the system
                maintainer to service requests for files  initiated  by  client
                SUP  programs.  The file server runs on every machine used as a
                "repository" of distributable  versions  of  files.    It  runs
                continuously  and  listens  for  network connection requests by
                individual  client  processes;  for  each   individual   client
                request, a process is forked to service that request.

SUPSCAN         The   "file  scanner"  program,  that  may  optionally  be  run
                periodically to speed up execution of  the  file  server.    It
                pre-compiles  a list of files on the file system that match the
                specifications for a given file collection  so  that  the  file
                server need not do this during each upgrade of that collection.
                The file scanner is normally used daily  for  very  large  file
                collections  that  are upgraded by many clients each day; it is
                not so useful for small file collections or for those that  are
                upgraded by only a few client machines per day.

  When SUP is run, the user designates the names of certain "file collections",
sets of files, that should be upgraded.   All  pre-defined  system  collections
have  entries in the coll.host file that gives the name of the host will act as
the repository for that software collection.  The file server on  that  machine
provides  a  list  of  the files included in the collection and which ones have
been changed since the last time this collection was upgraded from that  client
machine;  the  client decides which of these files it needs to receive; and the
files are sent from the file server.  In this way, files can  be  installed  on
the  repository machine once, and they will propagate to all machines upgrading
from that repository as soon as the respective users execute SUP to perform the
upgrade.    This  allows groups of cooperating users to establish sets of files
that can be relied upon to be the same across a set of host machines.

  SUP is intended to provide a broadcast  facility  for  maintaining  identical
versions  of  files  across  multiple  machines.  An alternative approach is to
provide a common file system; even when such a  system  is  available,  SUP  is
useful  for  maintaining  frequently  used files on local disk storage, and for
maintaining files across the file server machines themselves.

  The SUP system does not  address  the  issues  of  version  control,  nor  of
maintaining  compatibility  of  pieces of a system that are being independently
changed by different users or on different machines; what  SUP  provides  is  a
broadcast  mechanism  for issuing stable, reliable versions of software or data
files, produced by a small number of maintainers and needed by a larger  number
of users.  SUP is intended specifically to address these situations:

   - A large collection of system software prepared by a maintenance staff
     for use by a large user community.  For  example,  the  CMU-CSD  UNIX
     software  used  by hundreds of workstations.  In such situations, the
     users know absolutely nothing about how to obtain such software,  but
     they   need  to  keep  it  constantly  upgraded  on  their  machines.
     Similarly, the  maintainers  cannot  possibly  maintain  each  user's
     machine individually: they must rely on a broadcast mechanism such as
     SUP.

   - A moderate collection of  software  and  data  files  shared  by  the
     members  of  a  project.    For example, the vision libraries used by
     computer vision researchers  at  CMU.    Again,  a  small  number  of
     maintainers on a specific machine produce and maintain this software,
     which is used by many users on many machines in the CMU  environment.
     However,  SUP  will not support the practice of some groups that have
     large programs with different pieces  being  simultaneously  modified
     and tested in incompatible ways by various users.

   - A  user  with accounts on more than one machine.  Such a user can set
     up SUP to automatically copy a collection of files from  one  machine
     to  one  or  more  others whenever they are changed on the repository
     machine.

  If the system maintenance staff is  involved  on  the  repository  machine  a
"system"  file collection can be set up for which client SUP programs need know
nothing but the name of the collection.  Otherwise, the file collection will be
"private",  and  client  SUP programs must be specifically told the name of the
repository host and the base directory name for the collection on that host.

  SUP provides facilities for upgrading read-protected files (i.e.  files  that
are  not  readable by the general public), data encryption of transmitted files
and filenames, allowing access only to selected host machines not on the  local
network,  automatically  creating  backup  copies  of critical files, executing
command-files or programs after upgrading files that require special  handling,
and  mailing  progress  and error messages to designated users.  SUP is also as
clever as can be about ensuring that upgraded files have  the  same  accounting
information  (mode,  owner,  links,  etc.)  on  the  client  machine  as on the
repository machine, and ensuring that upgrade problems don't wipe out  existing
files when this is avoidable.
2. How to Use SUP to Upgrade a File Collection
  You  will normally want to run SUP periodically, say every day or every week,
using the at program, to upgrade important file collections such as UNIX system
software.    You  can  also  execute SUP directly at any time.  The SUP command
looks like this:

    $ sup [flags] [supfile]

These are the flags and arguments:

-a (all files)  Normally, SUP only upgrades files if they  are  out-of-date  or
                missing  on your machine.  If you specify the -a flag, then all
                files in the collection will be upgraded regardless of  whether
                they meet these conditions.  This is useful for recovering from
                catastrophic file deletions or disk crashes.

-b (backup)      If this flag  is  given,  or  the  backup  supfile  option  is
                specified,  the  contents  of regular files on the local system
                will be saved before they are overwritten with new data.    The
                file  collection  maintainer can designate specific files to be
                worthy of backing up whenever they are upgraded.  However, such
                backup  will  only  take  place if you specify this flag or the
                backup option to allow backups for a file  collection  on  your
                machine.    The  backup  mechanism  will  create  a copy of the
                current version of a file immediately  before  a  new  copy  is
                received  from the file server; the copy is given the same name
                as the original file but is put into a directory called  BACKUP
                within  the  directory  containing  the  original  file.    For
                example, /usr/sas/src/foo.c would have  a  backup  copy  called
                /usr/sas/src/BACKUP/foo.c.      There   is   no  provision  for
                automatically maintaining multiple old versions of  files;  you
                would have to do this yourself.

-B              overrides  and  disables  the  -b  flag  and the backup supfile
                option.

-d (delete)      Files that are no longer in the collection on  the  repository
                will be deleted if present on the local machine.  This may also
                be specified in a supfile with the deleteoption.

-D              This flag overrides and disables the -d  flag  and  the  delete
                supfile option.

-e (execute)    Sup  will execute commands sent from the repository that should
                be run when a file is upgraded.  If the  -e  flag  is  omitted,
                Sup will print a message that specifies the command to execute.
                This may also be  specified  in  a  supfile  with  the  execute
                option.

-E              overrides  and  disables  the  -e  flag and the execute supfile
                option.

-f (file list)  If you specify -f, then SUP will print a list of all the  files
                in  the specified collections, indicating which ones need to be
                upgraded, which  are  directories,  and  which  require  backup
                copies  to  be  created.    The  upgrade  itself  will  not  be
                performed.

-l (local)       Normally, SUP will not upgrade a collection if the  repository
                is  on  the same machine.  This allows users to run upgrades on
                all machines without having to  make  special  checks  for  the
                repository  machine.   If the -l flag is specified, collections
                will be upgraded even if the repository is local.

-m (mail)       Normally, SUP prints log messages on its  standard  output  and
                diagnostic  output.   With the -m flag, messages will be mailed
                to you instead.  This also  allows  the  notify  option  to  be
                effective  (see  the discussion of supfiles below) to send mail
                to someone else.

-N (network debugging)
                The  -N  flag  causes  SUP  to  produce  tons  of  output lines
                describing   the   progress   and   status   of   the   network
                communications with the name server and file server.

-P (debugging ports)
                The -P flag tells SUP to use an alternate set of TCP ports from
                the  normal  ports.    This  is  a  debugging  aid  for  system
                maintenance.

-o (old files)  This flag overrides the noold  option  if  it  appears  in  the
                supfile.    The  -a  flag also overrides the noold option.  See
                "Supfiles" below for details.

-O              overrides and disables the -o flag and the old supfile option.

-s (system collections)
                Normally,  you  will specify a specific supfile to describe the
                file collections you want.  If you use  the  -s  flag,  then  a
                specific  supfile  will  be  used  that  describes  the  system
                software file collections.  The supfile for system software  is
                /usr/cmu/lib/supfiles/coll.list.

-t (time)       If you specify -t, then SUP will simply print out the last time
                and  date  at  which  each  specified   file   collection   was
                successfully  upgraded; it will not perform any actual upgrade.
                This is a diagnostic aid  in  case  you  suspect  the  upgrades
                aren't working.

-v (verbose)    Normally,  SUP only produces messages to tell what's gone wrong
                (if anything does go wrong).  With the -v flag,  messages  will
                be  produced  to  tell  what is happening when things are going
                normally as well.

supfile         You must specify the name of a supfile, unless you use  the  -s
                flag  to  indicate  the  system software supfile.  The supfile,
                described below, specifies which file collections you  want  to
                upgrade.

  For example, to upgrade system software on your machine, type:

    $ sup -s

or, to have detailed log messages mailed to you:

    $ sup -v -m -s

Because  SUP runs with your user-id, you will not be able to upgrade the system
software unless you are logged onto that account when you execute SUP.

  Each file collection being upgraded  must  have  a  base  directory  on  your
machine,  which  will normally contain all the files in the collection.  Within
this directory there should be a subdirectory called sup that will be  used  by
the SUP program; it will be created automatically if you do not create it.  SUP
will put files into this directory as needed.

  If you want to find out what files need to be upgraded, type:

    $ sup -f supfile

This will list all the files in the collection, indicating  which  need  to  be
upgraded  (and  why), which are directories, and which would have backup copies
created if the upgrade were performed.  If you simply want to find out the date
and time of the last successful upgrades, type:

    $ sup -t supfile

This  will  print  the  collection  name  and time of the last upgrade for each
collection described in the indicated supfile.  For the system collections, you
can use:

    $ sup -s -t

2.1 Supfiles
  When you execute SUP, you specify a supfile either by name or by using the -s
flag.  This file is a list of the file collections you wish to upgrade.

  The supfile is a text file, with each file collection described on  a  single
line.    The  line  begins with the name of the collection, and may then have a
number of options separated by spaces.  The options are:

base=directory  The name of the base directory on this machine  for  this  file
                collection,   when   you   don't   want   to  use  the  default
                (/usr/collection).

host=hostname   The name of the host machine acting as the repository for  this
                file  collection,  used  for  "private"  file collections.  For
                "system" file collections, this is unnecessary because the this
                information is kept in /usr/cs/lib/supfiles/coll.host.

hostbase=directory
                The name of the base directory on the  repository  machine  for
                the  file  collection  (see  "How  to Set Up a File Collection"
                below).  This is also used only for "private" file collections;
                for  "system"  file  collections,  the  information is obtained
                automatically by the file server.  The default name of the host
                base directory is /usr/collection.

login=accountid The name of the account to be used by the file server, when the
                default is not acceptable (i.e. it doesn't have  the  necessary
                file  access  privileges  to  read  the  file collection).  The
                default at CMU is  the  "Anonymous  FTP"  account  if  no  data
                encryption   is   used,   or   the   owner   of  the  directory
                sup/collection within the repository machine's  base  directory
                if encryption is used.

password=password
                The password used  for  the  login  account  specified  by  the
                "login" option.  This password will be transmitted in encrypted
                form over the network.

crypt=key       An optional encryption key for filenames and file data for this
                file  collection.    If used, the same key must be specified on
                the repository machine or the  upgrade  will  not  take  place.
                This  key  is  used  for  filenames  and  data  only -- not for
                transmission of the passsword in the "password"  option.    The
                use  of  data  encryption  also  implies  an  alternate default
                account for the file server (see the "login" option above).

notify=mailaddress
                The  account  name  to  which  mail  is to be addressed for log
                messages for this file collection, when the -m flag is given to
                SUP.  The account name can be a complete mail address, possibly
                including a network host name such as sas@cmu-cs-ius.

noexec          This option prevents the automatic execution of  command  files
                on  your  machine  with  the upgrade is finished (see "What SUP
                Does" below).

backup          This option enables backup  copies  of  critical  files  to  be
                created by SUP as specified in "What SUP Does" below.

nodelete        This option prevents SUP from deleting files on your machine if
                they are deleted from the file  collection  on  the  repository
                machine.

noold           This  option  tells SUP not to check on files in the collection
                that have not been modified or created since the last  upgrade.
                This  allows  SUP to run much faster on large file collections,
                but prevents it from deleting files on the  client  machine  if
                they  are  deleted from the repository, or from restoring files
                that have been accidentally deleted from  the  client  machine.
                This  option  is  normally  useful  only  for  very  large file
                collections.   Its  function  subsumes  that  of  the  nodelete
                option.    The noold flag will be ignored when either the -a or
                -o flag is specified to SUP; this allows a complete file  check
                to  be  performed with the -o flag when needed to recover from,
                say, accidental deletion of critical files.

  Here is an example of a supfile:

    cmu  backup
    vision  crypt=pupil backup notify=vision@cmu-cs-ius
    sas  host=ius hostbase=/usr/sas/sun login=sas password=foo crypt=bletch

This supfile specifies the following file collection upgrades:

cmu             The "cmu" file collection, which is a "system" file collection,
                with  local  base  directory  /usr/cmu  (the  default).  Backup
                copies of critical files will be created during upgrading.

vision          The "vision" file collection, also a "system" file  collection,
                with  local  base  directory  /usr/vision.    Backups  will  be
                created.  The data will be encrypted with key  pupil,  and  log
                messages will be sent to the vision account on cmu-cs-ius.

sas             A   "private"   file  collection  will  be  upgraded  from  the
                cmu-cs-ius machine.  The remote base directory is /usr/sas/sun,
                but the local base directory is /usr/sas.  The file server will
                login on account sas  with  password  foo;  the  data  will  be
                encrypted with key bletch.
3. What SUP Does
  An upgrade involves several steps:

   1. SUP  first  reads  the specified supfile, checking it for errors and
      recording all the specifications and options.

   2. If any collections do not specify a host  name,  SUP  will  look  in
      /usr/cs/supfiles/coll.host  to  find  out the names of the hosts for
      these collections.  In the preceding example, the name server  would
      be  asked  to  supply  the  host  names  for the cmu and vision file
      collections.

   3. For each collection on the list, SUP will connect to the file server
      on  the  appropriate host and carry on the upgrade process.  (If the
      file server is on the same host machine as the client, and the  base
      directories are the same, then no upgrade is performed.)

         a. The  file server and SUP exchange setup information, including
            the host base directory, login  account  name,  password,  and
            encryption  key.    SUP  also  reports  the  time  of the last
            upgrade, by looking  in  the  file  sup/collection/when  (e.g.
            /usr/vision/sup/vision/when)  on the client machine.  The file
            server gets the base directory name, if needed, by looking  in
            the   file   /usr/cs/lib/supservers/coll.dir,   and  gets  the
            encryption key from  sup/collection/crypt  on  the  repository
            machine.  The connection may be refused by the file server for
            such reasons as:

               - incorrect login name or password
               - base  directory  is  protected  against  access  by   the
                 specified account
               - incorrect data encryption key
               - host not allowed access

         b. Once  the  connection is established and access permission has
            been granted as above, the file server builds a  list  of  all
            files  and  directories in the file collection.  The list file
            sup/collection/list (see "How to Set  Up  a  File  Collection"
            below)  is used to generate this list.  The files indicated in
            the list file are marked with  a  special  flag  if  they  are
            indicated  to  have  backup copies created in case of upgrade.
            The last modification date of each file is checked against the
            time  of  the last upgrade (reported by the client above), and
            if it has been modified since the last upgrade, a flag is  set
            to  indicate  that  the  client's  copy of this file is out of
            date.  The file list, along with the  backup  and  out-of-date
            flag  for  each  file,  is sent to the client.  If a scan file
            exists as created by SUPSCAN (sup/collection/scan),  then  the
            file  list  is  taken  from  the  scan  file  instead of being
            constructed from the list file by the file server.    In  this
            case,  the  time of record for the upgrade will be the time at
            which the scan file was created rather than the time at  which
            the  upgrade  actually  occurs.    If  the  noold  option  was
            specified in the supfile (and not overridden by the -a  or  -o
            flag to SUP), the list of filenames sent to the client process
            will exclude those files that were  not  created  or  modified
            since the last upgrade.

         c. The  client  SUP  process  receives  the  list  of  files  and
            constructs a list of the files it needs.  This  will  normally
            be those files that are either (1) out-of-date as indicated by
            the flag sent from the file server, or (2)  missing  from  the
            local  machine.  However, if the -a flag was specified to SUP,
            then every file in the list will be  selected  by  the  client
            process.  The list of needed files is sent to the file server.
            For each selected file, if the backup flag was marked and  the
            user specified the backup option in the supfile, then a backup
            copy of the file will be created.  This will be a copy of  the
            file  with  "backup/"  inserted in the filename just after the
            directory name, i.e.  /usr/vision/lib/libvision.a would have a
            backup  copy  named  /usr/vision/lib/backup/libvision.a.  (The
            indicated  directory,  e.g.  /usr/vision/lib/backup,  will  be
            created if needed.)  Also at this time, if the nodelete option
            was not specified, the client reads its list of files  in  the
            collection     during    the    last    successful    upgrade,
            sup/collection/last, and deletes any files appearing  in  that
            list that are not in the current file list.

         d. The  file  server  receives the list of files requested by the
            client.  It checks to see that each file is  on  its  list  of
            files  for  this collection, and that each file is accessible;
            if a file fails either condition its name will be reported  to
            the  client as being denied to that client.  Each file will be
            sent to the client machine,  along  with  the  owning  account
            name,  the  owning group name, the 12 low-order mode bits, and
            the last modification time for that file.  If a file has  more
            than  one  link (filename), both of which are requested by the
            client, then the file will be sent once and the second  (etc.)
            filename will be accompanied only by a flag saying it's a link
            and the name of the file actually sent.  The  client  receives
            each   file   and   processes  it  as  described  under  "File
            Installation" below.  Directories  are  treated  similarly  to
            files;  the  mode,  owning account and group, and modification
            time  are  transmitted  to  the  client  machine  whenever   a
            directory is upgraded.

         e. When all files have been transmitted, the file server looks at
            the list of command-files to be executed after  upgrading  for
            this collection (see "How to Set Up a File Collection" below).
            If any of the command-files or their trigger files  have  been
            upgraded,  then  the  client  is  sent  the  filename  of  the
            command-file.  The client SUP process  will  normally  execute
            these  files; however, if the user has specified noexec in the
            supfile, then the files will not be executed.  In this case, a
            log message will be created and printed or mailed, telling the
            user to please execute these files.    When  creating  command
            files  to be executed by SUP, you should bear in mind that the
            command file might be  executed  several  times  on  the  same
            version of the trigger files.

         f. Finally,  if  the  upgrade is successfully completed, the file
            server reports the time  (on  its  own  clock)  at  which  the
            upgrade  began;  the  client will record this time in the file
            sup/collection/when to be reported as above at  the  start  of
            the  next  upgrade.  If the nodelete option was not specified,
            then the list of all files in the collection is  written  into
            sup/collection/last.

  SUP  and  the  server  processes begin each connection by determining whether
byte-swapping is necessary for passing integers across the network.  If so, the
server  process  performs  byte-swapping  on input or output of integers to the
network, while the client uses its natural representation for network I/O.

3.1 File Installation
  When SUP receives an ordinary file  (i.e.  one  that  is  not  a  link  to  a
previously sent file), it follows this procedure:

   1. If  the  file doesn't already exist on the local machine, it's a new
      file.  It will be created and the data will be  read  directly  into
      this file.

   2. Otherwise, the file already exists.  An attempt will be made to read
      the file contents from the network into a temporary file, which will
      later  be  renamed to replace the destination file.  SUP will try to
      create a temporary file in  the  following  directories,  proceeding
      down the list until one of the attempts succeeds:

         a. destination-directory   (the  directory  containing  the  file
            itself)
         b. sup (the sup subdirectory of the local base directory)
         c. . (the local base directory)
         d. /usr/tmp
         e. /tmp

      If all these attempts fail, SUP will try to create  the  destination
      file  itself  instead of using a temporary file.  If that fails, SUP
      will complain with a log message and go on to the next file.

   3. The file data itself is read into the temporary or destination file.
      Interrupts are disabled during this process.

   4. If  the  file  read  was  a  temporary  file,  it  is renamed to the
      destination file.  This is done via link/unlink, if possible, unless
      the destination file has more than one link already on this machine.
      If the link/unlink fails or if the  destination  file  has  multiple
      links, then the temporary file is actually copied to the destination
      and the temporary file is unlinked.

   5. The owner, group, modification time, and low-order 12 mode  bits  of
      the  destination  file  are set to the values received from the file
      server.  The last-access time of the file  is  set  to  the  current
      local clock.

   6. If  the  -v  flag  was  specified  to  SUP, a log message is printed
      indicating the successful receipt of the file.

  When SUP receives a new link to a file previously received, it  simply  tries
to  unlink  and  link unless the two names are on different file systems on the
local machine.  If this is the case, or if the link fails, then the  previously
received  file  is  actually  copied  to  the  new name (using exactly the same
process as described above for creating a temporary file if needed, etc.)   The
file-system  comparison  checks  the file system of the old file itself and the
directory containing the new name.

  In all cases, if the directory containing a received file or  link  does  not
exist  on  the local machine, SUP creates it with mkdir (recursively if needed)
before creating that file or link.  The mode, owner,  group,  and  modification
time of the newly created directory will then be set to be the same as the mode
of the corresponding directory on the  repository  machine.    This  accounting
information  will  be  updated  whenever  the  directory  is  modified  on  the
repository machine.

  As can be seen from this description, SUP will work the most  smoothly  (i.e.
always  using link/unlink for file name changing) if it has write permission in
the local base directory and in all subdirectories of that directory.
4. How to Set Up a File Collection
  It takes only a little bit of effort  to  set  up  a  file  collection  on  a
repository machine to be upgraded by authorized clients.

  First,  the file collection must be given a name and a base directory.  There
can  be  several  collections  with  different  names  sharing  the  same  base
directory;  for example, there might be a file collection called cmulib for the
CMU C library, and one called cmumathlib for just the math routines in the  CMU
C library, both using /usr/cmu as the base directory.

  If  it  is a "private" file collection, client users must be told the name of
the repository host and the name of the host base directory for use in the host
and  hostbase  options  in  the  supfile, described above.  If it is a "system"
collection instead, the system maintainers must alert the name servers  of  the
host  name  (in  /usr/cmu/lib/supservers/coll.host)  and  the  appropriate file
server of the base directory name (if not  the  default,  by  putting  it  into
/usr/cmu/lib/supservers/coll.dir).

  Within the base directory, a subdirectory must be created called sup.  Within
this subdirectory will be a further subdirectory whose name is the name of  the
collection (there may be several of these if several collections share the same
base directory).  Each collection's subdirectory will contain  any  or  all  of
four files:

collection/list The  list  file,  describing  the files in the collection.  The
                format of this file is explained below.

collection/host Normally, the file server allows access to a collection by  all
                machines.   If you wish to allow access only to specific remote
                hosts, you can list their names, one per  line,  in  this  text
                file.    If a remote host has several alias names, it need only
                be listed once in this file.  The name LOCAL  can  be  used  to
                allow access to all machines on the local network.  This access
                control is in addition to the  other  forms  of  authentication
                provided  by  SUP  (data  encryption  and  UNIX file protection
                modes).

collection/crypt
                If  you wish to apply data encryption to the filenames and file
                contents in this collection during upgrading, create this  file
                and place in it the encryption key.  This should be on a single
                line of text containing nothing else except an optional newline
                character.    The client must supply the same key via the crypt
                option in the supfile for this file collection; the file server
                checks  that  explicitly before authorizing the upgrade to take
                place.

collection/scan To speed up execution of the  file  server,  you  may  wish  to
                create a scan file periodically.  This is done by executing the
                SUPSCAN program:

                    $ supscan [-v] collection [basedir]

                This  will  construct  a  list  of  all  files   matching   the
                specifications  in  the  list  file,  and record it in the scan
                file.  When an upgrade is performed on the collection, the file
                server  will  notice that the scan file is present and use this
                list  instead  of  actually  building  the  filename  list   by
                analyzing  the  list  file.  The time of record for the upgrade
                will then be the time at which the scan file was created rather
                than the time at which the upgrade occurs.  A scan file is only
                useful for very large file collections that are  upgraded  many
                times  each  day.    The options for the SUPSCAN program are -v
                ("verbose") to produce messages as it scans the file list,  and
                basedir  if  the  collection is a private collection whose base
                directory name is not the default name.

  This is all the preparation required for a file collection to be upgraded.

  Note that the default user-id for the file server is "Anonymous  FTP"  if  no
data  encryption  is used; if encryption is used, the default will be the owner
of the subdirectory sup/collection within the base directory.

4.1 The List File
  The list file contains a description  of  the  files  to  be  upgraded.    It
contains  any  number  of commands, each on a separate line of text.  Each line
contains a keyword and a number of operands separated by spaces.  All filenames
in  the  list  are evaluated relative to the collection's base directory on the
repository machine for the file server, and relative to the base  directory  on
the  client  machine  for the client SUP process.  All (except execfile) may be
file specifications containing the shell's meta-characters  *,  ?,  [...],  and
{...}.

  The commands are:

upgrade filename ...
                These files will be  included  in  the  list  of  files  to  be
                upgraded.   If a directory name is given, all the files in that
                directory will be  included  and  any  subdirectories  will  be
                recursively included as well.

omit filename ...
                These files will not be included in the list; if a directory is
                specified,  it  will  not  be included nor will its contents be
                included.  For example, the specifications upgrade lib and omit
                lib/test  will  include  all  files  and  subdirectories of lib
                except  lib/test  (and  any  subdirectories  or  files   within
                lib/test).

omitany pattern ...
                The specified patterns are compared against the  files  in  the
                upgrade  list.  If a pattern matches, the file is omitted.  The
                omitany  command  currently  supports  all  wild-card  patterns
                except  {...}.    Also,  the  pattern  must  match  the  entire
                filename, so a leading */, or a trailing /*, may  be  necessary
                in the pattern.

backup filename ...
                The files will be marked for creating  backup  copies  whenever
                they  are  upgraded  (as  described  above).  Only files can be
                included in this list -- not  directories.    As  noted  above,
                actual  backup  copies  will  only be created by SUP when these
                files are being  upgraded,  and  then  only  if  the  user  has
                specified the backup option in the supfile.

execute execfile (triggerfile ...) ...
                The listed execfiles  are  command  files  or  programs  to  be
                executed  after  an  upgrade to perform routine installation of
                the upgraded files.  Each execfile will be executed  only  when
                it  is  upgraded itself, or when any of its listed triggerfiles
                have been upgraded.  The installation tasks performed  by  such
                files  might  be, for example, creating a table of contents for
                manual entries or for a subroutine library, or modifying a host
                name field within a data file.

include listfile ...
                The named listfiles will be read at this point.  This allows  a
                collection  to  contain  another collection in its entirety, by
                simply specifying the name  of  the  listfile  for  that  other
                collection.

backup filename...
                The specified file(s)  are  marked  for  backup;  if  they  are
                upgraded  and the client has specified the backup option in the
                corresponding line of the supfile, then backup copies  will  be
                created  as described above.  Directories may not be specified,
                and no recursive filename construction is performed;  you  must
                specify  the names of the specific files to be backed up before
                upgrading.

symlink filename...
                The  specified  file(s) are to be treated as symbolic links and
                will be transfered as such and not followed.  By  default,  SUP
                will follow symbolic links.

rsymlink dirname...
                All the symbolic links in the specified subdirectories  are  to
                be transferred as such and not followed.

  Blank  lines  may  appear  freely  in  the  list file, and the order in which
command lines appear within the file does not matter.  Filenames must generally
match  as  strings, e.g.  with base directory /usr/vision, "lib" in the upgrade
command would not match "/usr/vision/lib" in the omit command;  it  would  only
match  "lib"  in  the omit command.  However, one special exception exists:  if
the base directory is specified via "dot"  (.)  in  the  upgrade  command,  the
filenames  within  that  directory  need not begin with "./" in other commands.
For example, with base directory /usr/vision,  the  commands  "upgrade  ."  and
"omit  exp"  specify  a  file  list  including all files and directories within
/usr/vision except the subdirectory /usr/vision/exp and its subdirectories  and
files.
5. Setup for SUP
  You need to add the following entries to /etc/services:

    supfilesrv      871/tcp
    supfiledbg      1127/tcp

  A  supfilsrv  daemon  should be kept running on any machine that may act as a
repository for a collection. Since this includes  private  collections,  it  is
advisable  to  have  supfilesrv  running on all machines if SUP is to be widely
used. nanny can be used to start the supfilesrv.

  The program modcoll.8 is used to set up the control files  for  the  "system"
collections. See /usr/cs/man/man8/modcoll.8
                               Table of Contents

1. Introduction                                                               1

2. How to Use SUP to Upgrade a File Collection                                2

   2.1 Supfiles                                                               2

3. What SUP Does                                                              4

   3.1 File Installation                                                      4

4. How to Set Up a File Collection                                            5

   4.1 The List File                                                          5

5. Setup for SUP                                                              6