summaryrefslogtreecommitdiff
path: root/OPERATING
diff options
context:
space:
mode:
authorGravatar Greg Hudson <ghudson@mit.edu>1997-09-14 17:50:06 +0000
committerGravatar Greg Hudson <ghudson@mit.edu>1997-09-14 17:50:06 +0000
commitac16f380e349fa39ec7e26bccb5456cb300006a5 (patch)
treec07ca88af97b4f6b77d28a2dc723d2e4621ed302 /OPERATING
parentd33e482744fad80d95cdd89ed380c5b8401e49bf (diff)
Pull in sources from zephyr locker. See /mit/zephyr/repository for
detailed change information.
Diffstat (limited to 'OPERATING')
-rw-r--r--OPERATING54
1 files changed, 54 insertions, 0 deletions
diff --git a/OPERATING b/OPERATING
new file mode 100644
index 0000000..7f23a85
--- /dev/null
+++ b/OPERATING
@@ -0,0 +1,54 @@
+This file explains how to operate a Zephyr service once you have
+installed Zephyr on all the relevant machines and file servers in your
+environment. To learn how to configure, build, and install Zephyr,
+read the file INSTALL.
+
+To set up Zephyr service at a site, follow these steps:
+
+1. Choose the machines you wish to have act as Zephyr servers at your
+site. Expect the server to be CPU-efficient but to consume a bit more
+memory than you might expect (at MIT, with around a thousand
+simultaneous users, the Zephyr server's data size is 40MB). If you
+have a lot of users, the server should have enough memory so that the
+process doesn't swap.
+
+2a. If you configured Zephyr with Hesiod support, make sure your
+Hesiod realm has a "zephyr.sloc" entry containing a record for each
+server. (Each entry should contain the name of the server, nothing
+else.) The Zephyr servers will use the zephyr.sloc entry to find the
+other servers. Host managers will use the zephyr.sloc entry to find
+the Zephyr servers by default; however, you can control the set of
+servers for each host manager by giving each host a
+"<hostname>.cluster" entry containing a record "zcluster <serverset>".
+If such a record is found, the host manager will resolve
+"<serverset>.sloc" instead of "zephyr.sloc".
+
+2b. If you configured Zephyr without Hesiod support, and you have
+multiple Zephyr servers, each server should have a file "server.list"
+in the configuration directory (which is /etc/athena/zephyr if you
+configured with --enable-athena, or /usr/local/etc/zephyr if you
+installed Zephyr in /usr/local and didn't use --enable-athena). This
+file should contain a list of the servers, one per line.
+
+3. If you configured Zephyr with Kerberos 4 support, make a service
+key "zephyr.zephyr@<your realm>" and install a srvtab for that service
+as "srvtab" in the configuration directory of each of your zephyr
+servers.
+
+4. Start zephyrd from the system binary directory (/usr/athena/etc if
+you configured with --enable-athena, /usr/local/sbin if you installed
+in /usr/local and didn't use --enable-athena). zephyrd logs as
+service "local6"; watch the syslogs for error messages. Arrange for
+zephyrd to be run at boot time on your server machines.
+
+5. Each client machine should run zhm (the Zephyr Host Manager) from
+the local system binary directory (/etc/athena for --enable-athena,
+/usr/local/sbin if you installed in /usr/local and didn't use
+--enable-athena). If you built Zephyr without Hesiod support, you
+should start zhm as "zhm server1 server2 server3 ..." so that zhm
+knows where the Zephyr servers are.
+
+You can send a SIGFPE signal to the server process to make it dump its
+subscription database to /var/tmp/zephyr.db. (If /var/tmp didn't
+exist when Zephyr was built, the subscription database will be dumped
+in /usr/tmp or /tmp instead.)