From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 17:50:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04FA11065676; Mon, 8 Feb 2010 17:50:13 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9888FC15; Mon, 8 Feb 2010 17:50:12 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o18HoA10071786; Mon, 8 Feb 2010 19:50:10 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B704ECD.1060902@eng.auth.gr> Date: Mon, 08 Feb 2010 19:50:05 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: Rick Macklem References: <4B6BE7A2.6000402@eng.auth.gr> <4B6D3A18.2030304@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 17:50:13 -0000 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