Re: openldap 2.2.23 packaged with Debian Sarge

[Aaron Richton <richton@nbcs.rutgers.edu>]

> Pardon the direct mail.

This looks like it's OK by the openldap-software list charter. Please
follow up there.

> ITS #3688 deals with back-hdb.  If I plan to use back-bdb, there'd be no

Keep in mind that hdb only differs by a couple header files from bdb;
many "hdb bugs" affect both.

> any advantage over slapcat and a full DB search output to a file, as
> neither are sorted in any particular way, at least at my running version.

It's not a sort thing, but you do have more overhead (pump all the data
through network/socket vs. direct to a fd) and you run the risk of
running into ACLs/sizelimits/etc. An incomplete backup is a bad thing to
be making, slapcat reduces that risk.

> I would very much like the auto log cleanup, and a quick slave
> provisioning sounds very desirable.  But so does allowing the Debian
> team to manage my security and pre-requisites.  As I've stated, our LDAP

Yup. That's a tradeoff you'll have to make.

> So it seems you had some experience running this very version.  I would

I've run most versions since 2.1.mumble...

> ask, however, were you using the Debian package with their bugfixes and
> security updates, or did you run this minor revision as a source build?

Debian doesn't make packages for Solaris. We run our own rpms of OpenLDAP
(and everything else). See rpm.rutgers.edu.

When I run slapd on Linux--within a year--I can't imagine not running
locally packaged slapd. The fact that we need a locally developed overlay
influences this a bit, but not much.

> Again, I had good experiences with 2.3.11 except for some _extremely_
> unexpected behavior, so I'm not opposed to a source build.  I had a
[...]
> slave/slave deployment.  But the cloned slapd would frequently just stop
> running, and even an strace attached to the process and its forks did me
> no good!

Sorry to hear that. Somebody on openldap-software would likely help you
through this if you got debugging info from 2.3.23. Few on
openldap-software would be interested in working through this with 2.3.11
because we'd just pick a random ITS ("4409 is a livelock, maybe that's
it") and we'd want to make 100% sure that's not what you're running into.
The easiest way for us to know that is look at results from the fixed code.

Maybe your vendor will help you through this if it happens with their
package. I might be cynical, but I'll follow that with "probably not."

> For someone who does not deal with it frequently, the OpenLDAP product
> is a daunting one.  The prerequisite software itself is deserving of
> several pages of notes and caveats, and to put them on top of BerkelyDB
> which is itself endlessly configurable makes a guy pressed for time
> yearn for 'apt-get install openldap'

You can still use underlying binaries from your distro, at least until
those binaries are proven guilty. Even if you roll your own, it's an
up-front cost with little ongoing. My db4 is 4.2.52, and I haven't built
cyrus-sasl in a year either (2.1.18). Both of these are "out of date." But
there's never been any reason to suspect them, and the OpenLDAP community
has never yelled at me for using them. Since I built them locally, they've
got full symbols and are unstripped, so if there *is* a problem with them
I'll likely see it fast.

> I think I have convinced myself to build the latest stable, but the idea
> of taking more of my time to monitor the mailing list for "uh oh, we
> found a security flaw" chafes.

For us to build a local package of OpenLDAP literally involves changing
"2.3.21" to "2.3.23" with $EDITOR and running rpmbuild. After that, it's
lunchtime, then I have a new package when I'm back. It's not a very
brainpower-intensive job. You can monitor openldap-announce to know when
to kick off a build. It generates interrupts quite rarely.

> If you could provide just a little insight into the matter, I'd be ever
> grateful.

I have no idea if any of this is useful. Just my thoughts. The important
part is the long-standing OS vendor vs. non-OS vendor vs. in-house build
argument. Nothing new here...