Following up on the "request-key" issue, although it's sort of hijacking
Daniel's thread: could be related in the sense that I wonder if using
the 6.3 kernel in 6.2 isn't the source of many similar problems.  In the
new kernel changelog I see:

  * Wed Feb 29 2012 Aristeu Rozanski <[log in to unmask]> [2.6.32-245.el6]
  - [build] update RHEL_MINOR to '3' (Aristeu Rozanski)
  - [fs] keyring: allow special keyrings to be cleared (Steve Dickson) [772495]
  - [fs] NFS: Update idmapper documentation (Steve Dickson) [772495]
  - [fs] NFS: Keep idmapper include files in one place (Steve Dickson) [772495]
  - [fs] NFS: Fall back on old idmapper if request_key() fails (Steve Dickson) [772495]

which explains why there are messages in /var/log/secure but no actual
failures like the older bug report mentions.  Unfortunately, this
bugzilla is restricted so no more info can be gleaned.  

Updating a test machine to the 6.3 RC, the request-key errors go away.
I interpret this as the new kernel seeing the the idmapper version in
6.2 (nfs-utils-1.2.3-15) as "old" but being happy with the version in
6.3 (nfs-utils-1.2.3-26).  Just the sort of backport bug you'd expect by
taking a 6.3 kernel and releasing it as a 6.2 update.

The nfs-utils changelog does list a lot of idmapper changes on the same
date:

  * Wed Feb 29 2012 Steve Dickson <[log in to unmask]> 1.2.3-16
  - Enable the keyring based idmapping (bz 772496)
  - Correct nfs(5) man page on how TCP retries are done (bz 737990)
  - Fixed sigio problem in rpc.idmapd (bz 751089)
  - Only link in libtirpc to binaries that need it (bz 772050)
  - Increase the stdio file buffer size for procfs files (bz 736741)
  - Fixed gssd from picking the wrong creds (bz 738774)
  - Mounts fail with using -o bg,vers= options (bz 740472)

So: looks like updating the nfs-utils should be a requirement of
updating the kernel: if that doesn't break other stuff, which I'm not in
a good position to test.  

Question for Pat: given that I can't read the bug report in question, do
I file a new one?  Or is this a SL problem not a TUV issue?  (not sure
of the provenance of the 6.3 kernel appearing in the 6.2 updates
directory).

	Alec

Alec T. Habig writes:
> Daniel Kontsek writes:
> > 
> > all of my SL 6.2 machines proposed today a kernel update to
> > 2.6.32-279.1.1.el6, which would probably make them unreachable after
> > reboot. This kernel is also included in the 6.3 release.
> 
> Another problem which came with this kernel update is thankfully
> annoying rather than fatal.  /var/log/secure is filling up with things
> like:
> 
>   request-key: Cannot find command to construct key 100834592
> 
> (where the int after "key" changes).
> 
> Looks similar to:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=794780
> 
> which came into the fedora kernel when it was the version we're using in
> SL6 now, but which has been fixed in Fedora for a while.
> 
> Anyway: if anybody else has noticed this, let me know as I try to get a
> proper bugzilla cooked up, so I can include your information too.
> 
>        Alec
> 

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    [log in to unmask]
		       http://neutrino.d.umn.edu/~habig/