OLC:

Technical Overview and Setup

Lucien Van Elsen

April 2, 1991

\begin{matrix}c \\ ◯ \end{matrix}1991 Massachusetts Institute of Technology

Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira, and Zephyr are trademarks of the Massachusetts Institute of Technology (MIT). No commercial use of these trademarks may be made

without prior written permission of MIT.

Contents

1 Overview 2

1.1 OLC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Locking Daemon: olcd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 Polling Daemon: polld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.3 Query Daemon: rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Discuss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Building the binaries 4 2.1 Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Use without Athena services 5 3.1 Hesiod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Zephyr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Discuss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 “Athena” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Installation 7

4.1 OLC Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1 olc/olcr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2 Xolc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3 Emacs OLCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.4 Stock Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 OLC Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1 olcd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2 polld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.3 rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.3 System files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.3.1 writed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Hesiod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6 Discuss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.7 Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Initial configuration 10 5.1 User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Acls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3 Topic List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Specialties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 Machine Information Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6 Support 14

1 Overview

The part of the document is intended to provide a general technical overview of the OLC service, with references to the relevant sections of source code. It assumes you have a working knowledge of user interface and concepts of the OLC system; it is not meant to be a general overview of the OLC system, but rather a guide to the installation, customization, and maintenance of an OLC system.

1.1 OLC Server

The OLC server is composed of a three daemons and a database that reside on a common machine. It also uses several services present on the machine (such as the ability to export NFS, and Discuss), as well as services present on the network (such as Zephyr, Hesiod, and Kerberos). While these services are necessary to have the full functionality of OLC, some functionality can be had without these services.

1.1.1 Locking Daemon: olcd

This daemon handles all changes to the database. It handles a wide variety of requests^{1}, and handles the direct communication with the users via write and zephyr when their question status changes, and also broadcasts notifications of status changes via Zephyr. It is also responsible for keeping the kerberos ticket file that it and the polling daemon use to authenticate themselves to the various services.

Additionally, this daemon is responsible for automatically connecting new questions to consultants based on the consultants available, their specialties, and other information about the question and consultant^{2}.

When a question is resolved, this server moves the log of the question to discuss^{3}, notifies the user and the consultant, and removes the question and the associated user information from the database.

1.1.2 Polling Daemon: polld

This daemon does not directly communication with the client programs, but instead uses Zephyr and finger to keep track of the login status of the users who have questions currently active in OLC, and to information the Locking Daemon when their status changes so it can update the database.

It does this by periodically reading the list of active questions from the database^{4}. It zlocates the user, and uses the locations it gets from zephyr and the last known location it got from the database to build a list of possible locations. From this, it then fingers at each of the locations, looking for the user. If the login status has changed from what it found in the database, it makes a request of the Locking Daemon to change the users’s status^{5}.

1.1.3 Query Daemon: rpd

This daemon is used to provide a quick means of retrieving information from the database. It cannot change the database state, but only retrieve information from it. Specifically, it is used to retrieve the logs of questions, the unseen messages for consultants and users, and the current queue listing. These functions were separated from the locking daemon because they don’t change the state, and because they are some of the most common requests made^{6}.

1For a long time, this was the only daemon. See src/include/olc/requests.h for a description of the protocol and a list of the requests and options it can take. The actual routines to handle the requests are in src/server/olcd/requests olc.c and src/server/olcd/requests admin.c.

2The routine that does this is match maker in src/server/olcd/data utils.c

3Actually, a small lie. It actually calls the lumberjack program to move the question log to discuss.

4The frequency can be controlled by changing CYCLE TIME in src/include/polld.h

5Note that this daemon uses the kerberos ticket file maintained by the locking daemon to make requests of the locking daemon. In order to make the user status change requests, the principle in the kerberos ticket file maintained by the olc server (commonly ‘olc.hostname’) must be on the admin acl of the OLC server.

6Based on profiling information, our average breakdown of requests shows that 18% are requests for logs, 12% are for unseen messages, and 15% are for the current queue listing

The daemon caches this information in memory, and keeps the file descriptors of the information it’s caching open as well. When a request comes in, it checks it’s cache, and if it finds the requested information, stats the file to make sure it has the most up to date copy. If it finds newer information, it reads it into memory, and then ships the information down the socket to the user.

The cache uses a pseudo-LRU (‘clock’) algorithm for its caching; in practice, cache hits average around 80%. Additionally, it uses a smaller, more streamlined protocol than the locking daemon.

