From 9e68fba8475a84acc0aadece40cb9d74ac7ebfb2 Mon Sep 17 00:00:00 2001 From: DerrickBrashear Date: Tue, 29 Jun 2010 14:29:38 -0700 Subject: [PATCH] attachment upload --- AFSLore/FurtherReading/NFS_on_steroids.txt | 731 ++++++++++++++++++++++++++++ 1 files changed, 731 insertions(+), 0 deletions(-) create mode 100644 AFSLore/FurtherReading/NFS_on_steroids.txt diff --git a/AFSLore/FurtherReading/NFS_on_steroids.txt b/AFSLore/FurtherReading/NFS_on_steroids.txt new file mode 100644 index 0000000..b0a305a --- /dev/null +++ b/AFSLore/FurtherReading/NFS_on_steroids.txt @@ -0,0 +1,731 @@ +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 *** \ No newline at end of file -- 1.7.1