Configuring Your AFS Filespace

Configuring Your AFS Filespace
	Chapter 2. Issues in Cell Configuration and Administration

This section summarizes the issues to consider when configuring your AFS filespace. For a discussion of creating volumes that correspond most efficiently to the filespace's directory structure, see Creating Volumes to Simplify Administration.

Note

For Windows users: Windows uses a backslash (\) rather than a forward slash (/) to separate the elements in a pathname. The hierarchical organization of the filespace is however the same as on a UNIX machine.

AFS pathnames must follow a few conventions so the AFS global namespace looks the same from any AFS client machine. There are corresponding conventions to follow in building your file tree, not just because pathnames reflect the structure of a file tree, but also because the AFS Cache Manager expects a certain configuration.

The Top /afs Level

The first convention is that the top level in your file tree be called the /afs directory. If you name it something else, then you must use the -mountdir argument with the afsd program to get Cache Managers to mount AFS properly. You cannot participate in the AFS global namespace in that case.

The Second (Cellname) Level

The second convention is that just below the /afs directory you place directories corresponding to each cell whose file tree is visible and accessible from the local cell. Minimally, there must be a directory for the local cell. Each such directory is a mount point to the indicated cell's root.cell volume. For example, in the Example Corporation cell, /afs/example.com is a mount point for the cell's own root.cell volume and example.org is a mount point for the Example Organization cell's root.cell volume. The fs lsmount command displays the mount points.

   % fs lsmount /afs/example.com
   '/afs/example.com' is a mount point for volume '#root.cell'
   % fs lsmount /afs/example.org
   '/afs/example.org' is a mount point for volume '#example.org:root.cell'

To reduce the amount of typing necessary in pathnames, you can create a symbolic link with an abbreviated name to the mount point of each cell your users frequently access (particularly the home cell). In the Example Corporation cell, for instance, /afs/example is a symbolic link to the /afs/example.com mount point, as the fs lsmount command reveals.

   % fs lsmount /afs/example
   '/afs/example' is a symbolic link, leading to a mount point for volume
'#root.cell'

The Third Level

You can organize the third level of your cell's file tree any way you wish. The following list describes directories that appear at this level in the conventional configuration:

common

This directory contains programs and files needed by users working on machines of all system types, such as text editors, online documentation files, and so on. Its /etc subdirectory is a logical place to keep the central update sources for files used on all of your cell's client machines, such as the ThisCell and CellServDB files.

public

A directory accessible to anyone who can access your filespace, because its ACL grants the l (lookup) and r (read) permissions to the system:anyuser group. It is useful if you want to enable your users to make selected information available to everyone, but do not want to grant foreign users access to the contents of the usr directory which houses user home directories (and is also at this level). It is conventional to create a subdirectory for each of your cell's users.

service

This directory contains files and subdirectories that help cells coordinate resource sharing. For a list of the proposed standard files and subdirectories to create, call or write to AFS Product Support.

As an example, files that other cells expect to find in this directory's etc subdirectory can include the following:

CellServDB.export, a list of database server machines for many cells
CellServDB.local, a list of the cell's own database server machines
passwd, a copy of the local password file (/etc/passwd or equivalent) kept on the local disk of the cell's client machines
group, a copy of the local groups file (/etc/group or equivalent) kept on the local disk of the cell's client machines

sys_type

A separate directory for storing the server and client binaries for each system type you use in the cell. Configuration is simplest if you use the system type names assigned in the AFS distribution, particularly if you wish to use the @sys variable in pathnames (see Using the @sys Variable in Pathnames). The OpenAFS Release Notes lists the conventional name for each supported system type.

Within each such directory, create directories named bin, etc, usr, and so on, to store the programs normally kept in the /bin, /etc and /usr directories on a local disk. Then create symbolic links from the local directories on client machines into AFS; see Configuring the Local Disk. Even if you do not choose to use symbolic links in this way, it can be convenient to have central copies of system binaries in AFS. If binaries are accidentally removed from a machine, you can recopy them onto the local disk from AFS rather than having to recover them from tape

usr

This directory contains home directories for your local users. As discussed in the previous entry for the public directory, it is often practical to protect this directory so that only locally authenticated users can access it. This keeps the contents of your user's home directories as secure as possible.

If your cell is quite large, directory lookup can be slowed if you put all home directories in a single usr directory. For suggestions on distributing user home directories among multiple grouping directories, see Grouping Home Directories.


Participating in the AFS Global Namespace		Creating Volumes to Simplify Administration