File: spec_4.html

package info (click to toggle)
exim-html 3.20-1
links: PTS
area: main
in suites: etch, etch-m68k, sarge, woody
size: 2,868 kB
ctags: 4,188
sloc: makefile: 40; sh: 19
file content (868 lines) | stat: -rw-r--r-- 30,264 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
     from spec on 25 November 2000 -->

<TITLE>Exim Specification - 4. Building and installing Exim</TITLE>
</HEAD>
<body bgcolor="#FFFFFF" text="#00005A" link="#FF6600" alink="#FF9933" vlink="#990000">
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_3.html">previous</A>, <A HREF="spec_5.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
<P><HR><P>


<H1><A NAME="SEC17" HREF="spec_toc.html#TOC17">4. Building and installing Exim</A></H1>

<P>
<A NAME="IDX52"></A>

</P>
<P>



<H2><A NAME="SEC18" HREF="spec_toc.html#TOC18">4.1 Unpacking</A></H2>

<P>
Exim is distributed as a gzipped or bzipped tar file which, when upacked,
creates a directory with the name of the current release (for example,
<TT>`exim-3.20'</TT>) into which the following files are placed:

<PRE>
<font color=green><TT>`CHANGES'</TT>        contains a reference to where changes are documented
</font>
<TT>`LICENCE'</TT>        the GNU General Public Licence
<TT>`Makefile'</TT>       top-level make file
<TT>`NOTICE'</TT>         conditions for the use of Exim
<TT>`README'</TT>         list of files, directories and simple build instructions
</PRE>

<P>
Other files whose names begin with <TT>`README'</TT> may also be present. The
following subdirectories are created:

<PRE>
<TT>`OS'</TT>             OS-specific files
<TT>`doc'</TT>            documentation files
<TT>`exim_monitor'</TT>   source files for the Exim monitor
<TT>`scripts'</TT>        scripts used in the build process
<TT>`src'</TT>            remaining source files
<TT>`util'</TT>           independent utilities
</PRE>

<P>
Some utilities are contained in the <TT>`src'</TT> directory, and are built with the
Exim binary; those distributed in the <TT>`util'</TT> directory are things like the log
file analyser, which do not depend on any compile-time configuration.

</P>



<H2><A NAME="SEC19" HREF="spec_toc.html#TOC19">4.2 Multiple machine architectures and operating systems</A></H2>

<P>
The building process for Exim is arranged to make it easy to build binaries for
a number of different architectures and operating systems from the same set of
source files. Compilation does not take place in the <TT>`src'</TT> directory. Instead,
a <EM>build directory</EM> is created for each architecture and operating system.
<A NAME="IDX53"></A>
<A NAME="IDX54"></A>
Symbolic links to the sources are installed in this directory, which is where
the actual building takes place.

</P>
<P>
In most cases, Exim can discover the machine architecture and operating system
for itself, but the defaults can be overridden if necessary.

</P>


<H2><A NAME="SEC20" HREF="spec_toc.html#TOC20">4.3 DBM libraries</A></H2>

<P>
<A NAME="IDX55"></A>
Licensed versions of Unix normally contain a library of DBM functions operating
via the `ndbm' interface, and this is what Exim expects by default. Free
versions of Unix seem to vary in what they contain as standard. In particular,
some versions of Linux have no default DBM library, and different distributors
have chosen to bundle different libraries with their packaged versions.
However, the more recent releases seem to have standardised on the Berkeley DB
library.

</P>
<P>
Different DBM libraries have different conventions for naming the files they
use. When a program opens a file called <TT>`dbmfile'</TT>, there are four
possibilities:

</P>

<OL>

<LI>

A traditional ndbm implementation, such as that supplied as part of Solaris 2,
operates on two files called <TT>`dbmfile.dir'</TT> and <TT>`dbmfile.pag'</TT>.

<LI>

The GNU library, <EM>gdbm</EM>, operates on a single file, but makes two different
hard links to it with names <TT>`dbmfile.dir'</TT> and <TT>`dbmfile.pag'</TT>.

<LI>

<A NAME="IDX56"></A>
The Berkeley DB package, if called via its ndbm compatibility interface,
operates on a single file called <TT>`dbmfile.db'</TT>, but otherwise looks to the
programmer exactly the same as the traditional ndbm implementation.

<LI>

If the Berkeley package is used in its native mode, it operates on a single
file called <TT>`dbmfile'</TT>; the programmer's interface is somewhat different to the
traditional ndbm interface.

<LI>

<font color=green>
<A NAME="IDX57"></A>
Yet another DBM library, called tdb, has become available from

<PRE>
<A HREF="http://download.sourceforge.net/tdb">http://download.sourceforge.net/tdb</A>
</PRE>

It has its own interface, and also operates on a single file.
</font>
</OL>

<P>
<A NAME="IDX58"></A>
Exim and its utilities can be compiled to use any of these interfaces. By
default it assumes an interface of type (1), though some operating system
configuration files default to assuming (4). In order to use the Berkeley
DB package in native mode, it is necessary to set USE_DB in an appropriate
configuration file,
<font color=green>
and to use tdb you must set USE_TDB. It may also be necessary to set
DBMLIB, as in one of these lines:

<PRE>
DBMLIB = -ldb
DBMLIB = -ltdb
</PRE>

<P>
To complicate things further, there are now three very different versions of
the Berkeley DB package. Version 1.85 has been stable for quite some time,
releases 2.x were current for a while, but the latest versions are numbered
3.x. Releases 2 and 3 are very different internally and externally from the
1.85 release. All versions of Berkeley DB can be obtained from

<PRE>
<A HREF="http://www.sleepycat.com/">http://www.sleepycat.com/</A>
</PRE>

<P>
but maintenance of version 1.85 has been phased out, and it may not compile on
some systems. Maintenance for the 2.x releases will cease shortly. There is
further discussion about the various DBM libraries in the file
<TT>`doc/dbm.discuss.txt'</TT>.
</font>

</P>



<H2><A NAME="SEC21" HREF="spec_toc.html#TOC21">4.4 Pre-building configuration</A></H2>

<P>
<A NAME="IDX59"></A>
<A NAME="IDX60"></A>
<A NAME="IDX61"></A>
<A NAME="IDX62"></A>
Before building Exim, a local configuration file that specifies options
independent of any operating system has to be created with the name
<TT>`Local/Makefile'</TT>. A template for this file is supplied as the file
<TT>`src/EDITME'</TT>, and it contains full descriptions of all the option settings
therein.
<font color=green>
If you are building Exim for the first time, the simplest thing to do is to
copy <TT>`src/EDITME'</TT> to <TT>`Local/Makefile'</TT>, then read it and edit it appropriately.
</font>

</P>
<P>
Default values are supplied for everything except the settings that specify the
locations of the run time configuration file and the directory for holding Exim
binaries. These must be given, as Exim will not build without them.
There are a few parameters that can be specified either at build time or at run
time to enable the same binary to be used on a number of different machines.
However, if the locations of Exim's spool directory and log file directory (if
not within the spool directory) are fixed, it is recommended that you specify
them in <TT>`Local/Makefile'</TT> instead of at run time so that errors detected early
in Exim's execution (such as a malformed configuration file) can be logged.

</P>
<P>
<A NAME="IDX63"></A>
<A NAME="IDX64"></A>
If you are going to build the Exim monitor, a similar configuration process is
required. The file <TT>`exim_monitor/EDITME'</TT> must be edited appropriately for your
installation and saved under the name <TT>`Local/eximon.conf'</TT>. If you are happy
with the default settings described in <TT>`exim_monitor/EDITME'</TT>,
<TT>`Local/eximon.conf'</TT> can be empty, but it must exist.

</P>
<P>
This is all the configuration that is needed in straightforward cases for known
operating systems. However, the building process is set up so that it is easy
to override options that are set by default or by operating-system-specific
configuration files, for example to change the name of the C compiler, which
defaults to <EM>gcc</EM>. See section 4.9 below for details of how to do
this.

</P>

<P>
<font color=green>


<H2><A NAME="SEC22" HREF="spec_toc.html#TOC22">4.5 Including TLS/SSL encryption support</A></H2>

<P>
<A NAME="IDX65"></A>
<A NAME="IDX66"></A>
<A NAME="IDX67"></A>
Exim can be built to support encrypted SMTP connections, using the STARTTLS
command (RFC 2487). Before you can do this, you must install the OpenSSL
library, which Exim uses for this purpose. There is no cryptographic code in
Exim itself. Once OpenSSL is installed, you can set

<PRE>
SUPPORT_TLS = yes
TLS_LIBS=-lssl -lcrypto
</PRE>

<P>
in <TT>`Local/Makefile'</TT>. You may also need to specify the locations of the OpenSSL
library and include files. For example:

