From owner-freebsd-current Tue Jul 1 15:58:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA28283 for current-outgoing; Tue, 1 Jul 1997 15:58:57 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA28273 for ; Tue, 1 Jul 1997 15:58:54 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA05255 for current@freebsd.org; Tue, 1 Jul 1997 15:57:08 -0700 From: Terry Lambert Message-Id: <199707012257.PAA05255@phaeton.artisoft.com> Subject: LDAP update To: current@freebsd.org Date: Tue, 1 Jul 1997 15:57:08 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I have narrowed the LDAP problem down to a bad interaction with the ndbm code. When compiled to use ndbm, an explicit flush prior to a the close fails to write the data aout to the database files. The failing flush occurs in the ldif2ldbm program when it is attempting to inialize the database, and results in zero length database files. The subsequent LDAP lookups over the wire fail to obtain the requested data. I went to the BSD btree code, and the problem went away. I also went tot he BSD hash code, and the problem also went away. So there is a bug in ndbm, but I don't have it pegged any closer than that. The LDAP server is at: ftp://terminator.rs.itd.umich.edu/ldap/ldap.tar.Z if the current ndbm maintainer is interested in tracking down the problem. Use the .ps or .pdf "slapd guide", section 2 "A Quick-Start Guide to Running slapd", pages 10 and 11. In step 7 "Create a database", add the parameter "-d 65535" to get debug information about the database creation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.