I did check out this URL as well as the two that Nelson had mention'd in his reply to your posting. These instructions are for the primary purpose of authentication rather than addressbook features although if done properly both can be accomplished in one step. It's just a matter of making sure your entry has the proper objectClass added to it and then adding the necessary attributes. The one problem I've found thus far with OpenLDAP and the various open-source LDAP management solutions is none of them produce a proper valid LDAP entry that can pass schemacheck muster. I generaly just use GQ and build out the entries themselves from my working knowledge. The problem becomes very evident with the 2.1.x version of OpenLDAP as I found out when I upgraded and had to spend a day bringing my entire tree up to muster. The biggest problem is in the various applications being able to follow a proper structural objectClass chain. Many (directory-administrator and webmin) would try to include objectClasses from two seperate STRUCTURAL objectClass chains. All the objectClasses for an entry need to be in the same structural chain or optionally include AUXILIARY objectClasses. Even the migration tools had problems with this last time I recall checking on them. For me I use the following objectClass definition for an account: top (structural) person (structural) posixAccount (auxiliary) inetLocalMailRecipient (auxiliary) The person OC is stack'd on top, so to follow a proper chain any other structural OC's must stack on 'person' not 'top' from this point. Both of the auxiliary OC's stack on top which is fine. What you can't do is what directory-administrator likes to try for host level access control and include the account OC which is structural stack'd on top. This violates the structural objectClass chain. You could add organizationalPerson and inetOrgPerson if you wanted to include more details as organizationalPerson stacks on person, and inetOrgPerson stacks on organizationalPerson. That would give you a very detail'd address book entry for a user. If they didn't need to have an account referenced then you could get away with removing the posixAccount auxiliary objectClass. The inetLocalMailRecipient is handy for smart LDAP routing of email addresses. I use my LDAP information rather extensively on my network as user accounts are listed in there, as well my mail servers use it for most of their configurations allowing them to be replaced with relative ease. So my LDAP servers are hit pretty hard daily, as of me writing this LDAP01 hashandled over 878K searches and LDAP02 another 867K and those are just the slaves that the network rely on. My primary is just used for management of the tree itself. Regards, Jeremy On Wed, Mar 10, 2004 at 06:00:51PM +0000, Martin Ellis wrote: > On Wed, Mar 10, 2004 at 04:43:45PM +0100, Nicos Gollan wrote: > > > Is there any good tutorial on how to set up a very basic LDAP > > > server for simple things like keeping an address book? I know > > On Wednesday 10 March 2004 17:13, Jeremy T. Bouse wrote: > > I've been working with LDAP to handle the centralized > > authentication of my home network, and now implimenting at work. > > There's a doc by Torsten Landschoff listed on the OpenLDAP pages on > alioth that describes this (NSS/PAM with LDAP): > > http://alioth.debian.org/forum/forum.php?forum_id=771 > > I don't know enough about the subject to know whether the default LDAP > schema you'll get following this article is sufficient to form an > address book - but it might be a good start? > > Martin >
Attachment:
signature.asc
Description: Digital signature