<PRE>
SUPPORT_TLS = yes
TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto
TLS_INCLUDE=-I/usr/local/openssl/include/
</PRE>

<P>
You don't need to set TLS_INCLUDE if the relevant directory is already
specified in INCLUDE.
</font>

</P>



<H2><A NAME="SEC23" HREF="spec_toc.html#TOC23">4.6 Use of tcpwrappers</A></H2>

<P>
<A NAME="IDX68"></A>
<A NAME="IDX69"></A>
Exim can be linked with the <EM>tcpwrappers</EM> library in order to check incoming
SMTP calls using the <EM>tcpwrappers</EM> control files. This may be a convenient
alternative to Exim's own checking facilities for installations that are
already making use of <EM>tcpwrappers</EM> for other purposes. To do this, you should
set USE_TCP_WRAPPERS in <TT>`Local/Makefile'</TT>, arrange for the file
<TT>`tcpd.h'</TT> to be available at compile time, and also ensure that the library
<TT>`libwrap.a'</TT> is available at link time, typically by including -<EM>lwrap</EM> in
EXTRALIBS_EXIM.
</font>
For example, if <EM>tcpwrappers</EM> is installed in <TT>`/usr/local'</TT>, you might have

<PRE>
USE_TCP_WRAPPERS=yes
CFLAGS=-O -I/usr/local/include
<font color=green>EXTRALIBS_EXIM=-L/usr/local/lib -lwrap
</font>
</PRE>

