Re: Automated tests

[William A Rowe Jr]

On Dec 30, 2016 14:55, "Stefan Fritsch"  wrote:

Hi,

it's quite rare that I have a bit of time for httpd nowadays. But  I want to
comment on a mail that Jacob Champion wrote on -security that contains some
valid points about the lack of our test framework. I am posting this to -dev
with his permission.

On Wednesday, 21 December 2016 08:55:30 CET Jacob Champion wrote:
> - Our APIs are really complex, and we don't really have unit tests for
> them. Nor are the internal APIs documented as well as the external APIs
> are. We had a few false starts for security fixes this release that were
> later shown to break something else, and I think that's related.

Yes, httpd lacks unit tests. One problem is that many APIs depend on very
complex structs like request_rec, conn_rec, server_conf, etc. In order to
write unit tests for such APIs, one would need to write quite a bit of
infrastructure to set these things up. I think it would be worth the effort,
but it's not a small task. As there does not seem to be anybody with enough
spare time to do it, one could possibly ask someone (CII?) for funding.

A possible approach would be to compile the unit tests in the server and
execute them on startup if a special define is given (like the various
DUMP_*
defines). Not sure how to get access to all the static helper function for
unit
tests, though. Unless one would somehow include the tests in the same .c
file.


Thinking two things would help.

Splitting our functional utilities into a libaputil would make it much
easier to write the tests that exercise these elements of our code.

And what I found easiest is a dedicated module to provide diagnostics or
tests. When not loaded, they are skipped.

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Daniel Ruggeri]

On 12/30/2016 8:37 PM, William A Rowe Jr wrote:
> Simply address the issue that caused the -1... 'Code mostly
> copyright...' needs to be 'Portions copyright'... A statement which is
> unlikely to become entirely false.

OK, got it. It wasn't entirely clear to me that was the hangup.


On 12/30/2016 8:34 PM, Eric Covener wrote:
> Hi Daniel, not to pull you in too many directions, but I would suggest
> to revert r1776674 and go back to erring on the side of attribution
> until we can arrive at a consensus.The license requires that
> copyright notices are preserved in derivative works.

Understood. Since it was a lapse in my initial commit that I didn't add
to CHANGES already, I'd like to keep r1776674 to cover that mistake, but
adjust mod_remoteip.c as Bill mentions.

I will do that later this evening or in the morning in the absence of
any disagreement.

-- 
Daniel Ruggeri

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[William A Rowe Jr]

Simply address the issue that caused the -1... 'Code mostly copyright...'
needs to be 'Portions copyright'... A statement which is unlikely to become
entirely false.


On Dec 30, 2016 18:28, "Daniel Ruggeri"  wrote:

> Aye - I suspected this would raise eyebrows so I did bring it up a few
> times [1][2]. I'm sure we're in agreement that attribution is important
> in the Open Source world so I'd like to be sure it's done appropriately.
> I'm happy to fix.
>
> Currently, though, I'm not sure how best to handle this veto... what
> would be the preferred path forward? As a first step, I've remove the
> three lines mentioned here and added to CHANGES in r1776674. The 2.4
> backport has also been modified (simply by removing the lines since
> CHANGES already has attribution to the original authors which seems to
> be preferred per your message).
>
> Does that work or did you have another approach in mind?
>
> [1]
> https://lists.apache.org/thread.html/95173df808992097f565bc7bcd06a0
> 1b2129415bff0aae6c608b82fe@%3Cdev.httpd.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/28e660f38d945216d9d0bb4cba3e1b
> 4336a4c5051a46f17c8f99a0f0@%3Cdev.httpd.apache.org%3E
>
>
> --
> Daniel Ruggeri
>
> On 12/30/2016 8:00 PM, William A Rowe Jr wrote:
> > -1 (yes, veto.)
> >
> > In general, as the original author of this particular module, you
> > might notice I don't claim attribution. We rely on svn provenance and
> > Changes to describe code legacy, so these make me very uncomfortable,
> > especially when injected into our sources. That isn't the key issue.
> >
> > The statement itself may be presently true. The statement a number of
> > years from now might be radically false. The presence of this
> > statement makes it impossible for the future svn hacker to know when
> > to modify the statement or determine when the sources have changed
> > such that it becomes untrue.
> >
> > It is a relativistic value judgement, and these aren't useful as
> > legalistic elements, so the conventional 'portions copyright...' sort
> > of language is used instead.
>
>

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Eric Covener]

On Fri, Dec 30, 2016 at 9:27 PM, Daniel Ruggeri  wrote:
> Aye - I suspected this would raise eyebrows so I did bring it up a few
> times [1][2]. I'm sure we're in agreement that attribution is important
> in the Open Source world so I'd like to be sure it's done appropriately.
> I'm happy to fix.
>
> Currently, though, I'm not sure how best to handle this veto... what
> would be the preferred path forward? As a first step, I've remove the
> three lines mentioned here and added to CHANGES in r1776674. The 2.4
> backport has also been modified (simply by removing the lines since
> CHANGES already has attribution to the original authors which seems to
> be preferred per your message).
>
> Does that work or did you have another approach in mind?

Hi Daniel, not to pull you in too many directions, but I would suggest
to revert r1776674 and go back to erring on the side of attribution
until we can arrive at a consensus.The license requires that
copyright notices are preserved in derivative works.

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Daniel Ruggeri]

Aye - I suspected this would raise eyebrows so I did bring it up a few
times [1][2]. I'm sure we're in agreement that attribution is important
in the Open Source world so I'd like to be sure it's done appropriately.
I'm happy to fix.

Currently, though, I'm not sure how best to handle this veto... what
would be the preferred path forward? As a first step, I've remove the
three lines mentioned here and added to CHANGES in r1776674. The 2.4
backport has also been modified (simply by removing the lines since
CHANGES already has attribution to the original authors which seems to
be preferred per your message).

Does that work or did you have another approach in mind?

[1]
https://lists.apache.org/thread.html/95173df808992097f565bc7bcd06a01b2129415bff0aae6c608b82fe@%3Cdev.httpd.apache.org%3E
[2]
https://lists.apache.org/thread.html/28e660f38d945216d9d0bb4cba3e1b4336a4c5051a46f17c8f99a0f0@%3Cdev.httpd.apache.org%3E


-- 
Daniel Ruggeri

On 12/30/2016 8:00 PM, William A Rowe Jr wrote:
> -1 (yes, veto.)
>
> In general, as the original author of this particular module, you
> might notice I don't claim attribution. We rely on svn provenance and
> Changes to describe code legacy, so these make me very uncomfortable,
> especially when injected into our sources. That isn't the key issue.
>
> The statement itself may be presently true. The statement a number of
> years from now might be radically false. The presence of this
> statement makes it impossible for the future svn hacker to know when
> to modify the statement or determine when the sources have changed
> such that it becomes untrue.
>
> It is a relativistic value judgement, and these aren't useful as
> legalistic elements, so the conventional 'portions copyright...' sort
> of language is used instead.

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Eric Covener]

