This is a discussion on Re: LDAP queries for nested mailing lists - VMS ; On Fri, 13 May 2005 09:58:29, firstname.lastname@example.org wrote: ... >> Let's say now I want to get the email addresses of the uniquemembers of my >> groups, say the I-Tech group: > >> $ pmdf test/url "ldap:///ou=Groups,dc=acme,dc=edu?mail?sub?(cn=i-tech)" >> cannot open ...
On Fri, 13 May 2005 09:58:29, email@example.com wrote:
>> Let's say now I want to get the email addresses of the uniquemembers of my
>> groups, say the I-Tech group:
>> $ pmdf test/url "ldap:///ou=Groups,dc=acme,dc=edu?mail?sub?(cn=i-tech)"
>> cannot open URL
>> %PMDF-E-NO, Basic NO
>> OK, that error message isn't much help here. What am I doing wrong?
>Hard to say. I tried a similar URL here, only changing the base DN and the cn
>so they would match some real entries, and it worked fine.
>You can try adding a /debug qualifier and see if that produces more
>information. I'll warn you, however, that all too often all you get is an error
>from the underlying LDAP client library. Knowing that you have a "protocol
>error" isn't very helpful, but it is all the library provides.
Yes, /debug gives me some useful hints -- even if it suggests I've
been barking up the wrong tree for several months ;-P
>> Is it because there is no mail attribute in that cn item?
>That's the error you'll get if the search doesn't match anything. And
>this is one case where /DEBUG will tell you exactly what's going on.
>> I want the
>> mail attribute from each of the uniquemembers in cn=itech, but I dont'
>> know how to request that I guess...
>If I read this right, what you want is to look in the group entry for each
>uniquemember attribute, and take each of those attributes and find the
>corrsponding mail address in the entry they point to.
Not only that, but if a given group is subordinate to another,
I either need the subordinate group name along with the uniquemembers
for the SUPERordinate group in the response, or I need the LDAP query
to walk the entire subordinate list and give me EVERY uniquemember
all the way thru. Wildcarding is NOT usable, since for example, we
could easily have groups which are NOT subordinate to each other
matching the same wildcard.
>If so, there's no way to do that in a single LDAP URL. We support this sort of
>list in iMS, and it requires two lookups. I don't know if the LDAP support in
>PMDF handles this or not - the iMS support was written some time after the
Well, the LDAP server we're using is Solaris Directory Services 5.2,
which is based on the Netscape Suite in a previous incarnation, which
I thought had its origins in iMS. Probably where that support there
came from. You'd think that one could imbed multiple queries by using
a query instead of the attribute to nest them.
Our LDAP structure is NOT cast in stone, and this kind of functionality
is crucial. Any suggestions on building our LDAP schema to achieve
this within PMDF's apparent limitations in this area?
+----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance") InterNet: Lance.Wilkinson@psu.edu
| Systems Design Specialist - Lead AT&T: (814) 865-1818
| Digital Library Technologies FAX: (814) 863-3560
| 3 Paterno Library "I'd rather be dancing..."
| Penn State University A host is a host from coast to coast,
| University Park, PA 16802 And no one will talk to a host that's close
Unless the host that isn't close
| EMail Professional since 1978 Is busy, hung or dead.
+---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
[apologies to DeForest Kelley, 1920-1999]
junk mail declaration
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL