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
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
Hi,
I'm trying to store some attributes with a bit more structure than simple key:value pairs. There seems to be a bit of a precedent in the Cosine otherMailbox attribute, but I don't really understand what's going on - can anyone give me any pointers?
What I'm trying to represent is a single username that could have access to multiple mailboxes on different mail services; each mailbox could receive mail via different mail addresses.
For example, user1 could have a mailbox on mailservice1 and another one on mailservice2, with user1a@example.org being delivered to her username on mailservice1 and user1b@example.org being delivered to her username on mailservice2, so I'd aim to have attributes that look something like: dn: uid=user1,ou=orgunit,dc=example,dc=org uid: user1 othermailbox: mailservice1 $ user1a@example.org othermailbox: mailservice2 $ user1b@example.org
The point is that I want to preserve the mapping between email addresses and email services in a way that's not possible with a straightforward multivalued attribute, and this seems to be too trivial a problem to bother with additional objects to represent the additional complexity.
I could just stuff the data into a printable string and leave it to the client to sort it out, but it looks like there's a way to do this properly, if only I can find some documentation or examples.
Steve.
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 :)
openldap-technical@openldap.org
-
Bennett, Steve -
Christian Manal -
radiatejava -
Zhang Weiwu