Date: Thu, 16 Sep 2010 19:26:42 +0300 From: George Mamalakis <mamalos@eng.auth.gr> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: stable@freebsd.org Subject: Re: fbsd8_stable nfsv3 sys=krb5 issue Message-ID: <4C924542.2090003@eng.auth.gr> In-Reply-To: <1333960500.1025681.1284651030347.JavaMail.root@erie.cs.uoguelph.ca> References: <1333960500.1025681.1284651030347.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C924542.2090003>