This page was last updated 09/16/11
Organizations that rely on OpenAFS for Windows are encouraged to financially support its on-going development. For the most part, all of the small projects that can be done in a few hours time have all been addressed. What are left are larger more strategic projects which can only be accomplished by dedicating the appropriate developer resources. Organizations do not have to pay the full cost of these projects by themselves. Secure Endpoints Inc. will co-ordinate contracts with multiple organizations in order to distribute the cost. Please send e-mail to openafs@secure-endpoints.com with questions, feedback, or offers of support
The AFS Client Service has come a long way in the last three years. For a summary of the progress please read the latest OpenAFS for Windows Status Report. Still, there are many things that can be done to improve the user experience and performance of the product.
Microsoft Windows users are used to the "Windows Offline Folders" functionality which permits them to synchronize local copies of files or folders from a CIFS server to their local disk for use when disconnected from the network. UMichigan long ago implemented a read-write disconnected mode for the UNIX AFS client which permits users to continue using data within the AFS cache while in an offline mode. Once the client is restored to an online state the modifications made to the cache buffers are written back to the file server provided that there are no conflicts. If there are conflicts a manual conflict resolution process must be initiated.
Implementing disconnected operations requires much more than just making the contents of the AFS cache available. Many issues affecting the end user experience must be addressed.
Estimated implementation time: TBD
The OpenAFS cache manager on Windows uses a single memory mapped paging file as the cache. This imposes a couple restrictions. First, on 32-bit operating systems the cache cannot be larger than the largest contiguous memory address region which is typically between 650MB and 1.2GB depending on other software packages that have been installed. Second, as the paging file is memory mapped into the afsd_service address space, there is no mechanism by which the virtual memory associated with the service can be limited without reducing the overall cache size.
The goal of the second level cache architecture is to provide an open plug-in interface by which third parties can implement their own second level cache. This would permit afsd_service to limit use of the paging file for file/directory status objects, volume metadata and the active working set of file contents. When a cache miss occurs in the paging file, a call would be issued to the second level cache implementation. Only if the second level cache does not hold the required data would the file server be contacted.
By producing an open interface, the second level cache could be implemented as a distributed peer-to-peer cache within a local area subnet as opposed to a single local file cache.
Estimated implementation time: TBD
The existing AFS Shell Extension adds an "AFS" menu when the current folder or selected objects exist within the AFS name space. This menu is a hodge-podge of items. A few of the items appropriately belong on a context menu but are in the wrong place and most of the items should be Property sheets or should display the information to the end user in a different manner. The following is a proposal for a replacement.
OpenAFS should provide a custom column handler to introduce several new detail columns that would display additional information about objects within AFS. For example, columns can be provided to optionally display and perhaps edit:
Estimated implementation time: 18 to 24 hours
Instead of the existing handler that simply adds an "AFS" menu containing everything, the new handler will selectively modify the existing context menu's behaviors when the current folder is located within AFS.
Estimated implementation time: 12 to 16 hours
A variety of property sheets will be added. Some will be context sensitive and others will be general tools.
An "AFS File" sheet
An "AFS Mount Point" sheet
An "AFS Symlink" sheet
An "AFS Volume" sheet
An "AFS ACL" sheet
For any given item the "AFS ACL", "AFS Volume", and "AFS Directory" sheets will be added to the Properties dialog. The "AFS File", "AFS Symlink", and "AFS Mount Point" sheets will be added when an item of that type is selected.
Estimated implementation time: 60 to 80 hours
An AFS Tool Band will provide graphical shortcuts to:
Estimated implementation time: 12 to 16 hours
A tool tips handler provides support for additional information about an object when the user hovers the mouse over the object. Tool tips could be used to display the destinations for symlinks and mount points.
Estimated implementation time: 12 to 16 hours
A metadata handler can be used to provide enhanced information about selected objects with the "Details" box within the Folders view.
Estimated implementation time: 18 to 24 hours
The Explorer Shell namespace can be extended by providing a plug-in to Windows Explorer called a Shell Namespace Extension. These extensions create a virtual namespace within Windows Explorer and have full control over how the namespace is rendered to the user. A new namespace can be attached to the current Shell namespace as a child of an existing namespace, including file system folders allowing the user to navigate to the new namespace.
Estimated prerequisite implementation time: 62 to 108 hours
The number of volumes in typical cells for large organizations are frequently counted in the tens of thousands. The Recent name space will show users the most recently accessed volumes from which file data was either read or written. Users will be able to pin volumes within the name space and can easily map drive letters to any listed volume. Volumes are represented as shortcuts. Opening an entry in this name space will redirect the user to a permanent path that can be accessed by applications.
Estimated implementation time: 45 to 72 hours
A name space extension can be developed for individual cells which will dynamically select the user's personal volume based upon the Kerberos principal name stored in the AFS token used to access the cell.
Each organization develops their own layout for volumes in their cell which are frequently based around users, projects, groups, departments, classes, etc. When there are thousands of volumes within each category it can often be challenging for end users to find the particular data they are searching for. The AFS Name Space extension permits custom name spaces to be defined which can be used to assist end users in finding the volumes that most interest them.
Once
a volume is selected, drive letters can be conveniently mapped.
Estimated implementation for first organization: 220 to 334 hours
Subsequent organizations: 70 to 100 hours (includes custom installers and organization specific deployment guide)
The existing control panel provides a mixture of functionality related to the logged in user as well as the system-wide configuration of the AFS Client Service. Configuration of the AFS Client Service should require administrative access which should not be available to all users. To improve the user experience, the control panel should only contain functionality that is applicable to the user. All of the administrator privileged functionality should be moved to the Microsoft Management Console. Microsoft Windows Vista will enforce this functional split by preventing processes from starting with administrative privilege even when the user is an "Administrator" unless the user explicitly grants the permission. Separate processes that run only with Administrative privilege must be created when changes to the machine or service configuration is required.
Therefore, the new OpenAFS Control Panel will only provide the following functionality:
The AFS Group Editor will provide all of the functionality of the pts command line tool. Shortcuts to this panel will accessible from the AFS Explorer Shell Extensions.
Estimated implementation time: 36 to 48 hours
This panel will duplicate some of the configuration capabilities of Network Identity Manager and permit the user to select which Network Identities will be used to obtain tokens for which cells.
Estimated implementation time: To be determined
A shortcut to start the OpenAFS Client Service MMC Plug-in will be provided if the user has administrative privileges.
Estimated implementation time: 2 to 3 hours
The Microsoft Management Console (MMC)has become the standard for configuring policy for Windows Services. The AFS Client Service is highly configurable and yet only a small fraction of the options can be adjusted via the existing AFS Control Panel. The majority must be set by manually adding or modifying registry values. The list of registry values used by OpenAFS for Windows is documented in Appendix A of the Release Notes.
The MMC will also provide access to:
This project is being worked on by Brant Gurganus. See the project web site. http://code.google.com/p/openafsclientmmc/
Microsoft Vista's User Account Control requires that privileged operations such as starting or stopping services or modifying machine configuration cannot be performed by processes that are executed as normal users. This requires that the Network Identity Manager AFS Provider configuration page be modified to remove the privileged operations and provide a privileged access method to the Microsoft Management Console.
Estimated implementation time: 2 to 3 hours
As of the 1.5.25 release, the AFS Servers essentially work on Microsoft Windows provided that they are manually configured. The AFS Server Configuration Wizard can be used provided that nothing goes wrong during the initial configuration. Unfortunately, the wizard is not very robust and cannot be used to resume an install after an error condition has been corrected. Regardless, the wizard makes a number of assumptions about Microsoft Windows and the AFS client that no longer hold true. In addition, the salvager is known to crash. As a result its use is strongly discouraged.
The long term goal of this project is to develop and distribute AFS Servers that can be deployed on Microsoft Windows Server and that will integrate well into the Active Directory environment. There are several sub-projects that must be achieved:
Estimated implementation time: 640 hours.
Send additional feature requests to openafs@secure-endpoints.com.