DataMuseum.dk

top - metrics - download

    Length: 6561 (0x19a1)
    Types: TextFile
    Names: »general.tex«

└─⟦2d1937cfd⟧ Bits:30007241 EUUGD22: P.P 5.0
    └─⟦dc59850a2⟧ »EurOpenD22/pp5.0/pp-5.tar.Z« 
        └─⟦e5a54fb17⟧ 
            └─⟦this⟧ »pp-5.0/doc/manual/volume1/general.tex« 

TextFile

\chapter {General Considerations}

\section {Overview}

Before rolling the tape onto a disk, there are some general issues which it
is useful to consider.  If you are planning to install PP on more than one
machine, you should read the latter parts of this chapter carefully.

\section {General Requirements}

\subsection{Systems}

PP is designed to be portable to a wide range of \unix/ systems.
Configurations are given for the following systems:
\begin{itemize}
\item	Sun 3 using SunOS 3.X
\item	Sun 3 using SunOS 4.X
\item	Sun 4 using SunOS 4.X
\end{itemize}
It is also known to run on the following systems:
\begin{itemize}
\item	Vax Ultrix
\item	Mips
\end{itemize}

\subsection {Disk space}

A fair amount of space must be made available for the system. The
figures given below are only a guide

The basic distribution tape contains sources amounting to around 7Mb.

You will need approximately 40Mb of headroom extra to compile
everything, although you can do it in stages if you don't have that
much space.

The installed binaries will take up somewhere around 20-30Mb.

The routing table files plus aliases etc may take up about 1Mb if you
have a lot of connectivity.

The \file{dbm} database built from these tables, perhaps another 1-2Mb

Of course you must also allow plenty of space for the mail passing through!

This suggests that you should allow about 50Mb of space for building
everything, and when built, about 25Mb to run the system with whatever
room you feel reasonable for spooling of messages (phew!).

\subsection   {Communications requirements}\index{X25 access}  

PP uses OSI/ROS for its internal communication, using the ISODE
implementation of ROS and the lower layers\cite{ISODE}. It is assumed
that ISODE is installed and available on the system in question. ISODE
ASN.1 tools are also required to build parts of PP. This version of
PP assumes ISODE version \isodevrsn/.

\subsection	{X window system}
The system has a very useful monitoring tool which is written using
the X windowing system\footnote{X Window System is a trademark of MIT}
which is used for managing the MTA as a whole. It is possible to run
an MTA without the console, but not so easily. The console depends on
X11 Release 4 and the Athena Widget set. It will not work under
earlier releases of X11.

There are also present some small programs to do X based alert of
new mail. These programs have the same X requirements.

All binaries should work against release 3
servers.

\subsection	{Quipu}
This release has no requirements on the Quipu X.500 directory service
agent. There is a prototype list channel that utilises the directory
but this is optional. Future releases of PP will require a Quipu DSA.

\section{Specific channel requirements}

Some of the channels in PP have external dependencies. 
\begin{describe}
\item[SMTP]	The Simple Mail Transfer Protocol channel requires the
use of TCP/IP. If the domain name server is to be used, then the
BIND\cite{BIND} resolver library must be provided (see
Table~\ref{tab:makedefs1} on page~\pageref{tab:makedefs1}).

\item[JNT Mail]	This is integrated with the UNIX-NIFTP package,
available from Cambridge (UK) at the following address:
\begin{quote}
Piete Brooks (pb@cl.cam.ac.uk)\\
Cambridge University Computer Laboratory,\\
Cambridge\\
ENGLAND\\
\end{quote}
X.25 access is usually required for this channel.

\item[X.400]	This uses the ISODE lower layers (both 1984 and 1988
variants). For most services X.25, CONS or CLNP is required to run
this channel although it can be run over TCP/IP using
RFC-1006\cite{TSAP.on.TCP}.

\item[UUCP]	This channel requires a working UUCP
installed on the given machine.

\end{describe}

\section{User Agents}

This version of PP does not support any sophisticated user agents. It
provides a mail sending interface of the same approximate
functionality of \pgm{/bin/mail}. It is strongly recommended that the
MH\cite{MH6.5} user agent is considered for use with PP. MH should be
configured with the SMTP transfer option which will connect to PP
though the SMTP protocol (configuration option \verb|mts send/smtp|).
This also allows PP to be accessed from hosts not running PP
directly but with SMTP connectivity. 

{\bf Warning:} MH should be compiled without the \verb|BERK| option.

\section{Compatibility with older MTAs}

PP is designed as a replacement for \man sendmail(8) and MMDF. As such it is
capable of the majority of functions of both (and a great deal more).
However, there are some differences.

\subsection{MMDF}
PP does not support the MMDF syntax that allows a user to give their
address as \verb|user=string@host.domain|.

\subsection{Sendmail}
PP does not support sendmail style mailboxes by default. These can
created by a variety of mechanisms listed later.

Some programs that send mail have compiled into them the
\pgm{sendmail} program. To deal with these, a fake sendmail is
provided that emulates some of the sendmail options.

\section{MTA layout}
Usually PP will support sites with many hosts. It is possible, but
not desirable to run a copy of PP on each host. An MTA is defined
by the existence of a queue (spool area). Each queue should be managed
(in human terms) in order to guarantee good service.

For this reason, the number of MTA's should be kept small, and other
mechanisms used for delivery to local hosts. Possibilities include
\begin{itemize}
\item NFS. This simply consists of NFS mounting (possible through use
of an automounter) the necessary files systems for delivery.
\item Remote access protocols. Use of services such as POP\cite{POP}
may be an alternative.
\item Delivery to a central place which is NFS mounted by clients.
\end{itemize}
For these reasons, some of the PP utility programs may be accessed
remotely using \man rsh(1).

A site with 1000 users and 100 hosts, might consider installing
between 1 and 4 MTA's.  Reasons for choosing MTAs might include:
\begin{itemize}
\item	External communication links
\item	Large host with many users
\item	Fileservers used substantially for mail.
\item	Separate administration domains.
\end{itemize}

\section{Performance}
Currently, not many statistics have been collected on the performance
of PP, and little effort has been made on tuning as yet.  However,
some observed results may be useful.

PP has been running on a Sun 4/330 at UCL handling a large percentage
of the electronic mail. This consists of around 50,000 messages a week
consisting of aorund 175Mb of data. This system is also providing a
directory service and does not show signs of saturation as yet.