[TUHS] YP / NIS / NIS+ / LDAP
gtaylor at tnetconsulting.net
Tue Nov 6 08:53:12 AEST 2018
On 11/05/2018 12:58 PM, Dave Horsfall wrote:
> I've used OpenLDAP in a previous job for many years, for all sorts of
> things, and it worked well. I had it integrated with Sendmail and even
> Kerberos, but I've forgotten the details now.
My biggest problem with OpenLDAP, or any LDAP, is (other than my
ignorance) the fact that all of them (save for AD) started with an empty
schema. So I was functionally needing to create a schema that was
hopefully compatible with the things I needed /while/ learning LDAP ~>
$LDAPimplementation. I always felt it was a relatively steep learning
curve. And I was never sufficiently motivated.
Conversely, AD, has a very well established LDAP schema and many things
know how to work with it.
> There is a damned good book on LDAP in general (I can't remember the
> title, but it's a thick hard-cover)
Do you by chance know any more details? I'll dig and see if I can find it.
> so read it, cover to cover. Then download the OpenLDAP source (or used
> a trusted binary) and read the documentation, esp. the quick start guide
> and the admin guide.
> Then read them again :-)
> The most important thing about learning LDAP is forgetting everything
> you ever knew about relational databases; LDAP is a *directory*, not a
> database, and the idiots at work were constantly referring to records,
> not *entries*, which drove me crazy (I have a Unify RDBMS background too).
I think I understand that. Or at least what (little) I know doesn't
doesn't seem to have any objection to that. I know that I would not
want to use LDAP as a general purpose relational database.
> And if/when you start using OpenLDAP, always keep it up to date; there
> is an active mailing list, but the first thing they'll ask is "What
> version are you running?". Sure, there's been some lemon releases, but
> in general it worked fine for us; the company's balls depended upon it.
Thank you for the ProTip.
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
More information about the TUHS