1.1.4 Database

The database stores the information that represents the “state” of the OLC server at any given time. This information consists of:

• Location: This is the current/last known location of the user. This information is used by the polling daemon to determine if the user is logged in, and is included as part of the queue listing to help consultants in answering the question.

• Login status of the user. This information is used in matching up users and consultants, and is included as part of the queue listing to help consultants in answering the question.

• Question log: This is a plain ascii file that contains a log of all the actions taken on the question to date. There may be a “censored” version as well as an uncensored version if private comments were made.

• Unseen messages: This is a plain ascii file that contains the messages that a user has not viewed yet; it is separate from the question log (although the information is present in both places) to allow easy access to the new messages separate from other information in the log.

• Unanswered questions: A list of all the questions that have yet to be resolved and the information associated with them.

• MOTD: The message of the day and the times that it should start being displayed and the time it should stop.

• ACLs: The access control lists used by the server. For more information on these, see section 5.2

• Specialties: The list of topics which consultants have special knowledge in, which is used when determining who to automatically connect a question to. For more information, see section 5.4.

• Topics: This is the list of the topics that the server supports. For more information, see section 5.3.

1.2 Discuss

Discuss is a conferencing system that is used to store the logs of resolved questions. The logs of resolved questions are not directly used by the server, but are useful in order to perform checks on the quality of answers given and other administrative functions. Additionally, it provides a reference of past answers that can be searched by consultants, to see if a similar question has been answered in the past.

1.3 Mail

Mail can be used to provide a means to enter questions into OLC; while this entry point cannot be authenticated (unlike all the other requests made of the server) there are some environments where the benefits gained by the ability to enter questions by mail outweigh the possible disadvantages.

1.4 NFS

NFS^{7} is not used directly by the server, but can be used to provide a convenient way for the OLC Administrator to access the various files that make up the OLC database. Using this, various administrative changes (such as changing user/consultant titles) can be made in the database with necessarily having to log in to the server machine.

1.5 Remote Access

Again, remote access is a convenience which is useful to maintain the machine. At Project Athena, this service is not turned on by default; if you’re outside of Athena, this may different.

2 Building the binaries

In order to build the binaries from the distribution, you will need the imake and makedepend utilities that are distributed along with X. It is useful if you have the other Athena services, motif, and emacs, but they are not necessary to build a bare-bones system.

2.1 Configuration files

Before building the distribution, it is necessary to modify the configuration files to reflect the preferences at your site. The files that must be modified are:

• src/config/site.def This is used to determine what services and systems you have present a your site. Some of the more non-obvious ones are:

– TestInstall: If this is true, the binaries will be installed in an alternate location when “make install” is run. The locations are determine by the individual Imakefiles in the directories involved.

– HaveSysWrited: If this is true, you already have a “writed” for handling network writes. I am not sure if this is true anywhere outside of MIT.

– HaveSysWCL: If this is true, you already have “WCL^{8} ”. Note that the version of wcl used in the code is 1.0.4, not 1.0.5 which is the most current.

– DoLogging: If this is true, the server will log all requests made of it to a file. Useful for debugging, or for profiling usage.

– DoUsageLog: If this is true, the clients will log their usage. A host must be set up in the .h files of the respective clients, and the logger/bbd program must be running on the host which is specified.

– AthenaCompat: Should be false for sites outside of MIT.

– HaveMotif: Should be true if you have Motif, and want the motif-based client built.

Additionally, site.def is used to specify the locations of various system libraries if they are present.

• src/config/Imake.template: This is used to set the defaults for several OS-dependent flags. Usually, this information is set in the MacroIncludeFile (e.g. machtype.cf) in the config directory for each platform, but if you wish to provide new defaults, you can do it here.

7Sun’s network file system; all trademarks are copyright their respective owners. that’s our lawyer speaking

8The widget creation library, developed by David E. Smyth. and copyright Auto-trol Technology Corp. For a full description of the copyright and such, see the directory wcl.

• src/config/machtype.cf: This is used to set platform specific flags. These configuration files are provided for all the platforms that OLC has been tested on so far, but you may need to tweak them to suit your local environment, or you may need to add a new one if you have a different platform.

These flags are:

– HaveTermIO: If 1, it uses SYSV termio style terminal control; if it is 0, it uses BSD-style.

– HaveDefErrno: If 0, /usr/include/sys/errno.h does not define errno or sys errlist, and they need to be defined when they are used.

