Amanda 2.2 INSTALLATION NOTES

This document covers the compilation, installation, and runtime setup of
Amanda 2.2.  

0. BEFORE DOING ANYTHING

    A.  Read this document all the way through.

    B.  Consult the docs/SYSTEM.NOTES file for installation notes
	specific to particular operating systems.  There is often
	important information there, so don't forget this step.

    C.  If you are using KERBEROS authentication, read docs/KERBEROS for
	details on installing and running the kerberized version of
	Amanda.


1. COMPILING THE AMANDA SOURCES

If you have multiple architectures, you only need to install the whole
amanda package on the tape server host (the one with tape drive).  On
the backup client hosts (the ones you are going to dump), you only need
to compile some of the Amanda programs (see section 1.2.B below).

1.1. SOURCE CONFIGURATION:

    A.  Change the CPP variable in the tools/munge script for your site.
	The C preprocessor (CPP) is used to pre-process the subdir
	makefiles and shell scripts.  Use '/lib/cpp', 'cc -E' or some
	equivalent.

    B.  In the config/ subdirectory:
		1. cp options.h-vanilla options.h
		2. edit options.h to suite your site preferences
		3. cp config.h-<your OS> config.h
		4. browse config.h to make sure it matches your OS.

1.2. BUILDING AND INSTALLING THE BINARIES

    A.  Back at the top-level source directory, build the sources:
		1. make
		2. su root; make install

    B.  On all your client architectures, repeat the configuration steps 
	in 1.1 above, then build the client side sources with:
		1. make client
		2. make install-client

    C.  If you have built with USE_VERSION_SUFFIXES, you will want to
	create symlinks to the version you wish to use, eg:
		ln -s amdump-2.2.6 amdump
	This is not done automatically by the install process, so that
	you can have multiple Amanda versions co-existing, and choose
	yourself which to make the default version.


2. SETTING UP YOUR AMANDA CONFIGURATION

2.1. SETTING UP THE TAPE SERVER HOST

    A.  On the server host, choose which user you will run the dumps
	under.  We run all our dumps as bin.  Also, choose some short
	name for your configuration (we use "csd").  This name is used
	by the Amanda commands to choose one of multiple possible
	configurations.

    B.  Create the config directory (eg /etc/amanda/csd) and copy the
	example/ files into that directory.  Edit these files to be correct
	for your site, consulting the amanda(8) man page if necessary.  You
	can also send mail to amanda-users@cs.umd.edu if you are having
	trouble deciding how to set things up.  You will also need to
	create the directory for the log and database files for the
	configuration to use (eg /usr/adm/amanda/csd), and the work
	directory on the holding disk.  These directories need to agree
	with the parameters in amanda.conf.  Don't forget to make all these
	directories writable by the dump user!

	Make sure that you specify the *no-rewind* version of the tape
	device in your amanda.conf file.  This is a frequently encountered
	problem for new sites.

	Note that you might want to temporarily set the "no-record"
	option in all your dumptypes when first installing amanda if
	you'd like to run tests of amanda in parallel with your existing
	dump scheme.  Amanda will then run but will not interfere with
	your current dumpdates.  However, you don't want to run with
	"no-record" under normal operations.

    C.  Put amanda into your crontab.  Here's a sample:
		0 16 * * 1-5 /usr/local/sbin/amcheck -m csd
		45 0 * * 2-6 /usr/local/sbin/amdump csd
	This is for SunOS 4.x, which has a per-user crontab; most other
	systems also require a userid on each cron line.  See your
	cron(8) for details.  With these cron lines, amanda will check
	that the correct tape is in the drive every weekday afternoon at
	4pm (if it isn't, all the operators will get mail).  At 12:45am
	that night the dumps will be run.

    D.  Put the Amanda service into your /etc/services file.  Add
	entry like:
		amanda       10080/udp
	You may choose a different port number if you like, but it must
	match that in the services file on the client hosts too.  

	If you are running NIS (aka YP), you have to enter the amanda
	service into your NIS services database.  Consult your NIS
	documentation for details.

    E.  If the tape server host is itself going to be backed up (as is
	usually the case), you must also follow the client-side install
	instructions below on the server host, INCLUDING setting up the
	.rhosts file so that the server host lets itself in.  This is a
	frequently encountered problem for new sites.


2.2. SET UP THE BACKUP CLIENT HOSTS

    A.  When using BSD-style security, set up your ~dumpuser/.rhosts or
	/etc/hosts.equiv so that the dumpuser is allowed in from the
	server host.

    B.  Set up your raw disk devices so that the dumpuser can read them,
	and /etc/dumpdates so that the dumpuser can write to it.
	Normally this is done by making the disk devices readable by
	(and dumpdates read/writeable by) group `operator', and putting
	the dumpuser into that group.

    C.  Put the Amanda service into your /etc/services file.  Add
	entry like:
		amanda       10080/udp
	You may choose a different port number if you like, but it must
	match that in the services file on the client hosts too.  

	If you are running NIS (aka YP), you have to enter the amanda
	service into your NIS services database.  Consult your NIS
	documentation for details.

    D.  Put the Amanda client service into inetd's config file.  This
	file is usually found in /etc/inetd.conf, but on older systems
	it is /etc/servers.  The format is different on different OSes,
	so you must consult the inetd man page for your site.  Here is
	an example from our site, again from SunOS 4.x:

	    amanda dgram udp wait bin /usr/local/libexec/amanda/amandad amandad

    E.  Kick inetd to make it read its config file.  On most systems you
	can just kill -HUP inetd.  On older systems you may have to kill
	it completely and restart it.  Note that killing/restarting
	inetd is not safe to do unless you are sure that no inetd
	services (like rlogin) are currently in use, otherwise inetd
	will not be able to bind that port and that service will be
	unavailable.

THAT'S IT!  YOU ARE READY TO RUN, UNLESS I FORGOT SOMETHING.  PLEASE send
mail to amanda-users@cs.umd.edu if you have any comments or questions.  I'm
not afraid of negative reviews, so let me have it!

James da Silva <jds@cs.umd.edu>
last updated February 10, 1995.