On Fri, Dec 30, 2016 at 9:00 PM, William A Rowe Jr  wrote:
> On Dec 30, 2016 06:20,  wrote:
>
> Author: druggeri
> Date: Fri Dec 30 14:20:48 2016
> New Revision: 1776575
>
> URL: http://svn.apache.org/viewvc?rev=1776575=rev
> Log:
> Merge new PROXY protocol code into mod_remoteip
>
> Modified:
> httpd/httpd/trunk/docs/log-message-tags/next-number
> httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
> httpd/httpd/trunk/modules/metadata/mod_remoteip.c
>
>
> ==
> --- httpd/httpd/trunk/modules/metadata/mod_remoteip.c (original)
> +++ httpd/httpd/trunk/modules/metadata/mod_remoteip.c Fri Dec 30 14:20:48
> 2016
> @@ -12,15 +12,20 @@
>   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>   * See the License for the specific language governing permissions and
>   * limitations under the License.
> + *
> + * The majority of the input filter code for PROXY protocol support is
> + * Copyright 2014 Cloudzilla Inc.
>   */
>
>
> -1 (yes, veto.)
>
> In general, as the original author of this particular module, you might
> notice I don't claim attribution. We rely on svn provenance and Changes to
> describe code legacy, so these make me very uncomfortable, especially when
> injected into our sources. That isn't the key issue.
>
> The statement itself may be presently true. The statement a number of years
> from now might be radically false. The presence of this statement makes it
> impossible for the future svn hacker to know when to modify the statement or
> determine when the sources have changed such that it becomes untrue.
>
> It is a relativistic value judgement, and these aren't useful as legalistic
> elements, so the conventional 'portions copyright...' sort of language is
> used instead.

Maybe something like this (for a start?)I think we have to keep
something here.

Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c (revision 1776673)
+++ modules/metadata/mod_remoteip.c (working copy)
@@ -13,8 +13,9 @@
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
- * The majority of the input filter code for PROXY protocol support is
- * Copyright 2014 Cloudzilla Inc.
+ * Portions Copyright 2014 Cloudzilla Inc.:
+ *   remoteip_input_filter() based on mod_proxy_protocol
+ *   https://github.com/roadrunner2/mod-proxy-protocol 62d2df6
 */

#include "ap_config.h"


-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[William A Rowe Jr]

On Dec 30, 2016 06:20,  wrote:

Author: druggeri
Date: Fri Dec 30 14:20:48 2016
New Revision: 1776575

URL: http://svn.apache.org/viewvc?rev=1776575=rev
Log:
Merge new PROXY protocol code into mod_remoteip

Modified:
httpd/httpd/trunk/docs/log-message-tags/next-number
httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
httpd/httpd/trunk/modules/metadata/mod_remoteip.c



==
--- httpd/httpd/trunk/modules/metadata/mod_remoteip.c (original)
+++ httpd/httpd/trunk/modules/metadata/mod_remoteip.c Fri Dec 30 14:20:48
2016
@@ -12,15 +12,20 @@
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
+ *
+ * The majority of the input filter code for PROXY protocol support is
+ * Copyright 2014 Cloudzilla Inc.
  */


-1 (yes, veto.)

In general, as the original author of this particular module, you might
notice I don't claim attribution. We rely on svn provenance and Changes to
describe code legacy, so these make me very uncomfortable, especially when
injected into our sources. That isn't the key issue.

The statement itself may be presently true. The statement a number of years
from now might be radically false. The presence of this statement makes it
impossible for the future svn hacker to know when to modify the statement
or determine when the sources have changed such that it becomes untrue.

It is a relativistic value judgement, and these aren't useful as legalistic
elements, so the conventional 'portions copyright...' sort of language is
used instead.

Re: Post 2.4.25

[Stefan Fritsch]

On Saturday, 24 December 2016 08:29:35 CET Rich Bowen wrote:
> From my perspective, watching Nginx gain traction through superior
> marketing, and channeling Dilbert's Pointy Haired Boss in assuming that
> everything which I have never done must be simple, I, for one, would
> like to see us release a 2.6, and more generally, to release a 2.x every
> 2 years, or less, rather than every 4 years, or more.

There is the problem that on the one hand, one should do some invasive changes 
in trunk to improve the architecture. On the other hand, this is problematic 
if the 2.6/3.0 release is not coming soon because

* it makes it difficult to backport stuff to 2.4.x

* there is the danger that the people who did the invasive changes are no 
longer around when 2.6/3.0 is actually release. We had this problem with the 
authn/authz stuff for 2.4, which took quite some time to get fixed.

* the longer 2.6/3.0 takes the more half-baked/half-finished stuff accumulates 
that needs to be fixed before a release.

But I don't have any ideas how to resolve this.

Cheers,
Stefan

Automated tests

[Stefan Fritsch]

Hi,

it's quite rare that I have a bit of time for httpd nowadays. But  I want to 
comment on a mail that Jacob Champion wrote on -security that contains some 
valid points about the lack of our test framework. I am posting this to -dev 
with his permission.

On Wednesday, 21 December 2016 08:55:30 CET Jacob Champion wrote:
> - Our APIs are really complex, and we don't really have unit tests for
> them. Nor are the internal APIs documented as well as the external APIs
> are. We had a few false starts for security fixes this release that were
> later shown to break something else, and I think that's related.

Yes, httpd lacks unit tests. One problem is that many APIs depend on very 
complex structs like request_rec, conn_rec, server_conf, etc. In order to 
write unit tests for such APIs, one would need to write quite a bit of 
infrastructure to set these things up. I think it would be worth the effort, 
but it's not a small task. As there does not seem to be anybody with enough 
spare time to do it, one could possibly ask someone (CII?) for funding.

A possible approach would be to compile the unit tests in the server and 
execute them on startup if a special define is given (like the various DUMP_* 
defines). Not sure how to get access to all the static helper function for unit 
tests, though. Unless one would somehow include the tests in the same .c file.