– HaveSelectMacros: If 0, /usr/include/sys/types.h does not provide the macros for working with the file descriptor sets used by selected (FD SET, FD ZERO, et. al.)

– HaveAnsiIncludes: This should be 1 if you are using an ansi compiler and your system provide ANSI-compiliant include files; otherwise, it will try to use its own.

– HasVFork: Set this if your system provides vfork; otherwise, fork is used in all cases.

– HasPutenv: Set this is your system does not provide setenv; putenv will be used instead.

– HasGcc: Set if you want to use gcc instead of the standard cc.

– HasSaberC: Set if you want to have rules for debugging under Saber included.

• Include files: If you want to change the default location of files, you will need to modify the appropriate include files in src/include and src/include/olc. The default directory setup that OLC expects is:

– /usr/spool/olc to store the question database and logs

– /usr/spool/olc/donelogs to store the logs of the resolved questions temporarily before they are moved to discuss.

– /usr/lib/olc to store the kerberos srvtab, the motd and hours files, and the server configuration files.

– /usr/lib/olc/acls to store the ACLs.

– /usr/lib/olc/specialties to store consultant’s specialties.

– /usr/local to store a local copy of olcr used by the daemon that handles questions entered by mail.

– /usr/adm/olc Used for storing error logs and statistics.

It would be wise to go through all of the .h files in these directories and double check that the locations of the various files, programs, and services are set up as you expect.

• Imakefiles: If you wish to change the locations the binaries will be installed in, you will need to change the individual Imakefiles. Currently, the server binaries are installed in /usr/etc, the client binaries in /usr/athena, and the help files stored in /usr/athena/lib/olc.

Once the configuration has been set up, you should be able to type “make world” at the top level, and it will go through and make the makefiles, add the dependencies, and then proceed to build the binaries. Once this is done, you can do a “make install” to install the binaries.

3 Use without Athena services

3.1 Hesiod

Use of OLC without the Hesiod naming service will have the following effects:

• For the (oreplay/olist/oshow) clients, you must always explicitly specify a server to use with the -s option.

• For the (olcr/olc) clients, you must always explicitly specify the -server option when invoking them, or set the OLCD HOST environment variable.

• For the polld daemon, you must explicitly specify a -host machinename option so it can find the locking daemon.

• for the olcd daemon, you must explicity sepcify a -host machinename option so it can find itself. Additionally, all users asking questions must be in the password file of the server in order to have the “real name” associated with their username be correct; if it cannot find them in the password file, their real name will be “The Unknown User”.

3.2 Zephyr

Use of OLC without the Zephyr location/messaging service will have the following effects^{9}:

• All workstations on which the clients are going to be used must have the writed server installed to allow write to work across the network.

• No broadcast notifications of status changes will be sent out, so the Emacs OLCR client will not be able to automatically update its state.

• The polling daemon will have reduced usefulness, since it can not use zephyr to track the users as they move around. However, it can still be somewhat effective using the “last known location” information that is stored in the database to determine when they leave that particular workstation.

3.3 Kerberos

Use of OLC without the Kerberos authentication service will have the following effects:

• There is no proof that anyone using the system is who they say they are; all that is/can be checked is that the username and uid they claim to be is on the correct acl.

• In the file src/server/rpd/acl files.c you must set the default realm of your site; without kerberos, this can be anything you chose to standardize upon, but this still needs to be set.

• Kerberized clients can work with a non-kerberized server, but non-kerberized clients cannot work with a kerberized server.

3.4 Discuss

• There is no way to save the logs of resolved questions and old MOTDs; they are just deleted.

• It would be easy to drop in hooks to another conferencing system; you just need to replace the functionality of the “lumberjack” program in src/server/lumberjack, which takes the logs and their associated control files from /usr/spool/olc/donelogs and moves them to the appropriate place. If you need to change the interface to whatever does the moving of the logs, the call to the external program is in the file src/server/olcd/log.c in the routine dispose of log().

9Note: you must have the com err package if you zephyr; it is available from athena-dist.mit.edu, and is also used in the kerberos and zephyr distributions

3.5 “Athena”

If the “Athena-compat” flag is not set in the site.def file, you’ll need to specify different default fallback values than the ones used at Athena. Additionally, some of the “friendly” error messages will need to be changed to reflect your site, as will the help files^{10}

