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.
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. 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 @(#) $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 daemon: bind(7) failed errno=98 (Address already in use) daemon: bind(7) failed errno=98 (Address already in use) slapd stopped. connections_destroy: nothing to destroy.
And when I run "lsof -i :389",
[root@pen openldap]# lsof -i :389 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME slapd 29465 ldap 7u IPv6 2066545 TCP *:ldap (LISTEN) slapd 29465 ldap 8u IPv4 2066546 TCP *:ldap (LISTEN)
I'm just a bit confused on how I can have 2 slapd processes listening on the same port when there's only one instance of slapd running. Should I "kill" one of the processes listening in at port 389? And if that is indeed the solution, which process should I kill? Once again any help or insight would be appreciated. Cheers.
Regards Sanjay
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: 02 November 2007 15:59 To: openldap-software@openldap.org Cc: Sanjay Vivek Subject: Re: LDAP provisioning error.
On Friday 02 November 2007 15:11:29 Sanjay Vivek wrote:
What we would like to happen is for the groups to be
provisioned from
Grouper to LDAP with the following entry in LDAP: dn: cn=ncl:staff,ou=grouper,dc=ncl,dc=ac,dc=uk objectClass: groupOfNames objectClass: top member: uid=john.smith@ncl.ac.uk,ou=people,dc=ncl,dc=ac,dc=uk cn: ncl:staff
The above entry tells us that we have John Smith (uid=john.smith@ncl.ac.uk) in the Staff group. The Staff group was created by Grouper and John Smith was already a member of the Staff group.
Yes, these are fairly standard groupOfNames groups ....
The way our Grouper configuration is setup is we have the all the users under "ou=people,dc=ncl,dc=ac,dc=uk". The groups are
provisioned
to "ou=grouper,dc=ncl,dc=ac,dc=uk". So
"ou=grouper,dc=ncl,dc=ac,dc=uk"
starts off empty before any provisioning activity. After the completion of provisioning, a samply entry (shown above) should be found under "ou=grouper,dc=ncl,dc=ac,dc=uk".
However, nothing is being provisioned over as described in
my previous
email. I believe its an openLDAP issue cos I've pretty much
exhausted
my Grouper options.
From your logs below, it doesn't seem so ...
I don't think its an ACL issue cos I'm binding as rootDN and so I should be able to read/write to "ou=grouper,dc=ncl,dc=ac,dc=uk".
I did a "slap -d acl" and what I got is shown below:
slapd -d acl @(#) $OpenLDAP: slapd 2.3.27 (Jan 3 2007 13:11:16) $
brewbuilder@ls20-bc1-14.build.redhat.com:/builddir/build/BUILD/openlda
p- 2.3.27/openldap-2.3.27/build-servers/servers/slapd daemon: bind(7) failed errno=98 (Address already in use) daemon: bind(7) failed errno=98 (Address already in use) slapd stopped. connections_destroy: nothing to destroy.
Well, slapd was evidently still running. Maybe you should rather set:
loglevel acl
in slapd.conf, and restart slapd via the normal means you use to start slapd, ensure that syslog is configured to log the facility slapd logs to (local4 by default), and then look for the errors. However, so far ACLs don't seem to be the problem.
And when I do a "lsof -i :389",
[root@pen openldap]# lsof -i :389 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME slapd 19048 ldap 7u IPv6 2005549 TCP *:ldap (LISTEN) slapd 19048 ldap 8u IPv4 2005550 TCP *:ldap (LISTEN)
I can't tell if this is an error or not. My LDAP server seems to be working fine so the "Address already in use" error shouldn't be popping up.
Except while your LDAP server is "working" ...
From what I gather while trawling through the mailing lists, this could be an Ipv6 issue.
???????
Is this indeed the case?
No, you can't run two processes listening on the same port and IP.
The logs (set at loglevel=256) is given below when I try to run the provisioning program. Any help would be greatly appreciated. Cheers.
Regards Sanjay
Nov 2 11:15:06 pen slapd[18902]: conn=6 fd=12 ACCEPT from IP=128.240.2.3:43541 (IP=0.0.0.0:389) Nov 2 11:15:06 pen slapd[18902]: conn=6 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Nov 2 11:15:06 pen slapd[18902]: conn=6 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Nov 2 11:15:06 pen slapd[18902]: conn=6
op=0 RESULT
tag=97 err=0 text= Nov 2 11:15:06 pen slapd[18902]: conn=7 fd=13 ACCEPT from IP=128.240.2.3:51570 (IP=0.0.0.0:389) Nov 2
11:15:06 pen
slapd[18902]: conn=7 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128 Nov 2 11:15:06 pen slapd[18902]: conn=7 op=0 BIND dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0 Nov 2 11:15:06 pen slapd[18902]: conn=7 op=0 RESULT tag=97 err=0 text= Nov 2 11:15:06 pen slapd[18902]: conn=7 op=1 UNBIND Nov 2 11:15:06 pen slapd[18902]: conn=7 fd=13 closed Nov 2 11:15:07 pen slapd[18902]: conn=8 fd=13 ACCEPT from IP=128.240.2.3:48240
(IP=0.0.0.0:389) 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=
So, it found no entry from the search it ran with the filter specified. Inspect your data, and see why this is the case. Do a search with the same filter/base/scope as the same DN, if you think the data is right ...
Nov 2 11:15:07 pen slapd[18902]: conn=8 op=2 UNBIND Nov 2 11:15:07 pen slapd[18902]: conn=8 fd=13 closed Nov 2 11:15:07 pen slapd[18902]: conn=6 op=1 UNBIND Nov 2 11:15:07 pen slapd[18902]: conn=6 fd=12 closed
At present, you've provided us with most things we would need, except the data you have, so we can't see why your application isn't finding the data it wants ... and this could simply be because it isn't there ...
Regards, Buchan