8:28 a.m.
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(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: gene.wilder(a)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(a)hotmail.com
entryCSN: 20071015124554Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124554Z
dn: uid=lionel.messi(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: lionel.messi(a)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(a)hotmail.com
entryCSN: 20071015124543Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124543Z
dn: uid=michael.owen(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: michael.owen(a)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(a)hotmail.com
entryCSN: 20071015124522Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124522Z
dn: uid=mariah.carey(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: mariah.carey(a)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(a)hotmail.com
entryCSN: 20071015124533Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124533Z
dn: uid=zizou(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: zizou(a)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(a)hotmail.com
entryCSN: 20071015124432Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124432Z
dn: uid=carlos.tevez(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: carlos.tevez(a)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(a)hotmail.com
entryCSN: 20071015124621Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124621Z
dn: uid=gael.clichy(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: gael.clichy(a)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(a)hotmail.com
entryCSN: 20071015124610Z#000000#00#000000
modifiersName: cn=Manager,dc=ncl,dc=ac,dc=uk
modifyTimestamp: 20071015124610Z
dn: uid=obi.martins(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk
objectClass: top
objectClass: person
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: obi.martins(a)hotmail.com
structuralObjectClass: inetOrgPerson
entryUUID: 8376746a-0d20-102c-9081-f35c0beda954
creatorsName: cn=Manager,dc=ncl,dc=ac,dc=uk
createTimestamp: 20071012150654Z
eduPersonPrincipalName: obi.martins(a)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(a)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