[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: LDAP provisioning error.

To: Sanjay Vivek <Sanjay.Vivek@newcastle.ac.uk>
Subject: RE: LDAP provisioning error.
From: Aaron Richton <richton@nbcs.rutgers.edu>
Date: Tue, 6 Nov 2007 10:32:46 -0500 (EST)
Cc: Buchan Milne <bgmilne@staff.telkomsa.net>, openldap-software@openldap.org
In-reply-to: <88493EDAE8A32D4EA88F17102879E3950504BC1E@moonraker.campus.ncl.ac.uk>
References: <88493EDAE8A32D4EA88F17102879E3950504BC1C@moonraker.campus.ncl.ac.uk> <200711021759.01078.bgmilne@staff.telkomsa.net> <88493EDAE8A32D4EA88F17102879E3950504BC1E@moonraker.campus.ncl.ac.uk>

The single process is listening on two different port 389s; one is IPv4 and the other is IPv6. This is absolutely fine. If you don't want one or the other, start slapd with "-4" or "-6" options.

What's not fine is that you can't run slapd twice with the same port(s) nor backend(s). Basically, if "pgrep slapd" isn't clean, don't bother trying to run "slapd -d acl" until you stop the existing slapd process and "pgrep slapd" returns no output. Then and only then try to "slapd -d acl" or whatever debug level you want.

The current working theory I'm reading is that the data you're expecting just isn't there. Perhaps you should use slapcat(8) to dump your database and verify that the entries you're trying to find actually exist? Again, so long as you're configured with rootdn, it's hard to imagine this is an ACL issue.

References:
- RE: LDAP provisioning error.
  - From: "Sanjay Vivek" <Sanjay.Vivek@newcastle.ac.uk>
- Re: LDAP provisioning error.
  - From: Buchan Milne <bgmilne@staff.telkomsa.net>
- RE: LDAP provisioning error.
  - From: "Sanjay Vivek" <Sanjay.Vivek@newcastle.ac.uk>

Prev by Date: Re: LDAP provisioning error.
Next by Date: Re: LDAP provisioning error.
Index(es):
- Chronological
- Thread