> == Tests and Test Culture ==
> 
> Tests for security fixes are especially important, to prevent
> regressions from committers who weren't part of the embargoed
> conversations. But our current test battery isn't deep enough to match
> the complexity of the server, and many fixes for complex bugs (whether
> security-related or not) are going in without test cases.
> 
> Compared to many other test suites I have used, our tests:
> - are difficult for newcomers to install, run, write, and/or extend
> - are not committed in the same breath as the bugfixes or features they
> test, since they exist in a separate project root
> - are not low-level enough to test our C API directly, at least as far
> as I can tell. (I.e. if your code can't be easily called from a module,
> you're out of luck.)

If the test suite would be easier to run, maybe more people would submit 
tests. Is there a reason why the test suite is in a separate repository? Would 
it help if it was moved into the normal httpd repo? Would it make sense to 
include it in the release tarballs, possibly including the necessary non-
standard perl modules? And include it in the makefiles in a way that a user can 
install a set of standard perl modules (from a distribution or cpan) and then 
call "make test" to start it. What is in the test/ dir in the httpd repo right 
now seems mostly useless and could probably be removed.

Another idea to make writing tests more attractive could be to somehow include 
it in the backporting policy. For example, if there is a test for a new 
feature (positive and error handling) or a bug fix, we could require only two 
+1s for a backport.


> For a guy like me who prefers doing his own work test-driven, it's just
> kinda painful.
> 
> Furthermore, the Apache::Test project appears to be a separate thing
> entirely...? I don't know *how* separate it is, but I consider that a
> red flag. To write code quickly, the way you need to when faced with
> immediate security problems, you need 100% control of your test suite --
> including the ability to write embargoed tests.
> 
> To give you a concrete example: I know that one of the httpd tests I
> wrote before being invited to this project was left uncommitted, because
> it would have required changes to Apache::Test, and that just wasn't
> worth the effort.

I have never tried to change Apache::Test. But in any case, understanding it 
enough to fix or extend it is a significant hurdle.

Another thing that is missing: A buildbot that builds current trunk (and 
possibly 2.x branches) and runs the test suite and alerts the dev list of 
regressions. I guess this "just" needs a volunteer to set it up and document 
it and the ASF would provide the infrastructure.

Cheers,
Stefan

Re: svn commit: r1776616 - in /httpd/httpd/trunk/docs/manual/mod: mod_remoteip.html.en mod_remoteip.xml.fr mod_remoteip.xml.meta

[Luca Toscano]

2016-12-30 20:07 GMT+01:00 Daniel Ruggeri :

> On 12/30/2016 12:47 PM, Luca Toscano wrote:
> > I personally like a lot RemoteIPProxyProtocol (rather than
> > RemoteIPProxyProtocolEnable that seems a bit heavy to read), but
> > everything is fine as long as we use a single name, especially in the
> > logs that admins will read :)
> >
> > I haven't checked the code in detail so I might say something
> > completely irrelevant, just writing the first things that I noticed!
>
> Hrm - yes... these are inconsistencies that came up as I was renaming
> stuff and moving it around. I also like the suggestion to shorten the
> name since "Enable" is repetitive... I have adjusted the references to
> be RemoteIPProxyProtocol in docs and code, fixed references to the
> "PROXY protocol" to align with the case that HAProxy uses as well as
> removed the mod_proxy_protocol module in r1776624. Thanks for the pointer.



Just updated the mod_remoteip doc after your last commit, it looks really
nice now! Thanks a lot!

Luca

Re: svn commit: r1776616 - in /httpd/httpd/trunk/docs/manual/mod: mod_remoteip.html.en mod_remoteip.xml.fr mod_remoteip.xml.meta

[Daniel Ruggeri]

On 12/30/2016 12:47 PM, Luca Toscano wrote:
> I personally like a lot RemoteIPProxyProtocol (rather than
> RemoteIPProxyProtocolEnable that seems a bit heavy to read), but
> everything is fine as long as we use a single name, especially in the
> logs that admins will read :)
>
> I haven't checked the code in detail so I might say something
> completely irrelevant, just writing the first things that I noticed!

Hrm - yes... these are inconsistencies that came up as I was renaming
stuff and moving it around. I also like the suggestion to shorten the
name since "Enable" is repetitive... I have adjusted the references to
be RemoteIPProxyProtocol in docs and code, fixed references to the
"PROXY protocol" to align with the case that HAProxy uses as well as
removed the mod_proxy_protocol module in r1776624. Thanks for the pointer.

-- 
Daniel Ruggeri

Re: svn commit: r1776616 - in /httpd/httpd/trunk/docs/manual/mod: mod_remoteip.html.en mod_remoteip.xml.fr mod_remoteip.xml.meta

[Luca Toscano]

Hi Daniel and Jim,

I saw your comments in one of the last email thread about Daniel's new code
change for mod_remoteip, and I have some questions for the doc about the
naming of the new directive:

2016-12-30 19:20 GMT+01:00 :

> Author: elukey
> Date: Fri Dec 30 18:20:04 2016
> New Revision: 1776616
>
> URL: http://svn.apache.org/viewvc?rev=1776616=rev
> Log:
> Documentation rebuild for mod_remoteip
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/mod_remoteip.html.en
> httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml.fr
> httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml.meta
>
> +using the RemoteIPProxyProtocolEnable



> + id="RemoteIPProxyProtocol">RemoteIPProxyProtocol  name="remoteipproxyprotocol" id="remoteipproxyprotocol">Directive
>


> + href="directive-dict.html#Syntax">Syntax:ProxyProtocol
> On|Optional|Off



In the above snippets I can see three different names:
RemoteIPProxyProtocolEnable, RemoteIPProxyProtocol and ProxyProtocol. The
new directive in the C code is called RemoteIPProxyProtocolEnable, but I
can see new logs using also RemoteIPProxyProtocol (like
"RemoteIPProxyProtocol: internal error: have data left over; ").

I personally like a lot RemoteIPProxyProtocol (rather than
RemoteIPProxyProtocolEnable that seems a bit heavy to read), but everything
is fine as long as we use a single name, especially in the logs that admins
will read :)

I haven't checked the code in detail so I might say something completely
irrelevant, just writing the first things that I noticed!

Luca

Re: mod_proxy's forced module_selection=most? (Was: --enable-mods-shared don't work)

[Yann Ylavic]

