Any NFS client machine that meets the following requirements can access files in AFS via the NFS/AFS Translator. It does not need to be configured as an AFS client machine.
It must NFS-mount a translator machine's /afs directory on a local directory, which by convention is also called /afs. The following instructions explain how to add the mount command to the NFS client machine's /etc/fstab file or equivalent.
The directory on which an NFS client mounts the translator's machine's /afs directory can be called something other than /afs. For instance, to make it easy to switch to another translator machine if the original one becomes inaccessible, you can mount more than one translator machine's /afs directory. Name the mount /afs for the translator machine that you normally use, and use a different name the mount to each alternate translator machine.
Mounting the AFS filespace on a directory other than /afs introduces another requirement, however: when issuing a command that takes an AFS pathname argument, you must specify the full pathname, starting with /afs, rather than a relative pathname. Suppose, for example, that a translator machine's AFS filespace is mounted at /afs2 on an NFS client machine and you issue the following command to display the ACL on the current working directory, which is in AFS:
% fs listacl .
The fs command interpreter on the NFS client must construct a full pathname before passing the request to the Cache Manager on the translator machine. The AFS filespace is mounted at /afs2, so the full pathname starts with that string. However, the Cache Manager on the translator cannot find a directory called /afs2, because its mount of the AFS filespace is called /afs. The command fails. To prevent the failure, provide the file's complete pathname, starting with the string /afs.
It must run an appropriate number of NFS client biod daemons, which improve performance by handling pre-reading and delayed writing. Most NFS vendors recommend running four such daemons, and most NFS initialization scripts start them automatically. Consult your NFS documentation.
To enable users to issue AFS commands, the NFS client machine must also be a supported system type (one for which AFS binaries are available) and able to access the AFS command binaries. The OpenAFS Release Notes list the supported system types in each release.
In addition, the AFSSERVER and AFSCONF environment variables must be set appropriately, as discussed in Setting the AFSSERVER and AFSCONF Environment Variables.
Become the local superuser root on the machine, if you are not already, by issuing the su command.
% su root Password: <
Configure the machine as an NFS client machine, if it is not already. Follow the instructions provided by your NFS vendor. The number of NFS client (biod) daemons needs to be appropriate for the expected load on this machine. The usual recommended number is four.
Create a directory called /afs on the machine, if one does not already exist, to act as the mount point for the translator machine's /afs directory. It is acceptable to use other names, but doing so introduces the limitation discussed in the introduction to this section.
# mkdir /afs
Modify the machine's file systems registry file (/etc/fstab or equivalent) to include a command that mounts a translator machine's /afs directory. To verify the correct syntax of the mount command, see the operating system's mount(5) manual page. The following example includes options that are appropriate on many system types.
mount -o hard,intr,timeo=300 translator_machine:/afs /afs
Indicates that the NFS client retries NFS requests until the NFS server (translator machine) responds. When using the translator, file operations possibly take longer than with NFS alone, because they must also pass through the AFS Cache Manager. With a soft mount, a delayed response from the translator machine can cause the request to abort. Many NFS versions use hard mounts by default; if your version does not, it is best to add this option.
Enables the user to use a keyboard interrupt signal (such as <Ctrl-c>) to break the mount when the translator machine is inaccessible. Include this
option only if the
hard option is used, in which case the connection does not
automatically break off when a translator machine goes down.
Sets the maximum time (in tenths of seconds) the translator can take to respond to the NFS client's request before the client considers the request timed out. With a hard mount, setting this option to a high number like 300 reduces the number of error messages like the following, which are generated when the translator does not respond immediately.
NFS server translator is not responding, still trying
With a soft mount, it reduces the number of actual errors returned on timed-out requests.
Specifies the fully-qualified hostname of the translator machine whose /afs directory is to be mounted on the client machine's /afs directory.
To mount the translator machine's /afs directory onto a directory on the NFS
client other than /afs, substitute the alternate directory name for the second instance
/afs in the mount command.
(Optional) If appropriate, create the /.AFSSERVER file to set the AFSSERVER environment variable for all of the machine's users. For a discussion, see Setting the AFSSERVER and AFSCONF Environment Variables. Place a single line in the file, specifying the fully-qualified hostname of the translator machine that is to serve as the remote executor. To enable users to issue commands that handle tokens, it must be the machine named as translator_machine in Step 4.
(Optional) If appropriate, create the /.AFSCONF file to set the AFSCONF environment variable for all of the machine's users. For a discussion, see Setting the AFSSERVER and AFSCONF Environment Variables. Place a single line in the file, specifying the name of the directory where the CellServDB and ThisCell files reside. If you use a central update source for these files (by convention, /afs/cellname/common/etc), name it here.