httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: load order dependency between mod_ldap and mod_authnz_ldap
Date Mon, 27 Jun 2011 14:04:58 GMT
On 6/27/2011 8:19 AM, Graham Leggett wrote:
> 
> mod_ldap - An LDAP shared memory cache
> mod_authnz_ldap - A user of the LDAP shared memory cache
> 
> The LDAP API exposes way more functionality than mod_ldap exposes, so while you may have
> fixed the problem for the special case that is mod_authnz_ldap, you won't have fixed
the
> problem for any other module that makes LDAP calls directly.
> 
> The v1.x LDAP API was removed from APR because it was an incomplete abstraction, and
for
> this exact same set of reasons it is inappropriate to add it to httpd.
> 
> Over and above that, given that httpd has no library component common to all modules
> (well, it has, it's called APR), and given that the httpd core is inappropriate for an
> LDAP portability library, the only place to put the LDAP bindings is in mod_ldap, which
> means we either have to accept the module ordering problems that result, or we have to
> create optional functions for every single LDAP API call, and if we do that, we end up
> solving the reason apr_ldap was removed from APR in the first place.

This is precisely the reason that you are wrong.  Only mod_ldap and
mod_authnz_ldap (and apparently mod_vhost_ldap) need functionality of
these helpers (hard to call it an API, since it doesn't actually expose
LDAP functionality).

If no other module of, nor httpd itself, needs ldap then none should bind
to ldap libraries.

Of course, following Joe's commit, we no longer have the module load order
issue (thanks Joe!  I'll review win32 within three days per Gregg's notes).

But you can't veto the status quo.  Today, mod_ldap and mod_authnz_ldap
already must bind to the ldap provider.  They are consumers of the stub
functions

And I'd nix your definition of mod_ldap... if it an "ldap shared cache
provider" then it should have been suitably named.  One can omit such a
feature and still use mod_authnz_ldap.  Of course, that was not possible
because mod_authnz_ldap required mod_ldap required the ldap helpers
required an ldap client library.

> This was an observation, not part of the veto. It's important because there are people
who
> are really keen to get v2.4 out the door, and this means practically is that a suboptimal
> API is being rushed unnecessarily into GA, and that is really really bad.

Suboptimal?  Sure.  But IJFW, which has been the critera for httpd for
as long as I've been here.  Not acceptable at APR, but just fine, here.

> The solution we agreed on in the past was to rewrite apr_ldap to fit the pattern of
> apr_dbd, but this effort was held up by a whole lot of problems in the apr_dbd API that
> were identified during review of the apr_crypto API, which was modeled on the apr_dbd
API.
> This effort was also held up by the focus on getting httpd v2.4 out the door.

No.  We didn't agree upon a solution.  We agreed upon a design pattern.
But that was never implemented, ergo never solved, ergo it's vapor.

> wrowe got impatient and removed apr_ldap from apr-trunk, which on the face of it isn't
a
> problem for httpd because apr-trunk isn't a released entity yet, nor is it likely to
be
> until the issues with apr_dbd (and as I understand apr_dbm) are fixed (among other
> issues). This move just forces us to solve the apr_ldap issue before apr v2.0 is released.
> It doesn't however put httpd under any obligation to take any drastic measures for httpd
> v2.4, because the existing apr_ldap library exists and is supported in apr v1.x.

You are absolutely right, httpd is under no obligation to support APR 2.0,
or APR 1.x, or pocore, or any other library.  It is an independent project.

> In short, when httpd v2.4 is released, we will be free to focus our attention on apr_ldap
> and get it fixed.
> 
> There is no need for any temporary hacks before then (where "temporary" is defined as
> "permanently baked into the httpd v2.4 API").

I have no expectation that it will be fixed, and the majority voted at
APR to evict apr_ldap, therefore it is gone (not be veto or fiat, but
by the preference of the majority).  I have reacted accordingly because
httpd would not have been happy if it had abandoned these helpers and
they were not present for httpd's consumption.

On the assumption that APR and httpd are now distinct, that httpd will
not require httpd-deps to run, and that httpd will hopefully consume
apr 1.x or apr 2.0 once it is released, this solution is correct for
the short term health of httpd.

httpd and apr major.minor lifespans have been measured in decades
(.5 .. 1.5) and it would be foolish to ship something another project
has abandoned, which was the basis of questioning if expat was the
right choice going forwards.  With the addition of libxml2 support it
is no longer a question or risk.  apr_ldap was a risk, and this change
proposed to fix it.

I agree with Joe's work to complete this, and it is not a veto'able
change for reasons rehashed on two dev lists.  Call a vote to reject
providing ap_ldap in httpd 2.4, if you like.  Because the technical
solution is identical to the technical solution previously provided
in httpd 2.2 with apr-util 1.x, there isn't a technical basis to your
objection.

Because you are trying to pull an end-run around the eviction of the
apr_ldap API (which would go something like "apr 2.0 didn't ship with
apr_ldap so I veto httpd picking up that version") there is not even
merit to your veto.  A few weeks ago you wanted a dozen apr-util-foo
libraries.

If there is someday merit to adopting a full-fledged ldap provider
in APR with actual source code, and a later version of httpd decides
to use that APR major.minor as a minimum version level, then things
will be great and httpd/mod_[foo_]ldap will never link to an ldap
client library again.  But in terms of carts and horses, ldap is
part of the horse, and you know which end some of us consider it.

Mime
View raw message