Just as a refresher, here's your logs from a previous post (had to go back and look em up):

Nov 2 11:15:07 pen slapd[18902]: conn=8 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Nov 2 11:15:07 pen slapd[18902]: conn=8 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Nov 2 11:15:07 pen slapd[18902]: conn=8 op=0 RESULT tag=97 err=0 text= Nov 2 11:15:07 pen slapd[18902]: conn=8 op=1 SRCH base="ou=people,dc=ncl,dc=ac,dc=uk" scope=2 deref=3 filter="(&(uid=groupersystem)(objectClass=eduPerson))" Nov 2 11:15:07 pen slapd[18902]: conn=8 op=1 SRCH attr=cn cn uid Nov 2 11:15:07 pen slapd[18902]: conn=8 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Your app is doing a search under "ou=people,dc=ncl,dc=ac,dc=uk" for all entries matching "(&(uid=groupersystem)(objectClass=eduPerson))", and you find no matching entries (which is not surprising, since none of your sample entries match this search criteria).

From your slapcat output below, none of your entries have the uid

"groupersystem", so I'm not sure how you expected this to find any matches to put into groups... You say that in another directory server, this worked? With the exact same data? This same data in another ldap server would yield the same results - basically, that there is nothing there to match what you want to find.

Given the above search filter "Grouper" performed, and looking at your data from slapcat, which entries do you expect to match, and how do you expect them to match that filter (i.e. in your mind, which entries have a uid of groupersystem AND an objectclass of eduPerson)?

Maybe export some matching sample users from the "other" directory server that got put into groups to see the differences, and why that search filter matches on that server and not in OpenLDAP. My guess is that the data is not really the same in both servers.

- Jeff

-----Original Message----- From: openldap-software-bounces+jeff_clowser=fanniemae.com@openldap.org [mailto:openldap-software-bounces+jeff_clowser=fanniemae.com@openldap.or g] On Behalf Of Sanjay Vivek Sent: Tuesday, November 06, 2007 11:28 AM To: Buchan Milne Cc: openldap-software@openldap.org Subject: RE: LDAP provisioning error.

... I also did a slapcat and the results are given below:

[root@pen openldap]# slapcat dn: dc=ncl,dc=ac,dc=uk description: Top level LDAP for ncl.ac.uk objectClass: top objectClass: dcObject objectClass: organization o: ncl dc: ncl structuralObjectClass: organization entryUUID: 958bf658-d39a-102b-925e-4d93d2b0c899 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20070731101436Z entryCSN: 20070731101436Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20070731101436Z

dn: ou=people,dc=ncl,dc=ac,dc=uk ou: people objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 958c9568-d39a-102b-925f-4d93d2b0c899 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20070731101436Z entryCSN: 20070731101436Z#000001#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20070731101436Z

dn: ou=grouper,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: organizationalUnit ou: grouper structuralObjectClass: organizationalUnit entryUUID: a5afe04c-0b8c-102c-985e-95f106e50073 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071010145555Z description: location in which to root provisioned groups entryCSN: 20071015081104Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015081104Z

dn: uid=gene.wilder@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: gene.wilder@hotmail.com cn: Gene Wilder sn: Wilder structuralObjectClass: inetOrgPerson entryUUID: 82227ea6-0d20-102c-907a-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150652Z eduPersonPrincipalName: gene.wilder@hotmail.com entryCSN: 20071015124554Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124554Z

dn: uid=lionel.messi@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: lionel.messi@hotmail.com cn: Lionel Messi sn: Messi structuralObjectClass: inetOrgPerson entryUUID: 82542780-0d20-102c-907b-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150652Z eduPersonPrincipalName: lionel.messi@hotmail.com entryCSN: 20071015124543Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124543Z

dn: uid=michael.owen@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: michael.owen@hotmail.com cn: Michael Owen sn: Owen structuralObjectClass: inetOrgPerson entryUUID: 82850904-0d20-102c-907c-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: michael.owen@hotmail.com entryCSN: 20071015124522Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124522Z

