+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 4//EN">
-<HTML><HEAD>
-<TITLE>Administration Guide</TITLE>
-<!-- Begin Header Records ========================================== -->
-<!-- /tmp/idwt3570/auagd000.scr converted by idb2h R4.2 (359) ID -->
-<!-- Workbench Version (AIX) on 2 Oct 2000 at 11:42:14 -->
-<META HTTP-EQUIV="updated" CONTENT="Mon, 02 Oct 2000 11:42:13">
-<META HTTP-EQUIV="review" CONTENT="Tue, 02 Oct 2001 11:42:13">
-<META HTTP-EQUIV="expires" CONTENT="Wed, 02 Oct 2002 11:42:13">
-</HEAD><BODY>
-<!-- (C) IBM Corporation 2000. All Rights Reserved -->
-<BODY bgcolor="ffffff">
-<!-- End Header Records ============================================ -->
-<A NAME="Top_Of_Page"></A>
-<H1>Administration Guide</H1>
-<HR><P ALIGN="center"> <A HREF="../index.htm"><IMG SRC="../books.gif" BORDER="0" ALT="[Return to Library]"></A> <A HREF="auagd002.htm#ToC"><IMG SRC="../toc.gif" BORDER="0" ALT="[Contents]"></A> <A HREF="auagd006.htm"><IMG SRC="../prev.gif" BORDER="0" ALT="[Previous Topic]"></A> <A HREF="#Bot_Of_Page"><IMG SRC="../bot.gif" BORDER="0" ALT="[Bottom of Topic]"></A> <A HREF="auagd008.htm"><IMG SRC="../next.gif" BORDER="0" ALT="[Next Topic]"></A> <A HREF="auagd026.htm#HDRINDEX"><IMG SRC="../index.gif" BORDER="0" ALT="[Index]"></A> <P>
-<HR><H1><A NAME="HDRWQ29" HREF="auagd002.htm#ToC_33">Issues in Cell Configuration and Administration</A></H1>
-<P>This chapter discusses many of the issues to consider when
-configuring and administering a cell, and directs you to detailed related
-information available elsewhere in this guide. It is assumed you are
-already familiar with the material in <A HREF="auagd006.htm#HDRWQ5">An Overview of AFS Administration</A>.
-<P>It is best to read this chapter before installing your cell's first
-file server machine or performing any other administrative task.
-<A NAME="IDX5609"></A>
-<A NAME="IDX5610"></A>
-<A NAME="IDX5611"></A>
-<HR><H2><A NAME="HDRWQ30" HREF="auagd002.htm#ToC_34">Differences between AFS and UNIX: A Summary</A></H2>
-<P>AFS behaves like a standard UNIX file system in most
-respects, while also making file sharing easy within and between cells.
-This section describes some differences between AFS and the UNIX file system,
-referring you to more detailed information as appropriate.
-<A NAME="IDX5612"></A>
-<P><H3><A NAME="Header_35" HREF="auagd002.htm#ToC_35">Differences in File and Directory Protection</A></H3>
-<P>AFS augments the standard UNIX file protection mechanism in two
-ways: it associates an <I>access control list</I> (<I>ACL</I>)
-with each directory, and it enables users to define a large number of their
-own groups, which can be placed on ACLs.
-<P>AFS uses ACLs to protect files and directories, rather than relying
-exclusively on the mode bits. This has several implications, which are
-discussed further in the indicated sections:
-<UL>
-<P><LI>AFS ACLs use seven access permissions rather than the three UNIX mode
-bits. See <A HREF="auagd020.htm#HDRWQ567">The AFS ACL Permissions</A>.
-<P><LI>For directories, AFS ignores the UNIX mode bits. For files, AFS
-uses only the first set of mode bits (the <B>owner</B> bits) , and their
-meaning interacts with permissions on the directory's ACL. See <A HREF="auagd020.htm#HDRWQ580">How AFS Interprets the UNIX Mode Bits</A>.
-<P><LI>A directory's ACL protects all of the files in a directory in the
-same manner. To apply a more restrictive set of AFS permissions to
-certain file, place it in directory with a different ACL.
-<P><LI>Moving a file to a different directory changes its protection. See <A HREF="auagd020.htm#HDRWQ566">Differences Between UFS and AFS Data Protection</A>.
-<P><LI>An ACL can include about 20 entries granting different combinations of
-permissions to different users or groups, rather than only the three UNIX
-entities represented by the three sets of mode bits. See <A HREF="auagd020.htm#HDRWQ566">Differences Between UFS and AFS Data Protection</A>.
-<P><LI>You can designate an AFS file as write-only as in the UNIX file system, by
-setting only the <B>w</B> (<B>write</B>) mode bit. You cannot
-designate an AFS directory as write-only, because AFS ignores the mode bits on
-a directory. See <A HREF="auagd020.htm#HDRWQ580">How AFS Interprets the UNIX Mode Bits</A>.
-</UL>
-<P>AFS enables users to define the groups of other users. Placing these
-groups on ACLs extends the same permissions to a number of exactly specified
-users at the same time, which is much more convenient than placing the
-individuals on the ACLs directly. See <A HREF="auagd019.htm#HDRWQ531">Administering the Protection Database</A>.
-<P>There are also system-defined groups, <B>system:anyuser</B> and
-<B>system:authuser</B>, whose presence on an ACL extends access to a
-wide range of users at once. See <A HREF="auagd019.htm#HDRWQ535">The System Groups</A> and <A HREF="auagd020.htm#HDRWQ571">Using Groups on ACLs</A>.
-<A NAME="IDX5613"></A>
-<A NAME="IDX5614"></A>
-<P><H3><A NAME="HDRWQ31" HREF="auagd002.htm#ToC_36">Differences in Authentication</A></H3>
-<P>Just as the AFS filespace is distinct from each
-machine's local file system, AFS authentication is separate from local
-login. This has two practical implications, which are discussed further
-in <A HREF="#HDRWQ65">Using an AFS-modified login Utility</A>.
-<UL>
-<P><LI>To access AFS files, users must both log into the local machine's
-UNIX file system and authenticate with the AFS authentication service.
-(Logging into the local UNIX file system is necessary because the AFS
-filespace is accessed through the Cache Manager, which resides in the local
-machine's kernel.)
-<P>AFS provides a modified login utility for each system type that
-accomplishes both local login and AFS authentication in one step, based on a
-single password. If you choose not to use the AFS-modified login
-utility, your users must login and authenticate in separate steps, as detailed
-in the <I>IBM AFS User Guide</I>.
-<P><LI>Passwords are stored in two separate places: the Authentication
-Database for AFS and each machine's local password file
-(<B>/etc/passwd</B> or equivalent) for the UNIX file system. A
-user's passwords in the two places can differ if desired, though the
-resulting behavior depends on whether and how the cell is using an
-AFS-modified login utility.
-</UL>
-<P><H3><A NAME="Header_37" HREF="auagd002.htm#ToC_37">Differences in the Semantics of Standard UNIX Commands</A></H3>
-<P>This section summarizes how AFS modifies the functionality of some UNIX
-commands.
-<DL>
-<A NAME="IDX5615"></A>
-<A NAME="IDX5616"></A>
-<A NAME="IDX5617"></A>
-<P><DT><B>The chmod command
-</B><DD>Only members of the <B>system:administrators</B> group can use
-this command to turn on the setuid, setgid or sticky mode bits on AFS
-files. For more information, see <A HREF="auagd015.htm#HDRWQ409">Determining if a Client Can Run Setuid Programs</A>.
-<A NAME="IDX5618"></A>
-<A NAME="IDX5619"></A>
-<P><DT><B>The chown command
-</B><DD>Only members of the <B>system:administrators</B> group can issue
-this command on AFS files.
-<A NAME="IDX5620"></A>
-<A NAME="IDX5621"></A>
-<P><DT><B>The chgrp command
-</B><DD>Only members of the <B>system:administrators</B> can issue this
-command on AFS files and directories.
-<A NAME="IDX5622"></A>
-<A NAME="IDX5623"></A>
-<P><DT><B>The ftpd daemon
-</B><DD>The AFS-modified version of this daemon attempts to authenticate remote
-issuers of the <B>ftp</B> command with the local AFS authentication
-service. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
-<A NAME="IDX5624"></A>
-<A NAME="IDX5625"></A>
-<P><DT><B>The groups command
-</B><DD>If the user's AFS tokens are associated with a process authentication
-group (PAG), the output of this command sometimes includes two large
-numbers. To learn about PAGs, see <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
-<A NAME="IDX5626"></A>
-<A NAME="IDX5627"></A>
-<P><DT><B>The inetd daemon
-</B><DD>The AFS-modified version of this daemon authenticates remote issuers of
-the AFS-modified <B>rcp</B> and <B>rsh</B> commands with the local AFS
-authentication service. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
-<P><DT><B>The login utility
-</B><DD>AFS-modified login utilities both log the issuer into the local file
-system and authenticate the user with the AFS authentication service.
-See <A HREF="#HDRWQ65">Using an AFS-modified login Utility</A>.
-<A NAME="IDX5628"></A>
-<A NAME="IDX5629"></A>
-<P><DT><B>The ln command
-</B><DD>This command cannot create hard links between files in different AFS
-directories. See <A HREF="#HDRWQ32">Creating Hard Links</A>.
-<A NAME="IDX5630"></A>
-<A NAME="IDX5631"></A>
-<P><DT><B>The rcp command
-</B><DD>The AFS-modified version of this command enables the issuer to access
-files on the remote machine as an authenticated AFS user. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
-<A NAME="IDX5632"></A>
-<A NAME="IDX5633"></A>
-<P><DT><B>The rlogind daemon
-</B><DD>The AFS-modified version of this daemon authenticates remote issuers of
-the <B>rlogin</B> command with the local AFS authentication
-service. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
-<P>The AFS distribution for some system types possibly does not include a
-modified <B>rlogind</B> program. See the <I>IBM AFS Release
-Notes</I>.
-<A NAME="IDX5634"></A>
-<A NAME="IDX5635"></A>
-<P><DT><B>The remsh or rsh command
-</B><DD>The AFS-modified version of this command enables the issuer to execute
-commands on the remote machine as an authenticated AFS user. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
-</DL>
-<A NAME="IDX5636"></A>
-<A NAME="IDX5637"></A>
-<A NAME="IDX5638"></A>
-<A NAME="IDX5639"></A>
-<A NAME="IDX5640"></A>
-<A NAME="IDX5641"></A>
-<P><H3><A NAME="Header_38" HREF="auagd002.htm#ToC_38">The AFS version of the fsck Command</A></H3>
-<P>Never run the standard UNIX <B>fsck</B> command on an AFS file
-server machine. It does not understand how the File Server organizes
-volume data on disk, and so moves all AFS data into the <B>lost+found</B>
-directory on the partition.
-<P>Instead, use the version of the <B>fsck</B> program that is included in
-the AFS distribution. The <I>IBM AFS Quick Beginnings</I> explains
-how to replace the vendor-supplied <B>fsck</B> program with the AFS
-version as you install each server machine.
-<P>The AFS version functions like the standard <B>fsck</B> program on data
-stored on both UFS and AFS partitions. The appearance of a banner like
-the following as the <B>fsck</B> program initializes confirms that you are
-running the correct one:
-<PRE> --- AFS (R) <VAR>version</VAR> fsck---
-</PRE>
-<P>where <VAR>version</VAR> is the AFS version. For correct results, it
-must match the AFS version of the server binaries in use on the
-machine.
-<P>If you ever accidentally run the standard version of the program, contact
-AFS Product Support immediately. It is sometimes possible to recover
-volume data from the <B>lost+found</B> directory.
-<A NAME="IDX5642"></A>
-<A NAME="IDX5643"></A>
-<P><H3><A NAME="HDRWQ32" HREF="auagd002.htm#ToC_39">Creating Hard Links</A></H3>
-<P>AFS does not allow hard links (created with the UNIX
-<B>ln</B> command) between files that reside in different directories,
-because in that case it is unclear which of the directory's ACLs to
-associate with the link.
-<P>AFS also does not allow hard links to directories, in order to keep the
-file system organized as a tree.
-<P>It is possible to create symbolic links (with the UNIX <B>ln -s</B>
-command) between elements in two different AFS directories, or even between an
-element in AFS and one in a machine's local UNIX file system. Do
-not create a symbolic link to a file whose name begins with either a number
-sign (<B>#</B>) or a percent sign (<B>%</B>), however. The
-Cache Manager interprets such links as a mount point to a regular or
-read/write volume, respectively.
-<A NAME="IDX5644"></A>
-<A NAME="IDX5645"></A>
-<A NAME="IDX5646"></A>
-<P><H3><A NAME="HDRWQ33" HREF="auagd002.htm#ToC_40">AFS Implements Save on Close</A></H3>
-<P>When an application issues the UNIX <B>close</B> system
-call on a file, the Cache Manager performs a synchronous write of the data to
-the File Server that maintains the central copy of the file. It does
-not return control to the application until the File Server has acknowledged
-receipt of the data. For the <B>fsync</B> system call, control does
-not return to the application until the File Server indicates that it has
-written the data to non-volatile storage on the file server machine.
-<P>When an application issues the UNIX <B>write</B> system call, the Cache
-Manager writes modifications to the local AFS client cache only. If the
-local machine crashes or an application program exits without issuing the
-<B>close</B> system call, it is possible that the modifications are not
-recorded in the central copy of the file maintained by the File Server.
-The Cache Manager does sometimes write this type of modified data from the
-cache to the File Server without receiving the <B>close</B> or
-<B>fsync</B> system call, for example if it needs to free cache chunks for
-new data. However, it is not generally possible to predict when the
-Cache Manager transfers modified data to the File Server in this way.
-<P>The implication is that if an application's <B>Save</B> option
-invokes the <B>write</B> system call rather than <B>close</B> or
-<B>fsync</B>, the changes are not necessarily stored permanently on the
-File Server machine. Most application programs issue the
-<B>close</B> system call for save operations, as well as when they finish
-handling a file and when they exit.
-<P><H3><A NAME="Header_41" HREF="auagd002.htm#ToC_41">Setuid Programs</A></H3>
-<A NAME="IDX5647"></A>
-<P>Set the UNIX setuid bit only for the local superuser <B>root</B>;
-this does not present an automatic security risk: the local superuser
-has no special privilege in AFS, but only in the local machine's UNIX
-file system and kernel.
-<P>Any file can be marked with the setuid bit, but only members of the
-<B>system:administrators</B> group can issue the <B>chown</B>
-system call or the <B>/etc/chown</B> command.
-<P>The <B>fs setcell</B> command determines whether setuid programs that
-originate in a foreign cell can run on a given client machine. See <A HREF="auagd015.htm#HDRWQ409">Determining if a Client Can Run Setuid Programs</A>.
-<A NAME="IDX5648"></A>
-<A NAME="IDX5649"></A>
-<A NAME="IDX5650"></A>
-<A NAME="IDX5651"></A>
-<HR><H2><A NAME="HDRWQ34" HREF="auagd002.htm#ToC_42">Choosing a Cell Name</A></H2>
-<P>This section explains how to choose a cell name and explains
-why choosing an appropriate cell name is important.
-<P>Your cell name must distinguish your cell from all others in the AFS global
-namespace. By conventions, the cell name is the second element in any
-AFS pathname; therefore, a unique cell name guarantees that every AFS
-pathname uniquely identifies a file, even if cells use the same directory
-names at lower levels in their local AFS filespace. For example, both
-the ABC Corporation cell and the State University cell can have a home
-directory for the user <B>pat</B>, because the pathnames are
-distinct: <B>/afs/abc.com/usr/pat</B> and
-<B>/afs/stateu.edu/usr/pat</B>.
-<P>By convention, cell names follow the ARPA Internet Domain System
-conventions for site names. If you are already an Internet site, then
-it is simplest to choose your Internet domain name as the cellname.
-<P>If you are not an Internet site, it is best to choose a unique
-Internet-style name, particularly if you plan to connect to the Internet in
-the future. AFS Product Support is available for help in selecting an
-appropriate name. There are a few constraints on AFS cell names:
-<UL>
-<P><LI>It can contain as many as 64 characters, but shorter names are better
-because the cell name frequently is part of machine and file names. If
-your cell name is long, you can reduce pathname length by creating a symbolic
-link to the complete cell name, at the second level in your file tree.
-See <A HREF="#HDRWQ42">The Second (Cellname) Level</A>.
-<P><LI>To guarantee it is suitable for different operating system types, the cell
-name can contain only lowercase characters, numbers, underscores, dashes, and
-periods. Do not include command shell metacharacters.
-<P><LI>It can include any number of fields, which are conventionally separated by
-periods (see the examples below).
-<P><LI>It must end in a suffix that indicates the type of institution it is, or
-the country in which it is situated. The following are some of the
-standard suffixes:
-<DL>
-<P><DT><B>.com
-</B><DD>For businesses and other commercial organizations. Example:
-<B>abc.com</B> for the ABC Corporation cell.
-<P><DT><B>.edu
-</B><DD>For educational institutions such as universities. Example:
-<B>stateu.edu</B> for the State University cell.
-<P><DT><B>.gov
-</B><DD>For United States government institutions.
-<P><DT><B>.mil
-</B><DD>For United States military installations.
-</DL>
-</UL>
-<P>Other suffixes are available if none of these are appropriate.
-<A NAME="IDX5652"></A>
-<A NAME="IDX5653"></A>
-You can learn about suffixes by calling the Defense Data Network [Internet]
-Network Information Center in the United States at (800) 235-3155. The
-NIC can also provide you with the forms necessary for registering your cell
-name as an Internet domain name. Registering your name prevents another
-Internet site from adopting the name later.
-<A NAME="IDX5654"></A>
-<A NAME="IDX5655"></A>
-<A NAME="IDX5656"></A>
-<A NAME="IDX5657"></A>
-<P><H3><A NAME="Header_43" HREF="auagd002.htm#ToC_43">How to Set the Cell Name</A></H3>
-<P>The cell name is recorded in two files on the local disk of each file
-server and client machine. Among other functions, these files define
-the machine's cell membership and so affect how programs and processes
-run on the machine; see <A HREF="#HDRWQ35">Why Choosing the Appropriate Cell Name is Important</A>. The procedure for setting the cell name is different
-for the two types of machines.
-<P>For file server machines, the two files that record the cell name are the
-<B>/usr/afs/etc/ThisCell</B> and <B>/usr/afs/etc/CellServDB</B>
-files. As described more explicitly in the <I>IBM AFS Quick
-Beginnings</I>, you set the cell name in both by issuing the <B>bos
-setcellname</B> command on the first file server machine you install in your
-cell. It is not usually necessary to issue the command again. If
-you run the United States edition of AFS and use the Update Server, it
-distributes its copy of the <B>ThisCell</B> and <B>CellServDB</B>
-files to additional server machines that you install. If you use the
-international edition of AFS, the <I>IBM AFS Quick Beginnings</I> explains
-how to copy the files manually.
-<P>For client machines, the two files that record the cell name are the
-<B>/usr/vice/etc/ThisCell</B> and <B>/usr/vice/etc/CellServDB</B>
-files. You create these files on a per-client basis, either with a text
-editor or by copying them onto the machine from a central source in
-AFS. See <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A> for details.
-<P>Change the cell name in these files only when you want to transfer the
-machine to a different cell (it can only belong to one cell at a time).
-If the machine is a file server, follow the complete set of instructions in
-the <I>IBM AFS Quick Beginnings</I> for configuring a new cell. If
-the machine is a client, all you need to do is change the files appropriately
-and reboot the machine. The next section explains further the negative
-consequences of changing the name of an existing cell.
-<P>To set the default cell name used by most AFS commands without changing the
-local <B>/usr/vice/etc/ThisCell</B> file, set the AFSCELL environment
-variable in the command shell. It is worth setting this variable if you
-need to complete significant administrative work in a foreign cell.
-<TABLE><TR><TD ALIGN="LEFT" VALIGN="TOP"><B>Note:</B></TD><TD ALIGN="LEFT" VALIGN="TOP">The <B>fs checkservers</B> and <B>fs mkmount</B> commands do not use
-the AFSCELL variable. The <B>fs checkservers</B> command always
-defaults to the cell named in the <B>ThisCell</B> file, unless the
-<B>-cell</B> argument is used. The <B>fs mkmount</B> command
-defaults to the cell in which the parent directory of the new mount point
-resides.
-</TD></TR></TABLE>
-<A NAME="IDX5658"></A>
-<P><H3><A NAME="HDRWQ35" HREF="auagd002.htm#ToC_44">Why Choosing the Appropriate Cell Name is Important</A></H3>
-<P>Take care to select a cell name that is suitable for
-long-term use. Changing a cell name later is complicated. An
-appropriate cell name is important because it is the second element in the
-pathname of all files in a cell's file tree. Because each cell
-name is unique, its presence in an AFS pathname makes the pathname unique in
-the AFS global namespace, even if multiple cells use similar filespace
-organization at lower levels. For instance, it means that every cell
-can have a home directory called <B>/afs/<VAR>cellname</VAR>/usr/pat</B>
-without causing a conflict. The presence of the cell name in pathnames
-also means that users in every cell use the same pathname to access a file,
-whether the file resides in their local cell or in a foreign cell.
-<P>Another reason to choose the correct cell name early in the process of
-installing your cell is that the cell membership defined in each
-machine's <B>ThisCell</B> file affects the performance of many
-programs and processes running on the machine. For instance, AFS
-commands (<B>fs</B>, <B>kas</B>, <B>pts</B> and <B>vos</B>
-commands) by default execute in the cell of the machine on which they are
-issued. The command interpreters check the <B>ThisCell</B> file on
-the local disk and then contact the database server machines listed in the
-<B>CellServDB</B> file for the indicated cell (the <B>bos</B> commands
-work differently because the issuer always has to name of the machine on which
-to run the command).
-<P>The <B>ThisCell</B> file also determines the cell for which a user
-receives an AFS token when he or she logs in to a machine. The cell
-name also plays a role in security. As it converts a user password into
-an encryption key for storage in the Authentication Database, the
-Authentication Server combines the password with the cell name found in the
-<B>ThisCell</B> file. AFS-modified login utilities use the same
-algorithm to convert the user's password into an encryption key before
-contacting the Authentication Server to obtain a token for the user.
-(For a description of how AFS's security system uses encryption keys, see
-<A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.)
-<P>This method of converting passwords into encryption keys means that the
-same password results in different keys in different cells. Even if a
-user uses the same password in multiple cells, obtaining a user's token
-from one cell does not enable unauthorized access to the user's account
-in another cell.
-<P>If you change the cell name, you must change the <B>ThisCell</B> and
-<B>CellServDB</B> files on every server and client machine. Failure
-to change them all can prevent login, because the encryption keys produced by
-the login utility do not match the keys stored in the Authentication
-Database. In addition, many commands from the AFS suites do not work as
-expected.
-<A NAME="IDX5659"></A>
-<A NAME="IDX5660"></A>
-<A NAME="IDX5661"></A>
-<HR><H2><A NAME="HDRWQ36" HREF="auagd002.htm#ToC_45">Participating in the AFS Global Namespace</A></H2>
-<P>Participating in the AFS global namespace makes your
-cell's local file tree visible to AFS users in foreign cells and makes
-other cells' file trees visible to your local users. It makes file
-sharing across cells just as easy as sharing within a cell. This
-section outlines the procedures necessary for participating in the global
-namespace.
-<UL>
-<P><LI>Participation in the global namespace is not mandatory. Some cells
-use AFS primarily to facilitate file sharing within the cell, and are not
-interested in providing their users with access to foreign cells.
-<P><LI>Making your file tree visible does not mean making it vulnerable.
-You control how foreign users access your cell using the same protection
-mechanisms that control local users' access. See <A HREF="#HDRWQ40">Granting and Denying Foreign Users Access to Your Cell</A>.
-<P><LI>The two aspects of participation are independent. A cell can make
-its file tree visible without allowing its users to see foreign cells'
-file trees, or can enable its users to see other file trees without
-advertising its own.
-<P><LI>You make your cell visible to others by advertising your database server
-machines. See <A HREF="#HDRWQ38">Making Your Cell Visible to Others</A>.
-<P><LI>You control access to foreign cells on a per-client machine basis.
-In other words, it is possible to make a foreign cell accessible from one
-client machine in your cell but not another. See <A HREF="#HDRWQ39">Making Other Cells Visible in Your Cell</A>.
-</UL>
-<A NAME="IDX5662"></A>
-<A NAME="IDX5663"></A>
-<A NAME="IDX5664"></A>
-<A NAME="IDX5665"></A>
-<A NAME="IDX5666"></A>
-<A NAME="IDX5667"></A>
-<P><H3><A NAME="HDRWQ37" HREF="auagd002.htm#ToC_46">What the Global Namespace Looks Like</A></H3>
-<P>The AFS global namespace appears the same to all AFS cells
-that participate in it, because they all agree to follow a small set of
-conventions in constructing pathnames.
-<P>The first convention is that all AFS pathnames begin with the string
-<B>/afs</B> to indicate that they belong to the AFS global
-namespace.
-<P>The second convention is that the cell name is the second element in an AFS
-pathname; it indicates where the file resides (that is, the cell in which
-a file server machine houses the file). As noted, the presence of a
-cell name in pathnames makes the global namespace possible, because it
-guarantees that all AFS pathnames are unique even if cells use the same
-directory names at lower levels in their AFS filespace.
-<P>What appears at the third and lower levels in an AFS pathname depends on
-how a cell has chosen to arrange its filespace. There are some
-suggested conventional directories at the third level; see <A HREF="#HDRWQ43">The Third Level</A>.
-<A NAME="IDX5668"></A>
-<A NAME="IDX5669"></A>
-<A NAME="IDX5670"></A>
-<P><H3><A NAME="HDRWQ38" HREF="auagd002.htm#ToC_47">Making Your Cell Visible to Others</A></H3>
-<P>You make your cell visible to others by advertising your cell
-name and database server machines. Just like client machines in the
-local cell, the Cache Manager on machines in foreign cells use the information
-to reach your cell's Volume Location (VL) Servers when they need volume
-and file location information. Similarly, client-side authentication
-programs running in foreign cells use the information to contact your
-cell's authentication service.
-<P>There are two places you can make this information available:
-<UL>
-<A NAME="IDX5671"></A>
-<A NAME="IDX5672"></A>
-<P><LI>In the global <B>CellServDB</B> file maintained by the AFS Product
-Support group. This file lists the name and database server machines of
-every cell that has agreed to make this information available to other
-cells.
-<P>To add or change your cell's listing in this file, have the official
-support contact at your site call or write to AFS Product Support.
-Changes to the file are frequent enough that AFS Product Support does not
-announce each one. It is a good policy to check the file for changes on
-a regular schedule.
-<A NAME="IDX5673"></A>
-<A NAME="IDX5674"></A>
-<P><LI>A file called <B>CellServDB.local</B> in the
-<B>/afs/</B><VAR>cellname</VAR><B>/service/etc</B> directory of your
-cell's filespace. List only your cell's database server
-machines.
-</UL>
-<P>Update the files whenever you change the identity of your cell's
-database server machines. Also update the copies of the
-<B>CellServDB</B> files on all of your server machines (in the
-<B>/usr/afs/etc</B> directory) and client machines (in the
-<B>/usr/vice/etc</B> directory). For instructions, see <A HREF="auagd008.htm#HDRWQ118">Maintaining the Server CellServDB File</A> and <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A>.
-<P>Once you have advertised your database server machines, it can be difficult
-to make your cell invisible again. You can remove the
-<B>CellServDB.local</B> file and ask AFS Product Support to remove
-your entry from the global <B>CellServDB</B> file, but other cells
-probably have an entry for your cell in their local <B>CellServDB</B>
-files already. To make those entries invalid, you must change the names
-or IP addresses of your database server machines.
-<P>Your cell does not have to be invisible to be inaccessible, however.
-To make your cell completely inaccessible to foreign users, remove the
-<B>system:anyuser</B> group from all ACLs at the top three levels of
-your filespace; see <A HREF="#HDRWQ40">Granting and Denying Foreign Users Access to Your Cell</A>.
-<A NAME="IDX5675"></A>
-<A NAME="IDX5676"></A>
-<A NAME="IDX5677"></A>
-<A NAME="IDX5678"></A>
-<P><H3><A NAME="HDRWQ39" HREF="auagd002.htm#ToC_48">Making Other Cells Visible in Your Cell</A></H3>
-<P>To make a foreign cell's filespace visible on a client
-machine in your cell, perform the following three steps:
-<OL TYPE=1>
-<P><LI>Mount the cell's <B>root.cell</B> volume at the second
-level in your cell's filespace just below the <B>/afs</B>
-directory. Use the <B>fs mkmount</B> command with the
-<B>-cell</B> argument as instructed in <A HREF="auagd010.htm#HDRWQ213">To create a cellular mount point</A>.
-<P><LI>Mount AFS at the <B>/afs</B> directory on the client machine.
-The <B>afsd</B> program, which initializes the Cache Manager, performs the
-mount automatically at the directory named in the first field of the local
-<B>/usr/vice/etc/cacheinfo</B> file or by the command's
-<B>-mountdir</B> argument. Mounting AFS at an alternate location
-makes it impossible to reach the filespace of any cell that mounts its
-<B>root.afs</B> and <B>root.cell</B> volumes at the
-conventional locations. See <A HREF="auagd015.htm#HDRWQ395">Displaying and Setting the Cache Size and Location</A>.
-<P><LI>Create an entry for the cell in the list of database server machines which
-the Cache Manager maintains in kernel memory.
-<P>The <B>/usr/vice/etc/CellServDB</B> file on every client machine's
-local disk lists the database server machines for the local and foreign
-cells. The <B>afsd</B> program reads the contents of the
-<B>CellServDB</B> file into kernel memory as it initializes the Cache
-Manager. You can also use the <B>fs newcell</B> command to add or
-alter entries in kernel memory directly between reboots of the machine.
-See <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A>.
-</OL>
-<P>Note that making a foreign cell visible to client machines does not
-guarantee that your users can access its filespace. The ACLs in the
-foreign cell must also grant them the necessary permissions.
-<A NAME="IDX5679"></A>
-<A NAME="IDX5680"></A>
-<P><H3><A NAME="HDRWQ40" HREF="auagd002.htm#ToC_49">Granting and Denying Foreign Users Access to Your Cell</A></H3>
-<P>Making your cell visible in the AFS global namespace does not
-take away your control over the way in which users from foreign cells access
-your file tree.
-<P>By default, foreign users access your cell as the user
-<B>anonymous</B>, which means they have only the permissions granted to
-the <B>system:anyuser</B> group on each directory's ACL.
-Normally these permissions are limited to the <B>l</B> (<B>lookup</B>)
-and <B>r</B> (<B>read</B>) permissions.
-<P>There are two ways to grant wider access to foreign users:
-<UL>
-<P><LI>Grant additional permissions to the <B>system:anyuser</B> group
-on certain ACLs. Keep in mind, however, that all users can then access
-that directory in the indicated way (not just specific foreign users you have
-in mind).
-<P><LI>Create a local authentication account for specific foreign users, by
-creating entries in the Protection and Authentication Databases and local
-password file. It is not possible to place foreign usernames on ACLs,
-nor to authenticate in a foreign cell without having an account in it.
-</UL>
-<A NAME="IDX5681"></A>
-<A NAME="IDX5682"></A>
-<A NAME="IDX5683"></A>
-<HR><H2><A NAME="HDRWQ41" HREF="auagd002.htm#ToC_50">Configuring Your AFS Filespace</A></H2>
-<P>This section summarizes the issues to consider when
-configuring your AFS filespace. For a discussion of creating volumes
-that correspond most efficiently to the filespace's directory structure,
-see <A HREF="#HDRWQ44">Creating Volumes to Simplify Administration</A>.
-<P><B>Note for Windows users:</B> Windows uses a backslash
-( <B>\</B> ) rather than a forward slash
-( <B>/</B> ) to separate the elements in a
-pathname. The hierarchical organization of the filespace is however the
-same as on a UNIX machine.
-<P>AFS pathnames must follow a few conventions so the AFS global namespace
-looks the same from any AFS client machine. There are corresponding
-conventions to follow in building your file tree, not just because pathnames
-reflect the structure of a file tree, but also because the AFS Cache Manager
-expects a certain configuration.
-<A NAME="IDX5684"></A>
-<A NAME="IDX5685"></A>
-<P><H3><A NAME="Header_51" HREF="auagd002.htm#ToC_51">The Top /afs Level</A></H3>
-<P>The first convention is that the top level in your file tree be called
-the <B>/afs</B> directory. If you name it something else, then you
-must use the <B>-mountdir</B> argument with the <B>afsd</B> program to
-get Cache Managers to mount AFS properly. You cannot participate in the
-AFS global namespace in that case.
-<A NAME="IDX5686"></A>
-<A NAME="IDX5687"></A>
-<A NAME="IDX5688"></A>
-<P><H3><A NAME="HDRWQ42" HREF="auagd002.htm#ToC_52">The Second (Cellname) Level</A></H3>
-<P>The second convention is that just below the <B>/afs</B>
-directory you place directories corresponding to each cell whose file tree is
-visible and accessible from the local cell. Minimally, there must be a
-directory for the local cell. Each such directory is a mount point to
-the indicated cell's <B>root.cell</B> volume. For
-example, in the ABC Corporation cell, <B>/afs/abc.com</B> is a
-mount point for the cell's own <B>root.cell</B> volume and
-<B>stateu.edu</B> is a mount point for the State University
-cell's <B>root.cell</B> volume. The <B>fs
-lsmount</B> command displays the mount points.
-<PRE> % <B>fs lsmount /afs/abc.com</B>
- '/afs/abc.com' is a mount point for volume '#root.cell'
- % <B>fs lsmount /afs/stateu.edu</B>
- '/afs/stateu.edu' is a mount point for volume '#stateu.edu:root.cell'
-</PRE>
-<P>To reduce the amount of typing necessary in pathnames, you can create a
-symbolic link with an abbreviated name to the mount point of each cell your
-users frequently access (particularly the home cell). In the ABC
-Corporation cell, for instance, <B>/afs/abc</B> is a symbolic link to the
-<B>/afs/abc.com</B> mount point, as the <B>fs lsmount</B>
-command reveals.
-<PRE> % <B>fs lsmount /afs/abc</B>
- '/afs/abc' is a symbolic link, leading to a mount point for volume '#root.cell'
-</PRE>
-<A NAME="IDX5689"></A>
-<A NAME="IDX5690"></A>
-<P><H3><A NAME="HDRWQ43" HREF="auagd002.htm#ToC_53">The Third Level</A></H3>
-<P>You can organize the third level of your cell's file
-tree any way you wish. The following list describes directories that
-appear at this level in the conventional configuration:
-<DL>
-<P><DT><B>common
-</B><DD>This directory contains programs and files needed by users working on
-machines of all system types, such as text editors, online documentation
-files, and so on. Its <B>/etc</B> subdirectory is a logical place
-to keep the central update sources for files used on all of your cell's
-client machines, such as the <B>ThisCell</B> and <B>CellServDB</B>
-files.
-<P><DT><B>public
-</B><DD>A directory accessible to anyone who can access your filespace, because
-its ACL grants the <B>l</B> (<B>lookup</B>) and <B>r</B>
-(<B>read</B>) permissions to the <B>system:anyuser</B>
-group. It is useful if you want to enable your users to make selected
-information available to everyone, but do not want to grant foreign users
-access to the contents of the <B>usr</B> directory which houses user home
-directories ( and is also at this level). It is conventional to create
-a subdirectory for each of your cell's users.
-<P><DT><B>service
-</B><DD>This directory contains files and subdirectories that help cells
-coordinate resource sharing. For a list of the proposed standard files
-and subdirectories to create, call or write to AFS Product Support.
-<P>As an example, files that other cells expect to find in this
-directory's <B>etc</B> subdirectory can include the following:
-<UL>
-<P><LI><B>CellServDB.export</B>, a list of database server machines
-for many cells
-<P><LI><B>CellServDB.local</B>, a list of the cell's own database
-server machines
-<P><LI><B>passwd</B>, a copy of the local password file
-(<B>/etc/passwd</B> or equivalent) kept on the local disk of the
-cell's client machines
-<P><LI><B>group</B>, a copy of the local groups file (<B>/etc/group</B>
-or equivalent) kept on the local disk of the cell's client machines
-</UL>
-<P><DT><B><VAR>sys_type</VAR>
-</B><DD>A separate directory for storing the server and client binaries for each
-system type you use in the cell. Configuration is simplest if you use
-the system type names assigned in the AFS distribution, particularly if you
-wish to use the <B>@sys</B> variable in pathnames (see <A HREF="#HDRWQ56">Using the @sys Variable in Pathnames</A>). The <I>IBM AFS Release Notes</I> lists the
-conventional name for each supported system type.
-<P>Within each such directory, create directories named <B>bin</B>,
-<B>etc</B>, <B>usr</B>, and so on, to store the programs normally kept
-in the <B>/bin</B>, <B>/etc</B> and <B>/usr</B> directories on a
-local disk. Then create symbolic links from the local directories on
-client machines into AFS; see <A HREF="#HDRWQ55">Configuring the Local Disk</A>. Even if you do not choose to use symbolic links in
-this way, it can be convenient to have central copies of system binaries in
-AFS. If binaries are accidentally removed from a machine, you can
-recopy them onto the local disk from AFS rather than having to recover them
-from tape
-<P><DT><B>usr
-</B><DD>This directory contains home directories for your local users. As
-discussed in the previous entry for the <B>public</B> directory, it is
-often practical to protect this directory so that only locally authenticated
-users can access it. This keeps the contents of your user's home
-directories as secure as possible.
-<P>If your cell is quite large, directory lookup can be slowed if you put all
-home directories in a single <B>usr</B> directory. For suggestions
-on distributing user home directories among multiple grouping directories, see
-<A HREF="#HDRWQ59">Grouping Home Directories</A>.
-<P><DT><B>wsadmin
-</B><DD>This directory contains prototype, configuration and library files for use
-with the <B>package</B> program. See <A HREF="auagd016.htm#HDRWQ419">Configuring Client Machines with the package Program</A>.
-</DL>
-<A NAME="IDX5691"></A>
-<A NAME="IDX5692"></A>
-<A NAME="IDX5693"></A>
-<A NAME="IDX5694"></A>
-<HR><H2><A NAME="HDRWQ44" HREF="auagd002.htm#ToC_54">Creating Volumes to Simplify Administration</A></H2>
-<P>This section discusses how to create volumes in ways that
-make administering your system easier.
-<P>At the top levels of your file tree (at least through the third level),
-each directory generally corresponds to a separate volume. Some cells
-also configure the subdirectories of some third level directories as separate
-volumes. Common examples are the
-<B>/afs/</B><VAR>cellname</VAR><B>/common</B> and
-<B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directories.
-<P>You do not have to create a separate volume for every directory level in a
-tree, but the advantage is that each volume tends to be smaller and easier to
-move for load balancing. The overhead for a mount point is no greater
-than for a standard directory, nor does the volume structure itself require
-much disk space. Most cells find that below the fourth level in the
-tree, using a separate volume for each directory is no longer
-efficient. For instance, while each user's home directory (at the
-fourth level in the tree) corresponds to a separate volume, all of the
-subdirectories in the home directory normally reside in the same
-volume.
-<P>Keep in mind that only one volume can be mounted at a given directory
-location in the tree. In contrast, a volume can be mounted at several
-locations, though this is not recommended because it distorts the hierarchical
-nature of the file tree, potentially causing confusion.
-<A NAME="IDX5695"></A>
-<A NAME="IDX5696"></A>
-<A NAME="IDX5697"></A>
-<A NAME="IDX5698"></A>
-<A NAME="IDX5699"></A>
-<P><H3><A NAME="Header_55" HREF="auagd002.htm#ToC_55">Assigning Volume Names</A></H3>
-<P>You can name your volumes anything you choose, subject to a few
-restrictions:
-<UL>
-<P><LI>Read/write volume names can be up to 22 characters in length. The
-maximum length for volume names is 31 characters, and there must be room to
-add the <B>.readonly</B> extension on read-only volumes.
-<P><LI>Do not add the <B>.readonly</B> and <B>.backup</B>
-extensions to volume names yourself, even if they are appropriate. The
-Volume Server adds them automatically as it creates a read-only or backup
-version of a volume.
-<P><LI>There must be volumes named <B>root.afs</B> and
-<B>root.cell</B>, mounted respectively at the top (<B>/afs</B>)
-level in the filespace and just below that level, at the cell's name (for
-example, at <B>/afs/abc.com</B> in the ABC Corporation
-cell).
-<P>Deviating from these names only creates confusion and extra work.
-Changing the name of the <B>root.afs</B> volume, for instance,
-means that you must use the <B>-rootvol</B> argument to the
-<B>afsd</B> program on every client machine, to name the alternate
-volume.
-<P>Similarly, changing the <B>root.cell</B> volume name prevents
-users in foreign cells from accessing your filespace, if the mount point for
-your cell in their filespace refers to the conventional
-<B>root.cell</B> name. Of course, this is one way to make
-your cell invisible to other cells.
-</UL>
-<P>It is best to assign volume names that indicate the type of data they
-contain, and to use similar names for volumes with similar contents. It
-is also helpful if the volume name is similar to (or at least has elements in
-common with) the name of the directory at which it is mounted.
-Understanding the pattern then enables you accurately to guess what a volume
-contains and where it is mounted.
-<P>Many cells find that the most effective volume naming scheme puts a common
-prefix on the names of all related volumes. <A HREF="#TBLVOL-PREFIX">Table 1</A> describes the recommended prefixing scheme.
-<BR>
-<P><B><A NAME="TBLVOL-PREFIX" HREF="auagd004.htm#FT_TBLVOL-PREFIX">Table 1. Suggested volume prefixes</A></B><BR>
-<TABLE WIDTH="100%" BORDER>
-<TR>
-<TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="14%"><B>Prefix</B>
-</TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="28%"><B>Contents</B>
-</TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="22%"><B>Example Name</B>
-</TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="36%"><B>Example Mount Point</B>
-</TH></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>common.</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">popular programs and files
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>common.etc</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/common/etc</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>src.</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">source code
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>src.afs</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/src/afs</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>proj.</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">project data
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>proj.portafs</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/proj/portafs</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>test.</B><TT></TT>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">testing or other temporary data
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>test.smith</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/usr/smith/test</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>user.</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">user home directory data
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>user.terry</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/usr/terry</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><VAR>sys_type</VAR><B>.</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">programs compiled for an operating system type
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>rs_aix42.bin</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/bin</B>
-</TD></TR></TABLE>
-<P><A HREF="#TBLPREFIX-EXAMPLE">Table 2</A> is a more specific example for a cell's
-<B>rs_aix42</B> system volumes and directories:
-<BR>
-<P><B><A NAME="TBLPREFIX-EXAMPLE" HREF="auagd004.htm#FT_TBLPREFIX-EXAMPLE">Table 2. Example volume-prefixing scheme</A></B><BR>
-<TABLE WIDTH="100%" BORDER>
-<TR>
-<TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="35%"><B><B>Example Name</B></B>
-</TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="65%"><B><B>Example Mount Point</B></B>
-</TH></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.bin</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/bin</B><B>/afs/<B>cell</B>/rs_aix42/bin</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.etc</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/etc</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.afsws</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/afsws</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.lib</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/lib</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.bin</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/bin</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.etc</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/etc</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.inc</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/inc</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.man</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/man</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.sys</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/sys</B>
-</TD></TR><TR>
-<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.local</B>
-</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/local</B>
-</TD></TR></TABLE>
-<P>There are several advantages to this scheme:
-<UL>
-<P><LI>The volume name is similar to the mount point name in the
-filespace. In all of the entries in <A HREF="#TBLPREFIX-EXAMPLE">Table 2</A>, for example, the only difference between the
-volume and mount point name is that the former uses periods as separators and
-the latter uses slashes. Another advantage is that the volume name
-indicates the contents, or at least suggests the directory on which to issue
-the <B>ls</B> command to learn the contents.
-<P><LI>It makes it easy to manipulate groups of related volumes at one
-time. In particular, the <B>vos backupsys</B> command's
-<B>-prefix</B> argument enables you to create a backup version of every
-volume whose name starts with the same string of characters. Making a
-backup version of each volume is one of the first steps in backing up a volume
-with the AFS Backup System, and doing it for many volumes with one command
-saves you a good deal of typing. For instructions for creating backup
-volumes, see <A HREF="auagd010.htm#HDRWQ201">Creating Backup Volumes</A>, For information on the AFS Backup System, see <A HREF="auagd011.htm#HDRWQ248">Configuring the AFS Backup System</A> and <A HREF="auagd012.htm#HDRWQ283">Backing Up and Restoring AFS Data</A>.
-<P><LI>It makes it easy to group related volumes together on a partition.
-Grouping related volumes together has several advantages of its own, discussed
-in <A HREF="#HDRWQ49">Grouping Related Volumes on a Partition</A>.
-</UL>
-<A NAME="IDX5700"></A>
-<A NAME="IDX5701"></A>
-<P><H3><A NAME="HDRWQ49" HREF="auagd002.htm#ToC_56">Grouping Related Volumes on a Partition</A></H3>
-<P>If your cell is large enough to make it practical, consider
-grouping related volumes together on a partition. In general, you need
-at least three file server machines for volume grouping to be
-effective. Grouping has several advantages, which are most obvious when
-the file server machine becomes inaccessible:
-<UL>
-<P><LI>If you keep a hardcopy record of the volumes on a partition, you know
-which volumes are unavailable. You can keep such a record without
-grouping related volumes, but a list composed of unrelated volumes is much
-harder to maintain. Note that the record must be on paper, because the
-outage can prevent you from accessing an online copy or from issuing the
-<B>vos listvol</B> command, which gives you the same information.
-<P><LI>The effect of an outage is more localized. For example, if all of
-the binaries for a given system type are on one partition, then only users of
-that system type are affected. If a partition houses binary volumes
-from several system types, then an outage can affect more people, particularly
-if the binaries that remain available are interdependent with those that are
-not available.
-</UL>
-<P>The advantages of grouping related volumes on a partition do not
-necessarily extend to the grouping of all related volumes on one file server
-machine. For instance, it is probably unwise in a cell with two file
-server machines to put all system volumes on one machine and all user volumes
-on the other. An outage of either machine probably affects
-everyone.
-<P>Admittedly, the need to move volumes for load balancing purposes can limit
-the practicality of grouping related volumes. You need to weigh the
-complementary advantages case by case.
-<A NAME="IDX5702"></A>
-<A NAME="IDX5703"></A>
-<A NAME="IDX5704"></A>
-<A NAME="IDX5705"></A>
-<P><H3><A NAME="HDRWQ50" HREF="auagd002.htm#ToC_57">When to Replicate Volumes</A></H3>
-<P>As discussed in <A HREF="auagd006.htm#HDRWQ15">Replication</A>, replication refers to making a copy, or
-clone, of a read/write source volume and then placing the copy on one or more
-additional file server machines. Replicating a volume can increase the
-availability of the contents. If one file server machine housing the
-volume becomes inaccessible, users can still access the copy of the volume
-stored on a different machine. No one machine is likely to become
-overburdened with requests for a popular file, either, because the file is
-available from several machines.
-<P>However, replication is not appropriate for all cells. If a cell
-does not have much disk space, replication can be unduly expensive, because
-each clone not on the same partition as the read/write source takes up as much
-disk space as its source volume did at the time the clone was made.
-Also, if you have only one file server machine, replication uses up disk space
-without increasing availability.
-<P>Replication is also not appropriate for volumes that change
-frequently. You must issue the <B>vos release</B> command every
-time you need to update a read-only volume to reflect changes in its
-read/write source.
-<P>For both of these reasons, replication is appropriate only for popular
-volumes whose contents do not change very often, such as system binaries and
-other volumes mounted at the upper levels of your filespace. User
-volumes usually exist only in a read/write version since they change so
-often.
-<P>If you are replicating any volumes, you must replicate the
-<B>root.afs</B> and <B>root.cell</B> volumes, preferably
-at two or three sites each (even if your cell only has two or three file
-server machines). The Cache Manager needs to pass through the
-directories corresponding to the <B>root.afs</B> and
-<B>root.cell</B> volumes as it interprets any pathname. The
-unavailability of these volumes makes all other volumes unavailable too, even
-if the file server machines storing the other volumes are still
-functioning.
-<P>Another reason to replicate the <B>root.afs</B> volume is that
-it can lessen the load on the File Server machine. The Cache Manager
-has a bias to access a read-only version of the <B>root.afs</B>
-volume if it is replicate, which puts the Cache Manager onto the
-<I>read-only path</I> through the AFS filespace. While on the
-read-only path, the Cache Manager attempts to access a read-only copy of
-replicated volumes. The File Server needs to track only one callback
-per Cache Manager for all of the data in a read-only volume, rather than the
-one callback per file it must track for read/write volumes. Fewer
-callbacks translate into a smaller load on the File Server.
-<P>If the <B>root.afs</B> volume is not replicated, the Cache
-Manager follows a read/write path through the filespace, accessing the
-read/write version of each volume. The File Server distributes and
-tracks a separate callback for each file in a read/write volume, imposing a
-greater load on it.
-<P>For more on read/write and read-only paths, see <A HREF="auagd010.htm#HDRWQ209">The Rules of Mount Point Traversal</A>.
-<P>It also makes sense to replicate system binary volumes in many cases, as
-well as the volume corresponding to the
-<B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directory and the volumes
-corresponding to the <B>/afs/</B><VAR>cellname</VAR><B>/common</B>
-directory and its subdirectories.
-<P>It is a good idea to place a replica on the same partition as the
-read/write source. In this case, the read-only volume is a clone (like
-a backup volume): it is a copy of the source volume's <VAR>vnode
-index</VAR>, rather than a full copy of the volume contents. Only if the
-read/write volume moves to another partition or changes substantially does the
-read-only volume consume significant disk space. Read-only volumes kept
-on other partitions always consume the full amount of disk space that the
-read/write source consumed when the read-only volume was created.
-<P><H3><A NAME="Header_58" HREF="auagd002.htm#ToC_58">The Default Quota and ACL on a New Volume</A></H3>
-<P>Every AFS volume has associated with it a quota that limits the amount
-of disk space the volume is allowed to use. To set and change quota,
-use the commands described in <A HREF="auagd010.htm#HDRWQ234">Setting and Displaying Volume Quota and Current Size</A>.
-<P>By default, every new volume is assigned a space quota of 5000 KB blocks
-unless you include the <B>-maxquota</B> argument to the <B>vos
-create</B> command. Also by default, the ACL on the root directory of
-every new volume grants all permissions to the members of the
-<B>system:administrators</B> group. To learn how to change
-these values when creating an account with individual commands, see <A HREF="auagd018.htm#HDRWQ503">To create one user account with individual commands</A>. When using <B>uss</B> commands to create
-accounts, you can specify alternate ACL and quota values in the template
-file's <B>V</B> instruction; see <A HREF="auagd017.htm#HDRWQ473">Creating a Volume with the V Instruction</A>.
-<A NAME="IDX5706"></A>
-<A NAME="IDX5707"></A>
-<A NAME="IDX5708"></A>
-<A NAME="IDX5709"></A>
-<A NAME="IDX5710"></A>
-<HR><H2><A NAME="HDRWQ51" HREF="auagd002.htm#ToC_59">Configuring Server Machines</A></H2>
-<P>This section discusses some issues to consider when
-configuring server machines, which store AFS data, transfer it to client
-machines on request, and house the AFS administrative databases. To
-learn about client machines, see <A HREF="#HDRWQ54">Configuring Client Machines</A>.
-<P>If your cell has more than one AFS server machine, you can configure them
-to perform specialized functions. A machine can assume one or more of
-the roles described in the following list. For more details, see <A HREF="auagd008.htm#HDRWQ90">The Four Roles for File Server Machines</A>.
-<UL>
-<P><LI>A <I>simple file server machine</I> runs only the processes that store
-and deliver AFS files to client machines. You can run as many simple
-file server machines as you need to satisfy your cell's performance and
-disk space requirements.
-<P><LI>A <I>database server machine</I> runs the four database server
-processes that maintain AFS's replicated administrative databases:
-the Authentication, Backup, Protection, and Volume Location (VL) Server
-processes.
-<P><LI>A <I>binary distribution machine</I> distributes the AFS server
-binaries for its system type to all other server machines of that system
-type.
-<P><LI>The single <I>system control machine</I> distributes common server
-configuration files to all other server machines in the cell, in a cell that
-runs the United States edition of AFS (cells that use the international
-edition of AFS must not use the system control machine for this
-purpose). The machine conventionally also serves as the time
-synchronization source for the cell, adjusting its clock according to a time
-source outside the cell.
-</UL>
-<P>The <I>IBM AFS Quick Beginnings</I> explains how to configure your
-cell's first file server machine to assume all four roles. The
-<I>IBM AFS Quick Beginnings</I> chapter on installing additional server
-machines also explains how to configure them to perform one or more
-roles.
-<A NAME="IDX5711"></A>
-<A NAME="IDX5712"></A>
-<A NAME="IDX5713"></A>
-<A NAME="IDX5714"></A>
-<P><H3><A NAME="HDRWQ52" HREF="auagd002.htm#ToC_60">Replicating the AFS Administrative Databases</A></H3>
-<P>The AFS administrative databases are housed on database
-server machines and store information that is crucial for correct cell
-functioning. Both server processes and Cache Managers access the
-information frequently:
-<UL>
-<P><LI>Every time a Cache Manager fetches a file from a directory that it has not
-previously accessed, it must look up the file's location in the Volume
-Location Database (VLDB).
-<P><LI>Every time a user obtains an AFS token from the Authentication Server, the
-server looks up the user's password in the Authentication
-Database.
-<P><LI>The first time that a user accesses a volume housed on a specific file
-server machine, the File Server contacts the Protection Server for a list of
-the user's group memberships as recorded in the Protection
-Database.
-<P><LI>Every time you back up a volume using the AFS Backup System, the Backup
-Server creates records for it in the Backup Database.
-</UL>
-<P>Maintaining your cell is simplest if the first machine has the lowest IP
-address of any machine you plan to use as a database server machine. If
-you later decide to use a machine with a lower IP address as a database server
-machine, you must update the <B>CellServDB</B> file on all clients before
-introducing the new machine.
-<P>If your cell has more than one server machine, it is best to run more than
-one as a database server machine (but more than three are rarely
-necessary). Replicating the administrative databases in this way yields
-the same benefits as replicating volumes: increased availability and
-reliability. If one database server machine or process stops
-functioning, the information in the database is still available from
-others. The load of requests for database information is spread across
-multiple machines, preventing any one from becoming overloaded.
-<P>Unlike replicated volumes, however, replicated databases do change
-frequently. Consistent system performance demands that all copies of
-the database always be identical, so it is not acceptable to record changes in
-only some of them. To synchronize the copies of a database, the
-database server processes use AFS's distributed database technology,
-Ubik. See <A HREF="auagd008.htm#HDRWQ102">Replicating the AFS Administrative Databases</A>.
-<P>If your cell has only one file server machine, it must also serve as a
-database server machine. If you cell has two file server machines, it
-is not always advantageous to run both as database server machines. If
-a server, process, or network failure interrupts communications between the
-database server processes on the two machines, it can become impossible to
-update the information in the database because neither of them can alone elect
-itself as the synchronization site.
-<A NAME="IDX5715"></A>
-<A NAME="IDX5716"></A>
-<P><H3><A NAME="HDRWQ53" HREF="auagd002.htm#ToC_61">AFS Files on the Local Disk</A></H3>
-<P>It is generally simplest to store the binaries for all AFS
-server processes in the <B>/usr/afs/bin</B> directory on every file server
-machine, even if some processes do not actively run on the machine.
-This makes it easier to reconfigure a machine to fill a new role.
-<P>For security reasons, the <B>/usr/afs</B> directory on a file server
-machine and all of its subdirectories and files must be owned by the local
-superuser <B>root</B> and have only the first <B>w</B>
-(<B>write</B>) mode bit turned on. Some files even have only the
-first <B>r</B> (<B>read</B>) mode bit turned on (for example, the
-<B>/usr/afs/etc/KeyFile</B> file, which lists the AFS server encryption
-keys). Each time the BOS Server starts, it checks that the mode bits on
-certain files and directories match the expected values. For a list,
-see the <I>IBM AFS Quick Beginnings</I> section about protecting sensitive
-AFS directories, or the discussion of the output from the <B>bos
-status</B> command in <A HREF="auagd009.htm#HDRWQ159">To display the status of server processes and their BosConfig entries</A>.
-<P>For a description of the contents of all AFS directories on a file server
-machine's local disk, see <A HREF="auagd008.htm#HDRWQ80">Administering Server Machines</A>.
-<P><H3><A NAME="Header_62" HREF="auagd002.htm#ToC_62">Configuring Partitions to Store AFS Data</A></H3>
-<P>The partitions that house AFS volumes on a file server machine must be
-mounted at directories named
-<P><B>/vicep<VAR>index</VAR></B>
-<P>where <VAR>index</VAR> is one or two lowercase letters. By convention,
-the first AFS partition created is mounted at the <B>/vicepa</B>
-directory, the second at the <B>/vicepb</B> directory, and so on through
-the <B>/vicepz</B> directory. The names then continue with
-<B>/vicepaa</B> through <B>/vicepaz</B>, <B>/vicepba</B> through
-<B>/vicepbz</B>, and so on, up to the maximum supported number of server
-partitions, which is specified in the <I>IBM AFS Release Notes</I>.
-<P>Each <B>/vicep</B><VAR>x</VAR> directory must correspond to an entire
-partition or logical volume, and must be a subdirectory of the root directory
-( / ). It is not acceptable to configure part of (for example) the
-<B>/usr</B> partition as an AFS server partition and mount it on a
-directory called <B>/usr/vicepa</B>.
-<P>Also, do not store non-AFS files on AFS server partitions. The File
-Server and Volume Server expect to have available all of the space on the
-partition. Sharing space also creates competition between AFS and the
-local UNIX file system for access to the partition, particularly if the UNIX
-files are frequently used.
-<A NAME="IDX5717"></A>
-<A NAME="IDX5718"></A>
-<A NAME="IDX5719"></A>
-<A NAME="IDX5720"></A>
-<A NAME="IDX5721"></A>
-<P><H3><A NAME="Header_63" HREF="auagd002.htm#ToC_63">Monitoring, Rebooting and Automatic Process Restarts</A></H3>
-<P>AFS provides several tools for monitoring the File Server, including
-the <B>scout</B> and <B>afsmonitor</B> programs. You can
-configure them to alert you when certain threshold values are exceeded, for
-example when a server partition is more than 95% full. See <A HREF="auagd013.htm#HDRWQ323">Monitoring and Auditing AFS Performance</A>.
-<P>Rebooting a file server machine requires shutting down the AFS processes
-and so inevitably causes a service outage. Reboot file server machines
-as infrequently as possible. For instructions, see <A HREF="auagd008.htm#HDRWQ139">Rebooting a Server Machine</A>.
-<P>By default, the BOS Server on each file server machine stops and
-immediately restarts all AFS server processes on the machine (including
-itself) once a week, at 4:00 a.m. on Sunday. This
-reduces the potential for the core leaks that can develop as any process runs
-for an extended time.
-<P>The BOS Server also checks each morning at 5:00 a.m.
-for any newly installed binary files in the <B>/usr/afs/bin</B>
-directory. It compares the timestamp on each binary file to the time at
-which the corresponding process last restarted. If the timestamp on the
-binary is later, the BOS Server restarts the corresponding process to start
-using it.
-<P>The default times are in the early morning hours when the outage that
-results from restarting a process is likely to disturb the fewest number of
-people. You can display the restart times for each machine with the
-<B>bos getrestart</B> command, and set them with the <B>bos
-setrestart</B> command. The latter command enables you to disable
-automatic restarts entirely, by setting the time to <B>never</B>.
-See <A HREF="auagd009.htm#HDRWQ171">Setting the BOS Server's Restart Times</A>.
-<A NAME="IDX5722"></A>
-<A NAME="IDX5723"></A>
-<HR><H2><A NAME="HDRWQ54" HREF="auagd002.htm#ToC_64">Configuring Client Machines</A></H2>
-<P>This section summarizes issues to consider as you install and
-configure client machines in your cell.
-<A NAME="IDX5724"></A>
-<A NAME="IDX5725"></A>
-<A NAME="IDX5726"></A>
-<P><H3><A NAME="HDRWQ55" HREF="auagd002.htm#ToC_65">Configuring the Local Disk</A></H3>
-<P>You can often free up significant amounts of local disk space
-on AFS client machines by storing standard UNIX files in AFS and creating
-symbolic links to them from the local disk. The <B>@sys</B>
-pathname variable can be useful in links to system-specific files; see <A HREF="#HDRWQ56">Using the @sys Variable in Pathnames</A>.
-<P>There are two types of files that must actually reside on the local
-disk: boot sequence files needed before the <B>afsd</B> program is
-invoked, and files that can be helpful during file server machine
-outages.
-<P>During a reboot, AFS is inaccessible until the <B>afsd</B> program
-executes and initializes the Cache Manager. (In the conventional
-configuration, the AFS initialization file is included in the machine's
-initialization sequence and invokes the <B>afsd</B> program.) Files
-needed during reboot prior to that point must reside on the local disk.
-They include the following, but this list is not necessarily
-exhaustive.
-<UL>
-<P><LI>Standard UNIX utilities including the following or their
-equivalents:
-<UL>
-<P><LI>Machine initialization files (stored in the <B>/etc</B> or
-<B>/sbin</B> directory on many system types)
-<P><LI>The <B>fstab</B> file
-<P><LI>The <B>mount</B> command binary
-<P><LI>The <B>umount</B> command binary
-</UL>
-<P><LI>All subdirectories and files in the <B>/usr/vice</B> directory,
-including the following:
-<UL>
-<P><LI>The <B>/usr/vice/cache</B> directory
-<P><LI>The <B>/usr/vice/etc/afsd</B> command binary
-<P><LI>The <B>/usr/vice/etc/cacheinfo</B> file
-<P><LI>The <B>/usr/vice/etc/CellServDB</B> file
-<P><LI>The <B>/usr/vice/etc/ThisCell</B> file
-</UL>
-<P>For more information on these files, see <A HREF="auagd015.htm#HDRWQ391">Configuration and Cache-Related Files on the Local Disk</A>.
-</UL>
-<P>The other type of files and programs to retain on the local disk are those
-you need when diagnosing and fixing problems caused by a file server outage,
-because the outage can make inaccessible the copies stored in AFS.
-Examples include the binaries for a text editor (such as <B>ed</B> or
-<B>vi</B>) and for the <B>fs</B> and <B>bos</B> commands.
-Store copies of AFS command binaries in the <B>/usr/vice/etc</B> directory
-as well as including them in the <B>/usr/afsws</B> directory, which is
-normally a link into AFS. Then place the <B>/usr/afsws</B>
-directory before the <B>/usr/vice/etc</B> directory in users'
-<TT>PATH</TT> environment variable definition. When AFS is
-functioning normally, users access the copy in the <B>/usr/afsws</B>
-directory, which is more likely to be current than a local copy.
-<P>You can automate the configuration of client machine local disks by using
-the <B>package</B> program, which updates the contents of the local disk
-to match a configuration file. See <A HREF="auagd016.htm#HDRWQ419">Configuring Client Machines with the package Program</A>.
-<A NAME="IDX5727"></A>
-<P><H3><A NAME="Header_66" HREF="auagd002.htm#ToC_66">Enabling Access to Foreign Cells</A></H3>
-<P>As detailed in <A HREF="#HDRWQ39">Making Other Cells Visible in Your Cell</A>, you enable the Cache Manager to access a cell's
-AFS filespace by storing a list of the cell's database server machines in
-the local <B>/usr/vice/etc/CellServDB</B> file. The Cache Manager
-reads the list into kernel memory at reboot for faster retrieval. You
-can change the list in kernel memory between reboots by using the <B>fs
-newcell</B> command. It is often practical to store a central version
-of the <B>CellServDB</B> file in AFS and use the <B>package</B>
-program periodically to update each client's version with the source
-copy. See <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A>.
-<P>Because each client machine maintains its own copy of the
-<B>CellServDB</B> file, you can in theory enable access to different
-foreign cells on different client machines. This is not usually
-practical, however, especially if users do not always work on the same
-machine.
-<A NAME="IDX5728"></A>
-<A NAME="IDX5729"></A>
-<A NAME="IDX5730"></A>
-<P><H3><A NAME="HDRWQ56" HREF="auagd002.htm#ToC_67">Using the @sys Variable in Pathnames</A></H3>
-<P>When creating symbolic links into AFS on the local disk, it
-is often practical to use the <VAR>@sys</VAR> variable in pathnames. The
-Cache Manager automatically substitutes the local machine's AFS system
-name (CPU/operating system type) for the <VAR>@sys</VAR> variable. This
-means you can place the same links on machines of various system types and
-still have each machine access the binaries for its system type. For
-example, the Cache Manager on a machine running AIX 4.2 converts
-<B>/afs/abc.com/@sys</B> to
-<B>/afs/abc.com/rs_aix42</B>, whereas a machine running Solaris 7
-converts it to <B>/afs/abc.com/sun4x_57</B>.
-<P>If you want to use the <VAR>@sys</VAR> variable, it is simplest to use the
-conventional AFS system type names as specified in the <I>IBM AFS Release
-Notes</I>. The Cache Manager records the local machine's system
-type name in kernel memory during initialization. If you do not use the
-conventional names, you must use the <B>fs sysname</B> command to change
-the value in kernel memory from its default just after Cache Manager
-initialization, on every client machine of the relevant system type.
-The <B>fs sysname</B> command also displays the current value; see <A HREF="auagd015.htm#HDRWQ417">Displaying and Setting the System Type Name</A>.
-<P>In pathnames in the AFS filespace itself, use the <VAR>@sys</VAR> variable
-carefully and sparingly, because it can lead to unexpected results. It
-is generally best to restrict its use to only one level in the
-filespace. The third level is a common choice, because that is where
-many cells store the binaries for different machine types.
-<P>Multiple instances of the <VAR>@sys</VAR> variable in a pathname are
-especially dangerous to people who must explicitly change directories (with
-the <B>cd</B> command, for example) into directories that store binaries
-for system types other than the machine on which they are working, such as
-administrators or developers who maintain those directories. After
-changing directories, it is recommended that such people verify they are in
-the desired directory.
-<P><H3><A NAME="Header_68" HREF="auagd002.htm#ToC_68">Setting Server Preferences</A></H3>
-<P>The Cache Manager stores a table of preferences for file server
-machines in kernel memory. A preference rank pairs a file server
-machine interface's IP address with an integer in the range from 1 to
-65,534. When it needs to access a file, the Cache Manager compares the
-ranks for the interfaces of all machines that house the file, and first
-attempts to access the file via the interface with the best rank. As it
-initializes, the Cache Manager sets default ranks that bias it to access files
-via interfaces that are close to it in terms of network topology. You
-can adjust the preference ranks to improve performance if you wish.
-<P>The Cache Manager also uses similar preferences for Volume Location (VL)
-Server machines. Use the <B>fs getserverprefs</B> command to
-display preference ranks and the <B>fs setserverprefs</B> command to set
-them. See <A HREF="auagd015.htm#HDRWQ414">Maintaining Server Preference Ranks</A>.
-<A NAME="IDX5731"></A>
-<HR><H2><A NAME="HDRWQ57" HREF="auagd002.htm#ToC_69">Configuring AFS User Accounts</A></H2>
-<P>This section discusses some of the issues to consider when
-configuring AFS user accounts. Because AFS is separate from the UNIX
-file system, a user's AFS account is separate from her UNIX
-account.
-<P>The preferred method for creating a user account is with the <B>uss</B>
-suite of commands. With a single command, you can create all the
-components of one or many accounts, after you have prepared a template file
-that guides the account creation. See <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A>.
-<P>Alternatively, you can issue the individual commands that create each
-component of an account. For instructions, along with instructions for
-removing user accounts and changing user passwords, user volume quotas and
-usernames, see <A HREF="auagd018.htm#HDRWQ491">Administering User Accounts</A>.
-<P>When users leave your system, it is often good policy to remove their
-accounts. Instructions appear in <A HREF="auagd017.htm#HDRWQ486">Deleting Individual Accounts with the uss delete Command</A> and <A HREF="auagd018.htm#HDRWQ524">Removing a User Account</A>.
-<P>An AFS user account consists of the following components, which are
-described in greater detail in <A HREF="auagd018.htm#HDRWQ494">The Components of an AFS User Account</A>.
-<UL>
-<P><LI>A Protection Database entry
-<P><LI>An Authentication Database entry
-<P><LI>A volume
-<P><LI>A home directory at which the volume is mounted
-<P><LI>Ownership of the home directory and full permissions on its ACL
-<P><LI>An entry in the local password file (<B>/etc/passwd</B> or equivalent)
-of each machine the user needs to log into
-<P><LI>Optionally, standard files and subdirectories that make the account more
-useful
-</UL>
-<P>By creating some components but not others, you can create accounts at
-different levels of functionality, using either <B>uss</B> commands as
-described in <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A> or individual commands as described in <A HREF="auagd018.htm#HDRWQ491">Administering User Accounts</A>. The levels of functionality include
-the following
-<UL>
-<P><LI>An <I>authentication-only account</I> enables the user to obtain AFS
-tokens and so to access protected AFS data and to issue privileged
-commands. It consists only of entries in the Authentication and
-Protection Database. This type of account is suitable for
-administrative accounts and for users from foreign cells who need to access
-protected data. Local users generally also need a volume and home
-directory.
-<P><LI>A <I>basic user account</I> includes a volume for the user, in
-addition to Authentication and Protection Database entries. The volume
-is mounted in the AFS filespace as the user's home directory, and
-provides a repository for the user's personal files.
-<P><LI>A <I>full account</I> adds configuration files for basic functions
-such as logging in, printing, and mail delivery to a basic account, making it
-more convenient and useful. For a discussion of some useful types of
-configuration files, see <A HREF="#HDRWQ60">Creating Standard Files in New AFS Accounts</A>.
-</UL>
-<P>If your users have UNIX user accounts that predate the introduction of AFS
-in the cell, you possibly want to convert them into AFS accounts. There
-are three main issues to consider:
-<UL>
-<P><LI>Making UNIX and AFS UIDs match
-<P><LI>Setting the password field in the local password file appropriately
-<P><LI>Moving files from the UNIX file system into AFS
-</UL>
-<P>For further discussion, see <A HREF="auagd017.htm#HDRWQ459">Converting Existing UNIX Accounts with uss</A> or <A HREF="auagd018.htm#HDRWQ498">Converting Existing UNIX Accounts</A>.
-<A NAME="IDX5732"></A>
-<A NAME="IDX5733"></A>
-<A NAME="IDX5734"></A>
-<A NAME="IDX5735"></A>
-<A NAME="IDX5736"></A>
-<P><H3><A NAME="HDRWQ58" HREF="auagd002.htm#ToC_70">Choosing Usernames and Naming Other Account Components</A></H3>
-<P>This section suggests schemes for choosing usernames, AFS
-UIDs, user volume names and mount point names, and also outlines some
-restrictions on your choices.
-<P><B>Usernames</B>
-<P>AFS imposes very few restrictions on the form of usernames. It is
-best to keep usernames short, both because many utilities and applications can
-handle usernames of no more than eight characters and because by convention
-many components of and AFS account incorporate the name. These include
-the entries in the Protection and Authentication Databases, the volume, and
-the mount point. Depending on your electronic mail delivery system, the
-username can become part of the user's mailing address. The
-username is also the string that the user types when logging in to a client
-machine.
-<P>Some common choices for usernames are last names, first names, initials, or
-a combination, with numbers sometimes added. It is also best to avoid
-using the following characters, many of which have special meanings to the
-command shell.
-<UL>
-<P><LI>The comma ( <B>,</B> )
-<P><LI>The colon ( <B>:</B> ), because AFS reserves it as a field
-separator in protection group names; see <A HREF="#HDRWQ62">The Two Types of User-Defined Groups</A>
-<P><LI>The semicolon ( <B>;</B> )
-<P><LI>The "at-sign" ( <B>@</B> ); this character is reserved for
-Internet mailing addresses
-<P><LI>Spaces
-<P><LI>The newline character
-<P><LI>The period ( <B>.</B> ); it is conventional to use this
-character only in the special username that an administrator adopts while
-performing privileged tasks, such as <B>pat.admin</B>
-</UL>
-<P><B>AFS UIDs and UNIX UIDs</B>
-<P>AFS associates a unique identification number, the <I>AFS UID</I>, with
-every username, recording the mapping in the user's Protection Database
-entry. The AFS UID functions within AFS much as the UNIX UID does in
-the local file system: the AFS server processes and the Cache Manager
-use it internally to identify a user, rather than the username.
-<P>Every AFS user also must have a UNIX UID recorded in the local password
-file (<B>/etc/passwd</B> or equivalent) of each client machine they log
-onto. Both administration and a user's AFS access are simplest if
-the AFS UID and UNIX UID match. One important consequence of matching
-UIDs is that the owner reported by the <B>ls -l</B> command matches the
-AFS username.
-<P>It is usually best to allow the Protection Server to allocate the AFS UID
-as it creates the Protection Database entry. However, both the <B>pts
-createuser</B> command and the <B>uss</B> commands that create user
-accounts enable you to assign AFS UIDs explicitly. This is appropriate
-in two cases:
-<UL>
-<P><LI>You wish to group together the AFS UIDs of related users
-<P><LI>You are converting an existing UNIX account into an AFS account and want
-to make the AFS UID match the existing UNIX UID
-</UL>
-<P>After the Protection Server initializes for the first time on a cell's
-first file server machine, it starts assigning AFS UIDs at a default
-value. To change the default before creating any user accounts, or at
-any time, use the <B>pts setmax</B> command to reset the <TT>max user
-id</TT> counter. To display the counter, use the <B>pts
-listmax</B> command. See <A HREF="auagd019.htm#HDRWQ560">Displaying and Setting the AFS UID and GID Counters</A>.
-<P>AFS reserves one AFS UID, 32766, for the user <B>anonymous</B>.
-The AFS server processes assign this identity and AFS UID to any user who does
-not possess a token for the local cell. Do not assign this AFS UID to
-any other user or hardcode its current value into any programs or a
-file's owner field, because it is subject to change in future
-releases.
-<A NAME="IDX5737"></A>
-<A NAME="IDX5738"></A>
-<P><B>User Volume Names</B>
-<P>Like any volume name, a user volume's base (read/write) name cannot
-exceed 22 characters in length or include the <B>.readonly</B> or
-<B>.backup</B> extension. See <A HREF="#HDRWQ44">Creating Volumes to Simplify Administration</A>. By convention, user volume names have the format
-<B>user.</B><VAR>username</VAR>. Using the
-<B>user.</B> prefix not only makes it easy to identify the
-volume's contents, but also to create a backup version of all user
-volumes by issuing a single <B>vos backupsys</B> command.
-<A NAME="IDX5739"></A>
-<A NAME="IDX5740"></A>
-<P><B>Mount Point Names</B>
-<P>By convention, the mount point for a user's volume is named after the
-username. Many cells follow the convention of mounting user volumes in
-the <B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directory, as discussed
-in <A HREF="#HDRWQ43">The Third Level</A>. Very large cells sometimes find that mounting all
-user volumes in the same directory slows directory lookup, however; for
-suggested alternatives, see the following section.
-<A NAME="IDX5741"></A>
-<A NAME="IDX5742"></A>
-<P><H3><A NAME="HDRWQ59" HREF="auagd002.htm#ToC_71">Grouping Home Directories</A></H3>
-<P>Mounting user volumes in the
-<B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directory is an
-AFS-appropriate variation on the standard UNIX practice of putting user home
-directories under the <B>/usr</B> subdirectory. However, cells with
-more than a few hundred users sometimes find that mounting all user volumes in
-a single directory results in slow directory lookup. The solution is to
-distribute user volume mount points into several directories; there are a
-number of alternative methods to accomplish this.
-<UL>
-<P><LI>Distribute user home directories into multiple directories that reflect
-organizational divisions, such as academic or corporate departments.
-For example, a company can create group directories called
-<B>usr/marketing</B>, <B>usr/research</B>,
-<B>usr/finance</B>. A good feature of this scheme is that knowing a
-user's department is enough to find the user's home
-directory. Also, it makes it easy to set the ACL to limit access to
-members of the department only. A potential drawback arises if
-departments are of sufficiently unequal size that users in large departments
-experience slower lookup than users in small departments. This scheme
-is also not appropriate in cells where users frequently change between
-divisions.
-<P><LI>Distribute home directories into alphabetic subdirectories of the
-<B>usr</B> directory (the <B>usr/a</B> subdirectory, the
-<B>usr/b</B> subdirectory, and so on), based on the first letter of the
-username. If the cell is very large, create subdirectories under each
-letter that correspond to the second letter in the user name. This
-scheme has the same advantages and disadvantages of a department-based
-scheme. Anyone who knows the user's username can find the
-user's home directory, but users with names that begin with popular
-letters sometimes experience slower lookup.
-<P><LI>Distribute home directories randomly but evenly into more than one
-grouping directory. One cell that uses this scheme has over twenty such
-directories called the <B>usr1</B> directory, the <B>usr2</B>
-directory, and so on. This scheme is especially appropriate in cells
-where the other two schemes do not seem feasible. It eliminates the
-potential problem of differences in lookup speed, because all directories are
-about the same size. Its disadvantage is that there is no way to guess
-which directory a given user's volume is mounted in, but a solution is to
-create a symbolic link in the regular <B>usr</B> directory that references
-the actual mount point. For example, if user <B>smith</B>'s
-volume is mounted at the <B>/afs/bigcell.com/usr17/smith</B>
-directory, then the <B>/afs/bigcell.com/usr/smith</B> directory is
-a symbolic link to the <B>../usr17/smith</B>
-directory. This way, if someone does not know which directory the user
-<B>smith</B> is in, he or she can access it through the link called
-<B>usr/smith</B>; people who do know the appropriate directory save
-lookup time by specifying it.
-</UL>
-<P>For instructions on how to implement the various schemes when using the
-<B>uss</B> program to create user accounts, see <A HREF="auagd017.htm#HDRWQ472">Evenly Distributing User Home Directories with the G Instruction</A> and <A HREF="auagd017.htm#HDRWQ473">Creating a Volume with the V Instruction</A>.
-<P><H3><A NAME="Header_72" HREF="auagd002.htm#ToC_72">Making a Backup Version of User Volumes Available</A></H3>
-<P>Mounting the backup version of a user's volume is a simple way to
-enable users themselves to restore data they have accidentally removed or
-deleted. It is conventional to mount the backup version at a
-subdirectory of the user's home directory (called perhaps the
-<B>OldFiles</B> subdirectory), but other schemes are possible. Once
-per day you create a new backup version to capture the changes made that day,
-overwriting the previous day's backup version with the new one.
-Users can always retrieve the previous day's copy of a file without your
-assistance, freeing you to deal with more pressing tasks.
-<P>Users sometimes want to delete the mount point to their backup volume,
-because they erroneously believe that the backup volume's contents count
-against their quota. Remind them that the backup volume is separate, so
-the only space it uses in the user volume is the amount needed for the mount
-point.
-<P>For further discussion of backup volumes, see <A HREF="#HDRWQ77">Backing Up AFS Data</A> and <A HREF="auagd010.htm#HDRWQ201">Creating Backup Volumes</A>.
-<A NAME="IDX5743"></A>
-<A NAME="IDX5744"></A>
-<A NAME="IDX5745"></A>
-<P><H3><A NAME="HDRWQ60" HREF="auagd002.htm#ToC_73">Creating Standard Files in New AFS Accounts</A></H3>
-<P>From your experience as a UNIX administrator, you are
-probably familiar with the use of login and shell initialization files (such
-as the <B>.login</B> and <B>.cshrc</B> files) to make an
-account easier to use.
-<P>It is often practical to add some AFS-specific directories to the
-definition of the user's <TT>PATH</TT> environment variable, including
-the following:
-<UL>
-<P><LI>The path to a <B>bin</B> subdirectory in the user's home
-directory for binaries the user has created (that is,
-<B>/afs/<VAR>cellname</VAR><B>/usr/</B>
-<VAR>username</VAR><B>/bin</B>)</B>
-<P><LI>The <B>/usr/afsws/bin</B> path, which conventionally includes programs
-like <B>fs</B>, <B>klog</B>, <B>kpasswd</B>, <B>pts</B>,
-<B>tokens</B>, and <B>unlog</B>
-<P><LI>The <B>/usr/afsws/etc</B> path, if the user is an administrator;
-it usually houses the AFS command suites that require privilege (the
-<B>backup</B>, <B>butc</B>, <B>kas</B>, <B>uss</B>,
-<B>vos</B> commands), the <B>package</B> program, and others
-</UL>
-<P>If you are not using an AFS-modified login utility, it can be helpful to
-users to invoke the <B>klog</B> command in their <B>.login</B>
-file so that they obtain AFS tokens as part of logging in. In the
-following example command sequence, the first line echoes the string
-<TT>klog</TT> to the standard output stream, so that the user understands
-the purpose of the <TT>Password:</TT> prompt that appears when the
-second line is executed. The <B>-setpag</B> flag associates the new
-tokens with a process authentication group (PAG), which is discussed further
-in <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
-<PRE> echo -n "klog "
- klog -setpag
-</PRE>
-<P>The following sequence of commands has a similar effect, except that the
-<B>pagsh</B> command forks a new shell with which the PAG and tokens are
-associated.
-<PRE> pagsh
- echo -n "klog "
- klog
-</PRE>
-<P>If you use an AFS-modified login utility, this sequence is not necessary,
-because such utilities both log a user in locally and obtain AFS
-tokens.
-<A NAME="IDX5746"></A>
-<A NAME="IDX5747"></A>
-<A NAME="IDX5748"></A>
-<A NAME="IDX5749"></A>
-<HR><H2><A NAME="HDRWQ61" HREF="auagd002.htm#ToC_74">Using AFS Protection Groups</A></H2>
-<P>AFS enables users to define their own <I>groups</I> of
-other users or machines. The groups are placed on ACLs to grant the
-same permissions to many users without listing each user individually.
-For group creation instructions, see <A HREF="auagd019.htm#HDRWQ531">Administering the Protection Database</A>.
-<P>Groups have AFS ID numbers, just as users do, but an AFS group ID (GID) is
-a negative integer whereas a user's AFS UID is a positive integer.
-By default, the Protection Server allocates a new group's AFS GID
-automatically, but members of the <B>system:administrators</B> group
-can assign a GID when issuing the <B>pts creategroup</B> command.
-Before explicitly assigning a GID, it is best to verify that it is not already
-in use.
-<P>A group cannot belong to another group, but it can own another group or
-even itself as long as it (the owning group) has at least one member.
-The current owner of a group can transfer ownership of the group to another
-user or group, even without the new owner's permission. At that
-point the former owner loses administrative control over the group.
-<P>By default, each user can create 20 groups. A system administrator
-can increase or decrease this group creation quota with the <B>pts
-setfields</B> command.
-<P>Each Protection Database entry (group or user) is protected by a set of
-five <I>privacy flags</I>which limit who can administer the entry and what
-they can do. The default privacy flags are fairly restrictive,
-especially for user entries. See <A HREF="auagd019.htm#HDRWQ559">Setting the Privacy Flags on Database Entries</A>.
-<A NAME="IDX5750"></A>
-<A NAME="IDX5751"></A>
-<A NAME="IDX5752"></A>
-<A NAME="IDX5753"></A>
-<P><H3><A NAME="Header_75" HREF="auagd002.htm#ToC_75">The Three System Groups</A></H3>
-<P>As the Protection Server initializes for the first time on a
-cell's first database server machine, it automatically creates three
-group entries: the <B>system:anyuser</B>,
-<B>system:authuser</B>, and <B>system:administrators</B>
-groups.
-<A NAME="IDX5754"></A>
-<P>The first two system groups are unlike any other groups in the Protection
-Database in that they do not have a stable membership:
-<UL>
-<P><LI>The <B>system:anyuser</B> group includes everyone who can access
-a cell's AFS filespace: users who have tokens for the local cell,
-users who have logged in on a local AFS client machine but not obtained tokens
-(such as the local superuser <B>root</B>), and users who have connected to
-a local machine from outside the cell. Placing the
-<B>system:anyuser</B> group on an ACL grants access to the widest
-possible range of users. It is the only way to extend access to users
-from foreign AFS cells that do not have local accounts.
-<P><LI>The <B>system:authuser</B> group includes everyone who has a
-valid token obtained from the cell's AFS authentication service.
-</UL>
-<P>Because the groups do not have a stable membership, the <B>pts
-membership</B> command produces no output for them. Similarly, they
-do not appear in the list of groups to which a user belongs.
-<P>The <B>system:administrators</B> group does have a stable
-membership, consisting of the cell's privileged administrators.
-Members of this group can issue any <B>pts</B> command, and are the only
-ones who can issue several other restricted commands (such as the
-<B>chown</B> command on AFS files). By default, they also
-implicitly have the <B>a</B> (<B>administer</B>) and <B>l</B>
-(<B>lookup</B>) permissions on every ACL in the filespace. For
-information about changing this default, see <A HREF="auagd021.htm#HDRWQ586">Administering the system:administrators Group</A>.
-<P>For a discussion of how to use system groups effectively on ACLs, see <A HREF="auagd020.htm#HDRWQ571">Using Groups on ACLs</A>.
-<P><H3><A NAME="HDRWQ62" HREF="auagd002.htm#ToC_76">The Two Types of User-Defined Groups</A></H3>
-<P>All users can create <I>regular</I> groups. A
-regular group name has two fields separated by a colon, the first of which
-must indicate the group's ownership. The Protection Server refuses
-to create or change the name of a group if the result does not accurately
-indicate the ownership.
-<P>Members of the <B>system:administrators</B> group can create
-<I>prefix-less</I> groups whose names do not have the first field that
-indicates ownership. For suggestions on using the two types of groups
-effectively, see <A HREF="auagd019.htm#HDRWQ545">Using Groups Effectively</A>.
-<A NAME="IDX5755"></A>
-<A NAME="IDX5756"></A>
-<HR><H2><A NAME="HDRWQ63" HREF="auagd002.htm#ToC_77">Login and Authentication in AFS</A></H2>
-<P>As explained in <A HREF="#HDRWQ31">Differences in Authentication</A>, AFS authentication is separate from UNIX
-authentication because the two file systems are separate. The
-separation has two practical implications:
-<UL>
-<P><LI>To access AFS files, users must both log into the local file system and
-authenticate with the AFS authentication service. (Logging into the
-local file system is necessary because the only way to access the AFS
-filespace is through a Cache Manager, which resides in the local
-machine's kernel.)
-<P><LI>Passwords are stored in two separate places: in the Authentication
-Database for AFS and in the each machine's local password file (the
-<B>/etc/passwd</B> file or equivalent) for the local file system.
-</UL>
-<P>When a user successfully authenticates, the AFS authentication service
-passes a <I>token</I> to the user's Cache Manager. The token
-is a small collection of data that certifies that the user has correctly
-provided the password associated with a particular AFS identity. The
-Cache Manager presents the token to AFS server processes along with service
-requests, as proof that the user is genuine. To learn about the mutual
-authentication procedure they use to establish identity, see <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.
-<P>The Cache Manager stores tokens in the user's credential structure in
-kernel memory. To distinguish one user's credential structure from
-another's, the Cache Manager identifies each one either by the
-user's UNIX UID or by a <I>process authentication group</I>
-(<I>PAG</I>), which is an identification number guaranteed to be unique in
-the cell. For further discussion, see <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
-<A NAME="IDX5757"></A>
-<P>A user can have only one token per cell in each separately identified
-credential structure. To obtain a second token for the same cell, the
-user must either log into a different machine or obtain another credential
-structure with a different identifier than any existing credential structure,
-which is most easily accomplished by issuing the <B>pagsh</B> command (see
-<A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>). In a single credential structure, a user can have
-one token for each of many cells at the same time. As this implies,
-authentication status on one machine or PAG is independent of authentication
-status on another machine or PAG, which can be very useful to a user or system
-administrator.
-<P>The AFS distribution includes library files that enable each system
-type's login utility to authenticate users with AFS and log them into the
-local file system in one step. If you do not configure an AFS-modified
-login utility on a client machine, its users must issue the <B>klog</B>
-command to authenticate with AFS after logging in.
-<TABLE><TR><TD ALIGN="LEFT" VALIGN="TOP"><B>Note:</B></TD><TD ALIGN="LEFT" VALIGN="TOP">The AFS-modified libraries do not necessarily support all features available
-in an operating system's proprietary login utility. In some cases,
-it is not possible to support a utility at all. For more information
-about the supported utilities in each AFS version, see the <I>IBM AFS
-Release Notes</I>.
-</TD></TR></TABLE>
-<A NAME="IDX5758"></A>
-<A NAME="IDX5759"></A>
-<A NAME="IDX5760"></A>
-<A NAME="IDX5761"></A>
-<A NAME="IDX5762"></A>
-<A NAME="IDX5763"></A>
-<A NAME="IDX5764"></A>
-<P><H3><A NAME="HDRWQ64" HREF="auagd002.htm#ToC_78">Identifying AFS Tokens by PAG</A></H3>
-<P>As noted, the Cache Manager identifies user credential
-structures either by UNIX UID or by PAG. Using a PAG is preferable
-because it guaranteed to be unique: the Cache Manager allocates it based
-on a counter that increments with each use. In contrast, multiple users
-on a machine can share or assume the same UNIX UID, which creates potential
-security problems. The following are two common such situations:
-<UL>
-<P><LI>The local superuser <B>root</B> can always assume any other
-user's UNIX UID simply by issuing the <B>su</B> command, without
-providing the user's password. If the credential structure is
-associated with the user's UNIX UID, then assuming the UID means
-inheriting the AFS tokens.
-<P><LI>Two users working on different NFS client machines can have the same UNIX
-UID in their respective local file systems. If they both access the
-same NFS/AFS Translator machine, and the Cache Manager there identifies them
-by their UNIX UID, they become indistinguishable. To eliminate this
-problem, the Cache Manager on a translator machine automatically generates a
-PAG for each user and uses it, rather than the UNIX UID, to tell users
-apart.
-</UL>
-<P>Yet another advantage of PAGs over UIDs is that processes spawned by the
-user inherit the PAG and so share the token; thus they gain access to AFS
-as the authenticated user. In many environments, for example, printer
-and other daemons run under identities (such as the local superuser
-<B>root</B>) that the AFS server processes recognize only as the
-<B>anonymous</B> user. Unless PAGs are used, such daemons cannot
-access files for which the <B>system:anyuser</B> group does not have
-the necessary ACL permissions.
-<P>Once a user has a PAG, any new tokens the user obtains are associated with
-the PAG. The PAG expires two hours after any associated tokens expire
-or are discarded. If the user issues the <B>klog</B> command before
-the PAG expires, the new token is associated with the existing PAG (the PAG is
-said to be <I>recycled</I> in this case).
-<P>AFS-modified login utilities automatically generate a PAG, as described in
-the following section. If you use a standard login utility, your users
-must issue the <B>pagsh</B> command before the <B>klog</B> command, or
-include the latter command's <B>-setpag</B> flag. For
-instructions, see <A HREF="#HDRWQ69">Using Two-Step Login and Authentication</A>.
-<P>Users can also use either command at any time to create a new PAG.
-The difference between the two commands is that the <B>klog</B> command
-replaces the PAG associated with the current command shell and tokens.
-The <B>pagsh</B> command initializes a new command shell before creating a
-new PAG. If the user already had a PAG, any running processes or jobs
-continue to use the tokens associated with the old PAG whereas any new jobs or
-processes use the new PAG and its associated tokens. When you exit the
-new shell (by pressing <<B>Ctrl-d</B>>, for example), you return to the
-original PAG and shell. By default, the <B>pagsh</B> command
-initializes a Bourne shell, but you can include the <B>-c</B> argument to
-initialize a C shell (the <B>/bin/csh</B> program on many system types) or
-Korn shell (the <B>/bin/ksh</B> program) instead.
-<A NAME="IDX5765"></A>
-<P><H3><A NAME="HDRWQ65" HREF="auagd002.htm#ToC_79">Using an AFS-modified login Utility</A></H3>
-<P>As previously mentioned, an AFS-modified login utility
-simultaneously obtains an AFS token and logs the user into the local file
-system. This section outlines the login and authentication process and
-its interaction with the value in the password field of the local password
-file.
-<P>An AFS-modified login utility performs a sequence of steps similar to the
-following; details can vary for different operating systems:
-<OL TYPE=1>
-<P><LI>It checks the user's entry in the local password file (the
-<B>/etc/passwd</B> file or equivalent).
-<P><LI>If no entry exists, or if an asterisk ( <TT>*</TT> ) appears in the
-entry's password field, the login attempt fails. If the entry
-exists, the attempt proceeds to the next step.
-<P><LI><A NAME="LIWQ66"></A>The utility obtains a PAG.
-<P><LI><A NAME="LIWQ67"></A>The utility converts the password provided by the user into an
-encryption key and encrypts a packet of data with the key. It sends the
-packet to the AFS authentication service (the AFS Authentication Server in the
-conventional configuration).
-<P><LI>The authentication service decrypts the packet and, depending on the
-success of the decryption, judges the password to be correct or
-incorrect. (For more details, see <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.)
-<UL>
-<P><LI>If the authentication service judges the password incorrect, the user does
-not receive an AFS token. The PAG is retained, ready to be associated
-with any tokens obtained later. The attempt proceeds to Step <A HREF="#LIWQ68">6</A>.
-<P><LI>If the authentication service judges the password correct, it issues a
-token to the user as proof of AFS authentication. The login utility
-logs the user into the local UNIX file system. Some login utilities
-echo the following banner to the screen to alert the user to authentication
-with AFS. Step <A HREF="#LIWQ68">6</A> is skipped.
-<PRE> AFS(R) <VAR>version</VAR> Login
-</PRE>
-</UL>
-<P><LI><A NAME="LIWQ68"></A>If no AFS token was granted in Step <A HREF="#LIWQ67">4</A>, the login utility attempts to log the user into the local
-file system, by comparing the password provided to the local password
-file.
-<UL>
-<P><LI>If the password is incorrect or any value other than an encrypted
-13-character string appears in the password field, the login attempt
-fails.
-<P><LI>If the password is correct, the user is logged into the local file system
-only.
-</UL>
-</OL>
-<A NAME="IDX5766"></A>
-<A NAME="IDX5767"></A>
-<A NAME="IDX5768"></A>
-<P>As indicated, when you use an AFS-modified login utility, the password
-field in the local password file is no longer the primary gate for access to
-your system. If the user provides the correct AFS password, then the
-program never consults the local password file. However, you can still
-use the password field to control access, in the following way:
-<UL>
-<P><LI>To prevent both local login and AFS authentication, place an asterisk (
-<B>*</B> ) in the field. This is useful mainly in emergencies, when
-you want to prevent a certain user from logging into the machine.
-<P><LI>To prevent login to the local file system if the user does not provide the
-correct AFS password, place a character string of any length other than the
-standard thirteen characters in the field. This is appropriate if you
-want to permit only people with local AFS accounts to login on your
-machines. A single <B>X</B> or other character is the most easily
-recognizable way to do this.
-<P><LI>To enable a user to log into the local file system even after providing an
-incorrect AFS password, record a standard UNIX encrypted password in the field
-by issuing the standard UNIX password-setting command (<B>passwd</B> or
-equivalent).
-</UL>
-<P>Systems that use a Pluggable Authentication Module (PAM) for login and AFS
-authentication do not necessarily consult the local password file at all, in
-which case they do not use the password field to control authentication and
-login attempts. Instead, instructions in the PAM configuration file (on
-many system types, <B>/etc/pam.conf</B>) fill the same
-function. See the instructions in the <I>IBM AFS Quick
-Beginnings</I> for installing AFS-modified login utilities.
-<A NAME="IDX5769"></A>
-<P><H3><A NAME="HDRWQ69" HREF="auagd002.htm#ToC_80">Using Two-Step Login and Authentication</A></H3>
-<P>In cells that do not use an AFS-modified login utility, users
-must issue separate commands to login and authenticate, as detailed in the
-<I>IBM AFS User Guide</I>:
-<OL TYPE=1>
-<P><LI>They use the standard <B>login</B> program to login to the local file
-system, providing the password listed in the local password file (the
-<B>/etc/passwd</B> file or equivalent).
-<P><LI>They must issue the <B>klog</B> command to authenticate with the AFS
-authentication service, including its <B>-setpag</B> flag to associate the
-new tokens with a process authentication group (PAG).
-</OL>
-<P>As mentioned in <A HREF="#HDRWQ60">Creating Standard Files in New AFS Accounts</A>, you can invoke the <B>klog -setpag</B> command in a
-user's <B>.login</B> file (or equivalent) so that the user
-does not have to remember to issue the command after logging in. The
-user still must type a password twice, once at the prompt generated by the
-login utility and once at the <B>klog</B> command's prompt.
-This implies that the two passwords can differ, but it is less confusing if
-they do not.
-<P>Another effect of not using an AFS-modified login utility is that the AFS
-servers recognize the standard <B>login</B> program as the
-<B>anonymous</B> user. If the <B>login</B> program needs to
-access any AFS files (such as the <B>.login</B> file in a
-user's home directory), then the ACL that protects the file must include
-an entry granting the <B>l</B> (<B>lookup</B>) and <B>r</B>
-(<B>read</B>) permissions to the <B>system:anyuser</B>
-group.
-<P>When you do not use an AFS-modified login utility, an actual (scrambled)
-password must appear in the local password file for each user. Use the
-<B>/bin/passwd</B> file to insert or change these passwords. It is
-simpler if the password in the local password file matches the AFS password,
-but it is not required.
-<A NAME="IDX5770"></A>
-<A NAME="IDX5771"></A>
-<A NAME="IDX5772"></A>
-<A NAME="IDX5773"></A>
-<A NAME="IDX5774"></A>
-<A NAME="IDX5775"></A>
-<A NAME="IDX5776"></A>
-<A NAME="IDX5777"></A>
-<A NAME="IDX5778"></A>
-<A NAME="IDX5779"></A>
-<A NAME="IDX5780"></A>
-<A NAME="IDX5781"></A>
-<A NAME="IDX5782"></A>
-<A NAME="IDX5783"></A>
-<P><H3><A NAME="Header_81" HREF="auagd002.htm#ToC_81">Obtaining, Displaying, and Discarding Tokens</A></H3>
-<P>Once logged in, a user can obtain a token at any time with the
-<B>klog</B> command. If a valid token already exists, the new one
-overwrites it. If a PAG already exists, the new token is associated
-with it.
-<P>By default, the <B>klog</B> command authenticates the issuer using the
-identity currently logged in to the local file system. To authenticate
-as a different identity, use the <B>-principal</B> argument. To
-obtain a token for a foreign cell, use the <B>-cell</B> argument (it can
-be combined with the <B>-principal</B> argument). See the <I>IBM
-AFS User Guide</I> and the entry for the <B>klog</B> command in the
-<I>IBM AFS Administration Reference</I>.
-<P>To discard either all tokens or the token for a particular cell, issue the
-<B>unlog</B> command. The command affects only the tokens
-associated with the current command shell. See the <I>IBM AFS User
-Guide</I>and the entry for the <B>unlog</B> command in the <I>IBM AFS
-Administration Reference</I>.
-<P>To display the tokens associated with the current command shell, issue the
-<B>tokens</B> command. The following examples illustrate its output
-in various situations.
-<P>If the issuer is not authenticated in any cell:
-<PRE> % <B>tokens</B>
- Tokens held by the Cache Manager:
- --End of list--
-</PRE>
-<P>The following shows the output for a user with AFS UID 1000 in the ABC
-Corporation cell:
-<PRE> % <B>tokens</B>
- Tokens held by the Cache Manager:
-
- User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
- --End of list--
-</PRE>
-<P>The following shows the output for a user who is authenticated in ABC
-Corporation cell, the State University cell and the DEF Company cell.
-The user has different AFS UIDs in the three cells. Tokens for the last
-cell are expired:
-<PRE> % <B>tokens</B>
- Tokens held by the Cache Manager:
-
- User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
- User's (AFS ID 4286) tokens for afs@stateu.edu [Expires Jun 3 1:34]
- User's (AFS ID 22) tokens for afs@def.com [>>Expired<<]
- --End of list--
-</PRE>
-<P>The Kerberos version of the <B>tokens</B> command (the
-<B>tokens.krb</B> command), also reports information on the
-ticket-granting ticket, including the ticket's owner, the ticket-granting
-service, and the expiration date, as in the following example. Also see
-<A HREF="#HDRWQ70">Support for Kerberos Authentication</A>.
-<PRE> % <B>tokens.krb</B>
- Tokens held by the Cache Manager:
- User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
- User smith's tokens for krbtgt.ABC.COM@abc.com [Expires Jun 2 10:00]
- --End of list--
-</PRE>
-<P><H3><A NAME="Header_82" HREF="auagd002.htm#ToC_82">Setting Default Token Lifetimes for Users</A></H3>
-<A NAME="IDX5784"></A>
-<P>The maximum lifetime of a user token is the smallest of the <I>ticket
-lifetimes</I> recorded in the following three Authentication Database
-entries. The <B>kas examine</B> command reports the lifetime as
-<TT>Max ticket lifetime</TT>. Administrators who have the
-<TT>ADMIN</TT> flag on their Authentication Database entry can use the
-<B>-lifetime</B> argument to the <B>kas setfields</B> command to set
-an entry's ticket lifetime.
-<UL>
-<P><LI>The <B>afs</B> entry, which corresponds to the AFS server
-processes. The default is 100 hours.
-<P><LI>The <B>krbtgt</B>.<VAR>cellname</VAR> entry, which corresponds to
-the ticket-granting ticket used internally in generating the token. The
-default is 720 hours (30 days).
-<P><LI>The entry for the user of the AFS-modified login utility or issuer of the
-<B>klog</B> command. The default is 25 hours for user entries
-created using the AFS 3.1 or later version of the Authentication
-Server, and 100 hours for user entries created using the AFS 3.0
-version of the Authentication Server. A user can use the <B>kas
-examine</B> command to display his or her own Authentication Database
-entry.
-</UL>
-<TABLE><TR><TD ALIGN="LEFT" VALIGN="TOP"><B>Note:</B></TD><TD ALIGN="LEFT" VALIGN="TOP">An AFS-modified login utility always grants a token with a lifetime
-calculated from the previously described three values. When issuing the
-<B>klog</B> command, a user can request a lifetime shorter than the
-default by using the <B>-lifetime</B> argument. For further
-information, see the <I>IBM AFS User Guide</I> and the <B>klog</B>
-reference page in the <I>IBM AFS Administration Reference</I>.
-</TD></TR></TABLE>
-<P><H3><A NAME="Header_83" HREF="auagd002.htm#ToC_83">Changing Passwords</A></H3>
-<A NAME="IDX5785"></A>
-<A NAME="IDX5786"></A>
-<A NAME="IDX5787"></A>
-<A NAME="IDX5788"></A>
-<A NAME="IDX5789"></A>
-<P>Regular AFS users can change their own passwords by using either the
-<B>kpasswd</B> or <B>kas setpassword</B> command. The commands
-prompt for the current password and then twice for the new password, to screen
-out typing errors.
-<P>Administrators who have the <TT>ADMIN</TT> flag on their Authentication
-Database entries can change any user's password, either by using the
-<B>kpasswd</B> command (which requires knowing the current password) or
-the <B>kas setpassword</B> command.
-<P>If your cell does not use an AFS-modified login utility, remember also to
-change the local password, using the operating system's password-changing
-command. For more instructions on changing passwords, see <A HREF="auagd018.htm#HDRWQ516">Changing AFS Passwords</A>.
-<P><H3><A NAME="Header_84" HREF="auagd002.htm#ToC_84">Imposing Restrictions on Passwords and Authentication Attempts</A></H3>
-<P>You can help to make your cell more secure by imposing restrictions on
-user passwords and authentication attempts. To impose the restrictions
-as you create an account, use the <B>A</B> instruction in the
-<B>uss</B> template file as described in <A HREF="auagd017.htm#HDRWQ478">Increasing Account Security with the A Instruction</A>. To set or change the values on an existing
-account, use the <B>kas setfields</B> command as described in <A HREF="auagd018.htm#HDRWQ515">Improving Password and Authentication Security</A>.
-<A NAME="IDX5790"></A>
-<A NAME="IDX5791"></A>
-<A NAME="IDX5792"></A>
-<A NAME="IDX5793"></A>
-<A NAME="IDX5794"></A>
-<A NAME="IDX5795"></A>
-<P>By default, AFS passwords never expire. Limiting password lifetime
-can help improve security by decreasing the time the password is subject to
-cracking attempts. You can choose an lifetime from 1 to 254 days after
-the password was last changed. It automatically applies to each new
-password as it is set. When the user changes passwords, you can also
-insist that the new password is not similar to any of the 20 passwords
-previously used.
-<A NAME="IDX5796"></A>
-<A NAME="IDX5797"></A>
-<A NAME="IDX5798"></A>
-<A NAME="IDX5799"></A>
-<P>Unscrupulous users can try to gain access to your AFS cell by guessing an
-authorized user's password. To protect against this type of
-attack, you can limit the number of times that a user can consecutively fail
-to provide the correct password. When the limit is exceeded, the
-authentication service refuses further authentication attempts for a specified
-period of time (the <I>lockout time</I>). To reenable
-authentication attempts before the lockout time expires, an administrator must
-issue the <B>kas unlock</B> command.
-<A NAME="IDX5800"></A>
-<A NAME="IDX5801"></A>
-<A NAME="IDX5802"></A>
-<A NAME="IDX5803"></A>
-<A NAME="IDX5804"></A>
-<A NAME="IDX5805"></A>
-<P>In addition to settings on user's authentication accounts, you can
-improve security by automatically checking the quality of new user
-passwords. The <B>kpasswd</B> and <B>kas setpassword</B>
-commands pass the proposed password to a program or script called
-<B>kpwvalid</B>, if it exists. The <B>kpwvalid</B> performs
-quality checks and returns a code to indicate whether the password is
-acceptable. You can create your own program or modified the sample
-program included in the AFS distribution. See the <B>kpwvalid</B>
-reference page in the <I>IBM AFS Administration Reference</I>.
-<P>There are several types of quality checks that can improve password
-quality.
-<UL>
-<P><LI>The password is a minimum length
-<P><LI>The password is not a word
-<P><LI>The password contains both numbers and letters
-</UL>
-<P><H3><A NAME="HDRWQ70" HREF="auagd002.htm#ToC_85">Support for Kerberos Authentication</A></H3>
-<A NAME="IDX5806"></A>
-<A NAME="IDX5807"></A>
-<A NAME="IDX5808"></A>
-<A NAME="IDX5809"></A>
-<A NAME="IDX5810"></A>
-<A NAME="IDX5811"></A>
-<A NAME="IDX5812"></A>
-<P>If your site is using standard Kerberos authentication rather than the AFS
-Authentication Server, use the modified versions of the <B>klog</B>,
-<B>pagsh</B>, and <B>tokens</B> commands that support Kerberos
-authentication. The binaries for the modified version of these commands
-have the same name as the standard binaries with the addition of a
-<B>.krb</B> extension.
-<P>Use either the Kerberos version or the standard command throughout the
-cell; do not mix the two versions. AFS Product Support can provide
-instructions on installing the Kerberos version of these four commands.
-For information on the differences between the two versions of these commands,
-see the <I>IBM AFS Administration Reference</I>.
-<HR><H2><A NAME="HDRWQ71" HREF="auagd002.htm#ToC_86">Security and Authorization in AFS</A></H2>
-<P>AFS incorporates several features to ensure that only
-authorized users gain access to data. This section summarizes the most
-important of them and suggests methods for improving security in your
-cell.
-<P><H3><A NAME="HDRWQ72" HREF="auagd002.htm#ToC_87">Some Important Security Features</A></H3>
-<A NAME="IDX5813"></A>
-<A NAME="IDX5814"></A>
-<P><B>ACLs on Directories</B>
-<P>Files in AFS are protected by the access control list (ACL) associated with
-their parent directory. The ACL defines which users or groups can
-access the data in the directory, and in what way. See <A HREF="auagd020.htm#HDRWQ562">Managing Access Control Lists</A>.
-<P><B>Mutual Authentication Between Client and Server</B>
-<P>When an AFS client and server process communicate, each requires the other
-to prove its identity during mutual authentication, which involves the
-exchange of encrypted information that only valid parties can decrypt and
-respond to. For a detailed description of the mutual authentication
-process, see <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.
-<P>AFS server processes mutually authenticate both with one another and with
-processes that represent human users. After mutual authentication is
-complete, the server and client have established an authenticated connection,
-across which they can communicate repeatedly without having to authenticate
-again until the connection expires or one of the parties closes it.
-Authenticated connections have varying lifetimes.
-<P><B>Tokens</B>
-<P>In order to access AFS files, users must prove their identities to the AFS
-authentication service by providing the correct AFS password. If the
-password is correct, the authentication service sends the user a
-<I>token</I> as evidence of authenticated status. See <A HREF="#HDRWQ63">Login and Authentication in AFS</A>.
-<P>Servers assign the user identity <B>anonymous</B> to users and
-processes that do not have a valid token. The <B>anonymous</B>
-identity has only the access granted to the <B>system:anyuser</B>
-group on ACLs.
-<P><B>Authorization Checking</B>
-<P>Mutual authentication establishes that two parties communicating with one
-another are actually who they claim to be. For many functions, AFS
-server processes also check that the client whose identity they have verified
-is also authorized to make the request. Different requests require
-different kinds of privilege. See <A HREF="#HDRWQ73">Three Types of Privilege</A>.
-<P><B>Encrypted Network Communications</B>
-<A NAME="IDX5815"></A>
-<A NAME="IDX5816"></A>
-<A NAME="IDX5817"></A>
-<P>The AFS server processes encrypt particularly sensitive information before
-sending it back to clients. Even if an unauthorized party is able to
-eavesdrop on an authenticated connection, they cannot decipher encrypted data
-without the proper key.
-<P>The following AFS commands encrypt data because they involve server
-encryption keys and passwords:
-<UL>
-<P><LI>The <B>bos addkey</B> command, which adds a server encryption key to
-the <B>/usr/afs/etc/KeyFile</B> file
-<P><LI>The <B>bos listkeys</B> command, which lists the server encryption
-keys from the <B>/usr/afs/etc/KeyFile</B> file
-<P><LI>The <B>kpasswd</B> command, which changes a password in the
-Authentication Database
-<P><LI>Most commands in the <B>kas</B> command suite
-</UL>
-<P>In addition, the United States edition of the Update Server encrypts
-sensitive information (such as the contents of <B>KeyFile</B>) when
-distributing it. Other commands in the <B>bos</B> suite and the
-commands in the <B>fs</B>, <B>pts</B> and <B>vos</B> suites do not
-encrypt data before transmitting it.
-<P><H3><A NAME="HDRWQ73" HREF="auagd002.htm#ToC_88">Three Types of Privilege</A></H3>
-<P>AFS uses three separate types of privilege for the reasons
-discussed in <A HREF="auagd021.htm#HDRWQ585">The Reason for Separate Privileges</A>.
-<UL>
-<P><LI>Membership in the <B>system:administrators</B> group.
-Members are entitled to issue any <B>pts</B> command and those
-<B>fs</B> commands that set volume quota. By default, they also
-implicitly have the <B>a</B> (<B>administer</B>) and <B>l</B>
-(<B>lookup</B>) permissions on every ACL in the file tree even if the ACL
-does not include an entry for them.
-<P><LI>The <TT>ADMIN</TT> flag on the Authentication Database entry. An
-administrator with this flag can issue any <B>kas</B> command.
-<P><LI>Inclusion in the <B>/usr/afs/etc/UserList</B> file. An
-administrator whose username appears in this file can issue any
-<B>bos</B>, <B>vos</B>, or <B>backup</B> command (although some
-<B>backup</B> commands require additional privilege as described in <A HREF="auagd011.htm#HDRWQ260">Granting Administrative Privilege to Backup Operators</A>).
-</UL>
-<P><H3><A NAME="Header_89" HREF="auagd002.htm#ToC_89">Authorization Checking versus Authentication</A></H3>
-<P>AFS distinguishes between authentication and authorization
-checking. <I>Authentication</I> refers to the process of proving
-identity. <I>Authorization checking</I> refers to the process of
-verifying that an authenticated identity is allowed to perform a certain
-action.
-<P>AFS implements authentication at the level of connections. Each time
-two parties establish a new connection, they mutually authenticate. In
-general, each issue of an AFS command establishes a new connection between AFS
-server process and client.
-<P>AFS implements authorization checking at the level of server
-machines. If authorization checking is enabled on a server machine,
-then all of the server processes running on it provide services only to
-authorized users. If authorization checking is disabled on a server
-machine, then all of the server processes perform any action for
-anyone. Obviously, disabling authorization checking is an extreme
-security exposure. For more information, see <A HREF="auagd008.htm#HDRWQ123">Managing Authentication and Authorization Requirements</A>.
-<P><H3><A NAME="HDRWQ74" HREF="auagd002.htm#ToC_90">Improving Security in Your Cell</A></H3>
-<A NAME="IDX5818"></A>
-<P>You can improve the level of security in your cell by configuring user
-accounts, server machines, and system administrator accounts in the indicated
-way.
-<P><B>User Accounts</B>
-<UL>
-<P><LI>Use an AFS-modified login utility, or include the <B>-setpag</B> flag
-to the <B>klog</B> command, to associate the credential structure that
-houses tokens with a PAG rather than a UNIX UID. This prevents users
-from inheriting someone else's tokens by assuming their UNIX
-identity. For further discussion, see <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
-<P><LI>Encourage users to issue the <B>unlog</B> command to destroy their
-tokens before logging out. This forestalls attempts to access tokens
-left behind kernel memory. Consider including the <B>unlog</B>
-command in every user's <B>.logout</B> file or
-equivalent.
-</UL>
-<P><B>Server Machines</B>
-<UL>
-<P><LI>Disable authorization checking only in emergencies or for very brief
-periods of time. It is best to work at the console of the affected
-machine during this time, to prevent anyone else from accessing the machine
-through the keyboard.
-<P><LI>Change the AFS server encryption key on a frequent and regular
-schedule. Make it difficult to guess (a long string including
-nonalphabetic characters, for instance). Unlike user passwords, the
-password from which the AFS key is derived can be longer than eight
-characters, because it is never used during login. The <B>kas
-setpassword</B> command accepts a password hundreds of characters
-long. For instructions, see <A HREF="auagd014.htm#HDRWQ355">Managing Server Encryption Keys</A>.
-<P><LI>As much as possible, limit the number of people who can login at a server
-machine's console or remotely. Imposing this limit is an extra
-security precaution rather than a necessity. The machine cannot serve
-as an AFS client in this case.
-<P><LI>Particularly limit access to the local superuser <B>root</B> account
-on a server machine. The local superuser <B>root</B> has free
-access to important administrative subdirectories of the <B>/usr/afs</B>
-directory, as described in <A HREF="#HDRWQ53">AFS Files on the Local Disk</A>.
-<A NAME="IDX5819"></A>
-<P><LI>As in any computing environment, server machines must be located in a
-secured area. Any other security measures are effectively worthless if
-unauthorized people can access the computer hardware.
-</UL>
-<P><B>System Administrators</B>
-<UL>
-<P><LI>Limit the number of system administrators in your cell. Limit the
-use of system administrator accounts on publicly accessible
-workstations. Such machines are not secure, so unscrupulous users can
-install programs that try to steal tokens or passwords. If
-administrators must use publicly accessible workstations at times, they must
-issue the <B>unlog</B> command before leaving the machine.
-<P><LI>Create an administrative account for each administrator separate from the
-personal account, and assign AFS privileges only to the administrative
-account. The administrators must authenticate to the administrative
-accounts to perform duties that require privilege, which provides a useful
-audit trail as well.
-<P><LI>Administrators must not leave a machine unattended while they have valid
-tokens. Issue the <B>unlog</B> command before leaving.
-<P><LI>Use the <B>-lifetime</B> argument to the <B>kas setfields</B>
-command to set the token lifetime for administrative accounts to a fairly
-short amount of time. The default lifetime for AFS tokens is 25 hours,
-but 30 or 60 minutes is possibly a more reasonable lifetime for administrative
-tokens. The tokens for administrators who initiate AFS Backup System
-operations must last somewhat longer, because it can take several hours to
-complete some dump operations, depending on the speed of the tape device and
-the network connecting it to the file server machines that house the volumes
-is it accessing.
-<P><LI>Limit administrators' use of the <B>telnet</B> program. It
-sends unencrypted passwords across the network. Similarly, limit use of
-other remote programs such as <B>rsh</B> and <B>rcp</B>, which send
-unencrypted tokens across the network.
-</UL>
-<A NAME="IDX5820"></A>
-<A NAME="IDX5821"></A>
-<A NAME="IDX5822"></A>
-<A NAME="IDX5823"></A>
-<P><H3><A NAME="HDRWQ75" HREF="auagd002.htm#ToC_91">A More Detailed Look at Mutual Authentication</A></H3>
-<P>As in any file system, security is a prime concern in
-AFS. A file system that makes file sharing easy is not useful if it
-makes file sharing mandatory, so AFS incorporates several features that
-prevent unauthorized users from accessing data. Security in a networked
-environment is difficult because almost all procedures require transmission of
-information across wires that almost anyone can tap into. Also, many
-machines on networks are powerful enough that unscrupulous users can monitor
-transactions or even intercept transmissions and fake the identity of one of
-the participants.
-<P>The most effective precaution against eavesdropping and information theft
-or fakery is for servers and clients to accept the claimed identity of the
-other party only with sufficient proof. In other words, the nature of
-the network forces all parties on the network to assume that the other party
-in a transaction is not genuine until proven so. <I>Mutual
-authentication</I> is the means through which parties prove their
-genuineness.
-<P>Because the measures needed to prevent fakery must be quite sophisticated,
-the implementation of mutual authentication procedures is complex. The
-underlying concept is simple, however: parties prove their identities by
-demonstrating knowledge of a <I>shared secret</I>. A shared secret
-is a piece of information known only to the parties who are mutually
-authenticating (they can sometimes learn it in the first place from a trusted
-third party or some other source). The party who originates the
-transaction presents the shared secret and refuses to accept the other party
-as valid until it shows that it knows the secret too.
-<P>The most common form of shared secret in AFS transactions is the
-<I>encryption key</I>, also referred to simply as a <I>key</I>.
-The two parties use their shared key to encrypt the packets of information
-they send and to decrypt the ones they receive. Encryption using keys
-actually serves two related purposes. First, it protects messages as
-they cross the network, preventing anyone who does not know the key from
-eavesdropping. Second, ability to encrypt and decrypt messages
-successfully indicates that the parties are using the key (it is their shared
-secret). If they are using different keys, messages remain scrambled
-and unintelligible after decryption.
-<P>The following sections describe AFS's mutual authentication procedures
-in more detail. Feel free to skip these sections if you are not
-interested in the mutual authentication process.
-<P><H4><A NAME="Header_92">Simple Mutual Authentication</A></H4>
-<P>Simple mutual authentication involves only one encryption key and two
-parties, generally a client and server. The client contacts the server
-by sending a <I>challenge</I> message encrypted with a key known only to
-the two of them. The server decrypts the message using its key, which
-is the same as the client's if they really do share the same
-secret. The server responds to the challenge and uses its key to
-encrypt its response. The client uses its key to decrypt the
-server's response, and if it is correct, then the client can be sure that
-the server is genuine: only someone who knows the same key as the client
-can decrypt the challenge and answer it correctly. On its side, the
-server concludes that the client is genuine because the challenge message made
-sense when the server decrypted it.
-<P>AFS uses simple mutual authentication to verify user identities during the
-first part of the login procedure. In that case, the key is based on
-the user's password.
-<P><H4><A NAME="HDRWQ76">Complex Mutual Authentication</A></H4>
-<P>Complex mutual authentication involves three encryption keys
-and three parties. All secure AFS transactions (except the first part
-of the login process) employ complex mutual authentication.
-<A NAME="IDX5824"></A>
-<A NAME="IDX5825"></A>
-<A NAME="IDX5826"></A>
-<P>When a client wishes to communicate with a server, it first contacts a
-third party called a <I>ticket-granter</I>. The ticket-granter and
-the client mutually authenticate using the simple procedure. When they
-finish, the ticket-granter gives the client a <I>server ticket</I> (or
-simply <I>ticket</I>) as proof that it (the ticket-granter) has
-preverified the identity of the client. The ticket-granter encrypts the
-ticket with the first of the three keys, called the <I>server encryption
-key</I> because it is known only to the ticket-granter and the server the
-client wants to contact. The client does not know this key.
-<P>The ticket-granter sends several other pieces of information along with the
-ticket. They enable the client to use the ticket effectively despite
-being unable to decrypt the ticket itself. Along with the ticket, the
-items constitute a <I>token</I>:
-<UL>
-<A NAME="IDX5827"></A>
-<P><LI>A <I>session key</I>, which is the second encryption key involved in
-mutual authentication. The ticket-granter invents the session key at
-random as the shared secret between client and server. For reasons
-explained further below, the ticket-granter also puts a copy of the session
-key inside the ticket. The client and server use the session key to
-encrypt messages they send to one another during their transactions.
-The ticket-granter invents a different session key for each connection between
-a client and a server (there can be several transactions during a single
-connection).
-<P><LI>The name of the server for which the ticket is valid (and so which server
-encryption key encrypts the ticket itself).
-<P><LI>A ticket lifetime indicator. The default lifetime of AFS server
-tickets is 100 hours. If the client wants to contact the server again
-after the ticket expires, it must contact the ticket-granter to get a new
-ticket.
-</UL>
-<P>The ticket-granter seals the entire token with the third key involved in
-complex mutual authentication--the key known only to it (the
-ticket-granter) and the client. In some cases, this third key is
-derived from the password of the human user whom the client represents.
-<P>Now that the client has a valid server ticket, it is ready to contact the
-server. It sends the server two things:
-<UL>
-<P><LI>The server ticket. This is encrypted with the server encryption
-key.
-<P><LI>Its request message, encrypted with the session key. Encrypting the
-message protects it as it crosses the network, since only the server/client
-pair for whom the ticket-granter invented the session key know it.
-</UL>
-<P>At this point, the server does not know the session key, because the
-ticket-granter just created it. However, the ticket-granter put a copy
-of the session key inside the ticket. The server uses the server
-encryption key to decrypts the ticket and learns the session key. It
-then uses the session key to decrypt the client's request message.
-It generates a response and sends it to the client. It encrypts the
-response with the session key to protect it as it crosses the network.
-<P>This step is the heart of mutual authentication between client and server,
-because it proves to both parties that they know the same secret:
-<UL>
-<P><LI>The server concludes that the client is authorized to make a request
-because the request message makes sense when the server decrypts it using the
-session key. If the client uses a different session key than the one
-the server finds inside the ticket, then the request message remains
-unintelligible even after decryption. The two copies of the session key
-(the one inside the ticket and the one the client used) can only be the same
-if they both came from the ticket-granter. The client cannot fake
-knowledge of the session key because it cannot look inside the ticket, sealed
-as it is with the server encryption key known only to the server and the
-ticket-granter. The server trusts the ticket-granter to give tokens
-only to clients with whom it (the ticket-granter) has authenticated, so the
-server decides the client is legitimate.
-<P>(Note that there is no direct communication between the ticket-granter and
-the server, even though their relationship is central to ticket-based mutual
-authentication. They interact only indirectly, via the client's
-possession of a ticket sealed with their shared secret.)
-<P><LI>The client concludes that the server is genuine and trusts the response it
-gets back from the server, because the response makes sense after the client
-decrypts it using the session key. This indicates that the server
-encrypted the response with the same session key as the client knows.
-The only way for the server to learn that matching session key is to decrypt
-the ticket first. The server can only decrypt the ticket because it
-shares the secret of the server encryption key with the ticket-granter.
-The client trusts the ticket-granter to give out tickets only for legitimate
-servers, so the client accepts a server that can decrypt the ticket as
-genuine, and accepts its response.
-</UL>
-<HR><H2><A NAME="HDRWQ77" HREF="auagd002.htm#ToC_94">Backing Up AFS Data</A></H2>
-<P>AFS provides two related facilities that help the
-administrator back up AFS data: backup volumes and the AFS Backup
-System.
-<P><H3><A NAME="Header_95" HREF="auagd002.htm#ToC_95">Backup Volumes</A></H3>
-<P>The first facility is the backup volume, which you create by cloning a
-read/write volume. The backup volume is read-only and so preserves the
-state of the read/write volume at the time the clone is made.
-<P>Backup volumes can ease administration if you mount them in the file system
-and make their contents available to users. For example, it often makes
-sense to mount the backup version of each user volume as a subdirectory of the
-user's home directory. A conventional name for this mount point is
-<B>OldFiles</B>. Create a new version of the backup volume (that
-is, reclone the read/write) once a day to capture any changes that were made
-since the previous backup. If a user accidentally removes or changes
-data, the user can restore it from the backup volume, rather than having to
-ask you to restore it.
-<P>The <I>IBM AFS User Guide</I> does not mention backup volumes, so
-regular users do not know about them if you decide not to use them.
-This implies that if you <B>do</B> make backup versions of user volumes,
-you need to tell your users about how the backup works and where you have
-mounted it.
-<P>Users are often concerned that the data in a backup volume counts against
-their volume quota and some of them even want to remove the
-<B>OldFiles</B> mount point. It does not, because the backup volume
-is a separate volume. The only amount of space it uses in the
-user's volume is the amount needed for the mount point, which is about
-the same as the amount needed for a standard directory element.
-<P>Backup volumes are discussed in detail in <A HREF="auagd010.htm#HDRWQ201">Creating Backup Volumes</A>.
-<P><H3><A NAME="Header_96" HREF="auagd002.htm#ToC_96">The AFS Backup System</A></H3>
-<P>Backup volumes can reduce restoration requests, but they reside on disk
-and so do not protect data from loss due to hardware failure. Like any
-file system, AFS is vulnerable to this sort of data loss.
-<P>To protect your cell's users from permanent loss of data, you are
-strongly urged to back up your file system to tape on a regular and frequent
-schedule. The AFS Backup System is available to ease the administration
-and performance of backups. For detailed information about the AFS
-Backup System, see <A HREF="auagd011.htm#HDRWQ248">Configuring the AFS Backup System</A> and <A HREF="auagd012.htm#HDRWQ283">Backing Up and Restoring AFS Data</A>.
-<A NAME="IDX5828"></A>
-<A NAME="IDX5829"></A>
-<A NAME="IDX5830"></A>
-<A NAME="IDX5831"></A>
-<A NAME="IDX5832"></A>
-<A NAME="IDX5833"></A>
-<A NAME="IDX5834"></A>
-<A NAME="IDX5835"></A>
-<A NAME="IDX5836"></A>
-<A NAME="IDX5837"></A>
-<A NAME="IDX5838"></A>
-<A NAME="IDX5839"></A>
-<HR><H2><A NAME="HDRWQ78" HREF="auagd002.htm#ToC_97">Using UNIX Remote Services in the AFS Environment</A></H2>
-<P>The AFS distribution includes modified versions of several
-standard UNIX commands, daemons and programs that provide remote services,
-including the following:
-<UL>
-<P><LI>The <B>ftpd</B> program
-<P><LI>The <B>inetd</B> daemon
-<P><LI>The <B>rcp</B> program
-<P><LI>The <B>rlogind</B> daemon
-<P><LI>The <B>rsh</B> command
-</UL>
-<P>These modifications enable the commands to handle AFS authentication
-information (tokens). This enables issuers to be recognized on the
-remote machine as an authenticated AFS user.
-<P>Replacing the standard versions of these programs in your file tree with
-the AFS-modified versions is optional. It is likely that AFS's
-transparent access reduces the need for some of the programs anyway,
-especially those involved in transferring files from machine to machine, like
-the <B>ftpd</B> and <B>rcp</B> programs.
-<P>If you decide to use the AFS versions of these commands, be aware that
-several of them are interdependent. For example, the passing of AFS
-authentication information works correctly with the <B>rcp</B> command
-only if you are using the AFS version of both the <B>rcp</B> and
-<B>inetd</B> commands.
-<P>The conventional installation location for the modified remote commands are
-the <B>/usr/afsws/bin</B> and <B>/usr/afsws/etc</B>
-directories. To learn more about commands' functionality, see
-their reference pages in the <I>IBM AFS Administration
-Reference</I>.
-<HR><H2><A NAME="HDRWQ79" HREF="auagd002.htm#ToC_98">Accessing AFS through NFS</A></H2>
-<P>Users of NFS client machines can access the AFS filespace by
-mounting the <B>/afs</B> directory of an AFS client machine that is
-running the <I>NFS/AFS Translator</I>. This is a particular
-advantage in cells already running NFS who want to access AFS using client
-machines for which AFS is not available. See <A HREF="auagd022.htm#HDRWQ595">Appendix A, Managing the NFS/AFS Translator</A>.
-<HR><P ALIGN="center"> <A HREF="../index.htm"><IMG SRC="../books.gif" BORDER="0" ALT="[Return to Library]"></A> <A HREF="auagd002.htm#ToC"><IMG SRC="../toc.gif" BORDER="0" ALT="[Contents]"></A> <A HREF="auagd006.htm"><IMG SRC="../prev.gif" BORDER="0" ALT="[Previous Topic]"></A> <A HREF="#Top_Of_Page"><IMG SRC="../top.gif" BORDER="0" ALT="[Top of Topic]"></A> <A HREF="auagd008.htm"><IMG SRC="../next.gif" BORDER="0" ALT="[Next Topic]"></A> <A HREF="auagd026.htm#HDRINDEX"><IMG SRC="../index.gif" BORDER="0" ALT="[Index]"></A> <P>
-<!-- Begin Footer Records ========================================== -->
-<P><HR><B>
-<br>© <A HREF="http://www.ibm.com/">IBM Corporation 2000.</A> All Rights Reserved
-</B>
-<!-- End Footer Records ============================================ -->
-<A NAME="Bot_Of_Page"></A>
-</BODY></HTML>
git://git.openafs.org / openafs.git / blobdiff