tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Importing OpenLDAP into base



Matt Sporleder pointed me at this thread...

I'll note that the original nss-ldap implementation was architecturally flawed, and its design caused a lot of problems for lots of folks. Arthur de Jong's fork of PADL's code, nss-ldapd, addresses most of those problems. In OpenLDAP we now have an NSS overlay that also addresses most of those issues. The overlay adds an NSS query handler directly into slapd. I think it would be worth your while to investigate this option, as it will help streamline system configuration overall. We'll probably integrate a PAM listener into it too but that tends to be a less frequent cause of problems.

As for cumbersome setup - it's pretty simple to create a canned config that Just Works for LDAP/Heimdal/SASL/Samba. We're already creating some sample configs for this purpose and other projects like Ubuntu are going to be working with us on that front.

Writing your own LDAP server - seems like wasted effort. The Samba guys have gone down that road as well; that was a couple man-years better spent elsewhere.

re: portability issues - file reports with stack traces from the crashes on our bug tracker. If we don't know about any bugs, we can't fix them. As an aside, I know that it runs perfectly well on Solaris Sparc64 and x86-64, so I'm sure we can nail whatever problems you've run into.

re: BerkeleyDB version - OpenLDAP supports BDB 4.2 and 4.4-4.6. 4.2 has been around for ages. (4.3 was buggy and prone to crashes, so we explicitly excluded it in our configure script.) What are you talking about, re: needing a modern version?

re: back-ldif - was never intended for use as a real backend. It was only intended to provide barely enough functionality to make back-config work.

We're looking at using Samba's libtdb to do a lightweight/zero config backend. If you're interested in that work, please followup on the openldap-devel list.

re: linux distros falling behind - yes. This is a pretty common problem, and there's not a lot we can do about it. It's up to the distro maintainers to keep in touch with us. Novell and Mandrake/Mandriva have team members who are active in the OpenLDAP developer community. Debian has recently become active as well, as has Ubuntu, so I have hopes that their situations will improve as well.

re: horrible code - pushing 100KB+ elements onto an 8MB thread stack that we allocated is no bad thing. Calling malloc/free repeatedly is a horrible thing in a threaded application. Even with a very good malloc library:
http://www.highlandsun.com/hyc/malloc/
OpenLDAP is the fastest LDAP implementation in the world today, and has been for the past 4-5 years. It is also the most spec-compliant. When you've written the world's fastest and most correct *anything*, in use by enterprises all around the world, then maybe you can judge what's horrible.

re: ASN.1 stuff - yes, OpenLDAP uses its own liblber library, as it has since the original UMich days in 1996. Of course we've tuned it extensively since then. As for BER vs DER, OpenLDAP actually uses DER anyway. It's unfortunate that everyone uses their own, but so it goes. At least ours works, unlike say the libtasn stuff used in GnuTLS.
http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
The only faster implementation than the one in our CVS is a streaming one we wrote for an FPGA.

If you tell us what issues you face, we'll help you solve them.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


Home | Main Index | Thread Index | Old Index