On Fri, Dec 30, 2016 at 6:02 PM, Yann Ylavic  wrote:
>
> Any reason why we need to force the "most" selection for proxy modules?
> This is already the default module_selection, and if --enable-modules
> is used (with the admin supposed to know what [s]he does), it'll
> break...
>
> Also it seems that we force module_default to the value of
> --enable-proxy (when "shared" or "static"), though I see no reason to
> force "static".
> Forcing "shared" is probably relevant if we don't want proxy
> submodules to be loaded statically with mod_proxy itself being
> dynamic, but one may want a static mod_proxy with dynamic mod_proxy_*
> (at least it doesn't break).

I'm thinking of the attached patch...
Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4	(revision 1776295)
+++ modules/proxy/config.m4	(working copy)
@@ -5,18 +5,14 @@ APACHE_MODPATH_INIT(proxy)
 proxy_objs="mod_proxy.lo proxy_util.lo"
 APACHE_MODULE(proxy, Apache proxy module, $proxy_objs, , most)
 
-dnl set aside module selections and default, and set the module default to the
-dnl same scope (shared|static) as selected for mod proxy, along with setting
-dnl the default selection to "most" for remaining proxy modules, mirroring the
-dnl behavior of 2.4.1 and later, but failing ./configure only if an explicitly
-dnl enabled module is missing its prereqs
-save_module_selection=$module_selection
+dnl set aside module default, and set it to the same scope shared if selected
+dnl for mod proxy, along with setting the default selection to "most" for
+dnl remaining proxy modules, mirroring the behavior of 2.4.1 and later, but
+dnl failing ./configure only if an explicitly enabled module is missing its
+dnl prereqs
 save_module_default=$module_default
-if test "x$enable_proxy" != "xno"; then
-module_selection=most
-if test "$enable_proxy" = "shared" -o "$enable_proxy" = "static"; then
-module_default=$enable_proxy
-fi
+if test "x$enable_proxy" = "xshared"; then
+module_default=shared
 fi
 
 proxy_connect_objs="mod_proxy_connect.lo"
@@ -78,7 +74,6 @@ APACHE_MODULE(proxy_hcheck, [reverse-proxy health-
 
 APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])
 
-module_selection=$save_module_selection
 module_default=$save_module_default
 
 APACHE_MODPATH_FINISH

mod_proxy's forced module_selection=most? (Was: --enable-mods-shared don't work)

[Yann Ylavic]

On Fri, Dec 30, 2016 at 5:16 PM, Yann Ylavic 
>>
>> How would the attached patch work for you?
>
> I mean with --enable-modules=none and then your exhaustive
> --enable-mods-shared/static list.

Any reason why we need to force the "most" selection for proxy modules?
This is already the default module_selection, and if --enable-modules
is used (with the admin supposed to know what [s]he does), it'll
break...

Also it seems that we force module_default to the value of
--enable-proxy (when "shared" or "static"), though I see no reason to
force "static".
Forcing "shared" is probably relevant if we don't want proxy
submodules to be loaded statically with mod_proxy itself being
dynamic, but one may want a static mod_proxy with dynamic mod_proxy_*
(at least it doesn't break).

Regards,
Yann.
Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4	(revision 1776076)
+++ modules/proxy/config.m4	(working copy)
@@ -13,7 +13,7 @@ dnl enabled module is missing its prereqs
 save_module_selection=$module_selection
 save_module_default=$module_default
 if test "$enable_proxy" != "no"; then
-module_selection=most
+dnl module_selection=most
 if test "$enable_proxy" = "shared" -o "$enable_proxy" = "static"; then
 module_default=$enable_proxy
 fi

RE: The Version Bump fallacy [Was Re: Post 2.4.25]

[Houser, Rick]

I agree with a lot of what Daniel says, and I'm in a similar role with 
maintaining my organization's httpd RPM packages.

However, I don't look at this suggestion so much as a replacement, but rather 
an additional option end users can use if they aren't up to the challenge of 
using sources, but can't get by with ancient builds in RHEL, etc.  I personally 
doubt this would affect that many of the bigger users (let alone those on this 
list), as we would just keep using sources to keep up with what the LTS distros 
leave off (a 5+ year cycle is just too slow for the modern web tier).  As 
someone who does distro packaging, I think this is completely the wrong 
distribution model, but it's also the quick and dirty one.

Just throwing this out there, but a better middle of the road option for 
similar user coverage may be a more aggressive backporting of bleeding edge 
apache-related packages from development distros like Fedora to repositories 
maintained for the LTS distros.  A lot of people already do this work 
independently, so perhaps much of the labor overhead could be knocked off with 
a bit more initial organizational effort, and referral/hosting support from the 
httpd project?


Rick Houser
Web Administration

> -Original Message-
> From: Daniel Ruggeri [mailto:drugg...@primary.net]
> Sent: Friday, December 30, 2016 10:12
> To: dev@httpd.apache.org
> Subject: Re: The Version Bump fallacy [Was Re: Post 2.4.25]
> 
> On 12/28/2016 6:40 PM, Yehuda Katz wrote:
> > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> > > wrote:
> >
> > Our adoption is *broadly* based on the OS distributions
> > from vendors, not from people picking up our sources.
> > Yes - some integrate directly from source, and others
> > use a non-OS distribution.
> >
> >
> > I think a significant number of users of nginx add the official nginx
> > yum/apt sources and keep up to date that way
> > (http://nginx.org/en/linux_packages.html#mainline).
> > This is particularly true because the vendor-supplied version are so
> > old. You can see this in the w3techs data: nginx 1.10.2 came out in
> > October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8
> > usage has similar trends.
> >
> > A possible solution to this would be to start publishing binaries in a
> > package-manager-accessible format.
> > I am confident it would see a much higher rate of adoption.
> >
> > - Y
> 
> I feel strongly about this...
> 
> As a package builder/maintainer at $dayjob, this idea terrifies me.
> Given the huge variation in distributions and what is current on those
> platforms, the "best" option I see is to build for the least common
> denominator (minimum common libc, APR, APR-UTIL, openssl, openldap,
> etc). Otherwise, the package may only work on sufficiently modern
> installations. Things like Docker containers for the different distros
> are nice, but I'm not sure those are guaranteed to be current or
> accurately represent what an installation will look like. Additionally,
> vendors set different prefixes or split their configurations up
> differently meaning we would then have to bite off the work of creating
> vendor-specific packages (sucks for us) or force a standard installation
> format (sucks for operators of the servers). A really good illustration
> of this challenge is the layout differences between Debian and CentOS
> where even the name of the server binary is changed from "httpd" to
> "apache2" in the former distro.
> 
> Or worse... we would have to bundle/vendor a copy of the dependencies
> inside the httpd package. This becomes a nightmare for the package
> builders because (as wrowe pointed out recently) it requires us to build
> these updated libraries and push the new package at some cadence as well
> as changing library search paths to potentially funky locations. It also
> becomes a challenge for server operators because a library now exists in
> two locations on the machine so compliance auditing gets forked (my
> httpd installation may be using openssl 1.0.2j but my postfix server may
> be using 0.9.8zh).
> 
> Also, I'm sure it goes without saying, but we can't reasonably consider
> either approach without full CI... doing all this manually is
> unmaintainable (heh - ask me how I know).
> 
> --
> Daniel Ruggeri

Re: --enable-mods-shared don't work

[Yann Ylavic]

On Fri, Dec 30, 2016 at 5:16 PM, Yann Ylavic  wrote:
> On Fri, Dec 30, 2016 at 5:13 PM, Yann Ylavic  wrote:
>> On Fri, Dec 30, 2016 at 3:11 PM, Reindl Harald  
>> wrote:
>>>
>>>
>>> Am 30.12.2016 um 15:06 schrieb Yann Ylavic:

 On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald 
 wrote:
>
> and --enable-modules= don't work too


 Doesn't setting --enable-modules=none first help?
>>>
>>> see my last post - only partially
>>>
>>> normally when i list explicit "this modules shared" and "this modules
>>> static" there shoul dbe nothing in between
>>
>> How would the attached patch work for you?
>
> I mean with --enable-modules=none and then your exhaustive
> --enable-mods-shared/static list.

Sorry, the changes on acinclude.m4 are not needed, here is a new/simpler patch.

Thanks,
Yann.
Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4	(revision 1776076)
+++ modules/proxy/config.m4	(working copy)
@@ -13,7 +13,7 @@ dnl enabled module is missing its prereqs
 save_module_selection=$module_selection
 save_module_default=$module_default
 if test "$enable_proxy" != "no"; then
-module_selection=most
+dnl module_selection=most
 if test "$enable_proxy" = "shared" -o "$enable_proxy" = "static"; then
 module_default=$enable_proxy
 fi

Re: --enable-mods-shared don't work

[Yann Ylavic]

On Fri, Dec 30, 2016 at 5:13 PM, Yann Ylavic  wrote:
> On Fri, Dec 30, 2016 at 3:11 PM, Reindl Harald  wrote:
>>
>>
>> Am 30.12.2016 um 15:06 schrieb Yann Ylavic:
>>>
>>> On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald 
>>> wrote:

 and --enable-modules= don't work too
>>>
>>>
>>> Doesn't setting --enable-modules=none first help?
>>
>> see my last post - only partially
>>
>> normally when i list explicit "this modules shared" and "this modules
>> static" there shoul dbe nothing in between
>
> How would the attached patch work for you?

I mean with --enable-modules=none and then your exhaustive
--enable-mods-shared/static list.

>
> Regards,
> Yann.

Re: --enable-mods-shared don't work

[Yann Ylavic]

On Fri, Dec 30, 2016 at 3:11 PM, Reindl Harald  wrote:
>
>
> Am 30.12.2016 um 15:06 schrieb Yann Ylavic:
>>
>> On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald 
>> wrote:
>>>
>>> and --enable-modules= don't work too
>>
>>
>> Doesn't setting --enable-modules=none first help?
>
> see my last post - only partially
>
> normally when i list explicit "this modules shared" and "this modules
> static" there shoul dbe nothing in between

How would the attached patch work for you?

Regards,
Yann.
Index: acinclude.m4
===
--- acinclude.m4	(revision 1776076)
+++ acinclude.m4	(working copy)
@@ -302,8 +302,19 @@ dnl
 AC_DEFUN([APACHE_MODULE],[
   AC_MSG_CHECKING(whether to enable mod_$1)
   define([optname],[--]ifelse($5,yes,disable,enable)[-]translit($1,_,-))dnl
-  AC_ARG_ENABLE(translit($1,_,-),APACHE_HELP_STRING(optname(),$2),force_$1=$enableval,enable_$1=ifelse($5,,maybe-all,$5))
+  AC_ARG_ENABLE(translit($1,_,-),APACHE_HELP_STRING(optname(),$2),force_$1=$enableval,enable_$1=ifelse($5,,maybe-all,maybe_$5))
   undefine([optname])dnl
+  case "$enable_$1" in
+maybe_*)
+  if test "$module_selection" = "none"; then
+ enable_$1=no
+  else
+ enable_$1=`echo "$enable_$1" | sed 's/^maybe_//g'`
+  fi
+  ;;
+*)
+  ;;
+  esac
   _apmod_extra_msg=""
   dnl If the module was not explicitly requested, allow it to disable itself if
   dnl its pre-reqs fail.
Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4	(revision 1776076)
+++ modules/proxy/config.m4	(working copy)
@@ -13,7 +13,7 @@ dnl enabled module is missing its prereqs
 save_module_selection=$module_selection
 save_module_default=$module_default
 if test "$enable_proxy" != "no"; then
-module_selection=most
+dnl module_selection=most
 if test "$enable_proxy" = "shared" -o "$enable_proxy" = "static"; then
 module_default=$enable_proxy
 fi

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Eric Covener]

On Fri, Dec 30, 2016 at 10:22 AM, Daniel Ruggeri  wrote:
> I do like the idea of being nice to end users... but this may be a dumb
> followup question showing a lack of understanding. How would we trigger
> behavior in two different modules for the same directive unless the
> directive were added to core?


It's rarely used, but config processor will let multiple modules share
a directive. They both get called when it's read and then manage it in
their own conf from there independently.

-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Daniel Ruggeri]

