Re: T 2.4.23 tomorrow (Thurs) ??
On Mon, 27 Jun 2016, William A Rowe Jr wrote: On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener <jens.schleuse...@t-online.de> wrote: On Fri, 24 Jun 2016, William A Rowe Jr wrote: On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <jens.schleuse...@t-online.de> wrote: 1) Just a pure ./configure (probably equivalent to using the option --enable-mods-shared=most) let produce the "make" (compared to the last release 2.4.20) 86 modules instead 85 modules with the additional modules modules/core/.libs/mod_watchdog.so modules/proxy/.libs/mod_proxy_hcheck.so Yes, proposed (and accepted) that we change the watchdog default to enable at enable "most", as proxy_hcheck requires it. and the omitted module modules/session/.libs/mod_session_crypto.so That may be expected. Need to look at mod_session_crypto, I hadn't proposed mod_session changes, modules/session/config.m4 hasn't changed since 2.4.21 was tagged. acinclude.m4 changes may have had side effects, but unlikely. Once the whole "--enable-proxy" decision is made, others that followed this broken pattern need to be reevaluated, but that isn't a change for a 2.4.23 tag, since there should be no regression here. There is a simpler explanation, did you change the detected apr-util to one without apr_crypto (based on openssl) enabled? Ensure your apr-util build enabled openssl and is current (1.5). Oops, my fault, well combined, you are completely right: For 2.4.20 I used (since I have originally not downloaded httpd-2.4.20-deps.tar.bz2) my "separate" self-compiled apr-1.5.2 and apr-util-1.5.4 installatations (using the configure options --with-crypto --with-openssl=/usr). By the way the option --enable-mods-shared=all produces 103 modules and --enable-mods-shared=reallyall 120 ones. 2) But for me surprising the option--enable-mods-shared=none seems to have the same configuration effect as the option--enable-mods-shared=most (producing 86 modules) respectively the option is ignored and the default "most" is used. Similar for e.g. --enable-mods-shared='headers rewrite dav' (an example from the documentation page http://httpd.apache.org/docs/2.4/programs/configure.html) seems to produce the same behaviour like --enable-mods-shared=most while I would expect that only the three specified modules would be buillt. Odd, also arbitray module names like --enable-mods-shared=nonsense seems equivalent to --enable-mods-shared=most. But that is an error it seems not a regression since 2.4.20 shows the same behaviour. It is, you found it, and the error was already a side effect within acinclude.m4 which trusted the value 'no' (which is why I continued to trust the value 'no'). In order for --enable-mods-shared=nonsense to behave as expected, I think the patch is pretty simple... --- acinclude.m4 (revision 1749925) +++ acinclude.m4 (working copy) @@ -375,6 +375,8 @@ "$force_$1" != "no" ; then enable_$1=$module_default _apmod_extra_msg=" ($module_selection)" + else + enable_$1=no fi if test "$enable_$1" != "no"; then dnl If we plan to enable it, allow the module to run some autoconf magic Just for completeness (since another fix seems on the way): At some first quick tests this fix seems not to work for me. For httpd-2.4.x I saw no difference in the number of built modules using either --enable-mods-shared=nonsense or --enable-mods-shared=none and for httpd-2.4.21 (patched with your proxy-rollup-2.4.21.patch patch) it let only omit the modules modules/proxy/balancers/.libs/mod_lbmethod_bybusyness.so modules/proxy/balancers/.libs/mod_lbmethod_byrequests.so modules/proxy/balancers/.libs/mod_lbmethod_bytraffic.so modules/proxy/balancers/.libs/mod_lbmethod_heartbeat.so Regards Jens
Re: T 2.4.23 tomorrow (Thurs) ??
On Fri, 24 Jun 2016, William A Rowe Jr wrote: On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <jens.schleuse...@t-online.de> wrote: ... good news. So now nearly superfluous info but just for completeness: Your first patch for modules/proxy/config.m4 sent at "Thu, 23 Jun 2016 07:32:02 -0500" solved at least the superficial problem and let the configure run end without an error. The entire solution is now presented in STATUS, but for reviewers I've rolled up all of the diffs into a single delta that can be applied to either 2.4.21 or 2.4.22 release candidates for easier testing; https://raw.githubusercontent.com/wrowe/patches/master/proxy-rollup-2.4.21.patch This will hopefully address every edge case with the proxy and proxy sub-modules logic in ./configure (just be sure to re-run ./buildconf after applying this patch!) Ok, I applied the patch to both release candidates and a ./configure --enable-mods-shared=few ends without errors (using openSUSE Leap 42.1; autoconf-2.69-11.4.noarch; libtool-2.4.2-16.6.x86_64). But a subsequent "make" produces to the expected 21 modules additionally the 4 modules modules/proxy/balancers/.libs/mod_lbmethod_bybusyness.so modules/proxy/balancers/.libs/mod_lbmethod_byrequests.so modules/proxy/balancers/.libs/mod_lbmethod_bytraffic.so modules/proxy/balancers/.libs/mod_lbmethod_heartbeat.so As since yesterday httpd-2.4.x seems now accordingly patched I tried that branch and it also works with the above configure command and a subsequent "make" produces just the expected 21 modules. So for the original reported error regarding the configure option --enable-mods-shared=few the fixes seems ok now. But some observations (from an outsider): 1) Just a pure ./configure (probably equivalent to using the option --enable-mods-shared=most) let produce the "make" (compared to the last release 2.4.20) 86 modules instead 85 modules with the additional modules modules/core/.libs/mod_watchdog.so modules/proxy/.libs/mod_proxy_hcheck.so and the omitted module modules/session/.libs/mod_session_crypto.so That may be expected. By the way the option --enable-mods-shared=all produces 103 modules and --enable-mods-shared=reallyall 120 ones. 2) But for me surprising the option--enable-mods-shared=none seems to have the same configuration effect as the option--enable-mods-shared=most (producing 86 modules) respectively the option is ignored and the default "most" is used. Similar for e.g. --enable-mods-shared='headers rewrite dav' (an example from the documentation page http://httpd.apache.org/docs/2.4/programs/configure.html) seems to produce the same behaviour like --enable-mods-shared=most while I would expect that only the three specified modules would be buillt. Odd, also arbitray module names like --enable-mods-shared=nonsense seems equivalent to --enable-mods-shared=most. But that is an error it seems not a regression since 2.4.20 shows the same behaviour. Regards Jens
Re: T 2.4.23 tomorrow (Thurs) ??
On Thu, 23 Jun 2016, William A Rowe Jr wrote:
On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener
<jens.schleuse...@t-online.de> wrote:
Just for curiosity I copied the soure code via
svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
src/httpd-2.4.x> ./buildconf
src/httpd-2.4.x> ./configure --enable-mods-shared=few
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking for chosen layout... Apache
[... many lines deleted ...]
checking whether to enable mod_proxy_express... no (few)
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_proxy is disabled but required for mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to prerequisite
failures
So it appears not the identical but a similar failure compared to that one I
reported some days ago
("Small problem in "configure" script with 2.4.21"): Now "mod_watchdog" is replaced by
"mod_proxy".
And again: Since the option "--enable-mods-shared=few" doesn't include any
"proxy"-related modules I
also don't expect to build the "reverse-proxy health-check module".
I am not sure if there is still a problem or if my "configure" building and
testing is incorrect.
There is still a problem, and it relates to a special case handling
of the underlying 'few' token. Found it, more updates shortly...
... good news.
So now nearly superfluous info but just for completeness: Your first patch
for modules/proxy/config.m4 sent at "Thu, 23 Jun 2016 07:32:02 -0500"
solved at least the superficial problem and let the configure run end
without an error.
But caused by some cut unicode errors and since your diff has within
the 3 trailing unified lines the line
enable_proxy_hcheck="no";
where the original file modules/proxy/config.m4 has at line number 67
enable_proxy_hcheck="";
I had to apply the patch manually.
Jens
Re: T 2.4.23 tomorrow (Thurs) ??
On Wed, 22 Jun 2016, Jim Jagielski wrote:
Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).
So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??
Just for curiosity I copied the soure code via
svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
and did for building the "configure" script a
src/httpd-2.4.x> ./buildconf
found apr source: srclib/apr
rebuilding srclib/apr/configure
buildconf: checking installation...
buildconf: python version 2.7.9 (ok)
buildconf: autoconf version 2.69 (ok)
buildconf: libtool version 2.4.2 (ok)
buildconf: copying libtool helper files using /usr/bin/libtoolize
buildconf: creating include/arch/unix/apr_private.h.in ...
buildconf: creating configure ...
buildconf: generating 'make' outputs ...
buildconf: rebuilding rpm spec file
copying build files
rebuilding include/ap_config_auto.h.in
rebuilding configure
rebuilding rpm spec file
fixing timestamps for ap_expr sources
and then issued
src/httpd-2.4.x> ./configure --enable-mods-shared=few
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking for chosen layout... Apache
[... many lines deleted ...]
checking whether to enable mod_proxy_express... no (few)
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_proxy is disabled but required for mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to prerequisite
failures
So it appears not the identical but a similar failure compared to that one
I reported some days ago ("Small problem in "configure" script with
2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
And again: Since the option "--enable-mods-shared=few" doesn't include any
"proxy"-related modules I also don't expect to build the "reverse-proxy
health-check module".
I am not sure if there is still a problem or if my "configure" building
and testing is incorrect.
Regards
Jens
Re: Small problem in "configure" script with 2.4.21
On Fri, 17 Jun 2016, Ruediger Pluem wrote: I guess the following should fix this: Index: modules/proxy/config.m4 === --- modules/proxy/config.m4 (revision 1748670) +++ modules/proxy/config.m4 (working copy) @@ -13,6 +13,9 @@ if test "$proxy_mods_enable" = "no"; then enable_proxy_hcheck=no fi +if test -z "$enable_proxy_hcheck" ; then + enable_proxy_hcheck="$proxy_mods_enable" +fi proxy_objs="mod_proxy.lo proxy_util.lo" APACHE_MODULE(proxy, Apache proxy module, $proxy_objs, , $proxy_mods_enable) Of course you need to run buildconf before your next configure call to regenerate configure which requires you to have Python, autoconf and libtool installed in suitable versions. Regards Rüdiger Thanks Rüdiger, that works for me. Jens On 06/17/2016 04:09 PM, Jens Schleusener wrote: Hi, I just tried to build Apache httpd 2.4.21 using the pre-release test tarball under Linux (openSUSE Leap 42.1). But in contrast to the previous releases my own build wrapper script unfortunately failed. I could reproduce the problem by just using the reduced command ./configure --enable-so --enable-mods-shared=few that issues [... lines deleted ...] checking whether to enable mod_proxy_express... no (few) checking whether to enable mod_proxy_hcheck... checking dependencies configure: WARNING: "mod_watchdog is disabled but required for mod_proxy_hcheck" checking whether to enable mod_proxy_hcheck... configure: error: mod_proxy_hcheck has been requested but can not be built due to prerequisite failures Ok, a "configure --help" mentions --enable-proxy-hcheck reverse-proxy health-check module. Requires --enable-proxy and --enable-watchdog but why is the module "proxy-hcheck" enabled while using the option "--enable-mods-shared=few"? Unfortunately the option "--enable-mods-shared=few" seems not well documented but it seems to enable for e.g. for 2.4.20 only the modules access_compat, alias, auth_basic, authn_core, authn_file, authz_core, authz_groupfile, authz_host, authz_user, autoindex, dir, env, filter, heaaders, log_config, mime, reqtimeout, setenvif, statis, unixd, and version. But no "proxy"-related modules are included! A short analysis of the configure script of 2.4.21 let me find the somewhat irritating line 23330 enable_proxy_hcheck=$enable_proxy_hcheck Comparing the logic about that line with that of the other "proxy"-related modules I replaced that line by the more meaningful (?) enable_proxy_hcheck=$proxy_mods_enable and at least ./configure now runs without errors. Additionally I found on lines 21591-21593 the in 2.4.21 added related code if test "$proxy_mods_enable" = "no"; then enable_proxy_hcheck=no fi that seems to me a little bit like an incomplete hack for the errorneous (?) line 23330 mentioned above (but I'm not sure). Regards Jens
Small problem in "configure" script with 2.4.21
Hi, I just tried to build Apache httpd 2.4.21 using the pre-release test tarball under Linux (openSUSE Leap 42.1). But in contrast to the previous releases my own build wrapper script unfortunately failed. I could reproduce the problem by just using the reduced command ./configure --enable-so --enable-mods-shared=few that issues [... lines deleted ...] checking whether to enable mod_proxy_express... no (few) checking whether to enable mod_proxy_hcheck... checking dependencies configure: WARNING: "mod_watchdog is disabled but required for mod_proxy_hcheck" checking whether to enable mod_proxy_hcheck... configure: error: mod_proxy_hcheck has been requested but can not be built due to prerequisite failures Ok, a "configure --help" mentions --enable-proxy-hcheck reverse-proxy health-check module. Requires --enable-proxy and --enable-watchdog but why is the module "proxy-hcheck" enabled while using the option "--enable-mods-shared=few"? Unfortunately the option "--enable-mods-shared=few" seems not well documented but it seems to enable for e.g. for 2.4.20 only the modules access_compat, alias, auth_basic, authn_core, authn_file, authz_core, authz_groupfile, authz_host, authz_user, autoindex, dir, env, filter, heaaders, log_config, mime, reqtimeout, setenvif, statis, unixd, and version. But no "proxy"-related modules are included! A short analysis of the configure script of 2.4.21 let me find the somewhat irritating line 23330 enable_proxy_hcheck=$enable_proxy_hcheck Comparing the logic about that line with that of the other "proxy"-related modules I replaced that line by the more meaningful (?) enable_proxy_hcheck=$proxy_mods_enable and at least ./configure now runs without errors. Additionally I found on lines 21591-21593 the in 2.4.21 added related code if test "$proxy_mods_enable" = "no"; then enable_proxy_hcheck=no fi that seems to me a little bit like an incomplete hack for the errorneous (?) line 23330 mentioned above (but I'm not sure). Regards Jens
Re: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On Thu, 10 Nov 2011, Rainer Jung wrote: On 09.11.2011 21:20, William A. Rowe Jr. wrote: On 11/9/2011 4:53 PM, Jim Jagielski wrote: Isn't the point different? If someone enables mod_proxy then the configure script needs to ensure that mod_slotmem is also built… Reporter suggests that *NOT* loading mod_slotmem_shm caused the server to start correctly; exactly the inverse of what we would expect. No, his subject is module proxy_balancer requires the not automatically loaded module slotmem_shm (the not and not to not) and he writes Ok, so I simply removed in the installed default httpd.conf the comment sign within the line #LoadModule slotmem_shm_module modules/mod_slotmem_shm.so and as expected now all works. I am the OP and yes, Rainer interprets me correctly. And here a small addition: Just for curiosity I added dav_lock to my previosly used configure options (don't ask why, just historical reasons): ./configure --prefix=/usr/local/www/httpd2.3.15-beta_with_dl \ --enable-so --disable-ldap --with-included-apr --with-pcre=/usr/local/soft \ --enable-mods-shared=most cache mem-cache dav_lock mime-magic proxy ssl unique_id Some relevant entries from the so generated default httpd.conf: #LoadModule slotmem_shm_module modules/mod_slotmem_shm.so #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so LoadModule dav_lock_module modules/mod_dav_lock.so If I now issue bin/apachectl start I got the error httpd: Syntax error on line 138 of /usr/local/www/httpd2.3.15-beta_with_dl/conf/httpd.conf: Cannot load /usr/local/www/httpd2.3.15-beta_with_dl/modules/mod_dav_lock.so into server: /usr/local/www/httpd2.3.15-beta_with_dl/modules/mod_dav_lock.so: undefined symbol: dav_push_error Remark: This error was output to the console and not as yesterday only to the error_log so I detected yesterday the problem only later since the httpd wasn't running (probably since the errors have different qualities and/or occur at different phases). Ok, in this case I had not only to activate/load the slotmem_shm_module but also to remove the comment sign from the following httpd.conf line #LoadModule dav_module modules/mod_dav.so to let apache load the required dav_module. Probably a very similar configuration dependency problem. I think at the moment there is some tendency to further reduce the default active LoadModules to a very small module set (see elsethread) and not activate the other enabled modules. Module set at build time is only loosely coupled to needed modules at run time. Jim's suggestion still makes sense: even if we do not activate most modules by default, some modules have dependencies to other modules and when a module with such a dependency is build (enabled), we could build the dependencies automatically as well. Modules with dependencies are at least mod_ssl (for the session cache), mod_proxy_balancer, and I think the heartbeat stuff. Probably also ldap auth needing mod_ldap. On the other hand we now build most by default and there are all and reallyall, *and* we now only activate few modules by default. So most users should not have a real need to add individual modules to the list of modules to build. IMHO the automatic dependency handling in configure is not a must. We could add after GA if users really need it. Regards, Rainer Regards Jens P.S.: OT (information respectively promotion): By the way I use the apache httpd server for my FOSS software archive and naturally the according tarballs are there also available, for e.g. under http://fossies.org/unix/www/httpd-2.3.14-beta.tar.gz/ or under the more general and version independent start URL http://fossies.org/httpd Why I write this (with bad conscience)? That site allows source code browsing, downloads with different compression formats, generates a CLOC statistic (ok, a gimmick), for e.g. http://fossies.org/unix/www/httpd-2.3.14-beta.tar.gz/cloc.html and offers Doxygen-generated source code documentation (ok, for httpd the dependency graphs are sometimes a little bit gigantic and confusing), for e.g. http://fossies.org/dox/httpd-2.3.14-beta/ in the hope that it helps the developers of the FOSS community. But probably apache teams have its own more specific according tools ;-)
Re: [VOTE] 1.3.42 release candidate
Hi, On Fri, 8 Jan 2010, Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 7:50 PM, Brian Havard brian.hav...@gmail.com wrote: Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ I just tried building on a fairly stock Ubuntu Karmic system and ran into this compile error: gcc -c -I../os/unix -I../include -DLINUX=22 -DHAVE_SET_DUMPABLE -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci` htpasswd.c htpasswd.c:101: error: conflicting types for ?getline? /usr/include/stdio.h:651: note: previous declaration of ?getline? was here So getline() is a system provided function here. I used the top level configure with /bin/sh changed to /bin/bash as mentioned elsewhere, no options. On fixing this I found that htdigest.c and logrotate.c have the same problem. The obvious fix would be to namespace protect these getline implementations, Thanks for the report - disinclined to fix anything that isn't a regression from 1.3.41 though. This is a security release, for upgraders only - so presumably people who've managed to work around these problems. Making life easy for new users is a deliberate non-goal :-) 2.2 is much much better for new users. Just for information: Only out of curiosity (we use 2.2) I tried to compile 1.3.42 on a current OpenSUSE 11.2 system and found also the above described compile problem (but on OpenSUSE 11.1 compiling is ok). The orign seems to lie in the used newer glibc-library respectively the changed file stdio.h. In the glibc-ChangeLog I found 2009-02-26 Ulrich Drepper drep...@redhat.com * libio/stdio.h: dprintf, fmemopen, getdelim, getline, open_memstream, and vdprintf are in POSIX 2008. The above patch would be better but for clarification I added in the Linux block of src/include/ap_config.h the following lines /* glibc 2.10 and later define getline in stdio.h if __USE_XOPEN2K8 * is defined but that conflicts with getline definitions in * support/htpasswd.c, support/htdigest.c and support/logresolve.c. */ #if (__GLIBC__ == 2 __GLIBC_MINOR__ 9) #undef __USE_XOPEN2K8 #endif and it works also (but I am not a C expert). But I accept the arguments of Colm and deleted the apache_1.3.42 directory but I expect some according bug reports after releasing 1.3.42 :-( Regards, Jens
Re: [EMAIL PROTECTED] ANN: mod_proxy_html 3.0-dev
Hi, On Mon, 25 Dec 2006, Nick Kew wrote: I've made a number of significant updates to mod_proxy_html, and it's working fine for me in a range of tests. I'd now like to invite testing and feedback from developers and bleeding edge users. The major new features in mod_proxy_html 3.0 are inspired by the common requests I've had from users of versions 2.x: * Much improved internationalisation/charset support. It now works properly with charsets not supported by libxml2, such as the windows-125x range, and enables an administrator to correct for backends that fail to supply the information. It can also generate output using any encoding available on the host system. * Configurable definition for the set of HTML attributes to treat as links and events. So you can now support rewriting proprietary hacks like td background by declaring them in httpd.conf. * Supports various fixups for bogus and deprecated HTML. * Supports flexible configuration, through interpolating environment variables in ProxyHTMLURLMap rules, and supports conditional processing of individual rules. Other feature requests can still be considered, too! The next task is to update the documentation further, notably the tutorial. The recipes everyone seems to copy were designed for Apache 2.0 and mod_proxy_html 1.x, and while they work for later versions, they lead users into some gotchas in spite of my warnings! http://apache.webthing.com/mod_proxy_html/ -- Nick Kew Thanks for the good (christmassy) news. But installing 3.0-dev revision 76 and adding in httpd.conf LoadFile/usr/lib/libxml2.so LoadModule proxy_html_modulemodules/mod_proxy_html.so Include conf/proxy_html.conf while checking the apache syntax I got the following error $ /usr/local/www/httpd2.2.3/bin/apachectl configtest Syntax error on line 22 of /usr/local/www/httpd2.2.3/conf/proxy_html.conf: Invalid command 'ProxyHTMLLink', perhaps misspelled or defined by a module not included in the server configuration Uncommenting the above Include I found via $ /usr/local/www/httpd2.2.3/bin/apachectl -t -D DUMP_MODULES the line proxy_html_module (shared) so the corresponding module seems to be loaded correctly. Looking in the source code I have the impression that the proxyHTMLLink declaration lines contains a small typo and must be replaced by proxyHTMLLinks. At least the configuration check is thereafter ok. Greetings Jens -- Dr. Jens SchleusenerT-Systems Solutions for Research GmbH Tel: +49 551 709-2493 Bunsenstr.10 Fax: +49 551 709-2169 D-37073 Goettingen [EMAIL PROTECTED] http://www.t-systems.com/
