mod_authnz_mysql
Hi, I tried to convert mod_auth_mysql to mod_authnz_mysql. Don't expect too much, it's my first contact with Apache modules. Code is here: https://github.com/machtfuernacht/mod_authnz_mysql What I did in a few words: - Took the sources from http://packages.debian.org/squeeze/libapache2-mod-auth-mysql (4.3.9-13) - Added the mutex patch from Rotem Ringel ro...@jungo.com http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603445 - Dropped a lot of redundant config options - Added mysql AuthBasicProvider - Dropped Apache 1.x support What I did not: - Enough testing. It does what I need though. ;) Regards Christopher Dyck
Re: EOL for 2.0
On 16.09.2011 17:59, William A. Rowe Jr. wrote: On 9/16/2011 12:51 AM, Issac Goldstand wrote: IIRC, we talked about making 2.0 EOL when we make the next release, but I don't think we ever formalized the decision. Does anyone have comments for or against announcing 2.0 End-Of-Life at a set time (say 3 months) following the release of 2.4? Yes, I'd prefer we set a 12 month sunset on 2.0 in conjunction with the 2.4 release, not 3 months later when nobody is paying attention. +1, 3 months is a bit quick, 12 months should be OK. Regards, Rainer
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 14.09.2011 22:32, Daniel Ruggeri wrote: My usage tests pass muster with the approach we have discussed, so I have updated trunk and the 2.2 backport proposal. At this point, I am satisfied with this particular patch, though I won't lose sight of the server-side issue. Since the patch should now be complete, I have given my vote in the 2.2 STATUS file and would appreciate any further review/votes. Looks good, judging from my (admittedly not very comprehensive) testing. +chain = X509_STORE_CTX_get1_chain(sctx); +sk_X509_shift(chain); +i=sk_X509_num(chain); pkp-ca_certs[n] = chain; I think with the sk_X509_shift(chain) line, we're leaking an X509 struct... maybe Steve can confirm (?). Adding a short comment as to why the first cert is dropped would be useful IMO, too. Second point, somewhat related: if we end up with an empty chain at this point, then it seems preferrable to me to discard/free the STACK_OF(X509) right on the spot (and not store it in pkp-ca_certs). Kaspar
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 17/09/2011 11:37, Kaspar Brand wrote: On 14.09.2011 22:32, Daniel Ruggeri wrote: My usage tests pass muster with the approach we have discussed, so I have updated trunk and the 2.2 backport proposal. At this point, I am satisfied with this particular patch, though I won't lose sight of the server-side issue. Since the patch should now be complete, I have given my vote in the 2.2 STATUS file and would appreciate any further review/votes. Looks good, judging from my (admittedly not very comprehensive) testing. +chain = X509_STORE_CTX_get1_chain(sctx); +sk_X509_shift(chain); +i=sk_X509_num(chain); pkp-ca_certs[n] = chain; I think with the sk_X509_shift(chain) line, we're leaking an X509 struct... maybe Steve can confirm (?). Adding a short comment as to why the first cert is dropped would be useful IMO, too. Yes you need store the returned value and free it with X509_free(). Note also that because you ignore return values of X509_verify_cert() you might have a situation where the chain is not complete and so deleting the last element will remove a non-root CA. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: With IP address in Host: header ServerName/ServerAlias doesn't work
Hi Rüdiger, Am 09.09.2011 11:45, schrieb Plüm, Rüdiger, VF-Group: Please update the bug report: 1. Declare the unneeded patch obsolete. 2. Update the needed patch to be against trunk. Done. See https://issues.apache.org/bugzilla/show_bug.cgi?id=51709 What else is needed to get it applied to trunk? Regards, Micha
Re: svn commit: r1171247 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h include/mod_core.h modules/http/http_core.c modules/proxy/balancers/mod_lbmethod_heartbeat.c modules/proxy/mo
On 09/16/2011 07:02 PM, Stefan Fritsch wrote:
On Fri, 16 Sep 2011, Ruediger Pluem wrote:
On 09/15/2011 09:53 PM, s...@apache.org wrote:
Author: sf
Date: Thu Sep 15 19:53:59 2011
New Revision: 1171247
URL: http://svn.apache.org/viewvc?rev=1171247view=rev
Log:
Create wrapper API for apr_random;
use in mod_lbmethod_heartbeat and mod_serf to
- replace some needles use of apr_generate_random_bytes
- remove code duplication
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/include/ap_mmn.h
httpd/httpd/trunk/include/httpd.h
httpd/httpd/trunk/include/mod_core.h
httpd/httpd/trunk/modules/http/http_core.c
httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_heartbeat.c
httpd/httpd/trunk/modules/proxy/mod_serf.c
httpd/httpd/trunk/server/core.c
Modified: httpd/httpd/trunk/server/core.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1171247r1=1171246r2=1171247view=diff
==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Thu Sep 15 19:53:59 2011
@@ -20,6 +20,7 @@
#include apr_fnmatch.h
#include apr_hash.h
#include apr_thread_proc.h/* for RLIMIT stuff */
+#include apr_random.h
#define APR_WANT_IOVEC
#define APR_WANT_STRFUNC
@@ -4593,12 +4594,93 @@ AP_DECLARE(int) ap_state_query(int query
}
}
+static apr_random_t *rng = NULL;
+#if APR_HAS_THREADS
+static apr_thread_mutex_t *rng_mutex = NULL;
+
+static void create_rng_mutex(apr_pool_t *pchild, server_rec *s)
+{
+int threaded_mpm;
+if (ap_mpm_query(AP_MPMQ_IS_THREADED, threaded_mpm) !=
APR_SUCCESS)
+return;
+if (threaded_mpm)
+apr_thread_mutex_create(rng_mutex,
APR_THREAD_MUTEX_DEFAULT, pchild);
Shouldn't we use ap_mutex API here to let the user configure the mutex
method?
This is a thread mutex, ap_mutex is only for proc and global mutexes. I
don't think it is necessary to be able to choose between the thread
mutex types (nested, unnested, default).
As always, thanks for the clarification :-)
Regards
Rüdiger
Re: EOL for 2.0
On 09/17/2011 12:25 PM, Rainer Jung wrote: On 16.09.2011 17:59, William A. Rowe Jr. wrote: On 9/16/2011 12:51 AM, Issac Goldstand wrote: IIRC, we talked about making 2.0 EOL when we make the next release, but I don't think we ever formalized the decision. Does anyone have comments for or against announcing 2.0 End-Of-Life at a set time (say 3 months) following the release of 2.4? Yes, I'd prefer we set a 12 month sunset on 2.0 in conjunction with the 2.4 release, not 3 months later when nobody is paying attention. +1, 3 months is a bit quick, 12 months should be OK. +1 Regards Rüdiger
Re: [PATCH 51709] With IP address in Host: header ServerName/ServerAlias doesn't work
Hi,
Am 09.09.2011 11:45, schrieb Plüm, Rüdiger, VF-Group:
2. Update the needed patch to be against trunk.
Once again with attached patch for issue 51709, ready for review. Please
review it and consider it for commit.
Thanks,
Micha
Index: httpd-trunk/server/vhost.c
===
--- httpd-trunk/server/vhost.c (Revision 1171988)
+++ httpd-trunk/server/vhost.c (Arbeitskopie)
@@ -860,9 +860,11 @@
const char *host = r-hostname;
apr_port_t port;
server_rec *s;
+server_rec *virthost_s;
server_rec *last_s;
name_chain *src;
+virthost_s = NULL;
last_s = NULL;
port = r-connection-local_addr-port;
@@ -889,23 +891,34 @@
s = src-server;
-/* does it match the virthost from the sar? */
-if (!strcasecmp(host, sar-virthost)) {
-goto found;
+/* If we still need to do ServerName and ServerAlias checks for this
+ * server, do them now.
+ */
+if (s != last_s) {
+/* does it match any ServerName or ServerAlias directive? */
+if (matches_aliases(s, host)) {
+goto found;
+}
}
-
-if (s == last_s) {
-/* we've already done ServerName and ServerAlias checks for this
- * vhost
- */
-continue;
-}
last_s = s;
-if (matches_aliases(s, host)) {
-goto found;
+/* Fallback: does it match the virthost from the sar? */
+if (!strcasecmp(host, sar-virthost)) {
+/* only the first match is used */
+if (virthost_s == NULL) {
+virthost_s = s;
+}
}
}
+
+/* If ServerName and ServerAlias check failed, we end up here. If it
+ * matches a VirtualHost, virthost_s is set. Use that as fallback
+ */
+if (virthost_s) {
+s = virthost_s;
+goto found;
+}
+
return;
found:
Re: svn commit: r1171250 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Fri, 16 Sep 2011, Ruediger Pluem wrote:
On 09/15/2011 09:55 PM, s...@apache.org wrote:
Author: sf
Date: Thu Sep 15 19:55:27 2011
New Revision: 1171250
URL: http://svn.apache.org/viewvc?rev=1171250view=rev
Log:
use random value as multipart range boundary to prevent leaking information
about the used MPM
Modified:
httpd/httpd/trunk/modules/http/byterange_filter.c
Modified: httpd/httpd/trunk/modules/http/byterange_filter.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/byterange_filter.c?rev=1171250r1=1171249r2=1171250view=diff
==
--- httpd/httpd/trunk/modules/http/byterange_filter.c (original)
+++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Sep 15 19:55:27 2011
@@ -505,17 +504,15 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
if (num_ranges 1) {
/* Is ap_make_content_type required here? */
const char *orig_ct = ap_make_content_type(r, r-content_type);
-boundary = apr_psprintf(r-pool, % APR_UINT64_T_HEX_FMT %lx,
-(apr_uint64_t)r-request_time, c-id);
ap_set_content_type(r, apr_pstrcat(r-pool, multipart,
use_range_x(r) ? /x- : /,
byteranges; boundary=,
- boundary, NULL));
+ ap_multipart_boundary, NULL));
Isn't it an issue that we now always use the same boundary value?
I didn't see a reason why this would be a problem. Do you? The old
boundary value was also rather predictable.
Re: svn commit: r1171250 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On 09/17/2011 05:03 PM, Stefan Fritsch wrote:
On Fri, 16 Sep 2011, Ruediger Pluem wrote:
On 09/15/2011 09:55 PM, s...@apache.org wrote:
Author: sf
Date: Thu Sep 15 19:55:27 2011
New Revision: 1171250
URL: http://svn.apache.org/viewvc?rev=1171250view=rev
Log:
use random value as multipart range boundary to prevent leaking
information
about the used MPM
Modified:
httpd/httpd/trunk/modules/http/byterange_filter.c
Modified: httpd/httpd/trunk/modules/http/byterange_filter.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/byterange_filter.c?rev=1171250r1=1171249r2=1171250view=diff
==
--- httpd/httpd/trunk/modules/http/byterange_filter.c (original)
+++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Sep 15
19:55:27 2011
@@ -505,17 +504,15 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
if (num_ranges 1) {
/* Is ap_make_content_type required here? */
const char *orig_ct = ap_make_content_type(r, r-content_type);
-boundary = apr_psprintf(r-pool, % APR_UINT64_T_HEX_FMT
%lx,
-(apr_uint64_t)r-request_time, c-id);
ap_set_content_type(r, apr_pstrcat(r-pool, multipart,
use_range_x(r) ? /x- :
/,
byteranges; boundary=,
- boundary, NULL));
+ ap_multipart_boundary,
NULL));
Isn't it an issue that we now always use the same boundary value?
I didn't see a reason why this would be a problem. Do you? The old
boundary value was also rather predictable.
I don't know. My point was rather that it is predictable, but that it might
be needed to be different on each response. Protocol gurus, any idea?
Regards
Rüdiger
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 9/17/2011 6:02 AM, Dr Stephen Henson wrote:
Yes you need store the returned value and free it with X509_free().
Note also that because you ignore return values of X509_verify_cert() you
might
have a situation where the chain is not complete and so deleting the last
element will remove a non-root CA.
Both suggestions make sense - here is what was just committed to
trunk... I also added logging of verification failures at WARNING level.
Since I was in the file again anyhow, I added logging at DEBUG of what
gets loaded and the order so there is no ambiguity.
...
for (n = 0; n ncerts; n++) {
int i, res;
char cert_cn[256];
X509_INFO *inf = sk_X509_INFO_value(pkp-certs, n);
X509_NAME *name = X509_get_subject_name(inf-x509);
X509_NAME_oneline(name, cert_cn, sizeof(cert_cn));
X509_STORE_CTX_init(sctx, store, inf-x509, NULL);
res=X509_verify_cert(sctx);
chain = X509_STORE_CTX_get1_chain(sctx);
if (res == 1) {
/* Removing the client cert if verification is OK
* could save a loop when choosing which cert to send
* when more than one is available */
/* XXX: This is not needed if we collapse the two
* checks in ssl_engine_kernel in the future */
X509_free(sk_X509_shift(chain));
}
else {
int n = X509_STORE_CTX_get_error(sctx);
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
SSL proxy client cert chain verification
failed for %s: %s,
cert_cn, X509_verify_cert_error_string(n));
}
ERR_clear_error();
i = sk_X509_num(chain);
pkp-ca_certs[n] = chain;
if (i == 0 || (res != 1 i == 1) ) {
/* zero or only the client cert won't be very useful
* due to verification failure */
sk_X509_pop_free(chain, X509_free);
i = 0;
pkp-ca_certs[n] = NULL;
}
X509_STORE_CTX_cleanup(sctx);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
loaded %i intermediate CA%s for cert %i (%s),
i, i == 1 ? : s, n, cert_cn);
if (i 0) {
int j;
for (j=0; ji; j++) {
char ca_cn[256];
X509_NAME *ca_name =
X509_get_subject_name(sk_X509_value(chain, j));
X509_NAME_oneline(ca_name, ca_cn, sizeof(ca_cn));
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, %i: %s, j,
ca_cn);
}
}
}
X509_STORE_CTX_free(sctx);
...
--
Daniel Ruggeri
Re: EOL for 2.0
On Sep 16, 2011, at 11:59 AM, William A. Rowe Jr. wrote: On 9/16/2011 12:51 AM, Issac Goldstand wrote: IIRC, we talked about making 2.0 EOL when we make the next release, but I don't think we ever formalized the decision. Does anyone have comments for or against announcing 2.0 End-Of-Life at a set time (say 3 months) following the release of 2.4? Yes, I'd prefer we set a 12 month sunset on 2.0 in conjunction with the 2.4 release, not 3 months later when nobody is paying attention. +1. While I'd like to be rid of it earlier, I think 3 months is too fast. 12 months may be too long, but we lose nothing by setting it there rather than too short. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On Sep 15, 2011, at 9:01 AM, Jim Jagielski wrote: I plan on push for a GA in Oct (of this year)… The only 2 showstoppers I see as reasonable are the documentation ones and the mod_fcgid one. Could you enumerate what you feel is lacking in the documentation? I know of several modules that are effectively undocumented, and a few more that have minimal, but insufficient documentation. I'd like to hear your take on this. As always, I'm willing to whatever I can on the editing, formatting, etc, side of things, but the raw info needs to come from somewhere. Please let me know where I can be of assistance. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Documentation clarification: ErrorLogFormat
In the documentation for the ErrorLogFormat directive, log format strings are given as, for example, %...A What does the ... signify? It's not clear to me either from the doc (which doesn't mention it) or the source what that's supposed to signify. Thanks for any light anyone can shed on this for me. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Documentation clarification: ErrorLogFormat
On Sep 17, 2011, at 10:56 PM, Rich Bowen wrote: In the documentation for the ErrorLogFormat directive, log format strings are given as, for example, %...A What does the ... signify? It's not clear to me either from the doc (which doesn't mention it) or the source what that's supposed to signify. My apologies. It *is* mentioned in the documentation. It's where the modifier (-, +, or a number 1-15 signifying the log level) goes. I'll add some examples in there so that people, like myself, who can't read, don't overlook it. :) -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
mod_cache incompatible with efficient PHP?
According to this thread on serverfault: http://serverfault.com/questions/74025/apaches-mod-cache-not-caching-fcgi-php-output and this dormant bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=48364 the use of Action directives to handle php requests (or indeed any type of request) breaks mod_cache. I believe Action is a key part of the standard / recommended way to use php with fcgi, and fcgi is needed for even moderate efficiency. Being able to use mod_cache with PHP seems like a pretty important use case. Is there hope for an Apache-only caching solution for php sites? Thank you!