On 12/30/2016 9:04 AM, Jim Jagielski wrote:
> I was thinking something like
>
>   ProxyProtocolEnable Incoming | Outgoing | Both | Optional | Off
>
> so that we have 1 command for all possible PROXY PROTOCOL usages.
> This, I think, is clearer for end-users.
I do like the idea of being nice to end users... but this may be a dumb
followup question showing a lack of understanding. How would we trigger
behavior in two different modules for the same directive unless the
directive were added to core?

> However, I also see the value in having it as a ProxySet
> parameter for outgoing, so I'm fine whichever way ;)
Actually, I didn't even consider this as an option but *really* like the
idea. It aligns with how we handle flags for outbound behavior already
plus aligns with how HAProxy handles it (on your server declaration you
simply add the "send-proxy" flag). Not that we have to work the same as
another server out there, but as mentioned above, it's nice to be
friendly to the operator by being consistent with expectations.

Between the options of an all-in-one directive and a directive for
incoming with a flag for outgoing, I definitely like the latter option.

-- 
Daniel Ruggeri

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Daniel Ruggeri]

On 12/28/2016 6:40 PM, Yehuda Katz wrote:
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> > wrote:
>
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-OS distribution.
>
>
> I think a significant number of users of nginx add the official nginx
> yum/apt sources and keep up to date that way
> (http://nginx.org/en/linux_packages.html#mainline).
> This is particularly true because the vendor-supplied version are so
> old. You can see this in the w3techs data: nginx 1.10.2 came out in
> October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8
> usage has similar trends.
>
> A possible solution to this would be to start publishing binaries in a
> package-manager-accessible format.
> I am confident it would see a much higher rate of adoption.
>
> - Y

I feel strongly about this...

As a package builder/maintainer at $dayjob, this idea terrifies me.
Given the huge variation in distributions and what is current on those
platforms, the "best" option I see is to build for the least common
denominator (minimum common libc, APR, APR-UTIL, openssl, openldap,
etc). Otherwise, the package may only work on sufficiently modern
installations. Things like Docker containers for the different distros
are nice, but I'm not sure those are guaranteed to be current or
accurately represent what an installation will look like. Additionally,
vendors set different prefixes or split their configurations up
differently meaning we would then have to bite off the work of creating
vendor-specific packages (sucks for us) or force a standard installation
format (sucks for operators of the servers). A really good illustration
of this challenge is the layout differences between Debian and CentOS
where even the name of the server binary is changed from "httpd" to
"apache2" in the former distro.

Or worse... we would have to bundle/vendor a copy of the dependencies
inside the httpd package. This becomes a nightmare for the package
builders because (as wrowe pointed out recently) it requires us to build
these updated libraries and push the new package at some cadence as well
as changing library search paths to potentially funky locations. It also
becomes a challenge for server operators because a library now exists in
two locations on the machine so compliance auditing gets forked (my
httpd installation may be using openssl 1.0.2j but my postfix server may
be using 0.9.8zh).

Also, I'm sure it goes without saying, but we can't reasonably consider
either approach without full CI... doing all this manually is
unmaintainable (heh - ask me how I know).

-- 
Daniel Ruggeri

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Jim Jagielski]

