apreq - apr-util
While doing some work on mod_sparql I found that some of the functionality i had assumed we already had in apr-util was actually available in apreq. Further examination revealed various parts of the library code that I feel really belong in apr-util. I talked briefly with joes and he seemed to be OK with us looking at what parts would be a good fit for apr-util. He indicated that the project was looking to try and alter their code in various ways and so having more of their generic lib code available directly in apr-util may be a win for them as well. I'm not giving specifics yet as I'd like to know if people think we should do it, and then what pieces we should look at moving. The overhead of moving will be minimal and the changes required look to be also minimal. -- david http://feathercast.org/
Re: apreq - apr-util
david reid wrote: While doing some work on mod_sparql I found that some of the functionality i had assumed we already had in apr-util was actually available in apreq. Further examination revealed various parts of the library code that I feel really belong in apr-util. I talked briefly with joes and he seemed to be OK with us looking at what parts would be a good fit for apr-util. He indicated that the project was looking to try and alter their code in various ways and so having more of their generic lib code available directly in apr-util may be a win for them as well. I'm not giving specifics yet as I'd like to know if people think we should do it, and then what pieces we should look at moving. The overhead of moving will be minimal and the changes required look to be also minimal. As a casual list reader who uses/distributes libapreq with his own project: http://biostat.mc.vanderbilt.edu/RApacheProject I welcome any collaboration that could further the idea of distributing libapreq with apache httpd (just as apr and apr-util are distributed with httpd) or even melding libapreq into apr-util. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
Re: docs are still half-missing
Jonathan Vanasco wrote: just a heads up: This was fixed in SVN and will be fixed on the website with 2.08. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night.
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
On 07/28/2006 03:26 AM, Sander Temme wrote: All of these hang on the t/protocol/nntp-like.t. I'll try and put a patch into that test that skips if we're on FreeBSD and accf_http.ko or accf_data.ko are loaded. I am neither an expert on FreeBSD nor on accept filters, but wouldn't it be better / be possible to adjust the test configuration with AcceptFilter nttp none instead of skipping the test on FreeBSD? Regards Rüdiger
Re: httpd-proxy-scoreboard
On 07/27/2006 02:37 PM, Jean-frederic Clere wrote: Ruediger Pluem wrote: You want to check all the connections of the pool corresponding to the worker but not all the workers. Not all at the same time, but only the one I actually leased. If it is not that does not mean necessarily that the server in the backend failed. That probably means the socket has been closed ;-) Yes, provided the backend is not faulty this will the most common case then. It could be just this connection. So the default response on a faulty connection would be to close this one and try with a new one. With TC that means you create a new thread in TC, we must not overload the back-end server. That should not be a problem in most cases. If e.g. TC has closed the socket from its side then the thread holding the connection is free again. And if httpd closes the connection successfully the thread also should be become available again. Regards Rüdiger
Re: svn commit: r425677 - /httpd/httpd/branches/2.2.x/STATUS
On Thursday 27 July 2006 18:36, Sander Temme wrote: Have you reviewed the patch? This is a small modification that takes unsupported code out of the compile path when building with -DDEBUG. I'm not happy with applying *any* local patch to a third-party package. With PCRE we have a quite a track record of trouble, as witness for example the length of the Cc; list (and the comments!) at http://issues.apache.org/bugzilla/show_bug.cgi?id=27550 I have this in all my working copies. It does not break the PCRE interface. In the following message to [EMAIL PROTECTED], PCRE author Philip Hazel all but admits forgetting to ifdef these calls out in this file (which gets #included from pcre.c only if DEBUG is #defined): http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/% [EMAIL PROTECTED] It seems to me he (tentatively?) agrees there's a problem. That's not the same as accepting your patch: it just means ensuring the underlying problem gets fixed. This just makes it easier for folks to build debug builds and help us out: People building for debug are presumably starting from source. Where's the problem with configure --with-pcre? for them? The real solution of course, is to upgrade to the current release of PCRE, version 6.7. However, we should probably not do that on the stable branches. At the risk of being a bore, the real solution is to unbundle pcre! Less confusing for people who compile from source, and perfectly within the capabilities of any package management system worth its salt. Please reconsider your bale. I'm in two minds about that. There is the workaround of configure --with-pcre but where does that leave packages? PR#27550 names two modules that needed to work around the bundled PCRE: mod_php and mod_caml. That implies two workarounds for the same problem. What if the PHP and CAML folks (or AN Other with the same problem) were to adopt mutually incompatible solutions? AFAICT the only mitigating circumstance is that this patch is not the underlying problem, so I'm complaining at a symptom rather than the cause. But it feels like when in a hole, dig deeper. -- Nick Kew
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
+1 on all, tested on OS X 10.4.7... Will try on Sol8 and SUSE later on today... On Jul 27, 2006, at 2:37 PM, William A. Rowe, Jr. wrote: Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bill
Re: httpd-proxy-scoreboard
On Jul 26, 2006, at 12:11 PM, Jean-frederic Clere wrote: Hi, I have started to write a generic health-checker for mod_proxy. I would like to change the macro PROXY_WORKER_IS_USABLE() to a routine in proxy_util.c. Why? We're simply checking bits... I can't see bothering with the overhead of a function call.
Re: proxy balancer backports for 2.2.3
yeah, it's a bit of an overhead, but it allows for one-to-one mapping of SVN commits to each new feature. And it makes it easier for people to follow what each smallish patch does (and therefore +1 it) rather than wrapping their heads around something larger. On Jul 26, 2006, at 11:30 AM, Mladen Turk wrote: Jim Jagielski wrote: Mladen Turk wrote: There are lots of things to backport. IMHO its the entire HEAD, and spread over the multiple svn commits. How we should deal with that? Having multiple backports or a single one? we should simply update STATUS as usually... most of the backports are self contained enough and non-dependent to allow that, I think. It looks like bureaucratic overhead to me :) But OK, we can have multiple STATUS entries. Regards, Mladen.
[Announcement] Apache HTTP Server 2.2.3 (2.0.59, 1.3.37) Released
Apache HTTP Server 2.2.3 Released The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the release of version 2.2.3 of the Apache HTTP Server (Apache). This version of Apache is principally a bug and security fix release. The following potential security flaws are addressed; CVE-2006-3747: An off-by-one flaw exists in the Rewrite module, mod_rewrite, as shipped with Apache 1.3 since 1.3.28, 2.0 since 2.0.46, and 2.2 since 2.2.0. Depending on the manner in which Apache HTTP Server was compiled, this software defect may result in a vulnerability which, in combination with certain types of Rewrite rules in the web server configuration files, could be triggered remotely. For vulnerable builds, the nature of the vulnerability can be denial of service (crashing of web server processes) or potentially allow arbitrary code execution. This issue has been rated as having important security impact by the Apache HTTP Server Security Team. This flaw does not affect a default installation of Apache HTTP Server. Users who do not use, or have not enabled, the Rewrite module mod_rewrite are not affected by this issue. This issue only affects installations using a Rewrite rule with the following characteristics: * The RewriteRule allows the attacker to control the initial part of the rewritten URL (for example if the substitution URL starts with $1) * The RewriteRule flags do NOT include any of the following flags: Forbidden (F), Gone (G), or NoEscape (NE). Please note that ability to exploit this issue is dependent on the stack layout for a particular compiled version of mod_rewrite. If the compiler used to compile Apache HTTP Server has added padding to the stack immediately after the buffer being overwritten, it will not be possible to exploit this issue, and Apache HTTP Server will continue operating normally. The Apache HTTP Server project recommends that all users who have built Apache from source apply the patch or upgrade to the latest level and rebuild. Providers of Apache-based web servers in pre-compiled form will be able to determine if this vulnerability applies to their builds. That determination has no bearing on any other builds of Apache HTTP Server, and Apache HTTP Server users are urged to exercise caution and apply patches or upgrade unless they have specific instructions from the provider of their web server. Statements from vendors can be obtained from the US-CERT vulnerability note for this issue at: http://www.kb.cert.org/vuls/id/395412 The Apache HTTP Server project thanks Mark Dowd of McAfee Avert Labs for the responsible reporting of this vulnerability. We consider this release to be the best version of Apache available, and encourage users of all prior versions to upgrade. Apache HTTP Server 2.2.3 is available for download from: http://httpd.apache.org/download.cgi Apache 2.2 offers numerous enhancements, improvements, and performance boosts over the 2.0 codebase. For an overview of new features introduced since 2.0 please see: http://httpd.apache.org/docs/2.2/new_features_2_2.html Please see the CHANGES_2.2 file, linked from the download page, for a full list of changes. Apache HTTP Server 1.3.37 and 2.0.59 legacy releases are also available with this security fix. See the appropriate CHANGES from the url above. The Apache HTTP Project developers strongly encourage all users to migrate to Apache 2.2, as only limited maintenance is performed on these legacy versions. This release includes the Apache Portable Runtime (APR) version 1.2.7 bundled with the tar and zip distributions. The APR libraries libapr, libaprutil, and (on Win32) libapriconv must all be updated to ensure binary compatibility and address many known platform bugs. This release builds on and extends the Apache 2.0 API. Modules written for Apache 2.0 will need to be recompiled in order to run with Apache 2.2, but no substantial reworking should be necessary. http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/VERSIONING When upgrading or installing this version of Apache, please bear in mind that if you intend to use Apache with one of the threaded MPMs, you must ensure that any modules you will be using (and the libraries they depend on) are thread-safe.
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Hi, I have committed the code to get comments on some points: - Does it make sense to include from support objects from modules/proxy? - Does the mod_proxy_health_checker is the right way to go? - I mean: one part is storing the worker information to use it in an external process and the other is the health check of a worker, should the module be cut in 2 pieces? - - Any other comments? Cheers Jean-Frederic On 7/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jfclereDate: Fri Jul 28 09:33:58 2006New Revision: 426604URL: http://svn.apache.org/viewvc?rev=426604view=revLog:First try to put togother an external health checker for mod_proxy.Added:httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/health_checker_util.c httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.chttpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.hhttpd/httpd/branches/httpd-proxy-scoreboard/support/proxymonitor.c Modified:httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy.chttpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy.h httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/proxy_util.chttpd/httpd/branches/httpd-proxy-scoreboard/support/Makefile.in+++ CUT +++
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Hi, I have committed the code to get comments on some points: - Does it make sense to include from support objects from modules/proxy? - Does the mod_proxy_health_checker is the right to do? - I mean: one part is storing the worker information to use it in an external process and the other is the health check of a worker, should the module be cut in 2 pieces? - - Any other comments? Cheers Jean-Frederic [EMAIL PROTECTED] wrote: Author: jfclere Date: Fri Jul 28 09:33:58 2006 New Revision: 426604 URL: http://svn.apache.org/viewvc?rev=426604view=rev Log: First try to put togother an external health checker for mod_proxy. Added: httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/health_checker_util.c httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.h httpd/httpd/branches/httpd-proxy-scoreboard/support/proxymonitor.c Modified: httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4 httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy.c httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy.h httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/proxy_util.c httpd/httpd/branches/httpd-proxy-scoreboard/support/Makefile.in +++ CUT +++
Re: svn commit: r425677 - /httpd/httpd/branches/2.2.x/STATUS
On Jul 28, 2006, at 2:31 AM, Nick Kew wrote: I'm in two minds about that. There is the workaround of configure --with-pcre but where does that leave packages? PR#27550 names two modules that needed to work around the bundled PCRE: mod_php and mod_caml. That implies two workarounds for the same problem. What if the PHP and CAML folks (or AN Other with the same problem) were to adopt mutually incompatible solutions? AFAICT the only mitigating circumstance is that this patch is not the underlying problem, so I'm complaining at a symptom rather than the cause. But it feels like when in a hole, dig deeper. Your reasoning may be valid for trunk, but not for 2.2. 2.2 is saddled with a builtin PCRE and it would be foolish not to fix its bugs to the extent that we can do so without breaking binaries. I suggest you put the energy into finding a clean way to remove PCRE from trunk. Until we do that, no patches to PCRE is an irresponsible position -- we have to maintain the code that we ship. Roy
product name
On Jul 27, 2006, at 1:36 PM, William A. Rowe, Jr. wrote: Roy T. Fielding wrote: That line is for the product name, not the project name. And - I understood that our product is the Apache HTTP Server, not httpd. At least that's been the consensus in the docs project for the last three years. Well, the docs project consensus is wrong. Our main product is httpd (one of several products) and our project is Apache HTTP Server Project. Change it back, please. It isn't important enough to stop the release, but I really don't appreciate people tweaking a file that I edited myself just a couple weeks ago to contain the correct legal information. Well, as I read it it was the incorrect legal information based on the project's evolution and group concensus. My appologies if I'm wrong. Our product is apache_1.3.37.tar.gz httpd-2.0.59-win32-src.zip httpd-2.0.59.tar.gz httpd-2.2.3-win32-src.zip httpd-2.2.3.tar.gz and the NOTICE files are tied to the source tree (httpd). What is wrong with this page (and the rest of the website and project files and...): http://httpd.apache.org/ Your title httpd is definately wrong. NCSA was httpd. Others ship httpd. This being Apache httpd at the very least invalidated the original NOTICE. That is nonsense. httpd is the name of -one- binary in the Apache HTTP Server, which includes a host of other binaries (e.g. support/) and the NOTICE file you placed there applies to them all, no? It is the name of the product containing a whole bunch of source code and many binaries, one of which is sometimes called httpd. The tarballs are called httpd. The legal notices will be called httpd, and the links to the artifacts will be called httpd. The only reason there is any confusion at all regarding the name is because the windows installer never used the right name. I have this nagging suspicion that once again the project has offended your sensibilities while your back was turned. Please be assured it wasn't intentional, but that we had this back-and-forth for months before the -project- determined it creates the Apache HTTP Server. A recent comment to Mark reaffirms it, I didn't see your response? I've been reading this dev list continuously for the past six years. People discuss what to put in the Announcement text on every release, but the only discussion I've seen about our product name was Paul's suggestion we change it to d. Only recently did people start changing the text to remove httpd, and that was certainly not by consensus. Do you have a pointer, or are these just more off-list conversations? Roy
Re: product name
Roy T. Fielding wrote: People discuss what to put in the Announcement text on every release, but the only discussion I've seen about our product name was Paul's suggestion we change it to d. yeah, that was funny :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
On 28.07.2006 18:34, [EMAIL PROTECTED] wrote:
Author: jfclere
Date: Fri Jul 28 09:33:58 2006
New Revision: 426604
URL: http://svn.apache.org/viewvc?rev=426604view=rev
Log:
First try to put togother an external health checker for mod_proxy.
Modified: httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4?rev=426604r1=426603r2=426604view=diff
==
--- httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4
(original)
+++ httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4 Fri
Jul 28 09:33:58 2006
@@ -17,6 +17,7 @@
+}
+/* copy the worker information in the shared area so the health-checker can
extract the part it need */
+static apr_status_t add_entry(proxy_worker *worker, char *balancer_name, int
id)
What is the purpose of the id parameter. I do not see that it is used.
+{
+struct proxy_worker_conf *workerconf = NULL;
+apr_status_t rv;
+
+if (myscore == NULL)
+return APR_ENOSHMAVAIL;
+rv = checkstorage-ap_slotmem_mem(myscore, worker-id, (void *)
workerconf);
+if (rv != APR_SUCCESS) {
+return rv;
+}
+
+if (balancer_name)
+strcpy(workerconf-balancer_name, balancer_name);
+workerconf-id = worker-id;
+workerconf-retry = worker-retry;
+workerconf-lbfactor = worker-lbfactor;
Is this approach thread safe / process safe or is there no need to be?
+if (worker-name)
+strcpy(workerconf-name, worker-name);
+if (worker-scheme)
+strcpy(workerconf-scheme, worker-scheme);
+if (worker-hostname)
+strcpy(workerconf-hostname, worker-hostname);
+if (worker-route)
+strcpy(workerconf-route, worker-route);
+if (worker-redirect)
+strcpy(workerconf-redirect, worker-redirect);
Don't you need to use strncpy here to avoid buffer overflows?
+/* read the entry stored in the shared area and build the corresponding
worker structure */
+static apr_status_t get_entry(int id, proxy_worker **worker, char
**balancer_name, apr_pool_t *pool)
+{
+struct proxy_worker_conf *workerconf = NULL;
+apr_status_t rv;
+
+if (myscore == NULL)
+return APR_ENOSHMAVAIL;
+rv = checkstorage-ap_slotmem_mem(myscore, id, (void *) workerconf);
+if (rv != APR_SUCCESS)
+return rv;
+
+/* allocate the data */
+*worker = apr_pcalloc(pool, sizeof(proxy_worker));
+if (workerconf-balancer_name)
+*balancer_name = apr_pcalloc(pool,
strlen(workerconf-balancer_name));
+else
+*balancer_name = NULL;
+
+/* The httpstatus is handle by httpd don't touch it here */
+(* worker)-id = workerconf-id;
+// XXX: what to do (* worker)-s = workerconf;
+(* worker)-retry = workerconf-retry;
+(* worker)-lbfactor = workerconf-lbfactor;
+if (workerconf-name)
+strcpy((* worker)-name, workerconf-name);
+if (workerconf-scheme)
+strcpy((* worker)-scheme, workerconf-scheme);
+if (workerconf-hostname)
+strcpy((* worker)-hostname, workerconf-hostname);
+if (workerconf-route)
+strcpy((* worker)-route, workerconf-route);
+if (workerconf-redirect)
+strcpy((* worker)-redirect, workerconf-redirect);
Don't you need to allocate space for this first (like with the balancer name)?
Added:
httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c?rev=426604view=auto
==
---
httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c
(added)
+++
httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c
Fri Jul 28 09:33:58 2006
+
+static int healthck_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
+ apr_pool_t *ptemp)
+{
+slotmem_storage_method *checkstorage;
+health_worker_method *worker_storage = health_checker_get_storage();
+ap_slotmem_t *myscore;
+
+checkstorage = ap_lookup_provider(SLOTMEM_STORAGE, shared, 0);
+if (checkstorage) {
+health_checker_init_slotmem_storage(checkstorage);
+}
+if (checkstorage worker_storage) {
+checkstorage-ap_slotmem_create(myscore, proxy/checker,
worker_storage-getentrysize(), 128, pconf);
+health_checker_init_slotmem(myscore);
+}
+return OK;
+}
+
+/* XXX: Was to get ap_proxy_lb_workers()
+static int healthck_post_config(apr_pool_t *pconf, apr_pool_t *plog,
+apr_pool_t *ptemp, server_rec *s)
+{
+slotmem_storage_method *checkstorage =
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
On Jul 28, 2006, at 12:34 PM, [EMAIL PROTECTED] wrote: Author: jfclere Date: Fri Jul 28 09:33:58 2006 New Revision: 426604 URL: http://svn.apache.org/viewvc?rev=426604view=rev Log: First try to put togother an external health checker for mod_proxy. Just coming back from OSCON, I haven't had a chance to take a deeper look but MAN that's a lot of code and data duplication. What's the goal for the code? What's the push for an external health checker?
Re: product name
Roy T. Fielding wrote: It is the name of the product containing a whole bunch of source code and many binaries, one of which is sometimes called httpd. The tarballs are called httpd. The legal notices will be called httpd, and the links to the artifacts will be called httpd. The only reason there is any confusion at all regarding the name is because the windows installer never used the right name. Well, +++1 that windows 2.x binaries used the wrong name. Be fixed by me if I'm the one to roll a windows binary for the next release 2.2.4. http://archive.apache.org/dist/httpd/ shows this has been an issue for some very long time, and had nothing to do with Windows. Just happened that windows didn't s/apache/httpd/ in sync with the other platforms. From this perspective and for clarity, while we are on the subject, perhaps apache-httpd-X would be the appropriate package names, and seems that would be consistent with how most many ASF projects are distributing their tarballs now? Not now perhaps, but with 2.4 or 3.0 release. Comments? Only recently did people start changing the text to remove httpd, and that was certainly not by consensus. Do you have a pointer, or are these just more off-list conversations? Just out of curiousity, have you also followed docs@ which is where almost all 'linguistic' twists around Apache HTTP tend to be discussed? Will forward pointers to the list once I figure out a sane way to search them, later tonight. The thread has wound its way through httpd-dev, httpd-docs, prc, members, should be fun to track it back down. I certainly hope this is not an off-list discussion. Bill
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
On Jul 28, 2006, at 1:54 PM, jean-frederic clere wrote: Hi, I have committed the code to get comments on some points: - Does it make sense to include from support objects from modules/ proxy? - Does the mod_proxy_health_checker is the right way to go? - I mean: one part is storing the worker information to use it in an external process and the other is the health check of a worker, should the module be cut in 2 pieces? - - Any other comments? I thought that this was about abstracting out scoreboard so that other modules could have scoreboard-like access without mucking around with the real scoreboard...
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Em 28/07/2006, às 13:34, [EMAIL PROTECTED] escreveu:
Author: jfclere
Date: Fri Jul 28 09:33:58 2006
New Revision: 426604
...
+
+static const slotmem_storage_method *checkstorage = NULL;
+static ap_slotmem_t *myscore=NULL;
Indentation consistency ? myscore=NULL
+
+if (!port) {
+if (strcmp(scheme, ajp) == 0)
+port = 8009;
+else if (strcmp(scheme, http) == 0)
+port = 80;
+else
+port = 443;
+}
apr_uri_port_of_scheme ? (it may not have the ajp scheme, a patch is
appreciated)
+rv = apr_sockaddr_info_get(epsv_addr, hostname, APR_INET,
port, 0, pool);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL,
+ apr_sockaddr_info_get failed);
+apr_socket_close(newsock);
+return rv;
+}
ap_log_error(..APLOG_ERR, rv, NULL..) so we may have a hint why it
failed
+rv = apr_socket_timeout_set(newsock, 10);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
+apr_socket_timeout_set);
+apr_socket_close(newsock);
+return rv;
same for ap_log_error
+rv = apr_socket_connect(newsock, epsv_addr);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, NULL,
+apr_socket_connect failed);
+apr_socket_close(newsock);
+return rv;
+}
same for ap_log_error..and so on.
+
+if (balancer_name)
+strcpy(workerconf-balancer_name, balancer_name);
+workerconf-id = worker-id;
+workerconf-retry = worker-retry;
+workerconf-lbfactor = worker-lbfactor;
+if (worker-name)
+strcpy(workerconf-name, worker-name);
+if (worker-scheme)
+strcpy(workerconf-scheme, worker-scheme);
+if (worker-hostname)
+strcpy(workerconf-hostname, worker-hostname);
+if (worker-route)
+strcpy(workerconf-route, worker-route);
+if (worker-redirect)
+strcpy(workerconf-redirect, worker-redirect);
strncpy ?
+/* allocate the data */
+*worker = apr_pcalloc(pool, sizeof(proxy_worker));
+if (workerconf-balancer_name)
+*balancer_name = apr_pcalloc(pool, strlen(workerconf-
balancer_name));
+else
+*balancer_name = NULL;
allocated for what ? the string is not copied. Also, shoudn't it be
strlen(..) + 1 ?
+/* make the module usuable from outside */
+health_worker_method *health_checker_get_storage()
+{
+return(worker_storage);
+}
+
+/* handle the slotmem storage */
+void health_checker_init_slotmem_storage(slotmem_storage_method *
storage)
+{
+checkstorage = storage;
+}
+slotmem_storage_method * health_checker_get_slotmem_storage()
+{
+return(checkstorage);
+}
+
+/* handle the slotmen itself */
+void health_checker_init_slotmem(ap_slotmem_t *score)
+{
+ myscore = score;
+}
+ap_slotmem_t *health_checker_get_slotmem()
+{
+return(myscore);
+}
static APR_INLINE ...
+char * ap_server_root_relative(apr_pool_t *p, const char *name)
+{
+char *fname;
+
+/* XXX: apr_filepath_merge better ? */
+if (basedir name[0] != '/') {
+fname = apr_pcalloc(p, strlen(basedir)+strlen(name)+1);
+strcpy(fname, basedir);
+strcat(fname, /);
+strcat(fname, name);
apr_pstrcat ?
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Jim Jagielski wrote: On Jul 28, 2006, at 1:54 PM, jean-frederic clere wrote: Hi, I have committed the code to get comments on some points: - Does it make sense to include from support objects from modules/ proxy? - Does the mod_proxy_health_checker is the right way to go? - I mean: one part is storing the worker information to use it in an external process and the other is the health check of a worker, should the module be cut in 2 pieces? - - Any other comments? I thought that this was about abstracting out scoreboard so that other modules could have scoreboard-like access without mucking around with the real scoreboard... The scoreboard abstract is in modules/mem. Cheers Jean-Frederic
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Jim Jagielski wrote: On Jul 28, 2006, at 12:34 PM, [EMAIL PROTECTED] wrote: Author: jfclere Date: Fri Jul 28 09:33:58 2006 New Revision: 426604 URL: http://svn.apache.org/viewvc?rev=426604view=rev Log: First try to put togother an external health checker for mod_proxy. Just coming back from OSCON, I haven't had a chance to take a deeper look but MAN that's a lot of code and data duplication. What's the goal for the code? What's the push for an external health checker? I see different reasons to have an external health checker: - It does not need a request to start. - It tests the back-end server not only the socket used to send the data. - It allows to have the information that a worker is down before send a request to it (prevent useless retries). Cheers Jean-Frederic
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
On Jul 28, 2006, at 4:03 PM, Jean-frederic Clere wrote: Jim Jagielski wrote: On Jul 28, 2006, at 1:54 PM, jean-frederic clere wrote: Hi, I have committed the code to get comments on some points: - Does it make sense to include from support objects from modules/ proxy? - Does the mod_proxy_health_checker is the right way to go? - I mean: one part is storing the worker information to use it in an external process and the other is the health check of a worker, should the module be cut in 2 pieces? - - Any other comments? I thought that this was about abstracting out scoreboard so that other modules could have scoreboard-like access without mucking around with the real scoreboard... The scoreboard abstract is in modules/mem. That is very specific to the proxy module implementation... It basically just moves the current scoreboard access for the proxy module to a different area, wraps them in some function redirection, but with an impl that isn't useful to anyone else but the proxy module... at least that's how it appears to me :/ Unless I'm missing something...
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Many compile warnings when compiling with maint-mode: mod_proxy.c: In function 'add_pass': mod_proxy.c:1176: warning: implicit declaration of function 'proxy_checkstorage_add_entry' mod_proxy.c: In function 'proxy_post_config': mod_proxy.c:1870: warning: implicit declaration of function 'proxy_create_comarea' mod_proxy.c: In function 'proxy_pre_config': mod_proxy.c:2014: warning: implicit declaration of function 'proxy_lookup_storage_provider' In file included from proxy_util.c:20: mod_proxy_health_checker.h:32: warning: function declaration isn't a prototype proxy_util.c:2234: warning: no previous prototype for 'proxy_create_comarea' proxy_util.c:2244: warning: function declaration isn't a prototype proxy_util.c:2255: warning: no previous prototype for 'proxy_checkstorage_add_entry' In file included from mod_proxy_health_checker.c:15: mod_proxy_health_checker.h:32: warning: function declaration isn't a prototype mod_proxy_health_checker.c: In function 'healthck_pre_config': mod_proxy_health_checker.c:21: warning: implicit declaration of function 'health_checker_get_storage' mod_proxy_health_checker.c:21: warning: initialization makes pointer from integer without a cast mod_proxy_health_checker.c:26: warning: implicit declaration of function 'health_checker_init_slotmem_storage' mod_proxy_health_checker.c:30: warning: implicit declaration of function 'health_checker_init_slotmem' mod_proxy_health_checker.c: In function 'ap_healthstore_register_hook': mod_proxy_health_checker.c:57: warning: initialization makes pointer from integer without a cast mod_proxy_health_checker.c:54: warning: unused variable 'aszPre' In file included from health_checker_util.c:32: mod_proxy_health_checker.h:32: warning: function declaration isn't a prototype health_checker_util.c:129: warning: function declaration isn't a prototype health_checker_util.c: In function 'get_entry': health_checker_util.c:240: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:242: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:244: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:246: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:248: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c: In function 'get_entryconf': health_checker_util.c:275: warning: passing argument 3 of 'checkstorage-ap_slotmem_mem' from incompatible pointer type health_checker_util.c: In function 'check_entryhealth': health_checker_util.c:289: warning: passing argument 3 of 'checkstorage-ap_slotmem_mem' from incompatible pointer type health_checker_util.c: At top level: health_checker_util.c:318: warning: initialization from incompatible pointer type health_checker_util.c:325: warning: function declaration isn't a prototype health_checker_util.c: In function 'health_checker_get_storage': health_checker_util.c:326: warning: return discards qualifiers from pointer target type health_checker_util.c: At top level: health_checker_util.c:331: warning: no previous prototype for 'health_checker_init_slotmem_storage' health_checker_util.c:335: warning: function declaration isn't a prototype health_checker_util.c: In function 'health_checker_get_slotmem_storage': health_checker_util.c:336: warning: return discards qualifiers from pointer target type health_checker_util.c: At top level: health_checker_util.c:341: warning: no previous prototype for 'health_checker_init_slotmem' health_checker_util.c:345: warning: function declaration isn't a prototype health_checker_util.c:306: warning: 'check_poolhealth' defined but not used sharedmem_util.c:52: warning: no previous prototype for 'cleanup_slotmem' sharedmem_util.c: In function 'ap_slotmem_create': sharedmem_util.c:139: warning: implicit declaration of function 'apr_pstrdup' sharedmem_util.c:139: warning: assignment makes pointer from integer without a cast sharedmem_util.c:83: warning: unused variable 'slotmem' sharedmem_util.c: In function 'ap_slotmem_attach': sharedmem_util.c:192: warning: assignment makes pointer from integer without a cast sharedmem_util.c:154: warning: unused variable 'slotmem' sharedmem_util.c: At top level: sharedmem_util.c:234: warning: function declaration isn't a prototype sharedmem_util.c: In function 'sharedmem_getstorage': sharedmem_util.c:235: warning: return discards qualifiers from pointer target type sharedmem_util.c: At top level: sharedmem_util.c:239: warning: no previous prototype for 'sharedmem_initglobalpool' sharedmem_util.c:244: warning: no previous prototype for 'sharedmem_initialize_cleanup'
Re: product name
On Jul 28, 2006, at 12:32 PM, William A. Rowe, Jr. wrote: From this perspective and for clarity, while we are on the subject, perhaps apache-httpd-X would be the appropriate package names, and seems that would be consistent with how most many ASF projects are distributing their tarballs now? Not now perhaps, but with 2.4 or 3.0 release. Comments? I agree, though if we change it we may as well go to apache-server-2.4.x given the noise about protocol-independence. Only recently did people start changing the text to remove httpd, and that was certainly not by consensus. Do you have a pointer, or are these just more off-list conversations? Just out of curiousity, have you also followed docs@ which is where almost all 'linguistic' twists around Apache HTTP tend to be discussed? Yes, but when we set up docs we made a conscious decision that absolutely no product changes (aside from the docs themselves) would be made on that list. Will forward pointers to the list once I figure out a sane way to search them, later tonight. The thread has wound its way through httpd-dev, httpd-docs, prc, members, should be fun to track it back down. I tried to yesterday, but it is nigh impossible without a single unique word to search for. Maybe we should just hold another vote. Roy
Re: product name
On Friday 28 July 2006 19:51, Roy T. Fielding wrote: Our product is apache_1.3.37.tar.gz httpd-2.0.59-win32-src.zip httpd-2.0.59.tar.gz httpd-2.2.3-win32-src.zip httpd-2.2.3.tar.gz and the NOTICE files are tied to the source tree (httpd). Isn't the whole problem the lack of a proper product name that we or anyone can identify with (other than Apache)? With that in mind, how about something more distinctive and less ineffably lame than anything like httpd or web server? For example, draw on our heritage and name it feather? Or find a novel word that describes a central role in communication? Did the apache indians have any great meeting? Or perhaps we could take a word from some more familiar tradition that hasn't hitherto been adopted on the 'net? -- Nick Kew
Re: product name
Let me sugest: :: Nahche :: Nahche (Na-ai-che, `mischievous,' `meddlesome.'-George Wrattan). An Apache warrior, a member of the Chiricahua band. He is the second son of the celebrated Cochise, and as hereditary chief succeeded his elder brother, Tazi, on the death of the latter. His mother was a daughter of the notorious Mangas Coloradas. why: 1) looks vagly like Apache ;) 2) has a link to Apache Indians 3) Sounds cool On 7/28/06, Nick Kew [EMAIL PROTECTED] wrote: On Friday 28 July 2006 19:51, Roy T. Fielding wrote: Our product is apache_1.3.37.tar.gz httpd-2.0.59-win32-src.zip httpd-2.0.59.tar.gz httpd-2.2.3-win32-src.zip httpd-2.2.3.tar.gz and the NOTICE files are tied to the source tree (httpd). Isn't the whole problem the lack of a proper product name that we or anyone can identify with (other than Apache)? With that in mind, how about something more distinctive and less ineffably lame than anything like httpd or web server? For example, draw on our heritage and name it feather? Or find a novel word that describes a central role in communication? Did the apache indians have any great meeting? Or perhaps we could take a word from some more familiar tradition that hasn't hitherto been adopted on the 'net? -- Nick Kew -- ~Jorge
Re: product name
On Friday 28 July 2006 22:59, Jorge Schrauwen wrote: Let me sugest: :: Nahche :: Nahche (Na-ai-che, `mischievous,' `meddlesome.'-George Wrattan). An Apache warrior, a member of the Chiricahua band. He is the second son of the celebrated Cochise, and as hereditary chief succeeded his elder brother, Tazi, on the death of the latter. His mother was a daughter of the notorious Mangas Coloradas. why: 1) looks vagly like Apache ;) 2) has a link to Apache Indians 3) Sounds cool I don't like it. Too confusing for an english-speaker to try and pronunce. That's not at all the same as confusion over pronunciation of, say, Linux. We may get that wrong, but we can do so with reasonable fluency and confidence. Not so Nahche:-( I wonder if that might also carry a risk of offending any descendents of the apache indians, if he's such an important figure in their history? -- Nick Kew
Re: product name
Nick Kew wrote: Isn't the whole problem the lack of a proper product name that we or anyone can identify with (other than Apache)? With that in mind, how about something more distinctive and less ineffably lame than anything like httpd or web server? For example, draw on our heritage and name it feather? Or find a novel word that describes a central role in communication? Did the apache indians have any great meeting? Or perhaps we could take a word from some more familiar tradition that hasn't hitherto been adopted on the 'net? Well this is a question in two parts. What *is* our product name right now? So it should remain until the 'next major release', e.g. at least 2.4 if not through 2.x. The second part is what should the next Apache HTTP Server be called? That's what started the thread about d, and I think your ideas are more speaking to that 'next name'. Which isn't a bad discussion to start now, thank you. Bill
Re: product name
I wouldn't push the "Apache" thing. Truth is... a letter could show up at any moment from lawyers of the Apache Nation regarding the name usage. Might even be way overdue. I wouldn't "go there" and draw attention to the issue at all. Yours... Kevin Kiley In a message dated 7/28/2006 3:00:23 PM Pacific Standard Time, [EMAIL PROTECTED] writes: Let me sugest::: Nahche ::Nahche (Na-ai-che, `mischievous,' `meddlesome.'-George Wrattan). AnApache warrior, a member of the Chiricahua band. He is the second sonof the celebrated Cochise, and as hereditary chief succeeded his elderbrother, Tazi, on the death of the latter. His mother was a daughterof the notorious Mangas Coloradas.why:1) looks vagly like Apache ;)2) has a link to Apache Indians3) Sounds cool
Re: product name
Jorge Schrauwen wrote: Let me sugest: :: Nahche :: Nahche (Na-ai-che, `mischievous,' `meddlesome.'-George Wrattan). An Apache warrior, a member of the Chiricahua band. He is the second son of the celebrated Cochise, and as hereditary chief succeeded his elder brother, Tazi, on the death of the latter. His mother was a daughter of the notorious Mangas Coloradas. FYI we are careful not avoid adding more Indian names, but most importantly, we would never borrow a proper individuals' names. If your suggested name wouldn't fly with the NCAA it probably won't fly here :) Bill
Re: product name
Fair point you have there... As long as the new name isn't some way to hard to rememebr abrivation :) AMPES ;) Apache Multi Protocal Extenable Sever j/k On 7/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wouldn't push the Apache thing. Truth is... a letter could show up at any moment from lawyers of the Apache Nation regarding the name usage. Might even be way overdue. I wouldn't go there and draw attention to the issue at all. Yours... Kevin Kiley In a message dated 7/28/2006 3:00:23 PM Pacific Standard Time, [EMAIL PROTECTED] writes: Let me sugest: :: Nahche :: Nahche (Na-ai-che, `mischievous,' `meddlesome.'-George Wrattan). An Apache warrior, a member of the Chiricahua band. He is the second son of the celebrated Cochise, and as hereditary chief succeeded his elder brother, Tazi, on the death of the latter. His mother was a daughter of the notorious Mangas Coloradas. why: 1) looks vagly like Apache ;) 2) has a link to Apache Indians 3) Sounds cool -- ~Jorge
Re: What does the Authz reject directive really mean...
On 07/29/2006 12:30 AM, Brad Nicholes wrote: There is a new concept (directive) that has been added to the authorization (access control) portion of the web server. This new concept is reject. Basically what this directive does is allow you to specify conditions by which access or authorization is denied. The question I have is how binding should reject be when found within a hierarchy set of authorization rules? Given the following configuration for example: Alias /pages /www/pages Directory /www/pages Reject ip 127.0.0.1 /Directory Directory /www/pages/secure Authtype Basic AuthName Something AuthBasicProvider file AuthUserFile /somewhere/usr.dat SatisfyAll Require valid-user Reject user joe /SatisfyAll /Directory In this case is the user granted or denied access to the following URL: https://127.0.0.1/pages/secure user: betty betty would be a valid user and the user name != joe but the ip is 127.0.0.1. In other words if the authorization directives specified in both Directory blocks are OR'ed together then authorization would be GRANTED since the result of the second block is GRANTED. However if the blocks are AND'ed together or the reject directive is definitive, then the result would be DENIED. Under the current implementation the implied merge would be an OR operation resulting in access GRANTED. So I guess my question is, should reject be definitive? If a reject rule is ever encountered and satisfied within the logic of authorization, is access automatically denied no matter what any of the other rules might produce? I am leaning towards 'yes, access should be denied'. I guess we need something like the old satisfy any / satisfy all here. In old speak satisfy any would have granted betty access whereas satisfy all would have denied it. As you cannot build SatisfyAll SatisfyOne blocks across different Directory / Location containers I think we need to have a directive that decides how to merge (AND / OR) the authz result from the parent container with that from the current container. Regards Rüdiger
Re: product name
Apache HTTP Server is (mostly) a web server. Let's call it 'parker' (I'll let the Spider Man fans explain it... :) ) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
docs are still half-missing
just a heads up: does not exist http://httpd.apache.org/apreq/docs/libapreq2/examples.html still no perl http://httpd.apache.org/apreq/docs/libapreq2/group__apreq__lang.html
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Jim Jagielski wrote: Many compile warnings when compiling with maint-mode: Fixed. Thanks, Cheers Jean-Frederic mod_proxy.c: In function 'add_pass': mod_proxy.c:1176: warning: implicit declaration of function 'proxy_checkstorage_add_entry' mod_proxy.c: In function 'proxy_post_config': mod_proxy.c:1870: warning: implicit declaration of function 'proxy_create_comarea' mod_proxy.c: In function 'proxy_pre_config': mod_proxy.c:2014: warning: implicit declaration of function 'proxy_lookup_storage_provider' In file included from proxy_util.c:20: mod_proxy_health_checker.h:32: warning: function declaration isn't a prototype proxy_util.c:2234: warning: no previous prototype for 'proxy_create_comarea' proxy_util.c:2244: warning: function declaration isn't a prototype proxy_util.c:2255: warning: no previous prototype for 'proxy_checkstorage_add_entry' In file included from mod_proxy_health_checker.c:15: mod_proxy_health_checker.h:32: warning: function declaration isn't a prototype mod_proxy_health_checker.c: In function 'healthck_pre_config': mod_proxy_health_checker.c:21: warning: implicit declaration of function 'health_checker_get_storage' mod_proxy_health_checker.c:21: warning: initialization makes pointer from integer without a cast mod_proxy_health_checker.c:26: warning: implicit declaration of function 'health_checker_init_slotmem_storage' mod_proxy_health_checker.c:30: warning: implicit declaration of function 'health_checker_init_slotmem' mod_proxy_health_checker.c: In function 'ap_healthstore_register_hook': mod_proxy_health_checker.c:57: warning: initialization makes pointer from integer without a cast mod_proxy_health_checker.c:54: warning: unused variable 'aszPre' In file included from health_checker_util.c:32: mod_proxy_health_checker.h:32: warning: function declaration isn't a prototype health_checker_util.c:129: warning: function declaration isn't a prototype health_checker_util.c: In function 'get_entry': health_checker_util.c:240: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:242: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:244: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:246: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c:248: warning: passing argument 1 of 'strcpy' discards qualifiers from pointer target type health_checker_util.c: In function 'get_entryconf': health_checker_util.c:275: warning: passing argument 3 of 'checkstorage-ap_slotmem_mem' from incompatible pointer type health_checker_util.c: In function 'check_entryhealth': health_checker_util.c:289: warning: passing argument 3 of 'checkstorage-ap_slotmem_mem' from incompatible pointer type health_checker_util.c: At top level: health_checker_util.c:318: warning: initialization from incompatible pointer type health_checker_util.c:325: warning: function declaration isn't a prototype health_checker_util.c: In function 'health_checker_get_storage': health_checker_util.c:326: warning: return discards qualifiers from pointer target type health_checker_util.c: At top level: health_checker_util.c:331: warning: no previous prototype for 'health_checker_init_slotmem_storage' health_checker_util.c:335: warning: function declaration isn't a prototype health_checker_util.c: In function 'health_checker_get_slotmem_storage': health_checker_util.c:336: warning: return discards qualifiers from pointer target type health_checker_util.c: At top level: health_checker_util.c:341: warning: no previous prototype for 'health_checker_init_slotmem' health_checker_util.c:345: warning: function declaration isn't a prototype health_checker_util.c:306: warning: 'check_poolhealth' defined but not used sharedmem_util.c:52: warning: no previous prototype for 'cleanup_slotmem' sharedmem_util.c: In function 'ap_slotmem_create': sharedmem_util.c:139: warning: implicit declaration of function 'apr_pstrdup' sharedmem_util.c:139: warning: assignment makes pointer from integer without a cast sharedmem_util.c:83: warning: unused variable 'slotmem' sharedmem_util.c: In function 'ap_slotmem_attach': sharedmem_util.c:192: warning: assignment makes pointer from integer without a cast sharedmem_util.c:154: warning: unused variable 'slotmem' sharedmem_util.c: At top level: sharedmem_util.c:234: warning: function declaration isn't a prototype sharedmem_util.c: In function 'sharedmem_getstorage': sharedmem_util.c:235: warning: return discards qualifiers from pointer target type sharedmem_util.c: At top level: sharedmem_util.c:239: warning: no previous prototype for 'sharedmem_initglobalpool' sharedmem_util.c:244: warning: no previous prototype for 'sharedmem_initialize_cleanup'
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Davi Arnaut wrote:
Em 28/07/2006, às 13:34, [EMAIL PROTECTED] escreveu:
Author: jfclere
Date: Fri Jul 28 09:33:58 2006
New Revision: 426604
...
+
+static const slotmem_storage_method *checkstorage = NULL;
+static ap_slotmem_t *myscore=NULL;
Indentation consistency ? myscore=NULL
fixed.
+
+if (!port) {
+if (strcmp(scheme, ajp) == 0)
+port = 8009;
+else if (strcmp(scheme, http) == 0)
+port = 80;
+else
+port = 443;
+}
apr_uri_port_of_scheme ? (it may not have the ajp scheme, a patch is
appreciated)
Done.
+rv = apr_sockaddr_info_get(epsv_addr, hostname, APR_INET,
port, 0, pool);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL,
+ apr_sockaddr_info_get failed);
+apr_socket_close(newsock);
+return rv;
+}
ap_log_error(..APLOG_ERR, rv, NULL..) so we may have a hint why it
failed
Yep.
+rv = apr_socket_timeout_set(newsock, 10);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
+apr_socket_timeout_set);
+apr_socket_close(newsock);
+return rv;
same for ap_log_error
+rv = apr_socket_connect(newsock, epsv_addr);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, NULL,
+apr_socket_connect failed);
+apr_socket_close(newsock);
+return rv;
+}
same for ap_log_error..and so on.
+
+if (balancer_name)
+strcpy(workerconf-balancer_name, balancer_name);
+workerconf-id = worker-id;
+workerconf-retry = worker-retry;
+workerconf-lbfactor = worker-lbfactor;
+if (worker-name)
+strcpy(workerconf-name, worker-name);
+if (worker-scheme)
+strcpy(workerconf-scheme, worker-scheme);
+if (worker-hostname)
+strcpy(workerconf-hostname, worker-hostname);
+if (worker-route)
+strcpy(workerconf-route, worker-route);
+if (worker-redirect)
+strcpy(workerconf-redirect, worker-redirect);
strncpy ?
Ok fixed.
+/* allocate the data */
+*worker = apr_pcalloc(pool, sizeof(proxy_worker));
+if (workerconf-balancer_name)
+*balancer_name = apr_pcalloc(pool, strlen(workerconf-
balancer_name));
+else
+*balancer_name = NULL;
allocated for what ? the string is not copied. Also, shoudn't it be
strlen(..) + 1 ?
Fixed.
+/* make the module usuable from outside */
+health_worker_method *health_checker_get_storage()
+{
+return(worker_storage);
+}
+
+/* handle the slotmem storage */
+void health_checker_init_slotmem_storage(slotmem_storage_method *
storage)
+{
+checkstorage = storage;
+}
+slotmem_storage_method * health_checker_get_slotmem_storage()
+{
+return(checkstorage);
+}
+
+/* handle the slotmen itself */
+void health_checker_init_slotmem(ap_slotmem_t *score)
+{
+ myscore = score;
+}
+ap_slotmem_t *health_checker_get_slotmem()
+{
+return(myscore);
+}
static APR_INLINE ...
No, why?
+char * ap_server_root_relative(apr_pool_t *p, const char *name)
+{
+char *fname;
+
+/* XXX: apr_filepath_merge better ? */
+if (basedir name[0] != '/') {
+fname = apr_pcalloc(p, strlen(basedir)+strlen(name)+1);
+strcpy(fname, basedir);
+strcat(fname, /);
+strcat(fname, name);
apr_pstrcat ?
Yes, done
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard: modules/proxy/ support/
Ruediger Pluem wrote:
On 28.07.2006 18:34, [EMAIL PROTECTED] wrote:
Author: jfclere
Date: Fri Jul 28 09:33:58 2006
New Revision: 426604
URL: http://svn.apache.org/viewvc?rev=426604view=rev
Log:
First try to put togother an external health checker for mod_proxy.
Modified: httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4?rev=426604r1=426603r2=426604view=diff
==
--- httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4
(original)
+++ httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/config.m4 Fri Jul
28 09:33:58 2006
@@ -17,6 +17,7 @@
+}
+/* copy the worker information in the shared area so the health-checker can
extract the part it need */
+static apr_status_t add_entry(proxy_worker *worker, char *balancer_name, int
id)
What is the purpose of the id parameter. I do not see that it is used.
The id of the slot where the worker has to be stored.
+{
+struct proxy_worker_conf *workerconf = NULL;
+apr_status_t rv;
+
+if (myscore == NULL)
+return APR_ENOSHMAVAIL;
+rv = checkstorage-ap_slotmem_mem(myscore, worker-id, (void *)
workerconf);
+if (rv != APR_SUCCESS) {
+return rv;
+}
+
+if (balancer_name)
+strcpy(workerconf-balancer_name, balancer_name);
+workerconf-id = worker-id;
+workerconf-retry = worker-retry;
+workerconf-lbfactor = worker-lbfactor;
Is this approach thread safe / process safe or is there no need to be?
It should be used while parse the configuration or adding an entry...
Well it isn't my idea is to have the thread/process synchro stuff before
calling add_entry.
+if (worker-name)
+strcpy(workerconf-name, worker-name);
+if (worker-scheme)
+strcpy(workerconf-scheme, worker-scheme);
+if (worker-hostname)
+strcpy(workerconf-hostname, worker-hostname);
+if (worker-route)
+strcpy(workerconf-route, worker-route);
+if (worker-redirect)
+strcpy(workerconf-redirect, worker-redirect);
Don't you need to use strncpy here to avoid buffer overflows?
Of course.
+/* read the entry stored in the shared area and build the corresponding worker
structure */
+static apr_status_t get_entry(int id, proxy_worker **worker, char
**balancer_name, apr_pool_t *pool)
+{
+struct proxy_worker_conf *workerconf = NULL;
+apr_status_t rv;
+
+if (myscore == NULL)
+return APR_ENOSHMAVAIL;
+rv = checkstorage-ap_slotmem_mem(myscore, id, (void *) workerconf);
+if (rv != APR_SUCCESS)
+return rv;
+
+/* allocate the data */
+*worker = apr_pcalloc(pool, sizeof(proxy_worker));
+if (workerconf-balancer_name)
+*balancer_name = apr_pcalloc(pool, strlen(workerconf-balancer_name));
+else
+*balancer_name = NULL;
+
+/* The httpstatus is handle by httpd don't touch it here */
+(* worker)-id = workerconf-id;
+// XXX: what to do (* worker)-s = workerconf;
+(* worker)-retry = workerconf-retry;
+(* worker)-lbfactor = workerconf-lbfactor;
+if (workerconf-name)
+strcpy((* worker)-name, workerconf-name);
+if (workerconf-scheme)
+strcpy((* worker)-scheme, workerconf-scheme);
+if (workerconf-hostname)
+strcpy((* worker)-hostname, workerconf-hostname);
+if (workerconf-route)
+strcpy((* worker)-route, workerconf-route);
+if (workerconf-redirect)
+strcpy((* worker)-redirect, workerconf-redirect);
Don't you need to allocate space for this first (like with the balancer name)?
Yes, done.
Added:
httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c?rev=426604view=auto
==
---
httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c
(added)
+++
httpd/httpd/branches/httpd-proxy-scoreboard/modules/proxy/mod_proxy_health_checker.c
Fri Jul 28 09:33:58 2006
+
+static int healthck_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
+ apr_pool_t *ptemp)
+{
+slotmem_storage_method *checkstorage;
+health_worker_method *worker_storage = health_checker_get_storage();
+ap_slotmem_t *myscore;
+
+checkstorage = ap_lookup_provider(SLOTMEM_STORAGE, shared, 0);
+if (checkstorage) {
+health_checker_init_slotmem_storage(checkstorage);
+}
+if (checkstorage worker_storage) {
+checkstorage-ap_slotmem_create(myscore, proxy/checker,
worker_storage-getentrysize(), 128, pconf);
+health_checker_init_slotmem(myscore);
+}
+return OK;
+}
+
+/* XXX: Was to
Re: svn commit: r426604 - in /httpd/httpd/branches/httpd-proxy-scoreboard:
A quick check shows that various worker stats are not shared... doing a reload of the balancer-manager shows the I/O/Elected values flopping all over the place. So they seem in this impl process specific and not shared at all. Did nothing special to build modules/mem just allowed default config and build... I'll try to look more over the weekend or next week, but I want to make sure to get my cluster-set patch in trunk soonish and start proposing some backports to 2.2.x :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
suexec mod_vhost_alias .... again
I'm looking into converting a mass virtualhost cluster from zeus to apache and I can't find a secure way to do this. I'm considering only mod_vhost_alias because I currently have 20,000 domains hosted on a few dozen servers connected to a NFS NAS. A hardcoded configuration is not practical in this configuration. I need to be able to suexec CGI's on a per-customer basis (by virtual domain). In addition to keeping my customers safe from each other, the users also need to write files under their own UID, and I need to be able to account for system resource usage on a per-user basis. I know this has been discussed before, but I can't really find anyone stating this is the reason why the feature doesnt exist. I've heard the argument that a flexible and secure way to map uid/gids using map_vhost_alias has not been proposed. .. ala ... VirtualDocRoot directories in my setup are currently chowned to their respective customer UID's, would not a flag to tell suexec to determine the UID of VirtualDocRoot be a safe mapping method? It sticks to the mod_vhost_alias paradigm of basing the VirtualHost configuration solely on the filesystem. ps. Is the lack of support for this in apache practical (difficult to implement) or lack of a developer resource? Thanks in advance, Matthew Fisch
[PATCH] perl-framework, Skip nntp-like tests on FreeBSD with accept filters
Folks,
On FreeBSD servers with accept filtering enabled, the nntp-like tests
in perl-framework hang because the client expects the server to send
data first, and the server never gets the request because it hangs in
the accept filter until the client sends data (which it doesn't).
As Rüdiger correctly points out, the fix for this is to put
AcceptFilter nttp none in the configuration file for the test server,
but this only works when that directive is actually available: this
means 2.0 is still out of luck.
Unaccustomed as I (still) am with the internals of the perl-
framework, I came up with the following:
Index: t/protocol/nntp-like.t
===
--- t/protocol/nntp-like.t (revision 426397)
+++ t/protocol/nntp-like.t (working copy)
@@ -20,7 +20,11 @@
plan tests = $tests, need('mod_nntp_like',
{ deferred accept() prohibits testing
with 2.1 =
sub { !have_min_apache_version
('2.1.0')
- || $^O ne linux } } );
+ || $^O ne linux } },
+ { Accept() filter breaks this test on
FreeBSD =
+ sub {!(($^O eq freebsd)
+ (`kldstat` =~ m/accf_http/
g))} } );
+
for my $module (@modules) {
print testing $module\n;
This works for me on Darwin (which AFAIK does not have accept()
filters) and my FreeBSD box which has accf_http and accf_data enabled
in /boot/loader.conf. How does the above work for you, gentle reader,
on your system?
Currently, this plan makes the tests skip on Apache 1.3 (which does
not have mod_nntp_like), Linux (where I must assume deferred accept()
is enabled automatically under any 2.1.0 and up) and FreeBSD when
accf_http is loaded according to kldstat.
I'd love to restrict this to Apache 2.0, but I have no idea how to
selectively insert the 'AcceptFilter nntp none' line into
extra.conf... the server is started with -D APACHE2, but that does
not make a distinction between 2.0, 2.1 etc. Perhaps a perl-framework
guru can shed some light on this.
S.
--
[EMAIL PROTECTED]http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
[jira] Assigned: (MODPYTHON-164) Allow req.add_handler()/req.register_*_filter() to take module/function for handler.
[ http://issues.apache.org/jira/browse/MODPYTHON-164?page=all ] Graham Dumpleton reassigned MODPYTHON-164: -- Assignee: Graham Dumpleton Allow req.add_handler()/req.register_*_filter() to take module/function for handler. Key: MODPYTHON-164 URL: http://issues.apache.org/jira/browse/MODPYTHON-164 Project: mod_python Issue Type: New Feature Components: core Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Currently, the: req.add_handler(phase, handler, dir) req.register_input_filter(filter_name, filter, dir) req.register_output_filter(filter_name, filter, dir) functions require the handler/filter to be a string. This string identifies the module that should be imported and which contains the necessary function, plus optionally, an alternate named function to the default for the phase or filter type. For example: req.add_handler(PythonHandler, mymodule::myhandler) It would be simpler if the handler/filter argument could be overloaded and instead supplied an actual module reference or callable object reference. For example: import mymodule def myhandler(req): ... def fixuphandler(req): req.add_handler(PythonHandler, mymodule) req.add_handler(PythonHandler, mymodule.myhandler) req.add_handler(PythonHandler, myhandler) return apache.OK This would be easier than having to construct a string module/function reference when you have direct access to the handler function. In the main the dir argument would be irrelevant. The only circumstance where it would matter is where PythonInterpPerDirective was used as it could be used to control the interpreter the code executed within. If not supplied, it could be argued that the directory where the supplied module/function is defined in should be used as dir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MODPYTHON-164) Allow req.add_handler()/req.register_*_filter() to take module/function for handler.
[ http://issues.apache.org/jira/browse/MODPYTHON-164?page=all ] Work on MODPYTHON-164 started by Graham Dumpleton. Allow req.add_handler()/req.register_*_filter() to take module/function for handler. Key: MODPYTHON-164 URL: http://issues.apache.org/jira/browse/MODPYTHON-164 Project: mod_python Issue Type: New Feature Components: core Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Currently, the: req.add_handler(phase, handler, dir) req.register_input_filter(filter_name, filter, dir) req.register_output_filter(filter_name, filter, dir) functions require the handler/filter to be a string. This string identifies the module that should be imported and which contains the necessary function, plus optionally, an alternate named function to the default for the phase or filter type. For example: req.add_handler(PythonHandler, mymodule::myhandler) It would be simpler if the handler/filter argument could be overloaded and instead supplied an actual module reference or callable object reference. For example: import mymodule def myhandler(req): ... def fixuphandler(req): req.add_handler(PythonHandler, mymodule) req.add_handler(PythonHandler, mymodule.myhandler) req.add_handler(PythonHandler, myhandler) return apache.OK This would be easier than having to construct a string module/function reference when you have direct access to the handler function. In the main the dir argument would be irrelevant. The only circumstance where it would matter is where PythonInterpPerDirective was used as it could be used to control the interpreter the code executed within. If not supplied, it could be argued that the directory where the supplied module/function is defined in should be used as dir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
