[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP provisioning error.
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
>