• If you are using kerberos, you will need to set server’s default realm DFLT SERVER REALM in

     src/include/olcd.h.

• Verification of the user’s mail address will not be done; your mail delivery service will most likely be sufficiently different that the routines we use here will not work. If you wish to enable it, replace the Athena-specific routine to do this in src/clients/lib/utils.c.

• You will need to specify the local kerberos realm in src/server/olcd/acl files.c

• In order to have information on the machine the client is running on included as part of the question, you will need to have the “machtype” program from Athena, or some equivalent at your site. Since this is not portable, no machine information will be sent by default. This is called from src/clients/lib/ask.c, in the OAsk() routine, if you wish to install your own method for determining the type of machine the client is running on.

• Several clients use the “attach” command to mount other filesystems for them; the widest use of this is to mount the filesystem that contains the stock answers. Depending on your setup, you may be able to get rid of the call to attach completely (if you know that the files will be accessible), or change the command to whatever is appropriate at your site.

4 Installation

Once you have the sources compiled to your satisfaction, you will need to install the binaries and set up the system configuration to allow the clients and server to work together smoothly.

4.1 OLC Clients

4.1.1 olc/olcr

olc, the “user” clients, and olcr, the “consultant” client are actually one and the same binary; it just uses the name it was invoked with to determine which of the commands to make available. The commands available in olc are a subset of the commands available in olcr.

These clients also expect to find their help files by default in the directories /usr/athena/lib/olc/olc help

and /usr/athena/lib/olc/olcr help respectively. These locations are set in src/include/olc/olc.h in
the defines OLC HELP DIR and OLCR HELP DIR.

4.1.2 Xolc

