Bug 163190
Summary: | RFE: ldap capability | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Zenon Panoussis <redhatbugs> | ||||||
Component: | bind | Assignee: | Jason Vas Dias <jvdias> | ||||||
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 4.0 | Keywords: | FutureFeature | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Enhancement | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-07-14 11:56:18 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Zenon Panoussis
2005-07-13 21:22:57 UTC
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]
sbb-ldap patch
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
patch.
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 > sub-package... 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.
|