Yeah, the "namespace" stuff makes sense, but really, when
you think of it, the PROXY support is, theoretically at least,
independent of RemoteIP, even though that module is the one
that implements it. It makes it seem like it is "different"
in some way to PROXY...

I was thinking something like

  ProxyProtocolEnable Incoming | Outgoing | Both | Optional | Off

so that we have 1 command for all possible PROXY PROTOCOL usages.
This, I think, is clearer for end-users.

However, I also see the value in having it as a ProxySet
parameter for outgoing, so I'm fine whichever way ;)

On Dec 30, 2016, at 9:41 AM, Daniel Ruggeri  wrote:
> 
> 
> On 12/30/2016 8:28 AM, Jim Jagielski wrote:
>> Kewl beans!
> Indeed - the best beans to have!
> 
>> Any issue if we rename the directive to just ProxyProtocolEnable?
>> The "RemoteIP" prefix just seems weird :)
> I assume we try to keep a "namespace" for the more optional modules like
> this. It does seem weird and is unnecessarily long but starting with
> "Proxy" would lead me to think this directive _belongs_ to one of the
> mod_proxy modules.
> 
>> Also, just as a head's up, I'm looking on adding PROXY support
>> to the proxy module itself (that is, we *send* the PROXY line
>> to backends) as a configurable option. So when that
>> happens, we may wish to rethink the command again.
> Yes, I planned the same (not cookie licking! It's all yours if you want
> it!) which kinda makes me like the RemoteIP prefix on this new directive
> to further differentiate it from the client-side work of mod_proxy_*. In
> the case of mod_proxy sending the header, a directive like
> "ProxySendProxyProtocolHeader On" seems like a viable option (again,
> long... and kinda redundant... but "clear" in my mind who's doing what).
> 
> Pending further responses to the followup I sent a moment ago, I'll do
> another commit for final cleanup and to remove the new module now ported
> to remoteip and will then work on a backport for 2.4
> 
> -- 
> Daniel Ruggeri
> 

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Daniel Ruggeri]

On 12/30/2016 8:28 AM, Jim Jagielski wrote:
> Kewl beans!
Indeed - the best beans to have!

> Any issue if we rename the directive to just ProxyProtocolEnable?
> The "RemoteIP" prefix just seems weird :)
I assume we try to keep a "namespace" for the more optional modules like
this. It does seem weird and is unnecessarily long but starting with
"Proxy" would lead me to think this directive _belongs_ to one of the
mod_proxy modules.

> Also, just as a head's up, I'm looking on adding PROXY support
> to the proxy module itself (that is, we *send* the PROXY line
> to backends) as a configurable option. So when that
> happens, we may wish to rethink the command again.
Yes, I planned the same (not cookie licking! It's all yours if you want
it!) which kinda makes me like the RemoteIP prefix on this new directive
to further differentiate it from the client-side work of mod_proxy_*. In
the case of mod_proxy sending the header, a directive like
"ProxySendProxyProtocolHeader On" seems like a viable option (again,
long... and kinda redundant... but "clear" in my mind who's doing what).

Pending further responses to the followup I sent a moment ago, I'll do
another commit for final cleanup and to remove the new module now ported
to remoteip and will then work on a backport for 2.4

-- 
Daniel Ruggeri

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Daniel Ruggeri]

I went ahead and ported this code to mod_remoteip. I also taught it how
to be optional (process PROXY headers when available, but don't fail
otherwise), checks for IPv6 in APR as well as log numbers. A small bit
of refactoring was included.
A few questions came up during initial code review and the porting...
opinions would be appreciated.

On 12/30/2016 8:20 AM, drugg...@apache.org wrote:
> Author: druggeri
> Date: Fri Dec 30 14:20:48 2016
> New Revision: 1776575
>
> URL: http://svn.apache.org/viewvc?rev=1776575=rev
> Log:
> Merge new PROXY protocol code into mod_remoteip
>
> Modified:
> httpd/httpd/trunk/docs/log-message-tags/next-number
> httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
> httpd/httpd/trunk/modules/metadata/mod_remoteip.c
. . .

> Modified: httpd/httpd/trunk/modules/metadata/mod_remoteip.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/mod_remoteip.c?rev=1776575=1776574=1776575=diff
> ==
> --- httpd/httpd/trunk/modules/metadata/mod_remoteip.c (original)
> +++ httpd/httpd/trunk/modules/metadata/mod_remoteip.c Fri Dec 30 14:20:48 2016
> @@ -12,15 +12,20 @@
>   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>   * See the License for the specific language governing permissions and
>   * limitations under the License.
> + *
> + * The majority of the input filter code for PROXY protocol support is
> + * Copyright 2014 Cloudzilla Inc.
>   */
Is this sufficient attribution?


> +/* XXX: Unsure if this is needed if v6 support is not available on
> +   this platform */
> +#ifndef INET6_ADDRSTRLEN
> +#define INET6_ADDRSTRLEN 46
> +#endif
I don't have a non-IPv6 capable platform so I'm not sure if this will be
defined anyway. Is this needed?


> +
> +/* add our filter */
> +if (!ap_add_input_filter(remoteip_filter_name, NULL, NULL, c)) {
> +/* XXX: Shouldn't this WARN in log? */
> +return DECLINED;
> +}
This came from the original code... but I assume that if the admin
desired for this to be configured, but we failed to enable it... we
should at least complain. Maybe more?

-- 
Daniel Ruggeri

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Jim Jagielski]

Kewl beans!

Any issue if we rename the directive to just ProxyProtocolEnable?
The "RemoteIP" prefix just seems weird :)

