8:59 a.m.
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(a)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(a)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