% $Id: tute.tex,v 1.2 1997/06/20 19:08:02 brlewis Exp $
%
%                Server Operations Documentation Template
%
% This template is intended to aid in the transitioning of a service
% from a development state to an operational one. It is hoped that this
% template, when filled out for a particular service, will answer all
% of the questions the operations group might have about maintaining
% the service. It is also hoped that the information asked for in this
% document will remind the developer of things he or she needed to
% document about the service but may have forgotten.
%
% Of course, the template will have shortcomings, as will any documents
% produced with it. For this and other reasons, the template and those
% documents should not be considered static at all. As new questions
% arise over the course of operating servers, both the documents that
% need to answer the questions and the template itself should be updated
% so that future efforts will learn from this experience.
%
% Similarly, as operations creates procedures for operating different
% services, they should update the documentation to reflect these changes.
% There are some things like this that will be determined by operations,
% and not by the developer. In general, the document should be considered
% the responsibility of both parties, and always kept up to date.
%
% Examples are sometimes used in this template to provide clarity,
% or a guidline for how a particular section might be used. They
% are also used to make the developer think about possible aspects
% of the server not previously considered.
%
% Don't feel constrained by this template. It provides a useful
% organizational framework, but many times more subsections may be
% appropriate. Add them in if that seems the right thing to do. Keep
% in mind that it is desirable to keep the same general format, however.
% Familiarity with a common format used for all documents can make them
% more useful than formatting each one differently. For example, it may
% be better to leave an inapplicable section blank (or say ``not applicable''
% than to remove it. If you think of any changes to the template that
% would be widely useful, suggest them.
%
%
% This template is not to be construed in any way as a list of requirements
% by operations. Filling out this template does not imply that operations
% will be happy to take your service. Operations has not yet produced a
% document of generic server requirements though.
%
% See /mit/slw/src/doc/slw.tex for an example of how this document
% might be filled out.
%

\documentstyle{article}
\title{MIT-Mostly (tute.mit.edu) web service}
\author{Bruce Lewis}
\date{DRAFT: \today}

% Default margins are too wide.
\addtolength{\oddsidemargin}{-.5in}
\addtolength{\evensidemargin}{-.5in}
\addtolength{\textwidth}{1in}

\begin{document}

\maketitle
\tableofcontents
\newpage

\section{Functional Overview}

There is an HTTP server (http://tute.mit.edu/) that mostly allows
connections from MIT hosts, rejecting requests from hosts with names
that do not resolve to the ending "mit.edu". This server will be able to
access files stored in protected directories in the athena.mit.edu AFS
cell, not using AFS tokens, but by an AFS group called mitweb that
includes the IP address of tute.mit.edu.

\section{Server Characteristics}

\subsection{Compatibility}

Because AFS documents are restricted by the server's IP address, this
service cannot coexist with unrestricted web service on the same host.

\subsection{Security}

The information to be protected is not expected to have bulletproof
security.  Users of this service are given caveats at {\tt
<URL:http://web.mit.edu/cwis/tute/mitmostly2.html>}.

\subsection{CPU and Network Loading}

This server gets fewer hits than the unrestricted server, but each
client is more costly because the client's hostname is looked up.

\section{Requirements and Dependencies}

This service has all the requirements of web.mit.edu service.  In
addition, the server's IP address must be part of the AFS group named
mitweb.  Type {\tt pts mem mitweb}

\section{Dependents}

Dependents may be determined through the advanced search page on the
unrestricted web server.  Search for url-references containing
``tute''.

\section{Impacts of Service Failures}

Users will not be able to reach MIT-mostly pages.

\section{Building}

The build process is exactly the same as that of the unrestricted web
service.

\section{Installation}

\begin{enumerate}
\item The server's IP address must be part of the AFS group named
mitweb.  Type {\tt pts mem mitweb}

\item Follow the installation procedure for unrestricted web service.

\item Remove the HostName and DNSLookups lines from the httpd.conf file.

\item Add the following lines to the httpd.conf file:

\end{enumerate}

\begin{verbatim}
HostName        tute.mit.edu

### protection

#
#       Allow only connections from ".mit.edu" hosts.
#       This is suboptimal, because
#         1) it may not cover everything we want, and
#         2) anyone who controls a portion of the reverse-name-resolution
#            space can claim their primary name to be at ".mit.edu".
#       However, it's probably good enough for now.
#
Protection mit-only {
        ServerId        YourProxyName
        Mask            @*.mit.edu
}
Protect * mit-only
\end{verbatim}

\section{Relocation}

No state information is kept.  To migrate, simply follow the
installation process on the new server.

\section{Maintenance and Everything Else}

Same as for unrestricted web service.

\end{document}
