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