%
%  Linux-Athena. A SIPB Document
% $Id: linux-athena.tex,v 1.26 1998/08/25 02:17:24 mhpower Exp $
%
\documentstyle[fullpage]{report}
% This avoids a page break just before the last line.
\addtolength{\textheight}{\baselineskip}

\date{August 24, 1998} % automatically updated with time-stamp

\title{
  \begin{center}
    \vspace{1.5in}
    \hspace*{1mm}\special{psfile=funky-owl.PS hoffset=-100}\hspace*{1mm}
    \vspace{2cm}
  \end{center}
  Inessential Linux-Athena}

\author{The Student Information Processing Board
\\ Derek Atkins
%\\ Greg Hudson
\\ Emil Sit
%\\ Erik Nygren
\\ Aaron Ucko
\\ Salvatore Valente
%\\ Jonathon Weiss
}

\def\thesection {\arabic{section}}
\def\thesubsection {\thesection.\arabic{subsection}}
\def\thesubsubsection {\thesubsection .\arabic{subsubsection}}

% We could define some logical style to get out of \tt all the time.

\def\GS {Installing RedHat-Athena Linux on MITnet}
\def\RHversion {4.2}
\def\Kversion {2.0.32}
%\def\Question#1 {\vspace{0.25in}{\em #1}}
\newenvironment{ttquote}{\tt\begin{quote}}{\end{quote}\rm}

\begin{document}

\maketitle
%\sloppypar

%%% still provide info for Slackware lusers?
%%% add info about Linux and Tether?
\section{Introduction}

