START slapd.conf:
overlay dynlist dynlist-attrset myGroupOfURLs myMemberURL
# happy.net: I can query through this proxy just fine. database ldap suffix "dc=happy,dc=net" uri "ldap://ldap1.lga6.us.happy.net" acl-bind bindmethod=simple binddn="cn=replicant,ou=Service Accounts,dc=happy,dc=net" credentials=my!!replicant
# happy.com: the following database has dc=happy,dc=com data in it already. database hdb suffix "" rootdn "cn=Manager,dc=happy,dc=com" rootpw secret
directory /var/lib/ldap
index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # indexes for replication index entryCSN,entryUUID eq
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200
END slapd.conf
START good dynlist entry
dn: cn=admin2,ou=Groups,dc=happy,dc=com objectClass: posixGroup objectClass: top objectClass: myGroupOfURLs cn: admin2 gidNumber: 20005 myMemberURL: ldap:///cn=sysadmins,ou=Groups,dc=happy,dc=com?memberUID?base?(objectClass=posixGroup)
works great and populates my memberUID just great.
END good dynlist entry
START bad dynlist entry dn: cn=admin2,ou=Groups,dc=happy,dc=com objectClass: posixGroup objectClass: top objectClass: myGroupOfURLs cn: admin2 gidNumber: 20005 myMemberURL: ldap:///cn=sysadmins,ou=Groups,dc=happy,dc=net?memberUID?base?(objectClass=posixGroup)
FAILS no entries in memeberUID - it a naming context mixup because "suffix ''" above?
openldap 2.3 latest
the dynlist feature works when I change the database backend from ldap to a bdb backend replica of the master. That's unfortunate, I'd like to not have to replicate the data to my local ldap box.
-judd
On Tue, Mar 27, 2012 at 3:30 PM, Judd Maltin judd@newgoliath.com wrote:
START slapd.conf:
overlay dynlist dynlist-attrset myGroupOfURLs myMemberURL
# happy.net: I can query through this proxy just fine. database ldap suffix "dc=happy,dc=net" uri "ldap://ldap1.lga6.us.happy.net" acl-bind bindmethod=simple binddn="cn=replicant,ou=Service Accounts,dc=happy,dc=net" credentials=my!!replicant
# happy.com: the following database has dc=happy,dc=com data in it already. database hdb suffix "" rootdn "cn=Manager,dc=happy,dc=com" rootpw secret
directory /var/lib/ldap
index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # indexes for replication index entryCSN,entryUUID eq
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200
END slapd.conf
START good dynlist entry
dn: cn=admin2,ou=Groups,dc=happy,dc=com objectClass: posixGroup objectClass: top objectClass: myGroupOfURLs cn: admin2 gidNumber: 20005 myMemberURL: ldap:///cn=sysadmins,ou=Groups,dc=happy,dc=com?memberUID?base?(objectClass=posixGroup)
works great and populates my memberUID just great.
END good dynlist entry
START bad dynlist entry dn: cn=admin2,ou=Groups,dc=happy,dc=com objectClass: posixGroup objectClass: top objectClass: myGroupOfURLs cn: admin2 gidNumber: 20005 myMemberURL: ldap:///cn=sysadmins,ou=Groups,dc=happy,dc=net?memberUID?base?(objectClass=posixGroup)
FAILS no entries in memeberUID - it a naming context mixup because "suffix ''" above?
-- Judd Maltin T: 917-882-1270 F: 501-694-7809 A loving heart is never wrong.
--On Wednesday, March 28, 2012 2:13 PM -0400 Judd Maltin judd@newgoliath.com wrote:
openldap 2.3 latest
This is years old. I doubt anyone is going to have an answer for you about what OpenLDAP 2.3 used to do.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap 2.3 latest
the dynlist feature works when I change the database backend from ldap to a bdb backend replica of the master. That's unfortunate, I'd like to not have to replicate the data to my local ldap box.
slapo-dynlist(5) works as expected (in 2.4) with slapd-ldap(5) as the backend serving the "DN" portion of the "memberURL". I suspect in your case the issue is related to issues like ACL, identity and similar things. You should check whether the remote server is actually contacted and how the operation is served in general. Looking at the logs (on both servers) with increasing level of verbosity, from "stats" to "stats,trace,args" would help.
p.
openldap-technical@openldap.org