From owner-freebsd-current@FreeBSD.ORG Wed Sep 23 08:35:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DCA1065670; Wed, 23 Sep 2009 08:35:35 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 24A548FC1F; Wed, 23 Sep 2009 08:35:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MqNK0-00081r-OA>; Wed, 23 Sep 2009 10:35:32 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MqNK0-0005kd-Mh>; Wed, 23 Sep 2009 10:35:32 +0200 Message-ID: <4AB9DDD8.2020700@zedat.fu-berlin.de> Date: Wed, 23 Sep 2009 08:35:36 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Daniel O'Connor References: <4AB8BAA9.1060100@zedat.fu-berlin.de> <200909222248.16475.doconnor@gsoft.com.au> <4AB93614.2080106@locolomo.org> <200909231104.39234.doconnor@gsoft.com.au> In-Reply-To: <200909231104.39234.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Erik Norgaard , freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: LDAP server gone -> impossible to login locally! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 08:35:35 -0000 Daniel O'Connor wrote: > On Wed, 23 Sep 2009, Erik Norgaard wrote: >> This sounds like the correct solution, AFAIK it's the same concept as >> for NIS, first check local files, then ldap. You don't want your root >> credentials possibly be leaked accross the network. On the other hand >> you don't want or need user accounts in the local files. >> >> Default first check local files which is fast, then fall back on ldap >> if the user is not found. > > Actually I wrote them the wrong way, how odd! > I actually have.. > group: cache ldap files > passwd: cache ldap files I had issues with the order 'files ldap' too, that's why I choosed 'ldap files'. > > I think that if it fails ldap, it does so very quickly - it certainly > did this morning when I rebooted uncleanly. > > I believe I did try it as "cache files ldap" but I had some issues, I > can't recall what they were though. I had quite a bit of difficulty > getting it to work acceptably so when it did I left it alone :) > > On a related note, why is slapd so damn fragile? It's a righteous pain > in the bum the way you have to run db_recover-X.Y /var/db/openldap-data > if slapd fails to start. Yes, this is a lot of pain. I have had issues the same way and never figured out what the reason was. /var/ is very often corrupted after a crash, power failure or unclean reboot. Maybe not slpad is that fragile, but db47 is. > > It wouldn't be so bad if it logged anything, but even with full logging > it gives a very cryptic message and if you have logging disabled (which > is recommended for performance!) it won't say _anything_. >