Congratulations!  You are now reading
the Inessential Guide to using the Linux operating system%
\footnote{If you don't know what Linux is, and you would like to find
  out, a very good source of documentation is the WWW page
  {\tt http://www.linux.org/}.} %
to access all of your favorite Athena services over the MIT network
and the Resnet extension.

This guide assumes that you are using RedHat-Athena.  However, it
should also apply with some changes to other Linux distributions.
Note in particular that SIPB no longer supports Slackware; we
recommend that you seriously consider switching to RedHat.

\subsection{\dots But I'm Not Using RedHat-Athena}

Installing RedHat-Athena is easy; detailed instructions appear in
``\GS.''  If you are running Slackware, any other non-RedHat-based
distribution,%
\footnote{If you are using a recent version of Debian, you may be able
  to follow the instructions for RedHat \RHversion\ with some modifications;
  {\tt dpkg} supports installing RedHat packages now.} %
or an old version of RedHat (older than 2.0), you will have to wipe
out your old installation and install RedHat from scratch.  Before
doing so, you should back up important files lest you lose them.  These
include the contents of {\tt /etc} and any personal files you may have
on your machine.  This procedure can be a nuisance, especially if you
have made a lot of random customizations to your machine, but SIPB
strongly recommends it anyway, particularly if you have not installed
the Linux-Athena software; again, RedHat is the only distribution SIPB
supports.

Before installing, you should know your complete hardware
configuration, as you will be asked for it.  If you cannot determine
this, here are some tips for identifying unknown hardware: A really
cheap network card is likely an NE2000.   If you don't know what kind
of video card you have, a program called {\tt SuperProbe} may tell you.

We should also warn you that new hardware may not be supported; as a
general rule, if the DOS or Windows version of the driver is still
being debugged, the device probably will not work with Linux; if your
hardware is not listed, this may be why.  You may be able to use a
driver for simpler versions of your hardware; for instance, the
generic VGA X server works with almost all video cards.

If you are using ``vanilla'' RedHat \RHversion, you can upgrade to
RedHat-Athena very easily.  Just {\tt su} to or log in as root, and
type the following commands:
\begin{ttquote}
mkdir -p /sipb-nfs/redhat \\
mount sipb-nfs:/redhat /sipb-nfs/redhat \\
rpm -ivh /sipb-nfs/redhat/\RHversion/i386/RedHat/sets/Athena/*
\end{ttquote}

\section{Assumptions}

This paper assumes that you have already successfully
installed RedHat-Athena on your computer.%
\footnote{SIPB offers a brief paper called \GS.  You can pick it up
in W20-557.}  %
You should be able to log in as root and run simple commands.  For
example, you should be able to use the {\tt passwd} command to change
the root password on your computer to be something that nobody else
knows.%
\footnote{If you change your root password you'll have to propagate
  your changes manually to {\tt /etc/passwd.local} because {\tt
    /etc/passwd} is reset on boot.}  %
You will {\bf NOT}, of course, tell {\bf anyone}.%
\footnote{Even if you are tortured.}

This paper also assumes that you are familiar with the basic concepts
of Unix.  For example, you should know what a ``dotfile'' is, you
should know how to change your ``path'', and you should have some idea
what a ``pipe'' is.  You should also know how to navigate around your
filesystem and how to copy and move files.  It might also be helpful
if you were familiar with standard Unix file permissions and
ownership.  If you are not familiar with these terms, then it's a good
idea for you to find a book on Unix for beginners; you could also read
some of Information Systems' documentation (particularly ``Managing
Your Athena Account'') or other SIPB documentation (particularly
``Inessential Athena''), or attend some introductory Athena
minicourses.

\subsection{For More Information\dots}
There are many useful sources for information about Linux.
\begin{itemize}
\item O'Reilly and Associates offers a number of useful books related
  to maintaining and running variants of Unix, and several books
  specifically on Linux. Some of these books are available at the
  Coop.
  
\item For general information on configuring a host for use on the
  net, you should consult the ``{\tt NET-2-HOWTO}'' in {\tt
    /mit/linux/docs/HOWTO}.  They may also be installed on your system
  in {\tt /usr/doc/HOWTO}. Basic configuration for MITnet is covered
  in the SIPB Linux Net Installation (``\GS'') document. If you need
  help after reading these files, call or drop by the SIPB office
  (W20-557, x3-7788) and we will try to help.
  
\item The Usenet newsgroups in the {\tt comp.os.linux.*} hierarchy
  discuss setting up, configuring and using the Linux operating
  system.  You may want to read the newsgroups for a while to get a
  feel for what problems other users encounter.%
  \footnote{SIPB has an Inessential NetNews document, if you want more
    information on reading news.}%
  
\item MIT has four mailing lists concerning Linux, all of which are
  archived in {\tt discuss}:%
\footnote{If you are unfamiliar with {\tt discuss}, you can read
  ``Inessential Discuss,'' available in
  W20-557.}\\
  \begin{tabular}{ll}
    List name & Discuss path \\
    \tt linux-help & \tt charon.mit.edu:/usr/spool/discuss/linux-help \\
    \tt linux-announce & \tt charon.mit.edu:/usr/spool/discuss/linux-athena \\
    \tt linux-dev & \tt charon.mit.edu:/usr/spool/discuss/linux-dev \\
    \tt linux-afs & \tt menelaus.mit.edu:/usr/spool/discuss/linux-afs \\
  \end{tabular} \\
  Please type {\tt blanche linux-announce -a \$USER} to add yourself
  to the {\tt linux-announce} mailing list.  You should probably also
  consider reading {\tt linux-help} because other users may have the
  same questions you do.
  
\item There are many WWW pages concerning Linux.  Two useful ones are
  given by the URLs \break{\tt http://web.mit.edu/linux/www/} and {\tt
    http://www.linux.org/}

\item Man pages are invaluable in gaining an understanding of how
  commands work and how to use them properly. You can read man pages
  by using the {\tt man} command. A typical usage would be {\tt man
    tar} to get help on the usage for ``{\tt tar}''.
\end{itemize}

\section{Kernels}
RedHat-Athena \RHversion\ is based on RedHat Linux release 4.2, the
fourth major release of the RedHat Linux distribution.  This
distribution is based on version \Kversion\ of the Linux kernel.  (A
kernel is the heart of an operating system, providing basic
functionality used by other components.  A distribution includes a
kernel and the rest of the software forming the operating system.)
The latest kernel version that works with Linux-AFS is 2.0.35;
although version \Kversion\ also works fine, you might want to consider
upgrading anyway because version 2.0.35 fixes some problems present in
version \Kversion.  Version 2.1.$n$ kernels will {\em not} be
supported; these kernels are experimental and unsupported by SIPB.

If the kernel you are using does everything you need it to do, you
should be able to keep using it.  However, you might want to install
another kernel, either because you want to use hardware (a sound card,
for instance) not supported by the kernel you currently have installed
or because you would like to upgrade to a newer supported kernel.

Linux-AFS is very dependent on kernel versions, so if you upgrade your
kernel you will also probably need to upgrade Linux-AFS.  See {\tt
  /mit/linux/packages/Linux-AFS/README} for more details.  If you
upgrade to a version 2.0.$n$ kernel from a 1.$m$.$n$ kernel, you will
have to make a lot of other changes; see {\tt
  /mit/linux/kernel/linux-2.0/Changes} for more details.  If you are
using RedHat Linux 3.0 or older and want to use a 2.0.$n$ kernel, it
is probably easiest just to upgrade to RedHat-Athena 4.2.

To actually build a kernel, you should first ensure that the version
you want to install is in {\tt /usr/src/linux}.  If it isn't, you can
obtain a kernel from {\tt /mit/linux/afskern}; all the kernels in this
directory are stable and should work with AFS.  Before you can compile
a kernel, you must first unpack it by running the following commands
as root:
\begin{ttquote}
  cd /usr/src \\
  zcat /mit/linux/afskern/linux-{\em version}.tar.gz | tar xvf -
\end{ttquote}
where {\em version} is the version you want to build.

To build the new kernel, you can now run the following commands as
root:
\begin{ttquote}
  cd /usr/src/linux \\
  make config \\
  make dep \\
  make zImage
\end{ttquote}
After you run these commands, your new kernel will be the file {\tt
  /usr/src/linux/arch/i386/boot/zImage}.  You can test this kernel by
putting it on a floppy: put a blank disk in the drive which DOS would
call {\tt A:} and type (as root)
\begin{ttquote}
  cd /usr/src/linux \\
  make zdisk
\end{ttquote}
If the new kernel works, you can install it with the commands
\begin{ttquote}
  cd /usr/src/linux \\
  make install
\end{ttquote}

If you are building a version 2.0 or newer kernel, you can run {\tt
  make xconfig} or {\tt make menuconfig} instead of {\tt make config}
if you want a friendlier interface.  When configuring the kernel, be
sure to enable module support and to ``set version information on all
symbols for modules''; otherwise, Linux-AFS will not run.  If you have
configured any drivers as modules, you will have to add some steps to
the above process; type {\tt make modules} after compiling the kernel,
and {\tt make modules\_install} after installing it.  More information
on building kernels is available in {\tt
  /mit/linux/docs/HOWTO/Kernel-HOWTO}.


\section{Installing Additional Packages}
If there's a package you would like to use but failed to install
initially, the situation is easy to remedy.  Just NFS-mount {\tt
  sipb-nfs} by typing {\tt mount sipb-nfs:/redhat
  /sipb-nfs/redhat} as root and run {\tt glint}.  When {\tt glint}
starts, click on ``Configure,'' enter {\tt
  /sipb-nfs/redhat/\RHversion/i386/RedHat/RPMS}, and click on
``Save.''  If you then click on ``Available,'' {\tt glint} will allow
you to select more packages to install.  If you are unsure whether a
package is already installed, {\tt glint} will tell you.  (Installed
packages are listed in the first window {\tt glint} shows.)  Another way
to determine which packages are installed is to type {\tt rpm -qa}.
(This will produce a long list, so you'll probably want to save it to
a file.)

\subsection{Updates}
RedHat-Athena will be updated occasionally with fixes to problems
which have been found in it.  To install updated versions of packages
you have installed, attach the {\tt linux} locker and then run the
script
\begin{ttquote}
  /mit/linux/redhat/current/i386/updates/update.pl
\end{ttquote}
as root.  This script will update only packages which you have already
installed and which need to be updated, and will attempt to keep
Athena-specific customizations.  If you are unsure whether there have
been recent updates, run the script anway; if there have been, it will
install them, and if there haven't, it will tell you.

\subsection{Missing Workstation Software}
You will not be able to run all of the software you can run on public
workstations on your computer because many lockers do not have support
for Linux binaries.  Framemaker, for instance, is not currently
available.  As Derek once said,
\begin{quote}
  The SIPB has been capable of convincing many organizations to
  support Linux; however, we can only encourage them, we cannot force
  or coerce anyone to do anything.  Generally we have encouraged
  groups by donating the disk space to hold the Linux binaries.  FYI:
  The third party software like Maple, Matlab, and Xess is only
  available because those companies have seen fit to make their
  products available under Linux.
\end{quote}

\section{Customizing Your Machine}
By default, your machine acts like any private Athena workstation:
among other things, this means that few users can telnet to it, that
there are no local mail addresses, and that it mounts your home
directory by AFS.  You may want to change various aspects of these.

\subsection{User access control}
User information for Unix machines is stored in a file called {\tt
  /etc/passwd}. By default, your system will allow any valid Athena
user to log in when physically at your machine, but only users in this
file to log in remotely (i.e., by telnet or rlogin). In order to allow
users the ability to log in remotely, you need to put them in the {\tt
  passwd} file.

To do this, you need to become root and run 
\begin{ttquote}
/bin/athena/hesinfo {\em user} passwd >> /etc/passwd.local \\
/bin/athena/hesinfo {\em user} passwd >> /etc/passwd
\end{ttquote}
This will append the appropriate user information to the file.  Note
that by default even you aren't in the file, so you'll probably want
to add yourself ASAP.

You may be wondering why you should change {\tt /etc/passwd.local} in
addition to {\tt /etc/passwd}.  The reason is simple: Any changes you
make only to {\tt /etc/passwd} will be lost because {\tt
  /etc/passwd.local} is copied to {\tt /etc/passwd} every time you
boot your machine.  (There are several reasons for this, such as that
it keeps {\tt /etc/passwd} from growing too large and allows for
improved security.)  The same applies to {\tt /etc/group} and {\tt
  /etc/group.local}.

If you wish to restrict access of users of the machine to just those
in the password database, edit the file {\tt /etc/athena/rc.conf} and
change the line {\tt NOCREATE=false} to {\tt NOCREATE=true}. Then run
{\tt touch /etc/nocreate}. This will only allow users in {\tt
  /etc/passwd.local} to log in to the machine whether they try to log
in remotely or at the console.  If you want to change this back,
remove {\tt /etc/nocreate} and change {\tt /etc/athena/rc.conf} to say
{\tt NOCREATE=false} instead of {\tt NOCREATE=true}.

At the other extreme, it is also possible to let everybody log in to
your machine remotely.  If you {\em really} want to do this, set {\tt
  NOREMOTE} to {\tt false} in {\tt /etc/athena/rc.conf} and {\tt rm
  /etc/noremote}.  Note that if {\tt NOREMOTE} is set, people can
still log in at the console; if you don't want them to be able to do
so, set {\tt NOCREATE}.

A third flag you may want to know about is {\tt NOATTACH}, which is
set and unset the same way as the other two flags.  If it is set, home
directories will not be {\tt attach}ed.

\subsection{Local Users}
Although your machine will share Athena's user and group information,
you can add local users and groups as well.  To avoid conflicting with
Athena, we recommend that you give local users and groups numerical
IDs either less than 100 or greater than 32000, and names not
currently used by Athena users or groups.  Also, you'll have to add
local user names to {\tt /etc/localusers} if you want them to receive
mail at your machine:

\subsection{Local Mail Addresses}
By default, mail sent to {\tt blah@{\em hostname}.mit.edu} is treated
as if sent to {\tt blah@mit.edu}, where {\tt blah} is any valid
sequence of characters and {\em hostname} is your hostname.  However,
you can change this behavior by adding {\tt blah} to {\tt
  /etc/localusers}: {\tt echo blah >> /etc/localusers}.

\subsection{Local Home Directory}

If you like, you can store your files on your local hard drive instead
of on Athena. The advantage of this is that you do not have to rely on
AFS servers working or be limited by your Athena quota. On the other
hand, you will have to copy all of your files from your locker to your
hard drive. You will then have to telnet to your machine anytime you
want to access those files.

If you choose to keep a local home directory, note that many programs
have configuration files stored in your home directory.  For example,
{\tt discuss} creates a dotfile called ``{\tt .meetings}'' in your
home directory, and updates it each time you use {\tt discuss}.  These
files will not be in sync with the ones in your Athena home directory.
Keeping these in sync can be annoying. One technique is to
symbolically link the files from your local home directory to your
Athena home directory.

Another alternative is to export some local files via NFS.  This
approach makes the export more transparent, but has one major problem:
NFS is {\bf not} secure, and we recommend that you do not run an NFS
server.  If you really, {\em really} want to export files via NFS,
however, there is a way to make NFS relatively secure: Make sure all
lines in {\tt /etc/exports} are of the form
\begin{ttquote}
  /usr/export\ \ \ \ \ *.mit.edu(root\_squash,ro)
\end{ttquote}
where {\tt /usr/export} is the root of a tree you want to make
publicly available.

The {\tt *.mit.edu} restricts access to machines in the {\tt mit.edu}
domain, the {\tt root\_squash} remaps root to nobody and the {\tt ro}
makes the export read-only.  Read the {\tt exports} man page for more
info.  Be aware that using NFS at all can open up security holes; it
is entirely conceivable that {\em anyone} could read {\em any} file on
your system.  (This may be a little paranoid, but you're much better
off being too paranoid with NFS).

In general, it is probably easier (and safer!) just to use your Athena
home directory.

%You can copy your files to a local drive using
%tar -cf - /mit/joeuser | tar -C /home -xf - 

\subsection{Local Printers}
If you're using RedHat and have installed all necessary packages ({\tt
  lpr}, {\tt printtool}, and probably {\tt ghostscript}), you can run
a program called {\tt printtool}, which will take care of setting
everything up for you.  (Notes: {\tt printtool} needs to be run as
root and under X.  {\tt ghostscript} is not installed by default, so
you will need to install it yourself if you do not have a PostScript
printer.)

In order to be able to print to your printer from other workstations,
you have to follow a more complicated procedure which includes getting
a Hesiod entry for your printer.  If you want to do this, please ask
on {\tt net-help@mit.edu} and somebody will fill you in on the
details.

\subsection{Running FTP and HTTP Servers}
If you want, you can configure your machine as an FTP or HTTP server.
Please remember that running these services may introduce security
holes, and may also slow your machine down.  If you still want to run
them, though, it is easy to do so.

To run an FTP server, install the packages {\tt wu-ftpd} and {\tt
  anon-ftp}, and put the files you want to export in {\tt
  /home/ftp/pub}.  You also need to uncomment the line referring to
ftpd in {\tt /etc/inetd.conf} by removing the {\tt \#} at the
beginning of the line and to restart {\tt inetd} by running the
command {\tt kill -HUP \em pid} as root, where {\em pid} is the
process ID of the running {\tt inetd} process.  (If you do not
understand this, you can also just reboot after editing {\tt
  /etc/inetd.conf}.

In general there is no reason to run a nonanonymous FTP server; you
can always FTP to your account at {\tt ftp.dialup.mit.edu} instead or
use {\tt rcp}.  Nevertheless, it is possible; to do so, you have to
follow the above instructions and then run {\tt /usr/bin/passwd} to
set a local password.  (You need to do this because {\tt ftpd} doesn't
deal with Kerberos.  For that same reason, you will not get tickets
this way.)
  
To run an HTTP server, install the package {\tt apache} and put the
files you want to export in {\tt /home/httpd/html}.  (Icons can go
  in {\tt /home/httpd/icons}, and CGI scripts%
\footnote{CGI scripts may introduce security holes of their own.  Be {\em
    very} careful with them.} %
must go in {\tt /home/httpd/cgi-bin}.)


\section{Security}

By now, you probably have a Linux machine which is on MITnet (and
hence the Internet). One thing every person running a Unix machine on
some network should note is that Unix and the network are probably
both insecure. In general, Unix machines that are newly bought or
newly set up are notoriously insecure. They are probably vulnerable to
any number of attacks.  {\tt http://web.mit.edu/network/security.html}
has general information about Unix system security at MIT.
RedHat-Athena should be relatively safe, but
there are still some things you should probably do, such as adding
yourself to the {\tt netusers} mailing list ({\tt blanche netusers -a
  \$USER}) and reading the {\tt discuss} meeting {\tt
  bloom-picayune:/usr/spool/discuss/linuxch-security}.  Another good
source for information about security holes in RedHat Linux is the WWW
page \break {\tt
  http://www.redhat.com/support/docs/rhl/rh42-errata-general.html}.
(This page also contains information about other problems which RedHat
Linux 4.2 may have.) 

One other very important issue is configuring your machine to support
secure telnets. After installation, your machine will accept incoming
telnets; however, they will {\bf not} be encrypted! This means that if
you log in and type your password, you will be transmitting your
password {\bf in clear text} over the network! This means that anyone
who is on the physical network(s) that your password is transmitted
through will be able to obtain your password, if they are sufficiently
motivated and knowledgeable.\footnote{Look at {\tt
    http://web.mit.edu/telnet/www/scenarios.html} for more
  information.}

In order to support secure incoming telnets, you need what is called a
{\tt srvtab}.  This file contains a secret key which allows your
machine to authenticate incoming users to Kerberos and then encrypt
the connection.  In order to get this file, send mail to {\tt
  accounts} asking for one; be sure to include both your username and
your computer's hostname in the message.  You should receive a
response three to five days later telling you how to retrieve the
file.  You should install it in {\tt /etc/athena/srvtab} and execute
\begin{verbatim}
chown root.root /etc/athena/srvtab
chmod 400 /etc/athena/srvtab
/usr/athena/bin/ksrvutil change
\end{verbatim}
Your {\tt srvtab} should start working in a day or two.  If you
require more assistance, send mail to {\tt net-help}.

Remember that it is important to keep your system secure; if
unauthorized users gain access to your machine, they may be able to
damage your data and the data of other users of your system (including
data stored on Athena accounts).

\subsection{Changing Your Root Password}
It is a good security measure to change your root password every so
often.  However, this procedure is currently difficult because of the
way Athena deals with passwords and {\tt passwd} files.  Here's what
you have to do:
\begin{itemize}
\item Log in as, or {\tt su} to, root.
\item Type {\tt /usr/bin/passwd root} and enter a new root password.
\item Edit {\tt /etc/passwd.local} with your favorite text editor and
  replace the encrypted password following the string ``{\tt root:}'' with
  the encrypted root password from {\tt /etc/passwd}.%
  \footnote{An encrypted password consists of thirteen random-looking
    characters between the first and second colons on a line in a {\tt
      passwd} file.}  %
  Important note: If you do not copy the encrypted password correctly,
  you will have trouble regaining root access on your system.  It is
  best to use your editor's commands to copy it to avoid the
  possibility of error.
\end{itemize}

\subsection{Kerberos Tickets}
Kerberos tickets work on Linux the same way they work on other
operating systems:

Normally, your tickets will be gotten for you during login (i.e.,
xlogin). If you ever want to get tickets manually, type {\tt kinit \em
  username}, where {\em username} is your Athena username.  Enter your
Athena password when prompted. You can check to see that this was
successful by running {\tt klist}.

Your tickets will last for about ten hours and will become useless
after this time.  You can use the {\tt renew} alias to get new
tickets. (This command will work on any Athena workstation.)

If you manually get tickets, you should {\tt kdestroy} them when you
are done.

\subsection{AFS Tokens}
Like Kerberos tickets, AFS tokens contain authentication information
and are automatically gotten for you during login and destroyed upon
logout.  However, they are not the same; as their name suggests, AFS
tokens apply only to AFS, whereas Kerberos tickets are used for
authentication to other MIT servers.

If you want to get AFS tokens manually, you can type {\tt aklog},
optionally followed by a list of cells or paths to authenticate to.
(For instance, {\tt aklog sipb.mit.edu} will authenticate you to the
SIPB cell, and {\tt aklog /mit/sipb} will authenticate you to the SIPB
locker.)  You can verify that this worked by running the command {\tt
  tokens}.

Your tokens should automatically expire at the same time your tickets
do; if you need new tokens, {\tt renew} will get them for you.  ({\tt
  renew} is the one command that works with both tickets and tokens.)

If you manually get tokens, you should run {\tt unlog} when you are
done to destroy them.

\section{Backups}
You should regularly back up any files you store on your local disk.
Howver, there are some things you should know before making backups of
your Linux system.  First, do {\bf not} attempt to back up remote file
systems, particularly not {\tt /afs}.  You also should not back up
{\tt /proc}, as it is not a physical file system.  There are two ways
to do this; either back up each partition separately (the {\tt -l}
flag tells {\tt tar} not to follow mount points; similar options may
exist for other backup software) or explicitly exclude {\tt /afs},
{\tt /proc}, and other mount points.%
\footnote{You can exclude specific files with GNU {\tt tar}: {\tt tar
    cXf {\em exclusionfile} {\em path} {\em dev}} will back up all of
  the files under {\em path} which are not listed in {\em
    exclusionfile} to the device (or file) {\em dev}.}  % 
Other things you probably don't want to backup are {\tt
  /usr/vice/cache} (your AFS cache, whose contents are simply copies
of files on AFS servers stored locally to save time) and directories
named {\tt tmp} (which stands for {\em temporary}).

Also, if there is any chance that somebody else can read your backup,
and particularly if you are backing up over the network,%
\footnote{Network backups can be eavesdropped on unless you encrypt
  the connection with a program like {\tt ssh}.  Make them only if you
  have no other choice.} %
you should be sure to exclude {\tt /etc/passwd*} and {\tt
  /etc/athena/srvtab}.  The contents of {\tt /etc/passwd.local} tell
malicious people who can telnet to your machine.  (The contents also
allow them to determine your root password, but only if you chose an
easily-guessed password, which you shouldn't have done anyway, or if
they have a lot of time or computational power.)  If {\bf anybody}
gets a copy of your {\tt srvtab}, however, the consequences can be
dire.  For instance, somebody with the contents of your {\tt srvtab}
could monitor encrypted connections to your machine, pretend to be
your machine, and convince your machine that he has tickets as any
user.

% \iffalse
% \section{Random Q\&A}
% {\em What is the point of running a name server on my computer instead of
% using MIT's servers directly?}
%
% {\tt named} keeps a cache of names that it has successfully resolved
% using the MIT name servers.  This reduces the load on MIT servers
% since the next time you need to look up the name/IP, it will be able
% to get it from the cache.  It should also make some operations faster.
% \vspace*{0.25in}
% {\em I'm trying to build something and I keep getting errors about
%  ``undefined references.''  What do I do?}
%
% This may be due to the a.out/ELF compatibility problem; if so, you can
%fix it by adding {\tt -b i486-linuxaout} to your {\tt CFLAGS}.
% \fi

\section{Feedback}

You will encounter some problems.  The programs we are providing may
have bugs, the packages may be incomplete, and this documentation may
be lacking. Please tell us what problems you encounter in the process
of Athena-izing your Linux box so we may improve the process.  Send
your comments to {\tt linux-dev@mit.edu}. If you have questions, send
them to {\tt linux-help@mit.edu}.  If you find bugs in programs or the
configuration of Linux-Athena, report them with {\tt sendbug}.


\vfill
{\noindent\it This document is \verb!$Revision: 1.26 $!. Last modified
\verb!$Date: 1998/08/25 02:17:24 $!}

\end{document}
% LocalWords:  netusers http edu www html srvtab athena chown chmod usr afs tmp
% LocalWords:  ksrvutil proc passwd rpm sipb FYI Matlab Xess
%Local Variables:
%time-stamp-start: "\\date{"
%time-stamp-end: "}"
%time-stamp-format: "%b %d, %y"
%End: