*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> supscan (8)              
Title
Content
Arch
Section
 

SUPSERVERS(8)

Contents


NAME    [Toc]    [Back]

       supfilesrv, supscan - sup server processes

SYNOPSIS    [Toc]    [Back]

       supfilesrv  [  -d  ] [ -l ] [ -q ] [ -N ] [ -P ] [ -C Max-
       Children ] [ -O lockdir ]
       supscan [ -v ] [ -s ] [ collection ] [ basedir ]

DESCRIPTION    [Toc]    [Back]

       Supfilesrv is the server processes used to  interact  with
       sup  client  processes  via  the  IP/TCP network protocol.
       This server normally is expected to be running  on  server
       machines  at all times.  Each machine with files of interest
 to users on other machines is expected to  be  a  file
       server and should run supfilesrv.

       A file server machine will service requests for both "private"
 and "system" file collections.  No special action is
       necessary  to  support  private collections, as the client
       user is expected to supply all necessary information.  For
       system  collections,  if  the  base  directory  is not the
       default (see FILES below), an entry must be put  into  the
       directory list file; this entry is a single text line containing
 the name of the collection, one  or  more  spaces,
       and the name of the base directory for that collection.

       Each  collection  should  have  an  entry in the host list
       file; this entry is a single text line containing the name
       of the collection, one or more spaces, and the name of the
       host machine acting as file server for that collection.

       Details of setting up  a  file  collection  for  the  file
       server are described in the manual entry for sup(1).

       Supfilesrv generally runs as a network server process that
       listens for connections, and  for  each  connection  (double-)forks
  a  process  to handle the interaction with the
       client.  However, with the -d flag, no forking  will  take
       place:  the  server  will listen for a network connection,
       handle it, and exit.  This is  useful  for  debugging  the
       servers in "live" mode rather than as daemons.

       For  debugging purposes, the -P "debugging ports" flag can
       be used.  It will cause the  selection  of  an  alternate,
       non-privileged  set  of  TCP  ports  instead  of the usual
       ports, which are reserved for the active server processes.
       The  -N  "network  debugging"  flag can be used to produce
       voluminous messages describing the  network  communication
       progress and status. The more -N switches that you use the
       more output you get. Use 3 (separated by spaces: -N -N -N)
       to get a complete record of all network messages. Log messages
 are printed by syslog on daemon.log .   To  suppress
       log messages, the -q "quiet" flag can be used.
       supfilesrv   uses   libwrap   style  access  control  (the
       /etc/hosts.allow and /etc/hosts.deny files)  with  service
       name  "supfilesrv".  The  -l  "log" flag turn on loggin of
       accepted  connections  (denied  connections   are   always
       logged).

       Normally  the  supfilesrv  will only respond to 3 requests
       simultaneously, forking a child process for  each  client.
       If  it  gets  additional requests it will respond with the
       error FSSETUPBUSY. The -C MaxChildren switch can  be  used
       to increase (or decrease) this number.


       The  -O  lockdir  switch  is used to make supfilesrv allow
       only one active connection at a time from  any  client  IP
       address.   This  is  accomplished  by each serving process
       obtaining exclusive lock, and writing its process ID  into
       a file in "lockdir" where the filename is the dotted decimal
 IP address of the  connecting  host.  Any  connections
       from  a  client where a lock can not be obtained on such a
       file will be rejected, limiting any  client  host  to  one
       connection  at  a  time to this sup server. This is useful
       for preventing problems where clients  running  sup  on  a
       regular  basis  manage  to  time requests so that a second
       request comes in before the first one completes.

SUPSCAN    [Toc]    [Back]

       It is possible to pre-compile a list of  the  files  in  a
       collection to make supfilesrv service that collection much
       faster.  This can  be  done  by  running  supscan  on  the
       desired  collection  on the repository machine.  This produces
 a list of all the files in  the  collection  at  the
       time  of the supscan; subsequent upgrades will be based on
       this list of files rather than actually scanning the  disk
       at  the  time of the upgrade.  Of course, the upgrade will
       consequently bring the client machine up to the status  of
       the  repository  machine  as  of  the  time of the supscan
       rather than as of the time of the upgrade; hence, if  sup-
       scan is used, it should be run periodically on the collection.
  This facility is useful for  extremely  large  file
       collections  that are upgraded many times per day, such as
       the CMU UNIX system software.  The "verbose" flag -v  will
       cause  supscan  to produce output messages as it scans the
       files in the collection.  The "system" flag -s will  cause
       supscan  to  scan  all  system collections residing on the
       current host.  The basedir parameter must be specified  if
       the  collection  is a private collection whose base directory
 is not the default.

FILES    [Toc]    [Back]

       /usr   default base directory for a collection
       /usr/lib/supfiles/coll.dir
              directory list file for file server

       /usr/lib/supfiles/coll.host
              host list file for system sups.

       <base-directory>/sup/<collection>/*
              files used by file server (see sup(1))

       <base-directory>/sup/<collection>/list
              list file used by supscan to create file list

       <base-directory>/sup/<collection>/scan
              file list created by supscan from list file

SEE ALSO    [Toc]    [Back]

      
      
       sup(1)
       The SUP Software Upgrade Protocol,  S.   A.   Shafer,  CMU
       Computer Science Dept., 1985.

DIAGNOSTICS    [Toc]    [Back]

       The  file  server  places log messages on the standard and
       diagnostic output files.  The process name and process  id
       number  generally  accompany  each  message for diagnostic
       purposes.

HISTORY    [Toc]    [Back]

       31-July-92 Mary Thompson (mrt) at Carnegie Mellon University

              Removed  references  to supnameserver which has not
              existed for a long time. Update a few  file  names.
              Added -C switch.

       21-May-87  Glenn Marcy (gm0w) at Carnegie-Mellon University

              Updated documentation for 4.3; changed /usr/cmu  to
              /usr/cs.

       15-Jan-86  Glenn Marcy (gm0w) at Carnegie-Mellon University

              Updated documentation; -s switch to supscan.

       23-May-85  Steven Shafer (sas) at Carnegie-Mellon University

              Supscan created and documented; also -N flag.

       04-Apr-85  Steven Shafer (sas) at Carnegie-Mellon University

              Created.
[ Back ]
 Similar pages
Name OS Title
ypserv Tru64 Network Information Service (NIS) server and binder processes
ypbind Tru64 Network Information Service (NIS) server and binder processes
bos OpenBSD is the client part of the Basic Overseer Daemon AFS server processes.
ypserv HP-UX Network Information Service (NIS) server, binder, and transfer processes
ypbind HP-UX Network Information Service (NIS) server, binder, and transfer processes
ypxfrd HP-UX Network Information Service (NIS) server, binder, and transfer processes
rfork OpenBSD control new processes
killall FreeBSD kill processes by name
killall Linux kill processes by name
top Linux display top CPU processes
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service