problems with sec=krb5

[Rohit Kumar Mehta]

I tried recompiling nfs-utils, but it became quite painful, so I just 
upgrade the system to feisty (uses nfs-utils 1.0.12-4 and kernel 2.6.20)
without any difficulty at all.

sec=sys mounts still work, but I notice something odd written to the 
daemon.log:

Mar 29 10:25:15 cselin12 nfsd[4549]: nfssvc: writing fds to kernel 
failed: errno 0 (Success)

Is this indicative of a kernel problem?  the mount (sec=sys) seems to 
work properly despite this error message.

sec=krb5 is still not working yet though, but I am getting different 
error messages.

root at cselin12:~# mount -t nfs4 -o sec=krb5 
filesm.ad.engr.uconn.edu:/StaffDirectories/nfs/rohitm /home/rohitm
Warning: rpc.idmapd appears not to be running.
          All uids will be mapped to the nobody uid.
mount: permission denied

With debugging turned way up I see:
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: New client: 20
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: Opened 
/var/lib/nfs/rpc_pipefs/nfs/clnt20/idmap
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: New client: 21
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: handling krb5 upcall
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: Using keytab file 
'/etc/krb5.keytab'
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: INFO: Credentials in CC 
'FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU' are good until 1175216725
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: using 
FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU as credentials cache for 
machine creds
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: using environment variable to 
select krb5 ccache FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: creating context using fsuid 0 
(save_uid 0)
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: creating tcp client for server 
filesm.ad.engr.uconn.edu
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: creating context with server 
nfs at filesm.ad.engr.uconn.edu
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: DEBUG: serialize_krb5_ctx: 
lucid version!
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: prepare_krb5_rfc1964_buffer: 
serializing keys with enctype 4 and length 8
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: doing downcall
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: Client 20: (user) name 
"administrator at engr.uconn.edu" -> id "106"
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: Client 20: (group) name 
"daemon at engr.uconn.edu" -> id "1"
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: destroying client clnt21
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: Stale client: 21
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: ^I-> closed 
/var/lib/nfs/rpc_pipefs/nfs/clnt21/idmap
Mar 29 11:06:19 cselin12 rpc.gssd[4701]: destroying client clnt20
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: Stale client: 20
Mar 29 11:06:19 cselin12 rpc.idmapd[4699]: ^I-> closed 
/var/lib/nfs/rpc_pipefs/nfs/clnt20/idmap

nsswitch.conf is configured for files and nis, and I think the following
idmapd.conf configuration is correct.

root at cselin12:~# cat /etc/idmapd.conf
[Translation]
Method = nsswitch

[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = engr.uconn.edu

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Can you tell if I am doing obviously incorrect?  Thanks for the help!

Rohit

Kevin Coffman wrote:
> On 3/28/07, Rohit Kumar Mehta <rohitm at engr.uconn.edu> wrote:
> 
>> Kevin Coffman wrote:
>> >
>> >
>> > OK!  The userland/nfs-utils part is now working and a gss context has
>> > been created with the server.  We're now failing to pass it down to
>> > the kernel.  I'm guessing that this error has something to do with
>> > missing crypto modules in the kernel.  If your kernel is built with
>> > modules,  does lsmod show rpcsec_gss_krb5?  Otherwise, "modprobe
>> > rpcsec_gss_krb5" to get it loaded.
>> >
>>
>> Yeah I have been typing "modprobe rpcsec_gss_krb5" every time I reboot.
>>
>> root at cselin12:~# lsmod|grep rpc
>> rpcsec_gss_krb5        11528  0
>> auth_rpcgss            54048  1 rpcsec_gss_krb5
>> sunrpc                172600  5 rpcsec_gss_krb5,auth_rpcgss,nfs,lockd
>>
>> I am running  2.6.15-23-amd64-generic Ubuntu kernel.  Should I try
>> recompiling with the latest and greatest nfs4 patches from CITI website?
> 
> 
> Well, now that you mention it, there *were* some 64-bit problems in
> nfs-utils that I am not sure are fixed in the version you have.  You
> might try that before changing the kernel.
> 
> K.C.
>