fbsd8_stable nfsv3 sys=krb5 issue

[George Mamalakis]

  Hi Rick,

   glad to hearing from you, since we had a few relevant discussions in 
the past.

On 16/9/2010 6:30 μμ, Rick Macklem wrote:
> Normally the server will have a keytab entry for its
> fully qualified domain name like:
> nfs/fbsdclient.ee.auth.gr at EXAMPLE
>
> and if that is the case, the client is expected to use
> fbsdclient.ee.auth.gr as the server's name in the mount
> and not "server" (which I assume is an alias for the above).
>
> I'm definitely no kerberos wizard, but I'd guess that's where
> the problem is?
> (try "kinit -k nfs/fbsdclient.ee.auth.gr at EXAMPLE" on the server,
> to see that the keytab works.)

The "aliases" were written by me after copying the console's output on 
the email. I missed out the one you are stating in your email, and this 
is why I caused this confusion. All names mentioned in my email are in 
real called by their fqdn. The real machine names are 
fbsdclient.ee.auth.gr and filesrv.ee.auth.gr (but server and client are 
used "the other way around") and my realm is EE.AUTH.GR. My 
/var/heimdal/kdc.log shows that all requests are handled without any 
problems (this is why I didn't mention it at all), and the configuration 
is the same as the one I was trying on Feb (subject: Kerberized NFSv3 
incorrect behavior sent on Feb 5 2010) where everything seemed to work 
OK...or this is what I think it is, since probably I must be overseeing 
something important...
> The fully qualified domain name is used so that the keytab can't
> be moved to a different client and made to work easily, although
> a keytab entry is obviously weaker that a password based ccache
> entry.
>
> Beyond that, I'd suggest that you look in your KDC's logs to see
> what it thinks is going on when you try to access the mount point.
>
> rick
ktutil -k /etc/krb5.keytab shows both keys on both servers. I haven't 
kinit'ed to the keytabs on the server, but when I do so I will inform 
you about my output (sadly I don't have access on my machines at the 
moment). The thing is that kdc.log shows that all keys are exchanged 
correctly and no exceptions are thrown...

Hence, I am afraid that kerberos-config is not the problem for my case, 
but if you or anybody else cannot see anything wrong with the rest of my 
config, I will have to reconfigure both server and client from scratch, 
step-by-step to make it work again (I hoped to avoid this step through 
sending this email on the list)

> ps: Btw, I haven't forgotten about the issue w.r.t. kdestroy not
>      invalidating the handle in the client so that access continues
>      to work until the handle times out, but I haven't gotten around
>      to fixing it.
No problem!! I understand that everybody's time is precious. It is more 
than enough that you even remember it (I had forgotten it myself:-) )

Thanx again for the time and help.

mamalos

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379