Date: Wed, 23 Sep 2009 08:35:36 +0000 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: LDAP server gone -> impossible to login locally! Message-ID: <4AB9DDD8.2020700@zedat.fu-berlin.de> In-Reply-To: <200909231104.39234.doconnor@gsoft.com.au> References: <4AB8BAA9.1060100@zedat.fu-berlin.de> <200909222248.16475.doconnor@gsoft.com.au> <4AB93614.2080106@locolomo.org> <200909231104.39234.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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_. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AB9DDD8.2020700>