dn: uid=mariah.carey@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: mariah.carey@hotmail.com cn: Mariah Carey sn: Carey structuralObjectClass: inetOrgPerson entryUUID: 82b47dba-0d20-102c-907d-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: mariah.carey@hotmail.com entryCSN: 20071015124533Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124533Z

dn: uid=zizou@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: zizou@hotmail.com cn: Zinedine Zindane sn: Zindane structuralObjectClass: inetOrgPerson entryUUID: 82dfb08e-0d20-102c-907e-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: zizou@hotmail.com entryCSN: 20071015124432Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124432Z

dn: uid=carlos.tevez@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: carlos.tevez@hotmail.com cn: Carlos Tevez sn: Tevez structuralObjectClass: inetOrgPerson entryUUID: 83166124-0d20-102c-907f-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150653Z eduPersonPrincipalName: carlos.tevez@hotmail.com entryCSN: 20071015124621Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124621Z

dn: uid=gael.clichy@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: gael.clichy@hotmail.com cn: Gael Clichy sn: Clichy structuralObjectClass: inetOrgPerson entryUUID: 834a1a50-0d20-102c-9080-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150654Z eduPersonPrincipalName: gael.clichy@hotmail.com entryCSN: 20071015124610Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124610Z

dn: uid=obi.martins@hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk objectClass: top objectClass: person objectClass: eduPerson objectClass: organizationalPerson objectClass: inetOrgPerson uid: obi.martins@hotmail.com structuralObjectClass: inetOrgPerson entryUUID: 8376746a-0d20-102c-9081-f35c0beda954 creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk createTimestamp: 20071012150654Z eduPersonPrincipalName: obi.martins@hotmail.com sn: Martins cn: Obi Martins entryCSN: 20071015124507Z#000000#00#000000 modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk modifyTimestamp: 20071015124507Z

As the results above indicate, there are 2 ou's (ou=grouper and ou=people). And there are 8 sample users under ou=people. So basically what's supposed to happen is for the provisioning program to provision the Grouper groups to "ou=grouper,dc=ncl,dc=ac,dc=uk" and it looks for the users in each group under "ou=people,dc=ncl,dc=ac,dc=uk". This is where the LDAP search filter comes in. The search filter looks for the users under "ou=people,dc=ncl,dc=ac,dc=uk".

Something stops Grouper from provisioning the groups over to the LDAP server and I still believe it's something to do with my openLDAP configuration. My Grouper installation/configuration has been replicated on another server and everything seems to be working fine. Cheers.

Regards Sanjay

-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: 06 November 2007 15:27 To: Sanjay Vivek Cc: openldap-software@openldap.org Subject: Re: LDAP provisioning error.

On Tuesday 06 November 2007 16:49:29 Sanjay Vivek wrote:

...

Hi again,

I don't think the errors have anything to with the LDAP

search filter

...

because it works perfectly fine with a similar installation with another LDAP server. The only difference between both installions is the LDAP server. So something about my openLDAP configuration is messing up the LDAP provisioning.

But thus far you haven't provided anything that anyone can use to try and find out what is wrong with your configuration. Please try and include logs relating to all the operations on a connection, where an ADD, MOD, or DEL operation is done on the connection. A connection with one bind and one search, is almost useless (unless you can show the data in the directory that should be found by that search).

...

I did a "ps -fade | grep slapd"

[root@pen openldap]# ps -fade | grep slapd ldap 29465 1 0 11:51 ? 00:00:00 /usr/sbin/slapd -h ldap:/// -u ldap root 29616 28950 0 13:53 pts/0 00:00:00 grep slapd

So this means that only one instance of slapd is running.

BUT YOU ARE NOW ABOUT TO TRY TO START A SECOND ONE!!!!!

...

So why do I get a "daemon: bind(7) failed errno=98 (Address already in

use)" error

...

when I run "slapd -d acl" as shown below:

[root@pen openldap]# slapd -d acl

But, this is starting slapd. By default, it will try and bind to port 389 on all IPs. So, you should stop this one, if you *really* want to start a slapd as above. Instead, maybe you should add:

loglevel acl

and restart the ldap service ('service ldap restart'), and then (if your syslog is configured to log for slapd) you should end up with acl-related entries in your log files.

Regards, Buchan