> WOW! That document was FANTASTIC!!! Thanks so much! I > don't know why the OpenLDAP docs don't cover those basics!
For the same reason they don't cover the care and feeding of a Berkley Database (BDB); there is already perfectly good documentation that takes care of that. Making documentation takes a great deal of time, as does keeping it up to date. > Here are some of the things I gleaned from that doc: > * The values of the objectClass attribute determine > the schema rules the entry must obey. > * The objectClass declares the type of the object > (person, device, > service, building, etc.) Every object contains an > objectClass "top". > * An attributeType must be included into an > objectClass definition as Except in the case of "extensibleObject", yes. But you shouldn't use "extensibleObject" unless you know what you are doing. > either required or allowed. > So, I draw these conclusions: > * attributeTypes are building-blocks for objectClasses > and as such, are reusable components from which other objectClasses > (ie. one's own) canbe built. > * attributeTypes are "born" out of the need to interpret the schema. I'd say the same applies to "objectclass". > Does that sound about right? If it does, I'm off an running! Pretty close anyway. > But one more question to clarify: Why does "every object > contain an objectClass top"? What is meant by "top"? It is the root of the inheritance chain. > On to the next point. The documentation you supplied > brought up another > point I found interesting that perhaps you could > clarify. Here's the > example: > > dn: cn=postgres+ipServiceProtocol=tcp,ou-ipServices,ou=NSS,... > objectClass: ipService > objectClass: top > ipServicePort: 5432 > ipServiceProtocol: tcp > cn: postgres > > Now, it is my understanding that the RDN is determined > by the cn components that appear in *both* the "dn" and the > "cn:" of the entity. > Obviously, I've missed some key point here, since in > the above example, > the RDN is "cn: postgres" AND "ipServiceProtocol: > tcp". So, how is the > RDN calculated? Calculated? It isn't. The RDN is specified in the DN: "cn=postgres +ipServiceProtocol=tcp"; in this case it is a multi-valued RDN. There is nothing special about "cn". It is just commonly used. --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
