File Server Machines

· A Fileset Server (ftserver process).

· The File Exporter, which is initialized by the fxd process, in the kernel.

· The dfsbind process.

· The Replication Server (repserver process).

· Two upclient processes: one to retrieve configuration files from the System Control machine, and one to retrieve binary files from the Binary Distribution machine of the proper CPU/OS type.

· A BOS Server (bosserver process). (See Choosing DFS Machine Roles for more information about the BOS Server.)

The Fileset Server, or ftserver process, provides an interface for commands that affect filesets (commands that create, delete, or move filesets, and commands that prepare filesets for archiving to tape or other media). The most common occurrences of fileset creation and deletion are when you add or remove users from the system. Filesets are most often moved to provide load balancing among File Server machines.

The Fileset Server must run on any machine that exports data for use in the global namespace. The admin.ft list is used to designate administrative users who can issue fts commands that affect the ftserver process on a machine and to designate other server machines from which the machine can accept filesets. Users, groups, and machines listed in the admin.ft list can differ among DFS administrative domains.

The File Exporter (sometimes called the Protocol Exporter) runs as part of the kernel on each File Server machine. It provides the same services across the network that the local operating system provides on a local disk:

· Delivering requested files and programs to clients; storing files and programs when clients finish with them

· Maintaining the directory hierarchy structure

· Handling file-related or directory-related requests (creating, deleting, copying, and moving filesets)

· Tracking status information (including size and modification status) about each file and directory

· Creating symbolic links between files

Unlike the DFS server processes, the File Exporter is not associated with an administrative list. Instead, the command line for the fxd process, which is used to initialize the File Exporter and start related kernel daemons, includes an -admingroup option that specifies the administrative group for the File Exporter on each File Server machine. The group specified with this option must be defined in the Registry Database, as must all groups used with DFS.

Members of this administrative group can change the ACL and UNIX permissions of all data exported from the machine. They have the equivalent of the ACL c permission on all of the files and directories in each exported DCE LFS fileset, and they can effectively change the UNIX permissions on all of the files and directories in each exported non-LFS fileset. Members of the group can also change the owner and owning group of all files and directories exported from the machine. Include only highly trusted system administrators in this group.

Though similar in many respects, inclusion in the administrative group associated with the File Exporter and being logged in as root are not equivalent. A user who is logged into the local machine as root can perform different operations on a file or directory, depending on how the user accesses the file or directory:

· When accessing a file or directory via its DCE pathname, if the user is logged into the local machine as root but is not authenticated to DCE, DFS treats the user as the /.../cellname/hosts/hostname/self principal of the local machine; in this case, the root user receives the permissions associated with the machine's self principal, which is treated as an authenticated user from the local cell. If the user is also authenticated to DCE as root, DFS treats the user according to the DCE identity root. (Note that you do not have to be logged into the local machine as root to be logged into DCE as root.)

Note: The DCE identity root effectively has root privileges for data in all exported non-LFS filesets in the cell. The identity is very powerful and represents a serious security risk. Either use the DCE root identity very cautiously or disable it altogether.

· When accessing a file or directory via its local pathname, the root user has all of the privileges commonly associated with root. For local access, root can perform any file system operation on a file or directory; for example, root can change the UNIX mode bits of a file or directory, change the ACL permissions of a DCE LFS file or directory, change the owner or owning group of a file or directory, or create or remove a file or directory. (A file or directory in a non-LFS fileset can always be accessed via a local pathname because a non-LFS fileset must always be mounted locally, as a file system on its File Server machine; a file or directory in a DCE LFS fileset can be accessed via a local pathname only if its fileset is mounted locally.)

Being a member of the fxd administrative group allows you to perform any operation on a file or directory in an exported fileset, but you may have to change the file's or directory's protections first. Being logged into the local machine as root lets you perform any operation on a file or directory in a locally mounted fileset immediately, without first changing the protections. Being authenticated as DCE root lets you perform any operation on a file or directory in an exported non-LFS fileset immediately.

The File Exporter also manages the distribution of tokens to clients. It maintains an inventory of outstanding tokens, including the clients to which it has granted tokens, the data for which it has granted those tokens, and the type of each token it has granted. (A token's type dictates the operations that the client holding the token can perform on the data to which the token applies.) (See Data Access Management in DFS for more information about the File Exporter's token-management mechanism.) information"

The fxd process must be run on any machine used to export data to the global namespace. (See Part 2 of this guide and reference for complete information about the fxd process.)

The dfsbind process on a File Server machine maintains user authentication information required by the File Exporter on the machine. The File Exporter uses this information to ensure that only authenticated users access data from the machine. The dfsbind process must be run on any machine used to export data to the global namespace.

The dfsbind process must also be run on all client machines. Its role on client machines is described along with client machines and their processes in Client Machine Processes and Files. (See Part 2 of this guide and reference for complete information about the dfsbind process.)

The Replication Server, or repserver process, manages replicas of filesets on all File Server machines. Depending on the replication method in use, you either release a new version of a fileset for distribution by the Replication Server, or the Replication Server automatically creates replicas at specified intervals. Install the Replication Server on all File Server machines, which are the machines that can store read-only replicas of filesets. No administrative list is associated with the repserver process.

In addition, each File Server machine must have a server entry registered in the FLDB before it can house filesets. Each File Server machine can have up to four server entries, with each entry specifying a different host name or IP address. The server entry must exist before the fts create or fts crfldbentry command can be used to create an entry in the FLDB for a DCE LFS or non-LFS fileset from the machine. The following topic discusses server entries in more detail. (See Making Filesets and Aggregates Available for more information about creating server entries.)

A client machine can also be configured as a Private File Server machine to export data to the global namespace. (See Exporting Data from a Client Machine for more information about configuring a client machine to export data.)