mod_security core dumps and r-per_dir_config
I'm trying to investigate some core dumps in mod_security and currently
face this
(gdb) bt
#0 0xf6efc232 in create_tx_context (r=0x1eac8ed0) at mod_security2.c:325
#1 0xf6efc606 in hook_error_log (file=0x80a51bd http_filters.c,
line=493, level=3, status=104, s=0x18144178, r=0x1eac8ed0, mp=0x0,
fmt=0xeb2f6dff Error reading chunk \n)
at mod_security2.c:771
#2 0x08080c2d in ap_run_error_log (file=0x80a51bd http_filters.c,
line=493, level=3, status=104, s=0x18144178, r=0x1eac8ed0, pool=0x0,
errstr=0xeb2f6dff Error reading chunk \n) at log.c:1116
#3 0x0808109b in log_error_core (file=0x80a51bd http_filters.c,
line=493, level=optimized out, status=104, s=0x18144178, c=0x0,
r=0x1eac8ed0, pool=0x0,
fmt=0x80a52a1 Error reading chunk %s , args=0xeb2f8e08
hT\n\b\230L\255\036\177\017\275\036\376\001) at log.c:705
#4 0x08081ec1 in ap_log_rerror (file=0x80a51bd http_filters.c, line=493,
level=3, status=104, r=0x1eac8ed0, fmt=0x80a52a1 Error reading chunk %s )
at log.c:737
#5 0x0808d400 in ap_http_filter (f=0x1eaca3b0, b=0x1eac8eb0,
mode=AP_MODE_READBYTES, block=APR_NONBLOCK_READ, readbytes=8192) at
http_filters.c:493
#6 0xf716bfe6 in ap_proxy_http_process_response (p=0x1eab4cd8,
r=0x1eab4d18, backend=0x9241848, origin=0x929ab40, conf=0x1e8db5e0,
server_portstr=0xeb2fd107 )
at mod_proxy_http.c:1771
#7 0xf716d609 in proxy_http_handler (r=0x1eab4d18, worker=0x13db7be8,
conf=0x1e8db5e0, url=0x1eac8950 /a/b/WebService, proxyname=0x0,
proxyport=optimized out) at mod_proxy_http.c:2037
#8 0xf72daec0 in proxy_run_scheme_handler (r=0x1eab4d18,
worker=0x13db7be8, conf=0x1e8db5e0, url=0x1eac8878
http://10.10.10.10:8080/a/b/WebServicehttp://10.21.9.205:8080/tourconex/services/TourConexWebService,
proxyhost=0x0, proxyport=0) at mod_proxy.c:2455
#9 0xf72dfdbb in proxy_handler (r=0x1eab4d18) at mod_proxy.c:1023
#10 0x0807cdc1 in ap_run_handler (r=0x1eab4d18) at config.c:157
#11 0x080802c6 in ap_invoke_handler (r=0x1eab4d18) at config.c:376
#12 0x0808b6d0 in ap_process_request (r=0x1eab4d18) at http_request.c:282
#13 0x080886e8 in ap_process_http_connection (c=0x1eaaaea8) at
http_core.c:190
#14 0x08084571 in ap_run_process_connection (c=0x1eaaaea8) at
connection.c:43
#15 0x08091aac in process_socket (bucket_alloc=optimized out,
my_thread_num=optimized out, my_child_num=optimized out,
sock=optimized out, p=optimized out)
at worker.c:544
#16 worker_thread (thd=0x1e96ac40, dummy=0x1ea48678) at worker.c:894
#17 0xf7575ac6 in dummy_worker (opaque=0x1e96ac40) at
threadproc/unix/thread.c:142
#18 0xf74fc809 in start_thread () from /lib/libpthread.so.0
#19 0xf745d30e in clone () from /lib/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind
further
(gdb) print r-per_dir_config
$1 = (struct ap_conf_vector_t *) 0x0
where the offending line of code is
msr-dcfg1 = (directory_config *)ap_get_module_config(r-per_dir_config,
security2_module);
Why would the per_dir_config be NULL here ? I don't think that should ever
be encountered during the request's lifetime, right ?
My confusion continued when I saw
(gdb) print *r
$2 = {pool = 0x1eab4cd8, connection = 0x929ab40, server = 0x18144178, next
= 0x0, prev = 0x0, main = 0x0, the_request = 0x0, assbackwards = 0,
proxyreq = 3, header_only = 0,
protocol = 0x0, proto_num = 0, hostname = 0x0, request_time =
1368183918343107, status_line = 0x0, status = 200, method = 0x0,
method_number = 0, allowed = 0,
allowed_xmethods = 0x0, allowed_methods = 0x0, sent_bodyct = 0,
bytes_sent = 0, mtime = 0, chunked = 0, range = 0x0, clength = 0, remaining
= 0, read_length = 0,
read_body = 0, read_chunked = 0, expecting_100 = 0, headers_in =
0x1ebcee40, headers_out = 0x1eac9750, err_headers_out = 0x1eac98f8,
subprocess_env = 0x1eac93e0,
notes = 0x1eac9a50, content_type = 0x0, handler = 0x0, content_encoding =
0x0, content_languages = 0x0, vlist_validator = 0x0, user = 0x0,
ap_auth_type = 0x0, no_cache = 0,
no_local_copy = 0, unparsed_uri = 0x0, uri = 0x0, filename = 0x0,
canonical_filename = 0x0, path_info = 0x0, args = 0x0, finfo = {pool = 0x0,
valid = 0, protection = 0,
filetype = APR_NOFILE, user = 0, group = 0, inode = 0, device = 0,
nlink = 0, size = 0, csize = 0, atime = 0, mtime = 0, ctime = 0, fname =
0x0, name = 0x0,
filehand = 0x0}, parsed_uri = {scheme = 0x0, hostinfo = 0x0, user =
0x0, password = 0x0, hostname = 0x0, port_str = 0x0, path = 0x0, query =
0x0, fragment = 0x0,
hostent = 0x0, port = 0, is_initialized = 0, dns_looked_up = 0,
dns_resolved = 0}, used_path_info = 0, per_dir_config = 0x0, request_config
= 0x1eac9ba8, htaccess = 0x0,
output_filters = 0x929aff8, input_filters = 0x1eaca3b0,
proto_output_filters = 0x929aff8, proto_input_filters = 0x1eaca3b0,
eos_sent = 0}
(gdb) dump_table(r-headers_in)
[0] 'Server'='Apache-Coyote/1.1' [0x1eaca1e0]
[1] 'X-Powered-By'='Servlet 2.4; JBoss-4.2.2.GA (build:
SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5' [0x1eaca218]
[2] 'Content-Type'='text/xml;charset=utf-8'
Re: mod_security core dumps and r-per_dir_config
On 24 May 2013, at 10:38 AM, Thomas Eckert thomas.r.w.eck...@gmail.com wrote: Why would the per_dir_config be NULL here ? I don't think that should ever be encountered during the request's lifetime, right ? I had this recently, and a completely clean rebuild sorted it out. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: mod_security core dumps and r-per_dir_config
How did you investigate into this ? I'll assume with rebuild you mean you rebuilt apache2 from source and reinstalled it. What made you rebuild it in this scenario ? Also, why do you think rebuilding solved it ? I'm being so specific about investigation options since rebuilding and reinstalling it is out of question in my case. I also saw some other issues with the rev-proxy I posted the core dumps for, like core dumps from one of my modules and some really REALLY weird looking core dumps which claimed to originate from system calls. Looking at the time stamps it's clear they are somehow related as they do not even differ in seconds. One of those incidents I relate to an attack on the rev-proxy but the others keep me confused. My best guess is that one process core dumped and took with it at least one other - but I thought this was cared for. I'm talking apache 2.2.22 here and updating it is - unfortunately - also out of question :-/ On Fri, May 24, 2013 at 10:46 AM, Graham Leggett minf...@sharp.fm wrote: On 24 May 2013, at 10:38 AM, Thomas Eckert thomas.r.w.eck...@gmail.com wrote: Why would the per_dir_config be NULL here ? I don't think that should ever be encountered during the request's lifetime, right ? I had this recently, and a completely clean rebuild sorted it out. Regards, Graham --
Re: mod_security core dumps and r-per_dir_config
On 24 May 2013, at 11:03 AM, Thomas Eckert thomas.r.w.eck...@gmail.com wrote: How did you investigate into this ? I'll assume with rebuild you mean you rebuilt apache2 from source and reinstalled it. What made you rebuild it in this scenario ? Yes, in my case the module that was returning NULL for per_dir_config was part of httpd, and a make distclean followed by make all sorted it out. Changes to header files had been made, and I suspect this was part of my specific problem. Also, why do you think rebuilding solved it ? I'm being so specific about investigation options since rebuilding and reinstalling it is out of question in my case. In that case are you 200% sure that the headers you are using to build against match the binaries you are building against? In the Redhat world, headers and binaries are packaged separately, and other OSes are probably similar. Caveat: I am one data point, I recently had the problem, and a rebuild solved it for me. That doesn't mean the problem isn't the same for you. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Unused files in Apache
On 24 May 2013, at 04:14, Eric Covener wrote: On Thu, May 23, 2013 at 11:12 PM, kalyan sita kalyansit...@gmail.com wrote: Hi all, I just came to know that sha2.c is no longer used from Jan Kaluža. Can anyone tell me the list of files that are not used in apache source code. If we had a list, they'd be removed. There's no sha2.c unless the poster is looking at APR. There are areas of libc we never use, either. Or any library. -- Nick Kew
Re: Time for 2.4.5 ??
There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) o Performance-related patches (Event mod_ssl, cache, etc)
Re: Intent to revert commit r1332643
Any news on this? Greetz Am Samstag, 18. Mai 2013 schrieb Jim Jagielski : Please don't submit what could be controversial reverts over a weekend. On May 17, 2013, at 10:36 AM, Guenter Knauf fua...@apache.orgjavascript:; wrote: Hi all, I will revert the changes done with: http://svn.apache.org/viewvc?view=revisionrevision=1332643 after 72 hours if nobody is going to fix the stuff properly for Windows since I'm tired of always copying mod_ssl over from 2.4.x branch in order to get a working mod_ssl with trunk. Reasons: 1) within last 12 months there was no attempt made to fix the issues which wrowe mentioned in this thread [1] - instead discussion died 2) a suggestion to fix the issue [2] was not applied due to the concerns wrowe brought up, and to which I agree. 3) the same issue also causes a stalled backport in 2.2.x STATUS [3] for the last 12 months [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3C20130205115224.33547872@hub%3E [2] http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3c510d8293.8010...@gknw.net%3E [3] http://svn.apache.org/viewvc?view=revisionrevision=1333501 I believe that one year in trunk without further review is long enough, and if someone wants to continue working on it its easy enough to checkout the last revision before removal. Gün.
Re: Intent to revert commit r1332643
On 24 May 2013, at 2:44 PM, Mario Brandt jbl...@gmail.com wrote: Any news on this? Not yet, there is however a big push to get 2.4.5 out the door, which is where the focus is lying at the moment. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Whither Windows (Was: Re: Intent to revert commit r1332643)
Maybe the real question is where exactly do we stand with Windows right now... We haven't had (complimentary) binary builds for Windows in quite awhile and, afaict, there are really no people focusing on Windows compatibility anymore. For me, I wouldn't want to stunt httpd development for every other platform we care about simply because it breaks Windows. But it's not just my decision, 'natch. On May 17, 2013, at 10:36 AM, Guenter Knauf fua...@apache.org wrote: Hi all, I will revert the changes done with: http://svn.apache.org/viewvc?view=revisionrevision=1332643 after 72 hours if nobody is going to fix the stuff properly for Windows since I'm tired of always copying mod_ssl over from 2.4.x branch in order to get a working mod_ssl with trunk. Reasons: 1) within last 12 months there was no attempt made to fix the issues which wrowe mentioned in this thread [1] - instead discussion died 2) a suggestion to fix the issue [2] was not applied due to the concerns wrowe brought up, and to which I agree. 3) the same issue also causes a stalled backport in 2.2.x STATUS [3] for the last 12 months [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3C20130205115224.33547872@hub%3E [2] http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3c510d8293.8010...@gknw.net%3E [3] http://svn.apache.org/viewvc?view=revisionrevision=1333501 I believe that one year in trunk without further review is long enough, and if someone wants to continue working on it its easy enough to checkout the last revision before removal. Gün.
Re: Intent to revert commit r1332643
On Fri, May 17, 2013 at 10:36 AM, Guenter Knauf fua...@apache.org wrote: Hi all, I will revert the changes done with: http://svn.apache.org/viewvc?**view=revisionrevision=1332643http://svn.apache.org/viewvc?view=revisionrevision=1332643 after 72 hours if nobody is going to fix the stuff properly for Windows since I'm tired of always copying mod_ssl over from 2.4.x branch in order to get a working mod_ssl with trunk. Reasons: 1) within last 12 months there was no attempt made to fix the issues which wrowe mentioned in this thread [1] - instead discussion died 2) a suggestion to fix the issue [2] was not applied due to the concerns wrowe brought up, and to which I agree. 3) the same issue also causes a stalled backport in 2.2.x STATUS [3] for the last 12 months [1] http://mail-archives.apache.**org/mod_mbox/httpd-dev/201302.** mbox/%3C20130205115224.**33547872@hub%3Ehttp://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3C20130205115224.33547872@hub%3E [2] http://mail-archives.apache.**org/mod_mbox/httpd-dev/201302.** mbox/%3C510D8293.8010103@gknw.**net%3Ehttp://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3c510d8293.8010...@gknw.net%3E [3] http://svn.apache.org/viewvc?**view=revisionrevision=1333501http://svn.apache.org/viewvc?view=revisionrevision=1333501 I believe that one year in trunk without further review is long enough, and if someone wants to continue working on it its easy enough to checkout the last revision before removal. Gün. NPN is pretty important, but I understand the frustration at having to deal with this in its incomplete state. I promise to post a patch (or just commit if it is as trivial an issue as it sounds) in the next week to fix the hard link between core and ssl. Maybe I'll mess with the AP-SSL hook issue too. (Yeah, I know this is a rather uninspiring promise but I'm busy ;) ) How close does that get you to goodness on Windows, and may I presume there's no desire to revert as long as progress is being made? -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Whither Windows (Was: Re: Intent to revert commit r1332643)
On May 24, 2013, at 9:08 AM, Jeff Trawick traw...@gmail.com wrote: Lots of us are employees of or otherwise manage to siphon money from these companies. Make a pitch... (And some of us are happy to freelance ;) ) I'll be honest: I don't even know to to *build* for Windows, at least with any Visual Studio release from this century.
Re: Time for 2.4.5 ??
On Fri, May 24, 2013 at 8:40 AM, Jim Jagielski j...@jagunet.com wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) Could you provide some notes for testing wstunnel in a real-world scenario? Thanks! o Performance-related patches (Event mod_ssl, cache, etc) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
On Fri, 24 May 2013 09:26:34 -0400 Jim Jagielski j...@jagunet.com wrote: On May 24, 2013, at 9:08 AM, Jeff Trawick traw...@gmail.com wrote: Lots of us are employees of or otherwise manage to siphon money from these companies. Make a pitch... (And some of us are happy to freelance ;) ) I'll be honest: I don't even know to to *build* for Windows, at least with any Visual Studio release from this century. That fortunately is documented, with some pretty good notes in the wiki as well that aught to percolate into the docs. That said, documenting every Microsoft-version-quirk seems out of scope for a general purpose 'compiling' doc. Symbol resolution on Linux is rather loosey-goosey, and very relaxed. Resolution in OS/X 2-level namespace mode is quite strict and a very good mirror of the world of Windows, z/OS and many others[1]. It should be relatively easy to enforce explicit exports on some other platforms which more of the developers use in day-to-day practice. The patch to 'fix' this is trivial. The well-documented issues with that 'fix' is the reason this patch should be reverted. httpd has a reasonably straightforward pattern to register and consume optional functions, hook functions etc. This has existed since close to the dawn of 2.0 and /had/ resolved almost all module load-ordering issues in the server software. It was close to world-class in behavior and quite foolproof when the return codes were observed. To see how simple these are in practice, see my backport of the Mutex behavior for 2.4-based modules to borrow when compiled under 2.2; http://people.apache.org/~wrowe/httpd-2.2-ports/util_mutex.h http://people.apache.org/~wrowe/httpd-2.2-ports/mod_mutex.c Optional hooks were introduced to allow for the registration of a sometimes-present, sometimes absent hook provider because not every hook was relevant to the core httpd server and not every hook should always exist. Both proxy and dav are good examples of modules which must introduce new hooks themselves. This patch ignored that, and introduced a hook provider that now exists in a sometimes-loaded module which the core is looking to register in. It breaks the pattern because that hook is not an optional hook. The implementation is a mess and it has been documented for a year what would fix it to follow httpd convention. The much greater problem is that the current proxy provider stack is riddled with load-time linkage between proxy modules, rather than run-time optional functions and hooks. This means that the entire LoadModule mod_proxy schema is broken and fails to follow the design principals of httpd 2.0. How can developers without Windows possibly cope with identifying these problems? Magically, all it takes is to re-sort your LoadModule list in inverse order and see what breaks. There are very few Windows-only behaviors in the server that can't be documented with some trivial tests even on Linux. So unless we really no longer care about this 'enhancement' to the Apache 2.0 family, it seems past time to start re-factoring such newly-reintroduced fragile behaviors and come back to that design principal. Or perhaps chuck it and go back to hard module linkages and document the required load orders? That would save a few ms at startup. It seems that we would all benefit from working out the libtool and exports.c logic so that we can have some explicit-export model on Linux that will approximate windows and demonstrate this logic to those who don't (and shouldn't have to) build on Windows, WDYT? p.s. I think your prior thread is rather dismissive of Gregg, and folks like Steffan who go out of their way to follow these docs and regularly report problems on Windows. It's dismissive of folks like Jeff and the rest who untangled the thorny change in mod_ssl that broke the windows MPM preloaded socket data approach so badly. The fact that reports and objections are ignored does not mean the platform is ignored. This is the only major issue I am aware of, nobody seems to have problems generating builds outside of the ASF, and we haven't seemed to have a large issue of following the Subversion model of binaries. p.p.s. We have delivered 2.0 and 2.2 binaries and aught to update those, now that my VM's are healed with the necessary crazy MSVCRT based compilation environment the 'final' 2.0 binary can be built and a refresh of 2.2 can be provided. (Mladen's hybrid solution rocks, but there are some insane to workaround quirks for httpd with his solution that weren't present in building apr, -util etc). p.p.p.s. I'll build a demonstration 2.4 package over the holiday weekend, but don't consider it 'prime time' just yet. We have a ways to go before all the Windows' players concerns can be resolved, I'll put up a scratchpad in the wiki for us to discuss. Lua et al introduce more 3rd-party build questions than they answer. p.p.p.p.s. Note that the Lua project makes life difficult for ALL
Re: Whither Windows (Was: Re: Intent to revert commit r1332643)
On Fri, 24 May 2013 08:52:05 -0400 Jim Jagielski j...@jagunet.com wrote: Maybe the real question is where exactly do we stand with Windows right now... We haven't had (complimentary) binary builds for Windows in quite awhile and, afaict, there are really no people focusing on Windows compatibility anymore. Thanks you just reminded me... Another question is where exactly do we stand with OS/X right now? Apple HFS+ is still not supported, there exists a forced lower-case canonicalization hack authored by Apple, but AFAICT still no progress on retrieving the true name of a file on a case-insensitive OS/X volume which I suspect are still in common use on most OS/X boxen. Of course, all the BSD-based file systems are strict case sensitive and don't have security bypass issues when running 'vanilla' httpd. Unfortunately I don't run an OS/X box anymore so it's awfully hard for me to complete research on such a fix (and isn't so personally interesting since my ppc laptop was retired for lack of OS updates). Also wondering where the OS/X download lives? It will build on any OS/X box with a deployed toolchain, but I imagine many OS/X users don't install that toolchain and live with the Apple provided flavors, and would guess that 2.4.x is not part of that Apple OS distributions so far.
Re: Intent to revert commit r1332643
Hi, On 24.05.2013 14:57, Jeff Trawick wrote: NPN is pretty important, granted. I promise to post a patch (or just commit if it is as trivial an issue as it sounds) in the next week to fix the hard link between core and ssl. Maybe I'll mess with the AP-SSL hook issue too. cool! How close does that get you to goodness on Windows, and may I presume there's no desire to revert as long as progress is being made? it was more an attempt by me to kick on discussion again; I feel sometimes that must be done in a drastical way when over one year nothing happend, and discussion just died ;-) so that was kinda last resort - of course if com0ilation breaks no longer all is fine again! Gün.
Re: Time for 2.4.5 ??
On 24.05.2013 14:40, Jim Jagielski wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff ok, after spending a bunch of hours during last weeks with testing mod_lua mainly on Windows I've finally removed my blocking vote from STATUS just now; nevertheless I feel that I did only test half of all the new stuff, and therefore my vote is +0.5 only ... some things which I see as outstanding are: - removal of the export declarations since they are unneeded (I will take a look into this during this weekend if nobody beats me) - removal of some doubled code ( ap_lua_check_request_rec() ) - another docu fix for r:sleep() -- r.sleep(); meanwhile I have a stronger oppinion about this: I believe we should chage all functions to r:function() in order to separate them more clearly from vars like r.filename; further more I believe r.sleep() would be better renamed to r.usleep() taking microseconds instead of having a r.sleep() and then dealing with fractions of seconds - this way also the code would be cleaner and no calculation of the passed-in value needed anymore, just the value would get passed to apr_sleep(). Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... So how do we further proceed with mod_lua? There are certainly some remaining issues, but it just takes too long for only 2 persons to find them all; also I see with current code that it works fine when I compile it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not sure yet if this is an issue with MSVC9 itself, or with the converted projects ...; I think we should now copy over the complete trunk code to 2.4.x branch, and keep the status 'experimental' so that users are warned that directives, functions, etc. might change even with an otherwise stable release branch; hopefully then when more users play with mod_lua we will make faster progress with finding any further issues ... also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. Gün.
Re: Whither Windows (Was: Re: Intent to revert commit r1332643)
Hi Jim, On 24.05.2013 14:52, Jim Jagielski wrote: For me, I wouldn't want to stunt httpd development for every other platform we care about simply because it breaks Windows. But it's not just my decision, 'natch. well, for me its no reason to just accept every code as long as it compiles on *nix platforms regardless of design flaws; also we could easily fix the stuff so that Windows would compile again even with the design flaw, but that's not what Bill would accept IIUC, and not what I would like to do ... finally what I was mainly after was kicking on discussion again about how to fix it correctly, and thats now in progress ... ;-) Gün.
Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
On Fri, May 24, 2013 at 8:13 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: That fortunately is documented, with some pretty good notes in the wiki as well that aught to percolate into the docs. That said, documenting every Microsoft-version-quirk seems out of scope for a general purpose 'compiling' doc. The build system should be able to compile with the major tool chains, nobody expects to know how to work around weird autoconf, make, gcc, etc quirks on Linux. I don't say this to be dismissive of anyones contributions but just to point out that producing Windows builds with a modern toolchain is not simple. I did a bunch of work on scripting building the dependencies for Subversion on Windows that's located here: http://svn.apache.org/repos/asf/subversion/trunk/tools/dev/build-svn-deps-win.pl By far httpd was the biggest pain of any of the dependencies to get to work. If your only interest is building httpd on Windows with Visual Studio 2012, taking a look at build_httpd() in that file should give a good starting point. Sometime when I find the time I want to fix the problems that I had to work around the right way and not the hackish way I did in that script and submit them back. But I haven't gotten to it. I'll admit that I haven't tried to build httpd-trunk on Windows so maybe improvements have been made that haven't made their way over to the 2.4 releases, Subversion certainly has similar issues with our 1.7 release branch.
Re: Whither Windows (Was: Re: Intent to revert commit r1332643)
On Fri, May 24, 2013 at 8:23 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Another question is where exactly do we stand with OS/X right now? Apple HFS+ is still not supported, there exists a forced lower-case canonicalization hack authored by Apple, but AFAICT still no progress on retrieving the true name of a file on a case-insensitive OS/X volume which I suspect are still in common use on most OS/X boxen. Of course, all the BSD-based file systems are strict case sensitive and don't have security bypass issues when running 'vanilla' httpd. Can't speak to this, it's not important to my use since I avoid the case sensitivity issues on OS X. I've had no problems building httpd on OS/X on 10.7 (I haven't bothered to upgrade to 10.8). I do a fair amount of work on OS X directly and often build httpd-trunk and releases with debugging. There may be computability issues like you pointed out above, but I quite frankly have never noticed them. Granted my use of httpd on OS X is purely developmental and I likely wouldn't run into the types of issues that someone using httpd for production servers on OS X would. Also wondering where the OS/X download lives? It will build on any OS/X box with a deployed toolchain, but I imagine many OS/X users don't install that toolchain and live with the Apple provided flavors, and would guess that 2.4.x is not part of that Apple OS distributions so far. I've never bothered to try to download a httpd binary build, it's easy enough to build that I don't feel the need. 10.7 still had httpd 2.2, not sure what 2.4 has.
httpd buildbot
I dont know who has access / maintains the httpd buildbot, but I would like to have it build with maintainer mode; this could be useful to avoid that code we dont want slips in, f.e. var declarations after statements ... Gün.
Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
On 24.05.2013 21:37, Ben Reser wrote: The build system should be able to compile with the major tool chains, nobody expects to know how to work around weird autoconf, make, gcc, etc quirks on Linux. I don't say this to be dismissive of anyones contributions but just to point out that producing Windows builds with a modern toolchain is not simple. yeah ...; and from what I see our project files are already broken even when not converted and used directly with MSVC6, f.e. when doing a release build a bunch of files land in the debug folder, and finally at linking stage it breaks ... probably we should think about moving either to plain Nmakefiles (as Pierre Joy also suggested), or add a Cmake build system; for me SCon is no alternative since I saw it too often already fail on modern Linux boxes (with other projects), so I have no hope that it works any better on Windows ... and regarding trunk: AFAICT there are no improvements (what I mentioned above was with trunk) ... Gün.
Re: httpd buildbot
On Fri, 24 May 2013 21:42:58 +0200 Guenter Knauf fua...@apache.org wrote: I dont know who has access / maintains the httpd buildbot, but I would like to have it build with maintainer mode; this could be useful to avoid that code we dont want slips in, f.e. var declarations after statements ... We could do both... should be straightforward.
Re: Time for 2.4.5 ??
On Fri, 24 May 2013 21:02:04 +0200 Guenter Knauf fua...@apache.org wrote: also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing.
Re: Whither Windows (Was: Re: Intent to revert commit r1332643)
On Fri, 24 May 2013 12:43:23 -0700 Ben Reser b...@reser.org wrote: On Fri, May 24, 2013 at 8:23 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Also wondering where the OS/X download lives? It will build on any OS/X box with a deployed toolchain, but I imagine many OS/X users don't install that toolchain and live with the Apple provided flavors, and would guess that 2.4.x is not part of that Apple OS distributions so far. I've never bothered to try to download a httpd binary build, it's easy enough to build that I don't feel the need. 10.7 still had httpd 2.2, not sure what 2.4 has. As far as we are aware, no commercial distributions and so far, no released free stable distributions incorporate 2.4. A couple have started integrating it, but the single biggest obstacle that is reported by the packagers community is that mod_perl had not yet supported 2.4 and that is an important package dependency to them.
Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
On Fri, 24 May 2013 21:53:50 +0200 Guenter Knauf fua...@apache.org wrote: On 24.05.2013 21:37, Ben Reser wrote: The build system should be able to compile with the major tool chains, nobody expects to know how to work around weird autoconf, make, gcc, etc quirks on Linux. I don't say this to be dismissive of anyones contributions but just to point out that producing Windows builds with a modern toolchain is not simple. yeah ...; and from what I see our project files are already broken even when not converted and used directly with MSVC6, f.e. when doing a release build a bunch of files land in the debug folder, and finally at linking stage it breaks ... probably we should think about moving either to plain Nmakefiles (as Pierre Joy also suggested), or add a Cmake build system; for me SCon is no alternative since I saw it too often already fail on modern Linux boxes (with other projects), so I have no hope that it works any better on Windows ... The concensus seems to be forming around cmake, and it is certainly my preference from working with pcre and other libraries and projects. But in the walk-before-you-run department, it's probably best to swap the scons for cmake over at the apr project, and that will take our most significant obstacle out of the way. The httpd cmake will still be quite complex, but not obnoxiously so, and our apr experience would be beneficial to setting out a well thought out plan.
Re: Time for 2.4.5 ??
On Wed, 22 May 2013 14:20:03 -0400 Jim Jagielski j...@jagunet.com wrote: I would be nice, imo, to start thinking about a 2.4.5 release Real Soon Now. We have lots of stuff added and fixed in 2.4.5-dev and even more fun stuff in STATUS. I'll RM. What is your thought on RSN? Sometime Thurs-Sat timeframe late next week? It could be good to have a goal and then slip the whole thing 1 week exactly if we can't reach it. My schedule is now very flexible, so you choose :) I like the late-week roll so that weekday coders and weekend warriors can both put their hands on the candidate.
Re: Time for 2.4.5 ??
On 24 May 2013, at 2:40 PM, Jim Jagielski j...@jagunet.com wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) o Performance-related patches (Event mod_ssl, cache, etc) Pretty much all of the cache and proxy related proposals are fixes for RFC violations, detected courtesy of the CoAdvisor test suite. It would be goodness to get these out there. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Time for 2.4.5 ??
On 24.05.2013 22:14, William A. Rowe Jr. wrote: There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing. ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. Gün.
Re: Time for 2.4.5 ??
On 05/24/2013 09:02 PM, Guenter Knauf wrote: On 24.05.2013 14:40, Jim Jagielski wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff ok, after spending a bunch of hours during last weeks with testing mod_lua mainly on Windows I've finally removed my blocking vote from STATUS just now; nevertheless I feel that I did only test half of all the new stuff, and therefore my vote is +0.5 only ... some things which I see as outstanding are: - removal of the export declarations since they are unneeded (I will take a look into this during this weekend if nobody beats me) - removal of some doubled code ( ap_lua_check_request_rec() ) - another docu fix for r:sleep() -- r.sleep(); meanwhile I have a stronger oppinion about this: I believe we should chage all functions to r:function() in order to separate them more clearly from vars like r.filename; I can only say +1 from me, we need consistency here :) further more I believe r.sleep() would be better renamed to r.usleep() taking microseconds instead of having a r.sleep() and then dealing with fractions of seconds - this way also the code would be cleaner and no calculation of the passed-in value needed anymore, just the value would get passed to apr_sleep(). That's fine by me, I'm not married to 'sleep' (although I do like a good nap) Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? So how do we further proceed with mod_lua? There are certainly some remaining issues, but it just takes too long for only 2 persons to find them all; also I see with current code that it works fine when I compile it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not sure yet if this is an issue with MSVC9 itself, or with the converted projects ...; I ran into some issues with MSVC10/11, but they appear to have been fixed (though not 100% sure) - but I'm not a big Windows expert anymore :| I think we should now copy over the complete trunk code to 2.4.x branch, and keep the status 'experimental' so that users are warned that directives, functions, etc. might change even with an otherwise stable release branch; hopefully then when more users play with mod_lua we will make faster progress with finding any further issues ... also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. Gün. With regards, Daniel.
Re: Time for 2.4.5 ??
Hi Daniel, On 24.05.2013 23:45, Daniel Gruno wrote: I can only say +1 from me, we need consistency here :) great! That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? yes, see the apr_dbm.h header; SDBM is the only database we allways have even without any driver or external libs; it can be used f.e. for password storage (htdbm.c), and I think mod_dav makes use of it for its lock database; as usage example might serve mod_authn_dbm.c ... Gün.
suexec and reload modules
Hi, Two questions First, when apache gracefully reloads, it does not reload the modules? is there an option to have it fully reloads them? or, is an option planned? Case: We use mod cband to control clients speed and limits, but if we alter their configuration to increase the speed, reload does not change it, only a full stop, and start changes. So pewrhaps a feature request? Second, SuExec, is there plan to modify suexec so docroot build option is the absolute root of what can be accessed, similar to using php_admin_value open_basedir which locks down (yes I know it does its best but rogue modules may break out of this) so users can not traverse parent directories. If apache/php can do its best to lock down php with no noticable resource impact, can not understand why the main programme, apache, can not either - without creating the nightmare that is jails, or relying on third party modules like mod security, which have had problems of their own, and even some configurations, like ours, mod security is not by their own worlds, suited to our needs. I know suexec hardens things up a little, and stops,. or at least tracks who is being naughty, but, prevention is better than the cure.
Re: Time for 2.4.5 ??
Hi Daniel, On 25.05.2013 02:06, Guenter Knauf wrote: On 24.05.2013 23:45, Daniel Gruno wrote: That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. done. Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5 local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5' the function call should here be r:unescape(url) ... Gün.
Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
On 5/24/2013 12:53 PM, Guenter Knauf wrote: yeah ...; and from what I see our project files are already broken even when not converted and used directly with MSVC6, f.e. when doing a release build a bunch of files land in the debug folder, and finally at linking stage it breaks ... Vice-versa, I never have a problem with release builds which probably explains why I do so few debug builds. It ends up being all objects land in /Release but then the linker looks in /Debug for them. libhttpd is the culpret here for me, I do not think I have had the problem with anything else. It's now been two or three weeks since I fought the dreaded debug build so who knows as I have done too many release builds since :) But libhttpd stands out above all and I have no idea why it's happening on this project, I'm just not seeing it. Gregg
Re: Time for 2.4.5 ??
On 5/24/2013 2:03 PM, Guenter Knauf wrote: ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. I'm +1 to this approach.
