Danno: I suspect that if people filed more bug reports when problems were experienced that things would get fixed faster. I understand that folks are reluctant to file reports when they can't reproduce the problems or when there are no resources available to assist in debugging or identifying the issues. Folks want a product that works and we want to provide it. Unfortunately, unless reports are received we have no idea that there is a problem. Each organization uses a different subset of the functionality and therefore has the potential to identify problems that others are not experiencing.
This is particularly frustrating for me because I am often hearing rumors that organizations are having problems but when I ask for details no one can provide them and bug reports are never submitted. As it turns out about three weeks ago an organization brought to my attention a serious problem in the Windows client that might have impacted your users as it occurs when multiple clients are actively creating/deleting files from the same directory. To reproduce the problem I wrote some test code which creates, writes, reads, closes, deletes temporary files and executed it from multiple times and from multiple machines in the same directory. What I discovered was not pleasant: * if the client has dirty buffers and the file has been deleted the buffers will remain dirty forever (or until the persistent AFS Cache is destroyed). * dirty buffers were not being written to the file server in a timely manner. It could take more than 23 minutes for all of the buffers in a 80MB cache to be checked and written to the file server. Dirty buffers are not flushed when a file is closed because if writing the dirty buffers takes longer than the CIFS timeout period, the CIFS client will tear down the SMB virtual circuit which in turn would invalidate all existing file handles and outstanding locks. * there were race conditions which could result in stat cache entry reference leaks. A stat cache entry with a reference cannot be recycled. If all stat cache entries are in use, then the OpenAFS client will panic when a new file is accessed. If the reference counts wraps back to zero, the AFS client will panic when freeing a reference. (stat cache entries are persistent so reference leaks accumulate over time.) * All pioctl operations would leak reference counts on the stat cache entries for the directory. The Explorer Shell extension performs many pioctl calls on the directory each time it is refreshed. * If the client panics, all dirty buffers will be lost and Windows may restart the AFS Client Service so that the end user doesn't even realize that there was a crash. Although they are not announced yet, OpenAFS 1.4.2 (205) and 1.5.9 (902) builds address these issues. There are links to the Windows installers from http://www.openafs.org/windows.html With regards to the distinctions between 1.4.2 and 1.5.9. The rate of new development on the Windows client far exceeds that of development on any other platform. This is primarily due to the fact that there has been so much more that has been required for the Windows client to play catchup with the rest of the platforms and because Microsoft has released several new platform variants (XP SP2, 2003 SP1, 64-bit XP/2003, and Vista). I do not believe that the 1.5.9 client is any less stable than the 1.4.2 client. In fact, the reverse is problem true. One performance problem that we have seen reported many times is that the Windows clients performance gets really really slow after a directory is listed multiple times in Explorer (or a File Open/Save dialog.) We narrowed the problem down to access control issues and the lack of support in the Windows AFS client for the Inline Bulk Status RPC. Instead of performing a single RPC to obtain the status information for the contents of an entire directory, the Windows client performs a separate FetchStatus RPC for each entry. If the user does not have permission to obtain the status info for an entry, the file server would send an error (rx abort EACCESS) to the client. If the file servers sends too many errors in a row, the rx library will attempt to pace the client to prevent a denial of service against the file server. Support for Inline Bulk Status calls were added to 1.5.9 but the changes are considered too large to pull into the 1.4 series. The 1.5.9 release also contains support for a number of other "features": * Support for 64-bit Large Files * Support for 64-bit Windows XP/2003/R2/Vista * Implements Windows Byte Range Locking backed by AFS File Server Locks * Uses GetCapabilities RPCs to probe the server status * Logs fs crypt state to the Windows Event Log * Supports DebugOutputString debugging of the RX Library * New command: fs uuid [-generate] * Improved CIFS protocol capatibility * Hard Dead and Connection Timeout values restricted to the CIFS Session Timeout value. Note that the 1.4.x and earlier clients would not reject attempts to read/write data beyond 2GB. The data would simply be corrupted. In answer to your question regarding Samba. There are several sites that I work with who have used Samba as a gateway for users on MacOS X and Windows that do not have AFS clients installed. The number one issue that they complain about is the fact that in order to use the --fake-kaserver functionality in conjunction with either a Kerberos KDC authentication or an LDAP authentication, the clients have to be configured to send username/password in the clear. Sending the user's Kerberos password in the clear is not a desirable solution. This may be improved with Vista clients since Vista will negotiate TLS first and then perform the SMB authentication on top of that. Even if you are willing to require that your users first VPN (or otherwise tunnel) to the Samba server, you still have the problem that the most recent MacOS X and Windows client OSs won't send username/password in the clear out of the box. Locking via the Samba server is not going to be improved. WebDAV is a work in progress. UMich has demonstrated CoSign, mod_dav and mod_waklog working together but I believe there are still issues to resolve. Here is a link to the mod_waklog presentation from this year's best practice workshop: http://www.pmw.org/afsbpw06/talks/jarod.willn/index.html Regarding SFTPdrive, I have not used it. I suspect if you can setup the SSH server to access your files via AFS then the product will work. I would guess that similar to the FTP shell extensions it works by copying the file locally and then copying it back when the user is finished. Jeffrey Altman Secure Endpoints Inc. Dan Pritts wrote: > Hi folks - > > what's the current status of using samba to serve files from an > AFS backend to windows clients? I could easily use Linux or Solaris > as the samba server. Other platforms would be possible. > > how does handle file locking? How does it handle authentication? > > can you successfully use MS office documents from the share? > > We're having some issues with deploying the windows AFS client to some > of our staff, and I'm considering my alternatives. > > Other alternatives folks are using would be interesting too (webdav?). > > Anyone have any experience with this? > > http://www.sftpdrive.com/ > > [background] > > since i know folks will be interested, here's the scoop with our issues > with the windows client. I am not interested in starting any flame wars, > and really i'm not interested in discussing the problems we've had with > the windows client. I personally am interested in making AFS work, > but it has the potential to become a huge political issue within our > organization and i'd like to avoid that. > > Bottom line, our accounting staff has had a lot of bad experience with > testing afs on the windows desktop. Some of it has been in the form > of long delays accessing files (which I think was related to recent > bug fixes in the server code, and I think this problem is gone). > > some of it has been mysterious issues with changes not being saved. > I think this is really because they are simultaneously editing AFS > files with MS office, because they refuse to drag files to their desktop > before opening and the 1.4 client we're using doesn't try to create any > AFS locks. Yes i know that 1.5 should solve this problem but i've been > worried what else will happen with the unstable branch. > > The situation is a lot better with the 1.4.2 rc client, but they're > at the point that they have lost patience with problems and I need to > give them something that just works. I'm hoping to avoid that solution > being a windows file server, since we will continue to use afs within > the organization, but it's not out of the question. > > thanks, > danno > -- > Dan Pritts, System Administrator > Internet2 > office: +1-734-352-4953 | mobile: +1-734-834-7224 > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info
smime.p7s
Description: S/MIME Cryptographic Signature