<P>
in <TT>`Local/Makefile'</TT>. The name to use in the <EM>tcpwrappers</EM> control files is
`exim'. For example, the line

<PRE>
exim : LOCAL  192.168.0.  .friendly.domain
</PRE>

<P>
in your <TT>`/etc/hosts.allow'</TT> file allows connections from the local host, from
the subnet 192.168.0.0/24, and from all hosts in <EM>friendly.domain</EM>. All
other connections are denied. Consult the <EM>tcpwrappers</EM> documentation for
further details.

</P>



<H2><A NAME="SEC24" HREF="spec_toc.html#TOC24">4.7 Including support for IPv6</A></H2>

<P>
<A NAME="IDX70"></A>
<font color=green>
Exim contains code for use on systems that have IPv6 support. Setting
HAVE_IPV6=YES in <TT>`Local/Makefile'</TT> causes the IPv6 code to be included; it
may also be necessary to set IPV6_INCLUDE and IPV6_LIBS on systems
where the IPv6 support is not fully integrated into the normal include and
library files.
</font>

</P>



<H2><A NAME="SEC25" HREF="spec_toc.html#TOC25">4.8 The building process</A></H2>

<P>
<A NAME="IDX71"></A>
<A NAME="IDX72"></A>
Once <TT>`Local/Makefile'</TT> (and <TT>`Local/eximon.conf'</TT>, if required) have been
created, run <EM>make</EM> at the top level. It determines the architecture and
operating system types, and creates a build directory if one does not exist.
For example, on a Sun system running Solaris 2.5.1, the directory
<TT>`build-SunOS5-5.5.1-sparc'</TT> is created.
<A NAME="IDX73"></A>
<A NAME="IDX74"></A>
Symbolic links to relevant source files are installed in the build directory.

</P>
<P>
If this is the first time <EM>make</EM> has been run, it calls a script which builds
a make file inside the build directory, using the configuration files from the
<TT>`Local'</TT> directory. The new make file is then passed to another instance of
<EM>make</EM> which does the real work, building a number of utility scripts, and
then compiling and linking the binaries for the Exim monitor (if configured), a
number of utilities, and finally Exim itself. The command <EM>make makefile</EM> can
be used to force a rebuild of the make file in the build directory, should this
ever be necessary.

