Re: Imap Name Change - NetWare Build
Done, Thanks
Brad
[EMAIL PROTECTED] Thursday, April 07, 2005 5:20:23 PM
Greetings All,
Just trying a build of 2.1 following the mod_imap - mod_imagemap name
change, and the attached patches are needed to build for NetWare:
In http 21. root directory:
--- NWGNUmakefile.orig 2005-02-15 06:42:40.0 +1100
+++ NWGNUmakefile 2005-04-08 08:46:50.0 +1000
@@ -215,7 +215,7 @@
$(OBJDIR)/mod_cgi.o \
$(OBJDIR)/mod_dir.o \
$(OBJDIR)/mod_env.o \
- $(OBJDIR)/mod_imap.o \
+ $(OBJDIR)/mod_imagemap.o \
$(OBJDIR)/mod_include.o \
$(OBJDIR)/mod_log_config.o \
$(OBJDIR)/mod_mime.o \
In http-2.1\os\netware directory:
--- modules.c.orig 2005-02-05 10:08:46.0 +1100
+++ modules.c 2005-04-08 09:05:55.0 +1000
@@ -39,7 +39,7 @@
extern module env_module;
extern module log_config_module;
extern module asis_module;
-extern module imap_module;
+extern module imagemap_module;
extern module actions_module;
extern module setenvif_module;
extern module nwssl_module;
@@ -62,7 +62,7 @@
env_module,
log_config_module,
asis_module,
- imap_module,
+ imagemap_module,
actions_module,
setenvif_module,
nwssl_module,
@@ -87,7 +87,7 @@
{env_module, env_module},
{log_config_module, log_config_module},
{asis_module, asis_module},
- {imap_module, imap_module},
+ {imagemap_module, imagemap_module},
{actions_module, actions_module},
{setenvif_module, setenvif_module},
{nwssl_module, nwssl_module},
@@ -112,7 +112,7 @@
env_module,
log_config_module,
asis_module,
- imap_module,
+ imagemap_module,
actions_module,
setenvif_module,
nwssl_module,
Cheers,
Norm
Re: simple-conf ready for merge
I see your rational, but I am looking at it from the point of view that the user knows that one of the first things that they need to do is tweak the MPM to fit their load/resource requirements. This is more a matter of where it they go? I could have sworn they were right here a minute ago. And I certainly wouldn't classify them as extra. [ Side note: The other question is How much confusion does the presence of these directives add to the config file? That mess of IfModule xxx_mpm was horribly confusing IMHO. That could be solved by intelligently including only the section for the relevant mpm in the default config, but that would require more complex build changes than I am up to. I agree, but I would still rather see only the applicable platform MPM directives anyway no matter whether they are implemented in httpd.conf or extra/httpd-mpm.conf. Brad [EMAIL PROTECTED] Wednesday, April 06, 2005 1:17:10 PM Brad Nicholes wrote: I'm still not a big fan of removing the MPM settings from the httpd.conf file. All of the other extra .conf files contain supplemental configuration but the MPM configuration seems to be more along the lines of a ServerRoot or Listen. Despite the fact that these are technically module directives, MPM directives just feel more like core directives. It's not really a question of core/module. Lots of core directives were removed too. The question is: Is this a directive that many/most users need to change? For most of the mpm directives, the answer is clearly no. (Although you could argue about something like MaxClients/MaxThreads.) [ Side note: The other question is How much confusion does the presence of these directives add to the config file? That mess of IfModule xxx_mpm was horribly confusing IMHO. That could be solved by intelligently including only the section for the relevant mpm in the default config, but that would require more complex build changes than I am up to. ] Joshua.
Re: simple-conf branch
+1 to Greg's comment, I also think that for a new users, having a bunch of little .conf files will be more confusing. For experienced users, they will split up the .conf file however they see fit anyway. So it doesn't really matter. Brad [EMAIL PROTECTED] Sunday, April 03, 2005 1:33:06 AM On Sat, Apr 02, 2005 at 02:58:26PM -0500, Joshua Slive wrote: Please take a look at http://svn.apache.org/repos/asf/httpd/httpd/branches/simple-conf/docs/conf/ This is my long-threatened project to massively simplify the basic httpd.conf by splitting a bunch of stuff out into smaller files in the extra/ directory that are not included by default. As long as the default is a single file, then I'm cool with this. The key here is that the gazillion little .conf files are *not* included in the default .conf file. That would be a pain because changes could involve one or more of N separate files. So: given that... I'm very supportive of a smaller default file. Cheers, -g -- Greg Stein, http://www.lyra.org/
So what is the real status of 2.1.x...
The STATUS file says: 2.1.4 : in development 2.1.3 : Released on 2/22/2005 as alpha. The ap_release.h header file says: 2.1.5-dev The distribution page /dist/httpd says: httpd-2.1.3-beta.tar.gz Are we BETA yet or not? I am assuming that the true status is: - httpd-2.1.3-beta.tar.gz - should really be ALPHA - STATUS file needs to be updated to 2.1.5 : in development 2.1.4 : pending BETA released 2.1.3 : Released on 2/22/2005 as alpha. - ap_release.h - no change. Am I missing something? Brad
Re: Enhancement of mod_charset_lite
Open an enhancement request in Bugzilla http://httpd.apache.org/bug_report.html an include the patch file there. Brad [EMAIL PROTECTED] Thursday, March 24, 2005 4:47:52 AM Hello, for my personal needs i had to add some functionality to mod_charset_lite. Here is what i did: 1) Add an option AllowProxied that makes it work also on proxied requests (usefull in a reverse proxy environment which uses mod_proxy_html to return to the original encoding). 2) Add an option AdjustHeader that adjusts the content-type header according to the destination encoding. If someone is interested in these changes, i am not sure where to post them. Greetings, Jens Stutte
Re: 2.1.4 available for testing
+1 NetWare Brad [EMAIL PROTECTED] Wednesday, March 16, 2005 2:00:47 PM Hi all, There are some 2.1.4-alpha tarballs waiting to be tested at: http://httpd.apache.org/dev/dist/ Please report back with any problems. Thanks for testing! Sander
Re: [STATUS] (httpd-2.0) Wed Mar 9 23:45:36 2005
For 2.0 auth_ldap and mod_ldap it will probably forever remain experimental. There have been a lot of changes that have gone into the 2.1 version that IMO allowed it to graduate from experimental to a standard module. Most of these patches will never be backported to 2.0. In fact Josh's patch will probably not be backported (although it is simple enough that it could be) simply because the two code bases have become so different that it is difficult to backport anything. In most cases a backport is actually a rewrite. For this reason, I am ++1 for any effort to get 2.1/2.2 to BETA and released. Even if the latest Multiple AAA provider discussion has to wait for 2.4. We need exposure for the new authnz_ldap and util_ldap modules as well as the new auth module structure itself. Brad [EMAIL PROTECTED] Thursday, March 10, 2005 7:24 AM Paul Querna wrote: Jess Holle wrote: Rodent of Unusual Size wrote: CURRENT VOTES: * Promote mod_ldap and mod_auth_ldap from experimental to non experimental status. +1: bnicholes, wrowe +0: minfrin (wait till the last cache bugs are ironed out) I think we're pretty well there -- at least in 2.0.53 plus the recent patch from Josh Fenlason to cover the case when a shared cache file is not specified on a platform supporting shared memory. Thoughts? It was promoted in 2.1. Why change the status for 2.0.x? No big reason. Though I believe a non-experimental status is accurate now, I can understand if no one wants to rearrange any sources in 2.0.x. I was just reviewing the 2.0 status and the quoted portion above made it sound like this was still under consideration for 2.0. -- Jess Holle
Auth_ldap experimental status (was:Re: [STATUS] (httpd-2.0) Wed Mar 9 23:45:36 2005)
I am of the same opinion as Justin in that I believe that multiple auth providers can be put into 2.2 at anytime. If it happens to make it before initial release fine. If it is after, it is just additional functionality which won't break backward compatibility. As far as backporting other authnz_ldap patches, Josh's patch is minor and can be easily done. Other's may take a lot more work and the problem that we have right now is that there are very few of us that are looking at auth_ldap and even fewer that are reviewing backports and voting. So getting the required 3-votes doesn't happen very fast if at all. Also, if we can get 2.2 moving and out soon, backports won't matter anyway. Brad Jess Holle [EMAIL PROTECTED] Thursday, March 10, 2005 9:06:21 AM Agreed on all points *except* that we *really* need multiple LDAP providers as soon as possible. Thus if there is any way to get this into 2.2 that would be *very* helpful. Well, I'd also like to see Josh's patch back in 2.0.x as we'll have to continue patching it into each and every Apache 2.0.x build ourselves if it is not merged into 2.0.x. [I don't like leaving crashes around in executables we ship when they are so easily amended.] -- Jess Holle
Re: Proposed LDAP Fix
The patch has been committed to httpd-trunk.
thanks,
Brad
[EMAIL PROTECTED] Tuesday, March 08, 2005 7:26:02 AM
I had problems with LDAP modules in 2.0.53 on Windows. It
authenticates
fine, but when I shut down apache I get those Microsoft alerts saying
something went wrong. It only happens when I have the ldap modules
enabled. The problem is in modules/experimental/util_ldap_cache.c in
the util_ldap_cache_module_kill() method. The cache_file is null.
Adding a null check prior to calling apr_file_remove() fixed the
issue.
Any thoughts? Thanks.
,
Josh.
apr_status_t util_ldap_cache_module_kill(void *data)
{
util_ldap_state_t *st = (util_ldap_state_t *)data;
util_ald_destroy_cache(st-util_ldap_cache);
#if APR_HAS_SHARED_MEMORY
if (st-cache_rmm != NULL) {
apr_rmm_destroy (st-cache_rmm);
st-cache_rmm = NULL;
}
if (st-cache_shm != NULL) {
apr_status_t result = apr_shm_destroy(st-cache_shm);
st-cache_shm = NULL;
if ( st-cache_file != NULL ) // ADDED THIS LINE
apr_file_remove(st-cache_file, st-pool);
return result;
}
#endif
return APR_SUCCESS;
}
Re: Multiple AAA providers
I believe that we are talking about coding at the provider layer (ldap, file, etc.). The problem here is that I am not sure what the following means: [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. But I do know what this means: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. Brad [EMAIL PROTECTED] Sunday, March 06, 2005 11:16 PM At 12:03 PM 3/6/2005, Justin Erenkrantz wrote: On Sat, Mar 05, 2005 at 10:59:30PM -0600, William A. Rowe, Jr. wrote: Ok, as Justin and I are in significant disagreement ... to summarize; we (collectively) would like to see some mechanism for multiple configurations of the same 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at?
Re: Multiple AAA providers
I believe that we are talking about coding at the provider layer (ldap, file, etc.). Absolutely not my intention. Again, I do not want to have each provider have to reimplement the same code and parsing. I want a single module to do so, and the providers to be oblivious (but still work.) Let me clarify, we are talking about coding at the provider framework, not each provider itself. In other words, the authconfig module would do basically what you have proposed as far as merging config options outside of the actual provider module. The only difference would be allowing the authconfig configuration to be aliased so that it can be reused. I think we are close to the same page but I will wait to review the code that you come up with. Also the reason for the syntax authconfig ldap alt-ldap is so that the authconfig module knows what the base provider is. Otherwise how will it know which provider to call once the configuration merge is done? Then there would be no need for this syntax: VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig It could be replaced with: VirtualHost xxx Location /private AuthProvider alt-ldap AuthLdap additional or overridden directives... Which more closely maps to the configuration syntax today. Brad William A. Rowe, Jr. [EMAIL PROTECTED] Monday, March 07, 2005 4:47:15 PM At 10:11 AM 3/7/2005, Brad Nicholes wrote: I believe that we are talking about coding at the provider layer (ldap, file, etc.). Absolutely not my intention. Again, I do not want to have each provider have to reimplement the same code and parsing. I want a single module to do so, and the providers to be oblivious (but still work.) [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). Agreed :) I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. That's not accurate. It's allowed, but remember inheritance applies, In the module I already hacked, it's possible to VirtualHost xxx AuthConfig AuthDirectives /AuthConfig and that will also be inherited. But I didn't propose named aliases, which could be a very cool idea. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. I'd be even more partial to allowing them in location scope, with alias names, and merging up the aliases. My concern is names clashing, on servers with massive VHOST lists. Allowing you to 'refine' a given alias... e.g. AuthConfig alt-ldap AuthLdapDirectives /AuthConfig VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig ... then I think your preference for named sections, and my preference for scoped sections could both be satisfied. I'll give some thought to binding AuthConfig to a specific provider 'alias', v.s. allowing more complex control.
Re: Multiple AAA providers
Actually I think the better syntax would be: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Location /foo1 AuthProvider Myldap1 Myfile1 ...Other config options... /Location Location /foo2 AuthProvider Myldap2 Myfile1 ...Other config options... /Location Location /foo3 AuthProvider Myldap1 Myldap2 ...Other config options... /Location This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I haven't thought this through completely from an implementation standpoint, but by moving the provider definitions into mod_auth_basic and then extending the framework for handling multiple provider definitions into the providers themselves, I think we can come out with something very useful and reuseable. Brad [EMAIL PROTECTED] Friday, March 04, 2005 1:06:47 AM Justin Erenkrantz said: I still maintain the better way to do this is to handle it in the provider modules themselves by leveraging the provider API instead. To reiterate, in my mind, the ideal syntax is: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin This means that: - Every auth module has to be independantly updated to use this method (which won't happen) - Every module will have it's own method of configuring multiple providers. Putting my end user hat on, doing it the way you suggest would irritate me no end, as it would make no logical sense to me why one auth provider allows multiple configurations and another doesn't, or why one auth provider uses one config mechanism and another auth provider uses a different one. I definitely think that getting the auth framework to understand this syntax is the right way to go, we just need to figure out that magic syntax that will work elegantly. Regards, Graham --
Re: Multiple AAA providers
Although I agree that this would probably be the best way to go, I don't think it will be that simple. Authnz_ldap stores the LDAPurl and other information (bind user id, bind password, certs, etc) in a per-Dir structure. At the very least, authnz_ldap would have to be taught how to store multiple configurations per-dir. Other auth modules may have the same structure. Brad [EMAIL PROTECTED] Wednesday, March 02, 2005 11:14:33 AM Bleh. Wouldn't it be easier not to rearchitect the whole thing? What about the core or mod_auth respecting something like; Location /protected AuthConfig AuthFile users1 /AuthConfig AuthConfig AuthFile users2 /AuthConfig Simply use the existing scope, inheritance, and so on. Whenever multiple AuthConfigs apply to a given scope, iterate them until satisfied. I think we can accomplish this with minimal or no changes to any existing auth module. I'm concerned that the more complex each auth provider needs to be, the more probability that there will be logic errors in the provider. Bill At 09:45 AM 3/2/2005, Justin Erenkrantz wrote: On Wed, Mar 02, 2005 at 08:24:25AM -0500, Geoffrey Young wrote: while I don't claim to have more than a cursory understanding of ldap, I would think these cases could be handled by extending the current situation a bit. for instance, for the file provider something like AuthBasicProvider file AuthFileName file1 file2 if AuthFileName were ITERATE mod_authn_file would know that it should not return AUTH_USER_NOT_FOUND until it has checked all the files present. or somesuch off the top of my head. Correct. That is the approach that makes the most sense to me. The provider itself can loop as long as it wants to using its own config syntax. However, there is nothing that prohibits one authn module from registering multiple providers dynamically. Remember that the providers are only looked up at request-time. So, if mod_auth_ldap were to have a syntax like: AuthLDAPProvider foo-1 ldap://ldap.example.com/cn=? AuthLDAPProvider foo-2 ldap://ldap2.example.com/cn=? AuthBasicProvider foo-1 foo-2 That would work, as long as mod_auth_ldap calls ap_register_provider x number of times. -- justin
Re: [VOTE] 2.1.3 as beta
+1 on NetWare. [EMAIL PROTECTED] Thursday, February 24, 2005 12:52:23 AM --On Wednesday, February 23, 2005 10:37 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Uhm, no. By that definition, all the pollution spewed from typical Linux libraries would be considered 'public api.' Other platforms are using the construct to extract public symbol lists now, IIUC. APR_DECLARE (DAV_DECLARE, etc)is our shorthand of what has been publicizied and what is internal. No, we never declared them, hence they weren't officially part of the API. The fact that Unix-based OSes technically throw everything into the API isn't part of our API contract. Note that I'm not saying that making the mod_dav API change isn't good, but I'm miffed at the claim that this is justification to -1 a release. Actually, it should (if it can be fixed in these few days) be part of the 2.1.4. Good, then I hope that statement is backed with a willingness to be the RM for 2.1.4. (As you may or may not know, I'm traveling in the next few days and will have sporadic 'net/email access.) I'm a little curious - I understood we would tag an ALPHA, decide if it was 'good enough', then call it BETA. I certainly don't think that the last tarballs were good enough for that. My estimation of a beta is that it works for some folks but not necessarily others. Sure, it might have bugs. In fact, from our release guidelines: Beta indicates that at least three committers have voted positively for beta status and there were more positive than negative votes for beta designation. This indicates that it is expected to compile and perform basic tasks. However, there may be problems with this release that prohibit its widespread adoption. Perhaps we have a disagreement over what a beta release means? My intention with 2.1.3 is to get us moving solidly in the direction of a 2.2.x release - not see more time lost because we can't agree on a perfect 'beta' release. A beta release needs not to be perfect - that's what a release stabilization branch is for - to fix up these issues in time for a GA release. We have yet to publicize outside of [EMAIL PROTECTED] *any* 2.1.x release and that is really disturbing. I want us to start making noise about the upcoming 2.2.x releases. We ought to give our third-parties plenty of time to update their modules - frankly, most won't need it, but we should give them time to do that. 2.1.3 compiles and serves pages for me on Darwin. So, my +1 for beta still holds. -- justin
Re: [PROPOSAL] How to treat release candidate branches
+1 [EMAIL PROTECTED] Wednesday, February 23, 2005 9:03:48 AM Assuming that we can get a beta approved to eventually become 2.2.x, I'd like to propose the following policy that tries to balance the need for review with the need for stability: Any code changes can be backported to a release candidate branch from trunk via lazy consensus (CTR) if it does not change binary compatibility. However, if a change impacts binary compatibility or the external API in anyway (i.e. adds a new function or whatnot), it must receive 3 +1s before it can be committed to the release candidate branch (RTC). This way, we can add new features or binary-incompatible changes to a beta if three committers are in agreement that it should be present before the stable release. And, bug fixes ported back from trunk can be brought back with minimal hassle. At the point that we issue the first GA release, everything in that release candidate branch switches over to RTC (as we do right now for 2.0.x). Of course, this would not apply to trunk - which remains under CTR for all changes. For those who like concrete examples: If 2.1.3 is approved, we copy the tags/2.1.3 to branches/2.2.x. Trunk becomes 2.3.0. branches/2.2.x is immediately bumped to 2.1.4 (or perhaps 2.1.5 to identify those snapshots that came from the trunk before we branched). All changes must still hit the trunk (2.3.0) first. If you have a bug fix or a change that doesn't impact the API, it can be immediately backported to branches/2.2.x under CTR. If it changes the API in any way, it must enter branches/2.2.x/STATUS to receive votes for backport. What do ya'll think? -- justin
LDAP socket timeout patch (was:Re: [VOTE] Release httpd-2.0.53)
I have a 2.0 compatible patch just about ready to go. Once I get it cleaned up, I will post it as a 2.0.53 patch in the patches directory off of the download page. Brad [EMAIL PROTECTED] Monday, February 07, 2005 10:08:29 AM It appears that 2.0.53 does not include the LDAP socket timeout configuration patch. Is this true? If so, is there a 2.0.x-ready patch for this? We'll be building 2.0.53 binaries shortly and I'm interested in this patch whether it made it into 2.0.53 or not. -- Jess Holle
Re: LDAPTrustedMode has the wrong scope...
+1, allowing mod_authnz_ldap to override the default makes a lot more sense. Unless you are already working on a patch, I will try to put something together today. But after today I will be offline for the next two days. Brad [EMAIL PROTECTED] Wednesday, February 02, 2005 1:23:51 AM Brad Nicholes said: The attached patches convert LDAPTrustedMode into a per-directory directive rather than a per-server. This allows the configuration to specify which mode should be applied for the associated AuthLDAPURL. Thoughts on whether this should be the way to go or if LDAPTrustedMode should be moved up into mod_authnz_ldap as AuthLDAPTrustedMode? Thinking about this some more - I'm not keen on the idea of adding another directive to mod_authnz_ldap, because when the configuration-via-LDAP happens, and other potential LDAP modules happen, then we end up with directive soup as each module has it's own variation of AuthLDAPTrustedMode. The idea that it be possible to set the SSL mode inside mod_authnz_ldap is still really useful - what we could do is this: AuthLDAPURL ldap://etc AuthLDAPURL ldaps://etc AuthLDAPURL SSL ldap://etc AuthLDAPURL STARTTLS ldap://etc In other words, combine the SSL mode in a TAKE12 option, with an optional SSL mode prefix. The LDAPTrustedMode directive could stay so as to define the default (and overriding the default if the user wanted). Thoughts? Regards, Graham --
Re: LDAPTrustedMode has the wrong scope...
I have got something that almost works now. The problem that I am running into is that util_ldap_connection_find() doesn't know the difference between APR_LDAP_NONE(the secure mode was never set so use the default) vs. APR_LDAP_NONE (NONE is what I really want). Seems like we need another flag meaning UNSET. Brad [EMAIL PROTECTED] Wednesday, February 02, 2005 9:38:59 AM Brad Nicholes wrote: +1, allowing mod_authnz_ldap to override the default makes a lot more sense. Unless you are already working on a patch, I will try to put something together today. But after today I will be offline for the next two days. I will only have a chance to work on this tomorrow :( Regards, Graham --
Re: LDAPTrustedMode has the wrong scope...
You read my mind. I'm all over it. :) Brad Graham Leggett [EMAIL PROTECTED] Wednesday, February 02, 2005 12:13:56 PM Brad Nicholes wrote: I have got something that almost works now. The problem that I am running into is that util_ldap_connection_find() doesn't know the difference between APR_LDAP_NONE(the secure mode was never set so use the default) vs. APR_LDAP_NONE (NONE is what I really want). Seems like we need another flag meaning UNSET. Hmmm... maybe if we teach util_ldap_connection_find() to accept -1, which means none of NONE|SSL|TLS...? The -1 can be passed if AuthLDAPURL had one parameter, and NONE|SSL|TLS can be passed if AuthLDAPURL has two parameters? Regards, Graham --
Re: Time for 2.0.53?
I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); The default is 10 seconds, but this directive will allow the administrator to set it to whatever they want. See the STATUS file backport entry (svn rev 126565). This should be a much cleaner way to handle connection timeouts although I think that the whole connection pool itself should be converted to using apr_reslist_*. I have also considered adding a similar directive to set the search timelimit (LDAP_OPT_TIMELIMIT), but I haven't decided if just setting a global time limit is a good thing or not. It seems like this should be more of a per-request type of setting and also really depends on the size of the LDAP context that is being searched. thoughts? Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 8:55:24 AM Jess Holle said: I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. Is there an outstanding patch for this yet? The right way to solve this problem is to allocate the LDAP connection pool using apr_reslist_*, which handles things like connection timeouts for us. If this code exists already, then I'm keen to get it in ASAP, and if the code doesn't exist I should have time to fix it after tomorrow. Regards, Graham --
Re: Time for 2.0.53?
I was hoping that this wouldn't be the case. But since it is, take a look at SVN r149419 Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 9:39:20 AM Brad Nicholes wrote: I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); IMO this does not exists on WIN32 (at least PSDK does not declare that), thus mod_ldap breaks on build. The code should be enclosed inside: #if defined(LDAP_OPT_NETWORK_TIMEOUT) #endif Regards, Mladen
Re: Time for 2.0.53?
I hate it when I get bit by copy and paste. Try r149421. Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 10:23:01 AM Brad Nicholes wrote: I was hoping that this wouldn't be the case. But since it is, take a look at SVN r149419 util_ldap.c util_ldap.c(1615) : error C2065: 's' : undeclared identifier util_ldap.c(1615) : warning C4047: 'function' : 'const server_rec *' differs in levels of indirection from 'int' Seems you have typo using wrong server_rec for logging. It helps if you change line 1615 to use cmd-server instead s ;). Regards, Mladen.
LDAP connection timeout option (was:Re: Time for 2.0.53?)
The LDAP_OPT_SEND_TIMEOUT option appears to be a Microsoft LDAP SDK only option. As I see it we can go in a couple of different ways here. 1) Implement the connection pool as an apr_reslist and let it handle the connection timeouts as Graham suggested. 2) Add another #ifdef to the existing code to use LDAP_OPT_SEND_TIMEOUT if supported. Maybe for the short term we just add the #ifdef and then see what Graham comes up with for the apr_reslist implementation. Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 10:14:10 AM Jess Holle wrote: Ouch! Does the MS LDAP SDK define anything equivalent? Perhaps LDAP_OPT_SEND_TIMEOUT: The limit on the number of seconds that the local LDAP client will wait while attempting to send data to a remote computer. If the send operation is not completed before the timeout period expires, the LDAP call will fail with an LDAP_TIMEOUT error code. Fixing this on some platforms is better than on none, though. Regards, Mladen.
Re: LDAP connection timeout option (was:Re: Time for 2.0.53?)
The Novell SDK has the same options but they all perform different functions LDAP_OPT_TIMELIMIT - Searching timeout LDAP_OPT_TIMEOUT - default timeout value LDAP_OPT_NETWORK_TIMEOUT - Socket level timeout Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 10:41:04 AM --On Tuesday, February 1, 2005 10:33 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: The LDAP_OPT_SEND_TIMEOUT option appears to be a Microsoft LDAP SDK only option. As I see it we can go in a couple of different ways here. OpenLDAP has LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT, and LDAP_OPT_NETWORK_TIMEOUT. -- justin
LDAPTrustedMode has the wrong scope...
After testing mod_authnz_ldap and util_ldap some more, it appears that the directive LDAPTrustedMode should be pushed up into mod_authnz_ldap rather than util_ldap and become AuthLDAPTrustedMode. The reason why is because the connection type (ie. NONE, SSL, STARTTLS) is tied to the AuthLDAPUrl rather than the global connection or certificate directives that are set in util_ldap. As it stands today, the following configuration will fail: Alias /secure /webpages/secure Directory /webpages/secure Order deny,allow Allow from all AuthType Basic AuthName LDAP_Protected_Place AuthBasicProvider ldap AuthLDAPURL ldap://foo.ldapserver.com/o=ctx; AuthzLDAPAuthoritative off require valid-user /Directory Alias /othersecuredir /webpages/othersecuredir Directory /webpages/othersecuredir Order deny,allow Allow from all AuthType Basic AuthName LDAP_Secure_Test AuthBasicProvider ldap AuthzLDAPAuthoritative off LDAPTrustedMode STARTTLS AuthLDAPURL ldap://other.ldapserver.com/o=ctx; require valid-user /Directory The above configuration assumes that all connections to foo.ldapserver.com will be non-secure on port 389 and that all connections to other.ldapserver.com will be TLS connections on port 389. The problem is that the directive LDAPTrustedMode is global not per-directory. Therefore even though the configuration intended to connect to foo.ldapserver.com non-secure, since the global trusted mode has been set to STARTTLS, util_ldap will attempt to start tls on all connections. Since the type of connection is already determined partially by the AuthLDAPURL (ie. ldaps:// vs ldap://), changing the type to STARTTLS also needs to be in the same scope as AuthLDAPURL. There are two options, change LDAPTrustedMode to a per-directory directive within util_ldap or move LDAPTrustedMode up into mod_authnz_ldap as AuthLDAPTrustedMode. Brad
Re: LDAPTrustedMode has the wrong scope...
The attached patches convert LDAPTrustedMode into a per-directory
directive rather than a per-server. This allows the configuration to
specify which mode should be applied for the associated AuthLDAPURL.
Thoughts on whether this should be the way to go or if LDAPTrustedMode
should be moved up into mod_authnz_ldap as AuthLDAPTrustedMode?
Brad
[EMAIL PROTECTED] Tuesday, February 01, 2005 3:33:19 PM
After testing mod_authnz_ldap and util_ldap some more, it appears
that the directive LDAPTrustedMode should be pushed up into
mod_authnz_ldap rather than util_ldap and become AuthLDAPTrustedMode.
The reason why is because the connection type (ie. NONE, SSL,
STARTTLS)
is tied to the AuthLDAPUrl rather than the global connection or
certificate directives that are set in util_ldap. As it stands today,
the following configuration will fail:
Alias /secure /webpages/secure
Directory /webpages/secure
Order deny,allow
Allow from all
AuthType Basic
AuthName LDAP_Protected_Place
AuthBasicProvider ldap
AuthLDAPURL ldap://foo.ldapserver.com/o=ctx;
AuthzLDAPAuthoritative off
require valid-user
/Directory
Alias /othersecuredir /webpages/othersecuredir
Directory /webpages/othersecuredir
Order deny,allow
Allow from all
AuthType Basic
AuthName LDAP_Secure_Test
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
LDAPTrustedMode STARTTLS
AuthLDAPURL ldap://other.ldapserver.com/o=ctx;
require valid-user
/Directory
The above configuration assumes that all connections to
foo.ldapserver.com will be non-secure on port 389 and that all
connections to other.ldapserver.com will be TLS connections on port
389. The problem is that the directive LDAPTrustedMode is global not
per-directory. Therefore even though the configuration intended to
connect to foo.ldapserver.com non-secure, since the global trusted
mode has been set to STARTTLS, util_ldap will attempt to start tls on
all connections.
Since the type of connection is already determined partially by the
AuthLDAPURL (ie. ldaps:// vs ldap://), changing the type to STARTTLS
also needs to be in the same scope as AuthLDAPURL. There are two
options, change LDAPTrustedMode to a per-directory directive within
util_ldap or move LDAPTrustedMode up into mod_authnz_ldap as
AuthLDAPTrustedMode.
Brad
Index: util_ldap.h
===
--- util_ldap.h (revision 126565)
+++ util_ldap.h (working copy)
@@ -117,8 +117,6 @@
int ssl_supported;
apr_array_header_t *global_certs; /* Global CA certificates */
apr_array_header_t *client_certs; /* Client certificates */
-int secure;
-int secure_set;
#if APR_HAS_SHARED_MEMORY
apr_shm_t *cache_shm;
Index: util_ldap.c
===
--- util_ldap.c (revision 149421)
+++ util_ldap.c (working copy)
@@ -57,7 +57,14 @@
int util_ldap_handler(request_rec *r);
void *util_ldap_create_config(apr_pool_t *p, server_rec *s);
+typedef struct {
+apr_pool_t *pool; /* Pool */
+int secure; /* APR_LDAP_NONE, APR_LDAP_SSL, APR_LDAP_STARTTLS
*/
+int secure_set;
+} util_ldap_dir_config_t;
+
+
/*
* Some definitions to help between various versions of apache.
*/
@@ -416,6 +423,8 @@
util_ldap_state_t *st =
(util_ldap_state_t *)ap_get_module_config(r-server-module_config,
ldap_module);
+util_ldap_dir_config_t *dc =
+(util_ldap_dir_config_t *)ap_get_module_config(r-per_dir_config,
ldap_module);
#if APR_HAS_THREADS
@@ -514,7 +523,7 @@
* setting optionally supplied by the admin using LDAPTrustedMode
*/
l-secure = (APR_LDAP_NONE == secure) ?
- st-secure :
+ dc-secure :
secure;
/* save away a copy of the client cert list that is presently valid */
@@ -1566,31 +1575,29 @@
* - SSL (SSL encryption)
* - STARTTLS (TLS encryption)
*/
-static const char *util_ldap_set_trusted_mode(cmd_parms *cmd, void *dummy,
const char *mode)
+static const char *util_ldap_set_trusted_mode(cmd_parms *cmd, void *config,
const char *mode)
{
-util_ldap_state_t *st =
-(util_ldap_state_t *)ap_get_module_config(cmd-server-module_config,
- ldap_module);
+util_ldap_dir_config_t *dc = config;
ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0, cmd-server,
LDAP: SSL trusted mode - %s,
mode);
if (0 == strcasecmp(NONE, mode)) {
-st-secure = APR_LDAP_NONE;
+dc-secure = APR_LDAP_NONE;
}
else if (0 == strcasecmp(SSL, mode)) {
-st-secure = APR_LDAP_SSL;
+dc-secure = APR_LDAP_SSL;
}
else if (0 == strcasecmp(TLS, mode) || 0 == strcasecmp(STARTTLS,
mode)) {
-st-secure = APR_LDAP_STARTTLS;
+dc-secure = APR_LDAP_STARTTLS;
}
Re: Time for 2.0.53?
[EMAIL PROTECTED] Monday, January 31, 2005 2:26:09 PM I'd love to see the LDAP socket timeout configuration stuff make it in for 2.0.53! -- Jess Holle Justin Erenkrantz wrote: Any opposition to doing a tag and roll of 2.0.53 soon? (Yes, I volunteer to be RM.) How about targetting next Tuesday (2/8) for 2.0.53? I can lay down the candidate tarball on Friday morning, so whatever backports are merged by then make it. =) Do we want closure on Jeff's proxy chunking patch for 2.0.53? -- justin Me too ;) Any voters out there? I've already cast my vote (Obviously) From the looks of the STATUS file, there appears to be a number of backports with 3 +1's that just need to be backported. Brad
Re: Auth LDAP ssl/tls differences
I guess I am still a little unclear on what the advantage is to using ldap:// + start_tls vs. ldaps://. The end result is the same except that you have a secure connection to the LDAP server on 389 rather than 636. Is that the only reason? Administrators don't want to open a dedicated SSL port to their LDAP server? I thought that the advantage of start_tls was to be able to initiate an unsecure long-lived connection and then when required, converting it to a secure connection for a period time and then possible back to unsecure again. In other words, the ability to bounce back and forward from an unsecure connection to a secure connection. Since the ldap communication between the httpd server and the ldap server is basically a single authorization request and response, there is no point in which an initial unsecure connection can be converted to a secure connection except when the connection is established initially. The connection is either entirely secure or not. As far as util_ldap is concerned, it seems like just another way of doing the same thing. If you want a secure connection to the LDAP server, just use ldaps://. Unless I am missing something, ldap:// + start_tls isn't really buying you anything. Something to think about - what about ldap connection caching? Are the ldap://+start_tls connections cached separately from ldap:// and ldaps:// connections? Or do they keep flip-flopping back and forth as required by the http request? If they keep flip-flopping, it seems like a lot of overhead just to get a secure connection. If they are cached separately then we are just implementing another secure connection cache when we already have one. If I am completely missing the point, then please correct me. Brad [EMAIL PROTECTED] Tuesday, January 04, 2005 12:40 PM It seems that our support for ssl/tls with mod_ldap is considerably confusing and frustrating for users. The recent interest in fixing support for the Solaris/Netscape/Mozilla library reminded me of the fact that we need to finish thinking this through. Fast summary for those less familiar; there are two SSL schemas for LDAP communications. . Solaris/Netscape/Mozilla support is based on explicit SSLv3 connection to the ldaps:// port, 636. . OpenLDAP supports ldaps://, it also supports STARTTLS protocol over port 389. STARTTLS should not be invoked by the scheme ldaps:// (it's a semantic error - ldaps:// should not refer to an upgraded SSL connection, and would imply port 636 which is not correct for this protocol.) The correct scheme/port for STARTTLS LDAP connections is ldap:// with port 389 implicit. We need a mechanism to clarify to mod_ldap that TLS security is desired. Incident http://issues.apache.org/bugzilla/show_bug.cgi?id=31443 offers a solution which we should consider adopting. As I was asking for some offline feedback - Graham mentioned that some implementations use the URL to specify that STARTTLS is desired. But without some references the proposal seems to be a better option - we shouldn't be redefining the ldap:// URI space. Does anyone have any references to specifying STARTTLS as part of the URI to the ldap server? Any other comments on this patch before I integrate into httpd-2.1? Bill
Re: Auth LDAP ssl/tls differences
I personally feel more comfortable having LDAP on an SSL port only, then I know there is no way my server can be accessed accidently without encryption in place. Call me paranoid, but I completely agree. Especially since the primary purpose of auth_ldap is authentication, ie. userid's and passwords and constantly being passed on the wire. This doesn't mean that APR-util doesn't support the concept of starting and stopping tls, it only means that util_ldap doesn't choose to use this option. So we should probably split start_tls out from apr_ldap_ssl_init() into it's own API. This way some other module or application built on top of apr-util will have the ability to start and stop TLS at will. Brad [EMAIL PROTECTED] Thursday, January 06, 2005 2:18 PM Brad Nicholes wrote: I guess I am still a little unclear on what the advantage is to using ldap:// + start_tls vs. ldaps://. The end result is the same except that you have a secure connection to the LDAP server on 389 rather than 636. Is that the only reason? Apparently ldap:// + STARTTLS is a standard, and ldaps:// is not a standard (although it's universally supported). The end result of both methods is the same - a secure connection. I personally feel more comfortable having LDAP on an SSL port only, then I know there is no way my server can be accessed accidently without encryption in place. But others want to use STARTTLS, and if it's technically possible, I see no reason to stop them. Something to think about - what about ldap connection caching? Are the ldap://+start_tls connections cached separately from ldap:// and ldaps:// connections? No - there is just one cache of connections. SSL/TLS is negotiated when the connection is first established, and remains that way until the connection is closed. Whether the initial negotiation was SSL or STARTTLS makes no difference, once util_ldap has said STARTTLS it doesn't stop TLS again until the connection is disposed of. This doesn't mean that APR-util doesn't support the concept of starting and stopping tls, it only means that util_ldap doesn't choose to use this option. Regards, Graham --
Re: Auth LDAP ssl/tls differences
Off the top of my head, performance. Maybe you really only need a secure connection during the bind but after that switching back to an unsecure connection would perform better. Maybe you want to hold a connection pool of LDAP connections that can be used to transfer sensitive information or clear information that is only determined at the time of the request. Maybe you want to allow for connections that start out as anonymous binds to access public information and then can be rebound using the user credentials over a secure connection. Who knows, but it seems like it would have the same type of application that TLS upgrade would have in mod_ssl. Brad [EMAIL PROTECTED] Thursday, January 06, 2005 4:44 PM At 05:19 PM 1/6/2005, Brad Nicholes wrote: This doesn't mean that APR-util doesn't support the concept of starting and stopping tls, it only means that util_ldap doesn't choose to use this option. So we should probably split start_tls out from apr_ldap_ssl_init() into it's own API. This way some other module or application built on top of apr-util will have the ability to start and stop TLS at will. Can anyone provide an example of why this would be useful? Otherwise it makes sense just to have one API, and let the user choose the flavor based on their server config (https://, or AuthLDAPClientTLS on). Our job in apr-util is to make developers lives easier, not more complicated, for the typical situations. Bill
Re: RELEASE directory change
Yes, a new module directory called debug was added as a subdirectory of modules. This conflicted with the debug output directory that was being created during the build process. The result was that everytime you did a gmake -f NWGNUMakefile clean it wiped out the source code found in the new modules/debug directory. So both the build debug and release directories were renamed to debug.o and release.o. Brad [EMAIL PROTECTED] Friday, December 17, 2004 2:58 PM Greetings All, Doing a build of httpd-2.1-dev for NetWare on Win and find the Release directories are now /release.o ... is this intended behaviour? Norm
Re: Apache HTTP Server 2.1.2 tagged...
+1, lets get something out there for the community to test. If we have to go through a bunch of 2.1.x-betas before we feel comfortable with branching, so be it. Brad [EMAIL PROTECTED] Monday, December 13, 2004 4:30:29 PM --On Monday, December 13, 2004 2:40 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: This would be 2.1.2-beta right? Not 2.2.0-beta1? Correct. Our first 'beta' release doesn't necessarily mean that it'd be 2.2.0-beta1. We can have as many 2.1.x betas as we want. However, I think it was said that the 2.2.0 branch will start with some 2.1.x beta - I just don't think we're quite at the branch point yet, but, IMHO, we should try to get some folks pounding on 2.1.x... -- justin
Re: Apache HTTP Server 2.1.2 tagged...
httpd builds on NetWare but we are having problems with the version of APR that was included in the tarball. APR 1.0.1 is failing to build on the latest LibC SDK on NetWare due to a couple of minor type mismatches. It requires the following patch from the APR 1.0.x branch: threadproc\netware\proc.c locks\netware\thread_mutex.c -r106967 Is a new revision of APR 1.0.x going to be released anytime soon? Brad [EMAIL PROTECTED] Thursday, December 09, 2004 1:29:37 AM In the continuing string of 2.1.x releases, Apache HTTP Server 2.1.2 is now available at: http://httpd.apache.org/dev/dist/ Currently, this is only an alpha-quality release and is only meant for developers to provide feedback for the upcoming 2.2 series. New features with the 2.1/2.2 series are listed here: http://httpd.apache.org/docs-2.1/new_features_2_2.html Changes are here: http://httpd.apache.org/dev/dist/CHANGES_2.1 Please provide feedback, votes, etc. If you have any problems, as always, please bring them up on [EMAIL PROTECTED] Thanks! -- justin
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
It may be a bit of a hack, but it seems reasonable to me. The best
part is that it works.
+1
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 2:33:48 AM
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the header, you are saying that the header is being sent
encrypted but the content is not, correct? And the reason for this
is
because there is more than one filter stack that needs to be
modified?
Yes. I think this fixes it, it's a bit of a hack though:
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 59)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1184,22 +1184,26 @@
apr_bucket *b;
SSL *ssl;
-/* Just remove the filter, if it doesn't work the first time, it
won't
- * work at all for this request.
- */
-ap_remove_output_filter(f);
+/* f-ctx is non-NULL after the first call to this filter: it's
+ * necessary to pass through directly to the connection
output_filters
+ * for the remainder of this request, since the SSL output filter
has
+ * not been added to r-output_filters for this request. */
+if (f-ctx) {
+return ap_pass_brigade(f-c-output_filters, bb);
+}
-/* No need to ensure that this is a server with optional SSL, the
filter
- * is only inserted if that is true.
- */
-
+/* No need to ensure that this is a server with optional SSL, the
+ * filter is only inserted if that is true. */
upgrade = apr_table_get(r-headers_in, Upgrade);
if (upgrade == NULL
|| strcmp(ap_getword(r-pool, upgrade, ','), TLS/1.0)) {
/* Upgrade: TLS/1.0, ... header not found, don't do Upgrade
*/
+ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
+f-ctx = f; /* flag as non-NULL for subsequent passes */
+
apr_table_unset(r-headers_out, Upgrade);
/* Send the interim 101 response. */
@@ -1245,7 +1249,6 @@
pass the brigade off to the connection based output filters so
that the
request can complete encrypted */
return ap_pass_brigade(f-c-output_filters, bb);
-
}
static apr_status_t ssl_io_filter_input(ap_filter_t *f,
Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)
FYI, if anybody else is interesting is testing the TLS upgrade
functionality, there is a small test utility
(http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send
an upgradeable GET or POST request.
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 9:01:22 AM
It may be a bit of a hack, but it seems reasonable to me. The best
part is that it works.
+1
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 2:33:48 AM
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the header, you are saying that the header is being sent
encrypted but the content is not, correct? And the reason for this
is
because there is more than one filter stack that needs to be
modified?
Yes. I think this fixes it, it's a bit of a hack though:
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 59)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1184,22 +1184,26 @@
apr_bucket *b;
SSL *ssl;
-/* Just remove the filter, if it doesn't work the first time, it
won't
- * work at all for this request.
- */
-ap_remove_output_filter(f);
+/* f-ctx is non-NULL after the first call to this filter: it's
+ * necessary to pass through directly to the connection
output_filters
+ * for the remainder of this request, since the SSL output filter
has
+ * not been added to r-output_filters for this request. */
+if (f-ctx) {
+return ap_pass_brigade(f-c-output_filters, bb);
+}
-/* No need to ensure that this is a server with optional SSL, the
filter
- * is only inserted if that is true.
- */
-
+/* No need to ensure that this is a server with optional SSL, the
+ * filter is only inserted if that is true. */
upgrade = apr_table_get(r-headers_in, Upgrade);
if (upgrade == NULL
|| strcmp(ap_getword(r-pool, upgrade, ','), TLS/1.0)) {
/* Upgrade: TLS/1.0, ... header not found, don't do Upgrade
*/
+ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
+f-ctx = f; /* flag as non-NULL for subsequent passes */
+
apr_table_unset(r-headers_out, Upgrade);
/* Send the interim 101 response. */
@@ -1245,7 +1249,6 @@
pass the brigade off to the connection based output filters so
that the
request can complete encrypted */
return ap_pass_brigade(f-c-output_filters, bb);
-
}
static apr_status_t ssl_io_filter_input(ap_filter_t *f,
Re: Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)
Seems reasonable. I would have to take a closer look at it though. Brad [EMAIL PROTECTED] Wednesday, December 08, 2004 10:56:10 AM At 10:10 AM 12/8/2004, Brad Nicholes wrote: FYI, if anybody else is interesting is testing the TLS upgrade functionality, there is a small test utility (http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send an upgradeable GET or POST request. It seems to me we can make ab.c TLS upgrade-aware by; 1. recognizing the -s flag in conjunction with http: - that would set the ssl preference client-side. (This would not alter the behavior of https:, or of -s without a scheme.) 2. recognize upgrade-required and promote an http: connection to SSL when the server-side demands it. Sane? Bill
Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
It appears that the patch for bug 18757 which disallows a
content-length header for all requests with a content-length of 0 is too
broad.
Index: D:/Projects/2.x/httpd-trunk/server/protocol.c
===
--- D:/Projects/2.x/httpd-trunk/server/protocol.c (revision
104639)
+++ D:/Projects/2.x/httpd-trunk/server/protocol.c (revision
104923)
@@ -1244,8 +1244,11 @@
*
* We can only set a C-L in the response header if we haven't
already
* sent any buckets on to the next output filter for this
request.
+ *
+ * Also check against cases of zero bytes sent, to avoid a bogus
+ * C-L on HEAD requests, or no-body GETs like 204s.
*/
-if (ctx-data_sent == 0 eos) {
+if (ctx-data_sent == 0 eos r-bytes_sent 0 ) {
ap_set_content_length(r, r-bytes_sent);
}
Property changes on: D:/Projects/2.x/httpd-trunk/server/protocol.c
___
Name: cvs2svn:cvs-rev
- 1.150
+ 1.151
The bug simply says that the content-length should be removed just for
HEAD requests. By removing it for all requests including an OPTIONS
requests, causes the SSL handshake to fail after a TLS upgrade (somebody
with more knowledge of SSL would have to explain why). According to the
bugzilla report, this patch didn't completely resolve the issue anyway.
I will be reverting the patch shortly unless somebody has a better fix.
Brad
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
So what are you suggesting that the appropriate fix should be? Even
though the protocol.c patch was bogus, it sounds like might have exposed
something else. In fact I am still not seeing where the problem is.
The protocol.c patch was just allowing a bad response to happen that
should never have happened in the first place. It seems like the
appropriate OPTIONS response should include C-L:0. Anything else that
actually has content would also contain the appropriate C-L: header.
Brad
[EMAIL PROTECTED] Tuesday, December 07, 2004 12:51:15 PM
On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote:
I tested the TLS upgrade stuff last week and it failed because the
zero-length chunk to terminate the OPTIONS response was not sent
through
the mod_ssl output filter; is that the same problem you see?
I don't think so. I can make everything work again by simply
allowing
the Content-Length: 0 header to be sent through. I'm not sure
what
impact that header has on the rest of mod_ssl. Obviously by
removing
it, it causes mod_ssl to *not* do something it was suppose to. My
guess
is that if the zero-length chunk that terminates the OPTIONS response
is
not being sent, it is probably a result of mod_ssl not seeing a
content-length header.
I think we are seeing the same problem. Before, a zero-length OPTIONS
response would be sent with t-e: chunked and a single
zero-terminator-chunk. The 0\r\n\r\n packet was being sent
unencrypted
and breaking the SSL connection. After you reverted the protocol.c
change, a zero-length OPTIONS response is sent with C-L: 0 and hence
terminates after the headers. Subsequent requests on the connection
get
the right filter stack.
So you have successfully hidden the mod_ssl bug for upgrades with
zero-length responses. The fact that mod_ssl (incorrectly) refuses to
upgrade anything other than an OPTIONS request makes the bug less
obvious since OPTIONS responses are rarely anything but zero-length,
but
I'll fix that.
For an upgrade on GET the strace now looks like:
send(3, GET / HTTP/1.1\r\nHost..., 173, 0) = 173
recv(3, HTTP/1.1 101 Switchi..., 4096, 0) = 85
read(4, *J\204\17\342g l\327U\323/\271..., 32) = 32
write(3, \200|\1\3\1\0c\0\0\0\20\0\0009..., 126) = 126
SSL negotiation and response headers
read(3, \26\3\1\, 5) = 5
read(3, a\20\363\37{\372\347\205\350\36..., 48) = 48
read(3, html, 5) = 5
^ uh-oh!
BTW, what are you using to test TLS Upgrade with?
A hacked up version of neon.
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
OK, now that you have enabled upgrades for anything other than OPTIONS, I see the problem. Even though there is a content-length included in the header, you are saying that the header is being sent encrypted but the content is not, correct? And the reason for this is because there is more than one filter stack that needs to be modified? Brad [EMAIL PROTECTED] Tuesday, December 07, 2004 4:18:13 PM On Tue, Dec 07, 2004 at 03:00:52PM -0700, Brad Nicholes wrote: So what are you suggesting that the appropriate fix should be? Even though the protocol.c patch was bogus, it sounds like might have exposed something else. In fact I am still not seeing where the problem is. Try doing an upgrade on any request where the response includes an entity. I originally tried modifying ssl_io_filter_init and upwards to take an optional request_rec * and pass that to ap_add_output_filter but this broke everything horribly. Possibly I just missed some subtlety but if that's fatally flawed I have no better ideas. joe
Re: mod_auth_ldap and mod_auth interaction
The short answer is that it is already fixed in Apache 2.1/2.2. Unfortunately you have hit on one of the limitations of the Apache 2.0 authentication module structure. The problem is that authorization types are replicated through multiple authentication modules. Fortunately this has all been taken care of in Apache 2.1/2.2. For example, in the Apache 2.1/2.2 version of mod_authnz_ldap, the authorization types are no longer user, group, etc., they are ldap-user, ldap-group, etc. You can also mix and match different types of authorization with authentication. The quick fix for Apache 2.0 is to set AuthAuthoritative off so that if the mod_auth authorization fails, it will defer to mod_auth_ldap which will work. Brad [EMAIL PROTECTED] Tuesday, November 30, 2004 5:35:29 AM Sorry if this belongs in the users group, it's a query, but a query about the working of the code. I've filed a bug (32426) but am trying to fix it myself. What I've found is that if user_is_dn is set (AuthLDAPRemoteUserIsDN in an .htaccess file) then mod_auth_ldap sets r-user to be the users dn, not the user uid authenticated as. util_script.c uses this value to set REMOTE_USER (Good, all is well :) but.. mod_auth.c users this value to check the require(d) user and of course fails as the list of users is a list of uid's mod_auth_ldap has it's own require ( user | group | valid-user) checks. These are used for require group successfully but not require user. Is there a way to get information such as req-user or user_is_dn back into mod_auth? I'm guessing not easily you don't really want to mess with mod_auth. Or get mod_auth to use mod_auth_ldaps' auth_checker for require user as is does for require group which I think is the correct solution. Hoping someone familiar with the code can save me some time. Cheers, Duncan
Re: A zLib Update....?
NetWare builds against either 1.1.x or 1.2.x. It just depends on where you point the ZLIBSDK environment variable at compile time. Brad [EMAIL PROTECTED] Tuesday, November 30, 2004 6:52:58 AM At 01:57 AM 11/30/2004, Justin Erenkrantz wrote: --On Tuesday, November 30, 2004 6:53 PM +1100 NormW [EMAIL PROTECTED] wrote: With the recent upgrade of PCRE for Apache 2.1.x, I was curious if zLib (required for mod_deflate) is mandated at 1.1.4 or could it also be 'updated' to the 1.2.1 release (available since Nov'03). A 2.1 build on Windows for NetWare shows it glues together without issue; are there any test scripts that one might use to see if it works as expected? We don't bundle zlib. So, there's nothing for us to do. Or, do the Win32 folks perhaps bundle it? But, Unix only works off an external zlib. -- And win32 httpd-2.0 builds only with 1.1.x sources. httpd-2.1 builds against the zdll1.lib (and requires zlib1.dll), e.g. 1.2.2. Since zlib1.dll is an 'official format' now - when httpd 2.2 is released and a hole is found, the user can obtain zlib1.dll right from their web site rather than waiting for the 'next' httpd rel. Bill
Re: PCRE in 2.1/2.2
While trying to get NetWare to build with the new PCRE update, I noticed that there is a duplicate of pcreposix.h in both include/ and srclib/pcre/ directories. Currently they don't match which is causing the NetWare build to break. I can sync them up, but the real question is should this file be duplicated in include/ or moved from srclib/pcre/ to include/ ? Brad [EMAIL PROTECTED] Saturday, November 27, 2004 12:24:06 PM Joe Orton wrote: On Fri, Nov 26, 2004 at 11:55:35PM -0800, Brian Pane wrote: Yep. I just did that, and it worked as expected. I ended up with a clean merge: the only files that needed merge conflict resolution were those that had been modified in the srclib/pcre copy: Looks good, thanks Brian. Do you think it's worth keeping all ~1Mb of the doc/ directory in srclib/pcre? I think it might as well be removed, they won't get installed and developers can refer to the vendor/pcre copies if necessary. svn merge will happily ignore the removed files when merging to future versions so there's no issue there. +1, I'll remove docs/* from srclib/pcre and add a README pointing to vendor/pcre. Brian
Re: NWGNUmakefiles - Update or prod.
Checked in thanks, Brad [EMAIL PROTECTED] Wednesday, November 24, 2004 9:12:06 PM Greetings All, Attached and listed below are two NWGNUmakefiles plus diff's to add them into to the httpd build processdisavow being a wiz at this stuff and if someone doesn't like the names chosen, etc here's the chance to supply something better (the prod)... :-)
Re: Apache 2.1 Builds...
It looks like some changes in the LibC SDK exposed some type mismatches in some of the NetWare code. These have been fixed and checked in. Brad [EMAIL PROTECTED] Saturday, November 27, 2004 2:04:41 PM Greetings All, Thanks to all the recent updates the 2.1 (.2?) now builds cleanly using the June LibC from go to whoa However the issue mentioned previously with the Oct LibC persists... the LibC docs show no change in the function definition... Regards, Norm
Re: 2.1.1 tarballs posted...
Since this is alpha level, should the server signature contain -alpha so that users don't get this confused with an actual release? Once I build binaries for NetWare, the only thing that will indicate that this is an alpha is the name of the .zip file. It would be less confusing if the binaries also showed that it is an alpha. Index: ap_release.h === --- ap_release.h(revision 105990) +++ ap_release.h(working copy) @@ -36,7 +36,7 @@ #define AP_SERVER_MAJORVERSION_NUMBER 2 #define AP_SERVER_MINORVERSION_NUMBER 1 #define AP_SERVER_PATCHLEVEL_NUMBER 1 -#define AP_SERVER_ADD_STRING +#define AP_SERVER_ADD_STRING -alpha /* keep old macros as well */ #define AP_SERVER_MAJORVERSION APR_STRINGIFY(AP_SERVER_MAJORVERSION_NUMBER) Brad [EMAIL PROTECTED] Friday, November 19, 2004 11:14:19 PM http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin
Re: 2.1.1 tarballs posted...
The netware build is not copying the charset.conv file to the /conf directory during the make install stage. I just committed a patch for NWgnumakefile. Brad [EMAIL PROTECTED] Friday, November 19, 2004 11:14:19 PM http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin
More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see trunk which could be any one of a number of files. Not all of which I am interested in. Personally I would opt for file listings rather than directory listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. Thanks again for all of your hard work. Brad Justin Erenkrantz [EMAIL PROTECTED] Friday, November 19, 2004 12:12:39 PM --On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Our CVS mailer only showed the last directory (with files) that was committed - so subject lines were *always* inaccurate when touching multiple directories. The SVN mailer always shows all directories that were modified. I think that's a far better compromise. Plus, we've received a number of complaints that the subject lines were too long to be useful: hence just the directory names. *shrug* -- justin
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I understand about the revision numbers and I agree that it is an important piece of information, but unnecessary on the subject line. The subject line needs to include information that allows one to quickly sort and prioritize the commits. IMHO, the revision number isn't a piece of information that helps do that. Once I have determined that the commit is important enough for me to review, I will certainly open and view the contents of the message. After I have reviewed the commit via the message contents and determined that further review is necessary, that is the point when the revision number becomes *very* important. As far as the svn commit: prefix is concerned, it was redundant information before and I believe that it is still redundant information. Perhaps svn: is all that would be required so that when a commit message is replied to on the dev@ lists, it is distinguished from other posts. Brad [EMAIL PROTECTED] Friday, November 19, 2004 2:47:17 PM --On Friday, November 19, 2004 2:41 PM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. IMHO, the revision number is the *most* important attribute of the commit. Subversion uses global revision numbers: there is no per-file revisions like CVS. If you know the revision number, you can get everything else. And, we already had a 'cvs commit: ' prefix on our previous CVS emails. -- justin
Re: Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
Taking a snapshot look at the STATUS file at any given point in time does not show the actual problem. The problem is the delay in getting from point A (submitting a proposal) to point B (approval for backport). For a hot issue with many interested parties (who actually hold voting rights), getting a backport proposed and accepted is rather quick. In such cases I would even suggest that the backport proposal policy is simply a formality and overhead because those voting on a hot issue have already reviewed the issue even before it hit the STATUS file. So rather than just checking in a patch that has already been reviewed by the dev@ list, it is delayed simply on formality. But that is a different discussion on a minor point. The main evidence is the trend that is happening before each release. A release is proposed, an RM is selected, the RM sets a deadline and everybody emails the list with their favorite backport issue. Now the RM has to deal not only with the release but whether or not a backport has been accepted, can the tree be tagged yet, does a tag need to be moved, etc. Oh Oops a backport didn't make it and now we need to issue a release patch for a segfault(http://www.apache.org/dist/httpd/patches/apply_to_2.0.52/). Not only that but IMO, this in itself is a major contributor to destabilization. The best way to make sure that the branch is stable is to get it out in front of those that are testing and using it. Not throw a bunch of patches in right before we release just because they got three +1's. Implementing lazy consensus would make others aware of proposed backports, allow them to review the issue if interested and allow the backport to move smoothly and quickly through the process without having to beg the list for reviewers at the last minute. The opposite question is what evidence do we have that RTC isn't doing more harm than good once the branch is stable? And please don't point to the mess that happened between 2.0.35 and 2.0.4x. IMO, that mess was due to the fact that it was a first GA release and we just flat out got it wrong. It then took a few more rather quick releases to get it finally right. RTC for that period of stabilization may have been valuable, but since stabilization was achieved, it is just getting in the way of community involvement and ennovation. Brad [EMAIL PROTECTED] Wednesday, November 17, 2004 12:42:08 PM On Tue, Nov 16, 2004 at 06:10:17PM -0700, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Looking through the STATUS file, there doesn't actually appear to be much backport stagnation at all. The majority of stale backport proposals are stale because they are pending updates from the submitter after review by others, or they have been vetoed by a reviewer. Which is all healthy. So what's the evidence that there is a slowdown of activity caused by the backport policy? There have been four 2.0 releases already this year, including 179 individual user-visible changes listed in CHANGES according to grep. Sounds pretty healthy to me. Regards, joe
Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to the [EMAIL PROTECTED] [EMAIL PROTECTED] Tuesday, November 16, 2004 4:08:20 PM During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Brad
Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
[EMAIL PROTECTED] Tuesday, November 16, 2004 4:28:38 PM On Tue, Nov 16, 2004 at 04:08:20PM -0700, Brad Nicholes wrote: slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. -1 (vote, not veto). I think this is a bad idea and would make stable turn into CTR. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. If there are a lack of votes for backport, then I believe that is a sign that there is not a healthy enough community of people who are able to review the code. I'd like to ensure that we don't create 'islands' of code that do not have sufficient people who understand it. -- justin
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 4:46:45 PM On 17.11.2004, at 00:30, Cliff Woolley wrote: On Tue, 16 Nov 2004, Justin Erenkrantz wrote: I think this is a bad idea and would make stable turn into CTR. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. I agree with Justin, but I recognize what a pain in the ass it is for people working off in the corners of the codebase. So -0 from me. Exactly the same feelings here, so -0 from my side too. Cheers, Erik
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 5:21:28 PM +1 Lazy consensus applied in this way will help the less popular parts of our codebase to continue to evolve and stabilize. Up to this point, only the most popular patches have been getting enough attention to receive the required three +1s. Going in this direction is definitely the right way to go. p.s. why is this on the pmc list? we have committers who aren't PMCers, right? -aaron On Nov 16, 2004, at 3:08 PM, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Brad
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to the dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 5:48:15 PM If there are a lack of votes for backport, then I believe that is a sign that there is not a healthy enough community of people who are able to review the code. I'd like to ensure that we don't create 'islands' of code that do not have sufficient people who understand it. -- justin This is the definition of the downward spiral that we are in. If the code doesn't get out there then the interest in the code drops off. The more the interest in the code drops off, the less code there is to put out there. The whole idea behind Open Source is to get the code in front of the user, allow them to test, supply feedback so that bugs can be fixed. If the code gets hung up in the STATUS file, we don't get any feedback therefore the code never gets fixes. I would personally rather see the code in front of the user so that it is reviewed by more than just those with voting rights. How else are we going to generate a community. Brad [EMAIL PROTECTED] Tuesday, November 16, 2004 4:28:38 PM On Tue, Nov 16, 2004 at 04:08:20PM -0700, Brad Nicholes wrote: slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. -1 (vote, not veto). I think this is a bad idea and would make stable turn into CTR. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. If there are a lack of votes for backport, then I believe that is a sign that there is not a healthy enough community of people who are able to review the code. I'd like to ensure that we don't create 'islands' of code that do not have sufficient people who understand it. -- justin
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 6:00:16 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 it might open up a couple of bugs/regressions, but it will certainly mean more fixes going in On 17/11/2004, at 10:08 AM, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Brad - -- Ian Holsman Director Network Management Systems CNET Networks PH: 415-344-2608 (USA) /(++61) 3-9818-0132 (Australia) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBmqKgq3pgvCz4ZCcRAk6aAJ4pjGy170JuvPoq8fWgWtsf3Qw+kQCfXSe+ RmXGGKTaFWWTH6UeO/IQVZU= =k5e/ -END PGP SIGNATURE-
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 6:04:08 PM This proposal is in addition to the proposal on the dev list. Once the code converts from CTR to RTC in a stable branch, then we need a way to make sure that overhead doesn't stifle ennovation. The fact is that users and casual developers pay more attention to the stable branch rather than HEAD. Why?? Because that is what matters to them. If there is an itch that needs to be scratched, it's in the code that they are depending on to run their site. That is usually not the bleeding edge. Brad [EMAIL PROTECTED] Tuesday, November 16, 2004 4:29:31 PM * Brad Nicholes [EMAIL PROTECTED] wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. I think, the RTC policy for 2.0 is a good thing. It *forces* reviews, which actually often helped to prevent introducing new bugs (not always though, but that's probably another issue). IMHO a better way bring the development further is the suggestion on the dev list. *absolute* feature freeze on stable branches (except 1.3?), bug fixes only. Though it would need some time to establish the trust of the community in so much more versions, I like that idea somehow. nd -- Das einzige, das einen Gebäudekollaps (oder auch einen thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken und AOL-CDs. -- Bastian Lipp in dcsm
Re: Branching and release scheduling
I have to agree with Jim. Well put! Brad [EMAIL PROTECTED] Tuesday, November 16, 2004 5:55:04 PM On Nov 16, 2004, at 3:16 PM, Manoj Kasichainula wrote: We had a good discussion over lunch today on our release processes and how to have stable releases while making new feature development as fun and easy for the geeks as possible. The is a purely personal POV, and I'm wishing I was at the lunch because this addresses something that I've been think and maybe others as well, considering a similar Email thread I see from Brad N, so take the below as my own opinions. I find it somewhat hard to get excited by 2.x development because 2.1 almost seems like a black hole at times... You put the energy into the development but have to wait for it to be folded into an actual version that gets released and used. Now waiting is good, but sometimes it seems that the backports are slow in getting approved. I think most developers like, well, if not *immediate* satisfaction, something more quick than the current develop-2.1-and-wait- for-a-long-time-before-folded-into-2.0. Stability is great, but we should be careful that we don't unduly sacrifice developer energy. This may not be so clear, so feel free to grab me :)
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
It's not Linux but here is a piece of information that should help. NetWare is a thread only environment which means that we have been shipping and running all of the standard modules since day one with really no report of any threading related issues. I can't speak for any third party modules out there that may not be thread safe and I understand that Apache for NetWare has nowhere near the number of installations as Linux or others, but our standard modules seem to be doing well from a NetWare point of view. Even on multi-proc machines. Granted we don't normally stress test mod_example ;). Brad [EMAIL PROTECTED] Thursday, November 11, 2004 3:38:29 AM On Sat, Nov 06, 2004 at 12:48:50AM -0800, Justin Erenkrantz wrote: --On Saturday, November 6, 2004 8:28 AM + [EMAIL PROTECTED] wrote: @@ -125,6 +125,8 @@ +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? Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin I don't really agree with this. Many third-party modules still aren't thread-safe (and probably quite a few shipped in httpd too e.g. mod_example!). Making worker the default won't solve that, it'll just create a stream of I upgraded to 2.2 and now everything segfaults bug reports and people will stick with 1.3/2.0. 2.2 can be a compelling upgrade without making worker the default. joe
RE: [PATCH]Re: Adding a new user DN cache to authnz_ldap...
Good point. I will get the patch committed
Brad
Jari Ahonen [EMAIL PROTECTED] Thursday, November 04, 2004
7:39:01 AM
Brad,
I think this patch should be applied to the current HEAD
util_ldap.c code. It prevents util_ldap_cache_getuserdn()
timestamping cache entries with bindpw.
- Jari
- cut here - cut here -
--- util_ldap.c.orig2004-11-02 00:43:24.0 +0100
+++ util_ldap.c 2004-11-04 15:34:23.0 +0100
@@ -1096,7 +1096,12 @@
/* Nothing in cache, insert new entry */
util_ald_cache_insert(curl-search_cache,
the_search_node);
}
-else {
+/*
+ * Don't update lastbind on entries with bindpw because
+ * we haven't verified that password. It's OK to update
+ * the entry if there is no password in it.
+ */
+else if (!search_nodep-bindpw) {
/* Cache entry is valid, update lastbind */
search_nodep-lastbind = the_search_node.lastbind;
}
- cut here - cut here -
Re: [PATCH]: LDAP Authz (was: Ldap Authorization)
I like the suggestion as well because I think that would be the right way to implement complex LDAP expressions. But it would probably take adding at least a new util_ldap_filter_search() API to Util_ldap() in order to accomodate this functionality. The advantage of also having an ldap-attribute directive is because if simplicity as well as performance. According to the LDAP docs, doing an ldap_compare_s() is faster than an ldap_search_s(). I will go ahead an commit the patch as-is and also propose a backport for it. But I think that we should look at adding a require ldap-filter directive as well for Apache 2.1/2.2. Brad [EMAIL PROTECTED] Wednesday, November 03, 2004 8:09:35 AM Good suggestion. I am +1 for the patch as-is with the intent of looking into adding the below On Nov 3, 2004, at 5:04 AM, Graham Leggett wrote: Brad Nicholes wrote: I took a quick look at this patch and it seems to work well as long as all of the listed attributes are OR'ed together. I don't have a good suggestion yet, but is there a way to implement the logic so that attributes could be also AND'ed together? Or even a NOT-EQUAL operation? I think the best way to do this probably is instead of saying require ldap-attribute you say require LDAP filter. In other words, like this: require filter (objectclass=specialPerson) or require filter (host=somehost.com) This supports more complicated stuff, like this: require filter ((objectclass=specialPerson)(host=somehost.com)) Regards, Graham -- -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: cvs commit: httpd-2.0 STATUS
You are correct that a patch based on mod_authnz_ldap.c won't apply cleanly to mod_auth_ldap.c because of various differences in the code base. But the patch is fairly self-contained meaning that the same chunk of code can easily be copied from mod_authnz_ldap.c and pasted into mod_auth_ldap.c without modification to the code snipet itself. I can certainly create and post an actual patch file that will apply cleanly to mod_auth_ldap.c if required. But it shouldn't be difficult to review the patch as it stands in mod_authnz_ldap.c. Brad [EMAIL PROTECTED] Wednesday, November 03, 2004 4:01:07 PM On Wed, Nov 03, 2004 at 10:16:55PM -, [EMAIL PROTECTED] wrote: ... +*) mod_authnz_ldap: Added the directive Requires ldap-attribute that + allows the module to only authorize a user if the attribute value + specified matches the value of the user object. PR 31913 + modules/aaa/mod_authnz_ldap.c: r1.7 +docs/manual/mod/mod_authnz_ldap.xml: r1.3 + +1: bnicholes mod_authnz_ldap doesn't exist in 2.0; would this diff actually apply to mod_auth_ldap? If not then a separate patch needs to be posted somewhere for review. joe
Re: [PATCH]: LDAP Authz (was: Ldap Authorization)
I took a quick look at this patch and it seems to work well as long as all of the listed attributes are OR'ed together. I don't have a good suggestion yet, but is there a way to implement the logic so that attributes could be also AND'ed together? Or even a NOT-EQUAL operation? Brad [EMAIL PROTECTED] Sunday, October 31, 2004 2:03:53 PM I've opened an enhancement in bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=31913 I have attached the patch here for review. I'd also like to get this committed to the 2.0 tree so people can start taking advantage of the feature without waiting for 2.2. Thoughts?
Adding a new user DN cache to authnz_ldap...
I see your point about the req structure being tied to closely to authentication phase so that authorization will not work without it. Now I understand the need for util_ldap_cache_getuserdn() which is the real patch that needs to be added. In other words, the relevant bug is actually 28253 not 31898. The question now is should the same search cache used by util_ldap_cache_checkuserid() also be referenced in util_ldap_cache_getuserdn(). I guess it could be, but I am thinking that even though some user DN's might be stored in two different caches, it would be safer to create a new cache just for user DN's. This way, util_ldap_cache_checkuserid() can continue to enforce the no NULL or blank passwords as it was originally designed, as well as avoiding a potential false positive if util_ldap_cache_getuserdn() were to insert a NULL password entry thus allowing a user without a password to pass authentication when the cache is checked by util_ldap_cache_checkuserid(). Brad Jari Ahonen [EMAIL PROTECTED] Friday, October 29, 2004 8:53:41 AM Brad, What I've written below might sound that I'm just arguing that things should be done my way. Don't take it like that, I'm just trying to make it easier for you to understand my viewpoint on this issue. Brad Nicholes wrote: So basically what you did was write a function that puts bad data into the cache that the cache was never designed to handle or allow. I'm not sure I would agree with that. But then, I haven't seen the design specifications for the cache. I based my assumptions on comments in util_ldap_cache.h which I thought implied that NULL bindpw is allowed in a cache record. I would suggest closing the first bug that you wrote and opening another one that states that you would like to add new functionality to util_ldap through a functioned call util_ldap_cache_getuserdn(). That's what I tried some time back with bug 28253 but it didn't go very far... No, there are two other caches that are implemented by util_ldap. They are the compare cache and the comparedn cache. These caches are primarily used during the authorization phase rather than the authentication phase. True. And I understand that these caches exist and what they are used for. But what is missing in the current util_ldap implementation is a function that allows you to get the user DN out of the directory without having to supply the correct user password. None of the functions defined in include/util_ldap.h do that, yet this is what is needed in order to do LDAP group authorizations. Even the Apache 2.1 mod_authnz_ldap will not be able to authorize a request if that request is authenticated with some other module. This is because the user DN (In authn_ldap_request_t *req structure) is attached to the request in authentication phase and recalled later in authorization phase. If the request is not authenticated with mod_authnz_ldap, the req structrure does not exist and with current util_ldap there is no way to get the DN without knowing the user password. The end result of all this is that it is impossible to do authorization based on LDAP groups if you are authenticating with some other module. So we need some way of creating that authn_ldap_request_t structure in the authorization phase of the request. I thought the easiest way of doing this would be making a copy of util_ldap_cache_checkuserid() without password checking that would store the results in the cache with bindpw=NULL. But doing so caused the problems I reported in bug 31898. Storing bindpw= would cause slightly different problem because then the current util_ldap_cache_checkuserid would allow anyone in with blank password as long as the user had authenticated once and the cache record hasn't expired. Alternative fix for my problem is for myself to store the cache entries with bindpw= and move the blank password check that is now somewhere in the middle of util_ldap_cache_checkuserid() into the beginning of the function, before the cache check. In fact maybe that blank password check should be one of the first checks anyway since it makes no sense to do all that cache and LDAP searching if blank passwords aren't allowed at all. - Jari -- -- | Jari Ahonen | Progress Software Europe | | [EMAIL PROTECTED] | Schorpioenstraat 67| | Tel: +31-10-2865 700 | 3067 GG Rotterdam | | Fax: +31-10-2865 225 | The Netherlands| || | Once you've made the commitment to recreation, | | there is no turning back. | --
Re: Adding a new user DN cache to authnz_ldap...
Since the checkuserid cache does not allow NULL or blank passwords today and its purpose is for authentication, I'm just not completely comfortable allowing another function whose purpose it is to simply lookup user DN's to insert NULL or blank password entries. It seems like it would potentially open up holes where there wasn't a problem before. Adding a separate cache would just eliminate any potential problems. Brad Jari Ahonen [EMAIL PROTECTED] Friday, October 29, 2004 2:51:47 PM Brad Nicholes wrote: I see your point about the req structure being tied to closely to authentication phase so that authorization will not work without it. Now I understand the need for util_ldap_cache_getuserdn() which is the real patch that needs to be added. In other words, the relevant bug is actually 28253 not 31898. In a way they are both relevant because applying the changes needed for 28253 will cause the behaviour in 31898. The question now is should the same search cache used by util_ldap_cache_checkuserid() also be referenced in util_ldap_cache_getuserdn(). I guess it could be, but I am thinking that even though some user DN's might be stored in two different caches, it would be safer to create a new cache just for user DN's. I think the same search cache should be used. To me it makes no sense to have two caches with more or less the same data in them. Having a record in search cache with bindpw=NULL should be a good enough indicator that the particular record has not been through password verification (In fact the commets in util_ldap_cache.h suggest this might have been planned at some point). It is easy enough to check if bindpw exists in a cache record in util_ldap_cache_checkuserid() to prevent access with blank passwords. And a cache record created by util_ldap_cache_checkuserid() can be used with util_ldap_cache_getuserdn() since that function does not need to care about passwords. I have had a server running with this kind of setup for quite a while now, it was just that the shared cache changes done in 2.0.52 added the extra check that started to crash my server when util_ldap_cache_checkuserid() tries to strcmp() that NULL password. - Jari -- -- | Jari Ahonen | Progress Software Europe | | [EMAIL PROTECTED] | Schorpioenstraat 67| | Tel: +31-10-2865 700 | 3067 GG Rotterdam | | Fax: +31-10-2865 225 | The Netherlands| || | Once you've made the commitment to recreation, | | there is no turning back. | --
Re: cvs commit: httpd-2.0/server core.c protocol.c request.c scoreboard.c util.c util_script.c
mod_cache is a different issue. The compiler used to build the netware NLMs is very sensitive to type mismatches. @@ -3793,7 +3794,7 @@ core_net_rec *net = f-ctx; core_ctx_t *ctx = net-in_ctx; const char *str; -apr_size_t len; +apr_ssize_t len; Changing the type from apr_size_t to apr_ssize_t introduced a type mismatch in the call to apr_bucket_read() which expects an apr_size_t. Type casting it back to an apr_size_t to fix the problem seems like it would have defeated the whole purpose of doing it in the first place. Besides the fact that apr_bucket_read() can't give you back anything bigger than an apr_size_t anyway. Brad [EMAIL PROTECTED] Monday, October 25, 2004 10:01:53 AM Brad Nicholes wrote: -1 as well. This is now causing compiler errors on NetWare. Please revert this patch! Can you provide an indication of exactly what broke so we will know what to avoid in future. Or was the breakage actually due to the the mod_cache problem reported last night? Thanks, Allan
Re: Apache HTTP Server 1.3.32 RC Tarballs available for test
+1 NetWare [EMAIL PROTECTED] Monday, October 18, 2004 8:15:16 PM The RC tarballs for 1.3.32 are available for review and feedback: http://httpd.apache.org/dev/dist/ 1.3.32 is *not* yet released; these are simply the release candidate tarballs. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: Bye bye welcome page
From what I can see, the reason for providing a short and simple welcome page is to avoid confusing people by giving them too much information. The question I would ask is, are you just trading one set of problems for another? How many people are we going to confuse by not giving enough information? You may be climbing out of one boat full of problems, just to climb into another. Translation issues aside, personally the only thing that I see wrong with the welcome page is the fact that it keeps referring to this system. Cut the first paragraph and the rest is fine. I guess the point is, too much information might be a problem in this case, but then so is too little. Just my 1 of 1000 opinions. Brad [EMAIL PROTECTED] Wednesday, October 06, 2004 11:12:33 AM On Tue, 5 Oct 2004, Graham Leggett wrote: Joshua Slive wrote: No, because this is a very confusing and ambiguous statement from the perspective of a random web surfer who stumbles on the page. Their response is Why are you saying I installed a webserver on my computer? This must be some kind of security breach. Call in the marines! (And I'm hardly exagerating!) Point... How about The website you have accessed has not yet been configured. Please try to access this website again later.? It's directed at end users, and does not imply anywhere that the server might be running on their local machine. My opinion is that the shorter message is better because, by the fact that it gives no information at all, it is less likely to be misinterpreted to mean something that the website owner doesn't intend. I won't object if someone wants to put another piece of text there, as long as it doesn't start us back on the same road we left 5+ years ago with this page. Joshua.
segfault patch for util_ldap (was:Re: cvs commit: httpd-2.0 STATUS)
Since this patch was the last of three fixes for util_ldap and didn't make it into 2.0.52 because of lack of votes and since it fixes a segfault in util_ldap, now that it has the required votes, I would suggest we backport the fix and post the patch in /dist/httpd/patches. Any objections? Brad [EMAIL PROTECTED] Tuesday, September 28, 2004 10:20:11 AM clar2004/09/28 09:20:11 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: added vote for ldap cache purge fix Revision ChangesPath No revision No revision 1.751.2.1089 +2 -2 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.1088 retrieving revision 1.751.2.1089 diff -u -r1.751.2.1088 -r1.751.2.1089 --- STATUS24 Sep 2004 14:29:26 - 1.751.2.1088 +++ STATUS28 Sep 2004 16:20:10 - 1.751.2.1089 @@ -81,7 +81,7 @@ *) Fix a segfault in the LDAP cache purge. PR 24801 modules/ldap/util_ldap_cache_mgr.c: 1.9, 1.10 - +1: minfrin, bnicholes + +1: minfrin, bnicholes, clar bnicholes - backporting modules/ldap/util_ldap_cache_mgr.c: r1.7 below should eliminate the need to backport the else condition included in this patch.
Re: segfault patch for util_ldap (was:Re: cvs commit: httpd-2.0 STATUS)
I wouldn't consider posting the patch if there was going to be another release in a week and a half, but that usually isn't the case and a patch for an experimental module usually isn't reason enough to roll another release. Past history shows that it usually takes a serious vulnerability to warrant the turnaround we saw with 2.0.52. There have been a number of users reporting this segfault not only on the httpd email lists but on our own Novell news groups as well. We have been making a lot of progress towards stabilizing auth_ldap and util_ldap and as a result, I believe that the popularity of these modules has increased. I would really hate to put a damper on this forward progress just because we missed a segfault patch by one vote. Simply posting this patch seems like a quick and easy fix until the next release. Brad [EMAIL PROTECTED] Tuesday, September 28, 2004 4:28:25 PM At 04:59 PM 9/28/2004, Brad Nicholes wrote: Since this patch was the last of three fixes for util_ldap and didn't make it into 2.0.52 because of lack of votes and since it fixes a segfault in util_ldap, now that it has the required votes, I would suggest we backport the fix and post the patch in /dist/httpd/patches. Any objections? No objection to backporting. Why not simply keep moving towards another release starting in a week and a half? The project as a whole is making huge progress on many fronts - the concept of release early, release often comes to mind. We fix dozens of things per week, why would this merit special placement in patches? Seems like the sort of thing contrib was made for. And if you are asking if a special build of Netware + patch in binaries is appropriate, I would vote Nay. But if you want to push for a release the day this patch is committed, that's the right of every project member. Bill
Re: segfault patch for util_ldap (was:Re: cvs commit: httpd-2.0 STATUS)
[EMAIL PROTECTED] Tuesday, September 28, 2004 5:31:47 PM At 06:12 PM 9/28/2004, Brad Nicholes wrote: I wouldn't consider posting the patch if there was going to be another release in a week and a half, but that usually isn't the case and a patch for an experimental module usually isn't reason enough to roll another release. Past history shows that it usually takes a serious vulnerability to warrant the turnaround we saw with 2.0.52. No, it just takes someone motivated. I hated the thought of 2.0.51 sitting around so I did something about it :) It takes a little more than just motivation, it also takes a need and consensus. To all those using auth_ldap and util_ldap, this patch is very import. To the rest, they don't really care so another release within 3 weeks is just a pain. All I really want to do is release a patch to make life easier for those that care and want to move forward with ldap, not cause a headache for the majority that don't. I really doubt I am going to get 3 +1's in favor of rolling a release all for a patch to an experimental module. Quoting the download page: Official Patches When we have patches to a minor bug or two, or features which we haven't yet included in a new release, we will put them in the patches subdirectory so people can get access to it before we roll another complete release. All this is, is a patch to fix a bug which hasn't been included in a new release yet so people can get access to it, it doesn't warrant a new release. It's not that big of an issue. Brad
Re: new config organization for 2.1
Therefore I think there are certainly valid reasons to split up the conf file, and from a usability perspective, it may be a bit more confusing upon an initial install, but the benefits down the road were immense for me. Mind you, being in an organization where 12 people of varying degree of expertise have access to the conf file and can restart the web server in not common. Any downtime is not tolerated and has to be followed up with a post mortem. I am in total agreement in fact my guess would be that most organizations will eventually split up the httpd.conf file to fit whatever needs they have. But I would imagine that no two organizations split up the .conf file in the same way. So splitting it up and installing it in the way that the ASF likes it, just seems more confusing than helpful. But like Joshua said, If you can suggest a better compromise solution, I am very interested, I don't have a better suggestion yet so I will have to think about it some more. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: new config organization for 2.1
Maybe I am jumping in here out of turn, but let me ask the obvious question. Why would we want to split the standard base httpd.conf file up into multiple files? Doesn't this end up just confusing the average user? One thing that I always tell new users of Apache is that rather than trying to understand the entire alpabetical list of directives in the httpd docs, go read the comments in the standard httpd.conf file. This gives them a good idea of what the base set of directives are and how they are used in a working context. For newbies reading a single .conf file seems easier to understand than trying to trace through multiple .conf files just to figure out the big picture. For those that are Apache experts, they have already rewritten and rearchitected the the httpd.conf file to fit their needs so they don't care. I can understand splitting dead or rarely used directives out, but it seems much easier to read as a single file. Maybe just some additional formatting and comments to distinguish MPM directives from Language from Vhosts, etc. is needed. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: Apache 2.0.51 util_ldap
I'm still wondering if we shouldn't just stick with the local read/write lock on Windows and other single child MPMs (NetWare?) as this should allow better throughput in such cases and yet be safe, right? In fact, Actually on NetWare this is a non-issue. On NetWare everything is global (memory, locks, etc.), so there is no difference between a global mutex and a local one (other than previously we were using reader/writer locks rather than mutexes). I would like to use reader/writer locks rather than global mutexes simply for performance reasons, but I'm not sure how we would go about switching between global and local locks anyway. This would require #ifdef'ing the code for particular platforms or MPM's which isn't a good thing. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Sunday, September 19, 2004 3:43:20 PM Sorry for the chattiness of my solution process. I've tested and these fixes do apply with the global mutex changes *except* when one disables caches by sizing them all to 0, Apache will crash on the first authentication request when the global mutexes are used! This needs to be fixed! I've attached a unified diff containing the purge fix and the unassigned variable fix (which as Graham pointed out is already in the 2.1 branch). I'm still wondering if we shouldn't just stick with the local read/write lock on Windows and other single child MPMs (NetWare?) as this should allow better throughput in such cases and yet be safe, right? In fact, why do we use shared memory on these platforms for the cache? [If I'm just daft here, I apologize.] -- Jess Holle Jess Holle wrote: Here's a fixed LDAP purge routine which works great in my testing (with cache sizes of 8, 100, 1000, and 2150 and 2500 unique user logins repeated 3 times each). [No, I haven't produced a diff as I have pieces of util_ldap from various CVS levels at this point.] Essentially I added all the logic surrounding 'pp', which is the address of the previous node's 'next' field or of cache-nodes[i] in the case of the first node. [Cleary my C is getting rusty -- this took me a few attempts to get right...] This fixes the biggest LDAP module issue I'm aware of: hangs and crashes after one or more cache purges.
Re: cvs commit: httpd-2.0/modules/ldap util_ldap_cache_mgr.c
Even though it isn't a big deal, the point is that newcurl is not undefined. It was initialized to NULL when it was declared at the beginning of the function. This is a mismatch between HEAD and APACHE_2_0_BRANCH. util_ldap has been moved out of experimental in HEAD and now exists in modules/ldap. jorton is refering to the r1.7 revision of modules/ldap/util_ldap_cache_mgr.c rather than modules/experimental/util_ldap_cache_mgr.c. The backport should include the initialization of newcurl as was committed in modules/ldap/util_ldap_cache_mgr.c r1.7 rather than the else code submitted in the patch file so that the backport matches the current state of the code. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Monday, September 20, 2004 7:15:27 AM See my util_ldap.c patch. Whether or not this patch is absolutely necessary, leaving code paths that leave function return results undefined is never good! Also, see the bigger patch to util_ldap_cache_mgr.c that I passed along yesterday. I've attached both here for convenience. -- Jess Holle Joe Orton wrote: On Sun, Sep 19, 2004 at 11:00:25PM -, [EMAIL PROTECTED] wrote: --- util_ldap_cache_mgr.c 13 Sep 2004 11:11:32 - 1.8 +++ util_ldap_cache_mgr.c 19 Sep 2004 23:00:25 - 1.9 ... @@ -252,6 +254,8 @@ newcurl = util_ald_cache_insert(st-util_ldap_cache, curl); } +else + newcurl = NULL; return newcurl; } This is not necessary after the r1.7 fix last week, so there's no point in asking for r1.7 to be back-ported as well as this. Also it looks as if the _child_init hook in util_ldap.c will still segfault with a NULL _cache_lock?
Re: Time for 2.0.51 and 2.1.0
Same here. I need another vote for the util_ldap.c backport Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Thursday, August 26, 2004 11:21:22 AM Sander Striker wrote: Hi, I'm going to start a TR cycle for both 2.0 and 2.1 monday. Objections? Sander Got a few 2.0 backports from 2.1 I need to drum up support for but otherwise +1 Bill
Re: cvs commit: httpd-2.0/docs/manual/style/xsl common.xsl
Oops, my mistake. This wasn't suppose to be checked in. Reverting now.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Wednesday, August 25, 2004 2:15:25 PM
bnicholes2004/08/25 13:15:25
Modified:docs/manual/style build.properties lang-targets.xml
docs/manual/style/css manual-zip.css
docs/manual/style/lang de.xml en.xml fr.xml ja.xml ko.xml
ru.xml
docs/manual/style/xsl common.xsl
Log:
Update 8/25/04
Revision ChangesPath
1.3 +2 -1 httpd-2.0/docs/manual/style/build.properties
Index: build.properties
===
RCS file: /home/cvs/httpd-2.0/docs/manual/style/build.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.properties 1 Aug 2004 12:41:55 - 1.2
+++ build.properties 25 Aug 2004 20:15:24 - 1.3
@@ -1,7 +1,8 @@
# This file contains version specific properties
# No xml files yet
+noxml.ja=howto/auth.html.ja.euc-jp developer/modules.html.ja.euc-jp
noxml.fr=new_features_2_0.html.fr upgrading.html.fr
# (pending) httpd version
-httpd.version=2.1.0-dev
+httpd.version=2.0.51
1.4 +2 -15 httpd-2.0/docs/manual/style/lang-targets.xml
Index: lang-targets.xml
===
RCS file: /home/cvs/httpd-2.0/docs/manual/style/lang-targets.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- lang-targets.xml 29 Jul 2004 17:58:55 - 1.3
+++ lang-targets.xml 25 Aug 2004 20:15:24 - 1.4
@@ -21,8 +21,8 @@
!-- --
project name=lang-targets
-target description=- builds all HTML files and nroff man pages name=all
depends=de, en, es, fr, ja, ko, ru/
-target description=- builds all zip download packages name=zip-all
depends=zip-de, zip-en, zip-es, zip-fr, zip-ja, zip-ko, zip-ru/
+target description=- builds all HTML files and nroff man pages name=all
depends=de, en, es, ja, ko, ru/
+target description=- builds all zip download packages name=zip-all
depends=zip-de, zip-en, zip-es, zip-ja, zip-ko, zip-ru/
!-- German --
!-- --
@@ -76,18 +76,6 @@
chm.generic lang=es/
/target
-!-- French --
-!-- --
-property value=.xml.fr name=inputext.fr/
-property value=.html.fr name=outputext.fr/
-
-target description=- builds French HTML files name=fr
-html.generic lang=fr/
-/target
-target description=- builds the French zipped download package name=zip-fr
-zip.generic lang=fr/
-/target
-
!-- Japanese --
!-- --
property value=.xml.ja name=inputext.ja/
@@ -141,7 +129,6 @@
include name=**/*.xml.de/
include name=**/*.xml/
include name=**/*.xml.es/
-include name=**/*.xml.fr/
include name=**/*.xml.ja/
include name=**/*.xml.ko/
include name=**/*.xml.ru/
1.4 +0 -1 httpd-2.0/docs/manual/style/css/manual-zip.css
Index: manual-zip.css
===
RCS file: /home/cvs/httpd-2.0/docs/manual/style/css/manual-zip.css,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- manual-zip.css9 Feb 2004 20:22:53 - 1.3
+++ manual-zip.css25 Aug 2004 20:15:24 - 1.4
@@ -15,7 +15,6 @@
* limitations under the License.
*/
-
h1 {
margin: 0 0 0.5em 0;
}
1.20 +5 -7 httpd-2.0/docs/manual/style/lang/de.xml
Index: de.xml
===
RCS file: /home/cvs/httpd-2.0/docs/manual/style/lang/de.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- de.xml2 May 2004 22:53:22 - 1.19
+++ de.xml25 Aug 2004 20:15:24 - 1.20
@@ -1,6 +1,6 @@
?xml version=1.0 encoding=ISO-8859-1?
-!DOCTYPE language [ !ENTITY nbsp #160; ]
-!-- English Revision: 1.9 --
+!DOCTYPE messages [ !ENTITY nbsp #160; ]
+!-- English revision: 1.6.2.4 --
!--
Copyright 2002-2004 The Apache Software Foundation
@@ -84,8 +84,7 @@
in directivesynopsis headings will be replaced by the given string.
(see de.xml
Re: cvs commit: httpd-2.0/modules/aaa NWGNUauthnzldap mod_authnz_ldap.c NWGNUmakefile
If you have time to move it before I do, by all mean, go for it. I probably won't get around to it until this afternoon anyway. Thanks for taking care of the build scripts. I'm pretty sure that I can handle the util_ldap netware build files once it is moved :) Experimental/Mod_auth_ldap should probably be thrown into the attic so we can at least preserve the history. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, August 18, 2004 7:24:13 AM Brad Nicholes wrote: BTW, since I am not a Linux makefile guru, the new authnz_ldap module has not been added to the Linux build scripts. Can somebody make the appropriate changes to the makefiles? Done. Are you going to move util_ldap to the ldap directory, or should I do it? I am not a netware guru, so you would have to do the build scripts :) Can we cvs rm mod_auth_ldap from it's old location? Regards, Graham --
Re: cvs commit: httpd-2.0/modules/aaa NWGNUauthnzldap mod_authnz_ldap.c NWGNUmakefile
This is the first attempt to restructure mod_auth_ldap to fit the new authentication model. There are a couple of things to note that I would like some feedback on. 1. The ldap_authn provider and ldap_authz handler exist in the same module. The reason for this is because both handlers depend on the same set of directive values to provide the necessary information for establishing a connection to the ldap server. Rather than having to redefine the AuthLDAPUrl, AuthLDAPBindDN and AuthLDAPBindPassword for two different modules, it seemed to make more sense both from a module perspective and a user interface perspective, to allow them to share the directives. 2. As a result of #1, this leaves the ldap_authz hook registered whether it is ultimately being used or not. Therefore simply reimplementing the require types user and group within the ldap_authz handler would conflict with the same types in other authz modules if loaded and configured in the same directory at the same time. Therefore it seemed to make more since to implement ldap-user and ldap-group which more closely identifies what is happening during the authorization phase anyway. authnz_ldap is still capable of using valid-user, group or user if desired. 3. The directive AuthLDAPFrontPageHack has been removed. The reason for this hack was to allow authorization for frontpage to fallback on a groupfile rather than the LDAP directory. Now that authnz_ldap can be configured to authorize via a authz_groupfile rather than forced to use the directory, this directive didn't seem necessary anymore. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, August 17, 2004 5:33:08 PM bnicholes2004/08/17 16:33:07 Modified:modules/aaa NWGNUmakefile Added: modules/aaa NWGNUauthnzldap mod_authnz_ldap.c Log: Re-structure the auth_ldap module to fit the new authentication model. The authnz_ldap module provides an ldap authentication provider and an authorization handler. It implements the authorization require values ldap-user, ldap-dn and ldap-group. This restructure also moves auth_ldap out of the experimental directory. Revision ChangesPath 1.3 +2 -0 httpd-2.0/modules/aaa/NWGNUmakefile Index: NWGNUmakefile === RCS file: /home/cvs/httpd-2.0/modules/aaa/NWGNUmakefile,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- NWGNUmakefile 13 Sep 2002 21:34:27 - 1.2 +++ NWGNUmakefile 17 Aug 2004 23:33:07 - 1.3 @@ -158,9 +158,11 @@ $(OBJDIR)/authndbm.nlm \ $(OBJDIR)/authndef.nlm \ $(OBJDIR)/authnfil.nlm \ + $(OBJDIR)/authnzldap.nlm \ $(OBJDIR)/authzdbm.nlm \ $(OBJDIR)/authzdef.nlm \ $(OBJDIR)/authzgrp.nlm \ + $(OBJDIR)/authzusr.nlm \ $(OBJDIR)/authzusr.nlm \ $(EOLIST) 1.1 httpd-2.0/modules/aaa/NWGNUauthnzldap Index: NWGNUauthnzldap === # # Make sure all needed macro's are defined # # # Get the 'head' of the build environment if necessary. This includes default # targets and paths to tools # ifndef EnvironmentDefined include $(AP_WORK)\build\NWGNUhead.inc endif # # These directories will be at the beginning of the include list, followed by # INCDIRS # XINCDIRS += \ $(AP_WORK)/include \ $(NWOS) \ $(AP_WORK)/srclib/apr/include \ $(AP_WORK)/srclib/apr-util/include \ $(AP_WORK)/srclib/apr \ $(EOLIST) # # These flags will come after CFLAGS # XCFLAGS += \ $(EOLIST) # # These defines will come after DEFINES # XDEFINES += \ $(EOLIST) # # These flags will be added to the link.opt file # XLFLAGS += \ $(EOLIST) # # These values will be appended to the correct variables based on the value of # RELEASE # ifeq $(RELEASE) debug XINCDIRS += \ $(EOLIST) XCFLAGS += \ $(EOLIST) XDEFINES += \ $(EOLIST) XLFLAGS += \ $(EOLIST) endif ifeq $(RELEASE) noopt XINCDIRS += \ $(EOLIST) XCFLAGS += \ $(EOLIST) XDEFINES += \ $(EOLIST) XLFLAGS += \ $(EOLIST) endif ifeq $(RELEASE) release XINCDIRS += \ $(EOLIST) XCFLAGS
Re: cvs commit: httpd-2.0/modules/aaa NWGNUauthnzldap mod_authnz_ldap.c NWGNUmakefile
The util_ldap module also needs to be moved out of the experimental directory (mod_auth*_ldap depends on mod_ldap). This is my next task. Where should it be moved to? I was thinking of creating an ldap directory under modules and putting it there. Or does it make sense for one of the existing module directories to be the new home of util_ldap? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, August 17, 2004 5:41:12 PM [EMAIL PROTECTED] wrote: Re-structure the auth_ldap module to fit the new authentication model. The authnz_ldap module provides an ldap authentication provider and an authorization handler. It implements the authorization require values ldap-user, ldap-dn and ldap-group. Extremely cool. This restructure also moves auth_ldap out of the experimental directory. Viva to that and an eclaire for both of us! The util_ldap module also needs to be moved out of the experimental directory (mod_auth*_ldap depends on mod_ldap). Regards, Graham --
Re: cvs commit: httpd-2.0/modules/aaa NWGNUauthnzldap mod_authnz_ldap.c NWGNUmakefile
BTW, since I am not a Linux makefile guru, the new authnz_ldap module has not been added to the Linux build scripts. Can somebody make the appropriate changes to the makefiles? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, August 17, 2004 5:41:12 PM [EMAIL PROTECTED] wrote: Re-structure the auth_ldap module to fit the new authentication model. The authnz_ldap module provides an ldap authentication provider and an authorization handler. It implements the authorization require values ldap-user, ldap-dn and ldap-group. Extremely cool. This restructure also moves auth_ldap out of the experimental directory. Viva to that and an eclaire for both of us! The util_ldap module also needs to be moved out of the experimental directory (mod_auth*_ldap depends on mod_ldap). Regards, Graham --
Where is the AJP code...
The addition of the proxy_ajp module to the httpd project presents a build problem. The AJP module code exists in httpd/modules/proxy in the httpd project but the AJP lib code still sits in the jakarta-tomcat-connectors\ajp\ajplib\test in the jakarta project. Is the AJPLIB code going to be migrated to the httpd project? Why is the AJPLIB code in a test directory? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: New Mod_Proxy - some testing/looking
From what I can see, there seems to be a parameter mismatch for the scheme_handler hook. For example, the scheme_handler ap_proxy_connect_handler() is defined as: int ap_proxy_connect_handler(request_rec *r, proxy_server_conf *conf, char *url, const char *proxyname, apr_port_t proxyport) but the scheme_handler hook is defined as: APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, scheme_handler, (request_rec *r, proxy_worker *worker, proxy_server_conf *conf, char *url, const char *proxyhost, apr_port_t proxyport)) notice the difference in the parameter lists. The declaration has 6 parameters and the actual handler only has 5. The handler is missing proxy_worker * as the second parameter. How does this compile or even work on any platform? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Friday, August 13, 2004 1:37:16 PM At 04:58 AM 8/13/2004, NormW wrote: Good evening Bill, All... Please direct these comments to [EMAIL PROTECTED] - b.t.w., you can check out the latest httpd-2.0 HEAD and pick up the entire proxy solution (you must explicitly --enable-proxy-ajp and have the ajplib sources there too.) Someone want to take a wack at NormW's observations? Bill, thanks for the interest... I can say that the 'problem' noted in proxy_ftp.c has been attended with a recent update from Mladen. A build on the current 2.1 CVS shows (for NetWare): - mod_proxy.c having trouble finding mod_status.h (in ../modules/generators), - the same problem mentioned previously with proxy_connect.c, (Errors at 375 see 26, 80) Bypassing these I now get: Calling NWGNUproxyftp Generating Release\proxyftp_cc.opt Compiling proxy_ftp.c Compiling proxy_util.c Compiling ../arch/netware/libprews.c Generating Release\proxyftp_link.opt Linking Release/proxyftp.nlm ### mwldnlm Linker Error: # Undefined symbol: 'ap_proxy_ssl_enable' # referenced from 'ap_proxy_connection_create' in proxy_util.o ### mwldnlm Linker Error: # Undefined symbol: 'ap_proxy_ssl_disable' # referenced from 'ap_proxy_connection_create' in proxy_util.o As noted above, this is on a NetWare build... It's expected because the netware gurus haven't had a chance to catch up. Please quit using tomcat-dev already - final warning; ignoring future posts to there in order to enforce posting future proxy patches/comments to [EMAIL PROTECTED] ;-) I suspect Netware didn't grok that those symbols were local/global as required? Bill
Re: httpd-2.2 release roadmap v0.1
I would hope that 2.0 is EOLed as soon as possible after 2.2 ships. Being basically the NetWare platform maintainer of two versions of Apache (1.3, 2.0) with a development version on top of that, has been bad enough. Three would be a nightmare and when would it stop? Even for all but the most serious security fixes, the story would be upgrade to 2.2.x because that is where the fix is. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Thursday, August 12, 2004 2:53:05 PM At 03:15 PM 8/12/2004, Jim Jagielski wrote: Geoffrey Young wrote: so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0? that is, if everyday hacking is against 2.3 and we propose a new feature to backport, do we backport to both 2.2 and 2.0? or does it mean that 2.0 has reached end-of-life and we backport only to 2.2? just so I (and others) know what to expect... :) I would foresee only 1.3 and 2.2 being around and 2.0 being EOLed. I expect the same, although providing the occasional 2.0 release for security bug fixes. Bill
Re: cvs commit: httpd-2.0 STATUS
Do we care about backporting the overhaul into the 2.0 tree? I don't see that it really buys us anything unless you think that it is necessary in order to get auth_ldap out of experimental. After I get the latest util-ldap fixes backported, that should get mod_auth_ldap working in 2.0. Once it actually works, I think we can then propose that it is moved out of experimental. The next thing that needs to be done would be to rework mod_auth_ldap so that it complies with the rest of the 2.1 auth module structure.The util-ldap overhaul could be considered part of that work and only be available in 2.1. Thoughts? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, August 03, 2004 7:09:01 PM minfrin 2004/08/03 18:09:01 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Propose a backport. Revision ChangesPath No revision No revision 1.751.2.965 +7 -1 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.964 retrieving revision 1.751.2.965 diff -u -r1.751.2.964 -r1.751.2.965 --- STATUS3 Aug 2004 19:07:03 - 1.751.2.964 +++ STATUS4 Aug 2004 01:09:00 - 1.751.2.965 @@ -73,6 +73,12 @@ [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] +*) Remove LDAP toolkit specific code from util_ldap and mod_auth_ldap. + modules/experimental/mod_auth_ldap.c: 1.28 + modules/experimental/util_ldap.c: 1.36 + +1: minfrin (this requires the apr-util LDAP overhaul to be ported to +apr-util v0.9 first) + *) Add load balancer support to the scoreboard in preparation for load balancing support in mod_proxy. include/scoreboard.h: 1.52
Re: FW: Bug in AuthLDAPURL?
This does work according to what the documentation says but you must surround the LDAP URL with double quote as Graham suggested AuthLDAPURL ldap://ldap1.airius.com ldap2.airius.com/ou=People,o=Airius Otherwise Apache will interpret the space between the host names to be two different parameters. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Friday, July 16, 2004 11:15:32 AM [Forwarding on behalf of Tair-Shian Chou who has problems getting his mail through to [EMAIL PROTECTED] list] -Madhu -Original Message- From: Tair-Shian Chou [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 3:10 PM To: '[EMAIL PROTECTED]' Subject: FW: Bug in AuthLDAPURL? Hi Graham, I did try that and it did not work. Thanks, Chou -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 14, 2004 4:51 PM To: [EMAIL PROTECTED] Subject: Re: Bug in AuthLDAPURL? CHOU,TAIR-SHIAN (HP-Cupertino,ex1) wrote: AuthLDAPURL ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius require valid-user When I try the above AuthLDAPURL example given in Apache Module mod_auth_ldap document with 2.0.50, I get the following error: Syntax error on line 19 of /opt/hpws/apache/conf/ldap.conf: AuthLDAPURL takes one argument, URL to define LDAP connection. Can you try surrounding the ldap url with quotes and see if it fixes this? (If so, the docs are wrong). Regards, Graham --
Re: cvs commit: httpd-2.0/docs/manual/platform netware.xml
Basically because the same semantics don't fit for mod_nw_ssl. mod_nw_ssl is a much simpler module than mod_ssl. It really only has one significant directive which is SecureListen port certname. All the NWSSLUpgradeable directive is doing is associating a certificate name with an existing listen addr:port so that if the request to upgrade is made, Winsock has the information it needs to upgrade the socket. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, July 14, 2004 11:17:06 AM Brad, is this the same functionality as 'SSLEngine upgrade' for the _nw_ module? If so, why not reuse the same semantic? SSLEngine on negotation crypt - dismiss non-crypt requests SSLEngine upgradebegin uncrypted - allow upgrade SSLEngine off begin, and stay, uncrypted Bill At 11:29 AM 7/14/2004, [EMAIL PROTECTED] wrote: bnicholes2004/07/14 09:29:56 Modified:docs/manual/mod Tag: APACHE_2_0_BRANCH mod_nw_ssl.xml docs/manual/platform Tag: APACHE_2_0_BRANCH netware.xml Log: Add the new directive NWSSLUpgradeable to mod_nw_ssl to allow a non-secure connection to be upgraded to secure connections Revision ChangesPath No revision No revision 1.1.2.7 +16 -1 httpd-2.0/docs/manual/mod/mod_nw_ssl.xml Index: mod_nw_ssl.xml === RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_nw_ssl.xml,v retrieving revision 1.1.2.6 retrieving revision 1.1.2.7 diff -u -r1.1.2.6 -r1.1.2.7 --- mod_nw_ssl.xml17 Apr 2004 18:43:37 - 1.1.2.6 +++ mod_nw_ssl.xml14 Jul 2004 16:29:56 - 1.1.2.7 @@ -62,4 +62,19 @@ /usage /directivesynopsis +directivesynopsis +nameNWSSLUpgradeable/name +descriptionAllows a connection to be upgraded to an SSL connection upon request/description +syntaxNWSSLUpgradeable [varIP-address/var:]varportnumber/var/syntax +contextlistcontextserver config/context/contextlist + +usage +pAllow a connection that was created on the specified address +and/or port to be upgraded to an SSL connection upon request from +the client. The address and/or port must have already be defined +previously with a directive module=mpm_commonListen/directive +directive./p +/usage +/directivesynopsis + /modulesynopsis No revision No revision 1.3.2.8 +5 -1 httpd-2.0/docs/manual/platform/netware.xml Index: netware.xml === RCS file: /home/cvs/httpd-2.0/docs/manual/platform/netware.xml,v retrieving revision 1.3.2.7 retrieving revision 1.3.2.8 diff -u -r1.3.2.7 -r1.3.2.8 --- netware.xml 17 Apr 2004 19:10:48 - 1.3.2.7 +++ netware.xml 14 Jul 2004 16:29:56 - 1.3.2.8 @@ -413,6 +413,10 @@ lidirective module=mod_nw_sslNWSSLTrustedCerts/directive - Adds trusted certificates that are used to create secure connections to proxied servers./li /ul + ul +lidirective module=mod_nw_sslNWSSLUpgradeable/directive - +Allow a connection created on the specified address/port to be upgraded to an SSL connection./li + /ul /section
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c
Modules (right now, only mod_auth_ldap) depend on util_ldap, and changing the header would mean a break in binary compatibility (in theory). I think we should probably stick with an MMN bump for this to be consistent, even though only the mod_auth_ldap module uses it (to my knowledge). I was hoping to avoid the MMN bump mainly because that means we can't backport the changes to the 2.0 branch. If the httpd 2.2 includes a caching_util module then the only reason for these stabilization patches is the 2.0 branch. Also, if there are any other modules that do depend on util_ldap, wouldn't they be just as broken as mod_auth_ldap was and probably want to update anyway? I don't know, I was hoping to get some other feedback from the list. As for the header being in /include, I think it should be there so that external modules can be built against util_ldap. If the header was in /experiemental, the full httpd source would be needed to build an Apache module that used util_ldap (unless I am misunderstanding something). True. It just seems a little strange. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c
Agreed, and interested in other thoughts as well. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Graham Leggett [EMAIL PROTECTED] Monday, June 28, 2004 11:23:57 AM Brad Nicholes wrote: I was hoping to avoid the MMN bump mainly because that means we can't backport the changes to the 2.0 branch. If the httpd 2.2 includes a caching_util module then the only reason for these stabilization patches is the 2.0 branch. Also, if there are any other modules that do depend on util_ldap, wouldn't they be just as broken as mod_auth_ldap was and probably want to update anyway? I don't know, I was hoping to get some other feedback from the list. Well... the question is are there modules out there that use util_ldap right now? I think being experimental, the module is subject to incompatible change anyway, and there seems to be a catch 22 situation here - the module is currently broken, but the fix cannot be applied without an MMN bump (if it was a fully fledged module). I think to break this catch 22 situation, it seems reasonable to apply the changes to v2.0 without an MMN bump as the code is experimental. Any other thoughts? Regards, Graham --
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c util_ldap_cache.c util_ldap_cache.h
No, I didn't change anything that would allow for anonymous shared
memory. This should probably check for a NULL before calling
apr_file_remove().
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Saturday, June 26, 2004 9:30:42 AM
[EMAIL PROTECTED] wrote:
+#if APR_HAS_SHARED_MEMORY
+/* If the cache file already exists then delete it.
Otherwise we are
+ * going to run into problems creating the shared memory.
*/
+apr_file_remove(st-cache_file, ptemp);
+if (st-cache_file) {
+char *lck_file = apr_pstrcat (st-pool,
st-cache_file, .lck, NULL);
+apr_file_remove(lck_file, ptemp);
+}
+#endif
Does this patch support the idea of the cache file being NULL (ie
anonymous shared memory?).
The previous code insisted on specifying a cache file, which didn't
work
properly under Linux. Now, not specifying a cache filename means use
anonymous shared memory, I'd just like to check that this NULL
filename
is case is still handled properly.
Regards,
Graham
--
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c util_ldap_cache.c util_ldap_cache.h
ptemp shouldn't ever be NULL on a post_config, right? I just fixed the code so that it checks for a NULL file name before calling apr_file_remove(). Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Saturday, June 26, 2004 10:01:07 AM Brad Nicholes wrote: No, I didn't change anything that would allow for anonymous shared memory. This should probably check for a NULL before calling apr_file_remove(). +apr_file_remove(st-cache_file, ptemp); Will this line segfault if ptempt is NULL? If not, then it should be fine. If so, we should probably test for NULLness first (as you recommend above). Regards, Graham --
NetWare and protected address space (was: Re: cvs commit: httpd-2.0 STATUS)
Just to provide a little background on NetWare (and if you don't care, don't read any further). NetWare is not your standard general purpose operating system. NetWare was origninally designed and built to be a high performance, highly scalable and very secure file and print server. Over the years it has evolved into something that sits somewhere between its original design purpose and a general purpose OS. In order to achieve the performance levels that it does, as much overhead as possible was eliminated which includes the concept of processes and what most people understand to be address spaces. Everything that runs on NetWare runs as a thread in Kernel address space. The idea of a separate address space or Protected Address Space (as it is called around here) didn't show up in NetWare until NetWare 5 (I think that was the first version). Basically a protected address space is just that. NetWare allocates a separate address space in which it is able to run an application. In order for an application to run in this address space, everything that it depends on has to be loaded in that address space. This mean code as well as data. A protected address space on NetWare could probably be thought of more as a virtual machine than a process. This is why it is so expensive to spin up a CGI in a separate address space on Netware. But running everything in kernel address space is not as scary as it sounds on NetWare. If you have a wild module that causes the Apache instance to abend (another old time term that is still widely used when refering to NetWare), it will bring Apache down, but the OS is smart enough to isolate the offending application and still allow the server to continue running. The downside is that the only way to clear an abend in kernel address space is to restart the server. While an abend in a protected address space can simply be unloaded and cleared. Some NetWare administrators will choose to run applications like Apache in a protected address space simply for the ability to easily clean it up if something goes wrong. But by doing so they sacrifice some level of performance of the web server as well as system resources. Others may consider applications like Apache to be so stable and the performance hit so great, that they are comfortable in running them in kernel address space. For the most part, this is the case. But Apache is a long lived application. Once it is spun up and running, the overhead is gone. CGIs, as we all know, can come and go at anytime. Because of the same performance reason, other platforms have been able to increase performance by using mod_cgid rather than mod_cgi to avoid the same type of process creation overhead. But on NetWare, not only is starting up a CGI in protected address space much more expensive than forking a process on other platforms, we don't have fork/exec on NetWare. The bottom line is that because of the nature of the NetWare OS, it is much more efficient and much easier to run things in kernel address space. It is just the nature of the OS. What's the benefit? Performance, scalability and yes, security. (OK, that sounds a lot like a marketing line, but its true) Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, June 22, 2004 8:34:54 PM Uh, then may I follow up with another stupid, obvious question, if using another address space insulates the parent application and, in some cases, the server from a crash resulting from an unstable module, why do they all use the same address space on novell? Does this compromise a security measure in the case of a module fail or crash? -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Tue, 2004-06-22 at 16:49, Jean-Jacques Clar wrote: Can I ask the obvious, then? When would a separate address space be desirable for an apr-based app to invoke a child/forked process? It is a desirable option mainly for developers using unstable modules to ensure the child process will not kill the parent application, or the server, in case a major problem happens inside the child. By default on NetWare, the http server and all of its child processes are started in the same address space.
Re: cvs commit: httpd-2.0 STATUS
What if the default in APR is to run in a separate address space*, and in places in Apache where on NetWare the child process should run in the same address space there is a call to the proper procattr manipulator to override the default so that the child runs in the same address space? (and ignore any APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef NETWARE is needed around the call) The is actually the behavior that we don't want on NetWare. Running CGI's or utilities like RotateLogs in a separate address space is very painful and requires overhead and a performance hit that we don't want. On NetWare we need to default to the current address space. BTW, an address space on NetWare is, for the most part, very different than on other platforms. 90% of what is running on the box, is running in the same address space. When we implemented the CGIMapExtension directive to associate a CGI extension with an executible (NetWare doesn't have a shell like BASH to handle the associations) there is an optional parameter called detach which allows the user to specify wheither the associated executible should be run in the current address space or a separate address space. The default is the current address space. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, June 22, 2004 5:45:58 AM [EMAIL PROTECTED] wrote: clar2004/06/21 12:11:56 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Removing bb proposal since it will require a major number bump Revision ChangesPath No revision No revision 1.751.2.932 +1 -12 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.931 retrieving revision 1.751.2.932 diff -u -r1.751.2.931 -r1.751.2.932 --- STATUS 20 Jun 2004 13:12:26 - 1.751.2.931 +++ STATUS 21 Jun 2004 19:11:56 - 1.751.2.932 @@ -77,17 +77,6 @@ hooks just like DSO modules can [Philippe M. Chiasson gozer cpan.org] +1: geoff -*) mod_cgi: Added API call and new field in apr_procattr_t and cgi_exec_info_t - structures to support loading in current or new address space for CGIs. - It fixes NetWare that is currently broken after changes done to log.c r1.145. - modules/generators/mod_cgi.c r1.164 - modules/generators/mod_cgi.h r1.14 - modules/arch/netware/mod_netware r1.18 - +1: jjclar, bnicholes - -0: nd - trawick: is minor mmn bump needed to reflect that API structure was extended? - nd: same as mod_ssl.h issues. It's actually a major bump. Jeff eventually needs to backport the use of a different cmdtype for piped loggers in order to fix an outstanding PR and NetWare still needs to create piped logger processes as expected and recover from a historical lack of information provided to APR about whether or not the child process should run within the same address space of the parent. Surely there is some way to make this happen? What if the default in APR is to run in a separate address space*, and in places in Apache where on NetWare the child process should run in the same address space there is a call to the proper procattr manipulator to override the default so that the child runs in the same address space? (and ignore any APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef NETWARE is needed around the call) This at least avoids adding a field to the end of the cgi structure allocated by Apache and passed to modules implementing the optional function, which (at the moment) a minority of people think requires a major bump. *sounds natural to me; that also means that the default is the same on all platforms -- run child in different address space
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c
Do the docs need to be updated for this change? Allowing relative paths to be resolved against ServerRoot seemed like fairly standard procedure. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, June 15, 2004 3:42:25 AM [EMAIL PROTECTED] wrote: bnicholes2004/06/11 09:15:43 Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS modules/experimental Tag: APACHE_2_0_BRANCH util_ldap.c Log: Allow relative paths for LDAPTrustedCA to be resolved against ServerRoot PR#26602 Have the docs been updated to reflect this? Just to confirm - are docs changes subject to RTC? Regards, Graham --
Re: huge memory leak in 2.0.x
Actually I think this was addressed quite a while ago with the introduction of the MaxMemFree directive. This problem sounds a lot like the bucket issue where memory allocated for the bucket brigade that pushes the data through from the CGI app to the wire, simply held on to the memory assuming that it would be needed later. The MaxMemFree directive allowed the memory pool manager to release excess memory rather than allowing it to hang around. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Monday, June 14, 2004 11:55:29 AM Hi, [I'm writing to the dev list because it seems that not enough apache developers have noticed or taken interest into the original PR's on this bug] This is a real and easy to reproduce bug that has been agonizing me for a quite a while. It's been reported since at least October '03. 1.3.x does not show this behaviour. Please see the original report at http://issues.apache.org/bugzilla/show_bug.cgi?id=23567 and my report at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29528 I've tried looking into the problem, but unfortunatly, I have no knowledge/background of the apache source. I'll test any patches. Cheers, -m
Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
After speaking many times about this problem on #apache-modules, Paul Querna said that it would be better to port mod_auth_ldap to mod_authn_ldap, and do module caching auth, for all authentication method. I am sure this way is really better and i agree with him. I know he started this cache module, maybe it could be good to continue this effort and on another hand, port mod_auth_ldap to 2.1. I agree that a generic caching module would be of benefit here even before we port mod_auth_ldap to the 2.1 auth structure. Either way, I also think there is a lot of work to do on the caching code. I am sure that we can take advantage of what has been done in mod_ssl and other places that have to mutex protect shared memory. It is actually working great on NetWare at the moment but then we don't use shared memory and we are multi-threaded only. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Friday, June 11, 2004 4:04:22 PM mod_ssl mutex are totally different. global mutex are used. Actually, the mutex is in the module_conf, so i think when apache fork childs, this mutex is no more valid, and each child will have a value for it. There is also in util_ldap.c, apr_thread_mutex_create(st-mutex, APR_THREAD_MUTEX_DEFAULT, st-pool); This will alloc data for the mutex with apr_pcalloc, and i think it will be only in the current child. I think there is a lot of work to make it work with global mutex. After speaking many times about this problem on #apache-modules, Paul Querna said that it would be better to port mod_auth_ldap to mod_authn_ldap, and do module caching auth, for all authentication method. I am sure this way is really better and i agree with him. I know he started this cache module, maybe it could be good to continue this effort and on another hand, port mod_auth_ldap to 2.1. Regards, Matthieu
Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
I agree that the LDAP code needs to do more error checking and between the work that you did, along with the holes that I plugged previously and the shared memory fixes that Mathieu Estrade did, I think the code is much more robust than it has ever been. Many of our NetWare customers use auth_ldap as the primary means of authentication because it is the easiest way to authenticate against eDirectory. Outside of the shared memory problems, since NetWare doesn't use it, we have run into the same issues that you have seen. But since these latest patches that have gone into 2.0.50-dev, those problems have gone away. At least on NetWare, switching to pools would make the code much more complex. Rather than simply calling calloc and free in the same way that we are calling apr_rmm_calloc() and apr_rmm_free(), we would have to implement essentially the same model using pools and reslists. It seems to me like using a sledge hammer to drive a finishing nail in this instance. Also in the end, it all boils down to malloc and free anyway. As far as debugging goes, I can understand why it might be easier using the pool debug code, but we have never been successful in making the pool debug code work on NetWare. Granted we probably haven't tried real hard mainly because NetWare already has some good memory debugging capabilities built into the OS. If debugging is a problem, I think it might be easier to implement some memory debugging code specifically for the LDAP_cache rather than trying to retrofit it with pools and reslists. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Thursday, June 10, 2004 4:59:30 AM Brad Nicholes wrote: I guess that is a possibility but I still don't understand what the problem is with using calloc() and free() for the ldap caching code. This seems to be a common thing to do when global memory needs to be allocated and deallocated constantly. To avoid having the memory grow uncontrolably, you have to be able to control it at a much finer level than apr_pool allows you. What I've found in the LDAP code is that it isn't very defensive, most of the code simply assumes the rest of the code worked - it has resulted in me finding all sorts of side problems in the code, but not the real problem - the false negatives the code reports after it has been idle for a long time. Changing malloc and free into something more bulletproof (or at least more robust), like pools and/or the reslist stuff would make the code more resilient, and for me, easier to debug :) Regards, Graham --
Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
I have considered using a pool per entry in other caching code that I have written just so that I could have much finer control over allocating and freeing the memory. But in the end what it really comes down to is malloc and free and if that is what you really want, then why not just use malloc and free. Pools just add a layer of memory management between your application and the actual allocation that may be of no use. You have simply replaced malloc() with apr_pool_create() and free() with apr_pool_destroy(). If you forget to call apr_pool_destroy(), you have a memory leak in the same way as you would if you forget to call free(). When the application shuts down, the pool management will clean up the memory but then so will the process management of the OS. Outside of some debugging help during development, converting to pools and reslists is just adding a lot of unneeded overhead. The advantage to using memory pools is in situations where you need a pool of memory that can created, pieced out during a specific operation and then completely cleared once the operation is complete and reused without having to recreate it. Global caches just don't lend themselves to this model. The pieces can come can go, but you can never really clear the whole thing out and reuse it because the operation never actually ends. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Graham Leggett [EMAIL PROTECTED] Thursday, June 10, 2004 9:46:16 AM Brad Nicholes wrote: At least on NetWare, switching to pools would make the code much more complex. Rather than simply calling calloc and free in the same way that we are calling apr_rmm_calloc() and apr_rmm_free(), we would have to implement essentially the same model using pools and reslists. It seems to me like using a sledge hammer to drive a finishing nail in this instance. Also in the end, it all boils down to malloc and free anyway. As far as debugging goes, I can understand why it might be easier using the pool debug code, but we have never been successful in making the pool debug code work on NetWare. Granted we probably haven't tried real hard mainly because NetWare already has some good memory debugging capabilities built into the OS. If debugging is a problem, I think it might be easier to implement some memory debugging code specifically for the LDAP_cache rather than trying to retrofit it with pools and reslists. The theory is that the pools code is already hopefully been pre-debugged, you can allocate memory from a pool, and be reasonably sure that the problems of freeing the memory is handled for you. (If this is not the case, it won't be an LDAP bug, but an Apache wide bug). The only real issue really is worrying about the scope of the pool. Thinking further about this, we could use one pool per cache entry. To delete that cache entry just means to destroy the pool. No more need to walk the cache entry and delete each buffer one by one, and no room to make mistakes. No more chance that somebody adds a field to the cache entry, and then forgets the code to free the cache entry. Creation of the pool would only be done on creation of the cache entry, which in turn is done only on the first time this user is authenticated, all further requests being cached, so it doesn't seem to be expensive either, unless someone with a better understanding of the internals of pools would be able to say whether this idea is good or bad. Regards, Graham --
Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
It appears to me that if it doesn't handle low memory situations or
it is giving false positives, those are separate issues from pools vs.
calloc/free. I still think we need to implement some better monitoring
or logging code in the cache_mgr and enhance the cache-status pages so
that we can track things like false positives. Maybe tracking the
entries by user name and authentication state rather than just the
number entries and how often the cache was hit.
Maybe the real problem is with the locking. In fact just taking a
quick scan through the code again, I am seeing something that bothers me
in util_ldap_cache_comparedn()
if (curl) {
/* compare successful - add to the compare cache */
LDAP_CACHE_RDLOCK();
newnode.reqdn = (char *)reqdn;
newnode.dn = (char *)dn;
util_ald_cache_insert(curl-dn_compare_cache, newnode);
LDAP_CACHE_UNLOCK();
}
It appears to be acquiring a read lock but then inserts a new node into
the cache. Shouldn't it be acquiring a write lock before doing an
insert?
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
Graham Leggett [EMAIL PROTECTED] Thursday, June 10, 2004 4:24:54
PM
Brad Nicholes wrote:
Do we even know that there is a problem with this code? I haven't
seen
any memory leaks so far. I would hate to go to all of the work to
redesign and rewrite the ldap_cache manager for little to no gain.
It does not seem to handle the we ran out of memory while trying to
add
to the cache case very gracefully. It doesn't crash any more, but I'm
experiencing false negatives still, which is the problem I was trying
to
fix when I started trying to fix the code.
Regards,
Graham
--
Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
In fact, I don't think that these are shared locks at all
#define LDAP_CACHE_LOCK_CREATE(p) \
if (!st-util_ldap_cache_lock)
apr_thread_rwlock_create(st-util_ldap_cache_lock, st-pool)
which means that in the shared memory cache, it is highly likely that
multiple processes could be altering the cache at the same time. True?
Since NetWare is multi-threaded only, we never see this problem.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Thursday, June 10, 2004 5:07:52 PM
It appears to me that if it doesn't handle low memory situations or
it is giving false positives, those are separate issues from pools vs.
calloc/free. I still think we need to implement some better
monitoring
or logging code in the cache_mgr and enhance the cache-status pages so
that we can track things like false positives. Maybe tracking the
entries by user name and authentication state rather than just the
number entries and how often the cache was hit.
Maybe the real problem is with the locking. In fact just taking a
quick scan through the code again, I am seeing something that bothers
me
in util_ldap_cache_comparedn()
if (curl) {
/* compare successful - add to the compare cache */
LDAP_CACHE_RDLOCK();
newnode.reqdn = (char *)reqdn;
newnode.dn = (char *)dn;
util_ald_cache_insert(curl-dn_compare_cache, newnode);
LDAP_CACHE_UNLOCK();
}
It appears to be acquiring a read lock but then inserts a new node
into
the cache. Shouldn't it be acquiring a write lock before doing an
insert?
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
Graham Leggett [EMAIL PROTECTED] Thursday, June 10, 2004 4:24:54
PM
Brad Nicholes wrote:
Do we even know that there is a problem with this code? I haven't
seen
any memory leaks so far. I would hate to go to all of the work to
redesign and rewrite the ldap_cache manager for little to no gain.
It does not seem to handle the we ran out of memory while trying to
add
to the cache case very gracefully. It doesn't crash any more, but I'm
experiencing false negatives still, which is the problem I was trying
to
fix when I started trying to fix the code.
Regards,
Graham
--
Re:util_ldap [Bug 29217] - Remove references to calloc() and free()
But if you are allocating memory for cache entries that are constantly expiring and being purged, the pool will continue to grow until the server is restarted. The pool would end up with stale memory that the system has no way of reclaiming outside of restarting the server. NetWare doesn't have the concept of a child config pool since there are no child processes and therefore no need to use shared memory. Simply restarting a child process is not an option. On NetWare it is all or nothing. Apache is either up and running or not. If you tried to shutdown the process to reclaim memory, you lose the web server. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, June 09, 2004 4:43:22 PM DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29217. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29217 Remove references to calloc() and free() --- Additional Comments From [EMAIL PROTECTED] 2004-06-09 22:43 --- The idea is to use apr_rmm_calloc() for the shared memory case, and memory from the child config pool in the non shared memory case. When the server is restarted, the pool is cleaned up and the cache started from scratch. The purpose of this proposal is the fix the memory leak you mentioned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
