5:39 a.m.
Hi,
I wnt to use the dynlist overlay to collect attribute values from
entries in different branches of the DIT, via a dynamic group like this:
dn: cn=dynamicTestList,ou=Groups,dc=local,dc=site
cn: dynamicTestList
objectclass: groupOfURLs
memberURL: ldap:///dc=local,dc=site?sn,persID?sub?(objectclass=*)
When I query this, I via
ldapsearch -x -H ldaps:/// \
-b "cn=dynamicTestList,dc=local,dc=site" -s base "(objectclass=*)"
I recieve a reasonable number of "sn" values but just one for
"persID",
despite the fact, that there should be a lot of them.
"persID" is defined SINGLE VALUE.
Is this the reason for receiving just one item and if so, what can I do
to circumvent this, i.e. retrieve all "persID" from matched entries?
BTW, does the dynlist overlay support the "cn=config" staff?
Any help will be appreciated,
Gerd
--
------------------------------------------------------
-- Gerd Schering, Email: Schering(a)tubit.TU-Berlin.DE --
------------------------------------------------------
1:53 a.m.
New subject: Question concerning the dynlist overlay and single valued attributes
Gerd Schering wrote:
I wnt to use the dynlist overlay to collect attribute values from
entries in different branches of the DIT, via a dynamic group like this:
dn: cn=dynamicTestList,ou=Groups,dc=local,dc=site
cn: dynamicTestList
objectclass: groupOfURLs
memberURL: ldap:///dc=local,dc=site?sn,persID?sub?(objectclass=*)
When I query this, I via
ldapsearch -x -H ldaps:/// \
-b "cn=dynamicTestList,dc=local,dc=site" -s base "(objectclass=*)"
I recieve a reasonable number of "sn" values but just one for
"persID",
despite the fact, that there should be a lot of them.
"persID" is defined SINGLE VALUE.
Is this the reason for receiving just one item
Yes. By design, dynlist does it best to return entries that would pass
schema checking.
and if so, what can I do
to circumvent this, i.e. retrieve all "persID" from matched entries?
What you want to do basically consists in using dynlist to generate sort
of a dynamic group, where an identifier's (persID) values are used for
membership. Usually, this would be done by assigning those values to a
(multi-valued) membership attribute (say, memberID). Dynlist does not
allow massaging, so an option would be to stack a rwm before dynlist, so
that rwm can massage the attribute names from persID to memberID before
gathering. Looks ugly.
BTW, does the dynlist overlay support the "cn=config"
staff?
Yes.
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(a)sys-net.it
---------------------------------------
6:35 a.m.
New subject: Question concerning the dynlist overlay and single valued attributes
Pierangelo Masarati wrote:
[...]
Dynlist does not
allow massaging, so an option would be to stack a rwm before dynlist, so
that rwm can massage the attribute names from persID to memberID before
gathering. Looks ugly.
Oh, yes it does! I think, I will be looking for another solution :-(
In any case, thanks a lot for your answer.
Gerd
--
------------------------------------------------------
-- Gerd Schering, Email: Schering(a)tubit.TU-Berlin.DE --
-- TU Berlin, Zentraleinrichtung Rechenzentrum --
-- Sekr. E-N 50, Einsteinufer 17, 10587 Berlin --
-- phone: +49 30 314 24383, fax: +49 30 314 21060 --
------------------------------------------------------
5769
days inactive
5770
days old
openldap-technical@openldap.org
2 comments
2 participants
participants (2)
-
Gerd Schering -
Pierangelo Masarati