![[Return to Library]](../books.gif)
![[Contents]](../toc.gif)
![[Previous Topic]](../prev.gif)
![[Bottom of Topic]](../bot.gif)
![[Next Topic]](../next.gif)
![[Index]](../index.gif)
This chapter discusses many of the issues to consider when configuring and administering a cell, and directs you to detailed related information available elsewhere in this guide. It is assumed you are already familiar with the material in An Overview of AFS Administration.
It is best to read this chapter before installing your cell's first file server machine or performing any other administrative task.
AFS behaves like a standard UNIX file system in most respects, while also making file sharing easy within and between cells. This section describes some differences between AFS and the UNIX file system, referring you to more detailed information as appropriate.
AFS augments the standard UNIX file protection mechanism in two ways: it associates an access control list (ACL) with each directory, and it enables users to define a large number of their own groups, which can be placed on ACLs.
AFS uses ACLs to protect files and directories, rather than relying exclusively on the mode bits. This has several implications, which are discussed further in the indicated sections:
AFS enables users to define the groups of other users. Placing these groups on ACLs extends the same permissions to a number of exactly specified users at the same time, which is much more convenient than placing the individuals on the ACLs directly. See Administering the Protection Database.
There are also system-defined groups, system:anyuser and system:authuser, whose presence on an ACL extends access to a wide range of users at once. See The System Groups and Using Groups on ACLs.
Just as the AFS filespace is distinct from each machine's local file system, AFS authentication is separate from local login. This has two practical implications, which are discussed further in Using an AFS-modified login Utility.
AFS provides a modified login utility for each system type that accomplishes both local login and AFS authentication in one step, based on a single password. If you choose not to use the AFS-modified login utility, your users must login and authenticate in separate steps, as detailed in the IBM AFS User Guide.
This section summarizes how AFS modifies the functionality of some UNIX commands.
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The IBM AFS Quick Beginnings explains how to replace the vendor-supplied fsck program with the AFS version as you install each server machine.
The AFS version functions like the standard fsck program on data stored on both UFS and AFS partitions. The appearance of a banner like the following as the fsck program initializes confirms that you are running the correct one:
--- AFS (R) version fsck---
where version is the AFS version. For correct results, it must match the AFS version of the server binaries in use on the machine.
If you ever accidentally run the standard version of the program, contact AFS Product Support immediately. It is sometimes possible to recover volume data from the lost+found directory.
AFS does not allow hard links (created with the UNIX ln command) between files that reside in different directories, because in that case it is unclear which of the directory's ACLs to associate with the link.
AFS also does not allow hard links to directories, in order to keep the file system organized as a tree.
It is possible to create symbolic links (with the UNIX ln -s command) between elements in two different AFS directories, or even between an element in AFS and one in a machine's local UNIX file system. Do not create a symbolic link to a file whose name begins with either a number sign (#) or a percent sign (%), however. The Cache Manager interprets such links as a mount point to a regular or read/write volume, respectively.
When an application issues the UNIX close system call on a file, the Cache Manager performs a synchronous write of the data to the File Server that maintains the central copy of the file. It does not return control to the application until the File Server has acknowledged receipt of the data. For the fsync system call, control does not return to the application until the File Server indicates that it has written the data to non-volatile storage on the file server machine.
When an application issues the UNIX write system call, the Cache Manager writes modifications to the local AFS client cache only. If the local machine crashes or an application program exits without issuing the close system call, it is possible that the modifications are not recorded in the central copy of the file maintained by the File Server. The Cache Manager does sometimes write this type of modified data from the cache to the File Server without receiving the close or fsync system call, for example if it needs to free cache chunks for new data. However, it is not generally possible to predict when the Cache Manager transfers modified data to the File Server in this way.
The implication is that if an application's Save option invokes the write system call rather than close or fsync, the changes are not necessarily stored permanently on the File Server machine. Most application programs issue the close system call for save operations, as well as when they finish handling a file and when they exit.
Set the UNIX setuid bit only for the local superuser root; this does not present an automatic security risk: the local superuser has no special privilege in AFS, but only in the local machine's UNIX file system and kernel.
Any file can be marked with the setuid bit, but only members of the system:administrators group can issue the chown system call or the /etc/chown command.
The fs setcell command determines whether setuid programs that originate in a foreign cell can run on a given client machine. See Determining if a Client Can Run Setuid Programs.
This section explains how to choose a cell name and explains why choosing an appropriate cell name is important.
Your cell name must distinguish your cell from all others in the AFS global namespace. By conventions, the cell name is the second element in any AFS pathname; therefore, a unique cell name guarantees that every AFS pathname uniquely identifies a file, even if cells use the same directory names at lower levels in their local AFS filespace. For example, both the ABC Corporation cell and the State University cell can have a home directory for the user pat, because the pathnames are distinct: /afs/abc.com/usr/pat and /afs/stateu.edu/usr/pat.
By convention, cell names follow the ARPA Internet Domain System conventions for site names. If you are already an Internet site, then it is simplest to choose your Internet domain name as the cellname.
If you are not an Internet site, it is best to choose a unique Internet-style name, particularly if you plan to connect to the Internet in the future. AFS Product Support is available for help in selecting an appropriate name. There are a few constraints on AFS cell names:
The AFS distribution for some system types possibly does not include a modified rlogind program. See the IBM AFS Release Notes.
Never run the standard UNIX fsck command on an AFS file server machine. It does not understand how the File Server organizes volume data on disk, and so moves all AFS data into the lost+found directory on the partition.
Instead, use the version of the fsck program that is included in the AFS distribution. The <