[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: LDAP provisioning error.

To: "Sanjay Vivek" <Sanjay.Vivek@newcastle.ac.uk>, "Buchan Milne" <bgmilne@staff.telkomsa.net>
Subject: RE: LDAP provisioning error.
From: "Clowser, Jeff (Contractor)" <jeff_clowser@fanniemae.com>
Date: Tue, 6 Nov 2007 12:34:09 -0500
Cc: openldap-software@openldap.org
Content-class: urn:content-classes:message
Thread-index: AcggiZilMo+8X0AcR0OlhuJX9GxlEAAAod0AAALSQjAAADQQ0A==
Thread-topic: LDAP provisioning error.
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
>
Prev by Date: Re: LDAP provisioning error.
Next by Date: RE: LDAP provisioning error.
Index(es):
- Chronological
- Thread