New features for the Windows Clients ------------------------------------ This file describes new features that have been added to the Windows AFS clients. DNS lookup ---------- DNS lookup of cell servers is now available for the Windows AFS clients. A type 1 AFSDB record is queried to determine the cell server host names. These names are then resolved to IP addresses. 1. Usage This feature is enabled at compilation with the switch "AFS_AFSDB_ENV", as with the Unix clients. It is activated by default, and can be disabled at runtime by running afsd.exe with the -noafsdb flag for the Win9x client, or by setting the following registry entry on the NT/2000 client: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters\UseDNS=0 The Windows AFS clients use a configuration file named afsdns.ini (stored in the same directory as the cell server database) to determine the address of the DNS server. This file has the following format: [AFS Domain Name Servers] ns1=xx.xx.xx.xx Only one name server is actually used currently. Support for multiple name servers should be easy to add. 2. Design Because of the lack of standard resolver libraries on the Win32 and DJGPP platforms, it was decided to perform DNS queries by manually creating packets to send to the DNS server. The DNS response is then decoded to determine the correct cell server addresses. New files: WINNT/afsd/cm_dns.c WINNT/afsd/cm_dns.h WINNT/afsd/cm_dns_private.h Changed files: WINNT/afsd/cm_config.c WINNT/afsd/cm_cell.c WINNT/afsd/cm_ioctl.c WINNT/afsd/afsd_init.c WINNT/afsd/afsd_init95.c auth/cellconfig.c kauth/user_nt.c 3. Future work Support for multiple DNS servers Support for resolver libraries, if available for DJGPP and/or Win32 Freelance AFS Client -------------------- 1 Introduction The current implementation of AFS requires that all AFS clients belong to a home cell. The home cell provides the client with a starting point to mount the entire AFS file system. The client's top most level view of AFS is determined by the home cell server's root.afs volume. Through root.afs, the home cell also controls which cells clients can access. To provide a more flexible and relevant view of the AFS file system to the user, this projects aims to remove the need for a home cell and to allow each client to customize its view of the AFS file system. To this end, the current Windows 2000 and 9x clients for AFS have been modified into a Freelance AFS Client that allows the user to mount and dismount AFS cells at will, without the need of a home cell. The new Freelance AFS Client also increases the scalability of the AFS file system since administrator intervention is no longer required for clients to access newly established cells. It also removes the client dependency on the availability of the home cell. Previously, if the home cell were not available, clients would not be able to access the AFS file system. This critical dependency is not present in the Freelance AFS Client. 2 Usage The Freelance feature is available only for the Windows NT/2000 and 9x clients. In 9x, it can be enabled by running afsd.exe manually with the "-freelance" flag. It can be enabled in NT/2000 by setting the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters\FreelanceClient=1 (GUI support to activate this feature will be available soon.) The Freelance client reads the available mount points from a file called afs_freelance.ini. This file will be created if not found and the list of mount points will initially be empty. New mount points can be added using "fs mkmount" or the Explorer shell extension. Specification of a home cell is unnecessary with the Freelance client itself, but is still needed by programs such as klog and pts to provide a default cell argument. 3 Design This section describes the design approach and provides a high-level description of the project. 3.1 Design Approach The main aim of the project was to shift the client's view of the AFS file system, root.afs, from the home cell onto the client, and thus eliminate the need for a home cell. This had to be done while maintaining compatibility with the existing system, so changes to the client were kept to a minimum. My primary approach has been to trick the current system into thinking that there is still a home cell by while feeding it fake information that is generated from a locally stored root.afs directory whenever root.afs of the home cell is requested. This is accomplished by intercepting function calls that fetch data from root.afs on the home cell. 3.2 Afs_freelance.ini The local version of root.afs is represented by a file named afs_freelance.ini, typically stored in the same directory as the cell database. The first line of this file is an integer that specifies the number of mount points there are in this file. The rest of the file is a list of entries, one on each line, in the form xxx#yyy:zzz, where xxx is the name of the mount point, yyy is the cell name and zzz is the volume name. 3.3 Directory File Structure Using the data in afs_freelance.ini, a fake directory is created in memory that is identical to what an AFS directory containing those mount points. This fake directory is then fed to the client when necessary. The structure of the directory is as follows: 1. Each directory is made up of pages, each of a fixed size. 2. Each page is divided into 32 byte chunks, which are indivisible units. 3. The first 13 chunks of the first page, called the directory header page, are used for header information. 4. The first chunk of all other pages, are also used for header information. 5. Chunks other than those reserved for header information can be used to store mount points. Mount points are stored in a struct defined as such: typedef struct cm_localMountPoint { char* namep; char* mountPointStringp; struct cm_localMountPoint* next; } cm_localMountPoint_t; 3.4 Adding/removing mounts The fs commands "mkmount" and "rmmount" can be used to add/remove mount points from the afs_freelance.ini file. These functions can also be accessed from the Explorer shell extension. 4 Implementation 4.1 Files Changed/Added Most of the changes have been made in 5 files: afsd_init.c cm_callback.c cm_dcache.c cm_scache.c cm_vnodeops.c Afsd_init.c was changed to include initialization code for the fake directory and local mount points. Cm_callback.c was changed to handle callbacks to /afs differently, since it is now local. Cm_dcache was changed to feed fake information into buffers when the /afs directory is read. Cm_scache.c was changed to provide fake scp information for the mount points found under /afs. Finally, cm_vnodeops.c was modified to make the function trybulkproc skip the fake directory entries. In addition, the following files were added: cm_freelance.h cm_freelance.c Cm_freelance.h and cm_freelance.c were added to provide functions that create and handle the fake directory and fake mount points. 4.2 Functions Modified Below is a list of the functions that have been modified. The list is not exhaustive but includes most of the major changes. 4.2.1 afsd_InitCM Several lines of code were added to this function to call the initialization functions for the fake directory and fake mount points. 4.2.2 cm_HaveCallback This function is called to check if files have changed. The /afs directory and mount points on /afs need to handled differently by this function. In particular, whenever this function is called on mount points on /afs, the function needs to always return true. This is because local mount points are only added or removed, never modified. 4.2.3 cm_GetCallBack Because of the same reasons as in 4.2.2, this function needs to handle /afs differently. This function should never be called on the local mount points since the cm_HaveCallBack function always returns true on local mount points. When this function is called on /afs, we need to load the status information of /afs if it is the first time that /afs is accessed since initialization of the fake directory. Otherwise, we simply return. 4.2.4 cm_GetBuffer This function is used to fetch actual data from a file into memory buffers. When this function is called on /afs, we need to fill the memory buffers with data from the fake directory created in memory, rather than by calling server functions. 4.2.5 cm_GetSCache This function is used to fetch meta data about files. When it is called on /afs, we return a hardcoded scache structure. When it is called on the mount points on /afs, we return fake scache data based on the mount points in afs_freelance.ini 4.2.6 cm_SyncOp This function was modified to skip cm_HaveCallback and cm_GetCallback calls on the mount points on /afs. 4.2.6 cm_MergeStatus This function was modified to provide fake status data on /afs. 4.2.7 cm_TryBulkProc This function was modified to skip operations on fake mount points. 4.3 New Functions 4.3.1 cm_InitFakeRootDir This function uses the array cm_localMountPoints and creates in memory an image of a fake directory. This directory is then used to fill buffers when read requests of /afs are made. 4.3.2 cm_getNoLocalMountPoints This function returns the number of mount points on /afs, based on afs_freelance.ini. 4.3.3 cm_InitLocalMountPoints This function reads afs_freelance.ini and creates an array of fake mount points based on its contents. The array is then used by cm_InitFakeRootDir to create a fake directory in memory. 4.3.4 reInitLocalMountPoints This function clears all the fake information in memory and reconstructs them from afs_freelance.ini. 5 Current Status This feature is still experimental. Please post problem reports to the openafs-devel mailing list. 5.1 Future Work GUI support for activation of the Freelance feature will be available soon. An auto-mount function could be added. This would work by intercepting the cm_lookup call so that when a cell is not found in /afs, it would be automatically added. Support for Unix clients.