OpenAFS for Windows - outstanding projects report and call for testers

Jeffrey Altman <[email protected]>
Newsgroups gmane.comp.file-systems.openafs.devel.win32,gmane.comp.file-systems.openafs.general
Organization No Longer Affiliated with Columbia University in the City of New York
Message-ID <[email protected]>
To the OpenAFS for Windows user community:

Since the last status report in mid-June, version 1.3.65 was released on 
June 26.  The overall
feedback has been quite good.  There have been no significant bug 
reports filed against this
release.  Since that time work has continued with in the intention of 
producing a release at
the end of July which can be distributed by organizations getting ready 
for the Fall.  This
was supposed to be the in-famous 1.4 release but it won't be.

The following question was raised "what does the version number mean in 
the context of
OpenAFS?  Current the version number is a source code version number.  
Not a product
release version number.  The Windows products are built out of the 1.3 
branch of the
the OpenAFS CVS.  Unfortunately, the Unix development is not at a point 
where a 1.4
branch is ready to be made.  Since I really do not want to fork a new 
branch for Windows
and because even with this next release I am anticipating a major 
release once a month
for the forseeable future there appears to be no justification for 
splitting the Windows
version numbering away from the source code it is based on.  The next 
version will therefore
be 1.3.70.

There are approximately two weeks left before the next release.  As such 
the list of features
which can go into it are minimal.  The focus is on stability and 
security.  Since the 1.3.65
release the following changes have been made:

    * A new registry value "MaxCPUs" has been added to allow
      administrators to restrict the
      number of CPUs on which the OpenAFS Client Service,
      afsd_service.exe, will execute.
      This is to help avoid some of the known thread safety problems in
      the RX library which
      are frequently triggered on hyperthreaded machines.
    * In afscreds, if you already have a Kerberos ticket for user@REALM
      and wish to obtain
      a second token with it for another cell, simply enter the cell
      name and user@REALM
      for the username without a password to perform the token acquisition.
    * The default RPC mechanism used for pioctl calls is now local RPC
      instead of Named
      Pipes
    * Freelance (dynamic fake root)  mode now supports read-write mount
      points in the fake
      root.afs volume. 
    * Freelance mode will automatically add read-only and read-write
      mount points for the
      default cell if there are no mount points in the fake root.afs
      volume.  No longer will
      the fake root.afs volume be empty.
    * Fixed a bug related to expiring DNS entries which would cause a
      crash if the DNS
      entries expired while the computer was suspended
    * Added support for authenticated SMB connections.  No longer will
      high security mode
      be needed.

These changes are currently available in the daily builds.  I urge any 
organization which is
planning on releasing this next build to its community to start testing 
the daily builds now.
The daily builds are available from:

    /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/
    \\afs\athena.mit.edu\user\j\a\jaltman\Public\OpenAFS\
    http://web.mit.edu/~jaltman/Public/OpenAFS/

The following items are the ones which are in my opinion required for 
the next release but
have yet to be implemented:

    * migration from .INI files to a pure registry only environment
      including movement
      from %WINDIR%\afsdcell.ini to <Program
      Files>\OpenAFS\Client\CellServDB
    * Support for XP SP2 and 2003 SP1.  This includes automatic
      configuration of the Internet
      Connection Firewall and registry modifications to support SMB
      authentication
    * Per Domain configurations for AFS Integrated Logon
    * Creation of a Windows Security Group for "AFS Administration".  If
      users are not
      a member of this group they cannot modify the configuration of the
      AFS Client
      Service

My remaining list of outstanding projects is as follows:

  1. No longer use AFS Client Service "cell" as the default cell for 
individual users
  2. Re-write afsd_service.exe to perform synchronized thread startup 
and shutdown.  Currently there is no
      synchronization of thread creation which results in timing 
conflicts; and there is no attempt to cleanly
      shutdown the service which causes problems when restarting and 
prevents the implementation of a
      persistent cache
  3. Implement a persistent cache
  4. Prevent panic situation when the root.afs volume is not reachable
  5. Prevent panic situation when the IP address to which the SMB server 
is bound is removed from the
      local machine's network configuration
  6. Identify and fix the problems with running the RX library on 
Hyperthreaded systems
  7. Add support for Named Pipes within the afs filesystem
  8. Re-write afscreds.exe to support:
        1. choosing between Kerberos 5 and Kerberos 4 on a per principal 
basis
        2. providing users with the ability to map multiple cells to a 
single principal
        3. providing change password functionality on a per principal basis
        4. no longer include drive mapping
        5. configuration of afscreds startup options in shortcut
  9. Re-write afs_config.exe to be only "per user" functionality which 
does not require admin privileges
        1. default cell and principal for the user
        2. drive mappings
        3. visibility of afs creds and setting of afs creds startup options
 10. Create new afs_admin.exe tool to be installed in the administrator 
folder (or use MMS) which contains:
        1. afs client service cell name
        2. integrated logon configuration
        3. Gateway configuration
        4. start/stop service
        5. global drive mapping
        6. submount management
        7. file/volume server preferences
        8. afs cells
        9. cache configuration
       10. diagnostics
       11. network configuration
       12. miscellaneous
       13. need to add support for all of the new registry values since 
1.2.8
 11. Identify why 16-bit DOS applications executed out of AFS fail
  12. Add support for configurable Icon file representing AFS folders 
within the Explorer Shell
 13. Documentation Documentation Documentation
 14. Large File support (> 2GB)
 15. Integrate KFW installation into the NSIS installer
 **. Replace the SMB/CIFS Server with an Installable File System

As always I encourage all organizations that wish to contribute to 
OpenAFS for Windows development to
contact me.  Financial contributions as well as in kind assistance are 
seriously appreciated.   There is
much to do and it is only going to be accomplished with the support of 
the organizations which rely on
this software within their organizations.

Jeffrey Altman
smime.p7s (application/x-pkcs7-signature, 3.2 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.