Secure Endpoints Inc. 255 W 94th Street 6B, New York NY 10025


This page was last updated 05/13/2014

OpenAFS for Windows
Wish List

The following are some of features that are on the wish list for future OpenAFS for Windows releases. The estimated cost to implement is provided when known.  This list only includes items that can be implemented without changes to the AFS-3 Wire Protocols.  The OpenAFS.org Wish List describes proposed modifications that require server modifications.

Organizations that rely on OpenAFS for Windows are encouraged to financially support its on-going development either through donations or the purchase of support contracts

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

Table of Contents

AFS Client Service Improvements

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.

Disconnected Operations

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.

  1. how do items (files, directories, volumes) get pinned in the cache?
  2. how does the cache manager determine when to go offline and how is this conveyed to the user?
  3. when offline, the cache manager permits the user to write to the contents of the cache including creating new directories, files, symlinks, mount points, etc. how does the cache manager handle synchronization and collisions? several rules apply.
  4. what is the mechanism for end user interaction?

Estimated implementation time: TBD

Second Level Cache Architecture

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

Streamlined Installation Packages

The existing installation procedure for OpenAFS on Windows requires separate installation of multiple installer packages for:

The requirement that multiple installation packages are used is due to the capabilities of the tooling used to architect the packaging in 2004 coupled with the lack of a Kerberos distribution that supported side-by-side assemblies. MIT Kerberos still does not provide side-by-side assemblies whereas Heimdal does.

A single installer that includes both 64-bit and 32-bit OpenAFS components and a Heimdal side-by-side assembly could be created today but will require recreating the packaging from scratch.

Estimated implementation time: 3 to 4 months

Explorer Shell Extension Improvements

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.

Custom Column Handler

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

Custom Context Menu Handler

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

"AFS ACL" sheet should support recursive ACL operations

But it does not support the modification of ACLs on a recursive basis.

Estimated implementation time: To be determined

AFS Tool Band

An AFS Tool Band will provide graphical shortcuts to:

Estimated implementation time: 12 to 16 hours

AFS MetaData Handler

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

Name Spaces

 

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

Recently Viewed Volumes

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

My User Volume Custom Name Spaces for Organizations

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)

OpenAFS Control Panel Replacement

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:

AFS Group Editor Panel

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

Network Identity Manager AFS Plug-in Panel

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

Microsoft Management Console Shortcut

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

OpenAFS Client Service Microsoft Management Console Plug-in

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:

OpenAFS Client MMC - General Page OpenAFS Client MMC - CIFS Page OpenAFS Client MMC - Performance Page OpenAFS Client MMC - Cache Manager Page OpenAFS Client MMC - Freelance Client Page OpenAFS Client MMC - Servers Page OpenAFS Client MMC - Logon Options Page OpenAFS Client MMC - Diagnostics Page

Estimated implementation time: 180 to 240 hours

Vista User Account Control Privilege Separation

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

AFS Servers on Microsoft Windows

As of the 1.7.31 release, the AFS Servers do not work on Microsoft Windows.  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: at least six months.

Additional Feature Requests?

Send additional feature requests to openafs@secure-endpoints.com.