Review PR for BZ 62497
Folks, I have an open trivial PR [1] for five years now. Is anyone willing to review and merge into into trunk and then to 2.4.x? [1] https://github.com/apache/httpd/pull/67 >From a fellow committer, Michael
Re: Crash with SSL renegotiations in 2.4.x branch
Backported in 1844223, will be part of 2.4.37. Thanks again! Rainer Great! Thanks a lot for proposing & backporting. Regards, Michael
Crash with SSL renegotiations in 2.4.x branch
Hi, there's a bug in the current 2.4.x branch of httpd which leads to crashes for SSL renegotiations. The variable "ctx" is always NULL in ssl_engine_kernel.c, ssl_hook_Access_classic(), and it's used here: if (!(cert_store || (cert_store = SSL_CTX_get_cert_store(ctx ... In trunk, this bug has been fixed in r1828793. Please backport this for 2.4.37. Regards, Michael
Re: Wherefor 2.4.36?
Aww, all I care about is getting 2.4.36 going so I can say I have TLS 1.3 supported with my h2. LOL, no but seriously, is 2.4.36 stable enough to be using? -- Sent from: http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
Re: Does httpd work with buildbot or considering buildbot
On 17/09/2018 13:15, Michal Karm wrote: > Ad "Mustard after the meal", exactly what has been troubling me, so I stitched > together this little Jenkins thing :-) > > Cheers > K > > Michal Karm Babacek Looks like I will have some work to do - in the coming days/weeks. signature.asc Description: OpenPGP digital signature
Does httpd work with buildbot or considering buildbot (was: Re: 2.4.35 in Sept?)
On 12/09/2018 22:47, Jim Jagielski wrote: > The idea is that people actually take the time to download the tarballs, > build a version of httpd for their use and then perform testing on said > version such that they can vote on whether to release it or not. That testing > entails such activities as running it through our test framework, putting it > in a dev/prod environment to see how it works, etc... That is a schema that > we have had for... let me see... years and decades. Curious. Does httpd work with buildbots as a way to test things. afaik it works without git repositories - although most seem to. If yes, I would be willing to dedicate some processing cycles from my server - assuming I can get it working. As far as downloading tarballs, etc. - done that in the past (although i am not a registered voter), but generally my 'results' are what the dutch call "Mustard after the meal" aka "too late to have any utility". In short, if yes, or when it moves towards yes - willing to helpout. Michael signature.asc Description: OpenPGP digital signature
Backporting BZ 60330
Hi folks, the issue #60330 has been resolved on trunk and I'd like to have it backported to 2.4.x branch. Yann Ylavic has done some great work and I have been testing this from trunk on FreeBSD 10.4-STABLE against Apache Tomcat 8.5.30. Please comment, Michael
Re: Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)
On 2/9/2018 6:02 AM, William A Rowe Jr wrote: I will continue to work with you on this. The horrors I'm confronting in other upstream projects... Ugh... Please delete apr from your post to list. Unless they understand the purpose of doing so, it is a stupid build chain to reference, an exusible one is httpd's. no longer included... The httpd project is probably the wrong list to address you php concerns, historically, php has always pointed at httpd - however... but I'm ok with our helping you once or twice more. Good luck in your efforts; I think I figured it out: See https://bugs.php.net/bug.php?id=63182 (opened in 2012!!, and nothing. Older ones as well, but maybe they closed that one ;) For the weary: looks like: ancient libtool components (1.5.26, from 2008) and logic that might have almost been correct in 2008 (I have actually had issues since php-4.0.4, and always libtool related). My "fix" - while it gets the jobs done (finally) - it does not mean it is "ASF" caused. My apologies - and thanks! for the hints that got me looking the right area (over 100k lines in php configure - sigh). Anyway - issue is closed - here - as far as I am concerned. Best regards, Michael On Feb 8, 2018 4:19 PM, "Michael Felt" <mailto:aixto...@felt.demon.nl>> wrote: On 07-Feb-18 19:40, William A Rowe Jr wrote: Is the sapi compiled against libtool etc. from httpd? Or is it using the configure logic shipped with the php package? The sapi is compiled using php configure, etc. The install part uses instdso.sh and apxs, instdso.sh, iirc calls the libtool built with/by apr. In any case, asking httpd/apr to conform to the autoconf/libtool packaging of php, which was built using its own flavor of the toolchain seems inconsistent. As I tried to say, this is something I have been trying to get understood by whoever. Going with your idea re: php use of the toolchain - maybe they do something wrong, read unexpected, in the way the library_name variable is defined. And I also wonder, new idea, maybe I need to use the libtool argument (must look it up) to say shared library is not aix, but svr4 style. That might fix the .la contents. So, thx for the thoughts! It seems foolish to ask httpd-apxs to be the install tool of the libphp5 binary. These are two different packages with two different sets of tooling. If you simply fix the make install to point to the build/install.sh tool of php, does it all work? On Wed, Feb 7, 2018 at 8:50 AM, Michael mailto:aixto...@felt.demon.nl>> wrote: a) It has been a hard climb to get httpd-2.4.29 to build using the latest apr and apr-util. Still researching what that is (might be expat related - embedded versus external, still searching). Anyway, working with apr-1.5.2 I was at least able to get httpd-2.4.29 to build so I could proceed to my other "forever" hassle. b) the forever "hassle": over the years (the first time I posted "a bug may be as far back as 2010", not bothering to post before then (or it was working??) - was getting "make install" to work for PHP. c) PHP stated correctly - not them - would be instdso.sh. Also posted, but not conclusive. I hacked at instdso - as it knew what to remove (rm -f) but did not install. I just hard-wired it to copy the file, if, at the end, it was not there. With that, the chmod command that follows instdso.sh works. Quick History, better review: Currently: root@x065:[/data/prj/php/php-5.3.29]make install-sapi Installing PHP SAPI module: apache2handler /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then for i in 0.0.0 0.0 0; do if test -r /data/prj/php/php-5.3.29/libs/libphp5.so.$i; then ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i /data/prj/php/php-5.3.29/libs/libphp5.so; break; fi; done; fi /data/prj/php/src/php-5.3.29/build/shtool mkdir -p '/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir -p '/var/httpd/etc' && /opt/httpd/bin/apxs -S LIBEXECDIR='/opt/httpd/libexec' -S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la <http://libphp5
Re: Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)
On 07-Feb-18 19:40, William A Rowe Jr wrote: Is the sapi compiled against libtool etc. from httpd? Or is it using the configure logic shipped with the php package? The sapi is compiled using php configure, etc. The install part uses instdso.sh and apxs, instdso.sh, iirc calls the libtool built with/by apr. In any case, asking httpd/apr to conform to the autoconf/libtool packaging of php, which was built using its own flavor of the toolchain seems inconsistent. As I tried to say, this is something I have been trying to get understood by whoever. Going with your idea re: php use of the toolchain - maybe they do something wrong, read unexpected, in the way the library_name variable is defined. And I also wonder, new idea, maybe I need to use the libtool argument (must look it up) to say shared library is not aix, but svr4 style. That might fix the .la contents. So, thx for the thoughts! It seems foolish to ask httpd-apxs to be the install tool of the libphp5 binary. These are two different packages with two different sets of tooling. If you simply fix the make install to point to the build/install.sh tool of php, does it all work? On Wed, Feb 7, 2018 at 8:50 AM, Michael wrote: a) It has been a hard climb to get httpd-2.4.29 to build using the latest apr and apr-util. Still researching what that is (might be expat related - embedded versus external, still searching). Anyway, working with apr-1.5.2 I was at least able to get httpd-2.4.29 to build so I could proceed to my other "forever" hassle. b) the forever "hassle": over the years (the first time I posted "a bug may be as far back as 2010", not bothering to post before then (or it was working??) - was getting "make install" to work for PHP. c) PHP stated correctly - not them - would be instdso.sh. Also posted, but not conclusive. I hacked at instdso - as it knew what to remove (rm -f) but did not install. I just hard-wired it to copy the file, if, at the end, it was not there. With that, the chmod command that follows instdso.sh works. Quick History, better review: Currently: root@x065:[/data/prj/php/php-5.3.29]make install-sapi Installing PHP SAPI module: apache2handler /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then for i in 0.0.0 0.0 0; do if test -r /data/prj/php/php-5.3.29/libs/libphp5.so.$i; then ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i /data/prj/php/php-5.3.29/libs/libphp5.so; break; fi; done; fi /data/prj/php/src/php-5.3.29/build/shtool mkdir -p '/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir -p '/var/httpd/etc' && /opt/httpd/bin/apxs -S LIBEXECDIR='/opt/httpd/libexec' -S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la Use of uninitialized value in concatenation (.) or string at /opt/httpd/bin/apxs line 222. /var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la /opt/httpd/libexec rm -f /opt/httpd/libexec/libphp5.so /opt/build-1/libtool --mode=install install libphp5.la /opt/httpd/libexec/ libtool: install: install .libs/libphp5.a /opt/httpd/libexec/libphp5.a libtool: install: install .libs/libphp5.lai /opt/httpd/libexec/libphp5.la libtool: install: warning: remember to run `libtool --finish /data/prj/php/php-5.3.29/libs' chmod 755 /opt/httpd/libexec/libphp5.so chmod: /opt/httpd/libexec/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 . make: 1254-004 The error code from the last command is 1. I think I have it!! With one small change: (/opt/build-1/libtool apr-1.5.2) +3403 # See the names of the shared library. +3404 set dummy $dlname $library_names; shift root@x065:[/data/prj/php/php-5.3.29]make install-sapi Installing PHP SAPI module: apache2handler /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then for i in 0.0.0 0.0 0; do if test -r /data/prj/php/php-5.3.29/libs/libphp5.so.$i; then ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i /data/prj/php/php-5.3.29/libs/libphp5.so; break; fi; done; fi /data/prj/php/src/php-5.3.29/build/shtool mkdir -p '/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir -p '/var/httpd/etc' && /opt/httpd/bin/apxs -S LIBEXECDIR='/opt/httpd/libexec' -S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la Use of uninitialized value in concatenation (.) or string at /opt/httpd/bin/apxs line 222. /var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la /opt/httpd/libexec rm -f /opt/httpd/libexec/libphp5.so /opt/build-1/libtool --mode=install install libphp5.la /opt/httpd/libexec/ libtool: install: install .libs/libphp5.so /opt/httpd/libexec/
Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)
1.5.26 (1.1220.2.492 2008/01/30 06:40:56) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libphp5.so' # Names of this library. library_names='libphp5.a libphp5.a' # The name of the static archive. old_library='' # Libraries that this one depends upon. dependency_libs=' -lz -lrt -liconv -lz -lcurl -lrt -lm -liconv -lm -lcurl -lssh2 -lssh2 -lz -liconv -lm -lz -lm -liconv -lm -liconv -lm -liconv -lm -liconv -lm -L/opt/lib -L/opt/mysql/lib -lz -lrt -lmysqlclient -liconv /opt/lib/libfreetype.la /opt/lib/libpng15.la -lz -lm -lX11 -lXpm -lpng -lz -ljpeg -lcurl -lrt -lm -liconv -lm -lcurl -lssh2 -lssh2 -lssl -lcrypto -lz -liconv -lm -lmysqlclient_r -lz -lnsl_r -lm -liconv -lm -liconv -lm -liconv -lm /opt/lib/libxml2.la -lpthread -liconv -lm -liconv -lm' # Version information for libphp5. current=0 age=0 revision=0 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/data/prj/php/php-5.3.29/libs' *** So, besides sharing my "finding" that I'll just apply locally for php work, my question: Is there any knowledge of others trying to use instdso.sh with a "module" that demands a dlopen-able FILE (as httpd does not accept the packaging of a dlopen() archive member - which is what is in "the library". root@x065:[/data/prj/php/php-5.3.29]ls -l .libs total 6 -rw-r--r-- 1 root 1954 15467005 Feb 06 14:39 libphp5.a -rw-r--r-- 1 root 1954 134349 Feb 06 14:39 libphp5.exp lrwxrwxrwx 1 root 1954 13 Feb 06 14:40 libphp5.la -> ../libphp5.la -rw-r--r-- 1 root 1954 1261 Feb 06 14:40 libphp5.lai -rwxr-xr-x 1 root 1954 15095281 Feb 06 14:39 libphp5.so root@x065:[/data/prj/php/php-5.3.29]ar tv .libs/libphp5.a rwxr-xr-x 0/1954 15095281 Feb 06 14:39 2018 libphp5.so Just showing, in this last bit - that libtool has 'created' all the contents correctly, but libtool cannot --install it correctly. Would appreciate APR/APACHE assistance on getting this 'noticed' by GNU libtool - as in, is it $dlname should be prefixing $library_names, or should $library_names be different? I am hoping someone here (ASF) knows. Many thanks for taking the time to read and think! Michael
Re: New ServerUID directive
On 06/02/2018 11:54, Stefan Eissing wrote: Am 06.02.2018 um 11:45 schrieb Helmut K. C. Tessarek : On 2018-02-06 05:13, Yann Ylavic wrote: Sorry for what is probably (my) bad english, "fixed" meant "the same after restart (or stop/start)". Right, but isn't the virtual host's server name/port config after the restart the same as well? Why do you need a new separate unique identifier? And should you ever change the port number and/or the virtual host's server name, then this virtual host won't be the same after a restart anyway. Either I'm missing something here, but I still don't understand the reason for a unique identifier, when you already have one. You are missing that Yann exactly wants to do that. Only as consideration for people who prefer otherwise, he considered to introduce a ServerUID directive. Now, he tried several times to get the discussion back to what a good *automatic* id for the load balancer is, Ah, for the fortunate that have so much traffic they need the 'lb'. And I imagine, for that 'automatic' is fine. Never had to use one though - so no idea how hard they are to configure/manage. However, I expect I would rather "not care" how the internals work for giving me a vhost ServerID. Why should I care - after a restart whether the value generated is the same or not. That said - what could I do with a ServerID (forget the unique for the moment). Again, my first thoughts are with regard to 'security' aka 'access control'. Could I use (or is there already something I am unaware of) a ServerID in blocks, e.g., with - so that I can specify access control in terms of the rather than as attributes of clients. Might all be nonsense - asin - this is just me brainstorming. I guess my question is closer to: are there ways to manage 'access control' based on the server configuration and the physical resources (mainly thinking files). What is more manageable? What is easier to report on/with (to a non-httpd specialist). What is easier to audit/log, perhaps in separate logs? but everyone keeps discussing directives... *Waves Jedi Hand*: "Forget the directive..." (* Michael blinks - what were we talking about? *) Or at least one that can be used from a combination of several fields in the server struct. What am I missing? -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: New ServerUID directive
On 06/02/2018 11:13, Yann Ylavic wrote: On Tue, Feb 6, 2018 at 10:21 AM, Michael wrote: On 01/02/2018 18:54, Yann Ylavic wrote: I have this patch (attached) floating around that allows users to configure a *fixed* UID for each vhost. When I read the above sentence - with the emphasis on *fixed* my first thoughts were not on httpd internals on how a (semi-)fixed ID is used internally. Sorry for what is probably (my) bad english, "fixed" meant "the same after restart (or stop/start)". I 'translated' it to mean - 'settable' (as a Directive) - and permanence (restarts aka multiple sessions) and bound to the vhost. Falls in the category of "don't want to know. Instead, my initial reaction - this might be useful for having multiple UID - aka "UserNames" or other sort of "external", UID. And the U in UID meant Unique, not User :/ Then I think UUID - except you want it remembered over restarts - rather than for a session. I 'strongly dislike' naming things (i.e., I have a terrible coming up with names I like). PID (Permanant) ID is also confusing. Maybe VHID (Virtual Host ID), or UVID or longer UVHID). However, if it is not for 'external use' - how does it help me? What does it solve (ignorance is bliss!)? I got rather lost during the internal focused discussion. So I may not have choosen the right terms in the first place... Maybe - but great new ideas come from confusion about what was initially meant :) Regards, Yann.
Re: New ServerUID directive
On 01/02/2018 18:54, Yann Ylavic wrote: I have this patch (attached) floating around that allows users to configure a*fixed* UID for each vhost. I am not an httpd expert. And I probably already know more than I want to. When I read the above sentence - with the emphasis on *fixed* my first thoughts were not on httpd internals on how a (semi-)fixed ID is used internally. Falls in the category of "don't want to know. Instead, my initial reaction - this might be useful for having multiple UID - aka "UserNames" or other sort of "external", UID. As I read the discussions I realized my first thought was off - but still I continued thinking about - are there ways to make a vhost UID external, e.g., add to my logs for accountability. And I found myself "dreaming" - how about a different UID (aka Username) that would setuid() per vhost. Could be a nice way to separate data permissions - per vhost. So, maybe you do not really need it for something internal - per your own discussion. However, as a new "Directive" and all - what are ways this could be applied to improve/enhance security and/or accountability. Is, perhaps, the concept of a ServerUID as a new directive something that could be useful to a complex website - and much more than config-file fluff? I hope this helps - and is "out of the box" thinking. If not, well I tried. :) Good day all! Michael
httpd-2.4.29 does not build mod_lbmethod_byrequests.c (xlc)
Travelling, so not able to investigate deeply, but these are the error messages I see: /opt/build-1/libtool --silent --mode=compile xlc_r -qHALT=E -U__STR__ -D_THREAD_SAFE -D_USE_IRS -D_LARGEFILE64_SOURCE -I. -I/data/prj/apache/httpd/httpd-2.4.29/include -I/data/prj/apache/httpd/src/httpd-2.4.29/os/unix -I/data/prj/apache/httpd/src/httpd-2.4.29/include -I/opt/include/apr-1 -I/opt/include -DPCRE_STATIC -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/aaa -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/cache -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/core -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/database -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/filters -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/ldap -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/loggers -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/lua -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/session -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/ssl -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/test -I/data/prj/apache/httpd/src/httpd-2.4.29/server -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/arch/unix -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/dav/main -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/generators -I/data/prj/apache/httpd/src/httpd-2.4.29/modules/mappers -prefer-pic -c /data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c && touch mod_lbmethod_byrequests.slo "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 88.17: 1506-275 (S) Unexpected text ')' encountered. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 88.17: 1506-045 (S) Undeclared identifier apr_OFN_ap_proxy_retry_worker_t. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 88.64: 1506-277 (S) Syntax error: possible missing ')' or ','? "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 96.18: 1506-276 (S) Syntax error: possible missing ')'? "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 95.64: 1506-280 (W) Function argument assignment between types "const char*" and "int" is not allowed. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 142.69: 1506-260 (S) Octal integer constant 01208 is not valid. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 143.22: 1506-276 (S) Syntax error: possible missing ')'? "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 142.68: 1506-280 (W) Function argument assignment between types "const char*" and "int" is not allowed. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 179.5: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 180.5: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 181.5: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 193.1: 1506-273 (E) Missing type in declaration of AP_DECLARE_MODULE. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 193.1: 1506-282 (S) The type of the parameters must be specified in a prototype. "/data/prj/apache/httpd/src/httpd-2.4.29/modules/proxy/balancers/mod_lbmethod_byrequests.c", line 193.40: 1506-512 (S) An initializer is not allowed for "AP_DECLARE_MODULE".
Re: Re: [VOTE] Release Apache httpd 2.4.29 as GA
On 07/11/2017 17:21, Jan Ehrhardt wrote: Steffen in gmane.comp.apache.devel (Thu, 19 Oct 2017 23:15:32 +0200): I said before: In Apache.dsw is now project xml removed, it is not building out of the box with current released apr-util. With coming apr-util 1.6.1 it should be possible to build. With the expat/xml changes in apr-util and httpd, it is now a hard job for most win users to build. Grmbl. I did not expect it to be that hard, even with apr-util 1.6.1. Include directories like ./xml/expat/lib, env var XML_PARSER (which I can guess what it has to be), XML_OPTIONS (no idea what to put there), unresolved external symbol __imp__XML_ParserFree even if I link expat or the old xml ... Formal it is hard to say to go or not, so a +0. Mosterd na de maaltijd: -1. I have been trying to build 2.4.29 on AIX. There are some hard-coded assumptions that are not working. +++ This explains why I am getting a warning "all the time" root@x064:[/data/prj/apache/src/httpd-2.4.29]grep XML_Parse * */* configure: test "x$silent" != "xyes" && echo " setting HTTPD_LDFLAGS to \"-Wl,-uXML_Parse -Wl,-bE:$abs_builddir/server/httpd.exp\"" configure: HTTPD_LDFLAGS="-Wl,-uXML_Parse -Wl,-bE:$abs_builddir/server/httpd.exp" configure: apr_addto_bugger="-Wl,-uXML_Parse -Wl,-bE:$abs_builddir/server/httpd.exp" configure: test "x$silent" != "xyes" && echo " setting UTIL_LDFLAGS to \"-Wl,-uXML_Parse\"" configure: UTIL_LDFLAGS="-Wl,-uXML_Parse" configure: apr_addto_bugger="-Wl,-uXML_Parse" configure.in: APR_ADDTO(HTTPD_LDFLAGS, [-Wl,-uXML_Parse -Wl,-bE:$abs_builddir/server/httpd.exp]) configure.in: APR_ADDTO(UTIL_LDFLAGS, [-Wl,-uXML_Parse]) ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse ++ But I am still stuck re: finding where these are called from. ld: 0711-317 ERROR: Undefined symbol: .XML_Parse ld: 0711-317 ERROR: Undefined symbol: .XML_GetErrorCode ld: 0711-317 ERROR: Undefined symbol: .XML_StopParser ld: 0711-317 ERROR: Undefined symbol: .XML_ParserFree ld: 0711-317 ERROR: Undefined symbol: .XML_ErrorString ld: 0711-317 ERROR: Undefined symbol: .XML_ParserCreate ld: 0711-317 ERROR: Undefined symbol: .XML_SetUserData ld: 0711-317 ERROR: Undefined symbol: .XML_SetElementHandler ld: 0711-317 ERROR: Undefined symbol: .XML_SetCharacterDataHandler ld: 0711-317 ERROR: Undefined symbol: .XML_SetEntityDeclHandler Was there a 2.4.28 (if so, never got around to it - as 2.4.27 is the last one I worked on (and may have nearly finished). FYI: 2.4.25 was the last one I actually finished packaging. Really kind of sad - as httpd was an easy package. emphasis on was. p.s. - sent from the wrong from address, so "repeating" as the first mail might bounce off dev@httpd... Below is an addition to the first message: It appears (from the -bloadmap output) that XML_Parse is suppossed to be coming from apr-util. Or is it APR-UTIL is the caller? :g/XML_Parse/p (ld): keep XML_Parse ld: 0711-301 WARNING: Symbol specified with the -u flag not defined: XML_Parse .XML_Parse[142] ER PR ../src/apr-util-1.6.1/xml/apr_xml.c(/opt/lib/libaprutil-1.a[apr_xml.o]) .XML_ParserFree [148] ER PR ../src/apr-util-1.6.1/xml/apr_xml.c(/opt/lib/libaprutil-1.a[apr_xml.o]) .XML_ParserCreate [176] ER PR ../src/apr-util-1.6.1/xml/apr_xml.c(/opt/lib/libaprutil-1.a[apr_xml.o]) [Press return to continue] +++ Puzzled.
configure option --enable-option-checking warns about things it does know (httpd-2.2.X)
Just thought I would mention option-checking in httpd-2.2.X is borked. Fortunately, it just warns :) A small subset of the warnings: configure: WARNING: unrecognized options: --with-z, --enable-layout, --with-apr, --with-apr-util, --with-mpm, --enable-ssl, --enable-proxy, --enable-mods-shared Regards, Michael p.s. I have not been following the maillist for quite a while - so if this is already known, please ignore.
Re: Question re: build of (64-bit) httpd and issue with apr_password_validate
On 8/21/2016 12:12 AM, Michael Felt wrote:
I fear it is related to my different 'packaging', manually putting the
shared library into the .a archive (which is static only by default).
Going to try both ways (static and rtld linking to the library).
That seems to have fixed it. As I suspected - user (me) error.
a) working with shared_library stored in the archives
(${prefix}/lib/libapr.a and ${prefix}/lib/libaprutil.a
Will test again another day with static apr libraries (only). Advantage
of static could it removes two install dependancies, and maybe slightly
faster.
Re: Question re: build of (64-bit) httpd and issue with apr_password_validate
On 8/19/2016 3:03 PM, Eric Covener wrote: On Fri, Aug 19, 2016 at 7:14 AM, Michael Felt wrote: root@x064:[/data/prj/apache/httpd-2.4.23]nm /opt/modules/mod_authn_file.so | grep apr_password_validate Are you sure that the libapr you're scrutinizing is being loaded at runtime? Needed to reply list... I fear it is related to my different 'packaging', manually putting the shared library into the .a archive (which is static only by default). Going to try both ways (static and rtld linking to the library). Thanks for the feedback!
Re: Question re: build of (64-bit) httpd and issue with apr_password_validate
On 8/19/2016 3:03 PM, Eric Covener wrote: On Fri, Aug 19, 2016 at 7:14 AM, Michael Felt wrote: root@x064:[/data/prj/apache/httpd-2.4.23]nm /opt/modules/mod_authn_file.so | grep apr_password_validate Are you sure that the libapr you're scrutinizing is being loaded at runtime? I have not had time to link again, but I suspect that it is an issue of shared_library being in the archive together with static objects. If that does solve it - then I may want to think about static linking of apr and apr-util rather than rtld. Thanks for 'confirming' my suspicion.
Question re: build of (64-bit) httpd and issue with apr_password_validate
a) I expect I have "enabled" a new httpd flag as I attempt to build a comprehensive 64-bit version of httpd for AIX - so I expect this is a "user error". I am hoping for feedback on where to look (short path is to not load mod_authn_file, for now). I shall try same build as 32-bit and see if the issue goes away. b) I have built apr and apr-util "differently" than in the past in that: b1) added --with-crypto b2) added --with-ldap-dir=/xxx and --with-ldap=ldap Current ./configure command It was created by configure, which was generated by GNU Autoconf 2.69. Invocation command line was $ ../src/httpd-2.4.23/configure --prefix=/opt --sysconfdir=/var/httpd/etc --sharedstatedir=/var/httpd/com --localstatedir=/var/httpd --mandir=/usr/share/man --infodir=/opt/share/info/httpd c) After build completes - apachectl -t fails with: root@x064:[/data/prj/apache/httpd-2.4.23]apachectl -t httpd: Syntax error on line 66 of /var/httpd/etc/httpd.conf: Cannot load modules/mod_authn_file.so into server: rtld: 0712-001 Symbol apr_password_validate was referenced from module /opt/modules/mod_authn_file.so(), but a runtime definition of the symbol was not found.\nrtld: 0712-002 fatal error: exiting. root@x064:[/data/prj/apache/httpd-2.4.23]nm /opt/modules/mod_authn_file.so | grep apr_password_validate .apr_password_validate T 4294970628 .apr_password_validate t 4294970628 40 apr_password_validate U - apr_password_validate d 4563406976 8 root@x064:[/data/prj/apache/httpd-2.4.23]nm /opt/lib/libapr*.a | grep apr_password_validate .apr_password_validate T 0 apr_password_validate D 928 24 apr_password_validate d 896 8 .apr_password_validate T 4295008768 .apr_password_validate T 4295027960 .apr_password_validate t 4295027960 40 apr_password_validate D 4563413360 24 apr_password_validate d 4563420512 8 So, it seems, for some reason - during "make" I think, the U line ( apr_password_validate U - ) has not resolved to the line "apr_password_validate D 4563413360 24" while the "T, t, and d" lines did. And, just to be sure this is not an issue of 32 versus 64-bit listings: root@x064:[/data/prj/apache/httpd-2.4.23]nm -X32 /opt/lib/libapr*.a | grep apr_password_validate .apr_password_validate T 268475264 .apr_password_validate T 268492664 .apr_password_validate t 268492664 40 apr_password_validate D 536881340 12 apr_password_validate d 536884916 4 .apr_password_validate T 0 apr_password_validate D 912 12 apr_password_validate d 896 4 and root@x064:[/data/prj/apache/httpd-2.4.23]nm -X64 /opt/lib/libapr*.a | grep apr_password_validate .apr_password_validate T 0 apr_password_validate D 928 24 apr_password_validate d 896 8 .apr_password_validate T 4295008768 .apr_password_validate T 4295027960 .apr_password_validate t 4295027960 40 apr_password_validate D 4563413360 24 apr_password_validate d 4563420512 8 Many thanks for your ideas! Michael
Re: Regression: mod_http2 continues to process abandoned connection
Hi Stefan,
Yes, the patch solves the problem for me :-) Thanks a bunch!
Regards,
Michael
Zitat von Stefan Eissing :
Michael, I can reproduce the problem and habe a fix. Can you test if
the following patch also solves the problem for you? Thanks!
Index: modules/http2/h2_mplx.c
===
--- modules/http2/h2_mplx.c (revision 1748955)
+++ modules/http2/h2_mplx.c (working copy)
@@ -436,6 +436,9 @@
if (stream->input) {
m->tx_handles_reserved += h2_beam_get_files_beamed(stream->input);
h2_beam_on_consumed(stream->input, NULL, NULL);
+/* Let anyone blocked reading know that there is no more to come */
+h2_beam_abort(stream->input);
+/* Remove mutex after, so that abort still finds cond to signal */
h2_beam_mutex_set(stream->input, NULL, NULL, NULL);
}
h2_stream_cleanup(stream);
Regression: mod_http2 continues to process abandoned connection
t done h2_task.c(725): h2_task(66-1): processing done h2_mplx.c(949): h2_mplx(66): task(66-1) done h2_mplx.c(995): h2_mplx(66-1): request done, 37.554000 ms elapsed h2_mplx.c(1009): h2_mplx(66): increase worker limit to 8 h2_mplx.c(1030): h2_mplx(66-1): task_done, stream in hold h2_workers.c(119): h2_worker(0): looking for work h2_workers.c(159): h2_worker(0): waiting signal (eternal), worker_count=64, idle=64 h2_mplx.c(612): h2_mplx(66): 3. release_join 1 streams to purge h2_stream.c(234): h2_stream(66-1): destroy h2_mplx.c(350): h2_task(66-1): destroy h2_conn.c(316): h2_slave_conn(66): destroy (task=66-1) h2_mplx.c(223): h2_mplx(66): destroy, tasks=0 h2_session.c(799): h2_session(66): free() h2_session.c(799): h2_session(66): free() h2_session.c(799): h2_session(66): free() [...] h2_session.c(698): h2_session(66): destroy h2_conn_io.c(309): (103)Software caused connection abort: AH03044: h2_conn_io(66): pass_out brigade 0 bytes h2_conn.c(215): (70014)End of file found: AH03045: h2_session(66): process, closing conn Regards, Michael
Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Zitat von Stefan Eissing : Withdrawn the proposal in r1747668 after reading the comment from Roy again. Apache is the only HTTP/2 server in this world that sends this strange header. So omitting it would be the right thing to do. Michael, since you know more about this: is there a specific UA string where httpd can detect the broken NodeJS client from and suppress "Update: XXX" response headers? I believe NodeJS is broken on *any* Update response header, right? So, if we fix it for this client, we need to fix any protocol announcement, not just 'h2'. That sounds reasonable. I think the GitHub user that created the original bug report may know which NodeJS versions are affected. Regards, Michael
Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Zitat von William A Rowe Jr : Skimming the responses, they just keep getting more and more amusing, and shining a candle to the absurdity of keeping this non-sequitur request response. Could you go ahead and add that conditional? To all developers who participated in this discussion: Please review the backport proposal and vote +1 if you think that it's not completely wrong :-) Note that "Suppress 'h2' announcements in Upgrade: header" has been inserted at the top of the STATUS file; it should probably be moved to the bottom of the 'Patches proposed' section. Regards, Michael
Re: Detecting client aborts and stream resets
Zitat von Stefan Eissing : Thanks for the patch! I applied it to trunk in r1743335, will be part of next 1.5.4 release. I only omitted the last change as I do not want to set aborted on the main connection every time the session closes. Ok, that's fine for me. Thanks a lot Stefan! Regards, Michael
Re: Detecting client aborts and stream resets
Zitat von William A Rowe Jr :
On Wed, May 4, 2016 at 3:44 PM, Michael Kaufmann
wrote:
William is right, this is not a good idea. The ->aborted flag should serve
this purpose of telling anyone interested that this connection is not
longer delivering. I will make a github release soon where that is working
and you can test.
Thank you Stefan! It is now working for stream resets, but it's not yet
working if the client closes the whole TCP connection.
As expected... this is why I pointed out in my first reply that you don't
want a single-protocol solution to this puzzle.
Of course I'd also prefer a general solution.
I have created a patch for mod_http2: With the patch, it sets
c->aborted on the master connection and also on the "dummy"
connections (streams) when the client closes the TCP connection.
@Stefan: It would be great if you could check this code and add it to
mod_http2 :-)
Index: modules/http2/h2_mplx.c
===
--- modules/http2/h2_mplx.c (revision 1743146)
+++ modules/http2/h2_mplx.c (working copy)
@@ -488,6 +488,15 @@
return 1;
}
+static int task_abort_connection(void *ctx, void *val)
+{
+h2_task *task = val;
+if (task->c) {
+task->c->aborted = 1;
+}
+return 1;
+}
+
apr_status_t h2_mplx_release_and_join(h2_mplx *m, apr_thread_cond_t *wait)
{
apr_status_t status;
@@ -537,6 +546,8 @@
* and workers *should* return in a timely fashion.
*/
for (i = 0; m->workers_busy > 0; ++i) {
+h2_ihash_iter(m->tasks, task_abort_connection, m);
+
m->join_wait = wait;
status = apr_thread_cond_timedwait(wait, m->lock,
apr_time_from_sec(wait_secs));
@@ -591,6 +602,7 @@
AP_DEBUG_ASSERT(m);
if (!m->aborted && enter_mutex(m, &acquired) == APR_SUCCESS) {
m->aborted = 1;
+m->c->aborted = 1;
h2_ngn_shed_abort(m->ngn_shed);
leave_mutex(m, acquired);
}
See my later reply about detecting connection tear-down, patches welcome.
Sounds good! If someone sends a patch, I will help to test it.
Re: Detecting client aborts and stream resets
William is right, this is not a good idea. The ->aborted flag should serve this purpose of telling anyone interested that this connection is not longer delivering. I will make a github release soon where that is working and you can test. Thank you Stefan! It is now working for stream resets, but it's not yet working if the client closes the whole TCP connection. Regards, Michael
Re: Detecting client aborts and stream resets
Zitat von William A Rowe Jr : On Tue, May 3, 2016 at 9:31 AM, Michael Kaufmann wrote: Hi all, a content generator module can detect client aborts and stream resets while it reads the request body. But how can it detect this afterwards, while the response is being generated? This is important for HTTP/2, because the client may reset a stream, and mod_http2 needs to wait for the content generator to finish. Therefore the content generator should stop generating the response when it is no longer needed. Is there any API for this? The "conn_rec->aborted" flag exists, but which Apache function sets this flag? If there is no API, maybe an optional function for mod_http2 would be a solution. Nope - an optional function in mod_http2 is too special case, generators must remain protocol (socket or other transport) agnostic. Sure, official Apache modules should not call protocol-dependent hooks, but it could be a solution for 3rd party modules. In the case of mod_cache'd content, the generator can't quit, it is already populating a cache, which means you'll generate an invalid cached object. But if you knew that the cache module wasn't collecting info, r->c->aborted tells you if anyone is still listening, right? Unfortunately not. While the content generator is running (just preparing the response, it is not reading from the input filters anymore and not writing to the output filters yet), Apache does not check the connection's state. I'm not sure how mod_proxy deals with this - does it abort the backend request when the client closes the connection?
[PATCH 54255] mod_deflate adjusts the headers "too late"
Hi, It would be great if somebody could have a look at the proposed patch. The problem: Request headers are adjusted too late (in the input filter). Proposed solution: Adjust the request headers in the filter init function. https://bz.apache.org/bugzilla/show_bug.cgi?id=54255 Regards, Michael
Detecting client aborts and stream resets
Hi all, a content generator module can detect client aborts and stream resets while it reads the request body. But how can it detect this afterwards, while the response is being generated? This is important for HTTP/2, because the client may reset a stream, and mod_http2 needs to wait for the content generator to finish. Therefore the content generator should stop generating the response when it is no longer needed. Is there any API for this? The "conn_rec->aborted" flag exists, but which Apache function sets this flag? If there is no API, maybe an optional function for mod_http2 would be a solution. Regards, Michael
Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Done in r1740075.
I think that commit introduced a small bug, because the "for" loop is
left when "h2" is seen and "report_all" is false. There may be other
protocols that are more preferred than the current one.
Suggested change:
Index: server/protocol.c
===
--- server/protocol.c (revision 1740112)
+++ server/protocol.c (working copy)
@@ -2017,15 +2017,18 @@
* existing. (TODO: maybe 426 and Upgrade then?) */
upgrades = apr_array_make(pool, conf->protocols->nelts + 1,
sizeof(char *));
for (i = 0; i < conf->protocols->nelts; i++) {
const char *p = APR_ARRAY_IDX(conf->protocols, i, char *);
/* special quirk for HTTP/2 which does not allow 'h2' to
* be part of an Upgrade: header */
-if (strcmp(existing, p) && strcmp("h2", p)) {
+if (!strcmp("h2", p)) {
+continue;
+}
+if (strcmp(existing, p)) {
/* not the one we have and possible, add in this order */
APR_ARRAY_PUSH(upgrades, const char*) = p;
}
else if (!report_all) {
break;
}
}
Regards,
Michael
Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Zitat von Stefan Eissing : Done in r1740075. I was thinking of a nicer solution, but that involved inventing new hooks which seems not worth it. Since this area of protocol negotiation has already been talked about in regard to TLS upgrades and websockets, I do not want to invest in the current way of handling this too much time. -Stefan Thank you Stefan. Also thanks to everyone who took part in the discussion. This topic is way more complex than I thought. Regards, Michael
Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
On Tue, Apr 19, 2016 at 8:57 AM, Michael Kaufmann wrote: Yes, you are right. But with the response header "Upgrade: h2", Apache is telling the client "you may send such a header" when in fact this is not allowed. Devils advocate: Apache is telling the client at the application layer its protocol support and preferences. Something it couldn't actually do with ALPN. If the client knows HTTP/2 it has knows the particulars of the Upgrade. I'd suggest taking it up with the HTTP/2 workgroup mailing list. Good idea. I have sent a mail to the HTTP/2 workgroup mailing list, so let's discuss this issue there: https://lists.w3.org/Archives/Public/ietf-http-wg/
Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
On Tue, Apr 19, 2016 at 8:47 AM, Michael Kaufmann wrote: I think that this is wrong, because of this sentence in RFC 7540: A server MUST ignore an "h2" token in an Upgrade header field. Presence of a token with "h2" implies HTTP/2 over TLS, which is instead negotiated as described in Section 3.3. Isn't that referring to inbound Upgrade headers? Yes, you are right. But with the response header "Upgrade: h2", Apache is telling the client "you may send such a header" when in fact this is not allowed.
"Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Hi, you may already know that HTTP/2 clients use ALPN to advertise support for HTTP/2 when TLS is used. The issue is this: When mod_http2 is enabled, Apache sends an "Upgrade: h2" response header to clients that have *not* advertised support for HTTP/2 (clients that speak only HTTP/1.x). I think that this is wrong, because of this sentence in RFC 7540: A server MUST ignore an "h2" token in an Upgrade header field. Presence of a token with "h2" implies HTTP/2 over TLS, which is instead negotiated as described in Section 3.3. What do you think about this issue, and what do you think about the attached patch in bug 59311? Regards, Michael
Re: Bug with "SetHandler None"
Eric Covener wrote: On Sat, Mar 19, 2016 at 11:31 AM, Michael Kaufmann wrote: I have found a bug in the current 2.4.x branch: "SetHandler None" does not work anymore (note the capital letter "N"). This worked with Apache 2.4.18. Probably this commit has changed the behavior: http://svn.apache.org/r1729876 Thanks Michael! Thank you for fixing the bug! :-)
Bug with "SetHandler None"
Hi, I have found a bug in the current 2.4.x branch: "SetHandler None" does not work anymore (note the capital letter "N"). This worked with Apache 2.4.18. Probably this commit has changed the behavior: http://svn.apache.org/r1729876 The documentation at https://httpd.apache.org/docs/2.4/en/mod/core.html#sethandler is inconsistent: In the syntax definition, the value "none" is used, but there is also this sentence: "You can override an earlier defined SetHandler directive by using the value None." So I expect that both "none" and "None" should work. Example configuration that shows the problem (the send-as-is handler is not used anymore for asis files): SetHandler None AddType text/html .html .asis AddHandler send-as-is html asis Regards, Michael
Re: nghttp2 warning - what is this?
I have not tried executing the package. When I get home I will try to
execute what I have and see it it fails because a library is missing.
A warning more in the line of systemd or journald - that there is no h2
support available, and, per the comment above - just make sure it is not in
the enabled modules even with enable all set - should be sufficient - imho.
On Thu, Sep 17, 2015 at 1:26 PM, Yann Ylavic wrote:
> Isn't mod_h2 removed from the list of "enable-mods-shared=all" already
> when libh2 isn't available?
> There is no point in enabling it in this case, so a warning about
> disabling it automatically looks enough to me.
>
> On Thu, Sep 17, 2015 at 10:27 AM, Stefan Eissing
> wrote:
> > What do you propose? A better warning when libnghttp2 cannot be found at
> all? Anything else?
> >
> >> Am 16.09.2015 um 18:42 schrieb Michael Felt :
> >>
> >> well, correction on building nghttp. Seems it only expects to work in a
> GNU rte and I do not have the time to verify an environment that will
> support "POSIX" and GNU requirements. My experience is "small", i.e., not
> saying it cannot be done - but anytime I have tried to build a library that
> insisted on gcc I could not get it to work reliably with packages built
> using the IBM compiler and the default AIX libc (et al) .rte filesets.
> Basically, I need to add all the libraries that gcc needs to compile
> something.
> >>
> >> Oh well. In any case, not tonight.
> >>
> >> (p.s. gcc 4.7.X implies a standard compiler might work - if I
> understand correctly that there is a break with standard C starting with
> gcc 4.8)
> >>
> >> On Wed, Sep 16, 2015 at 6:31 PM, Michael Felt
> wrote:
> >> well, just built it again, with --enable-maintainer-mode added, so now
> have:
> >>
> >> It was created by configure, which was
> >> generated by GNU Autoconf 2.69. Invocation command line was
> >>
> >> $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config
> --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all
> --enable-mods-shared=all --disable-lua --enable-load-all-modules
> --enable-maintainer-mode
> >>
> >> I guess it will "complain" if I try to do anything. re: SSL - it is
> special, especially with the likes of libressl (aka "others" out there) -
> so maybe not the best test code - copying the test for pcre may be better.
> That caught me asap when I first started.
> >>
> >> And I shall go look for the library and get it built. Thanks for your
> quick reply!
> >>
> >>
> >>
> >> Slightly off topic - not sure if relevent considering the -Werror
> changes (whatever that is suppossed to mean in gcc land) here are the
> warning messages that are getting sent by XLC to stderr (there are
> more/others going to stdout):
> >>
> >> "util_expr_eval.c", line 1767.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1768.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1769.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1771.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1772.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1773.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1774.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1775.7: 1506-196 (W) Initialization between
> types "const void* const" and "const char*(*)(struct {...}*,const
> void*,const char*)" is not allowed.
> >> "util_expr_eval.c", line 1776.7: 1506-196 (W) Initialization
Re: nghttp2 warning - what is this?
well, correction on building nghttp. Seems it only expects to work in a GNU
rte and I do not have the time to verify an environment that will support
"POSIX" and GNU requirements. My experience is "small", i.e., not saying it
cannot be done - but anytime I have tried to build a library that insisted
on gcc I could not get it to work reliably with packages built using the
IBM compiler and the default AIX libc (et al) .rte filesets. Basically, I
need to add all the libraries that gcc needs to compile something.
Oh well. In any case, not tonight.
(p.s. gcc 4.7.X implies a standard compiler might work - if I understand
correctly that there is a break with standard C starting with gcc 4.8)
On Wed, Sep 16, 2015 at 6:31 PM, Michael Felt wrote:
> well, just built it again, with --enable-maintainer-mode added, so now
> have:
>
> It was created by configure, which was
> generated by GNU Autoconf 2.69. Invocation command line was
>
> $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config
> --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all
> --enable-mods-shared=all --disable-lua --enable-load-all-modules
> --enable-maintainer-mode
>
> I guess it will "complain" if I try to do anything. re: SSL - it is
> special, especially with the likes of libressl (aka "others" out there) -
> so maybe not the best test code - copying the test for pcre may be better.
> That caught me asap when I first started.
>
> And I shall go look for the library and get it built. Thanks for your
> quick reply!
>
>
>
> Slightly off topic - not sure if relevent considering the -Werror changes
> (whatever that is suppossed to mean in gcc land) here are the warning
> messages that are getting sent by XLC to stderr (there are more/others
> going to stdout):
>
> "util_expr_eval.c", line 1767.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1768.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1769.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1771.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1772.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1773.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1774.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1775.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1776.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1777.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1778.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1779.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1780.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1781.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1782.7: 1506-196 (W) Initialization between types
Re: nghttp2 warning - what is this?
har*)" is
not allowed.
"util_expr_eval.c", line 1795.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1796.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1797.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1798.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1799.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1800.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1801.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1802.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1803.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1804.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1805.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1806.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1807.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1812.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*,const
char*)" is not allowed.
"util_expr_eval.c", line 1813.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*,const
char*)" is not allowed.
"util_expr_eval.c", line 1814.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*,const
char*)" is not allowed.
"util_expr_eval.c", line 1815.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*,const
char*)" is not allowed.
make[2]: warning: Clock skew detected. Your build may be incomplete.
make[1]: warning: Clock skew detected. Your build may be incomplete.
"mod_include.c", line 722.26: 1506-068 (W) Operation between types "const
void*" and "const char*(*)(struct {...}*,const void*,const char*)" is not
allowed.
"mod_headers.c", line 971.43: 1506-280 (W) Function argument assignment
between types "const void*" and "const char*(*)(struct request_rec*,char*)"
is not allowed.
"ssl_engine_vars.c", line 161.26: 1506-068 (W) Operation between types
"const void*" and "const char*(*)(struct {...}*,const void*)" is not
allowed.
"ssl_engine_vars.c", line 168.26: 1506-068 (W) Operation between types
"const void*" and "struct apr_array_header_t*(*)(struct {...}*,const
void*,const char*)" is not allowed.
On Wed, Sep 16, 2015 at 5:57 PM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:
> Hi,
>
> if you enable all modules, it will enable mod_h2 and that one needs
> libnghttp2. The warning could be better, if this is missing, admittedly I
> just copied and modified mod_ssl's test for openssl.
>
> //Stefan
>
>
>
> > Am 16.09.2015 um 17:51 schrieb Michael Felt :
> >
> > Hello all,
> >
> > I have been ignoring building httpd-2.5.x and thought it was about time
> to start taking notice. And I see a bunch of new messages - one of which
> may be a drift in time between my AIX server and the NFS server I keep all
> the files on.
> >
> > But the first WARNING I saw was from nghttp2 - which perhaps I do not
> have at all! Is this something extra, like pcre or apr that I need to have
> as a library first? If so, the WARNING about it being too old is not
> correct - because I do not have it at all.
> >
> > However, if it is a module within httpd-2.5.x - how could it be too old
> when I have just refreshed from the SVN repository?
> >
> > Snip
> >
> > + ./configure
> > --enable-layout=AIX
> > --with-apr=/opt/bin/apr-1-config
> > --with-apr-util=/opt/bin/apu-1-config
> > --enable-mpms-shared=all
> > --enable-mods-shared=all
> > --disable-lua > build/aix/configure.out
> > configure: WARNING: apr/apr-util is compiled without ldap support
> > configure: WARNING: nghttp2 version is too old
> > configure: WARNING: apr/apr-util is compiled without ldap support
> > configure: WARNING: Your system does not support Journald.
> > configure: WARNING: Your system does not support systemd.
> > + make > build/aix/make.out
> > make: Warning: File '/data/prj/apache/httpd/httpd-2.5.x/.deps' has
> modification time 118 s in the future
> >
>
nghttp2 warning - what is this?
Hello all, I have been ignoring building httpd-2.5.x and thought it was about time to start taking notice. And I see a bunch of new messages - one of which may be a drift in time between my AIX server and the NFS server I keep all the files on. But the first WARNING I saw was from nghttp2 - which perhaps I do not have at all! Is this something extra, like pcre or apr that I need to have as a library first? If so, the WARNING about it being too old is not correct - because I do not have it at all. However, if it is a module within httpd-2.5.x - how could it be too old when I have just refreshed from the SVN repository? Snip + ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all --enable-mods-shared=all --disable-lua > build/aix/configure.out configure: WARNING: apr/apr-util is compiled without ldap support configure: WARNING: nghttp2 version is too old configure: WARNING: apr/apr-util is compiled without ldap support configure: WARNING: Your system does not support Journald. configure: WARNING: Your system does not support systemd. + make > build/aix/make.out make: Warning: File '/data/prj/apache/httpd/httpd-2.5.x/.deps' has modification time 118 s in the future
revisiting instdso.sh reported bugs - after nearly 8 years - maybe actually patch instdso.sh ??
Over the years (2007 being the first time for me) there have been at least three bugs reported re: instdso.sh - two on PHP - which they closed as not a PHP bug, and one on the apache bug list. 1. https://bugs.php.net/bug.php?id=27795 2. https://bugs.php.net/bug.php?id=43032 3. https://bz.apache.org/bugzilla/show_bug.cgi?id=43012 Further, I started a mail discussion here as well http://mail-archives.apache.org/mod_mbox/httpd-dev/201405.mbox/ See message titled:Subject Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php Today I started repackaging php again (I lost my previous archive during a NAS update. User error, snif) - and this brought me back to this problem. The patch I am using is: --- ./build/instdso.sh 2006-07-12 03:38:44 + +++ /var/httpd/build/instdso.sh 2014-06-20 19:13:56 + @@ -72,6 +72,20 @@ exit 0 fi +if test "$DLNAME" != "$TARGET_NAME" +then +mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME +fi + +# at this point $TARGETDIR/$TARGET_NAME should exist +# if not, let's hope it is in .libs and copy it to $TARGET_DIR +status=0 +if ! test -e $TARGETDIR/$TARGET_NAME +then + cp -p .libs/$TARGET_NAME $TARGETDIR/$TARGET_NAME || exit 1 + status=$? +fi + if test -n "$LIBRARY_NAMES" then for f in $LIBRARY_NAMES @@ -80,14 +94,9 @@ done fi -if test "$DLNAME" != "$TARGET_NAME" -then -mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME -fi - rm -f $TARGETDIR/$DSOARCHIVE_BASENAME rm -f $TARGETDIR/$DSOBASE.a rm -f $TARGETDIR/lib$DSOBASE.a rm -f $TARGETDIR/lib$TARGET_NAME -exit 0 +exit $status And I would be very happy - after 8 years of waiting - if instdso.sh could be patched. Feel free to delete my comments about hoping TARGET_NAME is in .libs p.s. Something "nice", but optional * the patch above fixes the regular make install command - however, when working with INSTALL_ROOT (the php equivalent of using DESTDIR) - the update of httpd.conf to add the module basically always fails. Rather than exit with non-zero status - only giving a warning message would be nicer - so the "DESTDIR" aka INSTALL_ROOT install finishes. Currently I am getting: + make install DESTDIR=/var/aixtools/prj/php/5.2.17.0> .buildaix/install.out /var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec libtool: install: warning: remember to run `libtool --finish /data/prj/php/php-5.2.17/libs' chmod 755 /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec/libphp5.so apxs:Error: Config file /var/aixtools/prj/php/5.2.17.0/var/httpd/etc/httpd.conf not found. make: 1254-004 The error code from the last command is 1. I can almost get the same using "make -i install" root@x064:[/data/prj/php/php-5.2.17]INSTALL_ROOT=/var/aixtools/prj/php/5.2.17.0 root@x064:[/data/prj/php/php-5.2.17]export INSTALL_ROOT root@x064:[/data/prj/php/php-5.2.17]make -i install Installing PHP SAPI module: apache2handler /var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec rm -f /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec/libphp5.so /opt/build-1/libtool --mode=install cp libphp5.la /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec/ libtool: install: cp .libs/libphp5.a /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec/libphp5.a libtool: install: cp .libs/libphp5.lai /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec/libphp5.la libtool: install: warning: remember to run `libtool --finish /data/prj/php/php-5.2.17/libs' chmod 755 /var/aixtools/prj/php/5.2.17.0/opt/httpd/libexec/libphp5.so apxs:Error: Config file /var/aixtools/prj/php/5.2.17.0/var/httpd/etc/httpd.conf not found. make: 1254-004 The error code from the last command is 1. make: 1254-005 Ignored error code 1 from last command. Installing PHP CLI binary:/var/aixtools/prj/php/5.2.17.0/opt/bin/ Installing PHP CLI man page: /var/aixtools/prj/php/5.2.17.0/opt/man/man1/ Installing build environment: /var/aixtools/prj/php/5.2.17.0/opt/lib/php/build/ Installing header files: /var/aixtools/prj/php/5.2.17.0/opt/include/php/ Installing helper programs: /var/aixtools/prj/php/5.2.17.0/opt/bin/ program: phpize program: php-config Installing man pages: /var/aixtools/prj/php/5.2.17.0/opt/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /var/aixtools/prj/php/5.2.17.0/opt/lib/php/ [PEAR] Archive_Tar- installed: 1.3.7 [PEAR] Console_Getopt - installed: 1.2.3 [PEAR] Structures_Graph- installed: 1.0.3 [PEAR] XML_Util - installed: 1.2.1 [PEAR] PEAR - installed: 1.9.1 Wrote PEAR system config file at: /var/aixtools/prj/php/5.2.17.0//opt/etc/pear.conf You may want to add: /opt/lib/php to your php.ini include_path Installing PDO headers: /var/aixtools/prj/php/5.2.17.0/opt/include/php/ext/pdo/ Target "install" is up to date.
Apache-Test, httpd-2.2.31 - help with debug/understanding t/ssl related error_log requested
I have built, and "tested" httpd-2.2.31 - and while 2.4.16 has no
errors, 2.2.31 reports some errors.
I have tried to understand the error_log, but I am not making any sense
of the output.
This is using OpenSSL. Same errors, and basically same error_log output
regardless of linked against OpenSSL-0.9.8.so or OpenSSL-1.0.0.so (i.e.,
the same tests fail).
FYI: I have also tested against LibreSSL and get many more messages. And
the good news is that there were many more failed tests with version
2.2.29 - so version 2.2.31 has corrected many t/ssl errors compared to
2.2.29
Suggestions/Hints on how to proceed welcome (read requested).
Procedure used:
First ran "t/TEST t/ssl" to get the general results (see Extra info below)
then: the following sequence
t/TEST -start-httpd
# clear the logs
for i in access_log error_log rewrite_log
ssl_request_log^Jdo^J>t/logs/$i^Jdone
t/TEST t/ssl/extlookup.t
cp -rp t/logs 2.2.31/extlookup.t.logs
for i in access_log error_log rewrite_log
ssl_request_log^Jdo^J>t/logs/$i^Jdone
t/TEST t/ssl/require.t
cp -rp t/logs 2.2.31/require.t.logs
t/TEST -stop-httpd
END of procedure...
** Comments/Current Thoughts **
re: "REQUIRE"
a) I do not understand why the "require" test even has the Failed
expression (cannot find "Lemons", as it is not in the require.t test -
but is part of the text for in the test extlookup.t
b) I am guessing this is not the failing test in the require.t test ...
[Sat Jul 25 12:34:02 2015] [debug] ssl_engine_kernel.c(1842): OpenSSL:
Loop: SSLv3 flush data
[Sat Jul 25 12:34:02 2015] [debug] ssl_engine_kernel.c(1838): OpenSSL:
Handshake: done
[Sat Jul 25 12:34:02 2015] [info] Connection: Client IP: 127.0.0.1,
Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Access to
/data/prj/apache/httpd/test/t/htdocs/index.html denied for 127.0.0.1
(requirement expression not fulfilled)
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Failed expression:
(%{SSL_CIPHER} !~ m/^(EXP|NULL)-/ and
%{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd."
and %{SSL_CLIENT_S_DN_OU}
in {"Staff", "CA", "Dev"} )
[Sat Jul 25 12:34:02 2015] [error] [client 127.0.0.1] access to
/data/prj/apache/httpd/test/t/htdocs/index.html failed, reason: SSL
requirement expression not fulfilled (see SSL
logfile for more details)
[Sat Jul 25 12:34:02 2015] [debug] ssl_engine_kernel.c(1852): OpenSSL:
Write: SSL negotiation finished successfully
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Connection closed
to child 2 with standard shutdown (server loopback:8532)
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Connection to child
1 established (server loopback:8532)
[Sat Jul 25 12:34:02 2015] [info] Seeding PRNG with 136 bytes of entropy
c)but I think this might be... except - it would seem to make more sense
as a message from the extlookup.t or is this just coming much too late
in the error_log (i.e., a late flush of a log?)?
[Sat Jul 25 12:34:02 2015] [info] Connection: Client IP: 127.0.0.1,
Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Access to
/data/prj/apache/httpd/test/t/htdocs/index.html denied for 127.0.0.1
(requirement expression not fulfilled)
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Failed expression:
"Lemons" in OID("1.3.6.1.4.1.18060.12.0")
[Sat Jul 25 12:34:02 2015] [error] [client 127.0.0.1] access to
/data/prj/apache/httpd/test/t/htdocs/index.html failed, reason: SSL
requirement expression not fulfilled (see SSL
logfile for more details)
[Sat Jul 25 12:34:02 2015] [debug] ssl_engine_kernel.c(1852): OpenSSL:
Write: SSL negotiation finished successfully
[Sat Jul 25 12:34:02 2015] [info] [client 127.0.0.1] Connection closed
to child 2 with standard shutdown (server loopback:8532)
root@x064:[/data/prj/apache/httpd/test/2.2.31]grep 18060 ../t/ssl/*.t
../t/ssl/extlookup.t: "1.3.6.1.4.1.18060.12.0" => "Lemons",
Extra INFO
root@x064:[/data/prj/apache/httpd/test]t/TEST t/ssl
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/opt/perl5/bin/perl
/data/prj/apache/httpd/test/t/TEST 't/ssl'
[ info] adding source lib /data/prj/apache/httpd/test/Apache-Test/lib
to @INC
t/ssl/basicauth.t .. ok
t/ssl/env.t ok
t/ssl/extlookup.t .. 1/4 # Failed test 2 in t/ssl/extlookup.t at line 27
t/ssl/extlookup.t .. Failed 1/4 subtests
t/ssl/fakeauth.t ... ok
t/ssl/headers.t ok
t/ssl/http.t ... ok
t/ssl/pr12355.t ok
t/ssl/pr43738.t ok
t/ssl/proxy.t .. ok
t/ssl/require.t 8/10 # Failed test 9 in t/ssl/require.t at line 44
t/ssl/require.t Failed 1/10 subtests
t/ssl/v2.t . ok
t/ssl/varlookup.t .. ok
t/ssl/verify.t . ok
Test Summary Report
---
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 2
t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1)
Failed test
Re: Recommended version of Perl for test framework
I have been installing Bundle::ApacheTest on AIX 5.3, with perl-5.8.2 and the tests seem to be working normally for me. There have been some "//" comment errors pop-up in a few mods, and a define that AIX does not like with a few mods. But other than those typos the only problem I have had is with getting SSLeay to keep working after updating OpenSSL. rebuilding the modules after game changing updates seems to clear errors. On Wed, Jul 22, 2015 at 3:04 PM, Jim Jagielski wrote: > > > On Jul 22, 2015, at 8:21 AM, Kevin A. McGrail wrote: > > > > On 7/22/2015 6:43 AM, Jim Jagielski wrote: > >> Nothing stands out... weird. I may try compiling on my own. > > Well, the gccversion is different. > > > > clang-600.0.54 v clang-600.0.39 > > > > I doubt that's causing the problem. > > In any case, I've built perl by hand, installed it in /opt/perl > to avoid any conflicts, and all is well. > >
Re: CipherLists and who has control: aka what to do re: renegotiate - a simple way to set minimum levels in "core"?
On 2015-07-18 6:12 PM, William A Rowe Jr wrote: This was addressed for 2.2.31 and 2.4.16... See the significantly revised default docs/conf/extra/httpd-ssl.conf.in template for our recommended config. I am "behind the times" obviously here. I have some regular work to do, but I shall try adopting the settings in httpd-ssl.conf and see if it has any effect on the tests when using OpenSSL. Ideally, I will be able to set "my defaults" so that a test with a CipherSuite setting that is lower that I want to serve - as a server - will also 'FAIL' because the renegotiation is not permitted "by me". We won't be entertaining patches to change the compiled-in behavior in these maintenance branches, this has severely negative impacts on users updating to the same version major.minor for security updates on an expedited basis. I was not expecting anything "compiled-in", why I was thinking httpd.conf to "literally" put in a place that cannot be avoided rather than somewhere someone should be looking (like asking people to read the manual :) ) Our discussions of compiled-in behavior changes is limited to svn trunk (what will become httpd 2.6 or 3.0). Much of this discussion becomes mute in the coming year or few as users deploy OpenSSL, LibreSSL or GNUTLS with all legacy SSLv3 and TLSv1.0 support eliminated. Yes, this is also what got me digging - the absolute demand that a) system already running TLS1.0 are permissable but must come up with a change plan b) systems not running TLS1.2 must do so by 1 July 2016 c) all new systems MUST use TLS1.2 from the start. (paraphrased from memory, so I hope I have the key points correct!) Many thanks for your reply! On Jul 18, 2015 10:40, "Michael Felt" wrote: A) OpenSSL and LibreSSL behave differently. Not surprising, because LibreSSL got it's start because OpenBSD was (my words) - fed up - with the upkeep of OpenSSL. And there are several presentations of "the first 30 days of LibreSSL" where the focus was on cutting out anything they felt was inherently insecure (keeping calls for "linking", but having them be a no-op). B) Maybe for a long time - 'attackers' have been targeting weaknesses in the OpenSSL specification (e.g. arbitrary order decidedfor ciphers, kex, etc.). Since HeartBleed and POODLE there is, in any case, a lot more attention to these issues. My (humble) opinion: for something as important to society - as httpd is these days - httpd should do (and maybe you have already!) to make sure that "any client" cannot break a server, or force into low modes of encryption. "The server should decide" and the defaults should be higher than they are now - even if it be arranged by a "simple change" (I would hope) to httpd.conf where a configuration line is added to force "TLS1.2" as minimum encryption - should it be used. p.s. - my goal is to start a discussion - if this is not the right place - "kick me", and I shall look for a better venue. regards, Michael On 2015-07-18 3:44 PM, Eric Covener wrote: On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt wrote: * Should the server determine that for a specific "Location"/"Directory" more strict levels are needed then a new handshake (renegotiate if you prefer) for a stricter cipher should start. However, based on the assumption above (the strictest cipher that the client has is already being used) - this should always fail because the client is not already at that level. The assumption is not right. The servers list and the clients list are in an arbitrary order decided by whoever wrote and configured the software, and the server can choose to honor either (or neither, but that would be weird) ordering. Also, some ciphers do not have such a strict relative ordering of strength.
CipherLists and who has control: aka what to do re: renegotiate - a simple way to set minimum levels in "core"?
A) OpenSSL and LibreSSL behave differently. Not surprising, because LibreSSL got it's start because OpenBSD was (my words) - fed up - with the upkeep of OpenSSL. And there are several presentations of "the first 30 days of LibreSSL" where the focus was on cutting out anything they felt was inherently insecure (keeping calls for "linking", but having them be a no-op). B) Maybe for a long time - 'attackers' have been targeting weaknesses in the OpenSSL specification (e.g. arbitrary order decidedfor ciphers, kex, etc.). Since HeartBleed and POODLE there is, in any case, a lot more attention to these issues. My (humble) opinion: for something as important to society - as httpd is these days - httpd should do (and maybe you have already!) to make sure that "any client" cannot break a server, or force into low modes of encryption. "The server should decide" and the defaults should be higher than they are now - even if it be arranged by a "simple change" (I would hope) to httpd.conf where a configuration line is added to force "TLS1.2" as minimum encryption - should it be used. p.s. - my goal is to start a discussion - if this is not the right place - "kick me", and I shall look for a better venue. regards, Michael On 2015-07-18 3:44 PM, Eric Covener wrote: On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt wrote: * Should the server determine that for a specific "Location"/"Directory" more strict levels are needed then a new handshake (renegotiate if you prefer) for a stricter cipher should start. However, based on the assumption above (the strictest cipher that the client has is already being used) - this should always fail because the client is not already at that level. The assumption is not right. The servers list and the clients list are in an arbitrary order decided by whoever wrote and configured the software, and the server can choose to honor either (or neither, but that would be weird) ordering. Also, some ciphers do not have such a strict relative ordering of strength.
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-18 3:44 PM, Eric Covener wrote: On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt wrote: * Should the server determine that for a specific "Location"/"Directory" more strict levels are needed then a new handshake (renegotiate if you prefer) for a stricter cipher should start. However, based on the assumption above (the strictest cipher that the client has is already being used) - this should always fail because the client is not already at that level. The assumption is not right. The servers list and the clients list are in an arbitrary order decided by whoever wrote and configured the software, and the server can choose to honor either (or neither, but that would be weird) ordering. Also, some ciphers do not have such a strict relative ordering of strength. That is the problem with 'assumptions' of course. Assumptions are frequently wrong. By specifying "defaults" I was hoping that httpd defaults would behave/order from highest to lowest - however, it seems OpenSSL never came up with a good naming scheme of "better" to worse. The closest you can get to a listing of defaults (I read elsewhere) is the output of the command "openssl ciphers -v"
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 4:44 PM, William A Rowe Jr wrote: On Fri, Jul 17, 2015 at 9:18 AM, Yann Ylavic wrote: Attached are the logs from both httpd and s_client, where we can see that httpd somehow expects a client certificate during the renegotiation (without sending any certificate request...), while s_client obviously does not send anything like that (but its key exchange). I can't explain that... I'd need to debug. Does this ring someone's bell? Sure. AIUI, LibreSSL stripped out TLS renegotiation as an 'unsafe thing'. Some of our tests demonstrate per-dir renegotiation for stricter SSL ciphers or client certs in specific contexts, but this would not be a supported feature under LibreSSL if I understood their scope changes correctly. The test is right, IMHO. Except these tests are going - atm - from more strict to less strict - if I understand the error_log output from "OpenSSL" - when the tests do not fail. [Thu Jul 16 12:10:47.979101 2015] [ssl:info] [pid 385024:tid 515] [client 127.0.0.1:39154] AH01964: Connection to child 0 established (server loopback:8532) [Thu Jul 16 12:10:47.979609 2015] [ssl:debug] [pid 385024:tid 515] ssl_engine_kernel.c(1936): [client 127.0.0.1:39154] AH02645: Server name not provided via TLS extension (using default/first virtual host) [Thu Jul 16 12:10:48.043295 2015] [ssl:debug] [pid 385024:tid 515] ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits) [Thu Jul 16 12:10:48.107123 2015] [mpm_worker:error] [pid 467080:tid 1] AH00287: server is within MinSpareThreads of MaxRequestWorkers, consider raising the MaxRequestWorkers setting [Thu Jul 16 12:10:48.107283 2015] [ssl:debug] [pid 385024:tid 515] ssl_engine_kernel.c(243): [client 127.0.0.1:39154] AH02034: Initial (No.1) HTTPS request received for child 0 (server loopback:8532) [Thu Jul 16 12:10:48.107746 2015] [ssl:debug] [pid 385024:tid 515] ssl_engine_kernel.c(500): [client 127.0.0.1:39154] AH02220: Reconfigured cipher suite will force renegotiation [Thu Jul 16 12:10:48.107774 2015] [ssl:info] [pid 385024:tid 515] [client 127.0.0.1:39154] AH02221: Requesting connection re-negotiation ... [Thu Jul 16 12:10:48.107868 2015] [ssl:info] [pid 385024:tid 515] [client 127.0.0.1:39154] AH02226: Awaiting re-negotiation handshake [Thu Jul 16 12:10:48.108182 2015] [ssl:debug] [pid 385024:tid 515] ssl_engine_kernel.c(1936): [client 127.0.0.1:39154] AH02645: Server name not provided via TLS extension (using default/first virtual host) [Thu Jul 16 12:10:48.114668 2015] [ssl:debug] [pid 385024:tid 515] ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: TLSv1, Cipher: RC4-SHA (128/128 bits) [Thu Jul 16 12:10:48.114708 2015] [authz_core:debug] [pid 385024:tid 515] mod_authz_core.c(835): [client 127.0.0.1:39154] AH01628: authorization result: granted (no directives) My understanding: ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits) is more strict/secure than ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: TLSv1, Cipher: RC4-SHA (128/128 bits) (The cipher used in the test has been upgraded since, but still at 128 bits if I recall correctly). If I understand your comment " "Some of our tests demonstrate per-dir renegotiation for stricter SSL ciphers or client certs in specific contexts" This does not appear to me to be what is being tested now. I think the test need to start, somehow, at - let's say 128-bit- but goes to 256 bit when a different directory is requested. Bill More in general though - trying to think as OpenBSD might have been thinking re: "Stricter SSL ciphers than original" connection. I had the assumption (which is always dangerous) that default behavior of servers and clients was to negotiate the strictest combination that both supported. Key phrase: "assume default behavior". I do not memorize CVE numbers, or even text - but renegotiate DOWN has become popular to attempt to lessen (break) security - such as logjam - From https://access.redhat.com/articles/1456263 in which a man-in-the-middle attacker could downgrade vulnerable TLS connections to 512-bit export-grade cryptography. The attack affects any server that supports DHE_EXPORT ciphers. This attack can be conduted by pre-computation of the 512-bit primes given in two popular sets of weak Diffie-Hellman parameters, namely Apache's /httpd/ versions 2.1.5 to 2.4.7, and all versions of OpenSSL. From above quote it seems that this has already been addressed in 2.4.8 and later, and maybe even in the 2.2.31 - but it "feels" as if the LibreSSL approach (no renegotiate) cuts off a line of attack - and, properly configured - a client-server should always be connecting at the most secure cipher possible. Special situations: "Beliefs" - the server should always determine the minimum level of ciphers "acceptable", and the highest that
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 5:34 PM, Yann Ylavic wrote: On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt wrote: Here I can see: Much more simple: 8352 != 8532 - i.e., typo
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 5:34 PM, Yann Ylavic wrote: On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt wrote: On 2015-07-17 4:18 PM, Yann Ylavic wrote: $ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532 -state What else did you change in your configuration files - to get it to listen on port 8352? When I run the same commands I do not see any port activated (just a file added to netstat -tn output) and the client cannot connect. I used the port defined for the SSL VirtualHost in /path/to/httpd/framework/trunk/t/conf/ssl/ssl.conf (i.e. I ran httpd directly with the configuration files generated by the framework). That port may be determined the first time the tests are run though, so you probably have to look at this VirtualHost's definition in your environment... Here I can see: So, did you run /path/to/httpd -f `pwd`/t/conf/httpd.conf -X or /path/to/httpd -f `pwd`t/conf/ssl/ssl.conf -X I tried to follow your's literally (I thought).
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 4:18 PM, Yann Ylavic wrote: Thanks, I finally managed to build libressl on my system and httpd-2.4.x linked to it. However since this isn't the system's native libssl, the perl framework (libwww-perl/5.836 here) does not use it (but Debian's libssl-0.9.8o-4squeeze20), so I had to use libressl's "openssl s_client" to reproduce the case. So: $ /path/to/httpd/2.4.x/bin/httpd -f /path/to/httpd/framework/trunk/t/conf/httpd.conf -X on the server side, and: $ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532 -state on the client side, with this simple request: GET /require-aes128-cgi HTTP/1.1 Host: localhost:8532 What else did you change in your configuration files - to get it to listen on port 8352? When I run the same commands I do not see any port activated (just a file added to netstat -tn output) and the client cannot connect. root@x068:[/data/prj/apache/httpd/test]diff x1 x2 54a55,56 > f100060006979808 stream 0 0 f10001001919fc38 000 /data/prj/apache/httpd/test/t/logs/cgisock.495796 > f100060006943500 root@x068:[/data/prj/apache/httpd/test]/opt/bin/openssl s_client -connect localhost:8352 -state connect: Connection refused connect:errno=9
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 12:39 PM, Yann Ylavic wrote: But possibly "LogLevel trace5" in httpd.conf (or t/conf/ssl/ssl.conf.in 's VirtualHost) would be enough to see what's going on. Since the "error" (interruption) seems to be on the client side though, it may also be interesting to start httpd with a configuration like the framework's generated t/conf/ssl/ssl.conf file, and then use openssl s_client (or libressl s_client? dunno the name of that binary in libreSSL...) with -state and -debug to have the client's POV... (I see you just replied again Yann, so I'll just send this as "history") Not knowing much - how much of a hint is it that there are references to SSLv3 (aka TLSv1.0) while the initial connection is TLSv1.2? Do the SSL Library numbers indicate where to look? *[Fri Jul 17 14:44:19.946820 2015] [ssl:error] [pid 503958:tid 772] SSL Library Error: error:060C1064:digital envelope routines:AEAD_CHACHA20_POLY1305_OPEN:bad decrypt -- wrong pass phrase!? [Fri Jul 17 14:44:19.946873 2015] [ssl:error] [pid 503958:tid 772] SSL Library Error: error:**1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac * [Fri Jul 17 14:44:19.878583 2015] [ssl:trace3] [pid 503958:tid 772] ssl_engine_kernel.c(1810): [client 127.0.0.1:51835] OpenSSL: Loop: SSLv3 flush data [Fri Jul 17 14:44:19.878600 2015] [ssl:trace3] [pid 503958:tid 772] ssl_engine_kernel.c(1805): [client 127.0.0.1:51835] OpenSSL: Handshake: done [Fri Jul 17 14:44:19.878614 2015] [ssl:debug] [pid 503958:tid 772] ssl_engine_kernel.c(1854): [client 127.0.0.1:51835] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits) [Fri Jul 17 14:44:19.939060 2015] [ssl:trace4] [pid 503958:tid 772] ssl_engine_io.c(2050): [client 127.0.0.1:51835] OpenSSL: read 5/5 bytes from BIO#20085f68 [mem: 202967fb] (BIO dump follows) [Fri Jul 17 14:44:19.939080 2015] [ssl:trace4] [pid 503958:tid 772] ssl_engine_io.c(2050): [client 127.0.0.1:51835] OpenSSL: read 244/244 bytes from BIO#20085f68 [mem: 20296800] (BIO dump follows) [Fri Jul 17 14:44:19.939098 2015] [core:trace5] [pid 503958:tid 772] protocol.c(618): [client 127.0.0.1:51835] Request received from client: POST /require-aes256-cgi/perl_echo.pl HTTP/1.1 [Fri Jul 17 14:44:19.939147 2015] [ssl:debug] [pid 503958:tid 772] ssl_engine_kernel.c(244): [client 127.0.0.1:51835] AH02034: Initial (No.1) HTTPS request received for child 1 (server loopback:8532) [Fri Jul 17 14:44:19.939161 2015] [http:trace4] [pid 503958:tid 772] http_request.c(322): [client 127.0.0.1:51835] Headers received from client: [Fri Jul 17 14:44:19.939170 2015] [http:trace4] [pid 503958:tid 772] http_request.c(326): [client 127.0.0.1:51835] TE: deflate,gzip;q=0.3 [Fri Jul 17 14:44:19.939177 2015] [http:trace4] [pid 503958:tid 772] http_request.c(326): [client 127.0.0.1:51835] Connection: TE, close [Fri Jul 17 14:44:19.939185 2015] [http:trace4] [pid 503958:tid 772] http_request.c(326): [client 127.0.0.1:51835] Host: loopback:8532 [Fri Jul 17 14:44:19.939193 2015] [http:trace4] [pid 503958:tid 772] http_request.c(326): [client 127.0.0.1:51835] User-Agent: libwww-perl/6.13 [Fri Jul 17 14:44:19.939201 2015] [http:trace4] [pid 503958:tid 772] http_request.c(326): [client 127.0.0.1:51835] Content-Length: 11 [Fri Jul 17 14:44:19.939209 2015] [http:trace4] [pid 503958:tid 772] http_request.c(326): [client 127.0.0.1:51835] Content-Type: application/x-www-form-urlencoded [Fri Jul 17 14:44:19.939268 2015] [core:trace4] [pid 503958:tid 772] util_expr_eval.c(860): [client 127.0.0.1:51835] Evaluation of expression from /data/prj/apache/httpd/test/t/conf/extra.conf:924 gave: 0 [Fri Jul 17 14:44:19.939413 2015] [core:trace4] [pid 503958:tid 772] util_expr_eval.c(860): [client 127.0.0.1:51835] Evaluation of expression from /data/prj/apache/httpd/test/t/conf/extra.conf:924 gave: 0 [Fri Jul 17 14:44:19.939471 2015] [ssl:debug] [pid 503958:tid 772] ssl_engine_kernel.c(511): [client 127.0.0.1:51835] AH02220: Reconfigured cipher suite will force renegotiation [Fri Jul 17 14:44:19.939482 2015] [ssl:trace4] [pid 503958:tid 772] ssl_engine_io.c(1692): [client 127.0.0.1:51835] filling buffer, max size 131072 bytes [Fri Jul 17 14:44:19.939503 2015] [ssl:trace4] [pid 503958:tid 772] ssl_engine_io.c(1745): [client 127.0.0.1:51835] total of 11 bytes in buffer, eos=1 [Fri Jul 17 14:44:19.939514 2015] [ssl:info] [pid 503958:tid 772] [client 127.0.0.1:51835] AH02221: Requesting connection re-negotiation [Fri Jul 17 14:44:19.939528 2015] [ssl:trace4] [pid 503958:tid 772] ssl_engine_io.c(2059): [client 127.0.0.1:51835] OpenSSL: I/O error, 5 bytes expected to read on BIO#20085f68 [mem: 202967fb] [Fri Jul 17 14:44:19.939543 2015] [ssl:debug] [pid 503958:tid 772] ssl_engine_kernel.c(802): [client 127.0.0.1:51835] AH02260: Performing full renegotiation: complete handshake protocol (client does support secure renegotiation) [Fri Jul 17 14:44:19.939556 2015] [ssl:trace3] [pid 503958:tid 772] ssl_eng
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 4:18 PM, Yann Ylavic wrote: On Fri, Jul 17, 2015 at 1:51 PM, Michael Felt wrote: On 2015-07-17 1:20 PM, Michael Felt wrote: On 2015-07-17 12:39 PM, Yann Ylavic wrote: tcpdump -i lo -w dump.pcap -s0 tcp port 8532 Run at a different time, but with trace5 enabled. Thanks, I finally managed to build libressl on my system and httpd-2.4.x linked to it. However since this isn't the system's native libssl, the perl framework (libwww-perl/5.836 here) does not use it (but Debian's libssl-0.9.8o-4squeeze20), so I had to use libressl's "openssl s_client" to reproduce the case. I installed a virgin system without OpenSSL, installed LibreSSL and then installed Bundle::ApacheTest - which loaded (compiled against libressl) the SSL related modules into perl on AIX. I repeated the same steps on a second AIX - installing only OpenSSL and then installing Bundle::ApacheTest I will try and repeat what you did as well. So: $ /path/to/httpd/2.4.x/bin/httpd -f /path/to/httpd/framework/trunk/t/conf/httpd.conf -X on the server side, and: $ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532 -state on the client side, with this simple request: GET /require-aes128-cgi HTTP/1.1 Host: localhost:8532 Attached are the logs from both httpd and s_client, where we can see that httpd somehow expects a client certificate during the renegotiation (without sending any certificate request...), while s_client obviously does not send anything like that (but its key exchange). I can't explain that... I'd need to debug. Does this ring someone's bell?
Re: Apache-Test pre-requisites
On 2015-06-13 12:26 PM, Rainer Jung wrote: Am 13.06.2015 um 12:23 schrieb Rainer Jung: Hi Michael, Am 13.06.2015 um 12:10 schrieb Michael Felt: Just a link to the "Howto setup Apache::Test" would be sufficient. The README in the project sends me to mod_perl info, not a list of perl mods needed to be added -- and unfortunately the Apache::Test does not "include" a dependency list either - or CPAN could do this all automatically. Try cpan command install Bundle::ApacheTest Here you had provided the answer that had been starting at me in the README file. Not being an avid perl programmer it did not ring a bell right away. perhaps add HTTP::DAV There are still some tests that get skipped, e.g. t/apache/pr17629.t .. skipped: cannot find module 'deflate', cannot find module 'case_filter' is deflate and/or case_filter: IO::Compress::Deflate (P/PM/PMQS/IO-Compress-2.068.tar.gz)? or Compress::Deflate7 (B/BJ/BJOERN/Compress-Deflate7-1.0.tar.gz) or ??? although... cpan> install IO::Compress::Deflate IO::Compress::Deflate is up to date. so, using i/deflate/ is not helping me (enough). to install prerequisites. See also http://search.cpan.org/~shay/Apache-Test-1.39/lib/Bundle/ApacheTest.pm There's some more info in the README file you can find after checking out http://svn.apache.org/repos/asf/httpd/test/framework/trunk/ or browsing via http://svn.apache.org/viewvc/httpd/test/framework/trunk/ Regards, Rainer
Re: test base line
On 2015-07-09 1:46 PM, Stefan Eissing wrote: I need some help with establishing a test baseline. I checked out the test framework from https://svn.apache.org/repos/asf/httpd/test/framework/trunk, followed the README and ran the tests against a freshly installed 2.4.x in /opt/httpd/2.4-plain. It did PASS with the default httpd.conf, but many tests were skipped due to modules missing. I tried enable some more modules like mod_ssl or mod_rewrite and all of these attempts led to test failures and perl errors such as "t/security/CVE-2011-3368-rewrite.t .. 1/3 # Failed test 1 in t/security/CVE-2011-3368-rewrite.t at line 13 Can't call method "print" on an undefined value at t/security/CVE-2011-3368-rewrite.t line 19. " My perl is the default Ubuntu 14.04 perl 5.18. What I have done - using a MUCH older version of perl is the following: # perl -MCPAN -e shell And once configured to get sources, install Bundle::ApacheTest You may run into other issues you need to resolve before the Bundle installs successfully. Hope this helps! Is this a failure on my part or is the system supposed to operate like this? I am a bit confused... Thanks for the help, Stefan bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 1:20 PM, Michael Felt wrote: On 2015-07-17 12:39 PM, Yann Ylavic wrote: tcpdump -i lo -w dump.pcap -s0 tcp port 8532 Run at a different time, but with trace5 enabled. logs.pr12355.libressl.trace5.tar.bz2 Description: Binary data
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 12:39 PM, Yann Ylavic wrote: tcpdump -i lo -w dump.pcap -s0 tcp port 8532 dump.pcap Description: Binary data
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 12:39 PM, Yann Ylavic wrote: Michael Felt wrote: Yann Ylavic wrote: So if RC4 was the culprit, the tests (pr12355 and pr43738) should pass now. I'll pull ApacheTest and check. p.s. I have built 2.4.16 now - and did not have to change anything for it to build against LibreSSL (very small ifdefs were needed with 2.4.12). And the summary of ApacheTest is now: Test Summary Report --- t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 8) Failed tests: 1-8 t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 4) Failed tests: 1-4 t/ssl/proxy.t (Wstat: 0 Tests: 172 Failed: 59) Failed tests: 114-172 t/ssl/varlookup.t (Wstat: 0 Tests: 73 Failed: 4) Failed tests: 39-40, 53-54 Files=110, Tests=4843, 378 wallclock secs ( 3.44 usr 0.47 sys + 98.64 cusr 74.60 csys = 177.15 CPU) Would you prefer a different test (rather than pr12355.t - that was just first in the list)?
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
Michael Felt wrote:
Yann Ylavic wrote:
So if RC4 was the culprit, the tests (pr12355 and pr43738) should pass
now.
I'll pull ApacheTest and check.
I assume the attached logs_pr12355_LibreSSL.zip was with the latest
framework (including r1691419), so the RC4 => AES changes did not
work...
Yes, that was with the latest framework (svn checkout) - as I showed in
the ciphers list - it is still there.
so if I look through the VirtualHost definitions made by ApacheTest I should
see some "Location CipherSuite" declarations?
Yes, t/conf/ssl/ssl.conf.in has a VirtualHost SSLCipherSuite
"ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL" which is
overridden for somes (/require-aes{128,256}-cgi and
/modules/ssl/aes{128,256}/) with SSLCipherSuite "AES{128,256}-SHA".
[Thu Jul 16 11:47:12.052157 2015] [ssl:info] [pid 389322:tid 772]
SSL Library Error: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected
message
That's not an alert (a close?).
Maybe a higher LogLevel (trace5?) would help, and/or a pcap...
So, an attachment again, with both binary and text of iptrace during run of
test pr12355. I guess (rather hope) you can read what is going on here.
Ouch, quite hard to read TLS in the matrix :)
Maybe "tcpdump -i lo -w dump.pcap -s0 tcp port 8532"?
(dump.pcap would then be readable in wireshark).
I would expect wireshark can also read iptrace date (the .iptrc file in
the bz2 attachment)
But possibly "LogLevel trace5" in httpd.conf (or
t/conf/ssl/ssl.conf.in 's VirtualHost) would be enough to see what's
going on.
Easiest for testing to just set it in /etc/httpd/httpd.conf and run make
test again. This server is only for testing anyway.
Since the "error" (interruption) seems to be on the client side
though, it may also be interesting to start httpd with a configuration
like the framework's generated t/conf/ssl/ssl.conf file, and then use
openssl s_client (or libressl s_client? dunno the name of that binary
in libreSSL...) with -state and -debug to have the client's POV...
libressl is the name of the package. the commands, etc. are the same.
So, if you can be more explicit about what you are thinking/needing I
shall comply.
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
On 2015-07-16 11:48 PM, Yann Ylavic wrote:
On Thu, Jul 16, 2015 at 7:02 PM, Michael Felt wrote:
A longish read - basically while 2.4.12 had few errors when built against
OpenSSL 0.9.8 LibreSSL has quite a few errors - perhaps because it has
removed many "unsafe" crypto combinations. The root question is: is this
LibreSSL misbehaving, or are the tests needing some work to verify that
"weak ciphers and key exchanges are not being used - e.g., via
renegotiation.
Latest commit on test framework ([1]) replaced RC4-{MD5,SHA} with
AES{128,256}-SHA so that these are more likely to be known by both
libs (unless LibreSSL also disabled all CBC based chainings).
So if RC4 was the culprit, the tests (pr12355 and pr43738) should pass now.
I'll pull ApacheTest and check.
BTW that's not what triggers the renegotiations since keep-alive seems
not be used for successive requests (that possibly could be another
test, though logs show Initial connections only here), but rather a
specific Location's CipherSuite different from the (handshaken)
VirtualHost's one.
so if I look through the VirtualHost definitions made by ApacheTest I
should see some "Location CipherSuite" declarations?
One test in LibreSSL (first one) from test:
[...]
[Thu Jul 16 11:47:11.864018 2015] [ssl:debug] [pid 389322:tid 772]
ssl_engine_kernel.c(1908): [client 127.0.0.1:48673] AH02043: SSL virtual host
for servername loopback found
[Thu Jul 16 11:47:11.982116 2015] [ssl:debug] [pid 389322:tid 772]
ssl_engine_kernel.c(1841): [client 127.0.0.1:48673] AH02041: Protocol:
TLSv1.2, Cipher: ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
Is the framework using openssl or libressl here?
Are PATH or APACHE_TEST_OPENSSL_CMD defined, or maybe the system's default lib?
As it is TLSv1.2 - that is LibreSSL. I'll generate a list of the ciphers
it supports asap.
[Thu Jul 16 11:47:12.051994 2015] [ssl:error] [pid 389322:tid 772]
[client 127.0.0.1:48673] AH02261: Re-negotiation handshake failed: Not
accepted by client!?
[Thu Jul 16 11:47:12.052072 2015] [ssl:info] [pid 389322:tid 772]
[client 127.0.0.1:48673] AH02008: SSL library error 1 in handshake (server
loopback:8532)
[Thu Jul 16 11:47:12.052157 2015] [ssl:info] [pid 389322:tid 772]
SSL Library Error: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected
message
I had cut out all the debug statements - (grep -v debug
t/logs/error_log) - for me too much noise.
I'll see about pcap/tcpdump (AIX program name is either tcpdump
(standard *NIX interface) or iptrace
That's not an alert (a close?).
Maybe a higher LogLevel (trace5?) would help, and/or a pcap...
Regards,
Yann.
[1] http://svn.apache.org/r1691419
Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
I'll look at it and hopefully understand something. but tomorrow. On Thu, Jul 16, 2015 at 7:56 PM, William A Rowe Jr wrote: > On Thu, Jul 16, 2015 at 12:02 PM, Michael Felt wrote: > >> Here I have the output of just one test t/ssl/pr12355.t - and note the >> differences in the ssl_access_log - not just the error messages (I have >> removed all "debug" messages from the logs as they were "in the way". >> >> LibreSSL is version 2.2.0, OpenSSL is version 0.9.8m (yes I know very old, >> will test with latest patches later - I hope not relevant to here). >> >> So, please note: LibreSSL says access is: >> t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST >> /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 >> while OpenSSL says >> t/logs/ssl_request_log:[16/Jul/2015:11:32:35 +] 127.0.0.1 TLSv1 RC4-SHA >> "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 200 11 >> >> My question: what can I do to understand why OpenSSL is adding TLSv1 >> RC4-SHA while LibreSSL is "- -" >> >> > I'll take this one item. Take a look into our implementation of > ssl_var_lookup_ssl > and particularly ssl_var_lookup_ssl_cipher. I would expect LibreSSL isn't > providing > any meaningful data to represent. > > >
Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
Moving this to a thread with a better title! A longish read - basically while 2.4.12 had few errors when built against OpenSSL 0.9.8 LibreSSL has quite a few errors - perhaps because it has removed many "unsafe" crypto combinations. The root question is: is this LibreSSL misbehaving, or are the tests needing some work to verify that "weak ciphers and key exchanges are not being used - e.g., via renegotiation. +++ I wish to recall a pleasant get together last April in Texas just before ApacheCon. At that time I mentioned LibreSSL and building httpd against it (actually mod_ssl is all it amounts to). The build itself was quite simple - I shall repeat that now for 2.4.16 and trunk - and send the 'patch' in. While build is simple - understanding the differences in test output is daunting. Here I have the output of just one test t/ssl/pr12355.t - and note the differences in the ssl_access_log - not just the error messages (I have removed all "debug" messages from the logs as they were "in the way". LibreSSL is version 2.2.0, OpenSSL is version 0.9.8m (yes I know very old, will test with latest patches later - I hope not relevant to here). So, please note: LibreSSL says access is: t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 while OpenSSL says t/logs/ssl_request_log:[16/Jul/2015:11:32:35 +] 127.0.0.1 TLSv1 RC4-SHA "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 200 11 My question: what can I do to understand why OpenSSL is adding TLSv1 RC4-SHA while LibreSSL is "- -" Note also in the ==> LibreSSL_pr12355.t.results<== t/logs/error_log:[Thu Jul 16 11:47:12.425257 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH01964: Connection to child 0 established (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:47:12.613855 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02221: Requesting connection re-negotiation t/logs/error_log:[Thu Jul 16 11:47:12.614004 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:47:12.620757 2015] [ssl:error] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02261: Re-negotiation handshake failed: Not accepted by client!? t/logs/error_log:[Thu Jul 16 11:47:12.620803 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02008: SSL library error 1 in handshake (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:47:12.620825 2015] [ssl:info] [pid 389322:tid 515] SSL Library Error: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message t/logs/error_log:[Thu Jul 16 11:47:12.620837 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH01998: Connection closed to child 0 with abortive shutdown (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:47:17.073812 2015] [core:warn] [pid 344086:tid 1] AH00045: child process 389322 still did not exit, sending a SIGTERM t/logs/error_log:[Thu Jul 16 11:47:19.076308 2015] [core:info] [pid 344086:tid 1] AH00096: removed PID file /data/prj/apache/httpd/test/t/logs/httpd.pid (pid=344086) t/logs/error_log:[Thu Jul 16 11:47:19.076349 2015] [mpm_worker:notice] [pid 344086:tid 1] AH00295: caught SIGTERM, shutting down t/logs/ssl_request_log:[16/Jul/2015:11:47:10 +] 127.0.0.1 - - "GET /index.html HTTP/1.1" 200 26 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-md5-cgi/perl_echo.pl HTTP/1.1" 403 237 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-md5-cgi/perl_echo.pl HTTP/1.1" 403 237 ==> OpenSSL_pr12355.t.results<== t/logs/error_log:[Thu Jul 16 11:32:35.380665 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39151] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:32:35.423630 2015] [ssl:info] [pid 417826:tid 772] [client 127.0.0.1:39152] AH01964: Connection to child 1 established (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:32:35.571262 2015] [ssl:info] [pid 417826:tid 772] [client 127.0.0.1:39152] AH02221: Requesting connection re-negotiation t/logs/error_log:[Thu Jul 16 11:32:35.571354 2015] [ssl:info] [pid 417826:tid 772] [client 127.0.0.1:39152] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:32:35.613858 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39153] AH01964: Connection to child 0 established (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:32:35.771440 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39153] AH02221: Requesting connection re-negotiation t/logs/error_log:[Thu Jul 16 11:32:35.771533 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39153] AH02226: Awaiting re-negotiation handshake t/logs/erro
Re: The show goes on - 2.4.16
Nothing serious of course - AND the advantage is that I do not have to do a new build to switch to pre-fork (which was the old way iirc). So - was I the first to find a bug in the new release :P btw - I am much more interested in the ssl tests and whether it is a failed test (going back to MC4 128-bit) when the initial connection was much better. I assume this is not logjam (or some other horrible recent OpenSSL TLS renegotiate CVE) - but it is something we want to prevent (as far as I know LibreSSL has no support for RC4 as it is too weak - hence these will fail by definition if the test (client) is forcing a renegotiate to that level of cryptography (key exchange?). In other words - think more about my other post please! On Thu, Jul 16, 2015 at 5:26 PM, Yann Ylavic wrote: > Yes, and with --enable-load-all-modules (not so common, I think, when > not testing with the framework...). > > On Thu, Jul 16, 2015 at 5:19 PM, Jim Jagielski wrote: > > Yeah... gr. > > > > In any case, this would affect only those w/ virgin builds, right? > > > >> On Jul 16, 2015, at 11:01 AM, Yann Ylavic wrote: > >> > >> On Thu, Jul 16, 2015 at 4:41 PM, Michael Felt > wrote: > >>> My comment is that with 2.4.12 the same configure did not do this. > This is > >>> new behavior. > >> > >> Probably a consequence of [1] which may not play very well with > >> --enable-load-all-modules. > >> > >> [1] http://svn.apache.org/r1661848 > > >
Re: Congradulations on the new release(s)
I really should have titled this differently - sigh! On Thu, Jul 16, 2015 at 2:20 PM, Michael Felt wrote: > I am a bit behind - yet looking forward. > > I wish to recall a pleasant get together last April in Texas just before > ApacheCon. At that time I mentioned LibreSSL and building httpd against it > (actually mod_ssl is all it amounts to). > > The build itself was quite simple - I shall repeat that now for 2.4.16 and > trunk - and send the 'patch' in. > > While build is simple - understanding the differences in test output is > daunting. > > Here I have the output of just one test t/ssl/pr12355.t - and note the > differences in the ssl_access_log - not just the error messages (I have > removed all "debug" messages from the logs as they were "in the way". > > LibreSSL is version 2.2.0, OpenSSL is version 0.9.8m (yes I know very old, > will test with latest patches later - I hope not relevant to here). > > So, please note: LibreSSL says access is: > t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST > /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 > while OpenSSL says > t/logs/ssl_request_log:[16/Jul/2015:11:32:35 +] 127.0.0.1 TLSv1 > RC4-SHA "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 200 11 > > My question: what can I do to understand why OpenSSL is adding TLSv1 > RC4-SHA while LibreSSL is "- -" > > Note also in the > > ==> LibreSSL_pr12355.t.results <== > t/logs/error_log:[Thu Jul 16 11:47:12.425257 2015] [ssl:info] [pid > 389322:tid 515] [client 127.0.0.1:48676] AH01964: Connection to child 0 > established (server loopback:8532) > t/logs/error_log:[Thu Jul 16 11:47:12.613855 2015] [ssl:info] [pid > 389322:tid 515] [client 127.0.0.1:48676] AH02221: Requesting connection > re-negotiation > t/logs/error_log:[Thu Jul 16 11:47:12.614004 2015] [ssl:info] [pid > 389322:tid 515] [client 127.0.0.1:48676] AH02226: Awaiting re-negotiation > handshake > t/logs/error_log:[Thu Jul 16 11:47:12.620757 2015] [ssl:error] [pid > 389322:tid 515] [client 127.0.0.1:48676] AH02261: Re-negotiation > handshake failed: Not accepted by client!? > t/logs/error_log:[Thu Jul 16 11:47:12.620803 2015] [ssl:info] [pid > 389322:tid 515] [client 127.0.0.1:48676] AH02008: SSL library error 1 in > handshake (server loopback:8532) > t/logs/error_log:[Thu Jul 16 11:47:12.620825 2015] [ssl:info] [pid > 389322:tid 515] SSL Library Error: error:1408E0F4:SSL > routines:SSL3_GET_MESSAGE:unexpected message > t/logs/error_log:[Thu Jul 16 11:47:12.620837 2015] [ssl:info] [pid > 389322:tid 515] [client 127.0.0.1:48676] AH01998: Connection closed to > child 0 with abortive shutdown (server loopback:8532) > t/logs/error_log:[Thu Jul 16 11:47:17.073812 2015] [core:warn] [pid > 344086:tid 1] AH00045: child process 389322 still did not exit, sending a > SIGTERM > t/logs/error_log:[Thu Jul 16 11:47:19.076308 2015] [core:info] [pid > 344086:tid 1] AH00096: removed PID file > /data/prj/apache/httpd/test/t/logs/httpd.pid (pid=344086) > t/logs/error_log:[Thu Jul 16 11:47:19.076349 2015] [mpm_worker:notice] > [pid 344086:tid 1] AH00295: caught SIGTERM, shutting down > t/logs/ssl_request_log:[16/Jul/2015:11:47:10 +] 127.0.0.1 - - "GET > /index.html HTTP/1.1" 200 26 > t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST > /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 > t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST > /require-md5-cgi/perl_echo.pl HTTP/1.1" 403 237 > t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST > /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 > t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST > /require-md5-cgi/perl_echo.pl HTTP/1.1" 403 237 > > ==> OpenSSL_pr12355.t.results <== > t/logs/error_log:[Thu Jul 16 11:32:35.380665 2015] [ssl:info] [pid > 417826:tid 515] [client 127.0.0.1:39151] AH02226: Awaiting re-negotiation > handshake > t/logs/error_log:[Thu Jul 16 11:32:35.423630 2015] [ssl:info] [pid > 417826:tid 772] [client 127.0.0.1:39152] AH01964: Connection to child 1 > established (server loopback:8532) > t/logs/error_log:[Thu Jul 16 11:32:35.571262 2015] [ssl:info] [pid > 417826:tid 772] [client 127.0.0.1:39152] AH02221: Requesting connection > re-negotiation > t/logs/error_log:[Thu Jul 16 11:32:35.571354 2015] [ssl:info] [pid > 417826:tid 772] [client 127.0.0.1:39152] AH02226: Awaiting re-negotiation > handshake > t/logs/error_log:[Thu Jul 16 11:32:35.613858 2015] [ssl:info] [pid > 417826:tid 515] [client 127.0.0.1:39153] AH01964: Connection to child 0 > established (server loopback:8532) > t/logs/error_log:[Thu Jul 16 11:32
Re: The show goes on - 2.4.16
My comment is that with 2.4.12 the same configure did not do this. This is new behavior. I was testing with 2.4.12 all day yesterday, using the same build scripts today with 2.4.16 came up differently. So now, after the build I have this difference in httpd.conf root@x065:[/data/prj/apache/httpd]diff -u */x/etc/httpd/httpd.conf --- httpd-2.4.12/x/etc/httpd/httpd.conf 2015-07-16 09:48:20 + +++ httpd-2.4.16/x/etc/httpd/httpd.conf 2015-07-16 12:31:25 + @@ -143,6 +143,7 @@ LoadModule lbmethod_bytraffic_module libexec/mod_lbmethod_bytraffic.so LoadModule lbmethod_bybusyness_module libexec/mod_lbmethod_bybusyness.so LoadModule lbmethod_heartbeat_module libexec/mod_lbmethod_heartbeat.so +LoadModule mpm_prefork_module libexec/mod_mpm_prefork.so LoadModule mpm_worker_module libexec/mod_mpm_worker.so LoadModule unixd_module libexec/mod_unixd.so LoadModule heartbeat_module libexec/mod_heartbeat.so On Thu, Jul 16, 2015 at 4:03 PM, William A Rowe Jr wrote: > On Jul 16, 2015 8:04 AM, "Michael Felt" wrote: > > > > First little thing I ran into - that I did not have with 2.4.12 is this: > > > > root@x065:[/data/prj/apache/httpd/test]/opt/httpd/sbin/apachectl start > > AH00534: httpd: Configuration error: More than one MPM loaded. > > > root@x065:[/data/prj/apache/httpd/test]grep -i mpm /etc/httpd/httpd.conf > > LoadModule mpm_prefork_module libexec/mod_mpm_prefork.so > > LoadModule mpm_worker_module libexec/mod_mpm_worker.so > > # Server-pool management (MPM specific) > > #Include /etc/httpd/extra/httpd-mpm.conf > > > > p.s. I had done configure with: > > > > $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config > --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all > --enable-mods-shared=all --disable-lua --enable-load-all-modules > --enable-maintainer-mode --with-ssl > > Looks correct... > > --enable-mpms-shared=all > Worked as instructed... > > --enable-load-all-modules > Did just as you asked. > > Not sure offhand if we can hack some mpm-specific module exception to the > later. >
Re: The show goes on - 2.4.16
I do not know why both are there - something to do with the "configure" statement perhaps. As I said above - not had this show up before. In any case, just finished ApacheTest and is looking very good. All tests successful. Files=110, Tests=4843, 364 wallclock secs ( 3.38 usr 0.50 sys + 88.88 cusr 74.02 csys = 166.78 CPU) Result: PASS [warning] server loopback:8529 shutdown [warning] port 8529 still in use... ..done On Thu, Jul 16, 2015 at 3:10 PM, Reindl Harald wrote: > > Am 16.07.2015 um 15:03 schrieb Michael Felt: > >> First little thing I ran into - that I did not have with 2.4.12 is this: >> >> root@x065:[/data/prj/apache/httpd/test]/opt/httpd/sbin/apachectl start >> AH00534: httpd: Configuration error: More than one MPM loaded. >> >> Granted, I should perhaps change to pre-fork (I noticed some had only >> tested that) - but I had 'adopted' MPM when 2.4.0 first came out. >> > > no, you jsut should not load *both* > > root@x065:[/data/prj/apache/httpd/test]grep -i mpm /etc/httpd/httpd.conf >> LoadModule mpm_prefork_module libexec/mod_mpm_prefork.so >> LoadModule mpm_worker_module libexec/mod_mpm_worker.so >> > > why are both there? > >
The show goes on - 2.4.16
First little thing I ran into - that I did not have with 2.4.12 is this: root@x065:[/data/prj/apache/httpd/test]/opt/httpd/sbin/apachectl start AH00534: httpd: Configuration error: More than one MPM loaded. Granted, I should perhaps change to pre-fork (I noticed some had only tested that) - but I had 'adopted' MPM when 2.4.0 first came out. root@x065:[/data/prj/apache/httpd/test]grep -i mpm /etc/httpd/httpd.conf LoadModule mpm_prefork_module libexec/mod_mpm_prefork.so LoadModule mpm_worker_module libexec/mod_mpm_worker.so # Server-pool management (MPM specific) #Include /etc/httpd/extra/httpd-mpm.conf p.s. I had done configure with: $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all --enable-mods-shared=all --disable-lua --enable-load-all-modules --enable-maintainer-mode --with-ssl
Re: Release annoucements missing on annou...@httpd.apache.org
Should have thought of that earlier :p @ me. On Thu, Jul 16, 2015 at 2:34 PM, Jim Jagielski wrote: > refresh your browser cache. :) > > > On Jul 16, 2015, at 8:22 AM, Michael Felt wrote: > > > > Also, the home page still says 2.4.12 and 2.2.29 - but the Download page > is up to date... > > > > On Thu, Jul 16, 2015 at 1:47 PM, Jim Jagielski wrote: > > Oops. Sorry. > > > On Jul 15, 2015, at 5:03 PM, Bostjan Skufca wrote: > > > > > > Hi all, > > > > > > since 2.4.10 and 2.2.29 the annou...@httpd.apache.org is abandoned. > Is this intentional? > > > > > > Someone already asked about this last year: > > > http://marc.info/?l=apache-httpd-dev&m=141157921203967&w=2 > > > > > > If this is not the right list to ask this question, where should it be > addressed then? > > > > > > b. > > > > > > PS: Congrats for finally successful 2.4.16 release :) > > > > > > > > >
Re: Release annoucements missing on annou...@httpd.apache.org
Also, the home page still says 2.4.12 and 2.2.29 - but the Download page is up to date... On Thu, Jul 16, 2015 at 1:47 PM, Jim Jagielski wrote: > Oops. Sorry. > > On Jul 15, 2015, at 5:03 PM, Bostjan Skufca wrote: > > > > Hi all, > > > > since 2.4.10 and 2.2.29 the annou...@httpd.apache.org is abandoned. Is > this intentional? > > > > Someone already asked about this last year: > > http://marc.info/?l=apache-httpd-dev&m=141157921203967&w=2 > > > > If this is not the right list to ask this question, where should it be > addressed then? > > > > b. > > > > PS: Congrats for finally successful 2.4.16 release :) > > > >
Congradulations on the new release(s)
I am a bit behind - yet looking forward. I wish to recall a pleasant get together last April in Texas just before ApacheCon. At that time I mentioned LibreSSL and building httpd against it (actually mod_ssl is all it amounts to). The build itself was quite simple - I shall repeat that now for 2.4.16 and trunk - and send the 'patch' in. While build is simple - understanding the differences in test output is daunting. Here I have the output of just one test t/ssl/pr12355.t - and note the differences in the ssl_access_log - not just the error messages (I have removed all "debug" messages from the logs as they were "in the way". LibreSSL is version 2.2.0, OpenSSL is version 0.9.8m (yes I know very old, will test with latest patches later - I hope not relevant to here). So, please note: LibreSSL says access is: t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 while OpenSSL says t/logs/ssl_request_log:[16/Jul/2015:11:32:35 +] 127.0.0.1 TLSv1 RC4-SHA "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 200 11 My question: what can I do to understand why OpenSSL is adding TLSv1 RC4-SHA while LibreSSL is "- -" Note also in the ==> LibreSSL_pr12355.t.results <== t/logs/error_log:[Thu Jul 16 11:47:12.425257 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH01964: Connection to child 0 established (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:47:12.613855 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02221: Requesting connection re-negotiation t/logs/error_log:[Thu Jul 16 11:47:12.614004 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:47:12.620757 2015] [ssl:error] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02261: Re-negotiation handshake failed: Not accepted by client!? t/logs/error_log:[Thu Jul 16 11:47:12.620803 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH02008: SSL library error 1 in handshake (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:47:12.620825 2015] [ssl:info] [pid 389322:tid 515] SSL Library Error: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message t/logs/error_log:[Thu Jul 16 11:47:12.620837 2015] [ssl:info] [pid 389322:tid 515] [client 127.0.0.1:48676] AH01998: Connection closed to child 0 with abortive shutdown (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:47:17.073812 2015] [core:warn] [pid 344086:tid 1] AH00045: child process 389322 still did not exit, sending a SIGTERM t/logs/error_log:[Thu Jul 16 11:47:19.076308 2015] [core:info] [pid 344086:tid 1] AH00096: removed PID file /data/prj/apache/httpd/test/t/logs/httpd.pid (pid=344086) t/logs/error_log:[Thu Jul 16 11:47:19.076349 2015] [mpm_worker:notice] [pid 344086:tid 1] AH00295: caught SIGTERM, shutting down t/logs/ssl_request_log:[16/Jul/2015:11:47:10 +] 127.0.0.1 - - "GET /index.html HTTP/1.1" 200 26 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-md5-cgi/perl_echo.pl HTTP/1.1" 403 237 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237 t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST /require-md5-cgi/perl_echo.pl HTTP/1.1" 403 237 ==> OpenSSL_pr12355.t.results <== t/logs/error_log:[Thu Jul 16 11:32:35.380665 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39151] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:32:35.423630 2015] [ssl:info] [pid 417826:tid 772] [client 127.0.0.1:39152] AH01964: Connection to child 1 established (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:32:35.571262 2015] [ssl:info] [pid 417826:tid 772] [client 127.0.0.1:39152] AH02221: Requesting connection re-negotiation t/logs/error_log:[Thu Jul 16 11:32:35.571354 2015] [ssl:info] [pid 417826:tid 772] [client 127.0.0.1:39152] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:32:35.613858 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39153] AH01964: Connection to child 0 established (server loopback:8532) t/logs/error_log:[Thu Jul 16 11:32:35.771440 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39153] AH02221: Requesting connection re-negotiation t/logs/error_log:[Thu Jul 16 11:32:35.771533 2015] [ssl:info] [pid 417826:tid 515] [client 127.0.0.1:39153] AH02226: Awaiting re-negotiation handshake t/logs/error_log:[Thu Jul 16 11:32:40.284682 2015] [core:warn] [pid 385024:tid 1] AH00045: child process 417826 still did not exit, sending a SIGTERM t/logs/error_log:[Thu Jul 16 11:32:42.287551 2015] [core:info] [pid 385024:tid 1] AH00096: removed PID file /data/prj/apache/httpd/test/t/logs/httpd.pid (pid=385024) t/logs/error_log:[Thu Jul 16 11:32:42.287591 2015] [mpm_worker:notice] [pid 3850
[PATCH 57044] Use base64url in UNIQUE_ID
Hi, in bug 57044, I proposed to use base64url for UNIQUE_ID. This means that the character '_' shall be used instead of '@', because '@' is not URL-safe. '_' is, and it may be used without percent-encoding in URLs, HTTP headers, or cookie values. What do you think? Does anyone dare to commit the proposed patch (in trunk only) ? Regards, Michael
Re: LimitRequestBody is broken in 2.4.13-2.4.15
Thanks for reporting this before the testing/release. Fixed in r1688274 (will now propose a backport), and since this is a showstopper, it will be merged (once reviewed) before 2.4.16/2.2.30. Proposed patch (for backport) is http://people.apache.org/~ylavic/httpd-2.4.x-fix_LimitRequestBody.patch Thanks (again) for testing if that's possible. I have tested the patch, it works :-) Thank you very much! Regards, Michael
LimitRequestBody is broken in 2.4.13-2.4.15
Hi, LimitRequestBody is broken in the (unreleased) Apache versions 2.4.13-2.4.15 because of this change: http://svn.apache.org/r1684515 In http_filters.c, ap_http_filter(): The variable "totalread" is uninitialized if readbytes is 0. Messages similar to this one are logged: "AH01591: Read content-length of 140067070814864 is larger than the configured limit of 104857600", and then Apache closes the connection. I hope that it's possible to fix this for Apache 2.4.16. Regards, Michael
Re: Apache-Test pre-requisites
Just a link to the "Howto setup Apache::Test" would be sufficient. The README in the project sends me to mod_perl info, not a list of perl mods needed to be added -- and unfortunately the Apache::Test does not "include" a dependency list either - or CPAN could do this all automatically. On Tue, Jun 9, 2015 at 9:55 PM, Michael Felt wrote: > My apologies for asking - but I am sure there are extra perl mods that > need to be installed before Apache-Test will operate as expected. > > Unfortunately, it does not seem to demand them, and I have forgotten the > extra mods I loaded to get 100's of tests compared to the 13 I am getting > now. > > I had hoped CPAN would tell me, but unfortunately, no. > > cpan> install Apache::Test > CPAN: Storable loaded ok > Fetching with LWP: > ftp://download.xs4all.nl/pub/mirror/CPAN/authors/01mailrc.txt.gz > Going to read /var/perl/.cpan/sources/authors/01mailrc.txt.gz > Fetching with LWP: > > ftp://download.xs4all.nl/pub/mirror/CPAN/modules/02packages.details.txt.gz > Going to read /var/perl/.cpan/sources/modules/02packages.details.txt.gz > Database was generated on Tue, 09 Jun 2015 17:17:02 GMT > > There's a new CPAN.pm version (v2.10) available! > [Current version is v1.7601] > You might want to try > install Bundle::CPAN > reload cpan > without quitting the current session. It should be a seamless upgrade > while we are running... > > Fetching with LWP: > ftp://download.xs4all.nl/pub/mirror/CPAN/modules/03modlist.data.gz > Going to read /var/perl/.cpan/sources/modules/03modlist.data.gz > Going to write /var/perl/.cpan/Metadata > Apache::Test is up to date. > > Reminders are welcome! > > Michael > > Tests are ending with: > Failed 2/13 test scripts, 84.62% okay. 7/43 subtests failed, 83.72% okay. > > whereas before I was gettign numbers such as: > > Failed 18/109 test programs. 247/4555 subtests failed. > > And I have also had all test successful... But do not have those saved. > > Mainly I am looking at 2/13 and 7/43 compared to 18/109 and 247/4555 > >
Apache-Test pre-requisites
My apologies for asking - but I am sure there are extra perl mods that need to be installed before Apache-Test will operate as expected. Unfortunately, it does not seem to demand them, and I have forgotten the extra mods I loaded to get 100's of tests compared to the 13 I am getting now. I had hoped CPAN would tell me, but unfortunately, no. cpan> install Apache::Test CPAN: Storable loaded ok Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/authors/01mailrc.txt.gz Going to read /var/perl/.cpan/sources/authors/01mailrc.txt.gz Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/modules/02packages.details.txt.gz Going to read /var/perl/.cpan/sources/modules/02packages.details.txt.gz Database was generated on Tue, 09 Jun 2015 17:17:02 GMT There's a new CPAN.pm version (v2.10) available! [Current version is v1.7601] You might want to try install Bundle::CPAN reload cpan without quitting the current session. It should be a seamless upgrade while we are running... Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/modules/03modlist.data.gz Going to read /var/perl/.cpan/sources/modules/03modlist.data.gz Going to write /var/perl/.cpan/Metadata Apache::Test is up to date. Reminders are welcome! Michael Tests are ending with: Failed 2/13 test scripts, 84.62% okay. 7/43 subtests failed, 83.72% okay. whereas before I was gettign numbers such as: Failed 18/109 test programs. 247/4555 subtests failed. And I have also had all test successful... But do not have those saved. Mainly I am looking at 2/13 and 7/43 compared to 18/109 and 247/4555
Re: httpd and OpenSSL 1.0.2
Along the lines of "to be continued" - IMHO httpd should be one of the early adopters of not allowing linkage to versions of openssl that cannot support TLS1.2. I have built (on AIX) against libreSSL (v2.1.6) with some private additions for AIX (that will be verified and improved upon by openbsd in the soon to be released libreSSL 2.2 version). Basically, there are only two defines that were 'missing'. One was rather 'obscure' it what it is suppossed to be doing (i.e., looking in the openssl code) - the other was downright 'dangerous" because it permits 'any external so-called enthrophy generator' to be added and used for randomness - because it is, or at least was, part of the openSSL libraries. (the approach of libreSSL was to completely remove it, hence a missing #define). Again - to be continued. and asap - in a separate post I will post the differences to get it to link against libreSSL (p.s. only mod_ssl needs this afaik). On Wed, May 27, 2015 at 3:29 PM, Tom Browder wrote: > On May 27, 2015 5:26 AM, "Mario Brandt" wrote: > > Hi Tom, > > I saw you on the httpd dev mailing list about that topic. How did you > > manage to build apache against 1.0.2? > > > > Cause if I try that I get in my VM > > > > /opt/apache2/modules/mod_ssl.so: undefined symbol: SSL_CONF_CTX_finish > > > > or on my real server > > > > /opt/apache2/modules/mod_ssl.so: undefined symbol: SSL_CONF_CTX_free > > > > OpenSSL > > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 > > make depend > > make > > sudo make install > > > > > > apache > > ./configure --prefix=/opt/apache2 --enable-pie > > --enable-mods-shared=all --enable-so --disable-include --enable-lua > > --enable-deflate --enable-headers --enable-expires --enable-ssl=shared > > --enable-mpms-shared=all --with-mpm=event --enable-rewrite > > --with-z=$HOME/apache24/httpd-2.4.12/srclib/zlib --enable-module=ssl > > --enable-fcgid --with-included-apr > > --with-openssl=$HOME/apache24/openssl-1.0.2a > > --enable-ssl-staticlib-deps > > > > with the 1.0.1m it works all fine > > seehttps:// > github.com/JBlond/debian_build_apache24/blob/master/build_apache.sh > > > > > > Please tell me how you got it working. > > Mario, I did get it working, but I did have a bit more effort to make > the latest openssl work. Taking a quick look at your blog I believe I > can help, but I'll explain my solution in a follow-up message so this > thread is on the public mailing lists. > > I feel I must explain that I'm using a Debian 7, 64-bit server. It > might help if we could know your server info as other architectures > may require more or other tweaks. > > Finally, the best I can probably do is show you my configure options > which may conflict with yours. > > TO BE CONTINUED > > Best regards, > > -Tom >
Re: Looking ahead to 2.4.13 / 2.2.30
I never assume it is easy. As far as AIX goes, it would be "easier" for me,
as a packager to ignore AIX 5.3. But, for now, what I package for AIX 5.3
(TL7 and later) also works on AIX 6.1 and AIX 7.1 - unchanged.
Getting people to update is hard. Some do it automatically - proud to be
bleading edge, some never update regardless of argument.
I would hope that by changing any requisites (e.g., minimal level of
openssl) would not change the behavior of the application. If it does, then
I would tend to follow (what I think you are saying) - that such a change
is not permitted. In that case, hurrying a new release where it is
applicable (e.g., 2.6.X) might be sensible - if a factor such as security
is the driving (emotional) motivator.
What was I thinking? Well, little me was considering the recent "media"
storms re: web-related security (when they mean the servers that browsers
connect to) - and what an organization (perhaps community is a better word)
could do to assist from the server side - rather than placing ALL the
responsibility and load on the remote device (phone, tablet, desktop).
So, yes - it it "breaks" the server by raising the bar as far as XXX is
concerned, we cannot, or maybe should not, raise that bar for those
releases with an "improved" XXX.
As far as OpenSSL goes - maybe the only affected component is mod_ssl. I am
probably completely offbase (I like simple worldviews when I can get away
with it) - but I thought OpenSSL is an API. I would hope the API for 0.9.7
and 0.9.8 are compatible; while openssl-1.0.0 and OpenSSL-0.9.X are not.
And again, that is only an issue if something in the new API is definitely
needed. If not, something like mod_ssl might still link against
OpenSSL-0.9.8 - but, as far as ASF httpd and mod_ssl is concerned -
security concerns with the root cause in openssl-0.9.8 are not supported.
Please excuse my rambling: too many phone calls in between.
In short, if it does not impact the expected behavior of httpd I would hope
that dropping "support" for openssl-0.9.X will improve "the product" and be
a motivator for upgrading, rather than a limiting factor. (Oh how I love my
pink glasses :) )
On Fri, May 8, 2015 at 2:29 PM, William A Rowe Jr
wrote:
> FWIW...
>
> On Fri, May 8, 2015 at 2:16 AM, Michael Felt wrote:
>
>> From my perspective - as a simple packager (re: openssl - old versions) I
>> run into the problem of only being able to get to 0.9.8.k (AIX 5.3 TL12)
>>
>
> So, an operating system that has been unsupported for the past 2 years,
> check...
>
>
>> In short, there are ways around dependencies on old versions of openssl
>> on AIX. And further, if a 'user' is not willing to upgrade their OpenSSL -
>> why would you think they are going to upgrade to the latest httpd-2.2.x (or
>> any version for that matter).
>>
>
> Indeed, most won't, hopefully they are busy deploying a supported OS still
> receiving security updates, check...
>
> The rules change - and we (read "me and other users") cannot reasonably
>> claim "latest and greatest from ASF" while requiring support for insecure
>> openssl.
>>
>
> And the latest and greatest is 2.4.{last}, not 2.2.{bump} legacy update,
> and nobody would assume otherwise, check...
>
>
>> IMHO - you, ASF, also have an implied responsibility to the users of
>> Apache httpd powered sites. Being backward compatible too long keeps
>> weaknesses alive.
>>
>
> Therefore we ensure everyone who would otherwise pick up security fixes in
> the future will refuse to do so, because we stubbornly force a
> breaking/incompatible behavior change on some subversion legacy
> maintainence bump? And yourself, a packager, shipping new packages for an
> operating system with vulnerabilities which are no longer being patched?
> check...
>
> I've proposed changing the *default* config, universally, across all
> shipping versions. Yann proposes to enhance mod_ssl in non-breaking ways
> even back to 2.2, because 75-80% of the deployed servers have yet to update
> to 2.4. Not that most won't eventually, but right now, they are at 2.2.
>
> About users who have deployed a server, you can rant about employing the
> cudgel to the foolish administrators' skulls who won't re-configure their
> systems, however that is not an effective tool to ensure users update to
> the least-buggy, least-insecure subversion release of the software. It was
> mentioned in another thread, but just as an example, ripping out SSLv3
> essentially means that every user with older back-end services will *never*
> update again, period. Is that a rational act by an upstream project?
>
> When discussing 2.2 and 2.4, altering the behavior of an update is
Re: Looking ahead to 2.4.13 / 2.2.30
>From my perspective - as a simple packager (re: openssl - old versions) I run into the problem of only being able to get to 0.9.8.k (AIX 5.3 TL12). With AIX 6.1 and 7.1 it would be openssl-1.0.0(something - do not know by memory what patchlevel IBM openssl.base is at). Personally, I am going to look at packaging against LibreSSL. There are only three #ifdefs I needed to add to get it to build. My apologies for being so late with saying anything about this (I have been busy with 'regular' work. I will start a new thread later today - and do it again from trunks of 2.2.x, 2.4.x and 2.5.x. In short, there are ways around dependencies on old versions of openssl on AIX. And further, if a 'user' is not willing to upgrade their OpenSSL - why would you think they are going to upgrade to the latest httpd-2.2.x (or any version for that matter). The rules change - and we (read "me and other users") cannot reasonably claim "latest and greatest from ASF" while requiring support for insecure openssl. IMHO - you, ASF, also have an implied responsibility to the users of Apache httpd powered sites. Being backward compatible too long keeps weaknesses alive. Michael p.s. - for what is is worth +1 to drop 0.9.7 (maybe even 0.9.8 - but must test more) Michael On Thu, May 7, 2015 at 11:50 PM, Yann Ylavic wrote: > +1 > > On Thu, May 7, 2015 at 6:45 PM, William A Rowe Jr > wrote: > > Looking at the proposals in RFC 7525, I'm thinking this is a good time to > > re-sync > > httpd to these guidelines, even if it defers these releases by a week. > > WDYT? > > > > Bill > > > > On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski wrote: > >> > >> Yeah... I was gonna propose that once I had the weekend > >> to take a more in-depth look at 2.4... But I am +1 for > >> a release v. soon. > >> > >> Yeah, I'll RM 2.4 > >> > On Apr 30, 2015, at 5:52 PM, William A Rowe Jr > >> > wrote: > >> > > >> > On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. > >> > wrote: > >> > On Tue, 31 Mar 2015 10:49:47 -0400 > >> > Jim Jagielski wrote: > >> > > >> > > BTW: Would it make sense to consider a release of 2.4.13 in April > >> > > to coincide w/ ApacheCon? > >> > > >> > We've historically produced a release at the beginning of the con. > >> > It worked really well when we would hackathon two days, then retire > >> > to do other con stuff for the balance of the event with a new > >> > release in the hopper looking for votes. > >> > > >> > I'd love to see us tag and roll releases based on our efforts > >> > throughout the entire gathering, sometime in that following week. > >> > I offer to T&R an update of 2.2 as well to pick up any issues we > >> > resolve over the course of that week. > >> > > >> > It seems that we have 2 groups of good things to come out of > ApacheCon, > >> > some immediate fixes for things like BSD project efforts, some pretty > >> > straightforward defects that have been resolved... and then there's a > >> > bunch > >> > of energy about enhancements and the h2 universe. > >> > > >> > In the short term, WDYT about giving the trees a week to settle, grab > >> > the > >> > low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this > >> > coming > >> > week? Guessing Jim's up for RM'ing 2.4.13, and I'm happy to T&R > 2.2.30 > >> > in tandem. > >> > > >> > Concerns / observations / thoughts? > >> > > >> > Bill > >> > > >
Re: FYI - version checking against libressl - FYI (not yet a bug)
I have rebuilt my build systems - basically stripping them of accumulated libraries, and now no "OpenSSL" installed, but "LibreSSL". A basic characteristic of LibreSSL is to remove exposed parts of the API/ABI in order to make the package more secure. Now maybe httpd needs this aspect it is now falling over, in which case - someone much more into httpd code than I explain the need. If it is not really "needed" this may be a bug. In any case when trying to build httpd-2.4.12 from: ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all --enable-mods-shared=all --disable-lua --enable-ssl --with-ssl=/opt It fails during make with: /opt/build-1/libtool --silent --mode=compile xlc -I/opt/include -qHALT=E -U__STR__ -D_THREAD_SAFE -D_USE_IRS -D_LARGEF/httpd-2.4.12/os/unix -I/data/prj/apache/httpd/httpd-2.4.12/include -I/opt/include/apr-1 -I/opt/include -I/data/prj/apache/httpd/htpd/httpd-2.4.12/modules/cache -I/data/prj/apache/httpd/httpd-2.4.12/modules/core -I/data/prj/apache/httpd/httpd-2.4.12/modules/datadules/filters -I/data/prj/apache/httpd/httpd-2.4.12/modules/ldap -I/data/prj/apache/httpd/httpd-2.4.12/server -I/data/prj/apache/htapache/httpd/httpd-2.4.12/modules/lua -I/data/prj/apache/httpd/httpd-2.4.12/modules/proxy -I/data/prj/apache/httpd/httpd-2.4.12/mod.4.12/modules/ssl -I/data/prj/apache/httpd/httpd-2.4.12/modules/test -I/data/prj/apache/httpd/httpd-2.4.12/server -I/data/prj/apacha/prj/apache/httpd/httpd-2.4.12/modules/dav/main -I/data/prj/apache/httpd/httpd-2.4.12/modules/generators -I/data/prj/apache/httpd/sl_engine_init.c && touch ssl_engine_init.slo "ssl_engine_init.c", line 357.28: 1506-045 (S) Undeclared identifier ENGINE_CTRL_CHIL_SET_FORKCHECK. make: 1254-004 The error code from the last command is 1. Note: if I leave out the --enable-ssl --with-ssl=/opt the package builds as expected. On Fri, Apr 10, 2015 at 2:26 PM, Michael Felt wrote: > I am experimenting with libressl - and just thought I would mention an > error message I am getting with regard to openssl compatibility > > And if this has already been reported - please ignore - and accept my > apologies. I have not scanned the maillist for a previous report. > > ±±± > > configure: WARNING: Your APR does not include SSL/EVP support. To enable > it: configure --with-crypto > configure: WARNING: OpenSSL libraries are unusable > > Now there are differences between OpenSSL and LibreSSL - so you may need > to be thinking about different tests for testing OpenSSL API suitability. > > ±± > From config.log - some additional feedback. > > configure:25683: checking for OpenSSL version >= 0.9.8a > configure:25702: xlc -c -I/opt/include -I/opt/buildaix/include -O2 > -I/opt/include -L/opt/lib -qHALT=E -I/op > t/include -U__STR__ -D_THREAD_SAFE -D_USE_IRS -D_LARGEFILE64_SOURCE > conftest.c >&5 > configure:25702: $? = 0 > configure:25703: result: OK > ... > > configure:25772: checking for openssl/engine.h > configure:25772: result: yes > configure:25785: checking for SSLeay_version > configure:25785: xlc -o conftest -I/opt/include -I/opt/buildaix/include > -O2 -I/opt/include -L/opt/lib -qHAL > T=E -I/opt/include -U__STR__ -D_THREAD_SAFE -D_USE_IRS > -D_LARGEFILE64_SOURCE -Wl,-brtl conftest.c -lssl -l > crypto -lpthread >&5 > ld: 0711-317 ERROR: Undefined symbol: .SSLeay_version > > | } > configure:25785: result: no > configure:25785: checking for SSL_CTX_new > configure:25785: xlc -o conftest -I/opt/include -I/opt/buildaix/include > -O2 -I/opt/include -L/opt/lib -qHAL > T=E -I/opt/include -U__STR__ -D_THREAD_SAFE -D_USE_IRS > -D_LARGEFILE64_SOURCE -Wl,-brtl conftest.c -lssl -l > crypto -lpthread >&5 > ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_new > ... > | } > configure:25785: result: no > configure:25799: checking for ENGINE_init > configure:25799: xlc -o conftest -I/opt/include -I/opt/buildaix/include > -O2 -I/opt/include -L/opt/lib -qHAL > T=E -I/opt/include -U__STR__ -D_THREAD_SAFE -D_USE_IRS > -D_LARGEFILE64_SOURCE -Wl,-brtl conftest.c -lssl -l > crypto -lpthread >&5 > ld: 0711-317 ERROR: Undefined symbol: .ENGINE_init > ... > | } > configure:25799: result: no > configure:25799: checking for ENGINE_load_builtin_engines > configure:25799: xlc -o conftest -I/opt/include -I/opt/buildaix/include > -O2 -I/opt/include -L/opt/lib -qHAL > T=E -I/opt/include -U__STR__ -D_THREAD_SAFE -D_USE_IRS > -D_LARGEFILE64_SOURCE -Wl,-brtl conftest.c -lssl -l > crypto -lpthread >&5 > ld: 0711-317 ERROR: Undefined symbol: .ENGINE_load_builtin_engines > > ... > > | } > configure:25799: result: no > configure:25809: WARNING: OpenSSL libraries are unusable > configure:25822: result: yes > > >
Re: [PATCH 57100] "SSLProtocol ALL" is ignored for virtual hosts
On Thu, Jan 22, 2015 at 8:27 AM, Michael Kaufmann wrote: Hi, It would be great if somebody finds time to review the proposed patch for bug 57100 (and maybe commit it to trunk). Any feedback would be greatly appreciated. -> https://issues.apache.org/bugzilla/show_bug.cgi?id=57100 Thanks, committed to trunk and proposed for 2.4.x. That was quick! Thank you very much for reviewing and committing :-) Michael
[PATCH 57100] "SSLProtocol ALL" is ignored for virtual hosts
Hi, It would be great if somebody finds time to review the proposed patch for bug 57100 (and maybe commit it to trunk). Any feedback would be greatly appreciated. -> https://issues.apache.org/bugzilla/show_bug.cgi?id=57100 Regards, Michael
Re: ./configure differences between 2.2.x and 2.4.x
FYI - building and loading all modules in 2.4.x gives a very similar test result. i.e., loading more modules meant getting more errors. Now that I am finally getting to the point that I understand a bit of this I might even start digging for causes. First I want to get PHP builds improved - now that httpd is stable and consistent. Well, second PHP - first is my vacation!! Have a great release! On Tue, Aug 26, 2014 at 2:00 AM, William A. Rowe Jr. wrote: > And I still intend to answer your underlying question :) Many of the > elections are about availability, but others are about the experimental > nature of a module in one release vs another, or legal complications, e.g. > SSL. > > > Michael Felt wrote: > > I remember that there are differences, by design. > > I guess I should not do these tests after midnight - as I just saw that I > had commented out the --enable-load-all-modules. You had already shared > this wisdom! > > My apologies. :( > > > > > On Thu, Aug 21, 2014 at 8:29 PM, William A. Rowe Jr. > wrote: > >> On Fri, 8 Aug 2014 10:55:17 +0200 >> Michael Felt wrote: >> >> > *Please excuse my laziness* - because I am sure there is a way to get >> > all modules activated in both 2.2.X and 2.4.X - only that they are >> > slightly different - and I am sure you have documented it somewhere >> > (and even mentioned it (that there are differences such as ...) in >> > passing in previous replies) >> > >> > For 2.2.X I use: >> > $ ./configure CFLAGS=-O2 --enable-layout=AIX >> > --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config >> > --with-mpm=worker --enable-ssl --enable-mods-shared=all >> > >> > But this does not seem to get the mod_proxy, and likely other, mods >> > built. >> >> We will not be changing the behavior of ./configure in 2.2 - users who >> are picking up these critical fixes expect their previous ./config.nice >> to do the same thing it did last time. >> >> > For 2.4.X I use: >> > $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config >> > --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all >> > --enable-mods-shared=all --enable-load-all-modules --disable-lua >> > >> > (Note: the --enable-load-all-modules is there for testing) >> > >> > Apparently, my assumption that --enable-mods-shared=all would get all >> > mods built and ready for LoadModule is incorrect. >> >> True, there are legacy/testing mods that aren't built. But the behavior >> of most, all etc was significantly revised to better meet expectations >> with the 2.4 release. This version also should have no significant >> changes to ./configure behavior, the next release (2.6, or 3.0) would >> be the place for continued improvement. >> >> >
Re: ./configure differences between 2.2.x and 2.4.x
I remember that there are differences, by design. I guess I should not do these tests after midnight - as I just saw that I had commented out the --enable-load-all-modules. You had already shared this wisdom! My apologies. :( On Thu, Aug 21, 2014 at 8:29 PM, William A. Rowe Jr. wrote: > On Fri, 8 Aug 2014 10:55:17 +0200 > Michael Felt wrote: > > > *Please excuse my laziness* - because I am sure there is a way to get > > all modules activated in both 2.2.X and 2.4.X - only that they are > > slightly different - and I am sure you have documented it somewhere > > (and even mentioned it (that there are differences such as ...) in > > passing in previous replies) > > > > For 2.2.X I use: > > $ ./configure CFLAGS=-O2 --enable-layout=AIX > > --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config > > --with-mpm=worker --enable-ssl --enable-mods-shared=all > > > > But this does not seem to get the mod_proxy, and likely other, mods > > built. > > We will not be changing the behavior of ./configure in 2.2 - users who > are picking up these critical fixes expect their previous ./config.nice > to do the same thing it did last time. > > > For 2.4.X I use: > > $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config > > --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all > > --enable-mods-shared=all --enable-load-all-modules --disable-lua > > > > (Note: the --enable-load-all-modules is there for testing) > > > > Apparently, my assumption that --enable-mods-shared=all would get all > > mods built and ready for LoadModule is incorrect. > > True, there are legacy/testing mods that aren't built. But the behavior > of most, all etc was significantly revised to better meet expectations > with the 2.4 release. This version also should have no significant > changes to ./configure behavior, the next release (2.6, or 3.0) would > be the place for continued improvement. > >
Re: HTTPD-2.2.x and buildconf messages
OK. I was confused by this bit in the Vote thread: Please take note of APR subversion version bump from 1.5.0 to 1.5.1 since 2.2.27 was released. I guess I am easily confused ;) On Mon, Aug 25, 2014 at 9:00 AM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > This is true, because only 1.4.X is required. > > > > Regards > > > > Rüdiger > > > > *From:* Michael Felt [mailto:mamf...@gmail.com] > *Sent:* Sonntag, 24. August 2014 19:26 > *To:* dev@httpd.apache.org > *Subject:* HTTPD-2.2.x and buildconf messages > > > > In the past I have used buildconf messages as a reminder for where I > should be looking for apr and apr-util > > Since I read in the VOTE thread a bit about the apr version being updated, > I would like to mention that buildconf still talks about 1.4.X versions. > > root@x093:[/data/prj/apache/httpd/httpd-2.2.x]./buildconf > > You don't have a copy of the apr source in srclib/apr. > Please get the source using the following instructions, > or specify the location of the source with > --with-apr=[path to apr] : > >svn co http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x > srclib/apr > > > You don't have a copy of the apr-util source in srclib/apr-util. > Please get the source using the following instructions, > or specify the location of the source with > --with-apr-util=[path to apr-util] : > >svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x > srclib/apr-util > > ./buildconf --with-apr=../../apr/apr-1.5.1 > --with-apr-util=../../apr/apr-util-1.5.3 > > FYI. >
Re: [VOTE] Release 2.2.29 as GA?
In short, no regression I spot in my builds (in this case, both on AIX 5.3 TL7, no_proxy) root@x093:[/data/prj/apache/httpd/test]diff -u *results --- 2.2.27.results 2014-08-24 21:29:52 + +++ 2.2.29.results 2014-08-24 21:29:18 + @@ -33,6 +33,6 @@ Failed tests: 1-73 t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1) Failed test: 2 -Files=109, Tests=3337, 401 wallclock secs ( 4.73 usr 0.42 sys + 96.32 cusr 63.47 csys = 164.94 CPU) +Files=109, Tests=3337, 400 wallclock secs ( 4.73 usr 0.42 sys + 95.87 cusr 62.90 csys = 163.92 CPU) Result: FAIL Failed 15/109 test programs. 127/3337 subtests failed. On Mon, Aug 25, 2014 at 12:09 AM, Michael Felt wrote: > Yes, I will compare with the 2.2.27 branch for regressions. > > I just completed a comparison of 2.2.x and 2.4.x. > > Maybe you can help me with the correct configure settings to really get > all modules - without resorting to maintainer mode. > > > Just wanted to compare both 2.2.x and 2.4.x (say 2.2.30 and 2.4.11 > internally) > URL: http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x > Repository Root: http://svn.apache.org/repos/asf > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > Revision: 1620143 > Node Kind: directory > Schedule: normal > Last Changed Author: nd > Last Changed Rev: 1620064 > Last Changed Date: 2014-08-23 19:54:35 + (Sat, 23 Aug 2014) > > compared with > > URL: http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x > Repository Root: http://svn.apache.org/repos/asf > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > Revision: 1620143 > Node Kind: directory > Schedule: normal > Last Changed Author: nd > Last Changed Rev: 1620072 > Last Changed Date: 2014-08-23 20:19:04 + (Sat, 23 Aug 2014) > > The configure command for 2.2.x is: > ./configure CFLAGS=-O2 --enable-layout=AIX > --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config\ > --with-mpm=worker --enable-ssl --enable-mods-shared=all --enable-proxy > > and for 2.4.x is: > ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config > --with-apr-util=/opt/bin/apu-1-config\ > --enable-mpms-shared=all --enable-mods-shared=all --disable-lua > == Observation == > Although I am intending that all mods are built and loaded, it looks as if > I am not getting that result > for the 2.4.X as it's test shows many tests being skipped because mods are > missing. That might explain why > 2.4.X has fewer failed tests: 2.2.X has (17/109) compared with 2.4.X (1/97) > > = > Apache--2.2.x test report > > Test Summary Report > --- > t/apache/server_name_port.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 84 tests but ran 0. > t/modules/proxy.t (Wstat: 0 Tests: 17 Failed: 2) > Failed tests: 9-10 > > t/protocol/nntp-like.t(Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 10 tests but ran 0. > t/security/CVE-2005-2700.t(Wstat: 0 Tests: 2 Failed: 1) > Failed test: 1 > t/security/CVE-2009-3555.t(Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 4 tests but ran 0. > t/ssl/basicauth.t (Wstat: 0 Tests: 3 Failed: 2) > Failed tests: 2-3 > t/ssl/env.t (Wstat: 0 Tests: 30 Failed: 23) > Failed tests: 1-8, 16-30 > t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4) > Failed tests: 1-4 > t/ssl/fakeauth.t (Wstat: 0 Tests: 3 Failed: 2) > Failed tests: 2-3 > t/ssl/headers.t (Wstat: 0 Tests: 3 Failed: 3) > Failed tests: 1-3 > t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 8) > Failed tests: 1-8 > t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 4) > Failed tests: 1-4 > t/ssl/proxy.t (Wstat: 0 Tests: 172 Failed: 118) > Failed tests: 3-7, 60-172 > > t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 5) > Failed tests: 2, 5-7, 9 > t/ssl/v2.t(Wstat: 0 Tests: 1 Failed: 1) > Failed test: 1 > t/ssl/varlookup.t (Wstat: 0 Tests: 73 Failed: 73) > Failed tests: 1-73 > t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1) > Failed test: 2 > Files=109, Tests=3543, 616 wallclock secs ( 5.15 usr 0.42 sys + 98.30 > cusr 64.99 csys = 168.86 CPU) > Result: FAIL > Failed 17/109 test programs. 247/3543 subtests failed. > > [warning] server loopback:8529 shut
Re: [VOTE] Release 2.2.29 as GA?
7;, cannot find module 'imap' t/security/CVE-2007-6388.t .. ok t/security/CVE-2008-2364.t .. skipped: cannot find module 'proxy' t/security/CVE-2009-1195.t .. skipped: cannot find module 'include' t/security/CVE-2009-1890.t .. skipped: cannot find module 'mod_proxy', cannot find module 'proxy_http.c' t/security/CVE-2009-3555.t .. skipped: cannot find module 'ssl' t/security/CVE-2011-3368-rewrite.t .. skipped: cannot find module 'rewrite' t/security/CVE-2011-3368.t .. skipped: cannot find module 'proxy' t/ssl/all.t . skipped: cannot find module 'mod_ssl' Test Summary Report --- t/apache/chunkinput.t (Wstat: 0 Tests: 9 Failed: 1) Failed test: 3 Files=97, Tests=2894, 382 wallclock secs ( 3.85 usr 0.38 sys + 88.76 cusr 82.22 csys = 175.21 CPU) Result: FAIL Failed 1/97 test programs. 1/2894 subtests failed. [warning] server loopback:8529 shutdown [warning] port 8529 still in use... On Mon, Aug 25, 2014 at 12:03 AM, William A. Rowe Jr. wrote: > Michael, can you please compare 2.2.27 to 2.2.29? 2.2 in testing doesn't > resemble 2.4. That said, we are simply concerned about any potential > regressions in the legacy branch. > > Thanks for the feedback! > > > Michael Felt wrote: > > built on a second server, but at AIX 5.3 TL12 (5300-12-05-1140), previous > report was on AIX 5.3 TL7 (5300-07-10-0943) - so the differences (more > tests passed) may be related to that. However, on the old AIX 5.3 TL7 to > 2.4.9 tests (nearly) all pass. > > BOTH are reporting some failed CVE tests! > > With --enable-proxy added, for more tests, result is now: > > Test Summary Report > --- > t/apache/chunkinput.t (Wstat: 0 Tests: 9 Failed: 1) > Failed test: 3 > t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2) > Failed tests: 2-3 > t/security/CVE-2009-3555.t(Wstat: 65280 Tests: 2 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 4 tests but ran 2. > t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) > Failed test: 2 > t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4) > Failed tests: 3-4, 7-8 > t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2) > Failed tests: 1-2 > t/ssl/proxy.t (Wstat: 0 Tests: 172 Failed: 10) > Failed tests: 3-7, 116-120 > t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1) > Failed test: 9 > Files=109, Tests=3731, 293 wallclock secs ( 1.51 usr 0.22 sys + 45.93 > cusr 15.62 csys = 63.28 CPU) > Result: FAIL > Failed 8/109 test programs. 21/3731 subtests failed. > [warning] server loopback:8529 shutdown > [warning] port 8529 still in use... > ..done > [ error] error running tests (please examine t/logs/error_log) > > Hope this helps! > > > On Sun, Aug 24, 2014 at 9:36 PM, Michael Felt wrote: > >> package builds fine using the build/aix scripts, except these ignore, if >> possible, the srcapr that was included in the tarball. >> >> Question: is the .gdbinit in tarball root part of the distro now? >> >> Apeche::Test returned these errors >> Test Summary Report >> --- >> t/apache/server_name_port.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 84 tests but ran 0. >> t/protocol/nntp-like.t(Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 10 tests but ran 0. >> t/security/CVE-2005-2700.t(Wstat: 0 Tests: 2 Failed: 1) >> Failed test: 1 >> t/security/CVE-2009-3555.t(Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 4 tests but ran 0. >> t/ssl/basicauth.t (Wstat: 0 Tests: 3 Failed: 2) >> Failed tests: 2-3 >> t/ssl/env.t (Wstat: 0 Tests: 30 Failed: 23) >> Failed tests: 1-8, 16-30 >> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4) >> Failed tests: 1-4 >> t/ssl/fakeauth.t (Wstat: 0 Tests: 3 Failed: 2) >> Failed tests: 2-3 >> t/ssl/headers.t (Wstat: 0 Tests: 3 Failed: 3) >> Failed tests: 1-3 >> t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 8) >> Failed tests: 1-8 >> t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 4) >> Failed tests: 1-4 >> t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 5) >> Failed tests: 2, 5-7, 9 >
Re: [VOTE] Release 2.2.29 as GA?
built on a second server, but at AIX 5.3 TL12 (5300-12-05-1140), previous report was on AIX 5.3 TL7 (5300-07-10-0943) - so the differences (more tests passed) may be related to that. However, on the old AIX 5.3 TL7 to 2.4.9 tests (nearly) all pass. BOTH are reporting some failed CVE tests! With --enable-proxy added, for more tests, result is now: Test Summary Report --- t/apache/chunkinput.t (Wstat: 0 Tests: 9 Failed: 1) Failed test: 3 t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/security/CVE-2009-3555.t(Wstat: 65280 Tests: 2 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 4 tests but ran 2. t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) Failed test: 2 t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4) Failed tests: 3-4, 7-8 t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 1-2 t/ssl/proxy.t (Wstat: 0 Tests: 172 Failed: 10) Failed tests: 3-7, 116-120 t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1) Failed test: 9 Files=109, Tests=3731, 293 wallclock secs ( 1.51 usr 0.22 sys + 45.93 cusr 15.62 csys = 63.28 CPU) Result: FAIL Failed 8/109 test programs. 21/3731 subtests failed. [warning] server loopback:8529 shutdown [warning] port 8529 still in use... ..done [ error] error running tests (please examine t/logs/error_log) Hope this helps! On Sun, Aug 24, 2014 at 9:36 PM, Michael Felt wrote: > package builds fine using the build/aix scripts, except these ignore, if > possible, the srcapr that was included in the tarball. > > Question: is the .gdbinit in tarball root part of the distro now? > > Apeche::Test returned these errors > Test Summary Report > --- > t/apache/server_name_port.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 84 tests but ran 0. > t/protocol/nntp-like.t(Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 10 tests but ran 0. > t/security/CVE-2005-2700.t(Wstat: 0 Tests: 2 Failed: 1) > Failed test: 1 > t/security/CVE-2009-3555.t(Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 4 tests but ran 0. > t/ssl/basicauth.t (Wstat: 0 Tests: 3 Failed: 2) > Failed tests: 2-3 > t/ssl/env.t (Wstat: 0 Tests: 30 Failed: 23) > Failed tests: 1-8, 16-30 > t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4) > Failed tests: 1-4 > t/ssl/fakeauth.t (Wstat: 0 Tests: 3 Failed: 2) > Failed tests: 2-3 > t/ssl/headers.t (Wstat: 0 Tests: 3 Failed: 3) > Failed tests: 1-3 > t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 8) > Failed tests: 1-8 > t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 4) > Failed tests: 1-4 > t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 5) > Failed tests: 2, 5-7, 9 > t/ssl/v2.t(Wstat: 0 Tests: 1 Failed: 1) > Failed test: 1 > t/ssl/varlookup.t (Wstat: 0 Tests: 73 Failed: 73) > Failed tests: 1-73 > t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1) > Failed test: 2 > Files=109, Tests=3337, 400 wallclock secs ( 4.73 usr 0.42 sys + 95.87 > cusr 62.90 csys = 163.92 CPU) > Result: FAIL > Failed 15/109 test programs. 127/3337 subtests failed. > > Will run again with --enable-proxy as I noticed all those tests are being > skipped. And may have to do something similiar for the _auth_ modules. They > do not look to all being tested. > > FYI only - as I do not believe I have a vote to give. > > I would like to mention, re: the tests, that most, if not all, pass with > httpd-2.4.9 > > > On Fri, Aug 22, 2014 at 8:59 PM, William A. Rowe Jr. > wrote: > >> The pre-release candidate Apache httpd 2.2.29 - with simply a rebuild >> of the docs/manual/ since 2.2.28, can be found in; >> >> http://httpd.apache.org/dev/dist/ >> >> +/-1 >> [ ] Release 2.2.29 (apr 1.5.1, apr-util 1.5.3) >> >> Please take note of APR subversion version bump from 1.5.0 to 1.5.1 >> since 2.2.27 was released. >> >> Vote to conclude 18:00 GMT Monday, provided enough voters have had time >> to review. >> > >
Re: [VOTE] Release 2.2.29 as GA?
package builds fine using the build/aix scripts, except these ignore, if possible, the srcapr that was included in the tarball. Question: is the .gdbinit in tarball root part of the distro now? Apeche::Test returned these errors Test Summary Report --- t/apache/server_name_port.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 84 tests but ran 0. t/protocol/nntp-like.t(Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 10 tests but ran 0. t/security/CVE-2005-2700.t(Wstat: 0 Tests: 2 Failed: 1) Failed test: 1 t/security/CVE-2009-3555.t(Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 4 tests but ran 0. t/ssl/basicauth.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/ssl/env.t (Wstat: 0 Tests: 30 Failed: 23) Failed tests: 1-8, 16-30 t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4) Failed tests: 1-4 t/ssl/fakeauth.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/ssl/headers.t (Wstat: 0 Tests: 3 Failed: 3) Failed tests: 1-3 t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 8) Failed tests: 1-8 t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 4) Failed tests: 1-4 t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 5) Failed tests: 2, 5-7, 9 t/ssl/v2.t(Wstat: 0 Tests: 1 Failed: 1) Failed test: 1 t/ssl/varlookup.t (Wstat: 0 Tests: 73 Failed: 73) Failed tests: 1-73 t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1) Failed test: 2 Files=109, Tests=3337, 400 wallclock secs ( 4.73 usr 0.42 sys + 95.87 cusr 62.90 csys = 163.92 CPU) Result: FAIL Failed 15/109 test programs. 127/3337 subtests failed. Will run again with --enable-proxy as I noticed all those tests are being skipped. And may have to do something similiar for the _auth_ modules. They do not look to all being tested. FYI only - as I do not believe I have a vote to give. I would like to mention, re: the tests, that most, if not all, pass with httpd-2.4.9 On Fri, Aug 22, 2014 at 8:59 PM, William A. Rowe Jr. wrote: > The pre-release candidate Apache httpd 2.2.29 - with simply a rebuild > of the docs/manual/ since 2.2.28, can be found in; > > http://httpd.apache.org/dev/dist/ > > +/-1 > [ ] Release 2.2.29 (apr 1.5.1, apr-util 1.5.3) > > Please take note of APR subversion version bump from 1.5.0 to 1.5.1 > since 2.2.27 was released. > > Vote to conclude 18:00 GMT Monday, provided enough voters have had time > to review. >
HTTPD-2.2.x and buildconf messages
In the past I have used buildconf messages as a reminder for where I should be looking for apr and apr-util Since I read in the VOTE thread a bit about the apr version being updated, I would like to mention that buildconf still talks about 1.4.X versions. root@x093:[/data/prj/apache/httpd/httpd-2.2.x]./buildconf You don't have a copy of the apr source in srclib/apr. Please get the source using the following instructions, or specify the location of the source with --with-apr=[path to apr] : svn co http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x srclib/apr You don't have a copy of the apr-util source in srclib/apr-util. Please get the source using the following instructions, or specify the location of the source with --with-apr-util=[path to apr-util] : svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x srclib/apr-util ./buildconf --with-apr=../../apr/apr-1.5.1 --with-apr-util=../../apr/apr-util-1.5.3 FYI.
PATCH: httpd-2.2.x build/aix
Done for now root@x099:[/data/prj/apache/httpd/httpd-2.2.x]cat build/aix/CHANGES 2014-08-07: %% buildaix.ksh * store installp result in ./installp/ppc directory rather than ./build/aix * default user/group is httpd/httpd rather than daemon/daemon * add argument to configure --with-z=`pwd`/build/aix/include and -L/opt/freeware/lib when ** no zlib.h can be found in a standard location * also check the old PATH for apr (/opt/apr/bin) for apr_config and apu_config * add start/stop scripts to /etc/rc.d/rc2.d to autostart/autostop httpd at boot/shutdown * add a symbolic link to /usr/sbin/apachectl => /opt/httpd/sbin/apachectl %%aixinfo * remove a fixed VERSION label value * change ARCH string from powerpc to ppc %%mkinstallp.ksh * Change description text * Add License Acceptance * Set file permissions - add group-read,other-read, remove other-write (rw-rw-r--, 644) * Set directory permissions: add group-other: read+access (rwxr-xr-x) * set user/group to httpd:httpd (root:system) in the installp file ** need to set the name now so the tcb inventory has the correct user/group labels * add a command to config AIX during install (build/aix/httpd.rte.config) ** this command makes the default user/group httpd/httpd if they do not exist ** and does a chown to the new numbers - so the files are not owned by root after install * store installp result in ./installp/ppc directory rather than ./build/aix * add Requisites for ASF.apr-vac.rte and ASF.apu-vac.rte AND bos.rte.libc at building AIX level httpd-2.2.x-buildaix.tar.bz2 Description: BZip2 compressed data
Re: testing apache
Last update (for your suggestions) -- verbose output
t/security/CVE-2008-2364.t ..
1..3
# Running under perl version 5.010001 for aix
# Current time local: Fri Aug 8 11:38:28 2014
# Current time GMT: Fri Aug 8 11:38:28 2014
# Using Test.pm version 1.25_02
# Using Apache/Test.pm version 1.38
# testing : reverse proxy to index.html
# expected: 200
# received: '200'
ok 1
# testing : small number of interim responses - CVE-2008-2364
# expected: 200
# received: '100'
not ok 2
# Failed test 2 in t/security/CVE-2008-2364.t at line 19
# testing : large number of interim responses - CVE-2008-2364
# expected: 502
# received: '100'
not ok 3
# Failed test 3 in t/security/CVE-2008-2364.t at line 22
Failed 2/3 subtests
t/ssl/extlookup.t ...
1..4
# Running under perl version 5.010001 for aix
# Current time local: Fri Aug 8 11:38:32 2014
# Current time GMT: Fri Aug 8 11:38:32 2014
# Using Test.pm version 1.25_02
# Using Apache/Test.pm version 1.38
# testing : ssl_ext_lookup works for 1.3.6.1.4.1.18060.12.0
# expected: 200
# received: '200'
ok 1
# testing : Extension value match for 1.3.6.1.4.1.18060.12.0
# expected: 'Lemons'
# received: 'NULL'
not ok 2
# Failed test 2 in t/ssl/extlookup.t at line 27
# testing : ssl_ext_lookup works for 2.16.840.1.113730.1.13
# expected: 200
# received: '200'
ok 3
# testing : Extension value match for 2.16.840.1.113730.1.13
# expected: 'This Is A Comment'
# received: 'This Is A Comment'
ok 4
Failed 1/4 subtests
t/ssl/require.t .
1..10
# Running under perl version 5.010001 for aix
# Current time local: Fri Aug 8 11:38:36 2014
# Current time GMT: Fri Aug 8 11:38:36 2014
# Using Test.pm version 1.25_02
# Using Apache/Test.pm version 1.38
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
not ok 9
# Failed test 9 in t/ssl/require.t at line 44
ok 10
Failed 1/10 subtests
Test Summary Report
---
t/security/CVE-2008-2364.t (Wstat: 0 Tests: 3 Failed: 2)
Failed tests: 2-3
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 2
t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1)
Failed test: 9
Files=3, Tests=17, 13 wallclock secs ( 0.08 usr 0.02 sys + 4.31 cusr
1.88 csys = 6.29 CPU)
Result: FAIL
Failed 3/3 test programs. 4/17 subtests failed.
Thank you for your attention!
On Fri, Aug 8, 2014 at 1:12 PM, Michael Felt wrote:
> update:
> I think the CVE test passed with 2.4.10 and failed with 2.2.28 because
> 1. iirc, 2.4.10 does not have CGI (by default) and 2.2.28 does.
> 2. the perl cgi_scripts needed are not present, so cannot be loaded
>
> The test is - mainly -
>
> Apache::TestRequest::module("proxy_http_reverse");
> Apache::TestRequest::user_agent(requests_redirectable => 0);
>
> my $r = GET("/reverse/");
> ok t_cmp($r->code, 200, "reverse proxy to index.html");
>
> if (have_cgi) {
> $r = GET("/reverse/modules/cgi/nph-interim1.pl");
> ok t_cmp($r->code, 200, "small number of interim responses -
> CVE-2008-2364");
>
> $r = GET("/reverse/modules/cgi/nph-interim2.pl");
> ok t_cmp($r->code, 502, "large number of interim responses -
> CVE-2008-2364");
>
> } else {
> skip "skipping tests without CGI module" foreach (1..2);
> }
>
> The first test passed (can GET /reverse/ )
> But the other two fail - I think because the nph-interim?.pl are missing
> in the ./test I download via svn:
>
> michael@x054:[/data/prj/SVN]svn checkout
> http://svn.apache.org/repos/asf/httpd/test/framework/trunk
> /data/prj/apache/httpd/test
>
> Fetching external item into 'apache/httpd/test/Apache-Test'
> Checked out external at revision 1616713.
>
> Checked out revision 1616713.
>
> cd /data/prj/apache/httpd/test
> root@x099:[/data/prj/apache/httpd/test]find . -name nph-interm1.pl
> root@x099:[/data/prj/apache/httpd/test]find . -name reverse
> ./t/htdocs/modules/proxy/reverse
> root@x099:[/data/prj/apache/httpd/test]find . -name reverse
> root@x099:[/data/prj/apache/httpd/test]ls -l
> ./t/htdocs/modules/proxy/reverse
> total 32
> drwxrwxr-x6 michael felt 4096 Aug 06 12:40 .svn
> drwxrwxr-x3 michael felt 4096 Feb 19 2013 notproxy
> root@x099:[/data/prj/apache/httpd/test]find . -name
> cgi
> ./t/htdocs/modules/cgi
>
> Suggestions?
>
>
>
> On Fri, Aug 8, 2014 at 12:42 PM, Michael Felt wrote:
>
>> after --enable-proxy reran tests and get this:
>> ...
>> using Apache/2.2.28-dev (worker MPM)
>> ...
>> Test Summary Report
>> ---
>> t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
>> Failed tests: 2-3
>>
>> t/ssl/extlookup.t (Wstat: 0 T
Re: testing apache
update:
I think the CVE test passed with 2.4.10 and failed with 2.2.28 because
1. iirc, 2.4.10 does not have CGI (by default) and 2.2.28 does.
2. the perl cgi_scripts needed are not present, so cannot be loaded
The test is - mainly -
Apache::TestRequest::module("proxy_http_reverse");
Apache::TestRequest::user_agent(requests_redirectable => 0);
my $r = GET("/reverse/");
ok t_cmp($r->code, 200, "reverse proxy to index.html");
if (have_cgi) {
$r = GET("/reverse/modules/cgi/nph-interim1.pl");
ok t_cmp($r->code, 200, "small number of interim responses -
CVE-2008-2364");
$r = GET("/reverse/modules/cgi/nph-interim2.pl");
ok t_cmp($r->code, 502, "large number of interim responses -
CVE-2008-2364");
} else {
skip "skipping tests without CGI module" foreach (1..2);
}
The first test passed (can GET /reverse/ )
But the other two fail - I think because the nph-interim?.pl are missing in
the ./test I download via svn:
michael@x054:[/data/prj/SVN]svn checkout
http://svn.apache.org/repos/asf/httpd/test/framework/trunk
/data/prj/apache/httpd/test
Fetching external item into 'apache/httpd/test/Apache-Test'
Checked out external at revision 1616713.
Checked out revision 1616713.
cd /data/prj/apache/httpd/test
root@x099:[/data/prj/apache/httpd/test]find . -name nph-interm1.pl
root@x099:[/data/prj/apache/httpd/test]find . -name reverse
./t/htdocs/modules/proxy/reverse
root@x099:[/data/prj/apache/httpd/test]find . -name reverse
root@x099:[/data/prj/apache/httpd/test]ls -l
./t/htdocs/modules/proxy/reverse
total 32
drwxrwxr-x6 michael felt 4096 Aug 06 12:40 .svn
drwxrwxr-x3 michael felt 4096 Feb 19 2013 notproxy
root@x099:[/data/prj/apache/httpd/test]find . -name
cgi
./t/htdocs/modules/cgi
Suggestions?
On Fri, Aug 8, 2014 at 12:42 PM, Michael Felt wrote:
> after --enable-proxy reran tests and get this:
> ...
> using Apache/2.2.28-dev (worker MPM)
> ...
> Test Summary Report
> ---
> t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
> Failed tests: 2-3
>
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
> Failed test: 2
> t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1)
> Failed test: 9
> Files=109, Tests=3709, 589 wallclock secs ( 5.13 usr 0.48 sys + 166.18
> cusr 74.55 csys = 246.34 CPU)
> Result: FAIL
>
> Any assistance with taking the next step, e.g., understanding why the test
> failed, is welcome.
>
>
> On Fri, Aug 8, 2014 at 10:42 AM, Michael Felt wrote:
>
>> So, back to testing again - on the same system where 2.4.10-distro passed
>> all tests it ran, 2.2.28-dev has a few errors reporting - and I need to
>> figure out why mod_proxy is not being built (or maybe it is only that it is
>> not Loaded)
>>
>> Summary:
>> cc is a tracked alias for /usr/vac/bin/cc
>> root@x099:[/data/prj/apache/httpd/test]oslevel -s
>> 7100-02-04-1341
>> root@x099:[/data/prj/apache/httpd/test]type perl
>> perl is /usr/bin/perl
>> root@x099:[/data/prj/apache/httpd/test]ls -l /usr/bin/perl
>> lrwxrwxrwx1 root system 29 Aug 05 21:00 /usr/bin/perl
>> -> /usr/opt/perl5/bin/perl5.10.1
>>
>> root@x099:[/data/prj/apache/httpd/test]find /opt/httpd -name apxs
>> /opt/httpd/sbin/apxs
>> root@x099:[/data/prj/apache/httpd/test]perl Makefile.PL -apxs
>> /opt/httpd/sbin/apxs
>> [ info] generating script ./Apache-Test.save/t/cgi-bin/
>> next_available_port.pl
>> [ info] generating script ./Apache-Test.save/t/cgi-bin/cookies.pl
>> ...
>> Checking for File::Spec...ok
>> Checking for Cwd...ok
>> Generating a Unix-style Makefile
>> Writing Makefile for httpd-test
>> Writing MYMETA.yml and MYMETA.json
>> root@x099:[/data/prj/apache/httpd/test]
>>
>> root@x099:[/data/prj/apache/httpd/test]find . ! -user michael -exec
>> chown michael {} \;
>> root@x099:[/data/prj/apache/httpd/test]su michael
>> root@x099:[/data/prj/apache/httpd/test]t/TEST
>> [warning] setting ulimit to allow core files
>> ulimit -c unlimited; /usr/opt/perl5/bin/perl
>> /data/prj/apache/httpd/test/t/TEST
>> cd test_rwrite && make .libs/mod_test_rwrite.so
>> make[1]: Entering directory
>> `/data/prj/apache/httpd/test/c-modules/test_rwrite'
>> /opt/httpd/sbin/apxs -D APACHE2 -I/data/prj/apache/httpd/test/c-modules
>> -c mod_test_rwrite.c
>> ...
>> using Apache/2.2.28-dev (worker MPM)
>>
>> waiting 60 seconds for server to start: ...
>> waiting 60 seconds for server to start: ok (waited 2 secs)
>> server loopback:8529 started
>> server loopback:8530 listening (mod_nntp_like)
Re: testing apache
after --enable-proxy reran tests and get this:
...
using Apache/2.2.28-dev (worker MPM)
...
Test Summary Report
---
t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
Failed tests: 2-3
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 2
t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1)
Failed test: 9
Files=109, Tests=3709, 589 wallclock secs ( 5.13 usr 0.48 sys + 166.18
cusr 74.55 csys = 246.34 CPU)
Result: FAIL
Any assistance with taking the next step, e.g., understanding why the test
failed, is welcome.
On Fri, Aug 8, 2014 at 10:42 AM, Michael Felt wrote:
> So, back to testing again - on the same system where 2.4.10-distro passed
> all tests it ran, 2.2.28-dev has a few errors reporting - and I need to
> figure out why mod_proxy is not being built (or maybe it is only that it is
> not Loaded)
>
> Summary:
> cc is a tracked alias for /usr/vac/bin/cc
> root@x099:[/data/prj/apache/httpd/test]oslevel -s
> 7100-02-04-1341
> root@x099:[/data/prj/apache/httpd/test]type perl
> perl is /usr/bin/perl
> root@x099:[/data/prj/apache/httpd/test]ls -l /usr/bin/perl
> lrwxrwxrwx1 root system 29 Aug 05 21:00 /usr/bin/perl ->
> /usr/opt/perl5/bin/perl5.10.1
>
> root@x099:[/data/prj/apache/httpd/test]find /opt/httpd -name apxs
> /opt/httpd/sbin/apxs
> root@x099:[/data/prj/apache/httpd/test]perl Makefile.PL -apxs
> /opt/httpd/sbin/apxs
> [ info] generating script ./Apache-Test.save/t/cgi-bin/
> next_available_port.pl
> [ info] generating script ./Apache-Test.save/t/cgi-bin/cookies.pl
> ...
> Checking for File::Spec...ok
> Checking for Cwd...ok
> Generating a Unix-style Makefile
> Writing Makefile for httpd-test
> Writing MYMETA.yml and MYMETA.json
> root@x099:[/data/prj/apache/httpd/test]
>
> root@x099:[/data/prj/apache/httpd/test]find . ! -user michael -exec chown
> michael {} \;
> root@x099:[/data/prj/apache/httpd/test]su michael
> root@x099:[/data/prj/apache/httpd/test]t/TEST
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/opt/perl5/bin/perl
> /data/prj/apache/httpd/test/t/TEST
> cd test_rwrite && make .libs/mod_test_rwrite.so
> make[1]: Entering directory
> `/data/prj/apache/httpd/test/c-modules/test_rwrite'
> /opt/httpd/sbin/apxs -D APACHE2 -I/data/prj/apache/httpd/test/c-modules
> -c mod_test_rwrite.c
> ...
> using Apache/2.2.28-dev (worker MPM)
>
> waiting 60 seconds for server to start: ...
> waiting 60 seconds for server to start: ok (waited 2 secs)
> server loopback:8529 started
> server loopback:8530 listening (mod_nntp_like)
> server loopback:8531 listening (mod_nntp_like_ssl)
> server loopback:8532 listening (mod_ssl)
> server loopback:8533 listening (ssl_optional_cc)
> server loopback:8534 listening (ssl_pr33791)
> server loopback:8535 listening (proxy_http_bal1)
> server loopback:8536 listening (proxy_http_bal2)
> server loopback:8537 listening (proxy_http_balancer)
> server loopback:8538 listening (cve_2011_3368_rewrite)
> server loopback:8539 listening (proxy_http_reverse)
> server loopback:8540 listening (cve_2011_3368)
> server loopback:8541 listening (mod_headers)
> server loopback:8542 listening (error_document)
> server loopback:8543 listening (http_strict)
> server loopback:8544 listening (mod_vhost_alias)
> server loopback:8545 listening (mod_include)
> server loopback:8546 listening (proxy_http_https)
> server loopback:8547 listening (proxy_https_https)
> server loopback:8548 listening (proxy_https_http)
> [ info] adding source lib /data/prj/apache/httpd/test/Apache-Test/lib to
> @INC
> t/apache/404.t .. ok
> t/apache/acceptpathinfo.t ... ok
> ...
> t/ssl/env.t . ok
> t/ssl/extlookup.t ... 1/4 # Failed test 2 in
> t/ssl/extlookup.t at line 27
> t/ssl/extlookup.t ... Failed 1/4 subtests
> t/ssl/fakeauth.t ok
> t/ssl/headers.t . ok
> t/ssl/http.t ok
> t/ssl/pr12355.t . ok
> t/ssl/pr43738.t . ok
> t/ssl/proxy.t ... skipped: cannot find module
> 'mod_proxy', cannot find module 'proxy_http.c'
> t/ssl/require.t . 2/10 # Failed test 9 in
> t/ssl/require.t at line 44
> t/ssl/require.t . Failed 1/10 subtests
> t/ssl/v2.t .. ok
> t/ssl/varlookup.t ... ok
> t/ssl/verify.t .. ok
>
> Test Summary Report
> ---
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
> Failed test: 2
> t/ssl/require.t (Wstat:
./configure differences between 2.2.x and 2.4.x
*Please excuse my laziness* - because I am sure there is a way to get all modules activated in both 2.2.X and 2.4.X - only that they are slightly different - and I am sure you have documented it somewhere (and even mentioned it (that there are differences such as ...) in passing in previous replies) For 2.2.X I use: $ ./configure CFLAGS=-O2 --enable-layout=AIX --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config --with-mpm=worker --enable-ssl --enable-mods-shared=all But this does not seem to get the mod_proxy, and likely other, mods built. For 2.4.X I use: $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all --enable-mods-shared=all --enable-load-all-modules --disable-lua (Note: the --enable-load-all-modules is there for testing) Apparently, my assumption that --enable-mods-shared=all would get all mods built and ready for LoadModule is incorrect. Thanks for clarification! Michael
Re: testing apache
So, back to testing again - on the same system where 2.4.10-distro passed
all tests it ran, 2.2.28-dev has a few errors reporting - and I need to
figure out why mod_proxy is not being built (or maybe it is only that it is
not Loaded)
Summary:
cc is a tracked alias for /usr/vac/bin/cc
root@x099:[/data/prj/apache/httpd/test]oslevel -s
7100-02-04-1341
root@x099:[/data/prj/apache/httpd/test]type perl
perl is /usr/bin/perl
root@x099:[/data/prj/apache/httpd/test]ls -l /usr/bin/perl
lrwxrwxrwx1 root system 29 Aug 05 21:00 /usr/bin/perl ->
/usr/opt/perl5/bin/perl5.10.1
root@x099:[/data/prj/apache/httpd/test]find /opt/httpd -name apxs
/opt/httpd/sbin/apxs
root@x099:[/data/prj/apache/httpd/test]perl Makefile.PL -apxs
/opt/httpd/sbin/apxs
[ info] generating script ./Apache-Test.save/t/cgi-bin/
next_available_port.pl
[ info] generating script ./Apache-Test.save/t/cgi-bin/cookies.pl
...
Checking for File::Spec...ok
Checking for Cwd...ok
Generating a Unix-style Makefile
Writing Makefile for httpd-test
Writing MYMETA.yml and MYMETA.json
root@x099:[/data/prj/apache/httpd/test]
root@x099:[/data/prj/apache/httpd/test]find . ! -user michael -exec chown
michael {} \;
root@x099:[/data/prj/apache/httpd/test]su michael
root@x099:[/data/prj/apache/httpd/test]t/TEST
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/opt/perl5/bin/perl
/data/prj/apache/httpd/test/t/TEST
cd test_rwrite && make .libs/mod_test_rwrite.so
make[1]: Entering directory
`/data/prj/apache/httpd/test/c-modules/test_rwrite'
/opt/httpd/sbin/apxs -D APACHE2 -I/data/prj/apache/httpd/test/c-modules
-c mod_test_rwrite.c
...
using Apache/2.2.28-dev (worker MPM)
waiting 60 seconds for server to start: ...
waiting 60 seconds for server to start: ok (waited 2 secs)
server loopback:8529 started
server loopback:8530 listening (mod_nntp_like)
server loopback:8531 listening (mod_nntp_like_ssl)
server loopback:8532 listening (mod_ssl)
server loopback:8533 listening (ssl_optional_cc)
server loopback:8534 listening (ssl_pr33791)
server loopback:8535 listening (proxy_http_bal1)
server loopback:8536 listening (proxy_http_bal2)
server loopback:8537 listening (proxy_http_balancer)
server loopback:8538 listening (cve_2011_3368_rewrite)
server loopback:8539 listening (proxy_http_reverse)
server loopback:8540 listening (cve_2011_3368)
server loopback:8541 listening (mod_headers)
server loopback:8542 listening (error_document)
server loopback:8543 listening (http_strict)
server loopback:8544 listening (mod_vhost_alias)
server loopback:8545 listening (mod_include)
server loopback:8546 listening (proxy_http_https)
server loopback:8547 listening (proxy_https_https)
server loopback:8548 listening (proxy_https_http)
[ info] adding source lib /data/prj/apache/httpd/test/Apache-Test/lib to
@INC
t/apache/404.t .. ok
t/apache/acceptpathinfo.t ... ok
...
t/ssl/env.t . ok
t/ssl/extlookup.t ... 1/4 # Failed test 2 in
t/ssl/extlookup.t at line 27
t/ssl/extlookup.t ... Failed 1/4 subtests
t/ssl/fakeauth.t ok
t/ssl/headers.t . ok
t/ssl/http.t ok
t/ssl/pr12355.t . ok
t/ssl/pr43738.t . ok
t/ssl/proxy.t ... skipped: cannot find module
'mod_proxy', cannot find module 'proxy_http.c'
t/ssl/require.t . 2/10 # Failed test 9 in
t/ssl/require.t at line 44
t/ssl/require.t . Failed 1/10 subtests
t/ssl/v2.t .. ok
t/ssl/varlookup.t ... ok
t/ssl/verify.t .. ok
Test Summary Report
---
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 2
t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 1)
Failed test: 9
Files=109, Tests=3503, 533 wallclock secs ( 4.66 usr 0.47 sys + 161.53
cusr 73.62 csys = 240.28 CPU)
Result: FAIL
Failed 2/109 test programs. 2/3503 subtests failed.
[warning] server loopback:8529 shutdown
[warning] port 8529 still in use...
..done
[ error] error running tests (please examine t/logs/error_log)
On Thu, Aug 7, 2014 at 6:05 PM, Michael Felt wrote:
> Actually, there are more files involved - if you read the CHANGES you
> might understand. So, here is a tar file with everything.
>
> As a zip file, because my mailer refuses the .tar file
>
>
>
> On Thu, Aug 7, 2014 at 5:43 PM, Michael Felt wrote:
>
>> Made updates to the wiki - and, although probably too late for 2.2.28
>> release - please review this patch for build/aix stuff. Who knows, if/when
>> a 2.2.29 release ever comes these will be there too.
>>
>> p.s. starting test run for trunk (aka 2.2.28)
>>
>> p.p.s. The idea is that the CHANGES file be added in build/aix. If that
>> is a sin of some sort, please just appe
Re: testing apache
Made updates to the wiki - and, although probably too late for 2.2.28 release - please review this patch for build/aix stuff. Who knows, if/when a 2.2.29 release ever comes these will be there too. p.s. starting test run for trunk (aka 2.2.28) p.p.s. The idea is that the CHANGES file be added in build/aix. If that is a sin of some sort, please just append to build/aix/README.aix I will see what it becomes when trunk is updated. On Thu, Aug 7, 2014 at 9:08 AM, Michael Felt wrote: > I already have a login. I have a problem with writing in wiki's - never > satisfied with how I put it there, but I shall add/update the info I know. > > > On Wed, Aug 6, 2014 at 2:40 PM, Eric Covener wrote: > >> On Wed, Aug 6, 2014 at 8:37 AM, Michael Felt wrote: >> > The good news: >> > All tests successful. >> > Files=109, Tests=4763, 645 wallclock secs ( 5.69 usr 0.51 sys + 175.37 >> cusr >> > 113.07 csys = 294.64 CPU) >> > Result: PASS >> > >> > How: tested on AIX 7.1 with a more modern perl version. There is one >> > sub-module (Test::Try if i recall correctly) - that demands perl 5.10 >> as a >> > minimum. So without that there are probably several perl modules that >> are >> > not sufficient for the tests to be processed correctly) >> > >> > For now I am just going to be happy with: All tests successful. ... >> Result: >> > PASS >> > >> >> Can you take a pass through https://wiki.apache.org/httpd/AIXPlatform >> while it's still fresh? You may have to register a nickname there and >> then ask for write access (spam problems >> > > httpd-buildaix-CHANGES.new Description: Binary data httpd-buildaix-20140807.patch Description: Binary data
Re: testing apache
I already have a login. I have a problem with writing in wiki's - never satisfied with how I put it there, but I shall add/update the info I know. On Wed, Aug 6, 2014 at 2:40 PM, Eric Covener wrote: > On Wed, Aug 6, 2014 at 8:37 AM, Michael Felt wrote: > > The good news: > > All tests successful. > > Files=109, Tests=4763, 645 wallclock secs ( 5.69 usr 0.51 sys + 175.37 > cusr > > 113.07 csys = 294.64 CPU) > > Result: PASS > > > > How: tested on AIX 7.1 with a more modern perl version. There is one > > sub-module (Test::Try if i recall correctly) - that demands perl 5.10 > as a > > minimum. So without that there are probably several perl modules that are > > not sufficient for the tests to be processed correctly) > > > > For now I am just going to be happy with: All tests successful. ... > Result: > > PASS > > > > Can you take a pass through https://wiki.apache.org/httpd/AIXPlatform > while it's still fresh? You may have to register a nickname there and > then ask for write access (spam problems >
Re: testing apache
The good news:
All tests successful.
Files=109, Tests=4763, 645 wallclock secs ( 5.69 usr 0.51 sys + 175.37
cusr 113.07 csys = 294.64 CPU)
Result: PASS
How: tested on AIX 7.1 with a more modern perl version. There is one
sub-module (Test::Try if i recall correctly) - that demands perl 5.10 as a
minimum. So without that there are probably several perl modules that are
not sufficient for the tests to be processed correctly)
For now I am just going to be happy with: All tests successful. ... Result:
PASS
On Tue, Aug 5, 2014 at 7:44 PM, Michael Felt wrote:
> Anyway - trying to learn howto work with test.
>
> server loopback:8552 listening (proxy_https_http)
> t/apache/server_name_portCan't call method "parse" on an undefined
> value at (eval 18) line 1.
> t/apache/server_name_portdubious
>
> Test returned status 255 (wstat 65280, 0xff00)
> DIED. FAILED tests 1-84
> Failed 84/84 tests, 0.00% okay
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
>
> ---
> t/apache/server_name_port.t 255 6528084 168 200.00% 1-84
> Failed 1/1 test scripts, 0.00% okay. 84/84 subtests failed, 0.00% okay.
>
>
> Cannot find anything in t/errors/log related to the test - even though
> there are 389 lines generated in the error_log
>
> perl is not my strong suit.
>
> in t/apache/server_port_name.t the only code I find with 'parse; in it is:
>
> my $response = HTTP::Response->parse($response_data);
> if (! defined $response) {
> die "HTTP::Response->parse failed";
> }
>
> This does not look like line 1 either. Neither does it look like line 18
> (whatever eval 18 means).
>
> Lastly, why is it counting double?
>
>
> On Tue, Aug 5, 2014 at 4:29 PM, Michael Felt wrote:
>
>> Anyway, I figured out a way to get it to load and run the tests with a
>> newer version of ssl (0.9.8za) compared to an AIX build version from 2009.
>>
>> Not as big a difference as I had hoped - just 5 tests better in
>> t/ssl/proxy.t
>>
>> So, curious if others working with AIX are showing similiar errors as I
>> am - or if I need to look more carefully at how I am building for AIX.
>> NEW SSL (openssl.0.9.8.za) results
>>
>> Failed Test Stat Wstat Total Fail Failed List of Failed
>>
>> ---
>> t/apache/server_name_port.t 255 6528084 168 200.00% 1-84
>> t/modules/proxy.t 172 11.76% 9-10
>> t/protocol/echo.t255 65280 8 16 200.00% 1-8
>> t/protocol/nntp-like.t 255 6528010 20 200.00% 1-10
>> t/security/CVE-2005-2700.t 21 50.00% 1
>> t/security/CVE-2009-3555.t 255 65280 48 200.00% 1-4
>> t/ssl/basicauth.t 32 66.67% 2-3
>> t/ssl/env.t 30 23 76.67% 1-8 16-30
>> t/ssl/extlookup.t 44 100.00% 1-4
>> t/ssl/fakeauth.t 32 66.67% 2-3
>> t/ssl/headers.t33 100.00% 1-3
>> t/ssl/pr12355.t 108 80.00% 1-8
>> t/ssl/pr43738.t44 100.00% 1-4
>> t/ssl/proxy.t172 113 65.70% 60-172
>> t/ssl/require.t 105 50.00% 2 5-7 9
>> t/ssl/varlookup.t 73 73 100.00% 1-73
>> t/ssl/verify.t 31 33.33% 2
>> 17 tests and 40 subtests skipped.
>> Failed 17/109 test scripts, 84.40% okay. 347/4661 subtests failed, 92.56%
>> okay.
>>
>> OLD openssl results
>> openssl.base0.9.8.1101C FOpen Secure Socket
>> Layer
>>
>> Failed Test Stat Wstat Total Fail Failed List of Failed
>>
>> ---
>> t/apache/server_name_port.t 255 6528084 168 200.00% 1-84
>> t/modules/proxy.t 172 11.76% 9-10
>> t/protocol/echo.t255 65280 8 16 200.00% 1-8
>> t/protocol/nntp-like.t 255 6528010 20 200.00% 1-10
>> t/security/CVE-2005-2700.t 21 50.00% 1
>> t/security/CVE-2009-3555.t 255 65280 48 200.00% 1-4
>> t/ssl/basicauth.t 32 66.67% 2-3
>> t/ssl/env.t 30 23 76.67% 1-8 16-30
>> t/ssl/extlookup.t
Re: testing apache
Anyway - trying to learn howto work with test.
server loopback:8552 listening (proxy_https_http)
t/apache/server_name_portCan't call method "parse" on an undefined
value at (eval 18) line 1.
t/apache/server_name_portdubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-84
Failed 84/84 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/apache/server_name_port.t 255 6528084 168 200.00% 1-84
Failed 1/1 test scripts, 0.00% okay. 84/84 subtests failed, 0.00% okay.
Cannot find anything in t/errors/log related to the test - even though
there are 389 lines generated in the error_log
perl is not my strong suit.
in t/apache/server_port_name.t the only code I find with 'parse; in it is:
my $response = HTTP::Response->parse($response_data);
if (! defined $response) {
die "HTTP::Response->parse failed";
}
This does not look like line 1 either. Neither does it look like line 18
(whatever eval 18 means).
Lastly, why is it counting double?
On Tue, Aug 5, 2014 at 4:29 PM, Michael Felt wrote:
> Anyway, I figured out a way to get it to load and run the tests with a
> newer version of ssl (0.9.8za) compared to an AIX build version from 2009.
>
> Not as big a difference as I had hoped - just 5 tests better in
> t/ssl/proxy.t
>
> So, curious if others working with AIX are showing similiar errors as I am
> - or if I need to look more carefully at how I am building for AIX.
> NEW SSL (openssl.0.9.8.za) results
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
>
> ---
> t/apache/server_name_port.t 255 6528084 168 200.00% 1-84
> t/modules/proxy.t 172 11.76% 9-10
> t/protocol/echo.t255 65280 8 16 200.00% 1-8
> t/protocol/nntp-like.t 255 6528010 20 200.00% 1-10
> t/security/CVE-2005-2700.t 21 50.00% 1
> t/security/CVE-2009-3555.t 255 65280 48 200.00% 1-4
> t/ssl/basicauth.t 32 66.67% 2-3
> t/ssl/env.t 30 23 76.67% 1-8 16-30
> t/ssl/extlookup.t 44 100.00% 1-4
> t/ssl/fakeauth.t 32 66.67% 2-3
> t/ssl/headers.t33 100.00% 1-3
> t/ssl/pr12355.t 108 80.00% 1-8
> t/ssl/pr43738.t44 100.00% 1-4
> t/ssl/proxy.t172 113 65.70% 60-172
> t/ssl/require.t 105 50.00% 2 5-7 9
> t/ssl/varlookup.t 73 73 100.00% 1-73
> t/ssl/verify.t 31 33.33% 2
> 17 tests and 40 subtests skipped.
> Failed 17/109 test scripts, 84.40% okay. 347/4661 subtests failed, 92.56%
> okay.
>
> OLD openssl results
> openssl.base0.9.8.1101C FOpen Secure Socket Layer
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
>
> ---
> t/apache/server_name_port.t 255 6528084 168 200.00% 1-84
> t/modules/proxy.t 172 11.76% 9-10
> t/protocol/echo.t255 65280 8 16 200.00% 1-8
> t/protocol/nntp-like.t 255 6528010 20 200.00% 1-10
> t/security/CVE-2005-2700.t 21 50.00% 1
> t/security/CVE-2009-3555.t 255 65280 48 200.00% 1-4
> t/ssl/basicauth.t 32 66.67% 2-3
> t/ssl/env.t 30 23 76.67% 1-8 16-30
> t/ssl/extlookup.t 44 100.00% 1-4
> t/ssl/fakeauth.t 32 66.67% 2-3
> t/ssl/headers.t33 100.00% 1-3
> t/ssl/pr12355.t 108 80.00% 1-8
> t/ssl/pr43738.t44 100.00% 1-4
> t/ssl/proxy.t172 118 68.60% *3-7* 60-172
> t/ssl/require.t 105 50.00% 2 5-7 9
> t/ssl/varlookup.t 73 73 100.00% 1-73
> t/ssl/verify.t 31 33.33% 2
> 17 tests and 40 subtests skipped.
> Failed 17/109 test scripts, 84.40% okay. 352/4661 subtests failed, 92.45%
> okay.
>
>
> On Mon, Aug 4, 2014 at 6:05 PM, Michael Felt wrote:
>
>> So, I figured out how to make a new libssl and libcrypt - as a way to
>> "fix" a lot of failed tests, and as I would rather leave the original files
>&g
Re: testing apache
Anyway, I figured out a way to get it to load and run the tests with a newer version of ssl (0.9.8za) compared to an AIX build version from 2009. Not as big a difference as I had hoped - just 5 tests better in t/ssl/proxy.t So, curious if others working with AIX are showing similiar errors as I am - or if I need to look more carefully at how I am building for AIX. NEW SSL (openssl.0.9.8.za) results Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/server_name_port.t 255 6528084 168 200.00% 1-84 t/modules/proxy.t 172 11.76% 9-10 t/protocol/echo.t255 65280 8 16 200.00% 1-8 t/protocol/nntp-like.t 255 6528010 20 200.00% 1-10 t/security/CVE-2005-2700.t 21 50.00% 1 t/security/CVE-2009-3555.t 255 65280 48 200.00% 1-4 t/ssl/basicauth.t 32 66.67% 2-3 t/ssl/env.t 30 23 76.67% 1-8 16-30 t/ssl/extlookup.t 44 100.00% 1-4 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/headers.t33 100.00% 1-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t44 100.00% 1-4 t/ssl/proxy.t172 113 65.70% 60-172 t/ssl/require.t 105 50.00% 2 5-7 9 t/ssl/varlookup.t 73 73 100.00% 1-73 t/ssl/verify.t 31 33.33% 2 17 tests and 40 subtests skipped. Failed 17/109 test scripts, 84.40% okay. 347/4661 subtests failed, 92.56% okay. OLD openssl results openssl.base0.9.8.1101C FOpen Secure Socket Layer Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/server_name_port.t 255 6528084 168 200.00% 1-84 t/modules/proxy.t 172 11.76% 9-10 t/protocol/echo.t255 65280 8 16 200.00% 1-8 t/protocol/nntp-like.t 255 6528010 20 200.00% 1-10 t/security/CVE-2005-2700.t 21 50.00% 1 t/security/CVE-2009-3555.t 255 65280 48 200.00% 1-4 t/ssl/basicauth.t 32 66.67% 2-3 t/ssl/env.t 30 23 76.67% 1-8 16-30 t/ssl/extlookup.t 44 100.00% 1-4 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/headers.t33 100.00% 1-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t44 100.00% 1-4 t/ssl/proxy.t172 118 68.60% *3-7* 60-172 t/ssl/require.t 105 50.00% 2 5-7 9 t/ssl/varlookup.t 73 73 100.00% 1-73 t/ssl/verify.t 31 33.33% 2 17 tests and 40 subtests skipped. Failed 17/109 test scripts, 84.40% okay. 352/4661 subtests failed, 92.45% okay. On Mon, Aug 4, 2014 at 6:05 PM, Michael Felt wrote: > So, I figured out how to make a new libssl and libcrypt - as a way to > "fix" a lot of failed tests, and as I would rather leave the original files > in /usr/lib and add new ones in /opt/lib - what flag am I missing (and > should I have asked this in "users") so the the modules ALSO use the same > LIBPATH. I would have expected them to have the same as the core. > core uses: /opt/lib:/usr/vac/lib:/usr/lib:/lib > as expected while the modules (more specifically, mod_ssl) does not look > /opt/lib at all! > mod_ssl.so uses: /usr/include/openssl/lib:/usr/vac/lib:/usr/lib:/lib > Note: there is no such directory /usr/include/openssl/lib - configure (or > libtool) seems to be inventing that. > > DUMP comand output - complete. > > root@x093:[/]dump -H /opt/httpd/sbin/httpd > > /opt/httpd/sbin/httpd: > > ***Loader Section*** > Loader Header Information > VERSION# #SYMtableENT #RELOCentLENidSTR > 0x0001 0x041e 0x0c88 0x0095 > > #IMPfilIDOFFidSTR LENstrTBLOFFstrTBL > 0x0007 0xf950 0x54dc 0xf9e5 > > > ***Import File Strings*** > INDEX PATH BASE > MEMBER > 0 > /opt/lib:/usr/vac/lib:/usr/lib:/lib > 1libpcre.a > libpcre.so.1 > 2 > libaprutil-1.so > 3 > libapr-1.so > 4libpthread.a > shr_xpg5.o > 5libc.a > shr.o > 6
