| Configuring NFS/AFS Translator Machines | ||
|---|---|---|
 | Appendix A. Managing the NFS/AFS Translator |  |
| Configuring NFS/AFS Translator Machines | ||
|---|---|---|
| | Appendix A. Managing the NFS/AFS Translator | |
To act as an NFS/AFS translator machine, a machine must configured as follows:
It must be an AFS client. Many system types supported as AFS clients can be translator machines. To learn about possible restrictions in a specific release of AFS, see the OpenAFS Release Notes.
It must be an NFS server. The appropriate number of NFS server daemons (nfsd and others) depends on the anticipated NFS client load.
It must export the local directory on which the AFS filespace is mounted, /afs by convention.
If users on a translator machine's NFS clients are to issue AFS commands, the translator machine must also meet the requirements discussed in Configuring the Translator Machine to Accept AFS Commands.
The AFS distribution for system types that can act as NFS/AFS Translator machines usually includes two versions of the AFS kernel extensions file, one for machines where the kernel supports NFS server functionality, and one for machines not using NFS (the latter AFS kernel extensions file generally has the string nonfs in its name). A translator machine must use the NFS-enabled version of the AFS extensions file. On some system types, you select the appropriate file by moving it to a certain location, whereas on other system types you set a variable that results in automatic selection of the correct file. See the instructions in the OpenAFS Quick Beginnings for incorporating AFS into the kernel on each system type.
On many system types, NFS is included in the kernel by default, so it is not necessary to load NFS kernel extensions explicitly. On system types where you must load NFS extensions, then in general you must load them before loading the AFS kernel extensions. The OpenAFS Quick Beginnings describes how to incorporate the AFS initialization script into a machine's startup sequence so that it is ordered correctly with respect to the script that handles NFS.
In addition, the AFS extensions must be loaded into the kernel before the afsd command runs. The AFS initialization script included in the AFS distribution correctly orders the loading and afsd commands.
For users working on a translator machine's NFS clients to issue AFS commands, the -rmtsys flag must be included on the afsd command which initializes the translator machine's Cache Manager. The flag starts an additional daemon (the remote executor daemon), which executes AFS-specific system calls on behalf of NFS clients. For a discussion of the implications of NFS users issuing AFS commands, see Setting the AFSSERVER and AFSCONF Environment Variables.
The instructions in the OpenAFS Quick Beginnings for configuring the Cache Manager explain how to add options such as the -rmtsys flag to the afsd command in the AFS initialization script. On many system types, it is simplest to list the flag on the line in the script that defines the OPTIONS variable. The remote executor daemon does not consume many resources, so it is simplest to add it to the afsd command on every translator machine, even if not all users on the machine's NFS clients issue AFS commands.
After an AFS client machine is configured as a translator machine, it by default exports the AFS filespace to NFS clients. You can disable and reenable translator functionality by using the fs exportafs command's -start argument. The command's other arguments control other aspects of translator behavior.
The -convert argument controls whether the second and third (group and other) sets of UNIX mode bits on an AFS file or directory being exported to NFS are set to match the first (owner) mode bits. By default, the mode bits are set to match.
Unlike AFS, NFS uses all three sets of mode bits when determining whether a user can read or write a file, even one stored in AFS. Some AFS files possibly do not have any group and other mode bits turned on, because AFS uses only the owner bits in combination with the ACL on the file's directory. If only the owner mode bits are set, NFS allows only the file's owner of the file to read or write it. Setting the -convert argument to the value on enables other users to access the file in the same manner as the owner. Setting the value off preserves the mode bits set on the file as stored in AFS.
The -uidcheck argument controls whether tokens can be assigned to an NFS user whose local UID on the NFS client machine differs from the local UID associated with the tokens on the translator machine. By default, this is possible.
If you turn on UID checking by setting the value on, then tokens can be assigned only to an NFS user whose local UID matches the local UID of the process on the translator machine that is assigning the tokens. One consequence is that there is no point in including the -id argument to the knfs command: the only acceptable value is the local UID of the command's issuer, which is the value used when the -id argument is omitted. Requiring matching UIDs in this way is effective only when users have the same local UID on the translator machine as on NFS client machines. In that case, it guarantees that users assign their tokens only to their own NFS sessions. For instructions, see Authenticating on Unsupported NFS Client Machines.
Turning on UID checking also prevents users on supported NFS clients from using the klog command to authenticate on the NFS client directly. They must authenticated and use the knfs command on the translator machine instead. This is because after the klog command interpreter obtains the token on the NFS client, it passes it to the Cache Manager's remote executor daemon, which makes the system call that stores the token in a credential structure on the translator machine. The remote executor generally runs as the local superuser root, so in most cases its local UID (normally zero) does not match the local UID of the user who issued the klog command on the NFS client machine.
On the other hand, although using the knfs command instead of the klog command is possibly less convenient for users, it eliminates a security exposure: the klog command interpreter passes the token across the network to the remote executor daemon in clear text mode.
If you disable UID checking by assigning the value off , the issuer of the knfs command can assign tokens to a user who has a different local UID on the NFS client machine, such as the local superuser root. Indeed, more than one issuer of the knfs command can assign tokens to the same user on the NFS client machine. Each time a different user issues the knfs command with the same value for the -id argument, that user's tokens overwrite the existing ones. This can result in unpredictable access for the NFS user.
The -submounts argument controls whether users on the NFS client can mount AFS directories other than the top-level /afs directory. By default, the translator does not permit these submounts.
Submounts can be useful in a couple of circumstances. If, for example, NFS users need to access their own AFS home directories only, then creating a submount to it eliminates the need for them to know or enter the complete path. Similarly, you can use a submount to prevent users from accessing parts of the filespace higher in the AFS hierarchy than the submount.
The following instructions configure the translator to enable users to issue AFS commands. Omit Step 6 if you do not want to enable this functionality.
Become the local superuser root on the machine, if you are not already, by issuing the su command.
% su root
Password: <root_password>
Configure the NFS/AFS translator machine as an NFS server, if it is not already. Follow the instructions provided by your NFS supplier. The appropriate number of NFS server daemons (such as nfsd) depends on the number of potential NFS clients.
Configure the NFS/AFS translator machine as an AFS client, if it is not already. For the most predictable performance, the translator machine's local copies of the /usr/vice/etc/CellServDB and /usr/vice/etc/ThisCell files must be the same as on other client machines in the cell.
Modify the file that controls mounting of directories on the machine by remote NFS clients.
On systems that use the /etc/exports file, edit it to enable export of the /afs directory to NFS clients. You can list the names of specific NFS client machines if you want to provide access only to certain users. For a description of the file's format, see the NFS manual page for exports(5).
The following example enables any NFS client machine to mount the machine's /afs, /usr, and /usr2 directories:
/afs /usr /usr2
On system types that use the share command, edit the /etc/dfs/dfstab file or equivalent to include share instructions that enable remote mounts of the /afs directory. Most distributions include the binary as /usr/sbin/share. The following example commands enable remote mounts of the root ( / ) and /afs directories. To verify the correct syntax, consult the manual page for the share command.
share -F nfs -o rw -d "root" / share -F nfs -o rw -d "afs gateway" /afs
Edit the machine's AFS initialization file to invoke the standard UNIX exportfs command after the afsd program runs. On some system types, the modifications you made in Step 4 are not enough to enable exporting the AFS filespace via the /afs directory, because the resulting configuration changes are made before the afsd program runs during machine initialization. Only after the afsd program runs does the /afs directory become the mount point for the entire AFS filespace; before, it is a local directory like any other.
Modify the afsd command in the AFS initialization file to include the -rmtsys flag.
For system types other than IRIX, the instructions in the OpenAFS Quick Beginnings for configuring the Cache Manager explain how to add the -rmtsys flag, for example by adding it to the line in the script that defines the value for the OPTIONS variable.
On IRIX systems, the AFS initialization script automatically adds the -rmtsys flag if you have activated the afsxnfs configuration variable as instructed in the OpenAFS Quick Beginnings instructions for incorporating AFS extensions into the kernel. If the variable is not already activated, issue the following command.
# /etc/chkconfig -f afsxnfs on
(Optional) Depending on the number of NFS clients you expect this machine to serve, it can be beneficial to add other arguments to the afsd command in the machine's initialization file, such as the -daemons argument to set the number of background daemons. See Administering Client Machines and the Cache Manager and the afsd reference page in the OpenAFS Administration Reference.
Reboot the machine. On many system types, the appropriate command is shutdown; consult your operating system administrator's guide.
# shutdown appropriate_options
Become the local superuser root on the machine, if you are not already, by issuing the su command.
% su root
Password: <root_password>
Issue the fs exportafs command.
# fs exportafs nfs [-start {on | off}} ] [-convert {on | off}] [-uidcheck {on | off}] [-submounts {on | off}]
Disables translator functionality if the value is off or reenables it if the value is on. Omit this argument to display the current setting of all parameters set by this command.
Controls the setting of the second and third (group and other) sets of UNIX mode bits on AFS files and directories as exported to NFS clients If the value is on, they are set to match the owner mode bits. If the value is off, the bits are not changed. If this argument is omitted, the default value is on.
Controls whether issuers of the knfs command can specify a value for its -id argument that does not match their AFS UID:
If the value is on, the value of the -id argument must match the issuer's local UID.
If the value is off, the issuer of the knfs command can use the -id argument to assign tokens to a user who has a different local UID on the NFS client machine, such as the local superuser root.
If this argument is omitted, the default value is off.
Controls whether the translator services an NFS mount of any directory in the AFS filespace other than the top-level /afs directory. If the value is on, such submounts are allowed. If the value is off, only mounts of the /afs directory are allowed. If this argument is omitted, the default value is off.
| |  | |
| Overview |  | Configuring NFS Client Machines |