| Overview | ||
|---|---|---|
 | Appendix A. Managing the NFS/AFS Translator |  |
| Overview | ||
|---|---|---|
| | Appendix A. Managing the NFS/AFS Translator | |
The NFS/AFS Translator enables users on NFS client machines to access the AFS filespace as if they are working on an AFS client machine, which facilitates collaboration with other AFS users.
An NFS/AFS translator machine (or simply ltranslator machine) is a machine configured as both an AFS client and an NFS server:
Its AFS client functionality enables it to access the AFS filespace. The Cache Manager requests and caches files from AFS file server machines, and can even maintain tokens for NFS users, if you have made the configuration changes that enable NFS users to authenticate with AFS.
Its NFS server functionality makes it possible for the translator machine to export the AFS filespace to NFS client machines. When a user on an NFS client machine mounts the translator machine's /afs directory (or one of its subdirectories, if that feature is enabled), access to AFS is immediate and transparent. The NFS client machine does not need to run any AFS software.
By configuring the translation environment appropriately, you can provide either unauthenticated or authenticated access to AFS from NFS client machines. The sections of this chapter on configuring translator machines, NFS client machines, and AFS user accounts explain how to configure the translation environment appropriately.
If you configure the environment for unauthenticated access, the AFS File Server considers the NFS users to be the user anonymous. They can access only those AFS files and directories for which the access control list (ACL) extends the required permissions to the system:anyuser group. They can issue only those AFS commands that do not require privilege, and then only if their NFS client machine is a system type for which AFS binaries are available and accessible by the system:anyuser group. Such users presumably do not have AFS accounts.
If you configure the environment for authenticated access, you must create entries in the AFS Authentication and Protection Databases for the NFS users. The authentication procedure they use depends on whether the NFS client machine is a supported system type (one for which AFS binaries are available):
If AFS binaries are available for the NFS client machine, NFS users can issue the klog command on the NFS client machine. They can access the filespace and issue AFS commands to the same extent as authenticated users working on AFS client machines.
If AFS binaries are not available for the NFS client machine, NFS users must establish a connection with the translator machine (using the telnet utility, for example) and then issue the klog and knfs commands on the translator machine to make its Cache Manager use the tokens correctly while users work on the NFS client. They can access the AFS filespace as authenticated users, but cannot issue AFS commands. For instructions, see Authenticating on Unsupported NFS Client Machines.
If you wish to enable your NFS users to issue AFS commands, you must define the AFSSERVER and AFSCONF environment variables in their command shell. This section explains the variables' function and outlines the various methods for setting them.
Issuing AFS commands also requires that the NFS client machine is a supported system type (one for which AFS binaries are available and accessible). Users working on NFS client machines of unsupported system types can access AFS as authenticated users, but they cannot issue AFS commands. It is not necessary to define the AFSSERVER and AFSCONF variables for such users. For instructions on using the knfs command to obtain authenticated access on unsupported system types, see Authenticating on Unsupported NFS Client Machines.
The AFSSERVER variable designates the AFS client machine that performs two functions for NFS clients:
It acts as the NFS client's remote executor by executing AFS-specific system calls on its behalf, such as those invoked by the klog and tokens commands and by many commands in the AFS suites.
Its stores the tokens that NFS users obtain when they authenticate with AFS. This implies that the remote executor machine and the translator machine must be the same if the user needs authenticated access to AFS.
The choice of remote executor most directly affects commands that display or change Cache Manager configuration, such as the fs getcacheparms, fs getcellstatus, and fs setcell commands. When issued on an NFS client, these commands affect the Cache Manager on the designated remote executor machine. (Note, however, that several such commands require the issuer to be logged into the remote executor's local file system as the local superuser root. The ability of NFS client users to log in as root is controlled by NFS, not by the NFS/AFS Translator, so setting the remote executor properly does not necessarily enable users on the NFS client to issue such commands.)
The choice of remote executor is also relevant for AFS commands that do not concern Cache Manager configuration but rather have the same result on every machine, such as the fs commands that display or set ACLs and volume quota. These commands take an AFS path as one of their arguments. If the Cache Manager on the remote executor machine mounts the AFS filespace at the /afs directory, as is conventional for AFS clients, then the pathname specified on the NFS client must begin with the string /afs for the Cache Manager to understand it. This implies that the remote executor must be the NFS client's primary translator machine (the one whose /afs directory is mounted at /afs on the NFS client).
The AFSCONF environment variable names the directory that houses the ThisCell and CellServDB files to use when running AFS commands issued on the NFS client machine. As on an AFS client, these files determine the default cell for command execution.
For predictable performance, it is best that the files in the directory named by the AFSCONF variable match those in the /usr/vice/etc directory on the translator machine. If your cell has an AFS directory that serves as the central update source for files in the /usr/vice/etc directory, it is simplest to set the AFSCONF variable to refer to it. In the conventional configuration, this directory is called /afs/cellname/common/etc.
To learn the values of the AFSSERVER and AFSCONF variables, AFS command interpreters consult the following three sources in sequence:
The current command shell's environment variable definitions
The .AFSSERVER or .AFSCONF file in the issuer's home directory
The /.AFSSERVER or /.AFSCONF file in the NFS client machine's root (/) directory. If the client machine is diskless, its root directory can reside on an NFS server machine.
(Actually, before consulting these sources, the NFS client looks for the CellServDB and ThisCell files in its own /usr/vice/etc directory. If the directory exists, the NFS client does not use the value of the AFSCONF variable. However, the /usr/vice/etc directory usually exists only on AFS clients, not NFS clients.)
As previously detailed, correct performance generally requires that the remote executor machine be the NFS client's primary translator machine (the one whose /afs directory is mounted at the /afs directory on the NFS client). The requirement holds for all users accessing AFS from the NFS client, so it is usually simplest to create the .AFSSERVER file in the NFS client's root directory. The main reason to create the file in a user's home directory or to set the AFSSERVER environment variable in the current command shell is that the user needs to switch to a different translator machine, perhaps because the original one has become inaccessible.
Similarly, it generally makes sense to create the .AFSCONF file in the NFS client's root directory. Creating it in the user's home directory or setting the AFSCONF environment variable in the current command shell is useful mostly when there is a reason to specify a different set of database server machines for the cell, perhaps in a testing situation.
When an application running on an AFS client machine issues the close or fsync system call on a file, the Cache Manager by default performs a synchronous write of the data to the File Server. (For further discussion, see AFS Implements Save on Close and Enabling Asynchronous Writes.)
To avoid degrading performance for the AFS users working on a translator machine, AFS does not perform synchronous writes for applications running on the translator machine's NFS clients. Instead, one of the Cache Manager daemons (the maintenance daemon) checks every 60 seconds for chunks in the cache that contain data saved on NFS clients, and writes their contents to the File Server. This does not guarantee that data saved on NFS clients is written to the File Server within 60 seconds, but only that the maintenance daemon checks for and begins the write of data at that interval.
Furthermore, AFS always ignores the fsync system call as issued on an NFS client. The call requires an immediate and possibly time-consuming response from the File Server, which potentially causes delays for other AFS clients of the File Server. NFS version 3 automatically issues the fsync system call directly after the close call, but the Cache Manager ignores it and handles the operation just like a regular close.
The delayed write mechanism means that there is usually a delay between the time when an NFS application issues the close or fsync system call on a file and the time when the changes are recorded at the File Server, which is when they become visible to users working on other AFS client machines (either directly or on its NFS clients). The delay is likely to be longer than for files saved by users working directly on an AFS client machine.
The exact amount of delay is difficult to predict. The NFS protocol itself allows a standard delay before saved data must be transferred from the NFS client to the NFS server (the translator machine). The modified data remains in the translator machine's AFS client cache until the maintenance daemon's next scheduled check for such data, and it takes additional time to transfer the data to the File Server. The maintenance daemon uses a single thread, so there can be additional delay if it takes more than 60 seconds to write out all of the modified NFS data. That is, if the maintenance daemon is still writing data at the time of the next scheduled check, it cannot notice any additional modified data until the scheduled time after it completes the long write operation.
The Cache Manager's response to the write system call is the same whether it is issued on an AFS client machine or on an NFS client of a translator machine: it records the modifications in the local AFS client cache only.
| |  | |
| Appendix A. Managing the NFS/AFS Translator |  | Configuring NFS/AFS Translator Machines |