On 05.08.2013 15:24, radiatejava wrote:

I am trying to understand the difference between these 2 ldap searches, can anyone explain ?

ldapsearch --hostname localhost --baseDN "ou=Groups,dc=example,dc=com" "(objectclass=*)" @groupOfUniqueNames

ldapsearch --hostname localhost --baseDN "ou=Groups,dc=example,dc=com" "(objectclass=groupOfUniqueNames)"

What do we primarily mean by using @<objectclass> format ?

Thanks

Hi,

@<objectClass> is a stand in for all the attributes the object class contains.

The first search returns everything under baseDN but only shows attributes that are part of the groupOfUniqueNames object class on the returned objects.

The second one only returns objects with the groupOfUniqueNames object class under baseDN with all their (non-operative) attributes.

Regards, Christian Manal

I remember such question is usually responded with

"your question is not specific to openldap. It is out-of-topic, go ask ldap@umich.edu instead"

but I waited a night and no one responds. Either people are more tolerant these days, or that openldap became so unimportant that no one bother to cleanse the mailing list;)

On Mon, 5 Aug 2013, Bennett, Steve wrote:

I'm trying to store some attributes with a bit more structure than simple key:value pairs.

I think it is much needed. I have a lot of different needs of rich-data attribute values. Examples:

# These need special ordering rule so that you can pick out the product that # is large enough.

myResolution: 1024x768 myFormatSize: 21mmx23mm myDisplayArea: 15inx20in

# These too, need special ordering rule, so that you get the equipment that # fits your shelf:

myDimension: 21x23x23 myStorageCapacity: 50x38x23 myShipmentContainDimension: 100x320x310

# This one is a key-value structure, it requires a numeric qualifier: # it means this person won 3 Silver Medals and 4 Gold Medals

myAwards: dn=Silver Medal,ou=awards,dc=my,dc=co $ 3 myAwards: dn=Gold Medal,ou=awards,dc=my,dc=co $ 4

All these requires some overlay, and, it looks very much like IO-logic, thus feasiable to overlay the ldap server instead of overlaying the appliation business logic.

There seems to be a bit of a precedent in the Cosine otherMailbox attribute, but I don't really understand what's going on

Following this lead, I looked up the attribute, and is much surprised, that it has its own syntax. The SYNTAX 'otherMailBox' seems to be created for just one attribute to use. I would have designed the SYNTAX to be 'labeledMailbox', and leave the meaning of the label to be defined by attributeType.

I feel that otherMailBox designer extends LDAP only to solve his / her problem with least system change. Perhaps when you do make your module, you can design it general-purpose, and share it with others? Or maybe we can work it out together :)