RE: [mod_python] ANNOUNCE: Mod_python 3.3.0b (Beta)
I have been testing with this version for some time no And as far as I can see this version is the most stable, reliable and memory leak free version of mod_python I have seen so far. The new importer makes development much better since you do not have to restart Apache for every module change. I suggest everybody starts using this on their development systems, I took it in production yesterday Martijn -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Gregory (Grisha) Trubetskoy Verzonden: Monday, December 25, 2006 7:08 PM Aan: announce@httpd.apache.org; python-dev@httpd.apache.org; [EMAIL PROTECTED] Onderwerp: [mod_python] ANNOUNCE: Mod_python 3.3.0b (Beta) The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the 3.3.0b (Beta) release of mod_python. Version 3.3.0b of mod_python features several new functions and attributes providing better access to apache internals, as well as many bug fixes and various performance and security improvements. A detailed description of the changes is available in Appendix A of the mod_python manual, also available here http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-fro m-3.2.10.html Beta releases are NOT considered stable and usually contain bugs. This release is intended to solicit widespread testing of the code. We strongly recommend that you try out your existing applications and experiment with new features in a non-production environment using this version and report any problems you may encounter so that they can be addressed before the final release. Preferred method of reporting problems is the mod_python user list [EMAIL PROTECTED] Mod_python 3.3.0b is available for download from: http://httpd.apache.org/modules/python-download.cgi For more information about mod_python visit http://www.modpython.org/ Regards, The Apache mod_python team. ___ Mod_python mailing list [EMAIL PROTECTED] http://mailman.modpython.org/mailman/listinfo/mod_python
Re: Location of APR/APU docs changed
Bojan Smojver [EMAIL PROTECTED] writes: On Thu, 2006-12-28 at 14:04 +1100, Bojan Smojver wrote: Changing APREQ build system to link to APR/APU docs with a specific version number would be the correct thing to do. Something like this, maybe. +1 -- Joe Schaefer
Re: Location of APR/APU docs changed
Bojan Smojver [EMAIL PROTECTED] writes: BTW, I have this ready for v2_09 branch as well. Is that OK to commit too? I think so. -- Joe Schaefer
Re: svn commit: r490939 - in /httpd/test/trunk/flood: NOTICE flood.vcproj flood_farm.c flood_pcre.c flood_pcre.h flood_round_robin.c
Propchange: httpd/test/trunk/flood/flood.vcproj -- svn:eol-style = CRLF -1. It's text, no matter which way you slice it. Please fix and ensure the repository has text and not WinCrap. Was about to veto the .vcproj (it should auto-convert upon loading the .dsp or .dsw, no???) because you are creating a maintainers headache. But I'm only -.9995 on that score.
Re: svn commit: r490939 - in /httpd/test/trunk/flood: NOTICE flood.vcproj flood_farm.c flood_pcre.c flood_pcre.h flood_round_robin.c
On 12/29/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Propchange: httpd/test/trunk/flood/flood.vcproj -- svn:eol-style = CRLF -1. My understanding was that VC 2005 requires its project files to be CRLF-delimited. If that's not the case, then I can switch it back to native. (I didn't try it as a LF ending to see what it'd do.) Was about to veto the .vcproj (it should auto-convert upon loading the .dsp or .dsw, no???) because you are creating a maintainers headache. But I'm only -.9995 on that score. The .dsp and .dsw's don't work as they require a bunch of environment variables to be set that I don't know how to set (or care to set). Plus, those project files are all built around APR 0.9.x. The .vcproj works for trunk and friends. -- justin
mod_dbd revisions
Hi -- I've been spending a lot of time staring at mod_dbd and have created four sequential patches for trunk: http://people.apache.org/~chrisd/patches/mod_dbd_pools_groups/ I've tested each one in both the threads and no-threads cases, making sure it compiles and runs with mod_authn_dbd. I've also tested the cumulative patch fairly extensively, using both ap_dbd_acquire() and ap_dbd_open()/ap_dbd_close() simultaneously (in different threads). I checked the threads and no-threads cases, with DBDPersist on and off for each, making sure all types of connections were always closed at the appropriate time. I also forced dbd_setup() to fail in the child_init hook to test the code path where dbd_setup() is called later after acquiring a mutex. Would other folks mind taking a these out for a trial run? One thing I'd be interested to know is whether multiple drivers work OK; with the cumulative patch it's possible to point one set of hosts to one kind of DB and another set to a different DB. Do the APR DBD drivers play well with each other if they're loaded into the same process? Another pair of questions I have relate to the netware and beos MPMs and their handling of child_init hook functions and memory pools. Skim down to the *** for details. Here's a rundown of the changes for the four patch files: First, a pile of cleanups, including some function and variable renaming. This is primarily for the sake of readability and clarity (and my sanity). Second, some miscellaneous fixes and changes, including: - Using ap_log_error() or ap_log_rerror() instead of ap_log_perror(), wherever possible, since without a server_rec log_error_core() ignores messages below the default server log level. - In the no-threads versions of ap_dbd_[c]acquire(), in the non- persistent case, cleanups are registered passing svr-conn as the data; but that's NULL since it's the non-persistent case. - In the no-threads persistent case, ap_dbd_open() makes a call to apr_dbd_error() passing arec-driver and arec-handle if apr_dbd_check_conn() fails, but arec/rec is NULL; it should be svr-conn-driver and svr-conn-handle. - Eliminating code duplication between the threads and no-threads cases. - Including apr_lib.h and using apr_isdigit() instead of including ctype.h and using isdigit() directly. - Including apr_want.h and using APR_WANT_MEMFUNC and APR_WANT_STRFUNC. Third, a fairly major change to deal with the problems identified in PR #39985: http://issues.apache.org/bugzilla/show_bug.cgi?id=39985 One issue raised by this bug report is that in the non-threaded persistent case, the DB connection is opened using s-process-pool and then dbd_close() is registered as a cleanup on that pool. However, the MPMs never call apr_pool_destroy() on that pool, so the DB connections aren't closed properly on shutdown. The larger issue raised in the report is that in the threaded, persistent case, segfaults could occur during shutdown. This is ultimately due to a second call to apr_pool_destroy() for a pool that was previously destroyed. More generally, it is due to the fact that there's no easy way to use reslists if you plan to create a sub-pool in the constructor. But, creating a sub-pool is often the right thing to do. This patch works around the problem by passing to apr_reslist_create() a pool for which apr_pool_destroy() is never called. For more details, see: http://marc.theaimsgroup.com/?l=apr-devm=116683262613500w=2 It turns out that the child processes created by MPMs call apr_pool_destroy() on their pchild pools, and this is the pool passed to the child_init hook functions. Currently dbd_setup_init() passes this pool to dbd_setup(), which creates a sub-pool and passes that to apr_reslist_create(). However, luckily, it turns out that s-process-pool, which is created in the main process, is not destroyed when a child process exits. This means that we can use it to create the reslist, and the reslist's internal cleanup function will never be called. Instead, we explicitly register apr_reslist_destroy() as a cleanup on a sub-pool of pchild which is created in dbd_setup_init(). At shutdown, this cleanup takes care of closing all the DB connections, without causing a double-free situation. (*** As a sidebar issue, it looks to me as though the netware MPM doesn't call apr_pool_destroy() on the pmain child it creates and passes to the child_init hook functions. Also, the beos MPM doesn't seem to call the child_init hook functions at all, because it only creates threads. I know nothing about either platform, but I'm making the assumption here that these are both things which should be fixed. If that's a bad assumption, please holler!) On advice from Nick Kew, I revised dbd_construct() so that it allocates its ap_dbd_t structure out of a sub-pool; this means the reslist won't leak memory over time. The dbd_close() is registered as a cleanup on the sub-pool,
Re: walk caching to avoid extra authnz
Hi -- Chris Darroch wrote: Much appreciated, but alas, Justin pointed out a serious conflict in mod_authz_svn, and more generally, various modules may exist out there that are also expecting authnz functions to be called for every sub-request that has a different URI/filepath. [snip] This optimization in httpd would be possible if it could assume its config files contained a complete description of all the per-directory authnz configurations. But, as noted in the SVN docs, some modules like mod_authz_svn may provide authnz functions that do per-directory discriminations based on data from outside the httpd config files. They can do this because of the way sub-request per_dir_config data is handled now. Since there's no way for httpd to know about such external per-directory authnz discriminations, we can't add the walk cache optimizations as I first wrote them. Maybe in 3.x they could be added this way, but I'd prefer to see them arrive a little sooner, if at all possible. Thinking about it last night, what I thought might work is for httpd to assume that any module that provides authnz functions is by default unsafe for walk cache optimization. However, the majority -- maybe all -- of the authnz modules in the httpd distribution could explicitly set a flag which indicates that they're safe. If no modules are loaded that are unsafe, then the optimization could be done, otherwise the old behaviour would be the default. Existing external modules would continue to work as before. I've revised my patch set for httpd trunk to do something like what's described above; it's available at: http://people.apache.org/~chrisd/patches/walk_cache/ Briefly, the walk cache changes I made earlier are still in place, but sub-requests and internal redirects only share the initial request's per_dir_config if ap_auth_initial_req_only() returns true. Otherwise, they get their own private copy, as before. The new function ap_auth_initial_req_only() simply returns the AND'ed value of two optional functions, one each for authn and authz. These functions return true or false depending on whether any authn or authz providers were registered using the old unsafe for walk cache optimization version code. If none were -- as should usually be the case for most installations -- then optimization can proceed. The main trick here is that instead of the hard-coded version string 0 for authn/z providers, AUTHN/Z_PROVIDER_VERSION_ALL_REQ and AUTHN/Z_PROVIDER_VERSION_INITIAL_REQ are defined. Also, instead of doing ap_lookup_provider() directly, ap_authn_lookup_provider() and ap_authz_lookup_provider() should be used instead. These check first for a better INITIAL_REQ version, then fall back to the ALL_REQ version. Based on a somewhat speedy evaluation, I don't see any authn/z modules that would require the ALL_REQ version -- that is, anything which works like mod_authz_svn, and discriminates between requests on the basis of URLs (using configuration information other than the normal httpd configuration directives). I won't check this in anytime soon, because I'd like to hear if anyone can think of additional problems, or has issues with this proposed solution. Fire away! Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: Location of APR/APU docs changed
On Fri, 2006-12-29 at 15:41 -0500, Joe Schaefer wrote: +1 Thanks. Committed to trunk. BTW, I have this ready for v2_09 branch as well. Is that OK to commit too? -- Bojan
Re: archive.apache.org issues
On 12/29/2006 06:17 AM, Paul Querna wrote:
Ya, I'm not sure why that is happening either.
This works:
http://archive.apache.org/dist/
And so does this:
http://archive.apache.org/index.html
But this:
http://archive.apache.org/
Does not. So, the error log has:
[Fri Dec 29 05:10:00 2006] [error] [client 66.225.25.189] (70008)Partial
results are valid but processing is incomplete: access to /index.html failed
It seems like the cause must be something broken in httpd trunk.
I think this commit did it:
http://svn.apache.org/viewvc?view=revrevision=425394
I think we should not shoot the messenger here :-):
--- httpd/httpd/trunk/server/request.c 2006/07/25 13:33:05 425393
+++ httpd/httpd/trunk/server/request.c 2006/07/25 13:40:32 425394
@@ -553,9 +553,22 @@
* check.
*/
if (!(opts OPT_SYM_LINKS)) {
-apr_stat(thisinfo, r-filename,
- APR_FINFO_MIN | APR_FINFO_NAME | APR_FINFO_LINK,
- r-pool);
+rv = apr_stat(thisinfo, r-filename,
+ APR_FINFO_MIN | APR_FINFO_NAME | APR_FINFO_LINK,
+ r-pool);
+if (rv != APR_SUCCESS) {
+/*
+ * This should never happen, because we did a stat on the
+ * same file, resolving a possible symlink several lines
+ * above. Therefore do not make a detailed analysis of rv
+ * in this case for the reason of the failure, just bail
out
+ * with a HTTP_FORBIDDEN in case we hit a race condition
+ * here.
+ */
+ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r,
+ access to %s failed, r-uri);
+return r-status = HTTP_FORBIDDEN;
+}
if (thisinfo.filetype == APR_LNK) {
/* Is this a possibly acceptable symlink? */
if ((res = resolve_symlink(r-filename, thisinfo,
I guess we should have good reasons to continue if apr_stat does not return
APR_SUCCESS, especially
since we try to process the results of this apr_stat call afterwards
(thisinfo.filetype == APR_LNK).
Partial results are valid but processing is incomplete seems to be the OS
error message
to me. To be honest I am not quite sure what it wants me to tell. On which OS
did this happen?
Regards
Rüdiger
P.S: +1 to the patch improving the error message by adding r-filename to it.
Re: archive.apache.org issues
On 12/29/06, Ruediger Pluem [EMAIL PROTECTED] wrote: Partial results are valid but processing is incomplete seems to be the OS error message to me. To be honest I am not quite sure what it wants me to tell. On which OS did this happen? I believe that error string is the APR_INCOMPLETE description. archive.apache.org is now a Solaris 10 box. Thanks. -- justin
Re: walk caching to avoid extra authnz
On 12/29/06, Chris Darroch [EMAIL PROTECTED] wrote: The main trick here is that instead of the hard-coded version string 0 for authn/z providers, AUTHN/Z_PROVIDER_VERSION_ALL_REQ and AUTHN/Z_PROVIDER_VERSION_INITIAL_REQ are defined. Without looking at the code, I'd hope that means that they are version 1 providers. =) -- justin
Re: PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
On Mon, Dec 4, 2006 at 1:00 PM, in message
[EMAIL PROTECTED], Johanna Bromberg Craig
[EMAIL PROTECTED] wrote:
Hi,
I've addressed the feedback I received on my patch from Brad Nicholes
as follows:
I've reviewed all instances of util_ldap_compare() and
util_ldap_cache_comparedn() to confirm that each is protected from
cases where req- dn might be NULL or '\0'.
I've addressed the differences between AuthLDAPGroupAttributeDN,
AuthLDAPGroupAttribute, and AuthzLDAPRequireDN.
Thanks,
Johanna
I finally got some time to take a closer look at the patch. Although I like
the concept, I am still uncomfortable with the implementation from a
configuration point of view. I have attached a patch which is actually closer
to your first patch except it maintains the original functionality while
enhancing the AuthLDAPGroupAttribute directive to support attributes that may
contain a full DN. Actually, I think that was the original intent of
AuthLDAPGroupAttributeIsDN but it appears to have been broken along the way.
Anyway the proposed new syntax for AuthLDAPGroupAttribute is:
AuthLDAPGroupAttribute attribute [DN | UN] ...
where the keywords DN (Distinguished Name) and UN (User Name) can
optionally follow each attribute in the list. If neither of the keywords are
specified, then the attribute type follows the AuthLDAPGroupAttributeIsDN
setting. The AuthLDAPGroupAttributeIsDN setting determines if a DN is required
in the group comparison or not. If the AuthLDAPGroupAttribute list contains
any UN's, then AuthLDAPGroupAttributeIsDN must be set to OFF otherwise the
authorization will fail since it would be expecting to be able to resolve the
user object to a DN within the LDAP directory.
Let me know if this works for you,
BTW, this patch is against trunk rather than the 2.2.x branch.
Brad
Index: mod_authnz_ldap.c
===
--- mod_authnz_ldap.c (revision 489925)
+++ mod_authnz_ldap.c (working copy)
@@ -84,6 +84,7 @@
struct mod_auth_ldap_groupattr_entry_t {
char *name;
+char *type;
};
module AP_MODULE_DECLARE_DATA authnz_ldap_module;
@@ -647,8 +648,10 @@
#endif
grp = apr_array_push(sec-groupattr);
grp-name = member;
+grp-type = NULL;
grp = apr_array_push(sec-groupattr);
grp-name = uniquemember;
+grp-type = NULL;
#if APR_HAS_THREADS
apr_thread_mutex_unlock(sec-lock);
#endif
@@ -682,7 +685,6 @@
if(result != LDAP_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
auth_ldap authorise: User DN not found, %s, ldc-reason);
-return AUTHZ_DENIED;
}
req = (authn_ldap_request_t *)apr_pcalloc(r-pool,
@@ -719,13 +721,30 @@
getpid(), t);
for (i = 0; i sec-groupattr-nelts; i++) {
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
- [% APR_PID_T_FMT ] auth_ldap authorize: require
group:
- testing for %s: %s (%s), getpid(),
- ent[i].name, sec-group_attrib_is_dn ? req-dn :
req-user, t);
+result = 0;
-result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
- sec-group_attrib_is_dn ? req-dn : req-user);
+if (ent[i].type == NULL) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ [% APR_PID_T_FMT ] auth_ldap authorize: require
group:
+ testing for %s: %s (%s), getpid(),
+ ent[i].name, sec-group_attrib_is_dn ? req-dn :
req-user, t);
+
+result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
+ sec-group_attrib_is_dn ? req-dn
: req-user);
+} else if (req-dn != NULL strlen(req-dn) != 0
strcasecmp(ent[i].type, dn) == 0) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ [% APR_PID_T_FMT ] auth_ldap authorise: require
group:
+ testing for %s: %s (%s), getpid(),
+ ent[i].name, req-dn, t);
+result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
req-dn);
+} else if (req-user != NULL strlen(req-user) != 0
strcasecmp(ent[i].type, un) == 0) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ [% APR_PID_T_FMT ] auth_ldap authorise: require
group:
+ testing for %s: %s (%s), getpid(),
+ ent[i].name, req-user, t);
+result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
req-user);
+}
+
switch(result) {
case LDAP_COMPARE_TRUE: {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
@@ -1252,15 +1271,29 @@
static const char *mod_auth_ldap_add_group_attribute(cmd_parms *cmd, void
*config, const char *arg)
{
Re: walk caching to avoid extra authnz
Justin Erenkrantz wrote: Without looking at the code, I'd hope that means that they are version 1 providers. =) -- justin Yes, that's what I used, although I wondered if that was ideal, or whether it should be something like 0-initial-req-only ... but 1 seemed less ugly to me. :-) However, it occurs to me that I probably have more to do here, to make sure that all modules that have registered hook functions for access_checker, check_user_id, and/or auth_checker have also signed off on the more aggresive walk caching. Sigh ... that I won't get to until the new year, for sure. Still, comments on what's there so far much appreciated! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
