So we have officially launched Phase I of the PASS Beta Test. I know many of you have been anxious. Both our NFS Gateway and CIFS Gateway are ready for testing. The documentation site has been moved to a new wiki. Other systems such as Secure-FTP, Web hosting, and Web-based tools for managing ACLs and quotas will be ready at future phases. Those who have enrolled in the Beta Test have already been allocated a home folder with 500 MB of space and we are accepting requests for additional testers at this time.
A lot has happened during Fall semester.
First, my PASS Beta Test site on php.scripts.psu.edu has been revamped. Most of the static content has been moved to https://wikispaces.psu.edu/display/PASS/PASS+Beta+Test, where many people can help out (or comment) on what is known about the current state of the technology. Secondly, I added a couple of email forms for signing up for the beta & giving feedback. Also, we have an RT queue to manage feedback which the email forms use. Personally, I've preferred my own email client to forms, so I have exposed the email address for those who are like me in that regard. The discussion list l-passbeta /at/ lists \dot\ psu (dot) edu will remain separate.
Now about those servers we are about ready to test:
We have a new NFS Gateway that supports both the v3 and v4 versions of the protocol using Kerberos. Note we do not have a server that supports v3 with an out of band (e.g. https POST) authentication mapping like we have today for https://nfs.pass.psu.edu/; those who want to use the new NFS gateways must use kerberos on the client side. We have tested the new gateway with a number of clients and have started to build wikified information on what has and what has not been tested along with directions we found to work for those that do.
One general challenge we encountered with testing NFS has to do with unifying the file namespace. Historically, NFS has not done this in band, which resulted in the various workarounds such as automounter daemons and client side mount scripts. We cheated with DFS because it appeared to NFS as a single filesystem device and thus we only had to export one "filesystem", allowing users the ease of only mounting PASS once to mount it all. Due to present limitations in GPFS, we will be unable to support a single filesystem device for all of PASS; we will need help from NFS or the client to unify it. On AIX, we have the option of the exname NFS export option, however this only works with AIX clients and would cause problems for other platforms if used. There is another product that should provide NFSv4 namespace unification called Network Data Administration Facility (NDAF), however, this is incompatible with the way we plan use GPFS (i.e. multiple servers that may access the same disk). Ultimately, we want to choose the option that is standards based and has the widest client support.
In the NFSv4.0 specification RFC 3530, there is a new concept called the "pseudo-filesystem" (I've even seen reference to it being called "mirror mounts"; see section 7.7 "Mount Point Crossing" of the RFC) which should provide a way for clients to automatically discover and mount secondary volume exports from the same server. We have found both AIX and Linux appear to support this decently and, being the direction of the NFSv4 spec, this will be what we will use. Unfortunately, our tests so far with Solaris haven't been so favorable. Hopefully that will change before too long.
Mac OS X appears to support kerberized NFS v3 in 10.5 (Leopard). Unfortunately, users of version 3 of the NFS protocol may be stuck with client-side mount automation overhead indefinitely. NFSv3 clients are also left in the dark w.r.t. ACLs as they are only accessible in v4 and chmod will not be able to modify permissions for at least the outset. We have also seen problems with the kerberized NFSv3 client on Mac OS X passing a valid security context to the server. This means that all access attempts are made as nobody. (Update 2008/02/28: It was later discovered to be a problem with the RFC 2307 compliant LDAP entries for the accounts we were testing. Both Solaris and Mac OS X are now able to successfully pass an authentication context.) Hopefully, Apple will provide a native, fully featured NFSv4 client for the Macintosh soon.
For SMB/CIFS, we have a different problem. While there are now IETF standards for CIFS, various implementations of Windows and Samba behave slightly differently, particularly with kerberization. The biggest problem is that the open source samba.org code we want to use assumes your kerberos realm name is IN ALL CAPITAL LETTERS despite what you have configured in your /etc/krb5.conf file. If you configure your samba server to join a kerberos realm or AD domain with all capitals, you can authenticate local realm/domain accounts fine. Cross realm authentication seems possible, but we are not yet sure what is needed for that to work in our environment; this is something we would like to test. Those familiar with the U Drive may notice that it uses WIN.PSU.EDU for its local AD domain and a cross realm trust to the dce.psu.edu kerberos realm, so this proves at least the protocol and Windows based clients are capable. Our preferred route is to patch the samba.org code to use our chosen realm name casing (all lower) to hook into dce.psu.edu directly. We have such a patch in place and would like help testing it.
For those curious how we do DCE authentication for the current PASS (DFS based) Samba gateway (win.pass.psu.edu aka smb.pass.psu.edu ...), we had some discussion on it recently on the Windows AD discussion list (L-UNV-WIN-AD). The sum of it is we currently use a custom set of modules and libraries for an older Samba (version 2) that authenticates the NTLM hash sent by the client against a hash that is generated and stored by/in DCE. This is required to get the full DCE security context including the Process Account Group (PAG) data, not just the kerberos tickets. None of this will port to the new environment. The good news is that leaving this behind allows us to finally upgrade various components, such as the version of samba, encryption ciphers used by kerberos, etc.
A lot of this may seem pretty rough. That's why we are testing in phases.
If you have any interest in helping us test, please let us know. Thanks for your patience and interest.
--
Jeff