[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP provisioning error.
Hi everyone,
I set loglevel=acl and I then restarted slapd. The logs I get after
running the provisioning program is given below:
Nov 6 15:40:08 pen slapd[29465]: daemon: shutdown requested and
initiated.
Nov 6 15:40:08 pen slapd[29465]: daemon: closing 7
Nov 6 15:40:08 pen slapd[29465]: daemon: closing 8
Nov 6 15:40:08 pen slapd[29465]: slapd shutdown: waiting for 0 threads
to terminate
Nov 6 15:40:08 pen slapd[29465]: slapd shutdown: initiated
Nov 6 15:40:08 pen slapd[29465]: ====> bdb_cache_release_all
Nov 6 15:40:08 pen slapd[29465]: slapd destroy: freeing system
resources.
Nov 6 15:40:08 pen slapd[29465]: slapd stopped.
Nov 6 15:40:08 pen slapd[29798]: @(#) $OpenLDAP: slapd 2.3.27 (Jan 3
2007 13:11:16) $
brewbuilder@ls20-bc1-14.build.redhat.com:/builddir/build/BUILD/openldap-
2.3.27/openldap-2.3.27/build-servers/servers/slapd
Nov 6 15:40:08 pen slapd[29799]: slapd starting
Nov 6 15:43:51 pen slapd[29799]: connection_read(13): no connection!
The logs above doesn't really say much about acl related issues. Is this
what is expected from the logs?
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
>