</P>
<P>
If you have problems building Exim, check for any comments there may be in the
<TT>`README'</TT> file concerning your operating system, and also take a look at the
FAQ, where some common problems are covered.

</P>



<H2><A NAME="SEC26" HREF="spec_toc.html#TOC26">4.9 Overriding build-time options for Exim</A></H2>

<P>
<A NAME="IDX75"></A>
The main make file that is created at the beginning of the building process
consists of the concatenation of a number of files which set configuration
values, followed by a fixed set of <EM>make</EM> instructions. If a value is set
more than once, the last setting overrides any previous ones. This provides a
convenient way of overriding defaults. The files that are concatenated are, in
order:

<PRE>
OS/Makefile-Default
OS/Makefile-&#60;<EM>ostype</EM>&#62;
Local/Makefile
Local/Makefile-&#60;<EM>ostype</EM>&#62;
Local/Makefile-&#60;<EM>archtype</EM>&#62;
Local/Makefile-&#60;<EM>ostype</EM>&#62;-&#60;<EM>archtype</EM>&#62;
OS/Makefile-Base
</PRE>

<P>
<A NAME="IDX76"></A>
where &#60;<EM>ostype</EM>&#62; is the operating system type and &#60;<EM>archtype</EM>&#62; is the
<A NAME="IDX77"></A>
<A NAME="IDX78"></A>
architecture type. <TT>`Local/Makefile'</TT> is required to exist, and the building
process fails if it is absent. The other three <TT>`Local'</TT> files are optional,
and are often not needed.

</P>
<P>
The values used for &#60;<EM>ostype</EM>&#62; and &#60;<EM>archtype</EM>&#62; are obtained from scripts
called <TT>`scripts/os-type'</TT> and <TT>`scripts/arch-type'</TT> respectively. If either of
the environment variables EXIM_OSTYPE or EXIM_ARCHTYPE is set, their
values are used, thereby providing a means of forcing particular settings.
Otherwise, the scripts try to get values from the <EM>uname</EM> command. If this
fails, the shell variables OSTYPE and ARCHTYPE are inspected. A number
of <EM>ad hoc</EM> transformations are then applied, to produce the standard names
that Exim expects. You can run these scripts directly from the shell in order
to find out what values are being used on your system.

</P>

<P>
<TT>`OS/Makefile-Default'</TT> contains comments about the variables that are set
therein. Some (but not all) are mentioned below. If there is something that
needs changing, review the contents of this file and the contents of the make
file for your operating system (<TT>`OS/Makefile-&#60;<EM>ostype</EM>&#62;'</TT>) to see what the
default values are.

</P>

<P>
If you need to change any of the values that are set in <TT>`OS/Makefile-Default'</TT>
or in <TT>`OS/Makefile-&#60;<EM>ostype</EM>&#62;'</TT>, or to add any new definitions, do so by putting
the new values in an appropriate <TT>`Local'</TT> file.
For example, to specify that the C compiler is called <EM>cc</EM> rather than <EM>gcc</EM>
<A NAME="IDX79"></A>
<A NAME="IDX80"></A>
<A NAME="IDX81"></A>
when compiling in the OSF1 operating system, and that it is to be to be called
with the flag -<EM>std1</EM>, create a file called <TT>`Local/Makefile-OSF1'</TT> containing
the lines

