Re: LDAP provisioning error.

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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/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.

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