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