There is an application that needs to display multiple lists of people with their email address. The number of lists and the content of the lists we would like to leave configurable in LDAP. So, we set up a few dynamic lists in LDAP, put them into a 'groupOfUniqueNames' object which the application retrieved, and then in turn queried the dynamic lists to obtain the contents of the lists. We ran into three challenges: First, since dynamic lists follow the schema definition rules it could not return multiple values for the attribute 'displayName' so we configured it for 'givenName' instead. Second, it returned the results grouped by email address and names instead of pairs of data so we walked through all the email addresses and then the names while confirming the counts were the same and assuming that they were in the same order. Third, if an email address or name was missing then the manual pairing of data would be incorrect so we put in a filter that ensures only members with both pieces of data were included. Ideally we would like to retrieve pairs of full names and email addresses. The following does provide the information to us in the preferred format:
ldapsearch -a never -h xxx.xxx.xxx.xxx -b "ou=people,dc=example,dc=com" -x (&(&(departmentNumber=other)(mail=*))(displayName=*))" displayName mail
# extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: (&(&(departmentNumber=other)(mail=*))(displayName=*)) # requesting: displayName mail #
# root, people, example.com dn: uid=root,ou=people,dc=example,dc=com mail: root@example.com displayName: root
# nobody, people, example.com dn: uid=nobody,ou=people,dc=example,dc=com displayName: nobody mail: nobody@example.com
# jsmith, people, example.com dn: uid=jsmith,ou=people,dc=example,dc=com mail: jsmith@example.com displayName: John Smith
# search result search: 2 result: 0 Success
# numResponses: 4 # numEntries: 3
An equivalent is the following which is set up as a 'memberURL' attribute of a 'groupOfURLs' object with the exception of 'givenName' instead of 'displayName' because of dynamic list adherence to schema definitions: ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber =other)(mail=*))(givenName=*))
ldapsearch -a never -h xxx.xxx.xxx.xxx -b "cn=other,ou=lists,dc=example,dc=com" -x
# extended LDIF # # LDAPv3 # base <cn=other,ou=lists,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# other, lists, example.com dn: cn=other,ou=lists,dc=example,dc=com cn: other objectClass: groupOfURLs objectClass: top memberURL: ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber =other)(mail=*))(givenName=*)) mail: root@example.com mail: nobody@example.com mail: jsmith@example.com givenName: root givenName: nobody givenName: John Smith member: uid=root,ou=people,dc=example,dc=com member: uid=nobody,ou=people,dc=example,dc=com member: uid=jsmith,ou=people,dc=example,dc=com
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Is there a way to accomplish what the regular search returns using openldap features?
Paul Ghosh wrote:
There is an application that needs to display multiple lists of people with their email address. The number of lists and the content of the lists we would like to leave configurable in LDAP. So, we set up a few dynamic lists in LDAP, put them into a 'groupOfUniqueNames' object which the application retrieved, and then in turn queried the dynamic lists to obtain the contents of the lists. We ran into three challenges: First, since dynamic lists follow the schema definition rules it could not return multiple values for the attribute 'displayName' so we configured it for 'givenName' instead. Second, it returned the results grouped by email address and names instead of pairs of data so we walked through all the email addresses and then the names while confirming the counts were the same and assuming that they were in the same order. Third, if an email address or name was missing then the manual pairing of data would be incorrect so we put in a filter that ensures only members with both pieces of data were included. Ideally we would like to retrieve pairs of full names and email addresses. The following does provide the information to us in the preferred format:
ldapsearch -a never -h xxx.xxx.xxx.xxx -b "ou=people,dc=example,dc=com" -x (&(&(departmentNumber=other)(mail=*))(displayName=*))" displayName mail
# extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: (&(&(departmentNumber=other)(mail=*))(displayName=*)) # requesting: displayName mail #
# root, people, example.com dn: uid=root,ou=people,dc=example,dc=com mail: root@example.com displayName: root
# nobody, people, example.com dn: uid=nobody,ou=people,dc=example,dc=com displayName: nobody mail: nobody@example.com
# jsmith, people, example.com dn: uid=jsmith,ou=people,dc=example,dc=com mail: jsmith@example.com displayName: John Smith
# search result search: 2 result: 0 Success
# numResponses: 4 # numEntries: 3
An equivalent is the following which is set up as a 'memberURL' attribute of a 'groupOfURLs' object with the exception of 'givenName' instead of 'displayName' because of dynamic list adherence to schema definitions: ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber =other)(mail=*))(givenName=*))
ldapsearch -a never -h xxx.xxx.xxx.xxx -b "cn=other,ou=lists,dc=example,dc=com" -x
# extended LDIF # # LDAPv3 # base <cn=other,ou=lists,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# other, lists, example.com dn: cn=other,ou=lists,dc=example,dc=com cn: other objectClass: groupOfURLs objectClass: top memberURL: ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber =other)(mail=*))(givenName=*)) mail: root@example.com mail: nobody@example.com mail: jsmith@example.com givenName: root givenName: nobody givenName: John Smith member: uid=root,ou=people,dc=example,dc=com member: uid=nobody,ou=people,dc=example,dc=com member: uid=jsmith,ou=people,dc=example,dc=com
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Is there a way to accomplish what the regular search returns using openldap features?
what the regular search returns seems to be the result of a regular search. It is not clear what special feature should be used to accomplish it. Can you restate in a clearer manner what you expect?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
The need is to get back pairs of full name/email address as opposed to a list of full names and a list of email addresses and then have to manually join them hoping they are in the same order. A dynamic list cannot return multiple values for 'displayName' and it does not return the data in pairs. In the example provided we used 'departmentNumber' to create a group of people and are returning their full name and email address. Initially we would create one such group for each of the departments we have in the organization. Going forward we would create additional groups based on other criteria. So, the need is to return pairs of fullname/email address data when LDAP is queried for a particular group/list while keeping the application unaware of the different criteria set up in LDAP to group the people together.
-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Monday, August 13, 2007 12:09 PM To: Paul Ghosh Cc: openldap-software@openldap.org Subject: Re: multiple attribute list need
Paul Ghosh wrote:
There is an application that needs to display multiple lists of people
with
their email address. The number of lists and the content of the lists we would like to leave configurable in LDAP. So, we set up a few dynamic
lists
in LDAP, put them into a 'groupOfUniqueNames' object which the application retrieved, and then in turn queried the dynamic lists to obtain the
contents
of the lists. We ran into three challenges: First, since dynamic lists follow the schema definition rules it could not return multiple values for the attribute 'displayName' so we configured it for 'givenName' instead. Second, it returned the results grouped by email address and names instead of pairs of data so we walked through all the email addresses and then the names while confirming the counts were the same and assuming that they
were
in the same order. Third, if an email address or name was missing then
the
manual pairing of data would be incorrect so we put in a filter that
ensures
only members with both pieces of data were included. Ideally we would
like
to retrieve pairs of full names and email addresses. The following does provide the information to us in the preferred format:
ldapsearch -a never -h xxx.xxx.xxx.xxx -b "ou=people,dc=example,dc=com" -x (&(&(departmentNumber=other)(mail=*))(displayName=*))" displayName mail
# extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: (&(&(departmentNumber=other)(mail=*))(displayName=*)) # requesting: displayName mail #
# root, people, example.com dn: uid=root,ou=people,dc=example,dc=com mail: root@example.com displayName: root
# nobody, people, example.com dn: uid=nobody,ou=people,dc=example,dc=com displayName: nobody mail: nobody@example.com
# jsmith, people, example.com dn: uid=jsmith,ou=people,dc=example,dc=com mail: jsmith@example.com displayName: John Smith
# search result search: 2 result: 0 Success
# numResponses: 4 # numEntries: 3
An equivalent is the following which is set up as a 'memberURL' attribute
of
a 'groupOfURLs' object with the exception of 'givenName' instead of 'displayName' because of dynamic list adherence to schema definitions:
ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber
=other)(mail=*))(givenName=*))
ldapsearch -a never -h xxx.xxx.xxx.xxx -b "cn=other,ou=lists,dc=example,dc=com" -x
# extended LDIF # # LDAPv3 # base <cn=other,ou=lists,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# other, lists, example.com dn: cn=other,ou=lists,dc=example,dc=com cn: other objectClass: groupOfURLs objectClass: top memberURL:
ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber
=other)(mail=*))(givenName=*)) mail: root@example.com mail: nobody@example.com mail: jsmith@example.com givenName: root givenName: nobody givenName: John Smith member: uid=root,ou=people,dc=example,dc=com member: uid=nobody,ou=people,dc=example,dc=com member: uid=jsmith,ou=people,dc=example,dc=com
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Is there a way to accomplish what the regular search returns using
openldap
features?
what the regular search returns seems to be the result of a regular search. It is not clear what special feature should be used to accomplish it. Can you restate in a clearer manner what you expect?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Paul Ghosh wrote:
The need is to get back pairs of full name/email address as opposed to a list of full names and a list of email addresses and then have to manually join them hoping they are in the same order. A dynamic list cannot return multiple values for 'displayName' and it does not return the data in pairs. In the example provided we used 'departmentNumber' to create a group of people and are returning their full name and email address. Initially we would create one such group for each of the departments we have in the organization. Going forward we would create additional groups based on other criteria. So, the need is to return pairs of fullname/email address data when LDAP is queried for a particular group/list while keeping the application unaware of the different criteria set up in LDAP to group the people together.
OK, so basically you would like to move the filter into an entry instead of setting it in the application. Searching for that entry (call it an "assertion object"?) would trigger the execution of a sub-search. Is this correct? If it is, I don't think there's anything specific to support that (but I might be overlooking something). However, it would be (almost) straightforward to implement it, with few caveats.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Yes - return the results when queried for the "assertion object" while keeping the application ignorant. Application just consumes the pairs of full names and email addresses. Also, perhaps leverage caching as done for dynamic lists.
-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Monday, August 13, 2007 12:29 PM To: Paul Ghosh Cc: openldap-software@openldap.org Subject: Re: multiple attribute list need
Paul Ghosh wrote:
The need is to get back pairs of full name/email address as opposed to a list of full names and a list of email addresses and then have to manually join them hoping they are in the same order. A dynamic list cannot return multiple values for 'displayName' and it does not return the data in
pairs.
In the example provided we used 'departmentNumber' to create a group of people and are returning their full name and email address. Initially we would create one such group for each of the departments we have in the organization. Going forward we would create additional groups based on other criteria. So, the need is to return pairs of fullname/email address data when LDAP is queried for a particular group/list while keeping the application unaware of the different criteria set up in LDAP to group the people together.
OK, so basically you would like to move the filter into an entry instead of setting it in the application. Searching for that entry (call it an "assertion object"?) would trigger the execution of a sub-search. Is this correct? If it is, I don't think there's anything specific to support that (but I might be overlooking something). However, it would be (almost) straightforward to implement it, with few caveats.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Paul Ghosh -
Pierangelo Masarati