Re: Apache-Test subdirectory has moved
yay, php docs at perl.apache.org :) they may be more popular, but I think we still win when it comes to open-source altruism :) sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? I'm all for it! cool. I'm going to spend some time over the next few days trying to get this situated, then. should there be Apache-Test/dist too? or should the CPAN distribution be sufficient? we can do that, although http://search.cpan.org/dist/Apache-Test/ is just as good. but if we want to mirror the way we do mod_perl then we can have dist/ as well, no problem. also we may want to add a /Apache-Test/snapshot for svn-impaired users. that's a good idea. I'll see if I can find the snapshot scripts or talk to whoever I need to to get that setup. --Geoff
Re: Apache-Test subdirectory has moved
Geoffrey Young wrote: [...] cool. I'm going to spend some time over the next few days trying to get this situated, then. should there be Apache-Test/dist too? or should the CPAN distribution be sufficient? we can do that, although http://search.cpan.org/dist/Apache-Test/ is just as good. but if we want to mirror the way we do mod_perl then we can have dist/ as well, no problem. it doesn't matter, less work for us w/o it. also we may want to add a /Apache-Test/snapshot for svn-impaired users. that's a good idea. I'll see if I can find the snapshot scripts or talk to whoever I need to to get that setup. geoff++ -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[STATUS] (httpd-test: flood) Thu Feb 10 06:05:01 2005
flood STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. Jacek is working on a Mozilla application, codename Flood URL bag (much like Live HTTP Headers) and small HTTP proxy. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h).
[STATUS] (httpd-test: perl-framework) Thu Feb 10 06:05:10 2005
httpd-test/perl-framework STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Stuff to do: * finish the t/TEST exit code issue (ORed with 0x2C if framework failed) * change existing tests that frob the DocumentRoot (e.g., t/modules/access.t) to *not* do that; instead, have Makefile.PL prepare appropriate subdirectory configs for them. Why? So t/TEST can be used to test a remote server. * problems with -d perl mode, doesn't work as documented Message-ID: [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 12:58:33 +0800 Subject: Re: perldb Tests to be written: * t/apache - simulations of network failures (incomplete POST bodies, chunked and unchunked; missing POST bodies; slooow client connexions, such as taking 1 minute to send 1KiB; ...) * t/modules/autoindex - something seems possibly broken with inheritance on 2.0 * t/ssl - SSLPassPhraseDialog exec: - SSLRandomSeed exec:
RE: loading mod_perl first?
Hi,
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
This solution looks good to me, but should be mod_embperl.c instead of
Embperl.c.
The reason why Embperl.so needs to loaded in the Apache config, is that it
adds Apache configuration directives to Apache, so you can write
Embperl_XXX foo
Instead of
PerlSetEnv EMBPERL_XXX foo
In Apache 1.3 this works without explicitly loading Embperl.so, just via
PerlModule, but for Apache 2 Embperl.so needs to be loaded via LoadModule,
otherwise it's to late for adding config directives. So the problem will
occur with all modules that adds configuration directives to Apache and you
are right that is not common. The only one I know is AxKit, which currently
runs only on mod_perl 1.
Gerald
P.S. I am currently on the German Perl Workshop, so I cannot test. I will
test this change when I am back.
Re: loading mod_perl first?
This solution looks good to me, but should be mod_embperl.c instead of Embperl.c. well, I went to the embperl site and added this to my httpd.conf LoadModule embperl_module /tmp/Embperl.so and things worked out as expected [ debug] /tmp/Embperl.so is already absolute [ debug] /tmp/Embperl.so successfully resolved to existing file /tmp/Embperl.so [ debug] Found: embperl_module = Embperl.c [ debug] Skipping LoadModule of Embperl.c is this not a correct setup? or it is for apache2 and not apache 1.3? --Geoff
RE: loading mod_perl first?
Hi This solution looks good to me, but should be mod_embperl.c instead of Embperl.c. well, I went to the embperl site and added this to my httpd.conf LoadModule embperl_module /tmp/Embperl.so and things worked out as expected [ debug] /tmp/Embperl.so is already absolute [ debug] /tmp/Embperl.so successfully resolved to existing file /tmp/Embperl.so [ debug] Found: embperl_module = Embperl.c [ debug] Skipping LoadModule of Embperl.c is this not a correct setup? or it is for apache2 and not apache 1.3? Looks like you done the right thing. As said I am not at home and cannot test at the moment, so I told you mod_embperl.c from my mind, but it looks like I am wrong. I will check this next week when I am back and give you a feedback. Gerald
Re: [Fwd: MODERATE for modperl-cvs@perl.apache.org]
Stas Bekman wrote: Folks committing to A-T, please don't forget to subscribe to the new lists: [EMAIL PROTECTED] [EMAIL PROTECTED] I think I mentioned that before, but it never hurts :) I've approved joe as a poster. Geoff, why the moderation hits the modperl-cvs /at/ perl.apache.org list? I dunno. ask set these up. Also it looks that commits to A-T go to two lists: To: [EMAIL PROTECTED], modperl-cvs@perl.apache.org any special reason? I didn't do it. I'll ping justin. --Geoff
[STATUS] (httpd-2.0) Thu Feb 10 06:04:45 2005
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-02-04 20:58:31 -0500 (Fri, 04 Feb 2005) $] The current version of this file can be found at: http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Release history: 2.0.53 : in development 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes in STATUS, and then merge into branches/2.0.x. RELEASE SHOWSTOPPERS: PATCHES TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! ] [ please append new backports at the end of this list not the top. ] *) Add a build script to create a solaris package. svn rev 124104 +1: minfrin *) Win32: Eliminate a very ugly race - the parallel starting threads were picking up thread identifiers other than their own. Because the limit of threads is an int, stuffing the int into the void* value is a safe argument convention. http://svn.apache.org/viewcvs.cgi?rev=123899view=rev +1: stoddard *) util_ldap: Add the directive LDAPConnectionTimeout to control the socket timeout value when binding to an LDAP server svn rev 126565 +1: bnicholes *) mod_ssl: fix to access mod_ssl-specific X509_STORE_CTX userdata using the proper accessor function; matters only in some pathological cases with OpenSSL global variables not getting reset during reloads but is fatal in such cases. http://svn.apache.org/viewcvs?view=revrev=111241 PR: 32529 +1: jorton *) win32: Handle PATH_INFO -and- PATH_TRANSLATED as opaque byte-wise data for cgi invocation, as handled for other variables originally fixed in bug 9223, within
[STATUS] (httpd-2.1) Thu Feb 10 06:04:53 2005
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2005-02-04 15:27:11 -0500 (Fri, 04 Feb 2005) $] The current version of this file can be found at: http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Release history: [NOTE that only Alpha/Beta releases occur in 2.1 development] 2.1.3 : in development 2.1.2 : Released on 12/08/2004 as alpha. 2.1.1 : Released on 11/19/2004 as alpha. 2.1.0 : not released. Please consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 jerenkrantz asks: Why should this block a release? * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 jerenkrantz asks: Why should this block a release? CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars pquerna: Do we want to change this for 2.2? RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Patches submitted to the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable * The Event MPM does not work on Solaris 10. Solaris 10 does support the Threadsafe Pollsets required by the Event MPM, but it does not support multiple threads calling accept() at the same time. The current structure of the Event MPM makes adding accept() locking difficult. * Filter stacks and subrequests, redirects and fast redirects. There's at least one PR that suffers from the current unclean behaviour (which lets the server send garbage): PR 17629 nd says: Every subrequest should get its own filter stack with the subreq_core filter as bottom-most. That filter does two things: - swallow EOS buckets - redirect
UNIX MPMs
OK - let's face it. Most people who seriously run Apache (1.3/2) run it on a UNIX system. Often Linux. Some people have switched from Apache 1.3 to Apache 2 for a variety of reasons, but from my POV the new MPMs were the primary reason for switching to Apache 2. This is an excerpt from the MPM blurb on the main doc pages: The server can be better customized for the needs of the particular site. For example, sites that need a great deal of scalability can choose to use a threaded MPM like worker, while sites requiring stability or compatibility with older software can use a prefork. In addition, special features like serving different hosts under different userids (perchild) can be provided. This is all very well, but none of the special features work, and have not worked for at least a year. This is the status of MPMs for UNIX at the moment: UNIX MPMs in Apache 2: perchild worker threadpool (experimental) leader (experimental) prefork (old) UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) Let me focus on perchild (an MPM that should work) for a moment. * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me how the Perchild MPM should be re-written. It hasn't worked correctly since filters were added because it wasn't possible to get the content that had already been written and the socket at the same time. This mode lets us do that, so the MPM can be fixed. The STATUS documents have included the above statement for (over?) a year now. A few months after it appeared the perchild MPM docs were updated to say the equivalent of sorry, we broke it. It seems there's lots of information about how wonderful the UNIX Apache 2 MPMs are, but little actual substance. In this all-singing, all-dancing not-so-new implementation of the world's most popular web server, we have - count 'em - ONE new MPM for UNIX that works. So - could someone who understands these things comment on whether there is any commitment to fix perchild, or any of the other UNIX Apache 2 MPMs at some point? Failing that, maybe the documentation for Apache 2 could be updated to avoid giving people the wrong impression from the outset. Thanks, Nick Maynard [EMAIL PROTECTED]
Re: RFC for a Perchild-like-MPM
The problem is: SSL is *NOT* usable for virtual hosting. You need an separate socket for each SSL vhost, so you'll probably prefere several independent httpd's - maybe then stripped down w/o any vhost support. You're right - SSL is not usable for name-based vhosts. However it should be fine for normal vhosts. Are you suggesting I use a separate httpd for every SSL host I have? That's a waste of resources, and horribly inefficient. Can metuxmpm deal with non name-based SSL vhosts? Aehm, what exactly do you want to do ? Measure users's consumed traffic ? (- logfile ?) Measure users's consumed bandwidth ? (eh, does this make sense at all? ) Limit user's bandwidth ? (very complicated w/o proper kernel support) As you have correctly surmised we'd be doing all this in kernel space. This isn't something Apache needs to support natively, I'm merely putting forward a consideration from my POV. PS. Not subscribed to the mailing list and checking this via gmane. So, copying replies to me is a good idea if you want a response! Thanks, Nick Maynard [EMAIL PROTECTED]
Terminating cgi scripts
We had a customer scenario (on HP-UX) recently where cgi scripts that were spawned by mod_cgid continued to run even when httpd was stopped. The ppid of these scripts was automatically 1 when the httpd processes terminated. The customer does not find any reason why these processes need to continue to run especially since the scripts need to be run again when httpd restarts. This does seem like a reasonable demand. The problem occurs both with mod_cgi and mod_cgid. Being a novice, I have the following questions. It would be really helpful to get your take on the following : 1. How do I get all the child pids spawned by the cgid daemon and the httpd child (mod_cgi) so I can kill them when I get a signal ? Is it okay if I modify apachectl so that I can get all the processes that are owned by 'www' and still running using the 'ps' command and then kill them after httpd -k stop ? 2. If that is not acceptable, I would need to change the code. I looked at the mod_cgid sources and I found that the pids of all the processes that cgid spawns are hashed in the hash table script_hash. If I could make script_hash a static global variable, I could get the pids in the signal handler and kill the processes. I have changed the code and it is working. Would I be breaking something ? 3. We use the worker MPM. For mod_cgi, I would need to make changes in worker.c since there is no daemon here. In mod_cgi code, I find that everytime a process is spawned, apr_pool_note_subprocess() is called. I should be able to retrieve this pid in worker.c when I get the terminate signal. I have tried several ways to do this, but I haven't been successful. Is it possible to retrieve the pid in worker.c and if so how can I do that ? Thanks and Regards, Kiran
Re: UNIX MPMs
On Thursday 10 February 2005 11:56, Nick Maynard wrote: OK - let's face it. Most people who seriously run Apache (1.3/2) run it on a UNIX system. Often Linux. Some people have switched from Apache 1.3 to Apache 2 for a variety of reasons, but from my POV the new MPMs were the primary reason for switching to Apache 2. Really? The old MPM isn't *that* bad for most applications. Except on those non-unix-like platforms where forking is stupidly inefficient. UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) + event (new - hopefully) But the main thing MPMs have done is make Apache truly cross-platform, rather than a Unix server that can be made to work (rather badly) on other platforms. Let me focus on perchild (an MPM that should work) for a moment. * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me how the Perchild MPM should be re-written. It hasn't worked correctly since filters were added because it wasn't possible to get the content that had already been written and the socket at the same time. This mode lets us do that, so the MPM can be fixed. The STATUS documents have included the above statement for (over?) a year now. A few months after it appeared the perchild MPM docs were updated to say the equivalent of sorry, we broke it. Noone is working on it. Feel free to commission some work, or take up the task yourself. So - could someone who understands these things comment on whether there is any commitment to fix perchild, or any of the other UNIX Apache 2 MPMs at some point? Failing that, maybe the documentation for Apache 2 could be updated to avoid giving people the wrong impression from the outset. I agree the documentation should be better. Also we should properly document the perchild-like options, since that is frequently-requested. In the meantime, here's a list of things to look at if you want perchild-like: * Metux MPM * mod_ruid (Linux only) * fastcgi (CGI plus) * suexec (for CGI) I don't know enough about them or your needs to advise you. -- Nick Kew
Re: UNIX MPMs
Apologies to all if this sounds a little harsh, but I've been banging my head against the perchild problem, and associated workarounds for a lack of it, for so long it seems my entire Apache config life is taken up with it. I'd just like some kind of indication of whether it will ever get fixed. If not, you/we really should tell everyone, and let it die its natural death. Maybe I've missed you doing this, but your docs do say work is ongoing on perchild... Thanks, Nick Maynard [EMAIL PROTECTED]
Re: UNIX MPMs
On Thu, Feb 10, 2005 at 01:16:10PM +, Nick Maynard wrote: If not, you/we really should tell everyone, and let it die its natural death. Maybe I've missed you doing this, but your docs do say work is ongoing on perchild... The docs have been updated (all complete and in a red warning box): http://httpd.apache.org/docs-2.0/mod/perchild.html This module is not functional. Development of this module is not complete and is not currently active. Do not use perchild unless you are a programmer willing to help fix it. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: UNIX MPMs
On Thu, 10 Feb 2005 11:56:47 +, Nick Maynard [EMAIL PROTECTED] wrote: UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) Yeah, but what if you want to run PHP or mod_perl? Sure, PHP or mod_perl ~might~ work for you if you're lucky and you don't compile in the wrong third-party library, but you'll be in a world of pain if you don't. It's very hard to bolt threading onto an existing system that links to legacy libraries. Java managed to provide a thread-safe environment by having a painful API to link to C code, 100% Pure Java xenophobia -- and it still took them 5 years to make a JVM which was reliable enough for government work. On Linux I've done some benchmarking and found that worker isn't any faster than prefork at serving static pages. (Is it any different on other platforms, such as Solaris?) In principle you might save RAM by running prefork, but in this day and age you can fit 16 GB in a 1U pretty easily and it's cheaper than hiring a programmer who doesn't know how to track down race conditions, never mind one that does.
Re: RFC for a Perchild-like-MPM
Nick Maynard [EMAIL PROTECTED]; [EMAIL PROTECTED]:03 GMT-5 The problem is: SSL is *NOT* usable for virtual hosting. You need an separate socket for each SSL vhost, so you'll probably prefere several independent httpd's - maybe then stripped down w/o any vhost support. You're right - SSL is not usable for name-based vhosts. However it should be fine for normal vhosts. Are you suggesting I use a separate httpd for every SSL host I have? That's a waste of resources, and horribly inefficient. Can metuxmpm deal with non name-based SSL vhosts? Hi. I hang out mostly on the users list, but have played with basic HTTPS configuration (using SSL or TLS). As I understand, HTTPS works fine with any VirtualHost, so long as it is based on a unique ip:port combination. That is the current alternative to name-based virtual hosting. It doesn't necessarily mean you need a unique ip address, if you're willing or able to use non-standard ports. Otherwise it does require unique ip addresses and port 443. That is IP Based Virtual Hosting. I guess it is somewhat of a misnomer. It should be Socket Based Virtual Hosting, but IPBVH implies that only default ports are used. If you must use a single ip:port combination for HTTPS, then it's not possible, due to the point at which the SSL/TLS layers takes over to ensure the ultimate security of the connection. I'm not an expert with SSL or TLS, but my intuitive response would be to modify the HTTPS protocol to establish an unsecured connection, send the host header (ignore anything else) to pick the right certificate, and then use that to secure the connection. But my intuition also tells me that this would probably open up some avenues for attacks which might seriously degrade the effectiveness as compared to securing a connection from the outset, or otherwise add many levels of complexity and possibly inefficiency to ensure the connection is secured after some data was transferred. It would be great to have a compromise to allow some host header data be sent to an unsecured socket for the purposes of NBVH, and then hand off to another socket to respond securely. It may be my naivety, but I think anything is possible if perhaps not easy, because we tell the computer what to do, the computer doesn't tell us what to do, or else we have given it too much power and need to step back. Until I find the time to educate myself about the HTTPS, SSL and TLS protocols, and practice using something like OpenSSL and the Apache 2.x module programming, then I personally can't explore the feasability or implementation of such things. But hopefully someone else beats me to it. Leif
Re: UNIX MPMs
Paul A. Houle wrote: On Thu, 10 Feb 2005 11:56:47 +, Nick Maynard [EMAIL PROTECTED] wrote: UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) Yeah, but what if you want to run PHP or mod_perl? Sure, PHP or mod_perl ~might~ work for you if you're lucky and you don't compile in the wrong third-party library, but you'll be in a world of pain if you don't. Use prefork. No threads. On Linux I've done some benchmarking and found that worker isn't any faster than prefork at serving static pages. (Is it any different on other platforms, such as Solaris?) Yes, there is little differences under Linux, but substantial ones under other OSs such as AIX, Solaris, HP-UX... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: UNIX MPMs [ot?]
Nick Kew [EMAIL PROTECTED]; [EMAIL PROTECTED]:11 GMT-5 I agree the documentation should be better. Also we should properly document the perchild-like options, since that is frequently-requested. In the meantime, here's a list of things to look at if you want perchild-like: * Metux MPM * mod_ruid (Linux only) * fastcgi (CGI plus) * suexec (for CGI) Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of Apache 2.0.x with all file i/o and cgi being done by a single user, and the perchild MPM being broken. The frustration is that it is difficult, if not impossible (and potentially not even portable) to get all of these workarounds working together. And the clinching belief is that these should all be handled in the core of Apache, or with a working MPM. Here I post as complete a list I can think of including the new ones I see above. * cgiwrap * FastCGI * Metux MPM * mod_perl * mod_php * mod_ruid (Linux only) * suexec * suphp It's already a huge list of workaround and compatibility and portability for an admin could be a nightmare. I do not know if there are even more security wrappers needed for other language modules. Can anyone add to the list some things which might commonly be used in concert? Is there any direction given from the top of the Apache group in regards to what gets attention? In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority (at least regarding setuid per request as perchild MPM would like to do), only competing with MS/IIS. I'm not implying anything, I don't know what to believe, so that's why I ask. I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, and other people just happened to want to increase portability to windows? I mean, I like having a windows port, because I can at least practice using Apache somewhat, and it expands the development platform, but I won't ever, ever, EVER run it on Windows in production, simply because I'd never run Windows in production. Except insofar as to show Windows users a shining example of free software, and offer the idea of using an entire OS filled with shining examples of free software engineering. ;-) Toungue in cheek of course, with the ugly little problems such as this code abandonment of vital features at the back of my mind. I don't mean to start an OS flame war, so please don't respond with that in mind. :-) If other people would like to use Windows, it takes nothing away from me, I'm just stating opinion based on my own interaction and experience with Apache, Win, and *nix (Linux FreeBSD). Leif
Re: UNIX MPMs [ot?]
On Thursday 10 February 2005 14:10, Leif W wrote: Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of Apache 2.0.x with all file i/o and cgi being done by a single user, and the perchild MPM being broken. That's rather different. If you care *at all* about security, you won't be running PHP as a module. So suexec is a complete solution there. -- Nick Kew
Re: UNIX MPMs
At 07:24 AM 2/10/2005, Paul A. Houle wrote: On Thu, 10 Feb 2005 11:56:47 +, Nick Maynard [EMAIL PROTECTED] wrote: UNIX MPMs that actually _work_ in Apache 2: worker Yeah, but what if you want to run PHP or mod_perl? Sure, PHP or mod_perl ~might~ work for you if you're lucky and you don't compile in the wrong third-party library, but you'll be in a world of pain if you don't. So true ... while you are at it, watch out for those libraries with Y2K bugs. Oh, and 2038 bugs if you last that long. Sorry, but get used to this stock response to 'threads are dangerous' trolls for the next 32 years :)
RE: UNIX MPMs [ot?]
From: Leif W [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 3:10 PM [...] It's already a huge list of workaround and compatibility and portability for an admin could be a nightmare. I do not know if there are even more security wrappers needed for other language modules. Can anyone add to the list some things which might commonly be used in concert? Is there any direction given from the top of the Apache group in regards to what gets attention? No, there is not. The committers are free to work on what they want. In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. only competing with MS/IIS. Not even that. I mean, it's fun to watch our marketshare rise every month, but that's not what the ASF is all about. I'm not implying anything, I don't know what to believe, so that's why I ask. I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? There's more to it than just portability to Windows. It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, Correct. and other people just happened to want to increase portability to windows? Portability in general. But this is all contained in the APR project, on top of which httpd-2.x is built. Also people worked on a lot of other things during last year. Just look at the Changelog, the commit messages etc, to see what I mean. I mean, I like having a windows port, because I can at least practice using Apache somewhat, and it expands the development platform, but I won't ever, ever, EVER run it on Windows in production, simply because I'd never run Windows in production. Not all administrators are in a position where they can refuse to run Windows. Except insofar as to show Windows users a shining example of free software, and offer the idea of using an entire OS filled with shining examples of free software engineering. ;-) Toungue in cheek of course, with the ugly little problems such as this code abandonment of vital features at the back of my mind. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. I don't mean to start an OS flame war, so please don't respond with that in mind. :-) If other people would like to use Windows, it takes nothing away from me, I'm just stating opinion based on my own interaction and experience with Apache, Win, and *nix (Linux FreeBSD). The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Sander
Re: UNIX MPMs [ot?]
At 08:10 AM 2/10/2005, Leif W wrote: I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? What gives you the impression that this has anything to do with alternate ports? What gives you the impression that Apache 1.3 had this right? You hit the nail on the head A feature that people want ... ... but apparently not badly enough to solve the puzzle? The Apache Software Foundation puts together code that folks want to create, it doesn't put together code that folks want to have created for them. Rather than bemoan the fact that something doesn't exist/is broken/isn't complete enough, they are welcome in any ASF project to offer issue + solution to their own itch. At least, when that solution in in the form of ASF Licensed code. It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, and other people just happened to want to increase portability to windows? Ding ding ding. Each developer has their own expertise(s) and scratches their own itch. There is no ombudsman who is saying Oh, you can add that code, just as soon as you go mop up this code over here... If you are suggesting that OtherBill should be fixing Perchild to support Linux users and not off supporting Win32 users, well then, bite me :) Perchild will be fixed the moment someone wants to invest the time to fix perchild. There is no obstacle, there is also no volunteer. And several folks out there, rather than fix Perchild, have set out to do their own thing instead to create such features. Nothing stopping them from offering their own solution out there, nothing stopping them from contributing here. And so it is as it should be.
Re: [PATCH] get a pointer to the raw cert from mod_ssl
Here's an alternative implementation: does it work for you?
Index: ssl_private.h
===
--- ssl_private.h (revision 153210)
+++ ssl_private.h (working copy)
@@ -641,6 +641,9 @@
/* Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *,
request_rec *, char *);
+
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const char
*oid);
+
void ssl_var_log_config_register(apr_pool_t *p);
#define APR_SHM_MAXSIZE (64 * 1024 * 1024)
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 153210)
+++ ssl_engine_vars.c (working copy)
@@ -61,6 +61,7 @@
{
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
APR_REGISTER_OPTIONAL_FN(ssl_var_lookup);
+APR_REGISTER_OPTIONAL_FN(ssl_ext_lookup);
return;
}
@@ -655,6 +656,58 @@
return result;
}
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer,
+ const char *oidnum)
+{
+SSLConnRec *sslconn = myConnConfig(c);
+SSL *ssl = sslconn-ssl;
+X509 *xs = NULL;
+ASN1_OBJECT *oid;
+int count = 0, j;
+char *result = NULL;
+
+oid = OBJ_txt2obj(oidnum, 1);
+if (!oid) {
+ERR_clear_error();
+return NULL;
+}
+
+xs = peer ? SSL_get_peer_certificate(ssl) : SSL_get_certificate(ssl);
+if (xs == NULL) {
+return NULL;
+}
+
+count = X509_get_ext_count(xs);
+
+for (j = 0; j count; j++) {
+X509_EXTENSION *ext = X509_get_ext(xs, j);
+
+if (OBJ_cmp(ext-object, oid) == 0) {
+BIO *bio = BIO_new(BIO_s_mem());
+BUF_MEM *buf;
+
+if (X509V3_EXT_print(bio, ext, 0, 0) != 1) {
+ERR_clear_error();
+BIO_vfree(bio);
+return NULL;
+}
+
+BIO_get_mem_ptr(bio, buf);
+result = apr_pstrmemdup(p, buf-data, buf-length);
+BIO_vfree(bio);
+break;
+}
+}
+
+if (peer) {
+/* only SSL_get_peer_certificate raises the refcount */
+X509_free(xs);
+}
+
+return result;
+}
+
+
/* _
**
** SSL Extension to mod_log_config
Index: mod_ssl.h
===
--- mod_ssl.h (revision 153210)
+++ mod_ssl.h (working copy)
@@ -27,6 +27,16 @@
conn_rec *, request_rec *,
char *));
+/* The ssl_ext_lookup() optional function retrieves the value of a SSL
+ * certificate X.509 extension. The client certificate is used if
+ * peer is non-zero; the server certificate is used otherwise. The
+ * oidnum parameter specifies the numeric OID (e.g. 1.2.3.4) of the
+ * desired extension. The string value of the extension is returned,
+ * or NULL on error. */
+APR_DECLARE_OPTIONAL_FN(const char *, ssl_ext_lookup,
+(apr_pool_t *p, conn_rec *c, int peer,
+ const char *oidnum));
+
/* An optional function which returns non-zero if the given connection
* is using SSL/TLS. */
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *));
Re: UNIX MPMs
On Thursday 10 February 2005 11:56, Nick Maynard wrote: OK - let's face it. Most people who seriously run Apache (1.3/2) run it on a UNIX system. Often Linux. Some people have switched from Apache 1.3 to Apache 2 for a variety of reasons, but from my POV the new MPMs were the primary reason for switching to Apache 2. I don't think this is true. The primary audience for MPMs is the developers rather than end users: Now the Windows port of httpd can now be Windows specific, rather than be buggy code full of #ifdefs. From an end user perspective it means that the code is more reliable, but at the end of the day a platform will probably have a preferred MPM, unless the user has special needs. MPMs are something most users will not need to worry about. If there is just one MPM for a platform, even if that platform is Unix in general, that's fine as long as that MPM works. If a second MPM comes along and is better, then so be it. If an MPM exists as an experiment, but ends up abandoned because another MPM is better, this isn't a problem. The only requirement is that there is at least one MPM for a platform, and it works. My primary reasons for switching to v2.0 and then v2.1 (as a webmaster) were filters and the caching code. Regards, Graham --
Re: Decreasing need to recompile buildmark.c?
--On Wednesday, February 9, 2005 3:55 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I did exactly that for win32. The old win32 build system recompiled buildmark.c as a build step (bleh.) The new win32 build system has the compilation of buildmark.c as a prelink step - if we aren't linking libhttpd, we don't recompile buildmark. Seemed to be a trivial solution, and avoided many, many worthless relink's, since recompiling buildmark.c forces the linker. Exactly! r153266 now matches what the Win32 build does. =) Man, that relink has been annoying the heck out of me lately. -- justin
Re: UNIX MPMs
The docs have been updated (all complete and in a red warning box): http://httpd.apache.org/docs-2.0/mod/perchild.html This module is not functional. Development of this module is not complete and is not currently active. Do not use perchild unless you are a programmer willing to help fix it. Hello Mads, That's fantastic. Could the docs at http://httpd.apache.org/docs-2.0/mpm.html be updated to reflect this too? Thanks, Nick Maynard [EMAIL PROTECTED]
Re: [PATCH] PCRE/regex shakeup part 1
No objections to going ahead with this?
On Thu, Jan 27, 2005 at 03:01:56PM +, Joe Orton wrote:
There are two problems with the use of PCRE in httpd: firstly that there
is no support for use of an external pcre library (PR27750), and
secondly that use of the pcreposix.h interface can cause namespace
collisions with the real POSIX regex API (PR26088, but this is triggered
when trying to solve 27750).
Attached is a patch which addresses the latter issue and prepares for
the use of an external PCRE, based on the patches by Andres Solomon in
27750: implementing the pcreposix.c wrapper inside the ap_ namespace, by
doing:
1. rename pcreposix.h to ap_regex.h (to avoid collisions with any
external pcre), and copy srclib/pcre/pcreposix.c to server/util_pcre.c
2. rename REG_* constants to AP_REG_*, regex_t-ap_regex_t,
regmatch_t-ap_regmatch_t, and ap_* prefix the reg* functions
Because the error handling in the PCRE-based regcomp() relies on a
non-public PCRE interface for mapping error strings to codes, this is
dropped; if ap_regcomp() fails, no specific error code is provided, just
REG_INVARG aka invalid argument. (the regcomp error code is not used
anywhere in httpd so no real difference; this could be improved later)
Two diffs attached: firstly to implement all the above; secondly to
update the rest of the tree to use the new API, you'll need to do
$ cp srclib/pcre/pcreposix.c server/util_pcre.c
$ cp include/pcreposix.h include/ap_regex.h
to apply the svn diff to a trunk checkout.
joe
Index: configure.in
===
--- configure.in (revision 126611)
+++ configure.in (working copy)
@@ -512,6 +512,7 @@
dnl AP_LIBS specifies the actual libraries. note we have some required libs.
AP_LIBS=$abs_builddir/srclib/pcre/libpcre.la $AP_LIBS
+APR_ADDTO(CPPFLAGS, [-I$abs_builddir/srclib/pcre])
dnl APR should go after the other libs, so the right symbols can be picked up
AP_LIBS=$AP_LIBS `$apu_config --link-libtool --libs` `$apr_config
--link-libtool --libs`
Index: include/ap_mmn.h
===
--- include/ap_mmn.h (revision 126611)
+++ include/ap_mmn.h (working copy)
@@ -85,6 +85,8 @@
* ap_setup_prelinked_modules,
ap_process_resource_config
* 20040425.1 (2.1.0-dev) Added ap_module_symbol_t and
ap_prelinked_module_symbols
* 20050101.0 (2.1.2-dev) Axed misnamed http_method for http_scheme (which
it was!)
+ * 20050127.0 (2.1.3-dev) renamed regex_t-ap_regex_t,
regmatch_t-ap_regmatch_t,
+ *REG_*-AP_REG_*, removed reg* in place of ap_reg*
*/
#define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */
Index: include/ap_regex.h
===
--- include/ap_regex.h(revision 126601)
+++ include/ap_regex.h(working copy)
@@ -52,37 +52,24 @@
/* Options defined by POSIX. */
-#define REG_ICASE 0x01
-#define REG_NEWLINE 0x02
-#define REG_NOTBOL0x04
-#define REG_NOTEOL0x08
+#define AP_REG_ICASE 0x01
+#define AP_REG_NEWLINE 0x02
+#define AP_REG_NOTBOL0x04
+#define AP_REG_NOTEOL0x08
/* These are not used by PCRE, but by defining them we make it easier
to slot PCRE into existing programs that make POSIX calls. */
-#define REG_EXTENDED 0
-#define REG_NOSUB 0
+#define AP_REG_EXTENDED 0
+#define AP_REG_NOSUB 0
/* Error values. Not all these are relevant or used by the wrapper. */
enum {
- REG_ASSERT = 1, /* internal error ? */
- REG_BADBR, /* invalid repeat counts in {} */
- REG_BADPAT, /* pattern error */
- REG_BADRPT, /* ? * + invalid */
- REG_EBRACE, /* unbalanced {} */
- REG_EBRACK, /* unbalanced [] */
- REG_ECOLLATE,/* collation error - not relevant */
- REG_ECTYPE, /* bad class */
- REG_EESCAPE, /* bad escape sequence */
- REG_EMPTY, /* empty expression */
- REG_EPAREN, /* unbalanced () */
- REG_ERANGE, /* bad range inside [] */
- REG_ESIZE, /* expression too big */
- REG_ESPACE, /* failed to get memory */
- REG_ESUBREG, /* bad back reference */
- REG_INVARG, /* bad argument */
- REG_NOMATCH /* match failed */
+ AP_REG_ASSERT = 1, /* internal error ? */
+ AP_REG_ESPACE, /* failed to get memory */
+ AP_REG_INVARG, /* bad argument */
+ AP_REG_NOMATCH /* match failed */
};
@@ -92,7 +79,7 @@
void *re_pcre;
size_t re_nsub;
size_t re_erroffset;
-} regex_t;
+} ap_regex_t;
/* The structure in which a captured offset is returned. */
@@ -101,15 +88,46 @@
typedef struct {
regoff_t rm_so;
regoff_t rm_eo;
-} regmatch_t;
+} ap_regmatch_t;
+#ifndef AP_DECLARE
+#define AP_DECLARE(x) x
+#endif /* AP_DECLARE */
+
/* The functions */
-extern int regcomp(regex_t
Re: UNIX MPMs [ot?]
Nick Kew [EMAIL PROTECTED]; [EMAIL PROTECTED]:15 GMT-5 On Thursday 10 February 2005 14:10, Leif W wrote: Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of Apache 2.0.x with all file i/o and cgi being done by a single user, and the perchild MPM being broken. That's rather different. If you care *at all* about security, you won't be running PHP as a module. So suexec is a complete solution there. Does this idea extend to any other modules as well? Are they all insecure simply because of Apache's design? Is that where the security problem lies? The module code can not be run as a separate user with fewer privileges per request? Leif
Re: UNIX MPMs
Nick Maynard wrote: UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) event (experimental) unclear if it works with mod_ssl with pipelining (not tested here yet) Greg
Re: UNIX MPMs
Paul A. Houle wrote: On Linux I've done some benchmarking and found that worker isn't any faster than prefork at serving static pages. (Is it any different on other platforms, such as Solaris?) I'm sure we can tweak worker and event to make them faster, especially in 2.1+ with judicious use of the improved apr atomics. But for now I think it's more important to deal with thread safety in the modules and libraries. In principle you might save RAM by running prefork, I assume you mean worker. some of my customers have reported dramatic RAM savings with worker. but in this day and age you can fit 16 GB in a 1U pretty easily and it's cheaper than hiring a programmer who doesn't know how to track down race conditions, never mind one that does. sure, but if you are using modules + libraries that are know to be thread safe, life is good. Greg
Re: UNIX MPMs
Paul A. Houle wrote: On Linux I've done some benchmarking and found that worker isn't any faster than prefork at serving static pages. (Is it any different on other platforms, such as Solaris?) In principle you might save RAM by running prefork, but in this day and age you can fit 16 GB in a 1U pretty easily and it's cheaper than hiring a programmer who doesn't know how to track down race conditions, never mind one that does. If you know of such a programmer that can quickly identify and fix race conditions, please send him my way. I will give him a job in a second. -Rasmus
Re: UNIX MPMs [ot?]
Sander Striker [EMAIL PROTECTED]; [EMAIL PROTECTED]:35 GMT-5 From: Leif W [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 3:10 PM things which might commonly be used in concert? Is there any direction given from the top of the Apache group in regards to what gets attention? No, there is not. The committers are free to work on what they want. Ok, just wasn't sure how the ASF worked, some combination of directed and volunteer effort or something. Not do this or else strict direction, but please focus energy here if you can, a laidback direction. In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. That's quoted out of context. Security holes get prompt attention. I was referring specifically to security as presented by perchild, as noted in the parenthisized expression below which was part of the same sentence. Sorry if my wording misconstrued the point. (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. [...] Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. I'd be more than happy to scratch this itch, but I haven't the coding ability or speed, testing environment, resources or time right now. I'd do it for the fee of training me how to do it. :p I'll need to consult the reference manuals. If I had financial resources I'd use them to encourage itches like this to be scratched, because when admin get burnt out over a missing feature, I'd like to give back that enthusiasm and fun and peace of mind. Coding is hard work and people deserve something for the time, even if enjoyment of the coding effort is usually enough. FWIW, I try to payback to this specific in the only way I can, by helping on the users list, and occasionally try to submit simpler code to other projects. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. There may be a discrepancy between what developers in general consensus think is vital, what is vital to individual developers, what admin think is vital, or people of different platforms, or what combinations of technologies are being used in concert. I'm thinking vital in terms of a common problem which many experience, for whom various workarounds do not work that well. To that end I am just curious about what it takes to have something of that magnitude eventually committed. If no developers are currently interested in a topic, who reviews it? What if someone applies to be a developer and says this is vital to them and a portion of the user base? Wether RTC or CTR, some patches of a lesser magnitude (affecting only one module for instance) seem to fly right through, yet other patches hang around a long time. I am just curious if status quo vs. who you know plays any part in the process. If so then it has to be planned for and addressed by anyone attempting to make a contribution. I'm not so good figuring this stuff out, so that's why I ask. The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Hmm, sorry, I didn't even see that happening. I did not feel like I was requesting a discussion of the A vs. B, but it maybe opened the wrong door, and I'm sorry for that. I mentioned something about A and B, thought that it might be mistaken for an argument of pro A con B, and stated that I didn't wish to discuss it in that context, and hoped that would be enough. The initial discussion was presented to me as perchild mpm (security) vs winnt mpm (portability), so my initial thoughts were along that line. But as I indicated, I considered the possibility that it was just a coincidence of events, not a directed intent. If I say I prefer A to B, is that wrong? IMO no, because I did not ask anyone to agree, nor ask their opinion, nor tell anyone what to prefer. You don't have to talk about that then. :-) I am not arguing for or against an OS. I just mentioned the three as the OSes to which I have had access, and experience, and to which platform some 3rd party solutions to setuid/setgid (perorphan?) are available and some are not. Of course I'd like a portable
Re: svn commit: r153273 - httpd/httpd/trunk/Makefile.in
--On Thursday, February 10, 2005 4:38 PM + [EMAIL PROTECTED] wrote: Author: jorton Date: Thu Feb 10 08:38:47 2005 New Revision: 153273 URL: http://svn.apache.org/viewcvs?view=revrev=153273 Log: * Makefile.in: Use buildmark.o not .lo since it was COMPILEd not LT_COMPILEd. I'm wondering if buildmark should be LT_COMPILEd instead. What do you think? -- justin
Re: UNIX MPMs [ot?]
Leif W wrote: My only concern is, if some people solved the puzzle externally, then are there barriers which prevent them from getting the code committed? The Metux web pages (official and unofficial) seem to be works in progress. There is a quote which indicates that at least the guy running the unofficial site would like to see this in Apache some day. The ASF doesn't suffer from the not coded here mentality. Many of our successful projects and codebases have originally started life elsewhere. As far as I know, even though internal (to the ASF) development of perchild languished, we did accept patches, etc. So if anyone had wanted to continue working on it, they could have done what countless other developers have done and submitted patches, etc... That's the start towards getting ASF commit privs, becoming a contributor, a PMC member and an ASF member. If Metux would like to donate the code to the ASF, then incubator.apache.org would be a good link to check out first. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: The use of CORE_PRIVATE
On Wed, 09 Feb 2005 11:25:44 +1100, Bojan Smojver wrote: [snip] Is it legal for third party modules to rely on CORE_PRIVATE in order to gain access to functions (and other bits) that would otherwise be out of bounds? For instance, I'm trying to rely on functions that help in creating sub-requests, such as ap_create_request_config(), which is only available if I define CORE_PRIVATE. I'm not sure if that The Right Thing To Do (TM)... I believe it is more of you better know what you are doing while using these functions and structures. It isn't like the Linux kernel's MODULE_LICENSE where if you are GPL you gain access to more of the kernel then if you are not. There are no legal ramifications of using the CORE_PRIVATE as I use it quite a bit in my mod_ftpd module on outoforder.cc
Re: svn commit: r153273 - httpd/httpd/trunk/Makefile.in
On Thu, Feb 10, 2005 at 09:17:20AM -0800, Justin Erenkrantz wrote: --On Thursday, February 10, 2005 4:38 PM + [EMAIL PROTECTED] wrote: Author: jorton Date: Thu Feb 10 08:38:47 2005 New Revision: 153273 URL: http://svn.apache.org/viewcvs?view=revrev=153273 Log: * Makefile.in: Use buildmark.o not .lo since it was COMPILEd not LT_COMPILEd. I'm wondering if buildmark should be LT_COMPILEd instead. What do you think? -- justin I thought exactly that, then I found that LT_COMPILE could only be used in an implicit rule since it uses $ and $@, so that's a no-go. I don't think that using a .o directly on a libtool link line poses any problems, so it should be OK like this. Very nice to have the thing rebuilt only when necessary now! joe
Re: UNIX MPMs
On 10 Feb 2005, at 16:45, Rasmus Lerdorf wrote: If you know of such a programmer that can quickly identify and fix race conditions, please send him my way. I will give him a job in a second. It kind of depends how well the races are hidden, doesn't it? :) -- Andy Armstrong, hexten.net
[PATCH] 2.0.x remove formatting from ap_log_error calls
Patch against 2.0.x of below.
-- Forwarded message --
From: Eric Covener [EMAIL PROTECTED]
Date: Wed, 9 Feb 2005 09:36:09 -0500
Subject: [PATCH] remove formatting from ap_log_error calls
To: dev@httpd.apache.org
ap_log_error escapes escape sequences such as newline and tab so that
they appear as the two-character strings \t or \n in error_log
(unless httpd was built with -DAP_UNSAFE_ERROR_LOG_UNESCAPED) as
fallout from CAN-2003-0020
Some callers throughout the code still send '\n' within the string
argument sent to ap_log_error, trivial patch attached removes the
formatting from these calls.
--
Eric Covener
[EMAIL PROTECTED]
Index: server/mpm/winnt/mpm_winnt.c
===
--- server/mpm/winnt/mpm_winnt.c (revision 152672)
+++ server/mpm/winnt/mpm_winnt.c (working copy)
@@ -668,7 +668,7 @@
if ((rv = apr_procattr_io_set(attr, APR_FULL_BLOCK,
APR_NO_PIPE, APR_NO_PIPE)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, ap_server_conf,
-Parent: Unable to create child stdin pipe.\n);
+Parent: Unable to create child stdin pipe.);
apr_pool_destroy(ptemp);
return -1;
}
@@ -679,7 +679,7 @@
|| ((rv = apr_procattr_child_out_set(attr, child_out, NULL))
!= APR_SUCCESS)) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, ap_server_conf,
-Parent: Unable to connect child stdout to NUL.\n);
+Parent: Unable to connect child stdout to NUL.);
apr_pool_destroy(ptemp);
return -1;
}
@@ -697,7 +697,7 @@
if ((rv = apr_procattr_child_err_set(attr, child_err, NULL))
!= APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, ap_server_conf,
-Parent: Unable to connect child stderr.\n);
+Parent: Unable to connect child stderr.);
apr_pool_destroy(ptemp);
return -1;
}
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 152672)
+++ modules/proxy/proxy_util.c (working copy)
@@ -707,7 +707,7 @@
if (bits != 32) /* no warning for fully qualified IP address */
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- Warning: NetMask not supplied with IP-Addr; guessing: %s/%ld\n,
+ Warning: NetMask not supplied with IP-Addr; guessing: %s/%ld,
inet_ntoa(This-addr), bits);
}
@@ -715,11 +715,11 @@
if (*addr == '\0' (This-addr.s_addr ~This-mask.s_addr) != 0) {
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- Warning: NetMask and IP-Addr disagree in %s/%ld\n,
+ Warning: NetMask and IP-Addr disagree in %s/%ld,
inet_ntoa(This-addr), bits);
This-addr.s_addr = This-mask.s_addr;
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- Set to %s/%ld\n,
+ Set to %s/%ld,
inet_ntoa(This-addr), bits);
}
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 152672)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -553,7 +553,7 @@
if (renegotiate !renegotiate_quick (r-method_number == M_POST)) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
SSL Re-negotiation in conjunction
- with POST method not supported!\n
+ with POST method not supported!
hint: try SSLOptions +OptRenegotiate);
return HTTP_METHOD_NOT_ALLOWED;
@@ -1794,7 +1794,7 @@
else if (where SSL_CB_ALERT) {
char *str = (where SSL_CB_READ) ? read : write;
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
- %s: Alert: %s:%s:%s\n,
+ %s: Alert: %s:%s:%s,
SSL_LIBRARY_NAME, str,
SSL_alert_type_string_long(rc),
SSL_alert_desc_string_long(rc));
Re: The use of CORE_PRIVATE
On Thu, 2005-02-10 at 12:56 -0500, Edward Rudd wrote: On Wed, 09 Feb 2005 11:25:44 +1100, Bojan Smojver wrote: [snip] Is it legal for third party modules to rely on CORE_PRIVATE in order to gain access to functions (and other bits) that would otherwise be out of bounds? For instance, I'm trying to rely on functions that help in creating sub-requests, such as ap_create_request_config(), which is only available if I define CORE_PRIVATE. I'm not sure if that The Right Thing To Do (TM)... I believe it is more of you better know what you are doing while using these functions and structures. It isn't like the Linux kernel's MODULE_LICENSE where if you are GPL you gain access to more of the kernel then if you are not. There are no legal ramifications of using the CORE_PRIVATE as I use it quite a bit in my mod_ftpd module on outoforder.cc I see now that I asked this question the wrong way... Sorry :-( When I said legal, I meant that in the technical sense. Along the lines of if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice? Basically, are functions and other bits available under CORE_PRIVATE a fair game for module developers or are they in publicly available headers by some historical accident? Are they standard part of the API, but as you said for the ones that know what they're doing (which would then exclude me :-)? -- Bojan
[PATCH] Log 408
Another set of eyes please :)
Index: server/protocol.c
===
--- server/protocol.c (revision 153271)
+++ server/protocol.c (working copy)
@@ -880,6 +880,12 @@
return r;
}
+if (r-status == HTTP_REQUEST_TIME_OUT
r-connection-keepalive != AP_CONN_KEEPALIVE) {
+r-the_request = ;
+ap_update_child_status(conn-sbh, SERVER_BUSY_LOG, r);
+ap_run_log_transaction(r);
+}
+
apr_brigade_destroy(tmp_bb);
return NULL;
}
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
There 10 types of people: those who read binary and everyone else.
Re: http TLS Upgrade (was RFC for a Perchild-like-MPM)
At 07:24 AM 2/10/2005, Leif W wrote: Hi. I hang out mostly on the users list, but have played with basic HTTPS configuration (using SSL or TLS). As I understand, HTTPS works fine with any VirtualHost, so long as it is based on a unique ip:port combination. That is the current alternative to name-based virtual hosting. It doesn't necessarily mean you need a unique ip address, if you're willing or able to use non-standard ports. Otherwise it does require unique ip addresses and port 443. That is IP Based Virtual Hosting. Yes - that's an accurate summary. I guess it is somewhat of a misnomer. It should be Socket Based Virtual Hosting, but IPBVH implies that only default ports are used. Oh no, IP based vhosts don't imply any such thing. Plenty of folks use port 80 for public services, port 8080 for private (dav or what ever other) services, and this is before you introduce SSL. Socket Based? That implies inetd hosting, where the server is given a socket from an external socket management app (e.g. inetd.) Beware that's a much more confusing term for this case. If you must use a single ip:port combination for HTTPS, then it's not possible, due to the point at which the SSL/TLS layers takes over to ensure the ultimate security of the connection. Yes. I'm not an expert with SSL or TLS, but my intuitive response would be to modify the HTTPS protocol to establish an unsecured connection, send the host header (ignore anything else) to pick the right certificate, and then use that to secure the connection. This is brought up ever three months by another user, and we point each of you here; Upgrading to TLS Within HTTP/1.1 [May, 2000] ftp://ftp.rfc-editor.org/in-notes/rfc2817.txt and point out that, obviously, great minds think alike, but that there are real-world obstacles to adopting this protocol for user browser clients. There are, of course, no obstacles for the use of this mechanism for automation, which is why it's ideal for things such as securing http based print servers (which Novell and others already do) and potentially things such as Subversion. Therefore this handshaking mechanism is already supported in httpd-2.1 (to become httpd-2.2 general release.) Rather than the SSLEngine On|Off directive, you can add to this mix a new SSLEngine optional flavor. http://httpd.apache.org/docs-2.1/mod/mod_ssl.html#sslengine The bottom line, however... let's suggest that tomorrow you offer a patch to Firefox, and it's adopted next week. Sometime a few months from now, it goes out in a new release. Then someone backports to Mozilla, say about 12 weeks later. This protocol is not https:// because that scheme designates a connection to a pipeline entirely encrypted within SSL/TLS. But if the user types http:// - how do they say but make it secure!!!? The protocol is http://, you have to find a GUI means of demanding security. [Perhaps, the lock 'icon' becomes a lock 'button' - which the user can toggle domain by domain. Such are the issues that browser writes must struggle with.] With 2% of the browsers supporting it, say that Microsoft gets behind it, and spends 2 months in their security group discussing how it can be less misleading in everyday use. Now if they decide that the next version gets the patch, and it's pushed out with all new Win2003 SP3 installs, it's still 18 months from seeing any significant uptake. It will be, basically, 5 years for this to actually have the impact that you ask for - to be able to fold 50 SSL hosts into a single IP address for mass vhosting. It is a very, very long time away before you can turn away users of circa 2005 browsers. But my intuition also tells me that this would probably open up some avenues for attacks which might seriously degrade the effectiveness as compared to securing a connection from the outset, or otherwise add many levels of complexity and possibly inefficiency to ensure the connection is secured after some data was transferred. Actually, because both client and server advertise and can each determine if encryption is desirable, it's a reasonable approach. Because the client, from the outset, can use an OPTIONS method to secure the connection for all future headers, there is quite a bit of security. As far as degradation, handshaking and crypting SSL are far more painful CPU wise than any header processing you can invent (short of computing MD5 sums on the fly for huge download bodies.) The fact that you can end up mixing encrypted and non-encrypted bodies based on sensitivity is actually a performance advantage, if the data that is not sensitive is not encrypted. Until I find the time to educate myself about the HTTPS, SSL and TLS protocols, and practice using something like OpenSSL and the Apache 2.x module programming, then I personally can't explore the feasability or implementation of such things. But hopefully someone else beats me to it. It's there for your use today ... by the time you hack the
Re: [PATCH] 2.0.x remove formatting from ap_log_error calls
On Thu, 10 Feb 2005 14:02:02 -0500, Eric Covener [EMAIL PROTECTED] wrote: Patch against 2.0.x of below. There is at least one other such fix that is in trunk but not in 2.0.x. See http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/server/mpm_common.c?rev=102772r1=102686r2=102772 Care to add that and possibly other similar fixes to your patch and post again? That way, folks who would approve it for the 2.0.x branch would only have to look at one patch. Thanks, Jeff
Re: The use of CORE_PRIVATE
Bojan Smojver wrote: if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice? I think the answer to this is similar to the old line if you need to ask how much it costs you can't afford it. ;) --Geoff
Re: The use of CORE_PRIVATE
On Fri, Feb 11, 2005 at 06:26:00AM +1100, Bojan Smojver wrote: ... When I said legal, I meant that in the technical sense. Along the lines of if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice? Basically, are functions and other bits available under CORE_PRIVATE a fair game for module developers or are they in publicly available headers by some historical accident? Are they standard part of the API, but as you said for the ones that know what they're doing (which would then exclude me :-)? They are not part of the public API. They are very subject to removal, change, or other bastardization at a whim. A number of modules within the httpd distribution erroneously set that #define and then use stuff. But we can always fix those things if we make changes to the hidden APIs. I can think of at least two points in the past where some of us have said, this is crap! we should move all this gunk to a private header! Great idea, but nobody has been peeved enough to do it. So yah: you run a risk of you use them. If you *do* need something hidden by CORE_PRIVATE, then bring it up along with a rationale for why that thing should be made public. That's your best solution. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: The use of CORE_PRIVATE
Greg Stein wrote: On Fri, Feb 11, 2005 at 06:26:00AM +1100, Bojan Smojver wrote: ... When I said legal, I meant that in the technical sense. Along the lines of if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice? Basically, are functions and other bits available under CORE_PRIVATE a fair game for module developers or are they in publicly available headers by some historical accident? Are they standard part of the API, but as you said for the ones that know what they're doing (which would then exclude me :-)? They are not part of the public API. They are very subject to removal, change, or other bastardization at a whim. So, there is no guaranteed binary compat for any module that defines CORE_PRIVATE?
Re: The use of CORE_PRIVATE
--On Thursday, February 10, 2005 4:57 PM -0800 Paul Querna [EMAIL PROTECTED] wrote: So, there is no guaranteed binary compat for any module that defines CORE_PRIVATE? I would think that any module that #define's CORE_PRIVATE is on its own and righly so. -- justin
Re: The use of CORE_PRIVATE
Quoting Greg Stein [EMAIL PROTECTED]: If you *do* need something hidden by CORE_PRIVATE, then bring it up along with a rationale for why that thing should be made public. That's your best solution. Get it. For example, function ap_create_request_config() is required in order to create request_config for every new request. It knows about some internal sizes and the like. It is under CORE_PRIVATE, so any module that needs to construct an internal request is out of luck. I would think that many modules construct and execute internal requests via ap_process_request_internal(), so this is bread and butter stuff (for instance, I can see a use of it in xs/Apache/RequestUtil/Apache__RequestUtil.h of mod_perl 2.0.0-RC4). I don't have the other functions that I needed handy, but I will post them back to the thread a bit later on. -- Bojan
