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...@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...@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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
