Journal: LAN Technology March 1993 v9 n3 p51(9) * Full Text COPYRIGHT M&T Publishing Inc. 1993. ------------------------------------------------------------------------- Title: AFS: NFS on steroids. (Carnegie Mellon University's Andrew File System; Sun Microsystem Inc.'s Network File System)(includes related article about the Open Software Foundation's Distributed File Service implementation of AFS; another related article is about features of the Kerberos security system) Author: Cohen, David L. Abstract: Some users now favor Carnegie Mellon University's Andrew File Systems (AFS) distributed file system over Sun Microsystems Inc's Network File System (NFS), which has been the predominant system. NFS is deficient in some areas such as scalability and security. AFS, which was developed to deal with these problems, can improve a distributed system's performance, reliability, security and management. AFS is currently distributed exclusively by Transarc, which started shipping Version 3 in 1990 and the current version, 3.2, in Aug 1992. AFS is available for the following Unix machines: DEC's DECstation and VAXstation; HP's HP 9000 Series 300, 400, 700 and 800; IBM's RS/6000 and RT; NeXT's full product line; and Sun's Sun, 3, 4, SPARCstation and 600MP. A table is provided that compares NFS and AFS features and capabilities. ------------------------------------------------------------------------- Full Text: For many organizations, a distributed file behind their distributed computer systems. Sun Microsystems Network File System [NFS] is the predominant distributed file system in use today. However, the Andrew File System [AFS] developed by Carnegie Mellon University has robust features that are winning over NFS users. For the College of Engineering at North Carolina State University (NCSU), moving from NFS to AFS meant a boost in reliability, performance, security, and management of its distributed computer system. With more than 8,000 user accounts on 600 Unix workstations, and over 3,000 original mail messages and 7,000 printed pages generated daily on this FDDI backbone with 20 subnetworks, ease of support is critical. AFS provides this, as well as a first step toward the adoption of the Open Software Foundation's (OSF) Distributed File Service (DFS), which incorporates AFS functionality. NCSU initially ran NFS with the Kerberos security scheme when it set up a network of Unix workstations for engineering students in 1990. However, project leaders quickly decided that students needed more transparent distribution of files than NFS offers. One of the problems was that when an NFS server went down, the client machines that depended on that server for applications were stranded. Also, as machines were added to the network, NFS had problems keeping up with file access requests and began dropping packets. AFS was selected to overcome these problems. According to Bill Willis, the director of computing operations at NCSU, the number of dropped packets decreased by an order of magnitude after installing AFS. Reliability also improved. Ken Barnhouse, a system administrator, reported that an application server crash once went undetected for four hours. Users' application requests were automatically rerouted to what is called a replicate server, and network administrators only discovered the crash duffting a routine check of outputs from management utilities. The Contenders Introduced by Sun Microsystems in 1985, NFS has mushroomed in popularity, with versions available for most minicomputers, workstations, and personal computers. Digital Equipment, IBM, FTP Software, Novell, and others either developed their own version of this open standard or resell third-party packages to satisfy user demand for distributed file system capabilities. NFS uses a peer-to-peer networking scheme, in which individual workstations access or mount subdirectory trees that are exported by other machines, making these directories and files appear local to the machine importing or mounting them. As with many technologies, full-scale implementation of NFS magnifies known deficiencies and brings new ones to light. In the case of NFS, scale-ability and security are the major sore points. With significant backing from IBM, CMU developed AFS to address these and other NFS shortcomings. AFS (the commercial name) is now distributed exclusively by Transarc, which began shipping Version 3 in 1990 and the current revision, 3.2, last August. AFS is available for the following Unix workstations: Digital Equipment's DECstation and VAXstation, HewlettPackard's HP 9000 Series 300, 400, 700, and 800, IBM's RS/6000 and RT, NeXT's full line, and Sun's Sun 3, 4, SPARCstation, and 600MP. NFS and AFS differ in their architecture, reliability, performance, security, management and administration, backup support, and availability. These differences are summarized in the table and will be elaborated throughout this article. Currently, AFS is only available from Transarc. However, OSF, backed by a consortium that includes IBM, is incorporating AFS in the DFS component of the Distributed Computing Environment. DCE is an integrated set of tools and services for developing and running distributed applications. It includes machine-independent data representation tools, a remote procedure call facility and compiler, an authentication service, a network naming service, a network time service, and a distributed file system. (For more on the migration to OSF, see the sidebar "From NFS to OSF via AFS.") Degrees of Distribution NCSU opted to move to AFS partly because it is a more truly distributed system than NFS. Architecturally, NFS follows the client-server model more closely than the distributed model. Like a client-server database, NFS requires the user to specify what file he or she wants and where that file resides. Client-server databases, like NFS file systems, can reside on any node. However, since each database is completely contained on one host, it is said to be location-dependent. Users can access multiple databases and even link them together, but they must still know which machines to access. A true distributed database or file system is accessible from any client station. It is not dependent on any one host, since individual pieces can be spread across multiple machines and even replicated in places. A truly distributed file system has location transparency; users don't need to know where file systems or directory trees reside. In contrast to NFS, where users need to know the location of a file system before they can mount it, AFS combines all files into a single name space, independent of physical location. A user can log on at any station and be presented with the same global view. It's this use of a single name space that makes AFS location-transparent, allowing system administrators to move individual file subsystems without disrupting users. Because of NFS' location-dependence, moves cannot be made transparently. In addition, applications and system files on an AFS network can be replicated on read-only servers. When an application is installed or upgraded, it can be easily propagated to multiple read-only servers by using the AFS vos release command. If an AFS application server goes down, user requests for applications and system software that reside on that server are redirected to a replicate server. NFS does not have replication. To better understand the differences, let's look at how NFS and AFS handle file distribution in more detail. I'll use Unix terminology in these examples, but the commands and file names are similar in other operating systems. Note that both file systems employ the User Datagram Protocol/Internet Protocol (UDP/IP) as the communications mechanism. In NFS, a system administrator (or a user) determines which files on a server can be exported. An exported file system includes files in the named directory and all subordinate directories and files. You can only export local file systems. That is, a file system that has been mounted from a remote server cannot be re-exported. The administrator lists the exported file systems along with options that govern how the file system can be used (such as whether it is mounted as read-write or read only) in a file called/etc/exports. Remote file systems to be mounted locally (which can be thought of as file systems that have been "imported") are listed along with local file systems in a file called/etc/fstab. Local file systems are accessed using the syntax: device, mount point, and options. A device refers to the disk or disk partition where the file system is located. A mount point is where the file system, which can come from a local device or a remote file system, is grafted onto the local file system. To access a remote file system, users must indicate remote-host:exported filesystem instead of the device. The mount command is used to mount either all file systems listed in /etc/fstab or a specific file system. Typical fstab entries look like this: /dev/sdOg/usr/local 4.2 rw 13 /dev/sdld/usr/local/bin 4.2 rw 13 zippy:/home/zippy/home/zippy nfs rw, bg, hard 0 0 pooh:/home/pooh/home/pooh nfs rw, bg,hard 0 0 As you can see, to mount a remote file system under NFS, a user needs to know the name of the specific host. Throw in all the other files containing specific host information, such as /etc/hosts and/etc/networks, and you can see that moving a subdirectory tree to a different host is not a trivial matter. Not only does the administrator have to change the export files on the machines the files are moved from and to, he or she has to modify the fstab file for each workstation that had been mounting that file system. NFS has no restriction on what you use for the specific mount points. However, to give users a consistent environment, most NFS administrators try to standardize on mount points by setting up the same subdirectory structure across workstations and putting the same mount point for that file system in each workstation's fstab file. This lets a user go to another machine that has mounted the same file system and see the same directory structure as on his or her own machine. The key processes for NFS are the nfsd and biod daemons or processes. The nfsd process runs on a file server and is basically a listener that fields client requests for file access. Multiple copies of nfsd can run on a server. On the client, processes use remote procedure calls (RPCs) to access NFS servers. The biod daemon takes client requests for non-local files and puts them on the network. This daemon interacts with the client's buffer cache to achieve adequate throughput via. read-aheads and batched writes. On the management front, NFS sites typically manage common configuration files, such as/etc/hosts, with the Network Information System (NIS; formerly known as the Yellow Pages). NIS centralizes configuration files and eases management, but does not help with specific file management. In contrast to NFS, which has multiple name spaces associated with multiple file systems, AFS presents a unified name space or global file system. Thus, a user can sit down at any station on the network and be presented with an identical environment. AFS must be incorporated into the kernel of all AFS file server and client machines. On servers, AFS executables are installed in/usr/afs/bin and server configuration files are installed in /usr/afs/etc. AFS volumes on servers must reside on partitions associated with directories named/vicep?, where ? can be A through Z. Logical directories are associated with physical partitions in the/etc/fstab file. Since the/vicep? directions are not standard Unix directories, Transarc ships its own version of the Unix fsck utility. (This tool checks file system consistency.) In the AFS client, executables and configuration files are installed in/usr/vice/etc. Every AFS client must have a cache set up in memory or on disk. In AFS, a volume corresponds to an NFS file system. A volume is a set of related files grouped together based on a disk space unit. Volumes cannot span multiple partitions. For management purposes, system administrators typically use a relatively small volume size to facilitate the replication and migration of files to another partition. In AFS, servers and clients are grouped into administrative domains known as cells. Applications, executable files, and AFS databases are replicated on multiple file servers within a cell, and users can easily share information both within and between cells. At the top of the AFS directory structure is a global file system that Transarc maintains. This file system encompasses many of the sites that use AFS and lets participants remotely access a file system from another site. NCSU is one of about 60 individual cells that Transarc lists. These cells are subordinate to the top-level/afs directory, so cell names need to be cleared with Transarc. Since most AFS sites are on the Internet, cell names typically correspond to registered Internet domain names to ensure uniqueness. Transarc's root volume's CellServDB file maintains the IP addresses. Individual client CellServDB files list the IP addresses and names of the database server machines in the local and foreign cells that a particular AFS client wants to contact. Various AFS processes work behind the scenes on designated file servers to present this distributed environment. For example, the File Server Process handles file requests from clients and maintains the overall directory struc- ture. The Basic OverSeer Server Process, as its Big Brother-ish name implies, monitors server processes and can restart them as necessary. Volume moves, replicates, and backups are managed by the Volume Server Process. The Volume Location Server Process is responsible for location transparency. Authentication is the domain of the Authentication Server Process. The Protection Server Process maintains user and group access information and authorization, while the propagation of application and system software updates to replicate servers is handled by the Update Server Process. Transarc divides files servers within cells into four distinct roles. The System Control Machine maintains information for all file servers in a cell. At least one file server runs the four AFS database processes (Authentication, Protection, Volume Location, and Backup Server), but Transarc recommends three or more file servers host these tasks. For each different type of computer (such as a SPARCstation or a DECstation) in a cell, a Binary Distribution Machine is required to distribute software to that specific class of machine. Finally, Simple Server Machines run only the basic File Server and Volume Server processes. At NCSU, file servers are further categorized into those with operating system-related files and user-related files. Of NCSU's 35 servers, 10 handle user home directories, 18 are used as binary servers for operating system files and third-party packages, and the remainder serve as department-specific servers. To simplify file access, administrators or users at NCSU use a program called attach, from MIT, to map volumes to a shorter name space. For example, if a user wants to access a mathematics package called matlab, typically the user would need to provide the path: /afs/eos. ncsu. edu/dist/matlab where afs represents the Transarc root directory, eos.ncsu.edu is the cell or site, dist is a directory within that cell, and matlab is the directory for the math application. Using attach, the path becomes/ncsu/matlab. Figure 1 Illustrates the AFS structure implemented at NCSU. You can use NIS as a name server for AFS but most sites, including NCSU, use the Berkeley Internet Name Domain (BIND) server to maintain a database of name information. The BIND tool comes with the standard BSD Unix distribution. A Question of Reliability AFS is more reliable than NFS because copies of applications and AFS databases can be replicated on multiple file servers within a cell. These replicates eliminate the single point of failure frequently seen on NFS networks. If an NFS file server containing applications goes down, then some block of client workstations is unable to access its applications. In AFS, a problem with a primary application server causes attached clients to be switched to a replicate, with only a minor delay. By using replicates to spread out the load of file system requests, AFS also eases the problem of dropped packets. In NFS, multiple nfsd daemons on a machine all retrieve client requests on the same UDP socket, which is an access point or a "listener" process. UDP sockets have limited buffer space, so a surge in requests can lead to overflows. Increasing the number of nfsd daemons helps to a point, but running too many degrades NFS performance due to context switching and scheduling overhead. AFS replicates lessen the importance of choosing the correct number of processes to listen on a UDP socket. A Better Performer Although third-party products can enhance the performance of NFS, I have concentrated on the base capabilities of NFS and AFS. Robust caching is the key to AFS's superior performance. When a non-local file is accessed, the requested portions of the file are retrieved in 64-Kbyte chunks and stored locally (on disk or in memory). Initial access of network applications is slower, but subsequent invocations run at local workstation speed. AFS's callback facility helps reduce LAN traffic as well as maintain cache consistency. With callback, an AFS server notifies clients when a file system they're caching has been changed. The next time a user accesses the file on the client, the cache manager knows to refresh its cache by reading the most recent copy of the file from the server. In comparison, NFS caches are similar to traditional Unix buffer caches, which are simply portions of memory reserved for recently accessed file blocks. Normally, NFS reads and writes data in 8-Kbyte chunks. Data validity is maintained via the file attributes, such as date of last access and file modification time, which are cached on the client and generally refreshed from the server every 60 seconds (although this refresh time is configurable). If some file attribute information changes, an NFS process knows it needs to refresh the block of data it has read. The file modification time determines if the cache must be flushed and the file re-read. This process causes traffic on the network, since clients must get file attribute refreshes at regular intervals. However, if a user is accessing an application, this refresh is unnecessary. Unlike AFS, the NFS process introduces the possibility of a client having out-of-date information. Shorter refresh periods reduce the danger of stale information, but dramatically increase the request load on the server, which can result in dropped packets. Both NFS and AFS clients perform asynchronous writes back to the server, but the larger buffer size blunts the impact with AFS. Use of a large buffer results in fewer network messages, and thus less network overhead. For example, writing one 32-Kbyte block is faster than writing four 8Kbyte blocks. The combination of a small buffer size, limited caching capability, and constant attribute cache updates puts a lot of strain on an NFS server, making wide area access prohibitively slow. Conversely, large buffers, significant caching capability, and server callbacks make life easier for AFS servers, allowing for excellent wide area access over T1 lines. Figure 2 contrasts the AFS and NFS caching approaches. In this scenario, a student first browses, then prints, a file containing class notes. In between the student's browsing and printing, the teacher updates the notes on the file server. With NFS, the student may end up priming the older information. Under AFS, the student prints out the updated class notes. While Transarc recommends 20 Mbytes of disk space per AFS client, NCSU uses 25 Mbytes or more. Transarc recommends 25 Mbytes or more of disk space for file servers, depending on their role. NFS requirements vary widely due to the diversity of implementations, but they are much lower due to NFS's primitive caching. AFS and NFS both support diskless clients but, since they place large demands on the network, NCSU shuns them. For better performance, NCSU installed AFS database servers on dedicated CPUs. Suddenly users could no longer reach file servers. Transarc helped NCSU administrators determine that the problem was related to backward compatibility with previous versions of AFS. It turned out that even though AFS maintained all system information in the databases, requesting processes looked for file servers instead of querying the Volume Location Process on the database servers. Until Transarc fixed the problem, NCSU worked around it by configuring database servers as both database and file servers. While replicates are mainly an AFS reliability feature, they also aid performance by reducing UDP socket activity on a given server. Performance can be further improved by configuring clients with server preference lists. NCSU buys applications with network licenses. Each client has a list of application servers it would prefer to access, based on where that server is located on the network. For example, a client typically would prefer to access an application server on the same LAN segment rather than traverse a router. AFS originally used random server access, but in Version 3.2 Transarc introduced a preference scheme that uses network addresses. Currently, AFS supports up to six read-only replicates of a single read-write volume. Support for more replicates is planned for the next release. In the meantime, NCSU administrators have implemented two read-write servers in some instances in order to increase the number of replicates to 12. This requires additional management, since they have to update two servers with new software releases. Security Muscle AFS gets its security edge through its integration with Kerberos. Although NFS can operate with Kerberos, it takes considerable effort to integrate. (For more on Kerberos, see the sidebar "Kerberized Services.") Kerberos uses network-wide passwords and requires clients to obtain tickets, which are a type of access key conveyed in messages, in order to access services. Typically, NFS systems use NIS to maintain a network-wide password file. However, trusted hosts and users are frequently employed by remote users as a means to access servers. (A trusted host has a trustworthy system administrator who won't let his or her machine masquerade as another host.) A user from a trusted host can access resources on another host, if the user has an account on both machines, without entering a user name and password. While this makes casual access easy, you must be able to trust the other systems and take steps to prevent one system from masquerading as another. In NFS, the/etc/hosts.equiv and . rhosts files in user home directories contain hostname or host-user pairs, for example pooh and zippy davec. This host trusts all users on host pooh and user davec on host zippy. Trusted hosts and users should be used cautiously, as they present large security gaps. For example, by changing the IP address and host name, an administrator on a single machine can make that machine look like one that has trusted host status. Similarly, an administrator can "become" a user who has trusted user access on another machine. For this reason, many sites have switched to a Kerberized NFS. AFS's use of protection groups for security is a significant advantage over NFS. A protection group is a set of users with common access rights to specific groups of files. These groups can be set up by anyone. While Unix lets you establish groups, you need system administrator rights to set them up and maintain them. In AFS, protection groups are generally created and maintained by users. At NCSU, the faculty sets up protection groups based on class members. To prevent name conflicts, a protection group name is prefaced by the creator's user name, such as davec:sysadm. Here, user davec created protection group sysadm. In AFS, access control lists (ACLs) apply to individuals or groups and support the following rights: read, lookup, insert, delete, write, lock, and admin. This is a major improvement over the standard Unix chmod command used in NFS, which only offers read, write, and execute. Currently, AFS access control is applied by directory only, while Unix rights apply to files and directories. Another security issue arises from the Unix root user and setuid programs. On a Unix system, the root user has access to everything on that workstation, since root defines a superuser. A setuid program can change its identity to become anyone else. Many Unix utilities, including mail and the lpd print spooler, require superuser rights to get at files they need. Some of the programs that comprise the standard Unix mail processes must run with setuid privileges in order to create files accessible by specific users. The lpd program typically would setuid to root to access the files it needs. On a distributed system, the superuser on one machine has no special rights on another machine. Since root does not operate across multiple machines, utilities that rely on root and setuid will not work across the network. NFS gets around this problem with trusted host operation, where root can run the printer and mail processes on another machine. This solution poses security risks and isn't possible under AFS and Kerberized NFS because Kerberos doesn't allow for the use of trusted hosts. To get around the difficulties posed by root and setuid programs, AFS users need to look to third parties. NCSU administrators tackled the mail problem by using a Kerberized post office protocol (pop) mail server from MIT. Using a pop mail server, clients access a central mail hub to retrieve messages. This scheme is familiar to those in the personal computer world, but most Unix systems use mail facilities that route mail between machines. Management Styles NFS and AFS have different administration and management tools as well as different backup systems. NFS file servers have several mechanisms for tracking mounted file systems. The exports utility maintains the/etc/xtab file, which lists exported file systems. The mountd daemon on the server notes client mount requests in the /etc/rmtab file, and administrators can retrieve the information with the show-mount utility. On clients, the/etc/mtab file lists file systems currently mount request in the client. (/etc/fstab, discussed earlier only lists those file systems the system, administrator has specifically indicated can be mounted.) Clients can review currently mounted file systems with the df utility. NFS file access statistic are available via nfstat. For clients, this utility shows aggregate server access statistics; for servers, it shows aggregate client access statistics. In AFS, the administration commands most commonly employed by users and administrators are: fs -- for file-related activities such as set access control, check quota, and get current server pts -- for group-related activities such as create groups, set group access, and add users to groups vos -- for volume-related activities such as create/destroy/update volumes and mount and examine volumes bos -- for server-related activities such as bring servers up and down and view server status and logs AFS also includes the following management utilities and tools: Scout, the Backup System, uss, Package, and Ubik. Scout probes AFS file servers, collecting load statistics, flagging unresponsive servers, and alerting administrators when a server parameter exceeds a predetermined threshold. The Backup System backs up volumes to tape in groups called volume sets. During backup, volume sets are "cloned," then backed up, allowing the file system to remain available. Clones also allow users to retrieve files they inadvertently deleted, as the clone of the user's volume appears under a .Old subdirectory in the user's home directory. The clone contains a reference, like a Unix hard link, to each file in the read-write volume. (With a hard link, a user can create a file called X and a link to that file called Y. If the user deletes X, the file still exists and can be read through Y.) When a file in an AFS read-write volume is deleted, the done volume's reference preserves the file until the volume is re-cloned. The AFS Backup System also has a mechanism for storing and retrieving volumes on tape. This system and its database of tape history were recently integrated into the AFS distributed database scheme. However, the AFS backup process requires human interaction, since it cannot be pre-scheduled to launch. This is a disadvantage compared to the standard Unix dump and restore scripts, which can be launched by cron, a program for scheduling other processes. To get around this shortcoming of the AFS backup scheme, NCSU uses a utility developed by the University of California at Berkeley that stores a set of keystrokes, so it can be used to launch a backup. NCSU doesn't use the .Old cloning facility because it can require considerable disk space. Thus, in order to restore one file from tape, the entire backup volume must be mounted and the file moved. To ease backups and restores, NCSU administrators limit the size of volumes so that the typical user volume is 5 Mbytes. The only backup advantage NFS offers over AFS is its ability to restore individual files; AYS requires that a whole volume be mounted. NFS backup systems are frequently just shell scripts cobbled together around the Unix dump and restore commands. The uss tool lets AFS administrators add users to the system via templates they create, and a bulk feature lets administrators create a large number of accounts at once. In contrast, NFS relies on NIS to maintain system-wide user name databases. The AFS Package tool performs client maintenance tasks and installs AFS on client machines using predefined configurations that require the administrator to change only a few parameters, such as machine-specific values. Finally, Ubik is a library of utilities that AFS database servers use to keep the individual copies of their databases synchronized. Ubik is a sub-process within the Authentication, Protection, Volume Location, and Backup processes. Primary copies of the four system databases are located on a server designated as the synchronization site, and secondary databases are updated when the primary is changed. AFS Strengths Based on NCSU's experience, Unix networks running AFS require minimal support. Ten people, including a secretary, are responsible for more than 8,000 accounts and 40 Gbytes of disk space. Unlike NFS' inscrutable uid-based disk quotas for users, AFS disk quotas are based on volumes and are easily reviewed by users. At NCSU, two support people handle hardware and two others take care of the operating system, file system, and security. Two more manage the 30plus applications. The NCSU team can have a workstation up and running on the AFS network 20 minutes after the hardware is set up, thanks to customized bootstrapping and configuration software engineered by Bobby Pham, the principal systems programmer. Responsibility for printers and printing is farmed out to a local service firm. Although NCSU has deployed mainly DEC workstations, some IBM, Hewlett-Packard, and Sun machines also exist on the network. When dealing with a heterogeneous environment, AFS clients use a file to point to the machine architecture. NFS also supports mixed environments, but because so many vendors have done their own implementations, you must take care when setting up NFS in a heterogenous environment. An important advantage of NFS over AFS is NFS's support for Intel-based and Macintosh clients. To incorporate these NFS clients into an AFS network, a Unix machine must be configured as an NFS server and run Transarc's NFS/AFS Translator. The key contribution AFS has made at NCSU is that students can sit down at any workstation and be presented with the same environment. System administrator Barnhouse refers to this as "wherever you go, there you are." This concept extends into management, as RPC-based administrative commands can be issued from any workstation, given appropriate access rights. NFS blazed a trail for distributed file systems, but its age is showing. Today's large, interconnected networks are constrained by NFS's performance bottlenecks and weak security. System administrators must work magic with piecemeal management tools. NFS's problems and patches were duly noted by CMU developers as they developed the Andrew File System. With Kerberos security, file location transparency, and powerful management tools as integral components, AFS represents a clear evolution for distributed file systems. Transarc's commercialization of the CMU offspring spawned wider use of AFS. Over the past three years, AFS has been installed in 250 sites, with 55 percent of these commercial, 35 percent educational, and 10 percent government sites. Roughly 80 percent of AFS installations are in the United States. OSF's adoption of AFS as the file system component of DCE will spur even greater acceptance of this technology. Although NFS is still the overwhelming choice for distributed file systems for Unix networks, look for AFS (and its DCE incarnation) to muscle its way into the market. Acknowledgments Bill Willis, the director of Computing Operations at NCSU, deserves credit for pushing a project with tremendous promise. He introduced me to the project and made personnel available for assistance. Ken Barnhouse gave me an in-depth look at AFS in action, while Bobby Pham, the principal systems programmer for the project, clarified technical details and took on the proofreading chores. Elaine Wolfe in marketing services and Kathy Rizzuti in product support at Transarc managed to block out the product blitz long enough to feed me technical literature and answer questions. Finally, Hal Stern's book, Managing NS and NIS (O'Reilly and Associates), proved to be a comprehensive resource. From NFS to OSF via AFS In May of 1990, the OSF selected technology submitted by Transarc for inclusion in the DFS component of DCE. As a result, AFS-based DCE will be available from all OSF vendors, with initial implementations due out by mid-year. To help port applications to DCE, Transarc is shipping a DCE Developer's Kit. The company also announced plans to deliver a production-quality DCE for Solaris 2.0 on Sun workstations this year, Transarc is positioning AFS Version 3 as a migration path to DCE. Architectural components, tools, and user commands will be similar. In particular, Transarc claims that system managers can make decisions based on AFS that apply to DCE in the following areas: hardware and software purchases, machine allocation (that is, machines needed for specific tasks), user disk quotas, security policies, and system administrative staffing. Once DCE is widely available, Transarc will discontinue selling AFS. The key differences between the stand-alone version of AFS and its DCE implementation are that the DCE version will support technologies that interoperate with other DCE components. For example, AFS implementation in DCE will support a journaling, high-performance file system called the Local File System. LFS is based on Transarc's Episode product. Also, automatic periodic updates of replicates will be supported in the DCE implementation. In addition, access control will be possible at the file level, rather than just the directory level. The DCE version of AFS will also support OSF components such as the Remote Procedure Call (RPC) facility, the Global Directory Service (based on X.500), and the Distributed Time Service. Transarc will offer an AFS 3-toDCE DFS Migration Toolkit to help customers move to DCE. The toolkit permits interoperability between AFS systems and systems that have been converted to DCE. It contains three primary components: a tool for transferring account and group information, a tool for converting files, and a tool for interoperability. On the other end of the spectrum, companies can ease the transition from NFS to AFS with Transarc's NFS/AFS Translator. The translator, installed on an AFS client, lets unmodified NFS systems access files stored in the AFS name space. ln effect, the AFS client becomes an NFS server. The translator is particularly valuable for machines such as IBM PCs and compatibles and Macintoshes, as these platforms boast numerous NFS solutions but are not supported under AFS. The NFS/AFS Translator thus becomes a key stepping-stone in a company's migration to AFS. However, potholes mar the road to OSF. The absence of a translator between NFS and DFS threatens to leave IBM PCs and Macintoshes by the wayside. Transarc indicated that a translator wouldn't lag too far behind early DCE releases. If you're thinking of skipping the translation stage and migrating your personal computers right to DCE, brace yourself for steep CPU, memory, and disk space requirements. (You'll need an 80486-based machine with at least 16 Mbytes of RAM and upwards of 100 Mbytes of disk space, depending on the number of DCE components installed.) Gradient Technologies has announced DCE for PC DOS and Siemens Nixdorf is working on an IBM PC version of DCE. OSF has reportedly had discussions with Apple concerning a Macintosh implementation. Kerberized Services Part of MIT's Project Athena, Kerberos was named after Cerberus, the three-headed dog that guards the entrance to Hades in Greek mythology. Like Cerberus, Kerberos' job is to prevent unauthorized access -- in this case, to Unix services. (The goal of Project Athena was to design a network that would run local applications while being able to call remote services. In addition to Kerberos, Project Athena spawned the X Window System and other Unix systems and tools.) Kerberos assumes it is operating in a distributed environment characterized by unsecured workstations, moderately secure servers, and secure Kerberos key distribution machines. The two mechanisms used to ensure security are tickets and authenticators. A ticket is a message used to obtain a temporary session key and to ensure the identity of the requester. An initial ticket is even required to obtain tickets for other services. The authenticator validates the identity of the requester. When a client (user or application) logs on to a system, a ticket request is sent to the Kerberos server. The Kerberos server issues a ticket, which the client then presents to the ticketgranting server (TGS) in order to obtain tickets for other servers. This initial ticket, known as the ticketgranting ticket, is encrypted with a key known only to the Kerberos server and the TGS. For additional security, the ticket expires at the end of a specified time, usually between eight and 24 hours. A dient must obtain a ticket from the TGS for each service to be used. The request to the TGS includes the server required, the ticket-granting ticket, and an authenticator. The authenticator is part of a message built by the dient; it contains some client information that is also in the ticket-granting ticket and is used to verify that the client is who he says he is. A client must create a new authenticator prior to every service request. The ticket the TGS returns is encrypted with the requested server's Kerberos key. Finally, the ticket and a new authenticator are sent to the server the client wants services from. The server decrypts the ticket, verities the ticket information against the authenticator, and, if everything checks out, grants the request. Kerberos plugs a number of security holes, but still requires a secure server and private passwords. In addition, a service's source code must be modified to use Kerberos. Fortunately, more and more network services are being Kerberized, giving you the equivalent of a three-headed dog to protect your Hades...er, network. ------------------------------------------------------------------------- Company: Sun Microsystems Inc. Transarc Corp. Product: AFS 3.2 Network File System Topic: Carnegie-Mellon University File Management Distributed Processing Network Software Communications Software Comparison Record#: 13 620 603. *** End ***