Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?4AB9DDD8.2020700>