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_.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
