NFS4 testing / functionality

[Frank Victor Fischer]

Bryce Harrington wrote:

>On Thu, Aug 31, 2006 at 08:38:10AM +0200, Frank Victor Fischer wrote:
>  
>
>>Hi there,
>>
>>I've just deployed a production NFS4 installation with the following 
>>characteristics:
>>*Server is a Quad Opteron SLES10 box running the nfs, ldap and kerberos 
>>server
>>*clients are all SUSE Linux 10.1 (SLED10 may be upcomning), older 
>>versions failed. autofs is used.
>>*mounts are done with sec=sys and sec=krb5. krb5i and krb5p might be 
>>implemented later.
>>
>>So if you there is need for some testing (that could for example be done 
>>over a weekend) or feedback, please reply. Crash-testing of the server 
>>is unfortunately out of the question :)
>>    
>>
>
>Hi Victor,
>
>From a project point of view, one thing we've been looking for is a case
>study, that could be used to demonstrate that nfsv4 is being deployed
>into production.  Could you tell us the name of the company that has the
>production NFSv4 installation?  Can you explain why nfsv4 was chosen (as
>opposed to v3) and what benefits you've gained so far?
>
>From a testing point of view, autofs is something that has not received
>a huge degree of testing with nfsv4.  Unfortunately, I don't know of
>people actively maintaining autofs, but it would probably be of great
>benefit if you could keep an eye out for errors with it, and record them
>into the NFSv4 bugzilla (http://bugzilla.linux-nfs.org).
>
>Thanks,
>Bryce
>
>  
>
This is a department of the Technical University of Munich, Germany. 
This network has been running NFS2/3 (with AUTH_SYS) for many years for 
the linux clients along with CIFS for the windows side. While replacing 
the current infrastructure, it was decided that most of the current IT 
infrastructure will be thrown out and everything should redeployed. Two 
of the requirements were that
a) root users on workstations may not have read or write access to 
mounted home directories
b) login should be seamless (one password, that's it)
So the options left were: NFS, AFS and CIFS (all with kerberos). First 
idea was to use Solaris 10 and zfs with nfs4 support, which was 
cancelled due to faulty drivers for the Fibre Channel HBA in the server, 
so we "reverted" to using SLES10. CIFS (preferred solution because we 
need it anyway for the windows part of the network) was out because 
mount.cifs does not support kerberos, so you cannot have the pam system 
mount the share unless you store cleartext passwords somewhere. AFS was 
then out because it thinks it needs to maintain its own user database 
instead of using LDAP (I'm already bored enough by the fact that MIT 
kerberos cannot support an LDAP backend) and deployment is difficult. So 
NFS was the only file system left that met the requirements. We've 
ditched NFS3 because it caused problems (the server runs XFS on EVMS) 
with stale NFS file handles we couldn't solve. So we ended up with NFS4.

Pros:
-Decent Performance (I have not yet made detailed testing, but it seems 
not worse than NFS3)
-Once the server is set up, no configuration to be done on the client 
(apart from activating LDAP and kerberos)
-Security

Cons:
-Documentation (or lack thereof) makes initial deployment time-consuming
-Bugs in "real world implementations" (SUSE 10.1, SLES 10, SLED 10). 
These distros (not sure about others) try to mount nfs file systems 
before starting gssd/idmapd to have the possibility of /usr on NFS. They 
also do not really use any up-to-date software (nfs-utils 1.0.7 for example)
-idmapd seems to need a hardcoded domain name and cannot use 'hostname -d'
-Minor problems left (will post them separatly).
-different export names in nfs3 and nfs4 (server:/export vs. server:/)

autofs was no problem at all. Only thing we needed to do is to change 
the LDAP entries (we run automount via LDAP) from nfs to nfs4 (and 
change the export).

Hope this helps a little,
Victor