Re: Kerberized NFSv3 incorrect behavior

On 08/02/2010 00:34, Rick Macklem wrote:
>
>
> On Sat, 6 Feb 2010, George Mamalakis wrote:
>
>>
>> thank you for all your answers. I am planning on setting up the 
>> computer labs of my department using kerberized nfsv3 (since v4 seems 
>> to be "more" experimental) with a FreeBSD nfs server and Linux nfs 
>> clients. I was wondering "how stable" such an implementation would 
>> be; meaning that I wouldn't want to end up with an unstsable setup 
>> when receiving requests from 50-60 simultaneous clients, because that 
>> would be my everyday scenario.
>>
>
> I believe that the above should be stable, but your mileage may vary, as
> they say. The main issue will be what your TGT lifetime will be, since
> client access to the server will normally stop when the TGT expires. Some
> systems (Mac OS X) will automagically renew the TGT before it expires,
> if your KDC allows that. I don't think most/all Linux systems do this
> by default, but there are some utilities out there (try a search for 
> krenew) that will do so.
>
I think that this I can be overcome with a default timeout option in my 
shell variables (at least for the 'pilot phase').

> Basically, I think you'll want to avoid TGTs expiring before the user
> logs out. You also need a unique uid<->user principal mapping for all
> users logging in.

I am planning on using LDAP as my backend with kerberos attributes (I 
have already setup my ldap like that). To be honest, I have done 
something funny. My heimdal's backend is openldap; this LDAP is only for 
heimdal access (inside a jail). Then, I have another jail which serves 
its openldap instance to all my clients. This ldap (which stores a 
totally different DIT then heimdal's LDAP) is kerberized (it uses gssapi 
authentication via cyrus-sasl), using the heimdal jail. It's a bit 
dramatic, but it seems to work fine-until now-, it seems quite secure, 
and allows me to synchronize the heimdal backend easily through openldap 
replication. Moreover, keeping the user credentials in ldap helps for 
having a generic user/password store for other services I use (like 
samba, (for my windows hosts)). So, I use a different ldap attribute for 
samba-semantics and another ldap attribute for kerberos. Lastly, 
openldap caters for storing uids,gids,home_folder_locations,etc for my 
users, where my clients have access to this information via their 
respective nsswitch.conf files. I think that this answers your question 
regarding uid<->user principal mapping, unless I misunderstood something.
>
> You definitely want to do some testing with whatever Linux system you
> are using for the client.
>
> Good luck with it, rick
> ps: Choosing nfsv3 vs nfsv4 is basically independent of using RPCSEC_GSS
>     except for the host based initiator credential needed by some clients
>     (Linux and Solaris10 are among those) for NFSv4.
>

To tell you the truth, when I recompiled my kernel with:

options         NFSD
options         KGSSAPI
device          crypto

to setup an nvsv4 server, nfsd refused to start because mountd was 
segfaulting. I didn't play much with this setup, because I was in a 
hurry, so I commented out NFSD and put back NFSSERVER, to be able to 
test my server.

Now a last question: Does gssapi/nfs setup work with the automounter 
(bsd/linux nfs-client)?

Thanx again for your answer.

-- 
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