Also, just as a head's up, I'm looking on adding PROXY support
to the proxy module itself (that is, we *send* the PROXY line
to backends) as a configurable option. So when that
happens, we may wish to rethink the command again.

Re: --enable-mods-shared don't work

[Reindl Harald]

Am 30.12.2016 um 15:06 schrieb Yann Ylavic:

On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald  wrote:

and --enable-modules= don't work too


Doesn't setting --enable-modules=none first help?


see my last post - only partially

normally when i list explicit "this modules shared" and "this modules 
static" there shoul dbe nothing in between

Re: --enable-mods-shared don't work

[Yann Ylavic]

On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald  wrote:
> and --enable-modules= don't work too

Doesn't setting --enable-modules=none first help?

Regards,
Yann.

Re: --enable-mods-shared don't work

[Reindl Harald]

and even --enable-modules=none leads to stuff like

checking whether to enable mod_proxy... shared
checking whether to enable mod_proxy_connect... checking dependencies
checking whether to enable mod_proxy_connect... shared (most)
checking whether to enable mod_proxy_ftp... checking dependencies
checking whether to enable mod_proxy_ftp... shared (most)
checking whether to enable mod_proxy_http... checking dependencies
checking whether to enable mod_proxy_http... shared
checking whether to enable mod_proxy_fcgi... checking dependencies
checking whether to enable mod_proxy_fcgi... shared
checking whether to enable mod_proxy_scgi... checking dependencies
checking whether to enable mod_proxy_scgi... shared (most)
checking whether to enable mod_proxy_fdpass... checking dependencies

 --enable-modules=none \
 --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info 
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
 --enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \


while for some parts it is respected like

checking whether to enable mod_file_cache... no (none)
checking whether to enable mod_cache... no (none)
checking whether to enable mod_cache_disk... no (none)
checking whether to enable mod_cache_socache... no (none)

anyways, the stuf fbelow is unasked built

Fehler beim Bauen des RPM:
Installierte (aber nicht gepackte) Datei(en) gefunden:
   /usr/lib64/httpd/modules/mod_lbmethod_bybusyness.so
   /usr/lib64/httpd/modules/mod_lbmethod_byrequests.so
   /usr/lib64/httpd/modules/mod_lbmethod_bytraffic.so
   /usr/lib64/httpd/modules/mod_lbmethod_heartbeat.so
   /usr/lib64/httpd/modules/mod_proxy_ajp.so
   /usr/lib64/httpd/modules/mod_proxy_balancer.so
   /usr/lib64/httpd/modules/mod_proxy_connect.so
   /usr/lib64/httpd/modules/mod_proxy_express.so
   /usr/lib64/httpd/modules/mod_proxy_fdpass.so
   /usr/lib64/httpd/modules/mod_proxy_ftp.so
   /usr/lib64/httpd/modules/mod_proxy_scgi.so
   /usr/lib64/httpd/modules/mod_proxy_wstunnel.so

Am 30.12.2016 um 15:00 schrieb Reindl Harald:

and --enable-modules= don't work too

none of the 3 options mentions "dbm" anywhere

checking whether to enable mod_authn_dbm... shared (most)
checking whether to enable mod_authn_anon... shared (most)
checking whether to enable mod_authn_dbd... shared (most)
checking whether to enable mod_authn_socache... shared (most)


 --enable-modules="alias allowmethods auth_basic auth_digest authn_core
authn_file authz_core authz_groupfile authz_host authz_user autoindex
cgi dav dav_fs dav_lock deflate dir env expires ext_filter filter
headers http2 info log_config mime mime_magic negotiation proxy
proxy_fcgi proxy_http ratelimit remoteip reqtimeout rewrite setenvif
socache_shmcb ssl status substitute unique_id unixd version" \
 --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
 --enable-mods-static="alias allowmethods auth_basic auth_digest
authn_core authn_file authz_core authz_groupfile authz_host authz_user
autoindex deflate dir env expires filter headers log_config mime
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id
unixd version" \


Am 30.12.2016 um 14:51 schrieb Reindl Harald:

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated
list of shared modules to enable when

--enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status
substitute" \
--enable-mods-static="alias allowmethods auth_basic auth_digest
authn_core authn_file authz_core authz_groupfile authz_host authz_user
autoindex deflate dir env expires filter headers log_config mime
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id
unixd version" \

leads to

checking whether to enable mod_request... shared (most)
checking whether to enable mod_include... shared (most)

and finally this list of unwanted modules is built?

   /usr/lib64/httpd/modules/mod_access_compat.so
   /usr/lib64/httpd/modules/mod_actions.so
   /usr/lib64/httpd/modules/mod_auth_form.so
   /usr/lib64/httpd/modules/mod_authn_anon.so
   /usr/lib64/httpd/modules/mod_authn_dbd.so
   /usr/lib64/httpd/modules/mod_authn_dbm.so
   /usr/lib64/httpd/modules/mod_authn_socache.so
   /usr/lib64/httpd/modules/mod_authz_dbd.so
   /usr/lib64/httpd/modules/mod_authz_dbm.so
   /usr/lib64/httpd/modules/mod_authz_owner.so
   /usr/lib64/httpd/modules/mod_buffer.so
   /usr/lib64/httpd/modules/mod_cache.so
   /usr/lib64/httpd/modules/mod_cache_disk.so
   /usr/lib64/httpd/modules/mod_cache_socache.so
   /usr/lib64/httpd/modules/mod_dbd.so
   /usr/lib64/httpd/modules/mod_dumpio.so
   

Re: --enable-mods-shared don't work

[Reindl Harald]

and --enable-modules= don't work too

none of the 3 options mentions "dbm" anywhere

checking whether to enable mod_authn_dbm... shared (most)
checking whether to enable mod_authn_anon... shared (most)
checking whether to enable mod_authn_dbd... shared (most)
checking whether to enable mod_authn_socache... shared (most)


 --enable-modules="alias allowmethods auth_basic auth_digest authn_core 
authn_file authz_core authz_groupfile authz_host authz_user autoindex 
cgi dav dav_fs dav_lock deflate dir env expires ext_filter filter 
headers http2 info log_config mime mime_magic negotiation proxy 
proxy_fcgi proxy_http ratelimit remoteip reqtimeout rewrite setenvif 
socache_shmcb ssl status substitute unique_id unixd version" \
 --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info 
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
 --enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \



Am 30.12.2016 um 14:51 schrieb Reindl Harald:

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated
list of shared modules to enable when

--enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
--enable-mods-static="alias allowmethods auth_basic auth_digest
authn_core authn_file authz_core authz_groupfile authz_host authz_user
autoindex deflate dir env expires filter headers log_config mime
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id
unixd version" \

leads to