<PRE>
CC=cc
CFLAGS=-std1
</PRE>

<P>
This makes it easy to transfer your configuration settings to new versions of
Exim simply by copying the contents of the <TT>`Local'</TT> directory.

</P>
<P>
<A NAME="IDX82"></A>
<A NAME="IDX83"></A>
<A NAME="IDX84"></A>
<A NAME="IDX85"></A>
Exim contains support for doing LDAP, NIS, NIS+, and other kinds of file
lookup, but not all systems have these components installed, so the default is
not to include the relevant code in the binary. All the different kinds of file
and database lookup that Exim supports are implemented as separate code modules
which are included only if the relevant compile-time options are set. In the
case of LDAP, NIS, and NIS+, the settings for <TT>`Local/Makefile'</TT> are:

<PRE>
LOOKUP_LDAP=yes
LOOKUP_NIS=yes
LOOKUP_NISPLUS=yes
</PRE>

<P>
and similar settings apply to the other lookup types. In most cases the
relevant include files and interface libraries need to be installed before
compiling Exim.
<A NAME="IDX86"></A>
However, in the case of cdb, which is included in the binary only if

<PRE>
LOOKUP_CDB=yes
</PRE>

<P>
is set, the code is entirely contained within Exim, and no external include
files or libraries are required.

</P>
<P>
When a lookup type is not included in the binary, attempts to configure Exim to
use it cause configuration errors.

</P>

<P>
<A NAME="IDX87"></A>
Exim can be linked with an embedded Perl interpreter, allowing Perl
subroutines to be called during string expansion. To enable this facility,

<PRE>
EXIM_PERL=perl.o
</PRE>

<P>
must be defined in <TT>`Local/Makefile'</TT>. Details of this facility are given in
chapter 10.

</P>
<P>
<A NAME="IDX88"></A>
The location of the X11 libraries is something that varies a lot between
operating systems, and of course there are different versions of X11 to cope
with. The following three variables are set in <TT>`OS/Makefile-Default'</TT>:

<PRE>
X11=/usr/X11R5
XINCLUDE=-I$(X11)/include
XLFLAGS=-L$(X11)/lib
</PRE>

<P>
These are overridden in some of the operating-system configuration files. For
example, in <TT>`OS/Makefile-SunOS5'</TT> there is

<PRE>
X11=/usr/openwin
XINCLUDE=-I$(X11)/include
XLFLAGS=-L$(X11)/lib -R$(X11)/lib
</PRE>

<P>
If you need to override the default setting for your operating system, place a
definition of all three of these variables into your
<TT>`Local/Makefile-&#60;<EM>ostype</EM>&#62;'</TT> file.

</P>
<P>
<A NAME="IDX89"></A>
If you need to add any extra libraries to the link steps, these can be put in a
variable called EXTRALIBS, which appears in all the link commands, but by
default is not defined.
<font color=green>
In contrast, EXTRALIBS_EXIM is used only on the command for linking the
main Exim binary, and not for any associated utilities.
</font>
There is also DBMLIB, which appears in the link commands for binaries that
use DBM functions (see also section 4.3). Finally, there is
EXTRALIBS_EXIMON, which appears only in the link step for the Exim monitor
binary, and which can be used, for example, to include additional X11
libraries.

</P>
<P>
<A NAME="IDX90"></A>
Another variable which is not normally defined is STDERR_FILE. This
defines a file to which debugging output is written if the -<EM>df</EM> flag is set,
and is of use when running Exim under <EM>inetd</EM>.

