SUPSERVERS(8)

okay so this is SUPSERVERS(8) from the System Manager's Manual, and it's all about supfilesrv and supscan — the sup server processes. grab a snack, bestie, we're doing servers 💅

---

✨ NAME ✨

supfilesrv, supscan — sup server processes 🫶

---

✨ SYNOPSIS ✨

supfilesrv [ -4 ] [ -6 ] [ -d ] [ -l ] [ -q ] [ -N ] [ -P ] [ -C MaxChildren ]
supscan [ -v ] [ -s ] [ collection ] [ basedir ]

---

✨ DESCRIPTION ✨

supfilesrv is the server process that talks to sup client processes over the IP/TCP network protocol. No cap. This server is normally expected to be running on server machines at all times — like, it lives there, it pays rent there. Every machine that has files other machines' users care about is expected to be a file server and should run supfilesrv. ✨

A file server machine services requests for both "private" and "system" file collections. Supporting private collections needs zero special action from you — the client user is expected to supply all the necessary information themselves. For system collections, if the base directory isn't the default (peep FILES below 👇), you have to put an entry into the directory list file. That entry is a single text line with the name of the collection, one or more spaces, and then the name of the base directory for that collection. 🎀

Every collection should also have an entry in the host list file. That entry is a single text line: the name of the collection, one or more spaces, then the name of the host machine acting as file server for that collection. 🦋

The whole vibe of setting up a file collection for the file server is described in the manual entry for sup(1). go read it, iykyk.

supfilesrv generally runs as a network server process that listens for connections, and for each connection it (double-)forks a process to handle the interaction with the client. double-forks. it's giving multitasking icon. BUT — with the -d flag, no forking happens at all: the server listens for a network connection, handles it, and exits. This is useful for debugging the servers in "live" mode rather than as daemons. 🙈

For debugging purposes, the -P "debugging ports" flag exists. It causes 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 produces voluminous messages describing the network communication progress and status. The more -N switches 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 is your girl. 🤫

supfilesrv uses libwrap style access control (the /etc/hosts.allow and /etc/hosts.deny files) with service name "supfilesrv". The -l "log" flag turns on logging of accepted connections — and btw, denied connections are always logged, no exceptions. 💀

Normally 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) that number. 👑

supfilesrv listens to the IPv4 listening socket by default. With the -6 flag, it will listen to the IPv6 listening socket. For dual stack support you will want to run two instances of supfilesrv. 🌈

Quick rundown of every flag so nothing slips through the group chat:

• -4 — the IPv4 listening socket life (this is the default anyway).
• -6 — listen on the IPv6 listening socket instead. want both? run two instances, bestie.
• -d — no forking: listen for one network connection, handle it, exit. debugging in "live" mode, iconic behaviour.
• -l — "log" flag, turns on logging of accepted connections. (denied ones get logged regardless, always.)
• -q — "quiet" flag, suppresses log messages.
• -N — "network debugging": voluminous messages about network communication progress and status. stack them (-N -N -N) for a complete record.
• -P — "debugging ports": picks an alternate, non-privileged set of TCP ports instead of the usual ports, which are reserved for the active server processes.
• -C MaxChildren — bump (or lower) the number of simultaneous requests handled. default is 3, and extra requests get FSSETUPBUSY.

---

✨ SUPSCAN ✨

So here's the tea: it's possible to pre-compile a list of the files in a collection to make supfilesrv service that collection much faster. You do this 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. And 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. so if you use supscan, you should run it periodically on the collection. periodt. 💅

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 causes supscan to produce output messages as it scans the files in the collection. 🦋
• The "system" flag -s causes 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 ✨

• /usr — default base directory for a collection 🌈
• /etc/supfiles/coll.dir — base directory list for system collections
• /etc/supfiles/coll.host — host name list for system collections
• <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 ✨

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

---

✨ DIAGNOSTICS ✨

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 ✨

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

---

and that's the whole page, bestie — this one's dated 1/16/86, from the System Manager's Manual era, so it's vintage but it still ate. 💜 stay slaying those collections 🧚