KFW 3.1 Beta 1 has been tagged and installers have been built.
An official announcement is soon to come.
Tuesday, July 25, 2006
Thursday, July 20, 2006
OpenAFS for Windows Large File Support is now available
Several weeks ago, OpenAFS.org announced the release of OpenAFS for Windows 1.5.3. For Windows this release contains three major changes:
With all of these changes I bet you can't wait to get your hands on this release.
- First, there are significant changes in the CIFS server compatibility with the Windows CIFS client. The result should be a major improvement in the interaction with the Explorer Shell.
- Second, this is the first AFS client on Windows to support the Inline Bulk Status RPCs. The reason that this is a big deal is that instead of performing one RPC per directory entry the Windows client now performs one RPC for every 50 directory entries. In addition, directory entries that are unreadable due to access permissions are temporarily cached as expired callbacks. This significantly reduces the time required to obtain a directory listing or create/open/delete files.
- Third, for the first time the Windows AFS client is capable of supporting 64-bit Large Files. You can now use AFS to store DVD images.
With all of these changes I bet you can't wait to get your hands on this release.
At long last, Kerberos for Windows 3.1 is nearing release
After more than seven months of waiting MIT Kerberos for Windows 3.1 is finally going to begin beta testing. This release will fix all of the bugs that plagued KFW 3.0 Network Identity Manager 1.0. The memory leaks, the principal name rejections, the non-en_US locale problems. They are all gone.
In addition, KFW 3.1 will not crash on Windows XP64 WOW64 simply because Microsoft failed to actually export tickets from the LSA even though the functions succeed. (This problem is fixed in Vista Beta 2.)
Along with KFW 3.1 will be a new version of the AFS plug-in installer. Now that the NetIDMgr APIs are truly stable the AFS plug-in can be integrated into an OpenAFS release. That said, the KFW 3.1 release will install on 64-bit Windows systems but there will not be 64-bit native support until KFW 3.2.
The most dramatic changes in KFW 3.1 are in the NetIDMgr. The user interface is much more fleshed out. In the main window tickets can be sorted in arbitrary ways by clicking the column headers. The View->Columns menu allows the user to select which ticket properties should be displayed. The properties include everything from principal names to lifetimes to enc-types to key version numbers. Tool Tips are supported for the toolbar. The font used to display tickets is user selectable. Identities can be added without obtaining credentials via the Global Identity Settings. The Kerberos 5 Realm configuration editor is complete. Kerberos 5 credentials can now be obtained from FILE: ccaches. In general, the overall look and feel of the tool is significantly improved.
I look forward to being able to announce on Tuesday July 25th that the installers are available for download.
In addition, KFW 3.1 will not crash on Windows XP64 WOW64 simply because Microsoft failed to actually export tickets from the LSA even though the functions succeed. (This problem is fixed in Vista Beta 2.)
Along with KFW 3.1 will be a new version of the AFS plug-in installer. Now that the NetIDMgr APIs are truly stable the AFS plug-in can be integrated into an OpenAFS release. That said, the KFW 3.1 release will install on 64-bit Windows systems but there will not be 64-bit native support until KFW 3.2.
The most dramatic changes in KFW 3.1 are in the NetIDMgr. The user interface is much more fleshed out. In the main window tickets can be sorted in arbitrary ways by clicking the column headers. The View->Columns menu allows the user to select which ticket properties should be displayed. The properties include everything from principal names to lifetimes to enc-types to key version numbers. Tool Tips are supported for the toolbar. The font used to display tickets is user selectable. Identities can be added without obtaining credentials via the Global Identity Settings. The Kerberos 5 Realm configuration editor is complete. Kerberos 5 credentials can now be obtained from FILE: ccaches. In general, the overall look and feel of the tool is significantly improved.
I look forward to being able to announce on Tuesday July 25th that the installers are available for download.
Monday, June 12, 2006
Tuesday, March 21, 2006
MIT Kerberos for Windows 3.1 has been delayed
MIT Kerberos for Windows 3.1 has been delayed. The original anticipated delivery date was late January. Unfortunately things have taken a bit longer than expected. On the plus side the Network Identity Manager is feature complete. The next edition will include a wide variety of new tools for viewing the acquired credentials. In addition, all of the known bugs have been fixed. KFW 3.1 will be a significant release.
OpenAFS 1.4.1 release candidate 10 is available
OpenAFS 1.4.1 release candidate 10 is available. See http://lists.openafs.org/pipermail/openafs-announce/2006/000145.html for the announcement letter.
The dates and location for the AFS & Kerberos Best Practices Workshop have been announced. The workshop will be held at the University of Michigan during the week of June 12th to 16th. The program will be similar to last year. Monday there will be a full day tutorial on AFS installation and administration. On Tuesday there will be a full day tutorial on Kerberos installation and administration. Wednesday through Friday there will be a series of talks on AFS and Kerberos given by key developers and members of the user community. Registration fees are $100 per person for the talks and $100 per person for each of the tutorials.
Jeffrey Altman of Secure Endpoints Inc. will be giving a talk at this years NIST PKI R&D Workshop which is being held April 4-6 in Washington D.C.
The dates and location for the AFS & Kerberos Best Practices Workshop have been announced. The workshop will be held at the University of Michigan during the week of June 12th to 16th. The program will be similar to last year. Monday there will be a full day tutorial on AFS installation and administration. On Tuesday there will be a full day tutorial on Kerberos installation and administration. Wednesday through Friday there will be a series of talks on AFS and Kerberos given by key developers and members of the user community. Registration fees are $100 per person for the talks and $100 per person for each of the tutorials.
Jeffrey Altman of Secure Endpoints Inc. will be giving a talk at this years NIST PKI R&D Workshop which is being held April 4-6 in Washington D.C.
Tuesday, January 24, 2006
Thread Safety is hard to maintain
I am constantly amazed by how hard it is to write thread safe code and have it stay thread safe. This week I had the pleasure of debugging two very different thread safety problems with very different origins on the theme.
Actually as I think about it, the origin of the problems are fairly similar. In both cases, the root cause was a failure of the thread safe architecture to be appropriately documented. In the first case, the degradation was gradual. The bugs were introduced slowly over time as multiple developers who did not understand the architectural requirements added or modified functionality. The worst part about thread safety problems is that problems that result in reference counting errors in which references are not released are nearly impossible to find. The same holds true for race conditions due to a failure to apply read/write locks or mutexes in a consistent manner.
These errors are extremely easy to introduce and unless there is very thorough auditing of the code it is quite likely that even a well written test suite is not going to trigger the errors. Deadlock conditions and under counting of references are much easier to identify because they typically result in a hard error.
The second problem was even more hideous. The architect made an assumption about the order in which threads would be allocated in an application. It never occurred to her/him that the libraries that are linked into the application might one day be multi-threaded themselves. The end result was that a data structure that was meant to allow thread safe access to objects by allocating a single bit in a table to each thread ended up due to math truncation associating multiple threads with the same bits. The end result is that while not a single line in the program changed, the thread safety of the application went out the window.
I don't know if better documentation would have helped in this second instance but it is clear that heavily used production servers started to bounce because of an undocumented assumption.
My advice to anyone that is developing and maintaining multi-threaded systems is to be careful. What looks on the surface like a trivial change may very well disrupt a a delicately balanced system. Whenever possible find someone else who understands the architecture of the system to review each and every line being very careful to pain attention to the expansion of macros and the side-effects that function calls might have.
Actually as I think about it, the origin of the problems are fairly similar. In both cases, the root cause was a failure of the thread safe architecture to be appropriately documented. In the first case, the degradation was gradual. The bugs were introduced slowly over time as multiple developers who did not understand the architectural requirements added or modified functionality. The worst part about thread safety problems is that problems that result in reference counting errors in which references are not released are nearly impossible to find. The same holds true for race conditions due to a failure to apply read/write locks or mutexes in a consistent manner.
These errors are extremely easy to introduce and unless there is very thorough auditing of the code it is quite likely that even a well written test suite is not going to trigger the errors. Deadlock conditions and under counting of references are much easier to identify because they typically result in a hard error.
The second problem was even more hideous. The architect made an assumption about the order in which threads would be allocated in an application. It never occurred to her/him that the libraries that are linked into the application might one day be multi-threaded themselves. The end result was that a data structure that was meant to allow thread safe access to objects by allocating a single bit in a table to each thread ended up due to math truncation associating multiple threads with the same bits. The end result is that while not a single line in the program changed, the thread safety of the application went out the window.
I don't know if better documentation would have helped in this second instance but it is clear that heavily used production servers started to bounce because of an undocumented assumption.
My advice to anyone that is developing and maintaining multi-threaded systems is to be careful. What looks on the surface like a trivial change may very well disrupt a a delicately balanced system. Whenever possible find someone else who understands the architecture of the system to review each and every line being very careful to pain attention to the expansion of macros and the side-effects that function calls might have.
Subscribe to:
Posts (Atom)