</P>
<P>
<A NAME="IDX91"></A>
Yet another variable which should not normally be needed is ERRNO_QUOTA.
Exim needs to know which error the operating system gives when writing to a
file fails because the user is over quota. POSIX specifies an error called
EDQUOT and
<A NAME="IDX92"></A>
this is present in the latest versions of all the systems Exim has been ported
to at the time of writing. However, it is not present in earlier versions of
SunOS5, which use ENOSPC instead.
<A NAME="IDX93"></A>
The code of Exim defaults to using EDQUOT if it is defined, and ENOSPC
otherwise. You should set ERRNO_QUOTA only if your system uses some
completely different error code.

</P>
<P>
<A NAME="IDX94"></A>
<A NAME="IDX95"></A>
The make file copes with rebuilding Exim correctly if any of the configuration
files are edited. However, if an optional configuration file is deleted, it is
necessary to touch the associated non-optional file (that is, <TT>`Local/Makefile'</TT>
or <TT>`Local/eximon.conf'</TT>) before rebuilding.

</P>


<H2><A NAME="SEC27" HREF="spec_toc.html#TOC27">4.10 OS-specific header files</A></H2>

<P>
<A NAME="IDX96"></A>
<A NAME="IDX97"></A>
<A NAME="IDX98"></A>
The <TT>`OS'</TT> directory contains a number of files with names of the form
<TT>`os.h-&#60;<EM>ostype</EM>&#62;'</TT>. These are system-specific C header files that should not
normally need to be changed. There is a list of macro settings that are
recognized in the file <TT>`OS/os.configuring'</TT>, which should be consulted if you
are porting Exim to a new operating system.

</P>



<H2><A NAME="SEC28" HREF="spec_toc.html#TOC28">4.11 Overriding build-time options for the monitor</A></H2>

<P>
A similar process is used for overriding things when building the Exim monitor,
where the files that are involved are

<PRE>
OS/eximon.conf-Default
OS/eximon.conf-&#60;<EM>ostype</EM>&#62;
Local/eximon.conf
Local/eximon.conf-&#60;<EM>ostype</EM>&#62;
Local/eximon.conf-&#60;<EM>archtype</EM>&#62;
Local/eximon.conf-&#60;<EM>ostype</EM>&#62;-&#60;<EM>archtype</EM>&#62;

</PRE>

<P>
<A NAME="IDX99"></A>
As with Exim itself, the final three files need not exist, and in this case the
<TT>`OS/eximon.conf-&#60;<EM>ostype</EM>&#62;'</TT> file is also optional. The default values in
<TT>`OS/eximon.conf-Default'</TT> can be overridden dynamically by setting environment
variables of the same name, preceded by EXIMON_. For example, setting
EXIMON_LOG_DEPTH in the environment overrides the value of
LOG_DEPTH at run time.

</P>



<H2><A NAME="SEC29" HREF="spec_toc.html#TOC29">4.12 Installing commands and scripts</A></H2>

<P>
<A NAME="IDX100"></A>
<A NAME="IDX101"></A>
The script <TT>`scripts/exim_install'</TT> copies binaries and utility scripts into the
directory whose name is specified by the BIN_DIRECTORY setting in
<TT>`Local/Makefile'</TT>. Files are copied only if they are newer than any versions
already in the binary directory, and old versions are renamed by adding the
suffix <TT>`.O'</TT> to their names.

</P>
<P>
The command <EM>make install</EM> runs the <EM>exim_install</EM> script with no arguments.
It can be run independently with arguments specifying which files are to be
copied, from within a build directory. For example,

<PRE>
(cd build-SunOS5-sparc; ../scripts/exim_install exim)
</PRE>

<P>
copies just the main binary file. The main <EM>exim</EM> binary is required to be
owned by root and setuid,
<A NAME="IDX102"></A>
for normal configurations. In some special cases (for example, if a host is
doing no local deliveries) is is possible to run Exim in other ways. If the
binary is run by a root process, the effect is the same as if it were setuid
root.
The install script tries to set root as the owner of the main binary, and to
make it setuid. It should therefore normally be run as root. If you
want to see what the script will do before running it for real, use the -<EM>n</EM>
option (for which root is not needed):

<PRE>
(cd build-SunOS5-5.5.1-sparc; ../scripts/exim_install -n)
</PRE>

<P>
Exim's run time configuration file is named by the CONFIGURE_FILE setting
<A NAME="IDX103"></A>
in <TT>`Local/Makefile'</TT>. If this file does not exist, the default configuration
file <TT>`src/configure.default'</TT> is copied there by the installation script. If a
run time configuration file already exists, it is left alone. The default
configuration uses the local host's name as the only local domain, and is set
up to do local deliveries into the shared directory <TT>`/var/mail'</TT>, running as the
local user. Aliases in <TT>`/etc/aliases'</TT> and <TT>`.forward'</TT> files in users' home
directories are supported, but no NIS or NIS+ support is configured. Remote
domains are routed using the DNS, with delivery over SMTP.

</P>


<H2><A NAME="SEC30" HREF="spec_toc.html#TOC30">4.13 Installing info documentation</A></H2>

<P>
Not all systems use the GNU <EM>info</EM> system for documentation, and for this
reason, the Texinfo source of Exim's documentation is not included in the main
distribution. Instead it is available separately from the ftp site (see section
1.2).

</P>
<P>
If you have defined INFO_DIRECTORY in <TT>`Local/Makefile'</TT> and the Texinfo
source of the documentation is found in the source tree, running <EM>make
install</EM> automatically builds the info files and installs them.

</P>



<H2><A NAME="SEC31" HREF="spec_toc.html#TOC31">4.14 Setting up the spool directory</A></H2>

<P>
<A NAME="IDX104"></A>
When it starts up, Exim tries to create its spool directory if it does not
exist. If a specific Exim uid and gid are specified, these are used for the
owner and group of the spool directory. Sub-directories are automatically
created in the spool directory as necessary.

</P>



<H2><A NAME="SEC32" HREF="spec_toc.html#TOC32">4.15 Testing</A></H2>

<P>
<A NAME="IDX105"></A>
Having installed Exim, you can check that the run time configuration file is
syntactically valid by running the command

<PRE>
exim -bV
</PRE>

<P>
If there are any errors in the configuration file, Exim will output error
messages. Otherwise it just outputs the version number and build date. Some
simple routing tests can be done by using the address testing option. For
example,

<PRE>
exim -v -bt &#60;<EM>local username</EM>&#62;
</PRE>

<P>
should verify that it recognizes a local mailbox, and

<PRE>
exim -v -bt &#60;<EM>remote address</EM>&#62;
</PRE>

<P>
a remote one. Then try getting it to deliver mail, both locally and remotely.
This can be done by passing messages directly to Exim, without going through a
user agent. For example:

<PRE>
exim postmaster@your.domain
From: user@your.domain
To: postmaster@your.domain
Subject: Testing Exim

This is a test message.
^D
</PRE>

<P>
<A NAME="IDX106"></A>
If you encounter problems, look at Exim's log files (<EM>mainlog</EM> and <EM>paniclog</EM>)
to see if there is any relevant information there. Another source of
information is running Exim with debugging turned on, by specifying the -<EM>d</EM>
option. The larger the number after -<EM>d</EM> (up to 9), the more information is
output. With -<EM>d2</EM>, for example, the sequence of directors or routers that
process an address is output. If there's a message stuck on Exim's spool, you
can force a delivery with debugging turned on by a command of the form

<PRE>
exim -d9 -M &#60;<EM>message-id</EM>&#62;
</PRE>

<P>
<A NAME="IDX107"></A>
<A NAME="IDX108"></A>
One specific problem that has shown up on some sites is the inability to do
local deliveries into a single shared mailbox directory that does not have the
`sticky bit' set on it. By default, Exim tries to create a lock file before
writing to a mailbox file, and if it cannot create the lock file, the delivery
is deferred. You can get round this either by setting the `sticky bit' on the
directory, or by setting a specific group for local deliveries and allowing
that group to create files in the directory (see the comments above the
<EM>local_delivery</EM> transport in the default configuration file). Another
approach is to configure Exim not to use lock files, but just to rely on
<EM>fcntl()</EM> locking instead. However, you should do this only if all user agents
also use <EM>fcntl()</EM> locking. For further discussion of locking issues, see
chapter 15.

</P>
<P>
One thing that cannot be tested on a system that is already running a mailer is
the receipt of incoming SMTP mail on the standard SMTP port. However, the -<EM>oX</EM>
option can be used to run an Exim daemon that listens on some other port, or
<EM>inetd</EM> can be used to do this.
The -<EM>bh</EM> option can be used to check out any policy controls on incoming SMTP
mail.

</P>
<P>
Testing a new version on a system that is already running Exim can most easily
be done by building a binary with a different CONFIGURE_FILE setting. From
within the run time configuration, all other file and directory names
that Exim uses can be altered, in order to keep it entirely clear of the
production version.

</P>


<H2><A NAME="SEC33" HREF="spec_toc.html#TOC33">4.16 Switching Exim on</A></H2>

<P>
<A NAME="IDX109"></A>
Building and installing Exim does not of itself put it in general use. The name
by which the system message transfer agent is called by mail user agents is
<font color=green>
either <TT>`/usr/lib/sendmail'</TT>, or <TT>`/usr/sbin/sendmail'</TT> (depending on the operating
system), and it is necessary to make this name point to the <EM>exim</EM> binary in
order to get them to use it. This is normally done by renaming any existing
file and making <TT>`/usr/lib/sendmail'</TT> or <TT>`/usr/sbin/sendmail'</TT>
<A NAME="IDX110"></A>
<A NAME="IDX111"></A>
a symbolic link to the <EM>exim</EM> binary. It is a good idea to remove any setuid
privilege and executable status from the old MTA. It is then necessary to stop
and restart the mailer daemon, if one is running.
</font>

</P>



<H2><A NAME="SEC34" HREF="spec_toc.html#TOC34">4.17 Exim on heavily loaded hosts</A></H2>

<P>
<A NAME="IDX112"></A>
<A NAME="IDX113"></A>
<A NAME="IDX114"></A>
If you are running Exim on a heavily loaded host you should consider installing
a current release of <EM>bind</EM> (from <A HREF="http://www.isc.org">http://www.isc.org</A>) as caching nameserver,
either locally or on a nearby host with a fast network connection. You should
also consider enabling Exim's <EM>split_spool_directory</EM> if you expect to have
large numbers of messages awaiting delivery.

</P>



<H2><A NAME="SEC35" HREF="spec_toc.html#TOC35">4.18 Stopping Exim on Solaris</A></H2>

<P>
The standard command for stopping the mailer daemon on Solaris is

<PRE>
/etc/init.d/sendmail stop
</PRE>

<P>
If <TT>`/usr/lib/sendmail'</TT> has been turned into a symbolic link, this script fails
to stop Exim because it uses the command <EM>ps -e</EM> and greps the output for the
text `sendmail'; this is not present because the actual program name (that is,
`exim') is given by the <EM>ps</EM> command with these options.
A fix that appears to work on Solaris 2.5 and above is to change the script so
that the <EM>ps</EM> command reads

<PRE>
ps -e -o pid,comm
</PRE>

<P>
which causes the name by which the daemon was started (that is,
<TT>`/usr/lib/sendmail'</TT>) to be output. However, this fails if the daemon has been
restarted with SIGHUP because Exim restarts itself using the real file
name. A better solution is to replace the line that finds the process id with
something like

<PRE>
pid=`cat /var/spool/exim/exim-daemon.pid`
</PRE>

<P>
to obtain the daemon's pid directly from the file that Exim saves it in.
See the description of the -<EM>bd</EM> option for details of where Exim writes the
daemon's process id file.

</P>

<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_3.html">previous</A>, <A HREF="spec_5.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>