Re: svn commit: 1573360 - SSLPassPhraseDialog arguments changed in 2.4.x
On 04/12/2014 12:37 PM, Kaspar Brand wrote: [picking this up from the comment in Re: svn commit: r1585902 - ...] On 09.04.2014 21:56, Jeff Trawick wrote: IMO this needs to be reworked to restore compatibility for 2.x up through 2.4.7, with the new interface used if some new keyword is added on the directive. Yeah, some people who reworked their scripts will have to add that new keyboard, but this will unblock others (vendors, distros, individuals) from upgrading without surprise. We can partly restore the argument structure for exec-type programs, but effectively, lifting the limit of 2 (or 3) certs per SSL host means that there's no longer a reliable way of determining if we are actually loading an RSA, DSA, or ECC key when calling the SSLPassPhraseDialog program. It would be useful to have the same arguments as before, but if that's not possible to do in all cases now, I would say just increasing the arguments count won't help anything. One option for improving backward compatibility with existing SSLPassPhraseDialog programs could consist of keeping the two-argument structure (servername:portnumber and index), and to replace the indexes 0 through 2 with the RSA, DSA, and ECC strings, respectively, as illustrated by the attached patch (quickly hacked up PoC). I will check the patch. I have some patch here too, but it's not ready yet (found that after some more testing during weekend...). The primary question is on what arguments existing passphrase handling programs are specifically relying - i.e. if it's mostly about only having servername:portnumber in the first argument, or whether the accuracy of RSA/DSA/ECC is equally important. I have already asked the original reporter of this incompatibility, but I have not received the answer yet. I will try to ask him again and will write an email if I get the response this time. My guess is that they are just using that second argument in the script and since the argument is not here, the script is failing now. I don't think it's used for anything more important than that, but I have no clue right now. Anyway, would you merge your documentation patch with httpd-2.4 with the mention it changed in 2.4.9? Kaspar Jan Kaluza
Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
(not to say there aren't complications, like trying to keep system directories out of rpath) -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
I usually force it with ./configure LDFLAGS=-Wl,-rpath -Wl,/path/to/my/openssl. +1 to have this automagically done according to --with-ssl. On Mon, Apr 14, 2014 at 1:08 PM, Jeff Trawick traw...@gmail.com wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate Transparency as a separate mod
On Sat, Apr 12, 2014 at 09:00:08AM -0400, Jeff Trawick wrote: So... Concerns? Suggestions? Etc.? Speak up, or forever* ask me to fix it after committing ;) (*Let's not be ridiculous though) Interesting stuff! I do think it is preferable to keep mod_ssl.h toolkit-agnostic. Because the API you are adding is not indended to be private, I'd suggest mod_ssl_openssl.h or something like that instead. Regards, Joe
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 04/14/2014 07:08 AM, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) I think that you're asking for mod_ssl to add an openssl-specific directory to its rpath. in general, i would discourage this; at the least, it needs to be an option that can be easily disabled during ./configure -- libssl and libcrypto should be in the usual system library path, and hard-coding a specific location makes system maintenance unpredictable and more difficult than it needs to be. For a decent overview of the problems with rpath from a distro's perspective: https://wiki.debian.org/RpathIssue Regards, --dkg signature.asc Description: OpenPGP digital signature
Re: The SERVER_ADDR environment variable
On Fri, Apr 11, 2014 at 10:55 PM, Reindl Harald h.rei...@thelounge.netwrote: simply list getenv in disable_functions, put ?php $_SERVER['SERVER_ADDR']='';? in a file listed in auto_prepend_file and you are done, no need to touch httpd for that and in case of security by obscurity allow to remove the Server header and hide what webserver you are running would have more benefit This is basically what I'm doing now, though from a PHP C extension (didn't know about auto_prepend_file). Having a switch in Apache would allow a language-agnostic solution though.
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate Transparency as a separate mod
On 14 Apr 2014, at 2:03 PM, Joe Orton jor...@redhat.com wrote: Interesting stuff! I do think it is preferable to keep mod_ssl.h toolkit-agnostic. +1. Because the API you are adding is not indended to be private, I'd suggest mod_ssl_openssl.h or something like that instead. Pass what you need as DER encoded structures, that way can can swap backends and they will still work. Regards, Graham --
Facing pass request body failed to X.X.X.X:8080 from Y.Y.Y.Y () . Urgent assistance required
Hi Team, I am using Apache 2.2.20 version , I am facing major problem in APache is below error my application server(Oracle weblogic ) and it is connecting to Apache 7443 and based on routing it is rewiriting to another apache instance apache on 8080 from here to back end server i.e to OSB O am receiving error at first Apache server i.e 7443 only Application flow Weblogic App serve--Apache 7443--Apache-8080--- OSB back end request is not going to OSB at all i m receiving below error pass request body failed to X.X.X.X:8080 from Y.Y.Y.Y () Please help me . it is show stopper for my application Regards, Bala
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Mon, Apr 14, 2014 at 8:04 AM, Daniel Kahn Gillmor d...@fifthhorseman.netwrote: On 04/14/2014 07:08 AM, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) I think that you're asking for mod_ssl to add an openssl-specific directory to its rpath. in general, i would discourage this; at the least, it needs to be an option that can be easily disabled during ./configure -- libssl and libcrypto should be in the usual system library path, and hard-coding a specific location makes system maintenance unpredictable and more difficult than it needs to be. For a decent overview of the problems with rpath from a distro's perspective: https://wiki.debian.org/RpathIssue Regards, --dkg We already add rpaths for other libraries in non-standard places (I guess that comes for free with libtool). We wouldn't add rpath to a system directory. I've been all over that document and a bunch of others when needing to remove rpath on various platforms for particular distribution requirements. But that's a different, much smaller group of people than a normal admin/user specifying --with-ssl= and then running into further complications, such as not picking up the expected (fixed) library. A --disable-rpath option would be awesome if indeed it would do that generally. -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Facing pass request body failed to X.X.X.X:8080 from Y.Y.Y.Y () . Urgent assistance required
On Mon, Apr 14, 2014 at 8:17 AM, HBalakrishna hbalakris...@yahoo.com wrote: request is not going to OSB at all i m receiving below error pass request body failed to X.X.X.X:8080 from Y.Y.Y.Y () This is a development list. You don't have a development issue. http://httpd.apache.org/lists.html#http-users
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate Transparency as a separate mod
On Mon, Apr 14, 2014 at 8:03 AM, Joe Orton jor...@redhat.com wrote: On Sat, Apr 12, 2014 at 09:00:08AM -0400, Jeff Trawick wrote: So... Concerns? Suggestions? Etc.? Speak up, or forever* ask me to fix it after committing ;) (*Let's not be ridiculous though) Interesting stuff! I do think it is preferable to keep mod_ssl.h toolkit-agnostic. Because the API you are adding is not indended to be private, I'd suggest mod_ssl_openssl.h or something like that instead. I'll do that. FWIW, I think it is reasonable to say This *is* a private mod_ssl interface for the purposes of introducing some modularity within this particular SSL/TLS implementation, and these interfaces aren't intended for third-party modules. That's not how I coded it, but now that somebody has actually looked I'm curious about your thoughts. Regards, Joe -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate Transparency as a separate mod
On Mon, Apr 14, 2014 at 8:14 AM, Graham Leggett minf...@sharp.fm wrote: On 14 Apr 2014, at 2:03 PM, Joe Orton jor...@redhat.com wrote: Interesting stuff! I do think it is preferable to keep mod_ssl.h toolkit-agnostic. +1. Because the API you are adding is not indended to be private, I'd suggest mod_ssl_openssl.h or something like that instead. Pass what you need as DER encoded structures, that way can can swap backends and they will still work. Pragmatically, what I need is to make OpenSSL calls at certain points (e.g., augment the type of setup that mod_ssl is doing). I'm not in a position (i.e., many days with nothing to do) to create enough generic interfaces to allow arbitrary mod_foo+FooSSL to implement CT. The generic TLS extension APIs submitted earlier were just a start, and even those needed additional work. Regards, Graham -- -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: svn commit: r1587075 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c
Cool... How much, if any, is applicable for backporting to 2.4.x? Obviously, the leaking stuff doesn't appear to be a candidate :)
Re: mod_cache thundering herd bug
r1023398 for 2.2: http://people.apache.org/~covener/patches/httpd-2.2.x-thunder.diff The remove_url() prevents other threads from serving a stale cached file during refresh of a slow response, but it's unnecessary to have a separate path because the refresh has to deal with 200s already. When the remove_url was added, there as no thundering herd lock / no ability to serve stale content while one guy was reloading. covener, mrumph, and I looked at this today at ApacheCon. I updated the bug with some comments and attached this patch. https://issues.apache.org/bugzilla/show_bug.cgi?id=50317 Hello, Thank You very much for the patch but*it doesn't works*. When I'm doing ab (/usr/bin/ab -k -c 5 -n 10http://host/url) test the application get more than one request 1.1.1.1 - - [14/Apr/2014:14:01:58 +0200] GET /url HTTP/1.0 200 42398 9A68DBA96CED90DC517F7D6302F5A748.gpi-app1 1163 1163 1.1.1.1 - - [14/Apr/2014:14:02:05 +0200] GET /url HTTP/1.0 200 42398 D378685BBD4FB87C63A3A867ABFAFB3E.gpi-app1 2931 2930 1.1.1.1 - - [14/Apr/2014:14:02:05 +0200] GET /url HTTP/1.0 200 42398 8B77A0C68FC6F16E0BA3A89C7A614E1A.gpi-app1 2992 2991 1.1.1.1 - - [14/Apr/2014:14:02:05 +0200] GET /url HTTP/1.0 200 42398 57A48B49FB6C52E28F1FA97DDFCDC0C8.gpi-app1 3007 3006 1.1.1.1 - - [14/Apr/2014:14:02:05 +0200] GET /url HTTP/1.0 200 42398 71573080388181B3C55E88CB4BFAB890.gpi-app1 3051 3051 1.1.1.1 - - [14/Apr/2014:14:02:06 +0200] GET /url HTTP/1.0 200 42398 38DA8533D4F9B4046A2F607071652E94.gpi-app1 1412 1412 Here are more information how to reproduce it. *Compilation* cd /tmp svn cohttp://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x cd 2.2.x/ svn cohttp://svn.apache.org/repos/asf/apr/apr/branches/1.4.x srclib/apr svn cohttp://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x srclib/apr-util ./buildconf ./configure --prefix=/etc/httpd --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --mandir=/usr/share/man --libdir=/usr/lib64 --sysconfdir=/etc/httpd/conf --includedir=/usr/include/httpd --libexecdir=/usr/lib64/httpd/modules --datadir=/var/www --with-installbuilddir=/usr/lib64/httpd/build --with-mpm=prefork --with-apr=/usr --with-apr-util=/usr --enable-suexec --with-suexec --with-suexec-caller=apache --with-suexec-docroot=/var/www --with-suexec-logfile=/var/log/httpd/suexec.log --with-suexec-bin=/usr/sbin/suexec --with-suexec-uidmin=500 --with-suexec-gidmin=100 --enable-pie --with-pcre --enable-mods-shared=all --enable-ssl --with-ssl --enable-proxy --enable-cache --enable-disk-cache --enable-ldap --enable-authnz-ldap --enable-cgid --enable-authn-anon --enable-authn-alias --disable-imagemap patch -p0 /root/rpmbuild/SOURCES/httpd-2.2.x-thunder.patch make make install *Configuration** * VirtualHost host:80 ... ... ## Cache CacheRoot /tmp/cache CacheEnable disk / CacheDisable /static/ CacheMinFileSize 0 CacheMaxFileSize 1048576 CacheDirLevels 2 CacheDirLength 2 CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders ETag Set-Cookie Header unset Expires Header unset Cache-Control Header always set Cache-Control max-age=30,stale-while-revalidate=15 /VirtualHost Best Regards Maciej Bogucki
Re: svn commit: r1587075 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c
On Mon, Apr 14, 2014 at 8:49 AM, Jim Jagielski j...@jagunet.com wrote: Cool... How much, if any, is applicable for backporting to 2.4.x? Obviously, the leaking stuff doesn't appear to be a candidate :) The error handlng, POLLHUP, and directive for the non-infinite poll should go to 2.4.x. I hope to revisit midweek. Probably do not merge in very well. I also have an event update for the socket callbacks w/ an associated timeout (timer event) that seems to work w/ wstunnel, but not polished.
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 2014-04-14 13:08, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) On FreeBSD it is possible that a user has openssl 0.9.x or 1.0.x in the base OS (/usr/lib) but installs openssl 1.x.x from the ports system (/usr/local/lib). The OpenSSL version used to build third party applications like apache is then controlled via a flag in /etc/make.conf.
Re: Configuration error handling after httpd restart
Hello Jim, Thanks for taking a look at this and providing a patch for case 2 (duplicate Listen directives). I will need to evaluate this patch in more detail. Your approach of simply ignoring duplicate Listen directives with a warning seems reasonable. At least in the simple case that I listed. But it does cause a change in behavior for apachectl -k start as well as apachectl -k restart. Is this acceptable? The same approach could be taken for case 1. If there is an unknown directive in the config file, simply ignore it with a warning. Does anyone else have an opinion on this? There are also underlying issues that are bypassed by your fix. Other more complicated test cases may uncover these again. I hope to have some time to investigate these issues and do further negative testing. Thanks, Mike On 4/11/2014 10:43 AM, Jim Riggs wrote: On 27 Mar 2014, at 14:16, Mike Rumph mike.ru...@oracle.com wrote: Hello all, I have been doing some testing on the results of httpd restart with configuration errors. This gave me some interesting results. For these tests I build httpd trunk with APR trunk on Linux using the following configure: $ ./configure --prefix=/home/mrumph/apache25 --with-included-apr --with-mpm=worker --enable-mpms-shared='worker' Modify the default httpd.conf to include the following line: Listen localhost:8080 Start the httpd server and verify the process information. $ bin/apachectl -k start $ ps -ef | grep -i httpd Now restart httpd from this starting point with the following configuration error cases: Case 1: An unknown directive. Add the following line to the httpd.conf file. Xyzzy bin/apachectl -k restart - Returns with exit code 1 and following error message in stderr: AH00526: Syntax error on line 198 of /home/mrumph/apache25/conf/httpd.conf: Invalid command 'Xyzzy', perhaps misspelled or defined by a module not included in the server configuration httpd: abnormal exit 1 $ ps -ef | grep -i httpd - The httpd server was not stopped and all of the previous processes remain. - And the logs/httpd.pid file remains intact. $ tail logs/error_log - No error message logged. Case 2: A duplicate Listen directive. Duplicate the Listen directive in the httpd.conf file. Listen localhost:8080 Listen localhost:8080 $ bin/apachectl -k restart - Returns with exit code 0 and no error message in stderr. - So the httpd server appears to be working at this point. - (But appearances are deceiving.) $ ps -ef | grep -i httpd - All of the httpd processes have stopped. - But the logs/httpd.pid file remains intact. $ tail logs/error_log [Thu Mar 27 11:26:22.836887 2014] [mpm_worker:notice] [pid 2677:tid 47577479346656] AH00298: SIGHUP received. Attempting to restart (98)Address already in use: AH00072: make_sock: could not bind to address 127.0.0.1:8080 [Thu Mar 27 11:26:22.844003 2014] [mpm_worker:alert] [pid 2677:tid 47577479346656] no listening sockets available, shutting down [Thu Mar 27 11:26:22.844031 2014] [core:emerg] [pid 2677:tid 47577479346656] AH00019: Unable to open logs, exiting This was httpd trunk, but similar results are seen with httpd 2.2.22, 2.2-HEAD and 2.4.6. Before working on this as a bug, I am trying to understand what should be the correct behavior. I think case 1 is working correctly. But case 2 doesn't seem quite right. First of all, it doesn't seem correct to have an httpd.pid file when all of the httpd processes have vanished. Secondly, it would be nice to see an error code from the apachectl -k restart. (But this is probably due to a different processing phase in the validation for both of the cases.) It is also a little strange to see a message Unable to open logs in the log. Does anyone have some opinions what the correct behavior should be for these cases. If there are some actual bugs here, I have some time available to work on them. Check out the attached patch to ignore duplicate Listen directives.
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate Transparency as a separate mod
On Mon, Apr 14, 2014 at 08:32:18AM -0400, Jeff Trawick wrote: FWIW, I think it is reasonable to say This *is* a private mod_ssl interface for the purposes of introducing some modularity within this particular SSL/TLS implementation, and these interfaces aren't intended for third-party modules. That's not how I coded it, but now that somebody has actually looked I'm curious about your thoughts. Hmmm, I think the only distinction that matters is whether it's in a header installed by make install. I don't think we can successfully hide private APIs in public headers, modules will use them regardless of the here be dragons comments - or e.g. CORE_PRIVATE! Regards, Joe
Re: Configuration error handling after httpd restart
On Thu, Mar 27, 2014 at 4:16 PM, Mike Rumph mike.ru...@oracle.com wrote: - And the logs/httpd.pid file remains intact. I noticed this once, IIRC if the 2nd pass of post-config returns an error, the pidfile is not cleaned up. Modules like to cheat and only do their work in the 2nd pass. -- Eric Covener cove...@gmail.com
Re: Configuration error handling after httpd restart
On Mon, Apr 14, 2014 at 11:15 AM, Mike Rumph mike.ru...@oracle.com wrote: If there is an unknown directive in the config file, simply ignore it with a warning. You can't do that. What if it was Reqiure?
Re: Configuration error handling after httpd restart
On 14 Apr 2014, at 10:38, Eric Covener cove...@gmail.com wrote: On Mon, Apr 14, 2014 at 11:15 AM, Mike Rumph mike.ru...@oracle.com wrote: If there is an unknown directive in the config file, simply ignore it with a warning. You can't do that. What if it was Reqiure? I agree with Eric. I would not want unknown directives to be ignored. It might be a typo of a really important directive like Eric describes. Or, what if a module I really, really need is accidentally disabled and we just ignore all of its directives? Not good. In this particular case, duplicating a Listen directive doesn't seem like it should bomb out the server. Listen 80 ... Listen 80 It's superfluous, but not really a critical error. So, my patch just ignores subsequent duplicate Listens.
Zombies from rotatelogs
I was taking a look at a server that had a handful of zombies and came to see they are caused by rotatelogs. It seems pretty straight forward why - I am calling gzip post-rotate to compress the log file and child cleanup only happens during the post_rotate function, but before apr_proc_create for this rotation. So, effectively, you will have a zombie process from time_child_dies to next_rotation. I would like to get rid of those zombie processes sooner but am wary to call apr_proc_wait_all_procs very often... I don't know what the expense of doing that would be. So... I'm seeking advice for the best option here: *Call apr_proc_wait_all_procs in the main loop (expensive?) *Spawn a thread on the side to reap the child a la blocking mode *Check an interval in the main loop to call apr_proc_wait_all_procs once per X time *or... your idea Thanks P.S. ApacheCon was a blast - can't wait until next one! -- Daniel Ruggeri
Re: Configuration error handling after httpd restart
Since this is up for discussion anyway, what if there was an option to set a directive as ignore-able. For example, PHP allows you to preface a function with `@` to ignore errors (http://www.php.net/manual/en/language.operators.errorcontrol.php). That way, if you restart and the error is Invalid command 'Xyzzy',, you could make the decision to ignore it. I am not sure how useful this would be in practice. The only thing that comes to mind is with a module like mod_auth_mysql where you could ignore errors about it being missing while still requiring some other type of authentication with satisfy any. - Y On Mon, Apr 14, 2014 at 12:00 PM, Jim Riggs apache-li...@riggs.me wrote: On 14 Apr 2014, at 10:38, Eric Covener cove...@gmail.com wrote: On Mon, Apr 14, 2014 at 11:15 AM, Mike Rumph mike.ru...@oracle.com wrote: If there is an unknown directive in the config file, simply ignore it with a warning. You can't do that. What if it was Reqiure? I agree with Eric. I would not want unknown directives to be ignored. It might be a typo of a really important directive like Eric describes. Or, what if a module I really, really need is accidentally disabled and we just ignore all of its directives? Not good. In this particular case, duplicating a Listen directive doesn't seem like it should bomb out the server. Listen 80 ... Listen 80 It's superfluous, but not really a critical error. So, my patch just ignores subsequent duplicate Listens.
Re: Zombies from rotatelogs
On Mon, Apr 14, 2014 at 11:06:25AM -0500, Daniel Ruggeri wrote: I was taking a look at a server that had a handful of zombies and came to see they are caused by rotatelogs. It seems pretty straight forward why - I am calling gzip post-rotate to compress the log file and child cleanup only happens during the post_rotate function, but before apr_proc_create for this rotation. So, effectively, you will have a zombie process from time_child_dies to next_rotation. I would like to get rid of those zombie processes sooner but am wary to call apr_proc_wait_all_procs very often... I don't know what the expense of doing that would be. So... I'm seeking advice for the best option here: It's free... dunno why I didn't think of this before. http://svn.apache.org/viewvc?view=revisionrevision=1587255 Regards, Joe
Re: Zombies from rotatelogs
On 4/14/2014 11:41 AM, Joe Orton wrote: It's free... dunno why I didn't think of this before. http://svn.apache.org/viewvc?view=revisionrevision=1587255 Regards, Joe Awesome - proposed for backport in 2.4. Thanks! -- Daniel Ruggeri