checking whether to enable mod_request... shared (most)
checking whether to enable mod_include... shared (most)

and finally this list of unwanted modules is built?

   /usr/lib64/httpd/modules/mod_access_compat.so
   /usr/lib64/httpd/modules/mod_actions.so
   /usr/lib64/httpd/modules/mod_auth_form.so
   /usr/lib64/httpd/modules/mod_authn_anon.so
   /usr/lib64/httpd/modules/mod_authn_dbd.so
   /usr/lib64/httpd/modules/mod_authn_dbm.so
   /usr/lib64/httpd/modules/mod_authn_socache.so
   /usr/lib64/httpd/modules/mod_authz_dbd.so
   /usr/lib64/httpd/modules/mod_authz_dbm.so
   /usr/lib64/httpd/modules/mod_authz_owner.so
   /usr/lib64/httpd/modules/mod_buffer.so
   /usr/lib64/httpd/modules/mod_cache.so
   /usr/lib64/httpd/modules/mod_cache_disk.so
   /usr/lib64/httpd/modules/mod_cache_socache.so
   /usr/lib64/httpd/modules/mod_dbd.so
   /usr/lib64/httpd/modules/mod_dumpio.so
   /usr/lib64/httpd/modules/mod_file_cache.so
   /usr/lib64/httpd/modules/mod_include.so
   /usr/lib64/httpd/modules/mod_lbmethod_bybusyness.so
   /usr/lib64/httpd/modules/mod_lbmethod_byrequests.so
   /usr/lib64/httpd/modules/mod_lbmethod_bytraffic.so
   /usr/lib64/httpd/modules/mod_lbmethod_heartbeat.so
   /usr/lib64/httpd/modules/mod_log_debug.so
   /usr/lib64/httpd/modules/mod_logio.so
   /usr/lib64/httpd/modules/mod_macro.so
   /usr/lib64/httpd/modules/mod_proxy_ajp.so
   /usr/lib64/httpd/modules/mod_proxy_balancer.so
   /usr/lib64/httpd/modules/mod_proxy_connect.so
   /usr/lib64/httpd/modules/mod_proxy_express.so
   /usr/lib64/httpd/modules/mod_proxy_fdpass.so
   /usr/lib64/httpd/modules/mod_proxy_ftp.so
   /usr/lib64/httpd/modules/mod_proxy_hcheck.so
   /usr/lib64/httpd/modules/mod_proxy_scgi.so
   /usr/lib64/httpd/modules/mod_proxy_wstunnel.so
   /usr/lib64/httpd/modules/mod_request.so
   /usr/lib64/httpd/modules/mod_sed.so
   /usr/lib64/httpd/modules/mod_session.so
   /usr/lib64/httpd/modules/mod_session_cookie.so
   /usr/lib64/httpd/modules/mod_session_crypto.so
   /usr/lib64/httpd/modules/mod_session_dbd.so
   /usr/lib64/httpd/modules/mod_slotmem_shm.so
   /usr/lib64/httpd/modules/mod_socache_dbm.so
   /usr/lib64/httpd/modules/mod_socache_memcache.so
   /usr/lib64/httpd/modules/mod_speling.so
   /usr/lib64/httpd/modules/mod_userdir.so
   /usr/lib64/httpd/modules/mod_vhost_alias.so
   /usr/lib64/httpd/modules/mod_watchdog.so

--enable-mods-shared don't work

[Reindl Harald]

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated 
list of shared modules to enable when


--enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info 
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
--enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \


leads to

checking whether to enable mod_request... shared (most)
checking whether to enable mod_include... shared (most)

and finally this list of unwanted modules is built?

   /usr/lib64/httpd/modules/mod_access_compat.so
   /usr/lib64/httpd/modules/mod_actions.so
   /usr/lib64/httpd/modules/mod_auth_form.so
   /usr/lib64/httpd/modules/mod_authn_anon.so
   /usr/lib64/httpd/modules/mod_authn_dbd.so
   /usr/lib64/httpd/modules/mod_authn_dbm.so
   /usr/lib64/httpd/modules/mod_authn_socache.so
   /usr/lib64/httpd/modules/mod_authz_dbd.so
   /usr/lib64/httpd/modules/mod_authz_dbm.so
   /usr/lib64/httpd/modules/mod_authz_owner.so
   /usr/lib64/httpd/modules/mod_buffer.so
   /usr/lib64/httpd/modules/mod_cache.so
   /usr/lib64/httpd/modules/mod_cache_disk.so
   /usr/lib64/httpd/modules/mod_cache_socache.so
   /usr/lib64/httpd/modules/mod_dbd.so
   /usr/lib64/httpd/modules/mod_dumpio.so
   /usr/lib64/httpd/modules/mod_file_cache.so
   /usr/lib64/httpd/modules/mod_include.so
   /usr/lib64/httpd/modules/mod_lbmethod_bybusyness.so
   /usr/lib64/httpd/modules/mod_lbmethod_byrequests.so
   /usr/lib64/httpd/modules/mod_lbmethod_bytraffic.so
   /usr/lib64/httpd/modules/mod_lbmethod_heartbeat.so
   /usr/lib64/httpd/modules/mod_log_debug.so
   /usr/lib64/httpd/modules/mod_logio.so
   /usr/lib64/httpd/modules/mod_macro.so
   /usr/lib64/httpd/modules/mod_proxy_ajp.so
   /usr/lib64/httpd/modules/mod_proxy_balancer.so
   /usr/lib64/httpd/modules/mod_proxy_connect.so
   /usr/lib64/httpd/modules/mod_proxy_express.so
   /usr/lib64/httpd/modules/mod_proxy_fdpass.so
   /usr/lib64/httpd/modules/mod_proxy_ftp.so
   /usr/lib64/httpd/modules/mod_proxy_hcheck.so
   /usr/lib64/httpd/modules/mod_proxy_scgi.so
   /usr/lib64/httpd/modules/mod_proxy_wstunnel.so
   /usr/lib64/httpd/modules/mod_request.so
   /usr/lib64/httpd/modules/mod_sed.so
   /usr/lib64/httpd/modules/mod_session.so
   /usr/lib64/httpd/modules/mod_session_cookie.so
   /usr/lib64/httpd/modules/mod_session_crypto.so
   /usr/lib64/httpd/modules/mod_session_dbd.so
   /usr/lib64/httpd/modules/mod_slotmem_shm.so
   /usr/lib64/httpd/modules/mod_socache_dbm.so
   /usr/lib64/httpd/modules/mod_socache_memcache.so
   /usr/lib64/httpd/modules/mod_speling.so
   /usr/lib64/httpd/modules/mod_userdir.so
   /usr/lib64/httpd/modules/mod_vhost_alias.so
   /usr/lib64/httpd/modules/mod_watchdog.so