Red Hat Bugzilla – Bug 163190
RFE: ldap capability
Last modified: 2007-11-30 17:07:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050523 CentOS/1.0.4-1.4.1.centos4 Firefox/1.0.4
Description of problem:
The bind-ldap patch is already in the source (contrib/sdb/ldap/), but it is not part of the binary rpm. For the increasing number of people who (wish to) use ldap as a backend, it would be a blessing to have it included. Would you please?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpmbuild -bb bind.spec
Created attachment 116725 [details]
.spec to enable ldap conditionally
This .spec builds a normal unmodified bind, just like the current one, but it
accepts '--with sdb_ldap' as a build argument to enable ldap backends. This way
it doesn't burden normal flat-file bind with unnecessary features, but yet
allows those who use ldap to install or upgrade with a simple rebuild.
Created attachment 116726 [details]
This includes all required modifications according to contrib/sdb/ldap/INSTALL.
ldapdb.c and ldapdb.h could have been moved from contrib/sdb/ldap/ instead of
being included in the patch, but then ldapdb.c would still need to be patched
to enable TLS, so it seems more practical to just include both files in the
Many thanks for the patches.
RE: Patch #1: bind.spec patch:
The goal met by providing a separate named_sdb executable in the bind-sdb
sub-package, with all the contributed SDB backends compiled in, with a .spec
file flag to disable its generation, was to both provide both a "vanilla" named
for the @98% of users who do not require SDB support, and a ready-made named
with SDB support for those @2% who do, and who may have qualms about building
their own packages (eg., when the current bind-9.3.1 goes into RHEL5, only
packages built by Red Hat will be "supported").
So I think we'll be keeping the "named_sdb" way of providing SDB support,
and not integrating SDB support into a single "named" executable.
In future, it would be nice to have the sdb backend code in a separate shared
library that is only linked into named dynamically when a runtime flag is
given to named - then we can dispense with named_sdb .
RE: Patch #2:
Yes, I agree it makes sense to allow named_sdb users to use LDAP TLS support.
But not all users run TLS enabled servers.
For the next bind version, I'll make TLS support the default for ldapdb.c, but
provide a named_sdb runtime '-p' (plain?) option to disable it .
> The goal met by providing a separate named_sdb executable in the bind-sdb
I think I've missed something here. Is a bind-sdb subpackage hiding somewhere in
/people/ or FC5b?
> Yes, I agree it makes sense to allow named_sdb users to use LDAP TLS support.
> But not all users run TLS enabled servers.
I tested the TLS-enabled package I built against a non-TLS server and it worked
just fine. Also, the phrasing "Finally, if you enabled TLS when compiling, you
can also use TLS if you like" in INSTALL.ldap suggests that compiling with TLS
does not disable plain. I can't figure why default is off.
> I think I've missed something here...
Now I see bind-sdb in FC4 and even in FC3 updates. Duh. Sorry for wasting your
time - and mine.