1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 4//EN">
3 <TITLE>Administration Guide</TITLE>
4 <!-- Begin Header Records ========================================== -->
5 <!-- /tmp/idwt3570/auagd000.scr converted by idb2h R4.2 (359) ID -->
6 <!-- Workbench Version (AIX) on 2 Oct 2000 at 11:42:14 -->
7 <META HTTP-EQUIV="updated" CONTENT="Mon, 02 Oct 2000 11:42:13">
8 <META HTTP-EQUIV="review" CONTENT="Tue, 02 Oct 2001 11:42:13">
9 <META HTTP-EQUIV="expires" CONTENT="Wed, 02 Oct 2002 11:42:13">
11 <!-- (C) IBM Corporation 2000. All Rights Reserved -->
12 <BODY bgcolor="ffffff">
13 <!-- End Header Records ============================================ -->
14 <A NAME="Top_Of_Page"></A>
15 <H1>Administration Guide</H1>
16 <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>
17 <HR><H1><A NAME="HDRWQ29" HREF="auagd002.htm#ToC_33">Issues in Cell Configuration and Administration</A></H1>
18 <P>This chapter discusses many of the issues to consider when
19 configuring and administering a cell, and directs you to detailed related
20 information available elsewhere in this guide. It is assumed you are
21 already familiar with the material in <A HREF="auagd006.htm#HDRWQ5">An Overview of AFS Administration</A>.
22 <P>It is best to read this chapter before installing your cell's first
23 file server machine or performing any other administrative task.
24 <A NAME="IDX5609"></A>
25 <A NAME="IDX5610"></A>
26 <A NAME="IDX5611"></A>
27 <HR><H2><A NAME="HDRWQ30" HREF="auagd002.htm#ToC_34">Differences between AFS and UNIX: A Summary</A></H2>
28 <P>AFS behaves like a standard UNIX file system in most
29 respects, while also making file sharing easy within and between cells.
30 This section describes some differences between AFS and the UNIX file system,
31 referring you to more detailed information as appropriate.
32 <A NAME="IDX5612"></A>
33 <P><H3><A NAME="Header_35" HREF="auagd002.htm#ToC_35">Differences in File and Directory Protection</A></H3>
34 <P>AFS augments the standard UNIX file protection mechanism in two
35 ways: it associates an <I>access control list</I> (<I>ACL</I>)
36 with each directory, and it enables users to define a large number of their
37 own groups, which can be placed on ACLs.
38 <P>AFS uses ACLs to protect files and directories, rather than relying
39 exclusively on the mode bits. This has several implications, which are
40 discussed further in the indicated sections:
42 <P><LI>AFS ACLs use seven access permissions rather than the three UNIX mode
43 bits. See <A HREF="auagd020.htm#HDRWQ567">The AFS ACL Permissions</A>.
44 <P><LI>For directories, AFS ignores the UNIX mode bits. For files, AFS
45 uses only the first set of mode bits (the <B>owner</B> bits) , and their
46 meaning interacts with permissions on the directory's ACL. See <A HREF="auagd020.htm#HDRWQ580">How AFS Interprets the UNIX Mode Bits</A>.
47 <P><LI>A directory's ACL protects all of the files in a directory in the
48 same manner. To apply a more restrictive set of AFS permissions to
49 certain file, place it in directory with a different ACL.
50 <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>.
51 <P><LI>An ACL can include about 20 entries granting different combinations of
52 permissions to different users or groups, rather than only the three UNIX
53 entities represented by the three sets of mode bits. See <A HREF="auagd020.htm#HDRWQ566">Differences Between UFS and AFS Data Protection</A>.
54 <P><LI>You can designate an AFS file as write-only as in the UNIX file system, by
55 setting only the <B>w</B> (<B>write</B>) mode bit. You cannot
56 designate an AFS directory as write-only, because AFS ignores the mode bits on
57 a directory. See <A HREF="auagd020.htm#HDRWQ580">How AFS Interprets the UNIX Mode Bits</A>.
59 <P>AFS enables users to define the groups of other users. Placing these
60 groups on ACLs extends the same permissions to a number of exactly specified
61 users at the same time, which is much more convenient than placing the
62 individuals on the ACLs directly. See <A HREF="auagd019.htm#HDRWQ531">Administering the Protection Database</A>.
63 <P>There are also system-defined groups, <B>system:anyuser</B> and
64 <B>system:authuser</B>, whose presence on an ACL extends access to a
65 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>.
66 <A NAME="IDX5613"></A>
67 <A NAME="IDX5614"></A>
68 <P><H3><A NAME="HDRWQ31" HREF="auagd002.htm#ToC_36">Differences in Authentication</A></H3>
69 <P>Just as the AFS filespace is distinct from each
70 machine's local file system, AFS authentication is separate from local
71 login. This has two practical implications, which are discussed further
72 in <A HREF="#HDRWQ65">Using an AFS-modified login Utility</A>.
74 <P><LI>To access AFS files, users must both log into the local machine's
75 UNIX file system and authenticate with the AFS authentication service.
76 (Logging into the local UNIX file system is necessary because the AFS
77 filespace is accessed through the Cache Manager, which resides in the local
79 <P>AFS provides a modified login utility for each system type that
80 accomplishes both local login and AFS authentication in one step, based on a
81 single password. If you choose not to use the AFS-modified login
82 utility, your users must login and authenticate in separate steps, as detailed
83 in the <I>IBM AFS User Guide</I>.
84 <P><LI>Passwords are stored in two separate places: the Authentication
85 Database for AFS and each machine's local password file
86 (<B>/etc/passwd</B> or equivalent) for the UNIX file system. A
87 user's passwords in the two places can differ if desired, though the
88 resulting behavior depends on whether and how the cell is using an
89 AFS-modified login utility.
91 <P><H3><A NAME="Header_37" HREF="auagd002.htm#ToC_37">Differences in the Semantics of Standard UNIX Commands</A></H3>
92 <P>This section summarizes how AFS modifies the functionality of some UNIX
95 <A NAME="IDX5615"></A>
96 <A NAME="IDX5616"></A>
97 <A NAME="IDX5617"></A>
98 <P><DT><B>The chmod command
99 </B><DD>Only members of the <B>system:administrators</B> group can use
100 this command to turn on the setuid, setgid or sticky mode bits on AFS
101 files. For more information, see <A HREF="auagd015.htm#HDRWQ409">Determining if a Client Can Run Setuid Programs</A>.
102 <A NAME="IDX5618"></A>
103 <A NAME="IDX5619"></A>
104 <P><DT><B>The chown command
105 </B><DD>Only members of the <B>system:administrators</B> group can issue
106 this command on AFS files.
107 <A NAME="IDX5620"></A>
108 <A NAME="IDX5621"></A>
109 <P><DT><B>The chgrp command
110 </B><DD>Only members of the <B>system:administrators</B> can issue this
111 command on AFS files and directories.
112 <A NAME="IDX5622"></A>
113 <A NAME="IDX5623"></A>
114 <P><DT><B>The ftpd daemon
115 </B><DD>The AFS-modified version of this daemon attempts to authenticate remote
116 issuers of the <B>ftp</B> command with the local AFS authentication
117 service. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
118 <A NAME="IDX5624"></A>
119 <A NAME="IDX5625"></A>
120 <P><DT><B>The groups command
121 </B><DD>If the user's AFS tokens are associated with a process authentication
122 group (PAG), the output of this command sometimes includes two large
123 numbers. To learn about PAGs, see <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
124 <A NAME="IDX5626"></A>
125 <A NAME="IDX5627"></A>
126 <P><DT><B>The inetd daemon
127 </B><DD>The AFS-modified version of this daemon authenticates remote issuers of
128 the AFS-modified <B>rcp</B> and <B>rsh</B> commands with the local AFS
129 authentication service. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
130 <P><DT><B>The login utility
131 </B><DD>AFS-modified login utilities both log the issuer into the local file
132 system and authenticate the user with the AFS authentication service.
133 See <A HREF="#HDRWQ65">Using an AFS-modified login Utility</A>.
134 <A NAME="IDX5628"></A>
135 <A NAME="IDX5629"></A>
136 <P><DT><B>The ln command
137 </B><DD>This command cannot create hard links between files in different AFS
138 directories. See <A HREF="#HDRWQ32">Creating Hard Links</A>.
139 <A NAME="IDX5630"></A>
140 <A NAME="IDX5631"></A>
141 <P><DT><B>The rcp command
142 </B><DD>The AFS-modified version of this command enables the issuer to access
143 files on the remote machine as an authenticated AFS user. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
144 <A NAME="IDX5632"></A>
145 <A NAME="IDX5633"></A>
146 <P><DT><B>The rlogind daemon
147 </B><DD>The AFS-modified version of this daemon authenticates remote issuers of
148 the <B>rlogin</B> command with the local AFS authentication
149 service. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
150 <P>The AFS distribution for some system types possibly does not include a
151 modified <B>rlogind</B> program. See the <I>IBM AFS Release
153 <A NAME="IDX5634"></A>
154 <A NAME="IDX5635"></A>
155 <P><DT><B>The remsh or rsh command
156 </B><DD>The AFS-modified version of this command enables the issuer to execute
157 commands on the remote machine as an authenticated AFS user. See <A HREF="#HDRWQ78">Using UNIX Remote Services in the AFS Environment</A>.
159 <A NAME="IDX5636"></A>
160 <A NAME="IDX5637"></A>
161 <A NAME="IDX5638"></A>
162 <A NAME="IDX5639"></A>
163 <A NAME="IDX5640"></A>
164 <A NAME="IDX5641"></A>
165 <P><H3><A NAME="Header_38" HREF="auagd002.htm#ToC_38">The AFS version of the fsck Command</A></H3>
166 <P>Never run the standard UNIX <B>fsck</B> command on an AFS file
167 server machine. It does not understand how the File Server organizes
168 volume data on disk, and so moves all AFS data into the <B>lost+found</B>
169 directory on the partition.
170 <P>Instead, use the version of the <B>fsck</B> program that is included in
171 the AFS distribution. The <I>IBM AFS Quick Beginnings</I> explains
172 how to replace the vendor-supplied <B>fsck</B> program with the AFS
173 version as you install each server machine.
174 <P>The AFS version functions like the standard <B>fsck</B> program on data
175 stored on both UFS and AFS partitions. The appearance of a banner like
176 the following as the <B>fsck</B> program initializes confirms that you are
177 running the correct one:
178 <PRE> --- AFS (R) <VAR>version</VAR> fsck---
180 <P>where <VAR>version</VAR> is the AFS version. For correct results, it
181 must match the AFS version of the server binaries in use on the
183 <P>If you ever accidentally run the standard version of the program, contact
184 AFS Product Support immediately. It is sometimes possible to recover
185 volume data from the <B>lost+found</B> directory.
186 <A NAME="IDX5642"></A>
187 <A NAME="IDX5643"></A>
188 <P><H3><A NAME="HDRWQ32" HREF="auagd002.htm#ToC_39">Creating Hard Links</A></H3>
189 <P>AFS does not allow hard links (created with the UNIX
190 <B>ln</B> command) between files that reside in different directories,
191 because in that case it is unclear which of the directory's ACLs to
192 associate with the link.
193 <P>AFS also does not allow hard links to directories, in order to keep the
194 file system organized as a tree.
195 <P>It is possible to create symbolic links (with the UNIX <B>ln -s</B>
196 command) between elements in two different AFS directories, or even between an
197 element in AFS and one in a machine's local UNIX file system. Do
198 not create a symbolic link to a file whose name begins with either a number
199 sign (<B>#</B>) or a percent sign (<B>%</B>), however. The
200 Cache Manager interprets such links as a mount point to a regular or
201 read/write volume, respectively.
202 <A NAME="IDX5644"></A>
203 <A NAME="IDX5645"></A>
204 <A NAME="IDX5646"></A>
205 <P><H3><A NAME="HDRWQ33" HREF="auagd002.htm#ToC_40">AFS Implements Save on Close</A></H3>
206 <P>When an application issues the UNIX <B>close</B> system
207 call on a file, the Cache Manager performs a synchronous write of the data to
208 the File Server that maintains the central copy of the file. It does
209 not return control to the application until the File Server has acknowledged
210 receipt of the data. For the <B>fsync</B> system call, control does
211 not return to the application until the File Server indicates that it has
212 written the data to non-volatile storage on the file server machine.
213 <P>When an application issues the UNIX <B>write</B> system call, the Cache
214 Manager writes modifications to the local AFS client cache only. If the
215 local machine crashes or an application program exits without issuing the
216 <B>close</B> system call, it is possible that the modifications are not
217 recorded in the central copy of the file maintained by the File Server.
218 The Cache Manager does sometimes write this type of modified data from the
219 cache to the File Server without receiving the <B>close</B> or
220 <B>fsync</B> system call, for example if it needs to free cache chunks for
221 new data. However, it is not generally possible to predict when the
222 Cache Manager transfers modified data to the File Server in this way.
223 <P>The implication is that if an application's <B>Save</B> option
224 invokes the <B>write</B> system call rather than <B>close</B> or
225 <B>fsync</B>, the changes are not necessarily stored permanently on the
226 File Server machine. Most application programs issue the
227 <B>close</B> system call for save operations, as well as when they finish
228 handling a file and when they exit.
229 <P><H3><A NAME="Header_41" HREF="auagd002.htm#ToC_41">Setuid Programs</A></H3>
230 <A NAME="IDX5647"></A>
231 <P>Set the UNIX setuid bit only for the local superuser <B>root</B>;
232 this does not present an automatic security risk: the local superuser
233 has no special privilege in AFS, but only in the local machine's UNIX
234 file system and kernel.
235 <P>Any file can be marked with the setuid bit, but only members of the
236 <B>system:administrators</B> group can issue the <B>chown</B>
237 system call or the <B>/etc/chown</B> command.
238 <P>The <B>fs setcell</B> command determines whether setuid programs that
239 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>.
240 <A NAME="IDX5648"></A>
241 <A NAME="IDX5649"></A>
242 <A NAME="IDX5650"></A>
243 <A NAME="IDX5651"></A>
244 <HR><H2><A NAME="HDRWQ34" HREF="auagd002.htm#ToC_42">Choosing a Cell Name</A></H2>
245 <P>This section explains how to choose a cell name and explains
246 why choosing an appropriate cell name is important.
247 <P>Your cell name must distinguish your cell from all others in the AFS global
248 namespace. By conventions, the cell name is the second element in any
249 AFS pathname; therefore, a unique cell name guarantees that every AFS
250 pathname uniquely identifies a file, even if cells use the same directory
251 names at lower levels in their local AFS filespace. For example, both
252 the ABC Corporation cell and the State University cell can have a home
253 directory for the user <B>pat</B>, because the pathnames are
254 distinct: <B>/afs/abc.com/usr/pat</B> and
255 <B>/afs/stateu.edu/usr/pat</B>.
256 <P>By convention, cell names follow the ARPA Internet Domain System
257 conventions for site names. If you are already an Internet site, then
258 it is simplest to choose your Internet domain name as the cellname.
259 <P>If you are not an Internet site, it is best to choose a unique
260 Internet-style name, particularly if you plan to connect to the Internet in
261 the future. AFS Product Support is available for help in selecting an
262 appropriate name. There are a few constraints on AFS cell names:
264 <P><LI>It can contain as many as 64 characters, but shorter names are better
265 because the cell name frequently is part of machine and file names. If
266 your cell name is long, you can reduce pathname length by creating a symbolic
267 link to the complete cell name, at the second level in your file tree.
268 See <A HREF="#HDRWQ42">The Second (Cellname) Level</A>.
269 <P><LI>To guarantee it is suitable for different operating system types, the cell
270 name can contain only lowercase characters, numbers, underscores, dashes, and
271 periods. Do not include command shell metacharacters.
272 <P><LI>It can include any number of fields, which are conventionally separated by
273 periods (see the examples below).
274 <P><LI>It must end in a suffix that indicates the type of institution it is, or
275 the country in which it is situated. The following are some of the
279 </B><DD>For businesses and other commercial organizations. Example:
280 <B>abc.com</B> for the ABC Corporation cell.
282 </B><DD>For educational institutions such as universities. Example:
283 <B>stateu.edu</B> for the State University cell.
285 </B><DD>For United States government institutions.
287 </B><DD>For United States military installations.
290 <P>Other suffixes are available if none of these are appropriate.
291 <A NAME="IDX5652"></A>
292 <A NAME="IDX5653"></A>
293 You can learn about suffixes by calling the Defense Data Network [Internet]
294 Network Information Center in the United States at (800) 235-3155. The
295 NIC can also provide you with the forms necessary for registering your cell
296 name as an Internet domain name. Registering your name prevents another
297 Internet site from adopting the name later.
298 <A NAME="IDX5654"></A>
299 <A NAME="IDX5655"></A>
300 <A NAME="IDX5656"></A>
301 <A NAME="IDX5657"></A>
302 <P><H3><A NAME="Header_43" HREF="auagd002.htm#ToC_43">How to Set the Cell Name</A></H3>
303 <P>The cell name is recorded in two files on the local disk of each file
304 server and client machine. Among other functions, these files define
305 the machine's cell membership and so affect how programs and processes
306 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
307 for the two types of machines.
308 <P>For file server machines, the two files that record the cell name are the
309 <B>/usr/afs/etc/ThisCell</B> and <B>/usr/afs/etc/CellServDB</B>
310 files. As described more explicitly in the <I>IBM AFS Quick
311 Beginnings</I>, you set the cell name in both by issuing the <B>bos
312 setcellname</B> command on the first file server machine you install in your
313 cell. It is not usually necessary to issue the command again. If
314 you run the United States edition of AFS and use the Update Server, it
315 distributes its copy of the <B>ThisCell</B> and <B>CellServDB</B>
316 files to additional server machines that you install. If you use the
317 international edition of AFS, the <I>IBM AFS Quick Beginnings</I> explains
318 how to copy the files manually.
319 <P>For client machines, the two files that record the cell name are the
320 <B>/usr/vice/etc/ThisCell</B> and <B>/usr/vice/etc/CellServDB</B>
321 files. You create these files on a per-client basis, either with a text
322 editor or by copying them onto the machine from a central source in
323 AFS. See <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A> for details.
324 <P>Change the cell name in these files only when you want to transfer the
325 machine to a different cell (it can only belong to one cell at a time).
326 If the machine is a file server, follow the complete set of instructions in
327 the <I>IBM AFS Quick Beginnings</I> for configuring a new cell. If
328 the machine is a client, all you need to do is change the files appropriately
329 and reboot the machine. The next section explains further the negative
330 consequences of changing the name of an existing cell.
331 <P>To set the default cell name used by most AFS commands without changing the
332 local <B>/usr/vice/etc/ThisCell</B> file, set the AFSCELL environment
333 variable in the command shell. It is worth setting this variable if you
334 need to complete significant administrative work in a foreign cell.
335 <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
336 the AFSCELL variable. The <B>fs checkservers</B> command always
337 defaults to the cell named in the <B>ThisCell</B> file, unless the
338 <B>-cell</B> argument is used. The <B>fs mkmount</B> command
339 defaults to the cell in which the parent directory of the new mount point
342 <A NAME="IDX5658"></A>
343 <P><H3><A NAME="HDRWQ35" HREF="auagd002.htm#ToC_44">Why Choosing the Appropriate Cell Name is Important</A></H3>
344 <P>Take care to select a cell name that is suitable for
345 long-term use. Changing a cell name later is complicated. An
346 appropriate cell name is important because it is the second element in the
347 pathname of all files in a cell's file tree. Because each cell
348 name is unique, its presence in an AFS pathname makes the pathname unique in
349 the AFS global namespace, even if multiple cells use similar filespace
350 organization at lower levels. For instance, it means that every cell
351 can have a home directory called <B>/afs/<VAR>cellname</VAR>/usr/pat</B>
352 without causing a conflict. The presence of the cell name in pathnames
353 also means that users in every cell use the same pathname to access a file,
354 whether the file resides in their local cell or in a foreign cell.
355 <P>Another reason to choose the correct cell name early in the process of
356 installing your cell is that the cell membership defined in each
357 machine's <B>ThisCell</B> file affects the performance of many
358 programs and processes running on the machine. For instance, AFS
359 commands (<B>fs</B>, <B>kas</B>, <B>pts</B> and <B>vos</B>
360 commands) by default execute in the cell of the machine on which they are
361 issued. The command interpreters check the <B>ThisCell</B> file on
362 the local disk and then contact the database server machines listed in the
363 <B>CellServDB</B> file for the indicated cell (the <B>bos</B> commands
364 work differently because the issuer always has to name of the machine on which
366 <P>The <B>ThisCell</B> file also determines the cell for which a user
367 receives an AFS token when he or she logs in to a machine. The cell
368 name also plays a role in security. As it converts a user password into
369 an encryption key for storage in the Authentication Database, the
370 Authentication Server combines the password with the cell name found in the
371 <B>ThisCell</B> file. AFS-modified login utilities use the same
372 algorithm to convert the user's password into an encryption key before
373 contacting the Authentication Server to obtain a token for the user.
374 (For a description of how AFS's security system uses encryption keys, see
375 <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.)
376 <P>This method of converting passwords into encryption keys means that the
377 same password results in different keys in different cells. Even if a
378 user uses the same password in multiple cells, obtaining a user's token
379 from one cell does not enable unauthorized access to the user's account
381 <P>If you change the cell name, you must change the <B>ThisCell</B> and
382 <B>CellServDB</B> files on every server and client machine. Failure
383 to change them all can prevent login, because the encryption keys produced by
384 the login utility do not match the keys stored in the Authentication
385 Database. In addition, many commands from the AFS suites do not work as
387 <A NAME="IDX5659"></A>
388 <A NAME="IDX5660"></A>
389 <A NAME="IDX5661"></A>
390 <HR><H2><A NAME="HDRWQ36" HREF="auagd002.htm#ToC_45">Participating in the AFS Global Namespace</A></H2>
391 <P>Participating in the AFS global namespace makes your
392 cell's local file tree visible to AFS users in foreign cells and makes
393 other cells' file trees visible to your local users. It makes file
394 sharing across cells just as easy as sharing within a cell. This
395 section outlines the procedures necessary for participating in the global
398 <P><LI>Participation in the global namespace is not mandatory. Some cells
399 use AFS primarily to facilitate file sharing within the cell, and are not
400 interested in providing their users with access to foreign cells.
401 <P><LI>Making your file tree visible does not mean making it vulnerable.
402 You control how foreign users access your cell using the same protection
403 mechanisms that control local users' access. See <A HREF="#HDRWQ40">Granting and Denying Foreign Users Access to Your Cell</A>.
404 <P><LI>The two aspects of participation are independent. A cell can make
405 its file tree visible without allowing its users to see foreign cells'
406 file trees, or can enable its users to see other file trees without
408 <P><LI>You make your cell visible to others by advertising your database server
409 machines. See <A HREF="#HDRWQ38">Making Your Cell Visible to Others</A>.
410 <P><LI>You control access to foreign cells on a per-client machine basis.
411 In other words, it is possible to make a foreign cell accessible from one
412 client machine in your cell but not another. See <A HREF="#HDRWQ39">Making Other Cells Visible in Your Cell</A>.
414 <A NAME="IDX5662"></A>
415 <A NAME="IDX5663"></A>
416 <A NAME="IDX5664"></A>
417 <A NAME="IDX5665"></A>
418 <A NAME="IDX5666"></A>
419 <A NAME="IDX5667"></A>
420 <P><H3><A NAME="HDRWQ37" HREF="auagd002.htm#ToC_46">What the Global Namespace Looks Like</A></H3>
421 <P>The AFS global namespace appears the same to all AFS cells
422 that participate in it, because they all agree to follow a small set of
423 conventions in constructing pathnames.
424 <P>The first convention is that all AFS pathnames begin with the string
425 <B>/afs</B> to indicate that they belong to the AFS global
427 <P>The second convention is that the cell name is the second element in an AFS
428 pathname; it indicates where the file resides (that is, the cell in which
429 a file server machine houses the file). As noted, the presence of a
430 cell name in pathnames makes the global namespace possible, because it
431 guarantees that all AFS pathnames are unique even if cells use the same
432 directory names at lower levels in their AFS filespace.
433 <P>What appears at the third and lower levels in an AFS pathname depends on
434 how a cell has chosen to arrange its filespace. There are some
435 suggested conventional directories at the third level; see <A HREF="#HDRWQ43">The Third Level</A>.
436 <A NAME="IDX5668"></A>
437 <A NAME="IDX5669"></A>
438 <A NAME="IDX5670"></A>
439 <P><H3><A NAME="HDRWQ38" HREF="auagd002.htm#ToC_47">Making Your Cell Visible to Others</A></H3>
440 <P>You make your cell visible to others by advertising your cell
441 name and database server machines. Just like client machines in the
442 local cell, the Cache Manager on machines in foreign cells use the information
443 to reach your cell's Volume Location (VL) Servers when they need volume
444 and file location information. Similarly, client-side authentication
445 programs running in foreign cells use the information to contact your
446 cell's authentication service.
447 <P>There are two places you can make this information available:
449 <A NAME="IDX5671"></A>
450 <A NAME="IDX5672"></A>
451 <P><LI>In the global <B>CellServDB</B> file maintained by the AFS Product
452 Support group. This file lists the name and database server machines of
453 every cell that has agreed to make this information available to other
455 <P>To add or change your cell's listing in this file, have the official
456 support contact at your site call or write to AFS Product Support.
457 Changes to the file are frequent enough that AFS Product Support does not
458 announce each one. It is a good policy to check the file for changes on
460 <A NAME="IDX5673"></A>
461 <A NAME="IDX5674"></A>
462 <P><LI>A file called <B>CellServDB.local</B> in the
463 <B>/afs/</B><VAR>cellname</VAR><B>/service/etc</B> directory of your
464 cell's filespace. List only your cell's database server
467 <P>Update the files whenever you change the identity of your cell's
468 database server machines. Also update the copies of the
469 <B>CellServDB</B> files on all of your server machines (in the
470 <B>/usr/afs/etc</B> directory) and client machines (in the
471 <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>.
472 <P>Once you have advertised your database server machines, it can be difficult
473 to make your cell invisible again. You can remove the
474 <B>CellServDB.local</B> file and ask AFS Product Support to remove
475 your entry from the global <B>CellServDB</B> file, but other cells
476 probably have an entry for your cell in their local <B>CellServDB</B>
477 files already. To make those entries invalid, you must change the names
478 or IP addresses of your database server machines.
479 <P>Your cell does not have to be invisible to be inaccessible, however.
480 To make your cell completely inaccessible to foreign users, remove the
481 <B>system:anyuser</B> group from all ACLs at the top three levels of
482 your filespace; see <A HREF="#HDRWQ40">Granting and Denying Foreign Users Access to Your Cell</A>.
483 <A NAME="IDX5675"></A>
484 <A NAME="IDX5676"></A>
485 <A NAME="IDX5677"></A>
486 <A NAME="IDX5678"></A>
487 <P><H3><A NAME="HDRWQ39" HREF="auagd002.htm#ToC_48">Making Other Cells Visible in Your Cell</A></H3>
488 <P>To make a foreign cell's filespace visible on a client
489 machine in your cell, perform the following three steps:
491 <P><LI>Mount the cell's <B>root.cell</B> volume at the second
492 level in your cell's filespace just below the <B>/afs</B>
493 directory. Use the <B>fs mkmount</B> command with the
494 <B>-cell</B> argument as instructed in <A HREF="auagd010.htm#HDRWQ213">To create a cellular mount point</A>.
495 <P><LI>Mount AFS at the <B>/afs</B> directory on the client machine.
496 The <B>afsd</B> program, which initializes the Cache Manager, performs the
497 mount automatically at the directory named in the first field of the local
498 <B>/usr/vice/etc/cacheinfo</B> file or by the command's
499 <B>-mountdir</B> argument. Mounting AFS at an alternate location
500 makes it impossible to reach the filespace of any cell that mounts its
501 <B>root.afs</B> and <B>root.cell</B> volumes at the
502 conventional locations. See <A HREF="auagd015.htm#HDRWQ395">Displaying and Setting the Cache Size and Location</A>.
503 <P><LI>Create an entry for the cell in the list of database server machines which
504 the Cache Manager maintains in kernel memory.
505 <P>The <B>/usr/vice/etc/CellServDB</B> file on every client machine's
506 local disk lists the database server machines for the local and foreign
507 cells. The <B>afsd</B> program reads the contents of the
508 <B>CellServDB</B> file into kernel memory as it initializes the Cache
509 Manager. You can also use the <B>fs newcell</B> command to add or
510 alter entries in kernel memory directly between reboots of the machine.
511 See <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A>.
513 <P>Note that making a foreign cell visible to client machines does not
514 guarantee that your users can access its filespace. The ACLs in the
515 foreign cell must also grant them the necessary permissions.
516 <A NAME="IDX5679"></A>
517 <A NAME="IDX5680"></A>
518 <P><H3><A NAME="HDRWQ40" HREF="auagd002.htm#ToC_49">Granting and Denying Foreign Users Access to Your Cell</A></H3>
519 <P>Making your cell visible in the AFS global namespace does not
520 take away your control over the way in which users from foreign cells access
522 <P>By default, foreign users access your cell as the user
523 <B>anonymous</B>, which means they have only the permissions granted to
524 the <B>system:anyuser</B> group on each directory's ACL.
525 Normally these permissions are limited to the <B>l</B> (<B>lookup</B>)
526 and <B>r</B> (<B>read</B>) permissions.
527 <P>There are two ways to grant wider access to foreign users:
529 <P><LI>Grant additional permissions to the <B>system:anyuser</B> group
530 on certain ACLs. Keep in mind, however, that all users can then access
531 that directory in the indicated way (not just specific foreign users you have
533 <P><LI>Create a local authentication account for specific foreign users, by
534 creating entries in the Protection and Authentication Databases and local
535 password file. It is not possible to place foreign usernames on ACLs,
536 nor to authenticate in a foreign cell without having an account in it.
538 <A NAME="IDX5681"></A>
539 <A NAME="IDX5682"></A>
540 <A NAME="IDX5683"></A>
541 <HR><H2><A NAME="HDRWQ41" HREF="auagd002.htm#ToC_50">Configuring Your AFS Filespace</A></H2>
542 <P>This section summarizes the issues to consider when
543 configuring your AFS filespace. For a discussion of creating volumes
544 that correspond most efficiently to the filespace's directory structure,
545 see <A HREF="#HDRWQ44">Creating Volumes to Simplify Administration</A>.
546 <P><B>Note for Windows users:</B> Windows uses a backslash
547 ( <B>\</B> ) rather than a forward slash
548 ( <B>/</B> ) to separate the elements in a
549 pathname. The hierarchical organization of the filespace is however the
550 same as on a UNIX machine.
551 <P>AFS pathnames must follow a few conventions so the AFS global namespace
552 looks the same from any AFS client machine. There are corresponding
553 conventions to follow in building your file tree, not just because pathnames
554 reflect the structure of a file tree, but also because the AFS Cache Manager
555 expects a certain configuration.
556 <A NAME="IDX5684"></A>
557 <A NAME="IDX5685"></A>
558 <P><H3><A NAME="Header_51" HREF="auagd002.htm#ToC_51">The Top /afs Level</A></H3>
559 <P>The first convention is that the top level in your file tree be called
560 the <B>/afs</B> directory. If you name it something else, then you
561 must use the <B>-mountdir</B> argument with the <B>afsd</B> program to
562 get Cache Managers to mount AFS properly. You cannot participate in the
563 AFS global namespace in that case.
564 <A NAME="IDX5686"></A>
565 <A NAME="IDX5687"></A>
566 <A NAME="IDX5688"></A>
567 <P><H3><A NAME="HDRWQ42" HREF="auagd002.htm#ToC_52">The Second (Cellname) Level</A></H3>
568 <P>The second convention is that just below the <B>/afs</B>
569 directory you place directories corresponding to each cell whose file tree is
570 visible and accessible from the local cell. Minimally, there must be a
571 directory for the local cell. Each such directory is a mount point to
572 the indicated cell's <B>root.cell</B> volume. For
573 example, in the ABC Corporation cell, <B>/afs/abc.com</B> is a
574 mount point for the cell's own <B>root.cell</B> volume and
575 <B>stateu.edu</B> is a mount point for the State University
576 cell's <B>root.cell</B> volume. The <B>fs
577 lsmount</B> command displays the mount points.
578 <PRE> % <B>fs lsmount /afs/abc.com</B>
579 '/afs/abc.com' is a mount point for volume '#root.cell'
580 % <B>fs lsmount /afs/stateu.edu</B>
581 '/afs/stateu.edu' is a mount point for volume '#stateu.edu:root.cell'
583 <P>To reduce the amount of typing necessary in pathnames, you can create a
584 symbolic link with an abbreviated name to the mount point of each cell your
585 users frequently access (particularly the home cell). In the ABC
586 Corporation cell, for instance, <B>/afs/abc</B> is a symbolic link to the
587 <B>/afs/abc.com</B> mount point, as the <B>fs lsmount</B>
589 <PRE> % <B>fs lsmount /afs/abc</B>
590 '/afs/abc' is a symbolic link, leading to a mount point for volume '#root.cell'
592 <A NAME="IDX5689"></A>
593 <A NAME="IDX5690"></A>
594 <P><H3><A NAME="HDRWQ43" HREF="auagd002.htm#ToC_53">The Third Level</A></H3>
595 <P>You can organize the third level of your cell's file
596 tree any way you wish. The following list describes directories that
597 appear at this level in the conventional configuration:
600 </B><DD>This directory contains programs and files needed by users working on
601 machines of all system types, such as text editors, online documentation
602 files, and so on. Its <B>/etc</B> subdirectory is a logical place
603 to keep the central update sources for files used on all of your cell's
604 client machines, such as the <B>ThisCell</B> and <B>CellServDB</B>
607 </B><DD>A directory accessible to anyone who can access your filespace, because
608 its ACL grants the <B>l</B> (<B>lookup</B>) and <B>r</B>
609 (<B>read</B>) permissions to the <B>system:anyuser</B>
610 group. It is useful if you want to enable your users to make selected
611 information available to everyone, but do not want to grant foreign users
612 access to the contents of the <B>usr</B> directory which houses user home
613 directories ( and is also at this level). It is conventional to create
614 a subdirectory for each of your cell's users.
616 </B><DD>This directory contains files and subdirectories that help cells
617 coordinate resource sharing. For a list of the proposed standard files
618 and subdirectories to create, call or write to AFS Product Support.
619 <P>As an example, files that other cells expect to find in this
620 directory's <B>etc</B> subdirectory can include the following:
622 <P><LI><B>CellServDB.export</B>, a list of database server machines
624 <P><LI><B>CellServDB.local</B>, a list of the cell's own database
626 <P><LI><B>passwd</B>, a copy of the local password file
627 (<B>/etc/passwd</B> or equivalent) kept on the local disk of the
628 cell's client machines
629 <P><LI><B>group</B>, a copy of the local groups file (<B>/etc/group</B>
630 or equivalent) kept on the local disk of the cell's client machines
632 <P><DT><B><VAR>sys_type</VAR>
633 </B><DD>A separate directory for storing the server and client binaries for each
634 system type you use in the cell. Configuration is simplest if you use
635 the system type names assigned in the AFS distribution, particularly if you
636 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
637 conventional name for each supported system type.
638 <P>Within each such directory, create directories named <B>bin</B>,
639 <B>etc</B>, <B>usr</B>, and so on, to store the programs normally kept
640 in the <B>/bin</B>, <B>/etc</B> and <B>/usr</B> directories on a
641 local disk. Then create symbolic links from the local directories on
642 client machines into AFS; see <A HREF="#HDRWQ55">Configuring the Local Disk</A>. Even if you do not choose to use symbolic links in
643 this way, it can be convenient to have central copies of system binaries in
644 AFS. If binaries are accidentally removed from a machine, you can
645 recopy them onto the local disk from AFS rather than having to recover them
648 </B><DD>This directory contains home directories for your local users. As
649 discussed in the previous entry for the <B>public</B> directory, it is
650 often practical to protect this directory so that only locally authenticated
651 users can access it. This keeps the contents of your user's home
652 directories as secure as possible.
653 <P>If your cell is quite large, directory lookup can be slowed if you put all
654 home directories in a single <B>usr</B> directory. For suggestions
655 on distributing user home directories among multiple grouping directories, see
656 <A HREF="#HDRWQ59">Grouping Home Directories</A>.
658 </B><DD>This directory contains prototype, configuration and library files for use
659 with the <B>package</B> program. See <A HREF="auagd016.htm#HDRWQ419">Configuring Client Machines with the package Program</A>.
661 <A NAME="IDX5691"></A>
662 <A NAME="IDX5692"></A>
663 <A NAME="IDX5693"></A>
664 <A NAME="IDX5694"></A>
665 <HR><H2><A NAME="HDRWQ44" HREF="auagd002.htm#ToC_54">Creating Volumes to Simplify Administration</A></H2>
666 <P>This section discusses how to create volumes in ways that
667 make administering your system easier.
668 <P>At the top levels of your file tree (at least through the third level),
669 each directory generally corresponds to a separate volume. Some cells
670 also configure the subdirectories of some third level directories as separate
671 volumes. Common examples are the
672 <B>/afs/</B><VAR>cellname</VAR><B>/common</B> and
673 <B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directories.
674 <P>You do not have to create a separate volume for every directory level in a
675 tree, but the advantage is that each volume tends to be smaller and easier to
676 move for load balancing. The overhead for a mount point is no greater
677 than for a standard directory, nor does the volume structure itself require
678 much disk space. Most cells find that below the fourth level in the
679 tree, using a separate volume for each directory is no longer
680 efficient. For instance, while each user's home directory (at the
681 fourth level in the tree) corresponds to a separate volume, all of the
682 subdirectories in the home directory normally reside in the same
684 <P>Keep in mind that only one volume can be mounted at a given directory
685 location in the tree. In contrast, a volume can be mounted at several
686 locations, though this is not recommended because it distorts the hierarchical
687 nature of the file tree, potentially causing confusion.
688 <A NAME="IDX5695"></A>
689 <A NAME="IDX5696"></A>
690 <A NAME="IDX5697"></A>
691 <A NAME="IDX5698"></A>
692 <A NAME="IDX5699"></A>
693 <P><H3><A NAME="Header_55" HREF="auagd002.htm#ToC_55">Assigning Volume Names</A></H3>
694 <P>You can name your volumes anything you choose, subject to a few
697 <P><LI>Read/write volume names can be up to 22 characters in length. The
698 maximum length for volume names is 31 characters, and there must be room to
699 add the <B>.readonly</B> extension on read-only volumes.
700 <P><LI>Do not add the <B>.readonly</B> and <B>.backup</B>
701 extensions to volume names yourself, even if they are appropriate. The
702 Volume Server adds them automatically as it creates a read-only or backup
704 <P><LI>There must be volumes named <B>root.afs</B> and
705 <B>root.cell</B>, mounted respectively at the top (<B>/afs</B>)
706 level in the filespace and just below that level, at the cell's name (for
707 example, at <B>/afs/abc.com</B> in the ABC Corporation
709 <P>Deviating from these names only creates confusion and extra work.
710 Changing the name of the <B>root.afs</B> volume, for instance,
711 means that you must use the <B>-rootvol</B> argument to the
712 <B>afsd</B> program on every client machine, to name the alternate
714 <P>Similarly, changing the <B>root.cell</B> volume name prevents
715 users in foreign cells from accessing your filespace, if the mount point for
716 your cell in their filespace refers to the conventional
717 <B>root.cell</B> name. Of course, this is one way to make
718 your cell invisible to other cells.
720 <P>It is best to assign volume names that indicate the type of data they
721 contain, and to use similar names for volumes with similar contents. It
722 is also helpful if the volume name is similar to (or at least has elements in
723 common with) the name of the directory at which it is mounted.
724 Understanding the pattern then enables you accurately to guess what a volume
725 contains and where it is mounted.
726 <P>Many cells find that the most effective volume naming scheme puts a common
727 prefix on the names of all related volumes. <A HREF="#TBLVOL-PREFIX">Table 1</A> describes the recommended prefixing scheme.
729 <P><B><A NAME="TBLVOL-PREFIX" HREF="auagd004.htm#FT_TBLVOL-PREFIX">Table 1. Suggested volume prefixes</A></B><BR>
730 <TABLE WIDTH="100%" BORDER>
732 <TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="14%"><B>Prefix</B>
733 </TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="28%"><B>Contents</B>
734 </TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="22%"><B>Example Name</B>
735 </TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="36%"><B>Example Mount Point</B>
737 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>common.</B>
738 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">popular programs and files
739 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>common.etc</B>
740 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/common/etc</B>
742 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>src.</B>
743 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">source code
744 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>src.afs</B>
745 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/src/afs</B>
747 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>proj.</B>
748 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">project data
749 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>proj.portafs</B>
750 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/proj/portafs</B>
752 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>test.</B><TT></TT>
753 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">testing or other temporary data
754 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>test.smith</B>
755 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/usr/smith/test</B>
757 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><B>user.</B>
758 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">user home directory data
759 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>user.terry</B>
760 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/usr/terry</B>
762 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="14%"><VAR>sys_type</VAR><B>.</B>
763 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="28%">programs compiled for an operating system type
764 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="22%"><B>rs_aix42.bin</B>
765 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="36%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/bin</B>
767 <P><A HREF="#TBLPREFIX-EXAMPLE">Table 2</A> is a more specific example for a cell's
768 <B>rs_aix42</B> system volumes and directories:
770 <P><B><A NAME="TBLPREFIX-EXAMPLE" HREF="auagd004.htm#FT_TBLPREFIX-EXAMPLE">Table 2. Example volume-prefixing scheme</A></B><BR>
771 <TABLE WIDTH="100%" BORDER>
773 <TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="35%"><B><B>Example Name</B></B>
774 </TH><TH ALIGN="LEFT" VALIGN="BOTTOM" WIDTH="65%"><B><B>Example Mount Point</B></B>
776 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.bin</B>
777 </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>
779 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.etc</B>
780 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/etc</B>
782 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr</B>
783 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr</B>
785 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.afsws</B>
786 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/afsws</B>
788 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.lib</B>
789 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/lib</B>
791 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.bin</B>
792 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/bin</B>
794 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.etc</B>
795 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/etc</B>
797 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.inc</B>
798 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/inc</B>
800 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.man</B>
801 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/man</B>
803 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.sys</B>
804 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/sys</B>
806 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="35%"><B>rs_aix42.usr.local</B>
807 </TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="65%"><B>/afs/</B><VAR>cellname</VAR><B>/rs_aix42/usr/local</B>
809 <P>There are several advantages to this scheme:
811 <P><LI>The volume name is similar to the mount point name in the
812 filespace. In all of the entries in <A HREF="#TBLPREFIX-EXAMPLE">Table 2</A>, for example, the only difference between the
813 volume and mount point name is that the former uses periods as separators and
814 the latter uses slashes. Another advantage is that the volume name
815 indicates the contents, or at least suggests the directory on which to issue
816 the <B>ls</B> command to learn the contents.
817 <P><LI>It makes it easy to manipulate groups of related volumes at one
818 time. In particular, the <B>vos backupsys</B> command's
819 <B>-prefix</B> argument enables you to create a backup version of every
820 volume whose name starts with the same string of characters. Making a
821 backup version of each volume is one of the first steps in backing up a volume
822 with the AFS Backup System, and doing it for many volumes with one command
823 saves you a good deal of typing. For instructions for creating backup
824 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>.
825 <P><LI>It makes it easy to group related volumes together on a partition.
826 Grouping related volumes together has several advantages of its own, discussed
827 in <A HREF="#HDRWQ49">Grouping Related Volumes on a Partition</A>.
829 <A NAME="IDX5700"></A>
830 <A NAME="IDX5701"></A>
831 <P><H3><A NAME="HDRWQ49" HREF="auagd002.htm#ToC_56">Grouping Related Volumes on a Partition</A></H3>
832 <P>If your cell is large enough to make it practical, consider
833 grouping related volumes together on a partition. In general, you need
834 at least three file server machines for volume grouping to be
835 effective. Grouping has several advantages, which are most obvious when
836 the file server machine becomes inaccessible:
838 <P><LI>If you keep a hardcopy record of the volumes on a partition, you know
839 which volumes are unavailable. You can keep such a record without
840 grouping related volumes, but a list composed of unrelated volumes is much
841 harder to maintain. Note that the record must be on paper, because the
842 outage can prevent you from accessing an online copy or from issuing the
843 <B>vos listvol</B> command, which gives you the same information.
844 <P><LI>The effect of an outage is more localized. For example, if all of
845 the binaries for a given system type are on one partition, then only users of
846 that system type are affected. If a partition houses binary volumes
847 from several system types, then an outage can affect more people, particularly
848 if the binaries that remain available are interdependent with those that are
851 <P>The advantages of grouping related volumes on a partition do not
852 necessarily extend to the grouping of all related volumes on one file server
853 machine. For instance, it is probably unwise in a cell with two file
854 server machines to put all system volumes on one machine and all user volumes
855 on the other. An outage of either machine probably affects
857 <P>Admittedly, the need to move volumes for load balancing purposes can limit
858 the practicality of grouping related volumes. You need to weigh the
859 complementary advantages case by case.
860 <A NAME="IDX5702"></A>
861 <A NAME="IDX5703"></A>
862 <A NAME="IDX5704"></A>
863 <A NAME="IDX5705"></A>
864 <P><H3><A NAME="HDRWQ50" HREF="auagd002.htm#ToC_57">When to Replicate Volumes</A></H3>
865 <P>As discussed in <A HREF="auagd006.htm#HDRWQ15">Replication</A>, replication refers to making a copy, or
866 clone, of a read/write source volume and then placing the copy on one or more
867 additional file server machines. Replicating a volume can increase the
868 availability of the contents. If one file server machine housing the
869 volume becomes inaccessible, users can still access the copy of the volume
870 stored on a different machine. No one machine is likely to become
871 overburdened with requests for a popular file, either, because the file is
872 available from several machines.
873 <P>However, replication is not appropriate for all cells. If a cell
874 does not have much disk space, replication can be unduly expensive, because
875 each clone not on the same partition as the read/write source takes up as much
876 disk space as its source volume did at the time the clone was made.
877 Also, if you have only one file server machine, replication uses up disk space
878 without increasing availability.
879 <P>Replication is also not appropriate for volumes that change
880 frequently. You must issue the <B>vos release</B> command every
881 time you need to update a read-only volume to reflect changes in its
883 <P>For both of these reasons, replication is appropriate only for popular
884 volumes whose contents do not change very often, such as system binaries and
885 other volumes mounted at the upper levels of your filespace. User
886 volumes usually exist only in a read/write version since they change so
888 <P>If you are replicating any volumes, you must replicate the
889 <B>root.afs</B> and <B>root.cell</B> volumes, preferably
890 at two or three sites each (even if your cell only has two or three file
891 server machines). The Cache Manager needs to pass through the
892 directories corresponding to the <B>root.afs</B> and
893 <B>root.cell</B> volumes as it interprets any pathname. The
894 unavailability of these volumes makes all other volumes unavailable too, even
895 if the file server machines storing the other volumes are still
897 <P>Another reason to replicate the <B>root.afs</B> volume is that
898 it can lessen the load on the File Server machine. The Cache Manager
899 has a bias to access a read-only version of the <B>root.afs</B>
900 volume if it is replicate, which puts the Cache Manager onto the
901 <I>read-only path</I> through the AFS filespace. While on the
902 read-only path, the Cache Manager attempts to access a read-only copy of
903 replicated volumes. The File Server needs to track only one callback
904 per Cache Manager for all of the data in a read-only volume, rather than the
905 one callback per file it must track for read/write volumes. Fewer
906 callbacks translate into a smaller load on the File Server.
907 <P>If the <B>root.afs</B> volume is not replicated, the Cache
908 Manager follows a read/write path through the filespace, accessing the
909 read/write version of each volume. The File Server distributes and
910 tracks a separate callback for each file in a read/write volume, imposing a
912 <P>For more on read/write and read-only paths, see <A HREF="auagd010.htm#HDRWQ209">The Rules of Mount Point Traversal</A>.
913 <P>It also makes sense to replicate system binary volumes in many cases, as
914 well as the volume corresponding to the
915 <B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directory and the volumes
916 corresponding to the <B>/afs/</B><VAR>cellname</VAR><B>/common</B>
917 directory and its subdirectories.
918 <P>It is a good idea to place a replica on the same partition as the
919 read/write source. In this case, the read-only volume is a clone (like
920 a backup volume): it is a copy of the source volume's <VAR>vnode
921 index</VAR>, rather than a full copy of the volume contents. Only if the
922 read/write volume moves to another partition or changes substantially does the
923 read-only volume consume significant disk space. Read-only volumes kept
924 on other partitions always consume the full amount of disk space that the
925 read/write source consumed when the read-only volume was created.
926 <P><H3><A NAME="Header_58" HREF="auagd002.htm#ToC_58">The Default Quota and ACL on a New Volume</A></H3>
927 <P>Every AFS volume has associated with it a quota that limits the amount
928 of disk space the volume is allowed to use. To set and change quota,
929 use the commands described in <A HREF="auagd010.htm#HDRWQ234">Setting and Displaying Volume Quota and Current Size</A>.
930 <P>By default, every new volume is assigned a space quota of 5000 KB blocks
931 unless you include the <B>-maxquota</B> argument to the <B>vos
932 create</B> command. Also by default, the ACL on the root directory of
933 every new volume grants all permissions to the members of the
934 <B>system:administrators</B> group. To learn how to change
935 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
936 accounts, you can specify alternate ACL and quota values in the template
937 file's <B>V</B> instruction; see <A HREF="auagd017.htm#HDRWQ473">Creating a Volume with the V Instruction</A>.
938 <A NAME="IDX5706"></A>
939 <A NAME="IDX5707"></A>
940 <A NAME="IDX5708"></A>
941 <A NAME="IDX5709"></A>
942 <A NAME="IDX5710"></A>
943 <HR><H2><A NAME="HDRWQ51" HREF="auagd002.htm#ToC_59">Configuring Server Machines</A></H2>
944 <P>This section discusses some issues to consider when
945 configuring server machines, which store AFS data, transfer it to client
946 machines on request, and house the AFS administrative databases. To
947 learn about client machines, see <A HREF="#HDRWQ54">Configuring Client Machines</A>.
948 <P>If your cell has more than one AFS server machine, you can configure them
949 to perform specialized functions. A machine can assume one or more of
950 the roles described in the following list. For more details, see <A HREF="auagd008.htm#HDRWQ90">The Four Roles for File Server Machines</A>.
952 <P><LI>A <I>simple file server machine</I> runs only the processes that store
953 and deliver AFS files to client machines. You can run as many simple
954 file server machines as you need to satisfy your cell's performance and
955 disk space requirements.
956 <P><LI>A <I>database server machine</I> runs the four database server
957 processes that maintain AFS's replicated administrative databases:
958 the Authentication, Backup, Protection, and Volume Location (VL) Server
960 <P><LI>A <I>binary distribution machine</I> distributes the AFS server
961 binaries for its system type to all other server machines of that system
963 <P><LI>The single <I>system control machine</I> distributes common server
964 configuration files to all other server machines in the cell, in a cell that
965 runs the United States edition of AFS (cells that use the international
966 edition of AFS must not use the system control machine for this
967 purpose). The machine conventionally also serves as the time
968 synchronization source for the cell, adjusting its clock according to a time
969 source outside the cell.
971 <P>The <I>IBM AFS Quick Beginnings</I> explains how to configure your
972 cell's first file server machine to assume all four roles. The
973 <I>IBM AFS Quick Beginnings</I> chapter on installing additional server
974 machines also explains how to configure them to perform one or more
976 <A NAME="IDX5711"></A>
977 <A NAME="IDX5712"></A>
978 <A NAME="IDX5713"></A>
979 <A NAME="IDX5714"></A>
980 <P><H3><A NAME="HDRWQ52" HREF="auagd002.htm#ToC_60">Replicating the AFS Administrative Databases</A></H3>
981 <P>The AFS administrative databases are housed on database
982 server machines and store information that is crucial for correct cell
983 functioning. Both server processes and Cache Managers access the
984 information frequently:
986 <P><LI>Every time a Cache Manager fetches a file from a directory that it has not
987 previously accessed, it must look up the file's location in the Volume
988 Location Database (VLDB).
989 <P><LI>Every time a user obtains an AFS token from the Authentication Server, the
990 server looks up the user's password in the Authentication
992 <P><LI>The first time that a user accesses a volume housed on a specific file
993 server machine, the File Server contacts the Protection Server for a list of
994 the user's group memberships as recorded in the Protection
996 <P><LI>Every time you back up a volume using the AFS Backup System, the Backup
997 Server creates records for it in the Backup Database.
999 <P>Maintaining your cell is simplest if the first machine has the lowest IP
1000 address of any machine you plan to use as a database server machine. If
1001 you later decide to use a machine with a lower IP address as a database server
1002 machine, you must update the <B>CellServDB</B> file on all clients before
1003 introducing the new machine.
1004 <P>If your cell has more than one server machine, it is best to run more than
1005 one as a database server machine (but more than three are rarely
1006 necessary). Replicating the administrative databases in this way yields
1007 the same benefits as replicating volumes: increased availability and
1008 reliability. If one database server machine or process stops
1009 functioning, the information in the database is still available from
1010 others. The load of requests for database information is spread across
1011 multiple machines, preventing any one from becoming overloaded.
1012 <P>Unlike replicated volumes, however, replicated databases do change
1013 frequently. Consistent system performance demands that all copies of
1014 the database always be identical, so it is not acceptable to record changes in
1015 only some of them. To synchronize the copies of a database, the
1016 database server processes use AFS's distributed database technology,
1017 Ubik. See <A HREF="auagd008.htm#HDRWQ102">Replicating the AFS Administrative Databases</A>.
1018 <P>If your cell has only one file server machine, it must also serve as a
1019 database server machine. If you cell has two file server machines, it
1020 is not always advantageous to run both as database server machines. If
1021 a server, process, or network failure interrupts communications between the
1022 database server processes on the two machines, it can become impossible to
1023 update the information in the database because neither of them can alone elect
1024 itself as the synchronization site.
1025 <A NAME="IDX5715"></A>
1026 <A NAME="IDX5716"></A>
1027 <P><H3><A NAME="HDRWQ53" HREF="auagd002.htm#ToC_61">AFS Files on the Local Disk</A></H3>
1028 <P>It is generally simplest to store the binaries for all AFS
1029 server processes in the <B>/usr/afs/bin</B> directory on every file server
1030 machine, even if some processes do not actively run on the machine.
1031 This makes it easier to reconfigure a machine to fill a new role.
1032 <P>For security reasons, the <B>/usr/afs</B> directory on a file server
1033 machine and all of its subdirectories and files must be owned by the local
1034 superuser <B>root</B> and have only the first <B>w</B>
1035 (<B>write</B>) mode bit turned on. Some files even have only the
1036 first <B>r</B> (<B>read</B>) mode bit turned on (for example, the
1037 <B>/usr/afs/etc/KeyFile</B> file, which lists the AFS server encryption
1038 keys). Each time the BOS Server starts, it checks that the mode bits on
1039 certain files and directories match the expected values. For a list,
1040 see the <I>IBM AFS Quick Beginnings</I> section about protecting sensitive
1041 AFS directories, or the discussion of the output from the <B>bos
1042 status</B> command in <A HREF="auagd009.htm#HDRWQ159">To display the status of server processes and their BosConfig entries</A>.
1043 <P>For a description of the contents of all AFS directories on a file server
1044 machine's local disk, see <A HREF="auagd008.htm#HDRWQ80">Administering Server Machines</A>.
1045 <P><H3><A NAME="Header_62" HREF="auagd002.htm#ToC_62">Configuring Partitions to Store AFS Data</A></H3>
1046 <P>The partitions that house AFS volumes on a file server machine must be
1047 mounted at directories named
1048 <P><B>/vicep<VAR>index</VAR></B>
1049 <P>where <VAR>index</VAR> is one or two lowercase letters. By convention,
1050 the first AFS partition created is mounted at the <B>/vicepa</B>
1051 directory, the second at the <B>/vicepb</B> directory, and so on through
1052 the <B>/vicepz</B> directory. The names then continue with
1053 <B>/vicepaa</B> through <B>/vicepaz</B>, <B>/vicepba</B> through
1054 <B>/vicepbz</B>, and so on, up to the maximum supported number of server
1055 partitions, which is specified in the <I>IBM AFS Release Notes</I>.
1056 <P>Each <B>/vicep</B><VAR>x</VAR> directory must correspond to an entire
1057 partition or logical volume, and must be a subdirectory of the root directory
1058 ( / ). It is not acceptable to configure part of (for example) the
1059 <B>/usr</B> partition as an AFS server partition and mount it on a
1060 directory called <B>/usr/vicepa</B>.
1061 <P>Also, do not store non-AFS files on AFS server partitions. The File
1062 Server and Volume Server expect to have available all of the space on the
1063 partition. Sharing space also creates competition between AFS and the
1064 local UNIX file system for access to the partition, particularly if the UNIX
1065 files are frequently used.
1066 <A NAME="IDX5717"></A>
1067 <A NAME="IDX5718"></A>
1068 <A NAME="IDX5719"></A>
1069 <A NAME="IDX5720"></A>
1070 <A NAME="IDX5721"></A>
1071 <P><H3><A NAME="Header_63" HREF="auagd002.htm#ToC_63">Monitoring, Rebooting and Automatic Process Restarts</A></H3>
1072 <P>AFS provides several tools for monitoring the File Server, including
1073 the <B>scout</B> and <B>afsmonitor</B> programs. You can
1074 configure them to alert you when certain threshold values are exceeded, for
1075 example when a server partition is more than 95% full. See <A HREF="auagd013.htm#HDRWQ323">Monitoring and Auditing AFS Performance</A>.
1076 <P>Rebooting a file server machine requires shutting down the AFS processes
1077 and so inevitably causes a service outage. Reboot file server machines
1078 as infrequently as possible. For instructions, see <A HREF="auagd008.htm#HDRWQ139">Rebooting a Server Machine</A>.
1079 <P>By default, the BOS Server on each file server machine stops and
1080 immediately restarts all AFS server processes on the machine (including
1081 itself) once a week, at 4:00 a.m. on Sunday. This
1082 reduces the potential for the core leaks that can develop as any process runs
1083 for an extended time.
1084 <P>The BOS Server also checks each morning at 5:00 a.m.
1085 for any newly installed binary files in the <B>/usr/afs/bin</B>
1086 directory. It compares the timestamp on each binary file to the time at
1087 which the corresponding process last restarted. If the timestamp on the
1088 binary is later, the BOS Server restarts the corresponding process to start
1090 <P>The default times are in the early morning hours when the outage that
1091 results from restarting a process is likely to disturb the fewest number of
1092 people. You can display the restart times for each machine with the
1093 <B>bos getrestart</B> command, and set them with the <B>bos
1094 setrestart</B> command. The latter command enables you to disable
1095 automatic restarts entirely, by setting the time to <B>never</B>.
1096 See <A HREF="auagd009.htm#HDRWQ171">Setting the BOS Server's Restart Times</A>.
1097 <A NAME="IDX5722"></A>
1098 <A NAME="IDX5723"></A>
1099 <HR><H2><A NAME="HDRWQ54" HREF="auagd002.htm#ToC_64">Configuring Client Machines</A></H2>
1100 <P>This section summarizes issues to consider as you install and
1101 configure client machines in your cell.
1102 <A NAME="IDX5724"></A>
1103 <A NAME="IDX5725"></A>
1104 <A NAME="IDX5726"></A>
1105 <P><H3><A NAME="HDRWQ55" HREF="auagd002.htm#ToC_65">Configuring the Local Disk</A></H3>
1106 <P>You can often free up significant amounts of local disk space
1107 on AFS client machines by storing standard UNIX files in AFS and creating
1108 symbolic links to them from the local disk. The <B>@sys</B>
1109 pathname variable can be useful in links to system-specific files; see <A HREF="#HDRWQ56">Using the @sys Variable in Pathnames</A>.
1110 <P>There are two types of files that must actually reside on the local
1111 disk: boot sequence files needed before the <B>afsd</B> program is
1112 invoked, and files that can be helpful during file server machine
1114 <P>During a reboot, AFS is inaccessible until the <B>afsd</B> program
1115 executes and initializes the Cache Manager. (In the conventional
1116 configuration, the AFS initialization file is included in the machine's
1117 initialization sequence and invokes the <B>afsd</B> program.) Files
1118 needed during reboot prior to that point must reside on the local disk.
1119 They include the following, but this list is not necessarily
1122 <P><LI>Standard UNIX utilities including the following or their
1125 <P><LI>Machine initialization files (stored in the <B>/etc</B> or
1126 <B>/sbin</B> directory on many system types)
1127 <P><LI>The <B>fstab</B> file
1128 <P><LI>The <B>mount</B> command binary
1129 <P><LI>The <B>umount</B> command binary
1131 <P><LI>All subdirectories and files in the <B>/usr/vice</B> directory,
1132 including the following:
1134 <P><LI>The <B>/usr/vice/cache</B> directory
1135 <P><LI>The <B>/usr/vice/etc/afsd</B> command binary
1136 <P><LI>The <B>/usr/vice/etc/cacheinfo</B> file
1137 <P><LI>The <B>/usr/vice/etc/CellServDB</B> file
1138 <P><LI>The <B>/usr/vice/etc/ThisCell</B> file
1140 <P>For more information on these files, see <A HREF="auagd015.htm#HDRWQ391">Configuration and Cache-Related Files on the Local Disk</A>.
1142 <P>The other type of files and programs to retain on the local disk are those
1143 you need when diagnosing and fixing problems caused by a file server outage,
1144 because the outage can make inaccessible the copies stored in AFS.
1145 Examples include the binaries for a text editor (such as <B>ed</B> or
1146 <B>vi</B>) and for the <B>fs</B> and <B>bos</B> commands.
1147 Store copies of AFS command binaries in the <B>/usr/vice/etc</B> directory
1148 as well as including them in the <B>/usr/afsws</B> directory, which is
1149 normally a link into AFS. Then place the <B>/usr/afsws</B>
1150 directory before the <B>/usr/vice/etc</B> directory in users'
1151 <TT>PATH</TT> environment variable definition. When AFS is
1152 functioning normally, users access the copy in the <B>/usr/afsws</B>
1153 directory, which is more likely to be current than a local copy.
1154 <P>You can automate the configuration of client machine local disks by using
1155 the <B>package</B> program, which updates the contents of the local disk
1156 to match a configuration file. See <A HREF="auagd016.htm#HDRWQ419">Configuring Client Machines with the package Program</A>.
1157 <A NAME="IDX5727"></A>
1158 <P><H3><A NAME="Header_66" HREF="auagd002.htm#ToC_66">Enabling Access to Foreign Cells</A></H3>
1159 <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
1160 AFS filespace by storing a list of the cell's database server machines in
1161 the local <B>/usr/vice/etc/CellServDB</B> file. The Cache Manager
1162 reads the list into kernel memory at reboot for faster retrieval. You
1163 can change the list in kernel memory between reboots by using the <B>fs
1164 newcell</B> command. It is often practical to store a central version
1165 of the <B>CellServDB</B> file in AFS and use the <B>package</B>
1166 program periodically to update each client's version with the source
1167 copy. See <A HREF="auagd015.htm#HDRWQ406">Maintaining Knowledge of Database Server Machines</A>.
1168 <P>Because each client machine maintains its own copy of the
1169 <B>CellServDB</B> file, you can in theory enable access to different
1170 foreign cells on different client machines. This is not usually
1171 practical, however, especially if users do not always work on the same
1173 <A NAME="IDX5728"></A>
1174 <A NAME="IDX5729"></A>
1175 <A NAME="IDX5730"></A>
1176 <P><H3><A NAME="HDRWQ56" HREF="auagd002.htm#ToC_67">Using the @sys Variable in Pathnames</A></H3>
1177 <P>When creating symbolic links into AFS on the local disk, it
1178 is often practical to use the <VAR>@sys</VAR> variable in pathnames. The
1179 Cache Manager automatically substitutes the local machine's AFS system
1180 name (CPU/operating system type) for the <VAR>@sys</VAR> variable. This
1181 means you can place the same links on machines of various system types and
1182 still have each machine access the binaries for its system type. For
1183 example, the Cache Manager on a machine running AIX 4.2 converts
1184 <B>/afs/abc.com/@sys</B> to
1185 <B>/afs/abc.com/rs_aix42</B>, whereas a machine running Solaris 7
1186 converts it to <B>/afs/abc.com/sun4x_57</B>.
1187 <P>If you want to use the <VAR>@sys</VAR> variable, it is simplest to use the
1188 conventional AFS system type names as specified in the <I>IBM AFS Release
1189 Notes</I>. The Cache Manager records the local machine's system
1190 type name in kernel memory during initialization. If you do not use the
1191 conventional names, you must use the <B>fs sysname</B> command to change
1192 the value in kernel memory from its default just after Cache Manager
1193 initialization, on every client machine of the relevant system type.
1194 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>.
1195 <P>In pathnames in the AFS filespace itself, use the <VAR>@sys</VAR> variable
1196 carefully and sparingly, because it can lead to unexpected results. It
1197 is generally best to restrict its use to only one level in the
1198 filespace. The third level is a common choice, because that is where
1199 many cells store the binaries for different machine types.
1200 <P>Multiple instances of the <VAR>@sys</VAR> variable in a pathname are
1201 especially dangerous to people who must explicitly change directories (with
1202 the <B>cd</B> command, for example) into directories that store binaries
1203 for system types other than the machine on which they are working, such as
1204 administrators or developers who maintain those directories. After
1205 changing directories, it is recommended that such people verify they are in
1206 the desired directory.
1207 <P><H3><A NAME="Header_68" HREF="auagd002.htm#ToC_68">Setting Server Preferences</A></H3>
1208 <P>The Cache Manager stores a table of preferences for file server
1209 machines in kernel memory. A preference rank pairs a file server
1210 machine interface's IP address with an integer in the range from 1 to
1211 65,534. When it needs to access a file, the Cache Manager compares the
1212 ranks for the interfaces of all machines that house the file, and first
1213 attempts to access the file via the interface with the best rank. As it
1214 initializes, the Cache Manager sets default ranks that bias it to access files
1215 via interfaces that are close to it in terms of network topology. You
1216 can adjust the preference ranks to improve performance if you wish.
1217 <P>The Cache Manager also uses similar preferences for Volume Location (VL)
1218 Server machines. Use the <B>fs getserverprefs</B> command to
1219 display preference ranks and the <B>fs setserverprefs</B> command to set
1220 them. See <A HREF="auagd015.htm#HDRWQ414">Maintaining Server Preference Ranks</A>.
1221 <A NAME="IDX5731"></A>
1222 <HR><H2><A NAME="HDRWQ57" HREF="auagd002.htm#ToC_69">Configuring AFS User Accounts</A></H2>
1223 <P>This section discusses some of the issues to consider when
1224 configuring AFS user accounts. Because AFS is separate from the UNIX
1225 file system, a user's AFS account is separate from her UNIX
1227 <P>The preferred method for creating a user account is with the <B>uss</B>
1228 suite of commands. With a single command, you can create all the
1229 components of one or many accounts, after you have prepared a template file
1230 that guides the account creation. See <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A>.
1231 <P>Alternatively, you can issue the individual commands that create each
1232 component of an account. For instructions, along with instructions for
1233 removing user accounts and changing user passwords, user volume quotas and
1234 usernames, see <A HREF="auagd018.htm#HDRWQ491">Administering User Accounts</A>.
1235 <P>When users leave your system, it is often good policy to remove their
1236 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>.
1237 <P>An AFS user account consists of the following components, which are
1238 described in greater detail in <A HREF="auagd018.htm#HDRWQ494">The Components of an AFS User Account</A>.
1240 <P><LI>A Protection Database entry
1241 <P><LI>An Authentication Database entry
1243 <P><LI>A home directory at which the volume is mounted
1244 <P><LI>Ownership of the home directory and full permissions on its ACL
1245 <P><LI>An entry in the local password file (<B>/etc/passwd</B> or equivalent)
1246 of each machine the user needs to log into
1247 <P><LI>Optionally, standard files and subdirectories that make the account more
1250 <P>By creating some components but not others, you can create accounts at
1251 different levels of functionality, using either <B>uss</B> commands as
1252 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
1255 <P><LI>An <I>authentication-only account</I> enables the user to obtain AFS
1256 tokens and so to access protected AFS data and to issue privileged
1257 commands. It consists only of entries in the Authentication and
1258 Protection Database. This type of account is suitable for
1259 administrative accounts and for users from foreign cells who need to access
1260 protected data. Local users generally also need a volume and home
1262 <P><LI>A <I>basic user account</I> includes a volume for the user, in
1263 addition to Authentication and Protection Database entries. The volume
1264 is mounted in the AFS filespace as the user's home directory, and
1265 provides a repository for the user's personal files.
1266 <P><LI>A <I>full account</I> adds configuration files for basic functions
1267 such as logging in, printing, and mail delivery to a basic account, making it
1268 more convenient and useful. For a discussion of some useful types of
1269 configuration files, see <A HREF="#HDRWQ60">Creating Standard Files in New AFS Accounts</A>.
1271 <P>If your users have UNIX user accounts that predate the introduction of AFS
1272 in the cell, you possibly want to convert them into AFS accounts. There
1273 are three main issues to consider:
1275 <P><LI>Making UNIX and AFS UIDs match
1276 <P><LI>Setting the password field in the local password file appropriately
1277 <P><LI>Moving files from the UNIX file system into AFS
1279 <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>.
1280 <A NAME="IDX5732"></A>
1281 <A NAME="IDX5733"></A>
1282 <A NAME="IDX5734"></A>
1283 <A NAME="IDX5735"></A>
1284 <A NAME="IDX5736"></A>
1285 <P><H3><A NAME="HDRWQ58" HREF="auagd002.htm#ToC_70">Choosing Usernames and Naming Other Account Components</A></H3>
1286 <P>This section suggests schemes for choosing usernames, AFS
1287 UIDs, user volume names and mount point names, and also outlines some
1288 restrictions on your choices.
1290 <P>AFS imposes very few restrictions on the form of usernames. It is
1291 best to keep usernames short, both because many utilities and applications can
1292 handle usernames of no more than eight characters and because by convention
1293 many components of and AFS account incorporate the name. These include
1294 the entries in the Protection and Authentication Databases, the volume, and
1295 the mount point. Depending on your electronic mail delivery system, the
1296 username can become part of the user's mailing address. The
1297 username is also the string that the user types when logging in to a client
1299 <P>Some common choices for usernames are last names, first names, initials, or
1300 a combination, with numbers sometimes added. It is also best to avoid
1301 using the following characters, many of which have special meanings to the
1304 <P><LI>The comma ( <B>,</B> )
1305 <P><LI>The colon ( <B>:</B> ), because AFS reserves it as a field
1306 separator in protection group names; see <A HREF="#HDRWQ62">The Two Types of User-Defined Groups</A>
1307 <P><LI>The semicolon ( <B>;</B> )
1308 <P><LI>The "at-sign" ( <B>@</B> ); this character is reserved for
1309 Internet mailing addresses
1311 <P><LI>The newline character
1312 <P><LI>The period ( <B>.</B> ); it is conventional to use this
1313 character only in the special username that an administrator adopts while
1314 performing privileged tasks, such as <B>pat.admin</B>
1316 <P><B>AFS UIDs and UNIX UIDs</B>
1317 <P>AFS associates a unique identification number, the <I>AFS UID</I>, with
1318 every username, recording the mapping in the user's Protection Database
1319 entry. The AFS UID functions within AFS much as the UNIX UID does in
1320 the local file system: the AFS server processes and the Cache Manager
1321 use it internally to identify a user, rather than the username.
1322 <P>Every AFS user also must have a UNIX UID recorded in the local password
1323 file (<B>/etc/passwd</B> or equivalent) of each client machine they log
1324 onto. Both administration and a user's AFS access are simplest if
1325 the AFS UID and UNIX UID match. One important consequence of matching
1326 UIDs is that the owner reported by the <B>ls -l</B> command matches the
1328 <P>It is usually best to allow the Protection Server to allocate the AFS UID
1329 as it creates the Protection Database entry. However, both the <B>pts
1330 createuser</B> command and the <B>uss</B> commands that create user
1331 accounts enable you to assign AFS UIDs explicitly. This is appropriate
1334 <P><LI>You wish to group together the AFS UIDs of related users
1335 <P><LI>You are converting an existing UNIX account into an AFS account and want
1336 to make the AFS UID match the existing UNIX UID
1338 <P>After the Protection Server initializes for the first time on a cell's
1339 first file server machine, it starts assigning AFS UIDs at a default
1340 value. To change the default before creating any user accounts, or at
1341 any time, use the <B>pts setmax</B> command to reset the <TT>max user
1342 id</TT> counter. To display the counter, use the <B>pts
1343 listmax</B> command. See <A HREF="auagd019.htm#HDRWQ560">Displaying and Setting the AFS UID and GID Counters</A>.
1344 <P>AFS reserves one AFS UID, 32766, for the user <B>anonymous</B>.
1345 The AFS server processes assign this identity and AFS UID to any user who does
1346 not possess a token for the local cell. Do not assign this AFS UID to
1347 any other user or hardcode its current value into any programs or a
1348 file's owner field, because it is subject to change in future
1350 <A NAME="IDX5737"></A>
1351 <A NAME="IDX5738"></A>
1352 <P><B>User Volume Names</B>
1353 <P>Like any volume name, a user volume's base (read/write) name cannot
1354 exceed 22 characters in length or include the <B>.readonly</B> or
1355 <B>.backup</B> extension. See <A HREF="#HDRWQ44">Creating Volumes to Simplify Administration</A>. By convention, user volume names have the format
1356 <B>user.</B><VAR>username</VAR>. Using the
1357 <B>user.</B> prefix not only makes it easy to identify the
1358 volume's contents, but also to create a backup version of all user
1359 volumes by issuing a single <B>vos backupsys</B> command.
1360 <A NAME="IDX5739"></A>
1361 <A NAME="IDX5740"></A>
1362 <P><B>Mount Point Names</B>
1363 <P>By convention, the mount point for a user's volume is named after the
1364 username. Many cells follow the convention of mounting user volumes in
1365 the <B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directory, as discussed
1366 in <A HREF="#HDRWQ43">The Third Level</A>. Very large cells sometimes find that mounting all
1367 user volumes in the same directory slows directory lookup, however; for
1368 suggested alternatives, see the following section.
1369 <A NAME="IDX5741"></A>
1370 <A NAME="IDX5742"></A>
1371 <P><H3><A NAME="HDRWQ59" HREF="auagd002.htm#ToC_71">Grouping Home Directories</A></H3>
1372 <P>Mounting user volumes in the
1373 <B>/afs/</B><VAR>cellname</VAR><B>/usr</B> directory is an
1374 AFS-appropriate variation on the standard UNIX practice of putting user home
1375 directories under the <B>/usr</B> subdirectory. However, cells with
1376 more than a few hundred users sometimes find that mounting all user volumes in
1377 a single directory results in slow directory lookup. The solution is to
1378 distribute user volume mount points into several directories; there are a
1379 number of alternative methods to accomplish this.
1381 <P><LI>Distribute user home directories into multiple directories that reflect
1382 organizational divisions, such as academic or corporate departments.
1383 For example, a company can create group directories called
1384 <B>usr/marketing</B>, <B>usr/research</B>,
1385 <B>usr/finance</B>. A good feature of this scheme is that knowing a
1386 user's department is enough to find the user's home
1387 directory. Also, it makes it easy to set the ACL to limit access to
1388 members of the department only. A potential drawback arises if
1389 departments are of sufficiently unequal size that users in large departments
1390 experience slower lookup than users in small departments. This scheme
1391 is also not appropriate in cells where users frequently change between
1393 <P><LI>Distribute home directories into alphabetic subdirectories of the
1394 <B>usr</B> directory (the <B>usr/a</B> subdirectory, the
1395 <B>usr/b</B> subdirectory, and so on), based on the first letter of the
1396 username. If the cell is very large, create subdirectories under each
1397 letter that correspond to the second letter in the user name. This
1398 scheme has the same advantages and disadvantages of a department-based
1399 scheme. Anyone who knows the user's username can find the
1400 user's home directory, but users with names that begin with popular
1401 letters sometimes experience slower lookup.
1402 <P><LI>Distribute home directories randomly but evenly into more than one
1403 grouping directory. One cell that uses this scheme has over twenty such
1404 directories called the <B>usr1</B> directory, the <B>usr2</B>
1405 directory, and so on. This scheme is especially appropriate in cells
1406 where the other two schemes do not seem feasible. It eliminates the
1407 potential problem of differences in lookup speed, because all directories are
1408 about the same size. Its disadvantage is that there is no way to guess
1409 which directory a given user's volume is mounted in, but a solution is to
1410 create a symbolic link in the regular <B>usr</B> directory that references
1411 the actual mount point. For example, if user <B>smith</B>'s
1412 volume is mounted at the <B>/afs/bigcell.com/usr17/smith</B>
1413 directory, then the <B>/afs/bigcell.com/usr/smith</B> directory is
1414 a symbolic link to the <B>../usr17/smith</B>
1415 directory. This way, if someone does not know which directory the user
1416 <B>smith</B> is in, he or she can access it through the link called
1417 <B>usr/smith</B>; people who do know the appropriate directory save
1418 lookup time by specifying it.
1420 <P>For instructions on how to implement the various schemes when using the
1421 <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>.
1422 <P><H3><A NAME="Header_72" HREF="auagd002.htm#ToC_72">Making a Backup Version of User Volumes Available</A></H3>
1423 <P>Mounting the backup version of a user's volume is a simple way to
1424 enable users themselves to restore data they have accidentally removed or
1425 deleted. It is conventional to mount the backup version at a
1426 subdirectory of the user's home directory (called perhaps the
1427 <B>OldFiles</B> subdirectory), but other schemes are possible. Once
1428 per day you create a new backup version to capture the changes made that day,
1429 overwriting the previous day's backup version with the new one.
1430 Users can always retrieve the previous day's copy of a file without your
1431 assistance, freeing you to deal with more pressing tasks.
1432 <P>Users sometimes want to delete the mount point to their backup volume,
1433 because they erroneously believe that the backup volume's contents count
1434 against their quota. Remind them that the backup volume is separate, so
1435 the only space it uses in the user volume is the amount needed for the mount
1437 <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>.
1438 <A NAME="IDX5743"></A>
1439 <A NAME="IDX5744"></A>
1440 <A NAME="IDX5745"></A>
1441 <P><H3><A NAME="HDRWQ60" HREF="auagd002.htm#ToC_73">Creating Standard Files in New AFS Accounts</A></H3>
1442 <P>From your experience as a UNIX administrator, you are
1443 probably familiar with the use of login and shell initialization files (such
1444 as the <B>.login</B> and <B>.cshrc</B> files) to make an
1445 account easier to use.
1446 <P>It is often practical to add some AFS-specific directories to the
1447 definition of the user's <TT>PATH</TT> environment variable, including
1450 <P><LI>The path to a <B>bin</B> subdirectory in the user's home
1451 directory for binaries the user has created (that is,
1452 <B>/afs/<VAR>cellname</VAR><B>/usr/</B>
1453 <VAR>username</VAR><B>/bin</B>)</B>
1454 <P><LI>The <B>/usr/afsws/bin</B> path, which conventionally includes programs
1455 like <B>fs</B>, <B>klog</B>, <B>kpasswd</B>, <B>pts</B>,
1456 <B>tokens</B>, and <B>unlog</B>
1457 <P><LI>The <B>/usr/afsws/etc</B> path, if the user is an administrator;
1458 it usually houses the AFS command suites that require privilege (the
1459 <B>backup</B>, <B>butc</B>, <B>kas</B>, <B>uss</B>,
1460 <B>vos</B> commands), the <B>package</B> program, and others
1462 <P>If you are not using an AFS-modified login utility, it can be helpful to
1463 users to invoke the <B>klog</B> command in their <B>.login</B>
1464 file so that they obtain AFS tokens as part of logging in. In the
1465 following example command sequence, the first line echoes the string
1466 <TT>klog</TT> to the standard output stream, so that the user understands
1467 the purpose of the <TT>Password:</TT> prompt that appears when the
1468 second line is executed. The <B>-setpag</B> flag associates the new
1469 tokens with a process authentication group (PAG), which is discussed further
1470 in <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
1471 <PRE> echo -n "klog "
1474 <P>The following sequence of commands has a similar effect, except that the
1475 <B>pagsh</B> command forks a new shell with which the PAG and tokens are
1481 <P>If you use an AFS-modified login utility, this sequence is not necessary,
1482 because such utilities both log a user in locally and obtain AFS
1484 <A NAME="IDX5746"></A>
1485 <A NAME="IDX5747"></A>
1486 <A NAME="IDX5748"></A>
1487 <A NAME="IDX5749"></A>
1488 <HR><H2><A NAME="HDRWQ61" HREF="auagd002.htm#ToC_74">Using AFS Protection Groups</A></H2>
1489 <P>AFS enables users to define their own <I>groups</I> of
1490 other users or machines. The groups are placed on ACLs to grant the
1491 same permissions to many users without listing each user individually.
1492 For group creation instructions, see <A HREF="auagd019.htm#HDRWQ531">Administering the Protection Database</A>.
1493 <P>Groups have AFS ID numbers, just as users do, but an AFS group ID (GID) is
1494 a negative integer whereas a user's AFS UID is a positive integer.
1495 By default, the Protection Server allocates a new group's AFS GID
1496 automatically, but members of the <B>system:administrators</B> group
1497 can assign a GID when issuing the <B>pts creategroup</B> command.
1498 Before explicitly assigning a GID, it is best to verify that it is not already
1500 <P>A group cannot belong to another group, but it can own another group or
1501 even itself as long as it (the owning group) has at least one member.
1502 The current owner of a group can transfer ownership of the group to another
1503 user or group, even without the new owner's permission. At that
1504 point the former owner loses administrative control over the group.
1505 <P>By default, each user can create 20 groups. A system administrator
1506 can increase or decrease this group creation quota with the <B>pts
1507 setfields</B> command.
1508 <P>Each Protection Database entry (group or user) is protected by a set of
1509 five <I>privacy flags</I>which limit who can administer the entry and what
1510 they can do. The default privacy flags are fairly restrictive,
1511 especially for user entries. See <A HREF="auagd019.htm#HDRWQ559">Setting the Privacy Flags on Database Entries</A>.
1512 <A NAME="IDX5750"></A>
1513 <A NAME="IDX5751"></A>
1514 <A NAME="IDX5752"></A>
1515 <A NAME="IDX5753"></A>
1516 <P><H3><A NAME="Header_75" HREF="auagd002.htm#ToC_75">The Three System Groups</A></H3>
1517 <P>As the Protection Server initializes for the first time on a
1518 cell's first database server machine, it automatically creates three
1519 group entries: the <B>system:anyuser</B>,
1520 <B>system:authuser</B>, and <B>system:administrators</B>
1522 <A NAME="IDX5754"></A>
1523 <P>The first two system groups are unlike any other groups in the Protection
1524 Database in that they do not have a stable membership:
1526 <P><LI>The <B>system:anyuser</B> group includes everyone who can access
1527 a cell's AFS filespace: users who have tokens for the local cell,
1528 users who have logged in on a local AFS client machine but not obtained tokens
1529 (such as the local superuser <B>root</B>), and users who have connected to
1530 a local machine from outside the cell. Placing the
1531 <B>system:anyuser</B> group on an ACL grants access to the widest
1532 possible range of users. It is the only way to extend access to users
1533 from foreign AFS cells that do not have local accounts.
1534 <P><LI>The <B>system:authuser</B> group includes everyone who has a
1535 valid token obtained from the cell's AFS authentication service.
1537 <P>Because the groups do not have a stable membership, the <B>pts
1538 membership</B> command produces no output for them. Similarly, they
1539 do not appear in the list of groups to which a user belongs.
1540 <P>The <B>system:administrators</B> group does have a stable
1541 membership, consisting of the cell's privileged administrators.
1542 Members of this group can issue any <B>pts</B> command, and are the only
1543 ones who can issue several other restricted commands (such as the
1544 <B>chown</B> command on AFS files). By default, they also
1545 implicitly have the <B>a</B> (<B>administer</B>) and <B>l</B>
1546 (<B>lookup</B>) permissions on every ACL in the filespace. For
1547 information about changing this default, see <A HREF="auagd021.htm#HDRWQ586">Administering the system:administrators Group</A>.
1548 <P>For a discussion of how to use system groups effectively on ACLs, see <A HREF="auagd020.htm#HDRWQ571">Using Groups on ACLs</A>.
1549 <P><H3><A NAME="HDRWQ62" HREF="auagd002.htm#ToC_76">The Two Types of User-Defined Groups</A></H3>
1550 <P>All users can create <I>regular</I> groups. A
1551 regular group name has two fields separated by a colon, the first of which
1552 must indicate the group's ownership. The Protection Server refuses
1553 to create or change the name of a group if the result does not accurately
1554 indicate the ownership.
1555 <P>Members of the <B>system:administrators</B> group can create
1556 <I>prefix-less</I> groups whose names do not have the first field that
1557 indicates ownership. For suggestions on using the two types of groups
1558 effectively, see <A HREF="auagd019.htm#HDRWQ545">Using Groups Effectively</A>.
1559 <A NAME="IDX5755"></A>
1560 <A NAME="IDX5756"></A>
1561 <HR><H2><A NAME="HDRWQ63" HREF="auagd002.htm#ToC_77">Login and Authentication in AFS</A></H2>
1562 <P>As explained in <A HREF="#HDRWQ31">Differences in Authentication</A>, AFS authentication is separate from UNIX
1563 authentication because the two file systems are separate. The
1564 separation has two practical implications:
1566 <P><LI>To access AFS files, users must both log into the local file system and
1567 authenticate with the AFS authentication service. (Logging into the
1568 local file system is necessary because the only way to access the AFS
1569 filespace is through a Cache Manager, which resides in the local
1571 <P><LI>Passwords are stored in two separate places: in the Authentication
1572 Database for AFS and in the each machine's local password file (the
1573 <B>/etc/passwd</B> file or equivalent) for the local file system.
1575 <P>When a user successfully authenticates, the AFS authentication service
1576 passes a <I>token</I> to the user's Cache Manager. The token
1577 is a small collection of data that certifies that the user has correctly
1578 provided the password associated with a particular AFS identity. The
1579 Cache Manager presents the token to AFS server processes along with service
1580 requests, as proof that the user is genuine. To learn about the mutual
1581 authentication procedure they use to establish identity, see <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.
1582 <P>The Cache Manager stores tokens in the user's credential structure in
1583 kernel memory. To distinguish one user's credential structure from
1584 another's, the Cache Manager identifies each one either by the
1585 user's UNIX UID or by a <I>process authentication group</I>
1586 (<I>PAG</I>), which is an identification number guaranteed to be unique in
1587 the cell. For further discussion, see <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
1588 <A NAME="IDX5757"></A>
1589 <P>A user can have only one token per cell in each separately identified
1590 credential structure. To obtain a second token for the same cell, the
1591 user must either log into a different machine or obtain another credential
1592 structure with a different identifier than any existing credential structure,
1593 which is most easily accomplished by issuing the <B>pagsh</B> command (see
1594 <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>). In a single credential structure, a user can have
1595 one token for each of many cells at the same time. As this implies,
1596 authentication status on one machine or PAG is independent of authentication
1597 status on another machine or PAG, which can be very useful to a user or system
1599 <P>The AFS distribution includes library files that enable each system
1600 type's login utility to authenticate users with AFS and log them into the
1601 local file system in one step. If you do not configure an AFS-modified
1602 login utility on a client machine, its users must issue the <B>klog</B>
1603 command to authenticate with AFS after logging in.
1604 <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
1605 in an operating system's proprietary login utility. In some cases,
1606 it is not possible to support a utility at all. For more information
1607 about the supported utilities in each AFS version, see the <I>IBM AFS
1610 <A NAME="IDX5758"></A>
1611 <A NAME="IDX5759"></A>
1612 <A NAME="IDX5760"></A>
1613 <A NAME="IDX5761"></A>
1614 <A NAME="IDX5762"></A>
1615 <A NAME="IDX5763"></A>
1616 <A NAME="IDX5764"></A>
1617 <P><H3><A NAME="HDRWQ64" HREF="auagd002.htm#ToC_78">Identifying AFS Tokens by PAG</A></H3>
1618 <P>As noted, the Cache Manager identifies user credential
1619 structures either by UNIX UID or by PAG. Using a PAG is preferable
1620 because it guaranteed to be unique: the Cache Manager allocates it based
1621 on a counter that increments with each use. In contrast, multiple users
1622 on a machine can share or assume the same UNIX UID, which creates potential
1623 security problems. The following are two common such situations:
1625 <P><LI>The local superuser <B>root</B> can always assume any other
1626 user's UNIX UID simply by issuing the <B>su</B> command, without
1627 providing the user's password. If the credential structure is
1628 associated with the user's UNIX UID, then assuming the UID means
1629 inheriting the AFS tokens.
1630 <P><LI>Two users working on different NFS client machines can have the same UNIX
1631 UID in their respective local file systems. If they both access the
1632 same NFS/AFS Translator machine, and the Cache Manager there identifies them
1633 by their UNIX UID, they become indistinguishable. To eliminate this
1634 problem, the Cache Manager on a translator machine automatically generates a
1635 PAG for each user and uses it, rather than the UNIX UID, to tell users
1638 <P>Yet another advantage of PAGs over UIDs is that processes spawned by the
1639 user inherit the PAG and so share the token; thus they gain access to AFS
1640 as the authenticated user. In many environments, for example, printer
1641 and other daemons run under identities (such as the local superuser
1642 <B>root</B>) that the AFS server processes recognize only as the
1643 <B>anonymous</B> user. Unless PAGs are used, such daemons cannot
1644 access files for which the <B>system:anyuser</B> group does not have
1645 the necessary ACL permissions.
1646 <P>Once a user has a PAG, any new tokens the user obtains are associated with
1647 the PAG. The PAG expires two hours after any associated tokens expire
1648 or are discarded. If the user issues the <B>klog</B> command before
1649 the PAG expires, the new token is associated with the existing PAG (the PAG is
1650 said to be <I>recycled</I> in this case).
1651 <P>AFS-modified login utilities automatically generate a PAG, as described in
1652 the following section. If you use a standard login utility, your users
1653 must issue the <B>pagsh</B> command before the <B>klog</B> command, or
1654 include the latter command's <B>-setpag</B> flag. For
1655 instructions, see <A HREF="#HDRWQ69">Using Two-Step Login and Authentication</A>.
1656 <P>Users can also use either command at any time to create a new PAG.
1657 The difference between the two commands is that the <B>klog</B> command
1658 replaces the PAG associated with the current command shell and tokens.
1659 The <B>pagsh</B> command initializes a new command shell before creating a
1660 new PAG. If the user already had a PAG, any running processes or jobs
1661 continue to use the tokens associated with the old PAG whereas any new jobs or
1662 processes use the new PAG and its associated tokens. When you exit the
1663 new shell (by pressing <<B>Ctrl-d</B>>, for example), you return to the
1664 original PAG and shell. By default, the <B>pagsh</B> command
1665 initializes a Bourne shell, but you can include the <B>-c</B> argument to
1666 initialize a C shell (the <B>/bin/csh</B> program on many system types) or
1667 Korn shell (the <B>/bin/ksh</B> program) instead.
1668 <A NAME="IDX5765"></A>
1669 <P><H3><A NAME="HDRWQ65" HREF="auagd002.htm#ToC_79">Using an AFS-modified login Utility</A></H3>
1670 <P>As previously mentioned, an AFS-modified login utility
1671 simultaneously obtains an AFS token and logs the user into the local file
1672 system. This section outlines the login and authentication process and
1673 its interaction with the value in the password field of the local password
1675 <P>An AFS-modified login utility performs a sequence of steps similar to the
1676 following; details can vary for different operating systems:
1678 <P><LI>It checks the user's entry in the local password file (the
1679 <B>/etc/passwd</B> file or equivalent).
1680 <P><LI>If no entry exists, or if an asterisk ( <TT>*</TT> ) appears in the
1681 entry's password field, the login attempt fails. If the entry
1682 exists, the attempt proceeds to the next step.
1683 <P><LI><A NAME="LIWQ66"></A>The utility obtains a PAG.
1684 <P><LI><A NAME="LIWQ67"></A>The utility converts the password provided by the user into an
1685 encryption key and encrypts a packet of data with the key. It sends the
1686 packet to the AFS authentication service (the AFS Authentication Server in the
1687 conventional configuration).
1688 <P><LI>The authentication service decrypts the packet and, depending on the
1689 success of the decryption, judges the password to be correct or
1690 incorrect. (For more details, see <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.)
1692 <P><LI>If the authentication service judges the password incorrect, the user does
1693 not receive an AFS token. The PAG is retained, ready to be associated
1694 with any tokens obtained later. The attempt proceeds to Step <A HREF="#LIWQ68">6</A>.
1695 <P><LI>If the authentication service judges the password correct, it issues a
1696 token to the user as proof of AFS authentication. The login utility
1697 logs the user into the local UNIX file system. Some login utilities
1698 echo the following banner to the screen to alert the user to authentication
1699 with AFS. Step <A HREF="#LIWQ68">6</A> is skipped.
1700 <PRE> AFS(R) <VAR>version</VAR> Login
1703 <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
1704 file system, by comparing the password provided to the local password
1707 <P><LI>If the password is incorrect or any value other than an encrypted
1708 13-character string appears in the password field, the login attempt
1710 <P><LI>If the password is correct, the user is logged into the local file system
1714 <A NAME="IDX5766"></A>
1715 <A NAME="IDX5767"></A>
1716 <A NAME="IDX5768"></A>
1717 <P>As indicated, when you use an AFS-modified login utility, the password
1718 field in the local password file is no longer the primary gate for access to
1719 your system. If the user provides the correct AFS password, then the
1720 program never consults the local password file. However, you can still
1721 use the password field to control access, in the following way:
1723 <P><LI>To prevent both local login and AFS authentication, place an asterisk (
1724 <B>*</B> ) in the field. This is useful mainly in emergencies, when
1725 you want to prevent a certain user from logging into the machine.
1726 <P><LI>To prevent login to the local file system if the user does not provide the
1727 correct AFS password, place a character string of any length other than the
1728 standard thirteen characters in the field. This is appropriate if you
1729 want to permit only people with local AFS accounts to login on your
1730 machines. A single <B>X</B> or other character is the most easily
1731 recognizable way to do this.
1732 <P><LI>To enable a user to log into the local file system even after providing an
1733 incorrect AFS password, record a standard UNIX encrypted password in the field
1734 by issuing the standard UNIX password-setting command (<B>passwd</B> or
1737 <P>Systems that use a Pluggable Authentication Module (PAM) for login and AFS
1738 authentication do not necessarily consult the local password file at all, in
1739 which case they do not use the password field to control authentication and
1740 login attempts. Instead, instructions in the PAM configuration file (on
1741 many system types, <B>/etc/pam.conf</B>) fill the same
1742 function. See the instructions in the <I>IBM AFS Quick
1743 Beginnings</I> for installing AFS-modified login utilities.
1744 <A NAME="IDX5769"></A>
1745 <P><H3><A NAME="HDRWQ69" HREF="auagd002.htm#ToC_80">Using Two-Step Login and Authentication</A></H3>
1746 <P>In cells that do not use an AFS-modified login utility, users
1747 must issue separate commands to login and authenticate, as detailed in the
1748 <I>IBM AFS User Guide</I>:
1750 <P><LI>They use the standard <B>login</B> program to login to the local file
1751 system, providing the password listed in the local password file (the
1752 <B>/etc/passwd</B> file or equivalent).
1753 <P><LI>They must issue the <B>klog</B> command to authenticate with the AFS
1754 authentication service, including its <B>-setpag</B> flag to associate the
1755 new tokens with a process authentication group (PAG).
1757 <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
1758 user's <B>.login</B> file (or equivalent) so that the user
1759 does not have to remember to issue the command after logging in. The
1760 user still must type a password twice, once at the prompt generated by the
1761 login utility and once at the <B>klog</B> command's prompt.
1762 This implies that the two passwords can differ, but it is less confusing if
1764 <P>Another effect of not using an AFS-modified login utility is that the AFS
1765 servers recognize the standard <B>login</B> program as the
1766 <B>anonymous</B> user. If the <B>login</B> program needs to
1767 access any AFS files (such as the <B>.login</B> file in a
1768 user's home directory), then the ACL that protects the file must include
1769 an entry granting the <B>l</B> (<B>lookup</B>) and <B>r</B>
1770 (<B>read</B>) permissions to the <B>system:anyuser</B>
1772 <P>When you do not use an AFS-modified login utility, an actual (scrambled)
1773 password must appear in the local password file for each user. Use the
1774 <B>/bin/passwd</B> file to insert or change these passwords. It is
1775 simpler if the password in the local password file matches the AFS password,
1776 but it is not required.
1777 <A NAME="IDX5770"></A>
1778 <A NAME="IDX5771"></A>
1779 <A NAME="IDX5772"></A>
1780 <A NAME="IDX5773"></A>
1781 <A NAME="IDX5774"></A>
1782 <A NAME="IDX5775"></A>
1783 <A NAME="IDX5776"></A>
1784 <A NAME="IDX5777"></A>
1785 <A NAME="IDX5778"></A>
1786 <A NAME="IDX5779"></A>
1787 <A NAME="IDX5780"></A>
1788 <A NAME="IDX5781"></A>
1789 <A NAME="IDX5782"></A>
1790 <A NAME="IDX5783"></A>
1791 <P><H3><A NAME="Header_81" HREF="auagd002.htm#ToC_81">Obtaining, Displaying, and Discarding Tokens</A></H3>
1792 <P>Once logged in, a user can obtain a token at any time with the
1793 <B>klog</B> command. If a valid token already exists, the new one
1794 overwrites it. If a PAG already exists, the new token is associated
1796 <P>By default, the <B>klog</B> command authenticates the issuer using the
1797 identity currently logged in to the local file system. To authenticate
1798 as a different identity, use the <B>-principal</B> argument. To
1799 obtain a token for a foreign cell, use the <B>-cell</B> argument (it can
1800 be combined with the <B>-principal</B> argument). See the <I>IBM
1801 AFS User Guide</I> and the entry for the <B>klog</B> command in the
1802 <I>IBM AFS Administration Reference</I>.
1803 <P>To discard either all tokens or the token for a particular cell, issue the
1804 <B>unlog</B> command. The command affects only the tokens
1805 associated with the current command shell. See the <I>IBM AFS User
1806 Guide</I>and the entry for the <B>unlog</B> command in the <I>IBM AFS
1807 Administration Reference</I>.
1808 <P>To display the tokens associated with the current command shell, issue the
1809 <B>tokens</B> command. The following examples illustrate its output
1810 in various situations.
1811 <P>If the issuer is not authenticated in any cell:
1812 <PRE> % <B>tokens</B>
1813 Tokens held by the Cache Manager:
1816 <P>The following shows the output for a user with AFS UID 1000 in the ABC
1818 <PRE> % <B>tokens</B>
1819 Tokens held by the Cache Manager:
1821 User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
1824 <P>The following shows the output for a user who is authenticated in ABC
1825 Corporation cell, the State University cell and the DEF Company cell.
1826 The user has different AFS UIDs in the three cells. Tokens for the last
1828 <PRE> % <B>tokens</B>
1829 Tokens held by the Cache Manager:
1831 User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
1832 User's (AFS ID 4286) tokens for afs@stateu.edu [Expires Jun 3 1:34]
1833 User's (AFS ID 22) tokens for afs@def.com [>>Expired<<]
1836 <P>The Kerberos version of the <B>tokens</B> command (the
1837 <B>tokens.krb</B> command), also reports information on the
1838 ticket-granting ticket, including the ticket's owner, the ticket-granting
1839 service, and the expiration date, as in the following example. Also see
1840 <A HREF="#HDRWQ70">Support for Kerberos Authentication</A>.
1841 <PRE> % <B>tokens.krb</B>
1842 Tokens held by the Cache Manager:
1843 User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
1844 User smith's tokens for krbtgt.ABC.COM@abc.com [Expires Jun 2 10:00]
1847 <P><H3><A NAME="Header_82" HREF="auagd002.htm#ToC_82">Setting Default Token Lifetimes for Users</A></H3>
1848 <A NAME="IDX5784"></A>
1849 <P>The maximum lifetime of a user token is the smallest of the <I>ticket
1850 lifetimes</I> recorded in the following three Authentication Database
1851 entries. The <B>kas examine</B> command reports the lifetime as
1852 <TT>Max ticket lifetime</TT>. Administrators who have the
1853 <TT>ADMIN</TT> flag on their Authentication Database entry can use the
1854 <B>-lifetime</B> argument to the <B>kas setfields</B> command to set
1855 an entry's ticket lifetime.
1857 <P><LI>The <B>afs</B> entry, which corresponds to the AFS server
1858 processes. The default is 100 hours.
1859 <P><LI>The <B>krbtgt</B>.<VAR>cellname</VAR> entry, which corresponds to
1860 the ticket-granting ticket used internally in generating the token. The
1861 default is 720 hours (30 days).
1862 <P><LI>The entry for the user of the AFS-modified login utility or issuer of the
1863 <B>klog</B> command. The default is 25 hours for user entries
1864 created using the AFS 3.1 or later version of the Authentication
1865 Server, and 100 hours for user entries created using the AFS 3.0
1866 version of the Authentication Server. A user can use the <B>kas
1867 examine</B> command to display his or her own Authentication Database
1870 <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
1871 calculated from the previously described three values. When issuing the
1872 <B>klog</B> command, a user can request a lifetime shorter than the
1873 default by using the <B>-lifetime</B> argument. For further
1874 information, see the <I>IBM AFS User Guide</I> and the <B>klog</B>
1875 reference page in the <I>IBM AFS Administration Reference</I>.
1877 <P><H3><A NAME="Header_83" HREF="auagd002.htm#ToC_83">Changing Passwords</A></H3>
1878 <A NAME="IDX5785"></A>
1879 <A NAME="IDX5786"></A>
1880 <A NAME="IDX5787"></A>
1881 <A NAME="IDX5788"></A>
1882 <A NAME="IDX5789"></A>
1883 <P>Regular AFS users can change their own passwords by using either the
1884 <B>kpasswd</B> or <B>kas setpassword</B> command. The commands
1885 prompt for the current password and then twice for the new password, to screen
1887 <P>Administrators who have the <TT>ADMIN</TT> flag on their Authentication
1888 Database entries can change any user's password, either by using the
1889 <B>kpasswd</B> command (which requires knowing the current password) or
1890 the <B>kas setpassword</B> command.
1891 <P>If your cell does not use an AFS-modified login utility, remember also to
1892 change the local password, using the operating system's password-changing
1893 command. For more instructions on changing passwords, see <A HREF="auagd018.htm#HDRWQ516">Changing AFS Passwords</A>.
1894 <P><H3><A NAME="Header_84" HREF="auagd002.htm#ToC_84">Imposing Restrictions on Passwords and Authentication Attempts</A></H3>
1895 <P>You can help to make your cell more secure by imposing restrictions on
1896 user passwords and authentication attempts. To impose the restrictions
1897 as you create an account, use the <B>A</B> instruction in the
1898 <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
1899 account, use the <B>kas setfields</B> command as described in <A HREF="auagd018.htm#HDRWQ515">Improving Password and Authentication Security</A>.
1900 <A NAME="IDX5790"></A>
1901 <A NAME="IDX5791"></A>
1902 <A NAME="IDX5792"></A>
1903 <A NAME="IDX5793"></A>
1904 <A NAME="IDX5794"></A>
1905 <A NAME="IDX5795"></A>
1906 <P>By default, AFS passwords never expire. Limiting password lifetime
1907 can help improve security by decreasing the time the password is subject to
1908 cracking attempts. You can choose an lifetime from 1 to 254 days after
1909 the password was last changed. It automatically applies to each new
1910 password as it is set. When the user changes passwords, you can also
1911 insist that the new password is not similar to any of the 20 passwords
1913 <A NAME="IDX5796"></A>
1914 <A NAME="IDX5797"></A>
1915 <A NAME="IDX5798"></A>
1916 <A NAME="IDX5799"></A>
1917 <P>Unscrupulous users can try to gain access to your AFS cell by guessing an
1918 authorized user's password. To protect against this type of
1919 attack, you can limit the number of times that a user can consecutively fail
1920 to provide the correct password. When the limit is exceeded, the
1921 authentication service refuses further authentication attempts for a specified
1922 period of time (the <I>lockout time</I>). To reenable
1923 authentication attempts before the lockout time expires, an administrator must
1924 issue the <B>kas unlock</B> command.
1925 <A NAME="IDX5800"></A>
1926 <A NAME="IDX5801"></A>
1927 <A NAME="IDX5802"></A>
1928 <A NAME="IDX5803"></A>
1929 <A NAME="IDX5804"></A>
1930 <A NAME="IDX5805"></A>
1931 <P>In addition to settings on user's authentication accounts, you can
1932 improve security by automatically checking the quality of new user
1933 passwords. The <B>kpasswd</B> and <B>kas setpassword</B>
1934 commands pass the proposed password to a program or script called
1935 <B>kpwvalid</B>, if it exists. The <B>kpwvalid</B> performs
1936 quality checks and returns a code to indicate whether the password is
1937 acceptable. You can create your own program or modified the sample
1938 program included in the AFS distribution. See the <B>kpwvalid</B>
1939 reference page in the <I>IBM AFS Administration Reference</I>.
1940 <P>There are several types of quality checks that can improve password
1943 <P><LI>The password is a minimum length
1944 <P><LI>The password is not a word
1945 <P><LI>The password contains both numbers and letters
1947 <P><H3><A NAME="HDRWQ70" HREF="auagd002.htm#ToC_85">Support for Kerberos Authentication</A></H3>
1948 <A NAME="IDX5806"></A>
1949 <A NAME="IDX5807"></A>
1950 <A NAME="IDX5808"></A>
1951 <A NAME="IDX5809"></A>
1952 <A NAME="IDX5810"></A>
1953 <A NAME="IDX5811"></A>
1954 <A NAME="IDX5812"></A>
1955 <P>If your site is using standard Kerberos authentication rather than the AFS
1956 Authentication Server, use the modified versions of the <B>klog</B>,
1957 <B>pagsh</B>, and <B>tokens</B> commands that support Kerberos
1958 authentication. The binaries for the modified version of these commands
1959 have the same name as the standard binaries with the addition of a
1960 <B>.krb</B> extension.
1961 <P>Use either the Kerberos version or the standard command throughout the
1962 cell; do not mix the two versions. AFS Product Support can provide
1963 instructions on installing the Kerberos version of these four commands.
1964 For information on the differences between the two versions of these commands,
1965 see the <I>IBM AFS Administration Reference</I>.
1966 <HR><H2><A NAME="HDRWQ71" HREF="auagd002.htm#ToC_86">Security and Authorization in AFS</A></H2>
1967 <P>AFS incorporates several features to ensure that only
1968 authorized users gain access to data. This section summarizes the most
1969 important of them and suggests methods for improving security in your
1971 <P><H3><A NAME="HDRWQ72" HREF="auagd002.htm#ToC_87">Some Important Security Features</A></H3>
1972 <A NAME="IDX5813"></A>
1973 <A NAME="IDX5814"></A>
1974 <P><B>ACLs on Directories</B>
1975 <P>Files in AFS are protected by the access control list (ACL) associated with
1976 their parent directory. The ACL defines which users or groups can
1977 access the data in the directory, and in what way. See <A HREF="auagd020.htm#HDRWQ562">Managing Access Control Lists</A>.
1978 <P><B>Mutual Authentication Between Client and Server</B>
1979 <P>When an AFS client and server process communicate, each requires the other
1980 to prove its identity during mutual authentication, which involves the
1981 exchange of encrypted information that only valid parties can decrypt and
1982 respond to. For a detailed description of the mutual authentication
1983 process, see <A HREF="#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.
1984 <P>AFS server processes mutually authenticate both with one another and with
1985 processes that represent human users. After mutual authentication is
1986 complete, the server and client have established an authenticated connection,
1987 across which they can communicate repeatedly without having to authenticate
1988 again until the connection expires or one of the parties closes it.
1989 Authenticated connections have varying lifetimes.
1991 <P>In order to access AFS files, users must prove their identities to the AFS
1992 authentication service by providing the correct AFS password. If the
1993 password is correct, the authentication service sends the user a
1994 <I>token</I> as evidence of authenticated status. See <A HREF="#HDRWQ63">Login and Authentication in AFS</A>.
1995 <P>Servers assign the user identity <B>anonymous</B> to users and
1996 processes that do not have a valid token. The <B>anonymous</B>
1997 identity has only the access granted to the <B>system:anyuser</B>
1999 <P><B>Authorization Checking</B>
2000 <P>Mutual authentication establishes that two parties communicating with one
2001 another are actually who they claim to be. For many functions, AFS
2002 server processes also check that the client whose identity they have verified
2003 is also authorized to make the request. Different requests require
2004 different kinds of privilege. See <A HREF="#HDRWQ73">Three Types of Privilege</A>.
2005 <P><B>Encrypted Network Communications</B>
2006 <A NAME="IDX5815"></A>
2007 <A NAME="IDX5816"></A>
2008 <A NAME="IDX5817"></A>
2009 <P>The AFS server processes encrypt particularly sensitive information before
2010 sending it back to clients. Even if an unauthorized party is able to
2011 eavesdrop on an authenticated connection, they cannot decipher encrypted data
2012 without the proper key.
2013 <P>The following AFS commands encrypt data because they involve server
2014 encryption keys and passwords:
2016 <P><LI>The <B>bos addkey</B> command, which adds a server encryption key to
2017 the <B>/usr/afs/etc/KeyFile</B> file
2018 <P><LI>The <B>bos listkeys</B> command, which lists the server encryption
2019 keys from the <B>/usr/afs/etc/KeyFile</B> file
2020 <P><LI>The <B>kpasswd</B> command, which changes a password in the
2021 Authentication Database
2022 <P><LI>Most commands in the <B>kas</B> command suite
2024 <P>In addition, the United States edition of the Update Server encrypts
2025 sensitive information (such as the contents of <B>KeyFile</B>) when
2026 distributing it. Other commands in the <B>bos</B> suite and the
2027 commands in the <B>fs</B>, <B>pts</B> and <B>vos</B> suites do not
2028 encrypt data before transmitting it.
2029 <P><H3><A NAME="HDRWQ73" HREF="auagd002.htm#ToC_88">Three Types of Privilege</A></H3>
2030 <P>AFS uses three separate types of privilege for the reasons
2031 discussed in <A HREF="auagd021.htm#HDRWQ585">The Reason for Separate Privileges</A>.
2033 <P><LI>Membership in the <B>system:administrators</B> group.
2034 Members are entitled to issue any <B>pts</B> command and those
2035 <B>fs</B> commands that set volume quota. By default, they also
2036 implicitly have the <B>a</B> (<B>administer</B>) and <B>l</B>
2037 (<B>lookup</B>) permissions on every ACL in the file tree even if the ACL
2038 does not include an entry for them.
2039 <P><LI>The <TT>ADMIN</TT> flag on the Authentication Database entry. An
2040 administrator with this flag can issue any <B>kas</B> command.
2041 <P><LI>Inclusion in the <B>/usr/afs/etc/UserList</B> file. An
2042 administrator whose username appears in this file can issue any
2043 <B>bos</B>, <B>vos</B>, or <B>backup</B> command (although some
2044 <B>backup</B> commands require additional privilege as described in <A HREF="auagd011.htm#HDRWQ260">Granting Administrative Privilege to Backup Operators</A>).
2046 <P><H3><A NAME="Header_89" HREF="auagd002.htm#ToC_89">Authorization Checking versus Authentication</A></H3>
2047 <P>AFS distinguishes between authentication and authorization
2048 checking. <I>Authentication</I> refers to the process of proving
2049 identity. <I>Authorization checking</I> refers to the process of
2050 verifying that an authenticated identity is allowed to perform a certain
2052 <P>AFS implements authentication at the level of connections. Each time
2053 two parties establish a new connection, they mutually authenticate. In
2054 general, each issue of an AFS command establishes a new connection between AFS
2055 server process and client.
2056 <P>AFS implements authorization checking at the level of server
2057 machines. If authorization checking is enabled on a server machine,
2058 then all of the server processes running on it provide services only to
2059 authorized users. If authorization checking is disabled on a server
2060 machine, then all of the server processes perform any action for
2061 anyone. Obviously, disabling authorization checking is an extreme
2062 security exposure. For more information, see <A HREF="auagd008.htm#HDRWQ123">Managing Authentication and Authorization Requirements</A>.
2063 <P><H3><A NAME="HDRWQ74" HREF="auagd002.htm#ToC_90">Improving Security in Your Cell</A></H3>
2064 <A NAME="IDX5818"></A>
2065 <P>You can improve the level of security in your cell by configuring user
2066 accounts, server machines, and system administrator accounts in the indicated
2068 <P><B>User Accounts</B>
2070 <P><LI>Use an AFS-modified login utility, or include the <B>-setpag</B> flag
2071 to the <B>klog</B> command, to associate the credential structure that
2072 houses tokens with a PAG rather than a UNIX UID. This prevents users
2073 from inheriting someone else's tokens by assuming their UNIX
2074 identity. For further discussion, see <A HREF="#HDRWQ64">Identifying AFS Tokens by PAG</A>.
2075 <P><LI>Encourage users to issue the <B>unlog</B> command to destroy their
2076 tokens before logging out. This forestalls attempts to access tokens
2077 left behind kernel memory. Consider including the <B>unlog</B>
2078 command in every user's <B>.logout</B> file or
2081 <P><B>Server Machines</B>
2083 <P><LI>Disable authorization checking only in emergencies or for very brief
2084 periods of time. It is best to work at the console of the affected
2085 machine during this time, to prevent anyone else from accessing the machine
2086 through the keyboard.
2087 <P><LI>Change the AFS server encryption key on a frequent and regular
2088 schedule. Make it difficult to guess (a long string including
2089 nonalphabetic characters, for instance). Unlike user passwords, the
2090 password from which the AFS key is derived can be longer than eight
2091 characters, because it is never used during login. The <B>kas
2092 setpassword</B> command accepts a password hundreds of characters
2093 long. For instructions, see <A HREF="auagd014.htm#HDRWQ355">Managing Server Encryption Keys</A>.
2094 <P><LI>As much as possible, limit the number of people who can login at a server
2095 machine's console or remotely. Imposing this limit is an extra
2096 security precaution rather than a necessity. The machine cannot serve
2097 as an AFS client in this case.
2098 <P><LI>Particularly limit access to the local superuser <B>root</B> account
2099 on a server machine. The local superuser <B>root</B> has free
2100 access to important administrative subdirectories of the <B>/usr/afs</B>
2101 directory, as described in <A HREF="#HDRWQ53">AFS Files on the Local Disk</A>.
2102 <A NAME="IDX5819"></A>
2103 <P><LI>As in any computing environment, server machines must be located in a
2104 secured area. Any other security measures are effectively worthless if
2105 unauthorized people can access the computer hardware.
2107 <P><B>System Administrators</B>
2109 <P><LI>Limit the number of system administrators in your cell. Limit the
2110 use of system administrator accounts on publicly accessible
2111 workstations. Such machines are not secure, so unscrupulous users can
2112 install programs that try to steal tokens or passwords. If
2113 administrators must use publicly accessible workstations at times, they must
2114 issue the <B>unlog</B> command before leaving the machine.
2115 <P><LI>Create an administrative account for each administrator separate from the
2116 personal account, and assign AFS privileges only to the administrative
2117 account. The administrators must authenticate to the administrative
2118 accounts to perform duties that require privilege, which provides a useful
2119 audit trail as well.
2120 <P><LI>Administrators must not leave a machine unattended while they have valid
2121 tokens. Issue the <B>unlog</B> command before leaving.
2122 <P><LI>Use the <B>-lifetime</B> argument to the <B>kas setfields</B>
2123 command to set the token lifetime for administrative accounts to a fairly
2124 short amount of time. The default lifetime for AFS tokens is 25 hours,
2125 but 30 or 60 minutes is possibly a more reasonable lifetime for administrative
2126 tokens. The tokens for administrators who initiate AFS Backup System
2127 operations must last somewhat longer, because it can take several hours to
2128 complete some dump operations, depending on the speed of the tape device and
2129 the network connecting it to the file server machines that house the volumes
2131 <P><LI>Limit administrators' use of the <B>telnet</B> program. It
2132 sends unencrypted passwords across the network. Similarly, limit use of
2133 other remote programs such as <B>rsh</B> and <B>rcp</B>, which send
2134 unencrypted tokens across the network.
2136 <A NAME="IDX5820"></A>
2137 <A NAME="IDX5821"></A>
2138 <A NAME="IDX5822"></A>
2139 <A NAME="IDX5823"></A>
2140 <P><H3><A NAME="HDRWQ75" HREF="auagd002.htm#ToC_91">A More Detailed Look at Mutual Authentication</A></H3>
2141 <P>As in any file system, security is a prime concern in
2142 AFS. A file system that makes file sharing easy is not useful if it
2143 makes file sharing mandatory, so AFS incorporates several features that
2144 prevent unauthorized users from accessing data. Security in a networked
2145 environment is difficult because almost all procedures require transmission of
2146 information across wires that almost anyone can tap into. Also, many
2147 machines on networks are powerful enough that unscrupulous users can monitor
2148 transactions or even intercept transmissions and fake the identity of one of
2150 <P>The most effective precaution against eavesdropping and information theft
2151 or fakery is for servers and clients to accept the claimed identity of the
2152 other party only with sufficient proof. In other words, the nature of
2153 the network forces all parties on the network to assume that the other party
2154 in a transaction is not genuine until proven so. <I>Mutual
2155 authentication</I> is the means through which parties prove their
2157 <P>Because the measures needed to prevent fakery must be quite sophisticated,
2158 the implementation of mutual authentication procedures is complex. The
2159 underlying concept is simple, however: parties prove their identities by
2160 demonstrating knowledge of a <I>shared secret</I>. A shared secret
2161 is a piece of information known only to the parties who are mutually
2162 authenticating (they can sometimes learn it in the first place from a trusted
2163 third party or some other source). The party who originates the
2164 transaction presents the shared secret and refuses to accept the other party
2165 as valid until it shows that it knows the secret too.
2166 <P>The most common form of shared secret in AFS transactions is the
2167 <I>encryption key</I>, also referred to simply as a <I>key</I>.
2168 The two parties use their shared key to encrypt the packets of information
2169 they send and to decrypt the ones they receive. Encryption using keys
2170 actually serves two related purposes. First, it protects messages as
2171 they cross the network, preventing anyone who does not know the key from
2172 eavesdropping. Second, ability to encrypt and decrypt messages
2173 successfully indicates that the parties are using the key (it is their shared
2174 secret). If they are using different keys, messages remain scrambled
2175 and unintelligible after decryption.
2176 <P>The following sections describe AFS's mutual authentication procedures
2177 in more detail. Feel free to skip these sections if you are not
2178 interested in the mutual authentication process.
2179 <P><H4><A NAME="Header_92">Simple Mutual Authentication</A></H4>
2180 <P>Simple mutual authentication involves only one encryption key and two
2181 parties, generally a client and server. The client contacts the server
2182 by sending a <I>challenge</I> message encrypted with a key known only to
2183 the two of them. The server decrypts the message using its key, which
2184 is the same as the client's if they really do share the same
2185 secret. The server responds to the challenge and uses its key to
2186 encrypt its response. The client uses its key to decrypt the
2187 server's response, and if it is correct, then the client can be sure that
2188 the server is genuine: only someone who knows the same key as the client
2189 can decrypt the challenge and answer it correctly. On its side, the
2190 server concludes that the client is genuine because the challenge message made
2191 sense when the server decrypted it.
2192 <P>AFS uses simple mutual authentication to verify user identities during the
2193 first part of the login procedure. In that case, the key is based on
2194 the user's password.
2195 <P><H4><A NAME="HDRWQ76">Complex Mutual Authentication</A></H4>
2196 <P>Complex mutual authentication involves three encryption keys
2197 and three parties. All secure AFS transactions (except the first part
2198 of the login process) employ complex mutual authentication.
2199 <A NAME="IDX5824"></A>
2200 <A NAME="IDX5825"></A>
2201 <A NAME="IDX5826"></A>
2202 <P>When a client wishes to communicate with a server, it first contacts a
2203 third party called a <I>ticket-granter</I>. The ticket-granter and
2204 the client mutually authenticate using the simple procedure. When they
2205 finish, the ticket-granter gives the client a <I>server ticket</I> (or
2206 simply <I>ticket</I>) as proof that it (the ticket-granter) has
2207 preverified the identity of the client. The ticket-granter encrypts the
2208 ticket with the first of the three keys, called the <I>server encryption
2209 key</I> because it is known only to the ticket-granter and the server the
2210 client wants to contact. The client does not know this key.
2211 <P>The ticket-granter sends several other pieces of information along with the
2212 ticket. They enable the client to use the ticket effectively despite
2213 being unable to decrypt the ticket itself. Along with the ticket, the
2214 items constitute a <I>token</I>:
2216 <A NAME="IDX5827"></A>
2217 <P><LI>A <I>session key</I>, which is the second encryption key involved in
2218 mutual authentication. The ticket-granter invents the session key at
2219 random as the shared secret between client and server. For reasons
2220 explained further below, the ticket-granter also puts a copy of the session
2221 key inside the ticket. The client and server use the session key to
2222 encrypt messages they send to one another during their transactions.
2223 The ticket-granter invents a different session key for each connection between
2224 a client and a server (there can be several transactions during a single
2226 <P><LI>The name of the server for which the ticket is valid (and so which server
2227 encryption key encrypts the ticket itself).
2228 <P><LI>A ticket lifetime indicator. The default lifetime of AFS server
2229 tickets is 100 hours. If the client wants to contact the server again
2230 after the ticket expires, it must contact the ticket-granter to get a new
2233 <P>The ticket-granter seals the entire token with the third key involved in
2234 complex mutual authentication--the key known only to it (the
2235 ticket-granter) and the client. In some cases, this third key is
2236 derived from the password of the human user whom the client represents.
2237 <P>Now that the client has a valid server ticket, it is ready to contact the
2238 server. It sends the server two things:
2240 <P><LI>The server ticket. This is encrypted with the server encryption
2242 <P><LI>Its request message, encrypted with the session key. Encrypting the
2243 message protects it as it crosses the network, since only the server/client
2244 pair for whom the ticket-granter invented the session key know it.
2246 <P>At this point, the server does not know the session key, because the
2247 ticket-granter just created it. However, the ticket-granter put a copy
2248 of the session key inside the ticket. The server uses the server
2249 encryption key to decrypts the ticket and learns the session key. It
2250 then uses the session key to decrypt the client's request message.
2251 It generates a response and sends it to the client. It encrypts the
2252 response with the session key to protect it as it crosses the network.
2253 <P>This step is the heart of mutual authentication between client and server,
2254 because it proves to both parties that they know the same secret:
2256 <P><LI>The server concludes that the client is authorized to make a request
2257 because the request message makes sense when the server decrypts it using the
2258 session key. If the client uses a different session key than the one
2259 the server finds inside the ticket, then the request message remains
2260 unintelligible even after decryption. The two copies of the session key
2261 (the one inside the ticket and the one the client used) can only be the same
2262 if they both came from the ticket-granter. The client cannot fake
2263 knowledge of the session key because it cannot look inside the ticket, sealed
2264 as it is with the server encryption key known only to the server and the
2265 ticket-granter. The server trusts the ticket-granter to give tokens
2266 only to clients with whom it (the ticket-granter) has authenticated, so the
2267 server decides the client is legitimate.
2268 <P>(Note that there is no direct communication between the ticket-granter and
2269 the server, even though their relationship is central to ticket-based mutual
2270 authentication. They interact only indirectly, via the client's
2271 possession of a ticket sealed with their shared secret.)
2272 <P><LI>The client concludes that the server is genuine and trusts the response it
2273 gets back from the server, because the response makes sense after the client
2274 decrypts it using the session key. This indicates that the server
2275 encrypted the response with the same session key as the client knows.
2276 The only way for the server to learn that matching session key is to decrypt
2277 the ticket first. The server can only decrypt the ticket because it
2278 shares the secret of the server encryption key with the ticket-granter.
2279 The client trusts the ticket-granter to give out tickets only for legitimate
2280 servers, so the client accepts a server that can decrypt the ticket as
2281 genuine, and accepts its response.
2283 <HR><H2><A NAME="HDRWQ77" HREF="auagd002.htm#ToC_94">Backing Up AFS Data</A></H2>
2284 <P>AFS provides two related facilities that help the
2285 administrator back up AFS data: backup volumes and the AFS Backup
2287 <P><H3><A NAME="Header_95" HREF="auagd002.htm#ToC_95">Backup Volumes</A></H3>
2288 <P>The first facility is the backup volume, which you create by cloning a
2289 read/write volume. The backup volume is read-only and so preserves the
2290 state of the read/write volume at the time the clone is made.
2291 <P>Backup volumes can ease administration if you mount them in the file system
2292 and make their contents available to users. For example, it often makes
2293 sense to mount the backup version of each user volume as a subdirectory of the
2294 user's home directory. A conventional name for this mount point is
2295 <B>OldFiles</B>. Create a new version of the backup volume (that
2296 is, reclone the read/write) once a day to capture any changes that were made
2297 since the previous backup. If a user accidentally removes or changes
2298 data, the user can restore it from the backup volume, rather than having to
2299 ask you to restore it.
2300 <P>The <I>IBM AFS User Guide</I> does not mention backup volumes, so
2301 regular users do not know about them if you decide not to use them.
2302 This implies that if you <B>do</B> make backup versions of user volumes,
2303 you need to tell your users about how the backup works and where you have
2305 <P>Users are often concerned that the data in a backup volume counts against
2306 their volume quota and some of them even want to remove the
2307 <B>OldFiles</B> mount point. It does not, because the backup volume
2308 is a separate volume. The only amount of space it uses in the
2309 user's volume is the amount needed for the mount point, which is about
2310 the same as the amount needed for a standard directory element.
2311 <P>Backup volumes are discussed in detail in <A HREF="auagd010.htm#HDRWQ201">Creating Backup Volumes</A>.
2312 <P><H3><A NAME="Header_96" HREF="auagd002.htm#ToC_96">The AFS Backup System</A></H3>
2313 <P>Backup volumes can reduce restoration requests, but they reside on disk
2314 and so do not protect data from loss due to hardware failure. Like any
2315 file system, AFS is vulnerable to this sort of data loss.
2316 <P>To protect your cell's users from permanent loss of data, you are
2317 strongly urged to back up your file system to tape on a regular and frequent
2318 schedule. The AFS Backup System is available to ease the administration
2319 and performance of backups. For detailed information about the AFS
2320 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>.
2321 <A NAME="IDX5828"></A>
2322 <A NAME="IDX5829"></A>
2323 <A NAME="IDX5830"></A>
2324 <A NAME="IDX5831"></A>
2325 <A NAME="IDX5832"></A>
2326 <A NAME="IDX5833"></A>
2327 <A NAME="IDX5834"></A>
2328 <A NAME="IDX5835"></A>
2329 <A NAME="IDX5836"></A>
2330 <A NAME="IDX5837"></A>
2331 <A NAME="IDX5838"></A>
2332 <A NAME="IDX5839"></A>
2333 <HR><H2><A NAME="HDRWQ78" HREF="auagd002.htm#ToC_97">Using UNIX Remote Services in the AFS Environment</A></H2>
2334 <P>The AFS distribution includes modified versions of several
2335 standard UNIX commands, daemons and programs that provide remote services,
2336 including the following:
2338 <P><LI>The <B>ftpd</B> program
2339 <P><LI>The <B>inetd</B> daemon
2340 <P><LI>The <B>rcp</B> program
2341 <P><LI>The <B>rlogind</B> daemon
2342 <P><LI>The <B>rsh</B> command
2344 <P>These modifications enable the commands to handle AFS authentication
2345 information (tokens). This enables issuers to be recognized on the
2346 remote machine as an authenticated AFS user.
2347 <P>Replacing the standard versions of these programs in your file tree with
2348 the AFS-modified versions is optional. It is likely that AFS's
2349 transparent access reduces the need for some of the programs anyway,
2350 especially those involved in transferring files from machine to machine, like
2351 the <B>ftpd</B> and <B>rcp</B> programs.
2352 <P>If you decide to use the AFS versions of these commands, be aware that
2353 several of them are interdependent. For example, the passing of AFS
2354 authentication information works correctly with the <B>rcp</B> command
2355 only if you are using the AFS version of both the <B>rcp</B> and
2356 <B>inetd</B> commands.
2357 <P>The conventional installation location for the modified remote commands are
2358 the <B>/usr/afsws/bin</B> and <B>/usr/afsws/etc</B>
2359 directories. To learn more about commands' functionality, see
2360 their reference pages in the <I>IBM AFS Administration
2362 <HR><H2><A NAME="HDRWQ79" HREF="auagd002.htm#ToC_98">Accessing AFS through NFS</A></H2>
2363 <P>Users of NFS client machines can access the AFS filespace by
2364 mounting the <B>/afs</B> directory of an AFS client machine that is
2365 running the <I>NFS/AFS Translator</I>. This is a particular
2366 advantage in cells already running NFS who want to access AFS using client
2367 machines for which AFS is not available. See <A HREF="auagd022.htm#HDRWQ595">Appendix A, Managing the NFS/AFS Translator</A>.
2368 <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>
2369 <!-- Begin Footer Records ========================================== -->
2371 <br>© <A HREF="http://www.ibm.com/">IBM Corporation 2000.</A> All Rights Reserved
2373 <!-- End Footer Records ============================================ -->
2374 <A NAME="Bot_Of_Page"></A>
git://git.openafs.org / openafs.git / blob