[RELEASE CANDIDATE] Apache-Test 1.21
a release candidate for Apache-Test 1.21 is now available. http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. --Geoff Changes since 1.20: fix Apache::TestConfig (was missing 'use lib' before using lib::import) [William McKee [EMAIL PROTECTED]] TestConfigPerl will now configure mod_perl last, giving mod_perl highest priority throughout the httpd lifecycle. [Geoffrey Young] Apache::TestConfig::untaint_path needs to remove empty entries in the PATH list, since -T considers those tainted too. [Stas] add Apache::TestHarnessPHP which allows for running client-side scripts via php instead of perl. [Geoffrey Young]
Re: [RELEASE CANDIDATE] Apache-Test 1.21
On Mar 21, 2005, at 9:57 AM, Geoffrey Young wrote: a release candidate for Apache-Test 1.21 is now available. http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. +1 on Sol8... SUSE 9.2 and OS X later on today :)
Re: Apache2 troubles with shmcb SSLSessionCache...
On Fri, Mar 18, 2005 at 12:12:15PM -0500, Daniel Freedman wrote: Anyway, I'm using apache 2.0.53 (mpm-prefork) on Debian testing on two different ia32 machines, with generally similar installs, and exhibiting the following problem only on one of them (which complicates the problem, in my analysis). Are you using the Debian-packaged version of httpd, or compiling from source? Namely, apache2 won't properly start if I include the following directive in my configuration file: SSLSessionCache shmcb:/var/log/apache2/scache(512000) I get the following error in my logs: [error] Cannot allocate shared memory: (22)Invalid argument Can you run the httpd process under strace to see exactly what is failing? strace -o /tmp/httpd.trace /path/to/httpd -X then upload /tmp/httpd.trace somewhere. joe
Re: 2.1.4 available for testing
At 06:44 AM 3/20/2005, Graham Leggett wrote: Oden Eriksson wrote: Ahh! I thought that loading order was something from the past? The order of modules is no longer important for configuration purposes (as I understand), but it is important for practical reasons when one module depends on another module, for example in this case where mod_authnz_ldap depends on mod_ldap. It would be nice if before 2.2 we got around to changing the mod_ldap api to register optional functions. It will still fail to start if the user didn't load mod_ldap, but at least we would accept them loaded in either order.
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
At 11:26 PM 3/19/2005, [EMAIL PROTECTED] wrote: Author: pquerna Date: Sat Mar 19 21:26:22 2005 New Revision: 158303 URL: http://svn.apache.org/viewcvs?view=revrev=158303 Log: Test for APR and APR-Util one directory bellow httpd too. I like not having to put them inside srclib. grumf I'm not keen on this change, since it complicates things unnecessarily - some day we discover a tag and roll organized like this out of the blue? Does config.nice not do what you want? Especially if you rename it config.me with all your absolute options that you don't tweak?
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
On Mon, Mar 21, 2005 at 05:19:56PM -0600, William A. Rowe, Jr. wrote: grumf I'm not keen on this change, since it complicates things unnecessarily - some day we discover a tag and roll organized like this out of the blue? Does config.nice not do what you want? Especially if you rename it config.me with all your absolute options that you don't tweak? Since moving to Subversion, having apr and apr-util at the same level as httpd is my typical working copy layout, so I'm definitely +1 on this change. srclib/apr and srclib/apr-util don't really make sense anymore, IMO. -- justin
Http/APR
Hello, Just wondering, if I install APR 1.X and then attempt to compile apache 2.0.X, can it use the newer APR? or does it use the built in 0.9.X version of apr? -- Nathanael D. Noblet Gnat Solutions 204 - 131 Gorge Road E Victoria, BC V9A 1L1 T 250.385.4613 C 250.893.4613 http://www.gnat.ca/
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
William A. Rowe, Jr. wrote: At 11:26 PM 3/19/2005, [EMAIL PROTECTED] wrote: Author: pquerna Date: Sat Mar 19 21:26:22 2005 New Revision: 158303 URL: http://svn.apache.org/viewcvs?view=revrev=158303 Log: Test for APR and APR-Util one directory bellow httpd too. I like not having to put them inside srclib. grumf I'm not keen on this change, since it complicates things unnecessarily - some day we discover a tag and roll organized like this out of the blue? What do you mean? I thought that the future goal was to unbundle apr* in httpd releases? So you're afraid of tagged and rolled (actually only rolled, since tags don't include apr* anyway) tarballs that don't contain srclib/apr* before we actually wish to unbundle? Isn't that the RM's responsibility? Does config.nice not do what you want? Especially if you rename it config.me with all your absolute options that you don't tweak? I don't see how that would help towards the unbundling goal. Also for development purposes it's way more convenient to allow apr* next to httpd as to require it be in srclib/. Sander
Re: Http/APR
On Mon, 21 Mar 2005, Nathanael Noblet wrote: Just wondering, if I install APR 1.X and then attempt to compile apache 2.0.X, can it use the newer APR? or does it use the built in 0.9.X version of apr? Apache 2.0.x is tied to APR 0.9.x for backward compatibility reasons. That doesn't stop you from having a concurrent installation of APR 1.x on the same machine, but Apache 2.0.x will not use it. --Cliff
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
Sander Striker wrote: William A. Rowe, Jr. wrote: At 11:26 PM 3/19/2005, [EMAIL PROTECTED] wrote: Author: pquerna Date: Sat Mar 19 21:26:22 2005 New Revision: 158303 URL: http://svn.apache.org/viewcvs?view=revrev=158303 Log: Test for APR and APR-Util one directory bellow httpd too. I like not having to put them inside srclib. grumf I'm not keen on this change, since it complicates things unnecessarily - some day we discover a tag and roll organized like this out of the blue? What do you mean? I thought that the future goal was to unbundle apr* in httpd releases? So you're afraid of tagged and rolled (actually only rolled, since tags don't include apr* anyway) tarballs that don't contain srclib/apr* before we actually wish to unbundle? Isn't that the RM's responsibility? My feeling is that it is the RM's responsibility. It does tell you which APR/APR-Util path it is using, so it doesn't leave you completely clueless. Does config.nice not do what you want? Especially if you rename it config.me with all your absolute options that you don't tweak? I don't see how that would help towards the unbundling goal. Also for development purposes it's way more convenient to allow apr* next to httpd as to require it be in srclib/. Yep, i was tried of passing --with-apr and --with-apr-util to ./buildconf -- this has nothing to do with ./config.nice, and I thought making a ./buildconf.nice would of been a little excessive. -Paul
Re: svn commit: r125465 httpd/httpd/trunk/modules/ldap/util_ldap.c
The referenced commit added two OR_ALL directives to util_ldap: LDAPTrustedClientCert LDAPTrustedMode However, that module has no per-directory config struct; all configuration is stored in per-server structs. Consequently, as far as I can see, the OR_ALL directives are unworkable. In particular, LDAPTrustedClientCert, if invoked in an .htaccess file, will: a) store a pointer to request-pool-allocated strings in a config-pool-allocated array b) tromp on changes being made in another thread reading an .htaccess file in the same vhost. Even if it were not for that, it seems odd to me that the configuration merge function appends the parent array of client certs to the current array of client certs; I think that is counter to the idea that a directory might have its own local collection of client certs. (Accumulating the global certs seems more reasonable.) As it stands, if my analysis is correct, the use of LDAPTrustedClientCert in an .htaccess file would probably cause a child to segfault; in a threaded mpm, the consequences would be even more serious. Until a more thorough review is done, it would probably be a good idea to change the directives to RSRC_CONF, or disable them altogether. Rici
Re: ap_mmn.h Update
Was never explicitly exported and not namespace protected. If you want it re-added, by all means. Just needs ap_ namespace decoration. At 04:18 PM 3/19/2005, NormW wrote: Greetings All, Found the following in ap_mmn.h, but darned if I can find a thread that discusses the reason for its removal or offers an alternate approach; the term 'axed' seems visually aggressive... * 20050217.0 (2.1.3-dev) Axed find_child_by_pid,... Any assistance appreciated, Norm