This client depends on being able to find its resources (defined in the file (src/clients/motif/Xolc) in order to function properly; if not, the user interface will look very strange. It expects to find its help files in the directory defined in src/clients/motif/data.h in the define HELP PATH. Additionally, it expects the X-based stock answer browser program to be installed in the location specified by SA LOC in the same file.

10For example, the phone number of our help desk, and “Contact Athena Operations” are appropriate to have at Project Athena; they would not be appropriate for other sites.

4.1.3 Emacs OLCR

The emacs client is not included in the main source tree build, given the different nature of its source files. Additionally, it has a separate set of configuration and setup instructions, which are in src/Emacs/INSTALL. There also is comprehensive documentation for it in the directory src/Emacs/dvi.

4.1.4 Stock Answers

The stock answers system is actually separate from the OLC system; it will work fine on its own, with no athena services, and without any of the OLC programs. Depending on your site, it may be useful to have an entry point to these stock answers outside of your OLC system. There is a script src/browser/curses/olc answers that invokes the browser outside of the OLC programs. If you use it, you will need to modify the script so that it points to the location of the stock answers in your file system, and adapt the “attach” to be a mount, or whatever is appropriate for your site.

The call to olc browser is

olc_browser -r directoryname

where directoryname is the “root” of the stock answer tree. To test this out, you can use the set of sample stock answers included in the distribution; to do this, you’d use

olc_browser -r samples/stock_answers

For more information on setting up the stock answers, see the information in stock answers guide.tex

in doc/guides.

4.2 OLC Daemons

These daemons reside on the OLC server. Typically, they are owned by root, and reside in /usr/etc and in

/usr/local.

4.2.1 olcd

A typical startup for olcd is

   /usr/etc/olcd -inst olx -host fionavar

which is placed in /etc/rc or a similar file so that it is started at boot time. The “inst” argument is only necessary if the “instance” of this server is different than the default one specified in src/include/olc/olc.h in the define OLC SERVICE. The “-host” is only necessary if the SLOC hesiod information for that name does not point to the current location, or if there is no hesiod SLOC information.

4.2.2 polld

A typical startup for polld is

   /usr/etc/polld -inst olx -host fionavar

The arguments are the same as for olcd. Note that this should be placed after olcd in the startup, so that it does not try to contact olcd server with location updates while olcd is still starting up. A short (≈10 sec) sleep may be necessary before the call to polld to do this.

4.2.3 rpd

A typical startup for rpd is

   /usr/etc/rpd

No arguments are needed.

4.3 System files

Several system files need to be modified:

• /etc/services: Add the lines

     write           811/tcp                         # Network write daemon
     olc             2051/tcp                        # OLC locking daemon
     ols             2052/tcp                        # OLC query daemon

• /etc/inetd.conf: Add the line for the network write service:

     write   stream  tcp     nowait  root    /etc/writed     writed

• /etc/syslog.conf: Add the line

     local6.debug /usr/adm/olc/syslog

4.3.1 writed

This needs to be installed on the machines on which the client is going to be run; the typical location is in

/etc/writed.

4.4 Hesiod

If you are using Hesiod, you will need to register the location of the OLC service. It expects to find two entries

Name HesiodNameType Value
olc  SLOC  foo.bar.baz
olc  SERVICE  olc tcp 2051

where “foo.bar.baz” is the name of the machine running the OLC server.

4.5 Kerberos

If you are using kerberos, you will need to get a “srvtab”, or shared secret, for the olc server so that it can authenticate requests and authenticate itself to zephyr. The srvtab should have entries for the services “olc” (and discuss, if you’re going to run authenticated discuss), with the instance being the name of the machine the server resides on. For example, on the machine “fionavar.mit.edu”, there would be entries for “olc.fionavar” and “discuss.fionavar”.

This srvtab needs to be placed in the locations specified by the SRVTAB FILE defines in src/include/olcd.h

and src/include/olcm.h.

4.6 Discuss

If you are going to be using discuss to archive the logs of resolved questions, you will need to create the discuss meetings, and set up a configuration file with their location. The configuration file /usr/lib/olc/ds prefix should contain a line of the form

HOSTNAME.FOO.BAR:/usr/spool/discuss/o

where “hostname.foo.bar” is the name of the machine that the discuss meetings are stored on (usually the name of the local machine), and “/usr/spool/discuss” is the location of the discuss meetings file. The “o” is the standard prefix appended to the name the server uses to find the location of the meeting^{11}. The standard meetings the server expects to find are:

• topic One discuss meeting for each topic, named with the prefix above.

• motd to archive the motds

• hno for canceled questions

• oga for unsolvable questions, marked as such via “forward -unanswered”.

4.7 Mail

If you want to take questions via mail, you will need to have the “olcm” program available on the machine that is taking mail, and add an entry to the mail aliases file of the form^{12}:

olc-test: "|/usr/etc/olcm -s fionavar -t test -k olc.fionavar"

where the -s option specifies the name of the OLC server to be used, the -t option specifies the topic it is to be entered under, and the -k specifies the kerberos principle to be used (which must be present in the srvtab of the machine receiving the mail). The principle must also be on the gask acl of the OLC server.

5 Initial configuration

5.1 User Database

5.2 Acls

The acls are used to control who has access to what functions on the OLC server. Each acl is stored in a separate file in the directory specified by ACL DIR in the file src/include/olcd.h^{13}. The acls currently used are:

• admin: A consultant must be on this acl in order to change or list any acls, or to load information about another user from the database into the server. Additionally, in order to change the hours, you must be on this acl. Also, in order to change a users login status, you must be on this acl.

• consult: In order to be able to done or cancel questions they are connected to, a consultant must be on this ACL. Additionally, a consultant must be on this acl in order to comment on or change the descriptions or topics of questions they are connected to. They must also be on this acl in order to grab questions in their specialty.

• gask: A consultant must be on this acl in order to ask questions on behalf of other people.

• gchtopic: A consultant must be on this acl in order to change the topic of a question he is not connected to.

• gcomment: A consultant must be on this acl in order to be able to comment on or change the description of questions they are not connected to.

11I.e, the meeting /usr/spool/discuss/oemacs would contain the logs of the questions on the “emacs” topic, … /discuss/omotd would contain the archived motds, etc.

12If you are on athena, it will be of the form: olc-test@fionavar.LOCAL: "|/site/usr/local/olcm -s fionavar -t test -k olc.fionavar"@fionavar.LOCAL

13By default, this is /usr/lib/olc/acls

• gmessage: In order to be able to send messages or mail to users you are not connected to, you must be on this acl.

• grab: A consultant must be on this ACL in order to be able to grab questions that are not among one of his specialties.

• gresolve: In order to be able to done, cancel, or forward questions other people are connected to, a consultant must be on this ACL. Additionally, you must be on this acl to sign another consultant “off duty”

• monitor: In order to be able to find out information about another user, including their current status in OLC or to see the log of their question, the consultant must be on this ACL.

• motd: A consultant must be on this acl in order to change the message of the day.

• olc: A user must be on this ACL in order to ask questions, find out the topics that a server supports, get the motd, or get the hours.

• on: In order to be able to sign “on” and get automatically connected to questions, the consultant must be on this ACL.

For a typical setup, all of the consultants would be on the acls:

consult
gcomment
grab
monitor
on

The OLC administrator(s) would be on the acls:

admin
consult
gask
gchtopic
gcomment
gmessage
grab
gresolve
monitor
motd
on

To allow everyone to ask questions, everybody would need to be on the acl^{14}:

olc

A sample set of acls can be found in the directory samples/usr.lib.olc/acls. These acls are read in when the person affected first accesses OLC after the locking daemon starts up, or when the dbload username command in olcr is used to re-load them for a specific person.

14This is done by having the acl entry be *.*@YOUR.REALM.NAME

5.3 Topic List

The list of topics is stored in the file /usr/lib/olc/topics on the server, and is read when the locking daemon starts up. The topics are listed one per line, and must consist of a single world. Anything after a “#” on the line is ignored. This file is send verbatim (including the text after the “#”) when a client asks for a list of topics. So, to have the topics “emacs”, “latex”, “mail”, “unix”, and “zephyr”, you’d have a topics file that looked like:

#########  Supported software
emacs             # the standard Athena editor
latex             # text formatter
mail              # how to send/receive/delete mail, including other sites
unix              # operating system commands and other unix utilities
xwindows          # how to manipulate/create/manage windows on the screen

A sample topics file can be found in samples/usr.lib.olc/topics.

5.4 Specialties

The lists of consultants who have a specialty^{15} in each topic are stored in the directory /usr/lib/olc/specialties on the server, in files named topic.acl. The format of entries in these files is the same as the acl files.

A sample set of specialties can be found in samples/usr.lib.olc/specialties. These specialties are read in when the person affected first accesses OLC after the locking daemon starts up, or when the dbload username command in olcr is used to re-load them for a specific person.

5.5 Database

This database is used to override the default titles and number of questions allowed on a per-user basis. A sample of this file can be found in samples/usr.lib.olc/database; the format is self-explanatory.

If it is desired to override the overall defaults for the number of questions allowed to be asked/answered, this can be done by editing the lines

  user->max_ask = 1;
  user->max_answer = 2;

in the function init dbinfo in the file server/olcd/data utils.c to have the values you desire.

5.6 Machine Information Translation

If you have compiled the source with Athena compatibility and have access to the “machtype” command, the locking daemon will do some translation of the machine information that is inserted after each question into a more “readable” form for humans^{16}. If this is not the case, you can skip this section.

The server expects a comma-separated list of things that make up the machine information to be passed over; it is in the form PROCESSOR, {DISPLAY,}^{∗} MEMORY. The locking daemon reads in the translations from the file /usr/lib/olc/translations when it first receives a question. This file is of the form

#_OF_PROCESSOR_TRANSLATIONS
ABBREV_1
FULL_NAME_1
ABBREV_2

15This “specialty” is used when deciding which consultants to connect automatically to incoming questions

16Specifically, the routine init log in the file src/server/olcd/log.c calls the trans m i function in the same file to do this work

FULL_NAME_2
....
#_OF_DISPLAY_TRANSLATIONS
ABBREV_1
FULL_NAME_1
ABBREV_2
FULL_NAME_2
....

A sample translations file can be found in samples/usr.lib.olc/translations.

6 Support

All of the software and documentation that make up this release are provided under the standard MIT copyright; a copy of this can be found in src/include/mit-copyright.h. In part, it says:

… Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided ”as is” without express or implied warranty.

olc-users@ATHENA.MIT.EDU is a mailing list set up for discussing issues relating to OLC, as well as the place where new releases of the OLC software will announced. Additionally, the mailing list olc@ATHENA.MIT.EDU may be able to provide a reference to consulting expertise in the areas of:

• Setting up an on-line consulting organization;

• Installing OLC in your environment;

• Maintaining OLC in your environment;

• OLC training and documentation ;

• Stock answer development and other on-line consulting tools;

• Modifying and augmenting OLC for your environment;

• and other similar development and organizational issues.

Any such referral is not an endorsement by M.I.T of the services provided by such an organization. M.I.T makes no representations with regard to the suitability or quality of services provided by the referred firms. The reference is made without express or implied warranty.

If you would like to subscribe to it, send a request to olc-request@ATHENA.MIT.EDU. If you find bugs, please mail them to olc-bugs@ATHENA.MIT.EDU.