Re: Writing Apache 2 Modules
Thanks a bunch that is unbelievably helpful. FYI: now I got side tracked and have to update the FreeBSD ports of Subversion. :) Thanks again On Sunday 02 March 2003 04:56, Chris Monson wrote: Try looking at the subversion code. It uses APXS and has a fairly intelligent set of macros to do it. It also looks for and uses apr-config and apu-config. It's pretty cool. http://subversion.tigris.org/project_source.html Good luck. I can also send you the appropriate m4 files if you are interested. C Philip M. Gollucci wrote: First of all, I'll take any and all pointers to documentation on this. Second, I am trying to setup autoconf/automake/CVS build environment in my configure.ac dnl Compile time options AC_ARG_WITH( apxs, [AC_HELP_STRING([--with-apxs path to apxs binary])], [ if test -x $withval; then APXS=$withval AC_SUBST($APXS) AC_MSG_RESULT([Using apxs`$APXS`]) else AC_MSG_ERROR([Can't find a usable apxs]) fi ], [AC_MSG_ERROR([Can't find a usable apxs])] ) I have yet to find a module that actually does this. I even scoured mod_php4. mod_perl2 the one I would know best doesn't help since it uses perl Makefile.PL. I've seen lots of --with-apache=DIR, but doesn't help me very much. -- END -- Philip M. Gollucci [EMAIL PROTECTED] 301.474.9294 301.646.3011 (cell) Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu eJournalPress Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.net/Resume
Re: mod_authn_dbi... first release...
On Thu, 27 Feb 2003, Paul Querna wrote: It is heavily based off of mod_authn_mysql. It uses libdbi( http://libdbi.sf.net ) as an abstraction layer. I personaly have only had a chance to use MySQL as a backend, it should work easily with PgSQL if libdbi does its job. You can get it now on: http://open.cyanworlds.com/ Second SELECT %s FROM ... without the conf-rec.isactive_field most propably needs the AND %s!=0 wacked :-) dbi_escape() escape scares me - i.e. it lets unicode and other fun like \n, \r, nl/cr survive. Are we sure that all backend DB's can handle that ? Or does the DBI interface make a very explicit promise that you -only- have to escape \,' and ? If you where as lazy a programmer as I am - you could look at ap_set_string_slot (and friends) with the XtOffset magic trick to replace the 14 odd set_dbi_something() functions by just one or two with the right offset specified in the CommmandRec. Great work ! Dw
Re: ap2 , parent process in worker mpm dies under load
Hi, On Sun, 2 Mar 2003, Jeff Trawick wrote: Andre Breiler wrote: the ap2 (2.0.43) parent process dies (but childs arn't) under load. This is with worker mpm on solaris 8 (multiprocessor). ... All seem to die with a SEGV or SIGBUS due to the fact that after returning from a function call the registers have wrong values. can you post backtraces from the coredumps? Sure: --- snip 1 --- program terminated by signal BUS (Bus Error) 0x7ee2c880: bad address 0x7ee2c880 Current function is ap_wait_or_timeout 222 rv = apr_proc_wait_all_procs(ret, exitcode, status, APR_NOWAIT, p); (/tool/lang9.1/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where [1] 0x7ee2c880(0x080e, 0x0836, 0x083a, 0x1, 0x100133e58, 0x0), at 0x7ee2c87f =[2] ap_wait_or_timeout(status = 0x083a, exitcode = 0x0836, ret = 0x080e, p = 0x100133e58), line 222 in mpm_common.c dbx: warning: invalid frame pointer --- snap core.httpd.323.u0 --- --- snip core.httpd.27942.u0 --- program terminated by signal SEGV (Segmentation Fault) 0x7ee2c880: bad address 0x7ee2c880 Current function is ap_wait_or_timeout 222 rv = apr_proc_wait_all_procs(ret, exitcode, status, APR_NOWAIT, p); (/tool/lang9.1/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where current thread: [EMAIL PROTECTED] [1] 0x7ee2c880(0x979b8, 0x979e0, 0x979e4, 0x1, 0x100133e58, 0x0), at 0x7ee2c87f =[2] ap_wait_or_timeout(status = 0x979e4, exitcode = 0x979e0, ret = 0x979b8, p = 0x100133e58), line 222 in mpm_common.c dbx: warning: invalid frame pointer --- snap core.httpd.27942.u0 --- --- snip core.httpd.26969.u0 --- program terminated by signal SEGV (Segmentation Fault) Current function is server_main_loop 1645 perform_idle_server_maintenance(); (/tool/lang9.1/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where current thread: [EMAIL PROTECTED] =[1] server_main_loop(remaining_children_to_start = 0), line 1645 in worker.c [2] ap_mpm_run(_pconf = 0x100133e58, plog = 0x10015dfa8, s = 0x1001634e8), line 1743 in worker.c [3] main(argc = 3, argv = 0x7cf8), line 643 in main.c --- snap core.httpd.26969.u0 --- --- snip core.httpd.18016.u0 --- program terminated by signal BUS (Bus Error) Current function is server_main_loop 1645 perform_idle_server_maintenance(); (/tool/lang9.1/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where current thread: [EMAIL PROTECTED] =[1] server_main_loop(remaining_children_to_start = 0), line 1645 in worker.c [2] ap_mpm_run(_pconf = 0x100133e58, plog = 0x10015dfa8, s = 0x100167508), line 1743 in worker.c [3] main(argc = 3, argv = 0x7d08), line 643 in main.c --- snap core.httpd.18016.u0 --- The other cores are following the same pattern. Bye Andre' -- Andre' Breiler | Tel: +44 (0) 1628 40 BBC Internet Services | URL: http://support.bbc.co.uk Maiden House, Vanwell Road | Maidenhead, SL6 4UB | Mail me if possible. And use a Subject line.
Re: ap2 , parent process in worker mpm dies under load
Andre Breiler wrote: Hi, On Sun, 2 Mar 2003, Jeff Trawick wrote: Andre Breiler wrote: the ap2 (2.0.43) parent process dies (but childs arn't) under load. This is with worker mpm on solaris 8 (multiprocessor). ... --- snip 1 --- program terminated by signal BUS (Bus Error) 0x7ee2c880: Current function is ap_wait_or_timeout 222 rv = apr_proc_wait_all_procs(ret, exitcode, status, APR_NOWAIT, p); (/tool/lang9.1/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where [1] 0x7ee2c880(0x080e, 0x0836, 0x083a, 0x1, 0x100133e58, 0x0), at 0x7ee2c87f =[2] ap_wait_or_timeout(status = 0x083a, exitcode = 0x0836, ret = 0x080e, p = 0x100133e58), line 222 in mpm_common.c dbx: warning: invalid frame pointer --- snap core.httpd.323.u0 --- Can you reproduce the problem in 32-bit mode? If you run pstack on the core, does it display something similar? Thanks!
Sending error responses to the client
I see two ways for the server to send an error response to the client. First way: - set r-status - call ap_send_error_response() (see protocol.c for an example) Second way: - call ap_bucket_error_create(r-status) - send the error bucket along with an EOS down the output filter stack Which is the preferred way and why? Seems we should be able to pick one way and use it consistently. Bill
Re: Sending error responses to the client
William A. Rowe, Jr. wrote: Filters must use 'the second way'. Early hooks (before ap_run_handler()) must use 'the first way'. Why? I have a filter using the first way and it appears to work. I can dig in the code as well as anyone so don't go to a lot of effort, just trying to save some time by mining the knowledge base on list :-) Thanks, Bill I guess handlers do as they will. Bill At 10:36 AM 3/3/2003, Bill Stoddard wrote: I see two ways for the server to send an error response to the client. First way: - set r-status - call ap_send_error_response() (see protocol.c for an example) Second way: - call ap_bucket_error_create(r-status) - send the error bucket along with an EOS down the output filter stack Which is the preferred way and why? Seems we should be able to pick one way and use it consistently. Bill
Re: [PATCH] call hook from sig_coredump
Justin Erenkrantz wrote: --On Wednesday, February 19, 2003 2:12 PM -0500 Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). Here's a compromise that I'd be willing to accept: you have to explictly enable this hook at configure-time. Otherwise, this hook won't be executed on a signal. Does anybody agree with Justin's compromise (i.e., if I put more effort into this direction am I going to find out that somebody doesn't think the compromise is conservative enough :) )?
Re: [PATCH] call hook from sig_coredump
At 12:30 PM 3/3/2003, Bill Stoddard wrote: Jeff Trawick wrote: Justin Erenkrantz wrote: --On Wednesday, February 19, 2003 2:12 PM -0500 Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). Here's a compromise that I'd be willing to accept: you have to explictly enable this hook at configure-time. Otherwise, this hook won't be executed on a signal. Does anybody agree with Justin's compromise (i.e., if I put more effort into this direction am I going to find out that somebody doesn't think the compromise is conservative enough :) )? I don't like the idea of enabling this hook at configure time. Why not add the hook and leave it to modules whether they want to use it or not? Because it is a potential security hole? The only individual who should choose to expose or prevent the hole would be the administrator who installs (and therefore probably built) Apache. I don't see the value in crufting up configure more that it already is. Can we piggy-back such features into a single --unwise-but-useful configure option? Bill
Run-Time clock in the MPM
Having atime structure in the mpm keeping updated sec and uSEC
field could help performance for the web server.
It could replace most calls to apr_time_now() and apr_time_sec()
at run-time:
NetWare has its main thread resuming every 100 uSEC (1 sec)
to do the idle server maintenance.
The following code keep a local timeval structure, which could
return current time without having to call apr_time_now() every
request.
Yes, only thetv_sec field is updated between call to
gettimeofday().
Who cares about the uSEC precision anyway, apache is a web server,
not a scientific clock application.
With the following function, calls to apr_time_now() in apache could
then be replaced with call to ap_time_now().
Or maybe just redefining apr_time_now() to ap_time_now() and
apr_time_sec() to ap_time_sec() will work for us.
I am thinkingof using a set of functions like the following ones in
the
NetWare mpm:
The synchonize_usec_clock() function is called every second by the main
thread when it resumes to do the idle maintenance.
Itsynchronizes the time fields every 5 seconds using the
gettimeofday() function.
Anyone sees problems with using a background thread to maintain
current timestructure?
--- boc ---
static apr_int32_t mpm_clock_initialized;static apr_time_t
now;struct timeval tv;
static void synchonize_usec_clock( void ){ static apr_int32_t
counter; if (mpm_clock_initialized) {
if(++counter 4) { gettimeofday(tv,
NULL); now = tv.tv_sec * APR_USEC_PER_SEC +
tv.tv_usec; counter = 0;
} else { now +=
SCOREBOARD_MAINTENANCE_INTERVAL;
tv.tv_sec++;
} } else {
gettimeofday(tv, NULL); now = tv.tv_sec *
APR_USEC_PER_SEC + tv.tv_usec; mpm_clock_initialized =
1; }}
AP_DECLARE(apr_time_t) ap_time_now(void){if
(mpm_clock_initialized) return now;
else return apr_time_now();}
AP_DECLARE(apr_time_t) ap_time_sec(apr_time_t time){ if
(mpm_clock_initialized) return tv.tv_sec;
else return apr_time_sec(time);}
--- eoc ---
Thank you,
Jean-Jacques
APR and Apache Time Format Questions
I have two Questions/Suggestions to improve the current performance
of Apache 2.
1:
Apache and Apr are keeping the time stamp in uSEC, it implies multiple
calls to apr_time_sec(), which is just doing a 64 bits division to
transform
uSEC in sec.
I think this is a waste of CPU cycles for nothing.
What about creating a new define called:
#define APR_HAS_USEC.
The else of that optioncould allow apache to run using ONLY sec for
all
apr_time_t field removing all 64 bits division to transform uSEC to
sec.
The size of the apr_time_t variables could also be changed to 32 bits and
calls to gettimeofday() changed to time() in that configuration.
Why is apache using uSEC?
Time variables are mostly used in seconds at run-time, and http
requirements use seconds.
The performance gain is minor but measurable: between 1 and 2.5%on
my box (from 1 to 4 CPUs).
---
Questions:
2-
If one does not fly, it should also be valuable to change the return format
of apr_date_parse_http() to be in seconds instead of uSEC.
This is a snippet of the last part of that function:
--- boc ---
/* ap_mplode_time uses tm_usec and tm_gmtoff fields, but
they haven't * been set yet.
* It should be safe to just zero out these
values. * tm_usec is the number of microseconds into
the second. HTTP only * cares about second
granularity. * tm_gmtoff is the number of seconds
off of GMT the time is. By * definition all
times going through this function are in GMT, so
this * is zero.
*/ ds.tm_usec = 0;--- eoc ---
and then the time is exploded to match the apr_time_t format.
A call to apr_date_parse_httpd() is usually followed by a call to
apr_time_sec(),
which do a 64 bits division to get the time in second.
What about having a new function called apr_date_parse_httpd_sec(), which
skip the end part of apr_time_exp_get() and return seconds?
It implies a small change to apr_time_exp_get() and moving the core code in
apr_time_exp_get() to apr_time_exp_get_sec().:
--- boc ---
APR_DECLARE(apr_status_t) apr_time_exp_get(apr_time_t *t, apr_time_exp_t
*xt){ apr_status_t ret;
ret = apr_time_exp_get_sec(t, xt);
if (ret == APR_SUCCESS)
*t = *t * APR_USEC_PER_SEC +
xt-tm_usec;
return ret;}--- eoc ---
Thank you,
Jean-Jacques
[PATCH] optimization in ap_meets_conditions()
The function ap_meets_conditions() is doing unnecessary calls to apr_time_now() and apr_time_sec(). Sincethe variables (mtime)has itstarget valuein second, it should be possible to use r-request_time instead of calling apr_time_now(). I did not see cases where the delay between a call to read_request_time() and ap_meets_conditions() was greater then 1 second. Also, if r-request_time is not available, it should just call time(NULL) instead of calling apr_time_now() followed by a call to apr_time_sec(). Thank you, Jean-Jacques http_protocol.c.patch Description: Binary data
Re: [PATCH] call hook from sig_coredump
William A. Rowe, Jr. wrote: At 12:30 PM 3/3/2003, Bill Stoddard wrote: Jeff Trawick wrote: Justin Erenkrantz wrote: --On Wednesday, February 19, 2003 2:12 PM -0500 Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). Here's a compromise that I'd be willing to accept: you have to explictly enable this hook at configure-time. Otherwise, this hook won't be executed on a signal. Does anybody agree with Justin's compromise (i.e., if I put more effort into this direction am I going to find out that somebody doesn't think the compromise is conservative enough :) )? I don't like the idea of enabling this hook at configure time. Why not add the hook and leave it to modules whether they want to use it or not? Because it is a potential security hole? The only individual who should choose to expose or prevent the hole would be the administrator who installs (and therefore probably built) Apache. That same admin controls which modules are loaded as well. I don't see the value in crufting up configure more that it already is. Can we piggy-back such features into a single --unwise-but-useful configure option? Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? Bill
.foo files in the same dir must have the same content-type and charset
In general, AddType/AddCharset directives provide general rules for
file extensions. mod_negotiation.c:handle_map_file provides a way to
do negotiation based on rules supplied in file.var rather than the
AddType/AddCharset rules for *.html.
for the purposes of content negotiation.
The problem is that these Content-Type/Language parameters are used for the negotiation
static int handle_map_file(request_rec *r)
{
negotiation_state *neg = parse_accept_headers(r);
var_rec *best;
int res;
char *udir;
// read .htaccess:
//AddType text/html;charset=iso-8859-1 html htm
// override with foo.var:
//URI: foo.html
//Content-Type: application/xhtml+xml; charset=UTF-8; qs=0.99
//Content-Language: en
if ((res = read_type_map(neg, r))) {
return res;
}
// find the characteristics of the best choice:
res = do_negotiation(r, neg, best, 0);
if (res != 0) return res;
if (r-path_info *r-path_info) {
r-uri[ap_find_path_info(r-uri, r-path_info)] = '\0';
}
udir = ap_make_dirstr_parent(r-pool, r-uri);
udir = ap_escape_uri(r-pool, udir);
// throw away everything except the file_name of the best choice:
ap_internal_redirect(ap_pstrcat(r-pool, udir, best-file_name,
r-path_info, NULL), r);
return OK;
}
It seems like making headers from best and stuffing them into r's
headers_out would be a good way to solve this. ap_internal_redirect
copies the new headers from the r (via internal_internal_redirect) and
i THINK that headers won't be replaced if they're already set.
gdb'd apache 1.3.27
looked at 2.something-or-other
--
-eric
office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell: +1.857.222.5741
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
Re: [PATCH] call hook from sig_coredump
--On Monday, March 3, 2003 2:14 PM -0500 Bill Stoddard [EMAIL PROTECTED] wrote: Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? We need to keep our signal handling code to a minimum since we can make no assumptions about the system integrity once we enter such routines. Allowing a hook to always be run by default seems like asking for trouble (because it'd be a global structure that might be susceptible to being maliciously overwritten). We've had strong recommendations from security types in the past to remove sig_coredump entirely. -- justin
[PATCH] ap_http_filter rewrite round 2
This incorporates some (but not all) of Justin's suggestions. This
patch will handle request bodies (both c-l and chunk encoded). Not
tested with pipelined requests but I think it will work.
Recap... ap_http_filter is now responsible for parsing the http protocol
header fields. This patch gets its performance improvement by replacing
multiple calls to ap_get_brigade(AP_MODE_GETLINE) made in
read_request_line and ap_get_mime_headers with a single call to
ap_get_brigade(AP_MODE_READBYTES) made from ap_http_filter (aka
HTTP_IN). Because ap_get_brigade(AP_MODE_READBYTES) can fetch request
body and/or a pipelined request bytes, the filter needs to be able to
setaside bytes received on ap_get_brigade that do not pertain to this
request (this is exactly what the core_input_filter does).
ap_http_filter uses a state driven algorithm to deliniate between
request headers, request bodies and pipelined requests.
Still to do:
- optionally refactor core_input_filter to account for ap_http_filter's
new function
- cleanup the error paths (code uses two different ways to handle
sending error responses to the client, which is goofy)
- handle the con_rec-r fooness a bit more cleanly
- get this patch working for proxy requests
- properly handle trailers (the code is commented out now)
Bill
Index: include/http_protocol.h
===
RCS file: /home/cvs/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.84
diff -u -r1.84 http_protocol.h
--- include/http_protocol.h 3 Feb 2003 17:52:53 - 1.84
+++ include/http_protocol.h 3 Mar 2003 19:58:17 -
@@ -717,6 +717,9 @@
apr_bucket_brigade *);
AP_DECLARE_NONSTD(apr_status_t) ap_old_write_filter(ap_filter_t *f,
apr_bucket_brigade *b);
+apr_status_t ap_http_header_input_filter(ap_filter_t *f, apr_bucket_brigade *b,
+ ap_input_mode_t mode, apr_read_type_e block,
+ apr_off_t readbytes);
/*
* Setting up the protocol fields for subsidiary requests...
* Also, a wrapup function to keep the internal accounting straight.
Index: include/httpd.h
===
RCS file: /home/cvs/httpd-2.0/include/httpd.h,v
retrieving revision 1.194
diff -u -r1.194 httpd.h
--- include/httpd.h 3 Feb 2003 17:52:53 - 1.194
+++ include/httpd.h 3 Mar 2003 19:58:17 -
@@ -1013,6 +1013,7 @@
void *sbh;
/** The bucket allocator to use for all bucket/brigade creations */
struct apr_bucket_alloc_t *bucket_alloc;
+request_rec *r;
};
/* Per-vhost config... */
Index: modules/http/http_core.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_core.c,v
retrieving revision 1.309
diff -u -r1.309 http_core.c
--- modules/http/http_core.c3 Feb 2003 17:53:03 - 1.309
+++ modules/http/http_core.c3 Mar 2003 19:58:17 -
@@ -281,7 +281,6 @@
* Read and process each request found on our connection
* until no requests are left or we decide to close.
*/
-
ap_update_child_status(c-sbh, SERVER_BUSY_READ, NULL);
while ((r = ap_read_request(c)) != NULL) {
@@ -327,9 +326,16 @@
return OK;
}
-
+static int http_core_pre_connection(conn_rec *c, void *csd)
+{
+ap_add_input_filter_handle(ap_http_input_filter_handle,
+ NULL, NULL, c);
+return OK;
+}
static void register_hooks(apr_pool_t *p)
{
+ap_hook_pre_connection(http_core_pre_connection, NULL, NULL,
+ APR_HOOK_LAST);
ap_hook_process_connection(ap_process_http_connection,NULL,NULL,
APR_HOOK_REALLY_LAST);
ap_hook_map_to_storage(ap_send_http_trace,NULL,NULL,APR_HOOK_MIDDLE);
@@ -338,7 +344,7 @@
ap_hook_create_request(http_create_request, NULL, NULL, APR_HOOK_REALLY_LAST);
ap_http_input_filter_handle =
ap_register_input_filter(HTTP_IN, ap_http_filter,
- NULL, AP_FTYPE_PROTOCOL);
+ NULL, AP_FTYPE_CONNECTION);
ap_http_header_filter_handle =
ap_register_output_filter(HTTP_HEADER, ap_http_header_filter,
NULL, AP_FTYPE_PROTOCOL);
Index: modules/http/http_protocol.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.465
diff -u -r1.465 http_protocol.c
--- modules/http/http_protocol.c19 Feb 2003 06:50:10 - 1.465
+++ modules/http/http_protocol.c3 Mar 2003 19:58:18 -
@@ -740,296 +740,706 @@
return NULL;
}
-static long get_chunk_size(char *);
-
-typedef struct http_filter_ctx {
-apr_off_t remaining;
-apr_off_t limit;
-apr_off_t limit_used;
-enum {
-
Re: [PATCH] call hook from sig_coredump
At 01:14 PM 3/3/2003, Bill Stoddard wrote: William A. Rowe, Jr. wrote: At 12:30 PM 3/3/2003, Bill Stoddard wrote: I don't like the idea of enabling this hook at configure time. Why not add the hook and leave it to modules whether they want to use it or not? Because it is a potential security hole? The only individual who should choose to expose or prevent the hole would be the administrator who installs (and therefore probably built) Apache. That same admin controls which modules are loaded as well. And they psychically know that a module is using this hook, or not, as the case may be? I rather like the permit this or not level of control by the Administrator, without relying on module authors. The paranoid Admin is unlikely to trust either the application or loadable modules anyways, so giving them as many overrides as possible to reduce exploitable behavior is goodness. I don't see the value in crufting up configure more that it already is. Can we piggy-back such features into a single --unwise-but-useful configure option? Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? Code running post-segv after a stack overflow is subject to any number of 'side-effects', Mark could provide better pointers to exploit code than I can. IIUC you propose this hook in the child that is segfaulting. If I've misunderstood and this is code in the parent after the child segfaults, ignore my musings. Bill
Re: APR and Apache Time Format Questions
At 01:03 PM 3/3/2003, Jean-Jacques Clar wrote: I have two Questions/Suggestions to improve the current performance of Apache 2. What about creating a new define called: #define APR_HAS_USEC. I responded to the problems with this proposal on the [EMAIL PROTECTED] list... Why is apache using uSEC? Time variables are mostly used in seconds at run-time, and http requirements use seconds. Apache != APR. If you want to offer a proposal of using time_t or timeval_t within Apache in lieu of APR's apr_time_t, please define such a proposal exclusive of what APR is doing. Removing [EMAIL PROTECTED] from this reply... Thanks, Bill
Re: [PATCH] call hook from sig_coredump
At 02:12 PM 3/3/2003, Justin Erenkrantz wrote: --On Monday, March 3, 2003 2:14 PM -0500 Bill Stoddard [EMAIL PROTECTED] wrote: Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? We need to keep our signal handling code to a minimum since we can make no assumptions about the system integrity once we enter such routines. Allowing a hook to always be run by default seems like asking for trouble (because it'd be a global structure that might be susceptible to being maliciously overwritten). We've had strong recommendations from security types in the past to remove sig_coredump entirely. -- justin Maybe that's the answer. One compile flag to eliminate the segv handler altogether, along with the proposed hook, or keep segv handling along with the hook. --segv-handler=enable|disable ??? No need for an in between 'one but not the other', at least I don't believe. Bill
Re: [PATCH] call hook from sig_coredump
William A. Rowe, Jr. wrote: At 02:12 PM 3/3/2003, Justin Erenkrantz wrote: We've had strong recommendations from security types in the past to remove sig_coredump entirely. -- justin Maybe that's the answer. One compile flag to eliminate the segv handler altogether, along with the proposed hook, or keep segv handling along with the hook. --segv-handler=enable|disable ??? so at startup we'd then have to chdir to whatever was specified by CoredumpDirectory...
Re: Security Audit
At 02:47 PM 3/3/2003, William A. Rowe, Jr. wrote: At 02:22 PM 3/3/2003, Juan Rivera wrote: Anybody has done a security audit for Apache? Wouldn't this be a question for [EMAIL PROTECTED] or even [EMAIL PROTECTED] Doh... of course I meant to say [EMAIL PROTECTED] or users@(same).
Re: PR 15282 AcceptEx problem
William A. Rowe, Jr. wrote:
Just to summarize, there are three conditions we need to consider:
1) we hit the TransmitFile recycle bug many times in a row
2) we have encountered an incompatible firewall or VPN
3) the IP address has changed
You seem to have the failcases easily reproduced. Would you tack in
some quick code that simply uses getsockopt(foo) (any option you like)
to see if simply getting socket options for a now-broken listen socket
will fail?
Actually I have not been able to reproduce the AcceptEx error
for 3), however I think the following will address all three
cases and introduces the WindowsSocketsWorkaround directive:
Index: mpm/winnt/child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.13
diff -u -d -b -r1.13 child.c
--- mpm/winnt/child.c 28 Feb 2003 14:02:42 - 1.13
+++ mpm/winnt/child.c 3 Mar 2003 22:31:15 -
@@ -498,7 +498,7 @@
PCOMP_CONTEXT context = NULL;
DWORD BytesRead;
SOCKET nlsd;
-int rv;
+int rv, err_count = 0;
apr_os_sock_get(nlsd, lr-sd);
@@ -538,15 +538,38 @@
rv = apr_get_netos_error();
if ((rv == APR_FROM_OS_ERROR(WSAEINVAL)) ||
(rv == APR_FROM_OS_ERROR(WSAENOTSOCK))) {
-/* Hack alert. Occasionally, TransmitFile will not recycle the
- * accept socket (usually when the client disconnects early).
- * Get a new socket and try the call again.
+/* Hack alert, we can get here because:
+ * 1) Occasionally, TransmitFile will not recycle the accept socket
+ *(usually when the client disconnects early).
+ * 2) There is VPN or Firewall software installed with buggy AcceptEx
implementation
+ * 3) The webserver is using a dynamic address and it has changed
*/
+Sleep(0);
+if (++err_count 1000) {
+apr_int32_t disconnected;
+
+/* abitrary socket call to test if the Listening socket is still
valid */
+apr_status_t listen_rv = apr_socket_opt_get(lr-sd,
APR_SO_DISCONNECTED, disconnected);
+
+if (listen_rv == APR_SUCCESS) {
+ap_log_error(APLOG_MARK,APLOG_ERR, listen_rv, ap_server_conf,
+ AcceptEx error: If this occurs constantly and NO
requests are being served
+ try using the WindowsSocketsWorkaround directive set
to 'on'.);
+err_count = 0;
+}
+else {
+ap_log_error(APLOG_MARK,APLOG_ERR, listen_rv, ap_server_conf,
+ The Listening socket is no longer valid. Dynamic
address changed?);
+break;
+}
+}
+
closesocket(context-accept_socket);
context-accept_socket = INVALID_SOCKET;
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, ap_server_conf,
- winnt_accept: AcceptEx failed due to early client
- disconnect. Reallocate the accept socket and try again.);
+ winnt_accept: AcceptEx failed, either early client disconnect,
+ dynamic address renewal, or incompatible VPN or Firewall
software.);
+
continue;
}
else if ((rv != APR_FROM_OS_ERROR(ERROR_IO_PENDING))
@@ -558,6 +581,7 @@
Sleep(100);
continue;
}
+err_count = 0;
/* Wait for pending i/o.
* Wake up once per second to check for shutdown .
@@ -701,7 +725,7 @@
ap_update_child_status_from_indexes(0, thread_num, SERVER_READY, NULL);
/* Grab a connection off the network */
-if (osver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) {
+if (osver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS ||
windows_sockets_workaround == 1) {
context = win9x_get_connection(context);
}
else {
@@ -769,7 +793,7 @@
static void create_listener_thread()
{
int tid;
-if (osver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) {
+if (osver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS ||
windows_sockets_workaround == 1) {
_beginthreadex(NULL, 0, (LPTHREAD_START_ROUTINE) win9x_accept,
NULL, 0, tid);
} else {
@@ -840,7 +864,7 @@
* Create the worker thread dispatch IOCompletionPort
* on Windows NT/2000
*/
-if (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS) {
+if (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS
windows_sockets_workaround != 1) {
/* Create the worker thread dispatch IOCP */
ThreadDispatchIOCP =
modules/loggers
I working on write mod_log_db
for apache2
It basically is going to do what mod_log_sql does for apache 1.x.x
Except with webinterfaces and multiple database backends.
However, I want the LogFormat parsing that mod_log_config provides.
Is there any documentation on re-using this rather then redoing it like
mod_log_sql did ?
I think that I what I'm looking for is mod_logio ?
static int logio_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t
*ptemp)
{
static APR_OPTIONAL_FN_TYPE(ap_register_log_handler) *log_pfn_register;
log_pfn_register = APR_RETRIEVE_OPTIONAL_FN(ap_register_log_handler);
if (log_pfn_register) {
log_pfn_register(p, I, log_bytes_in, 0);
log_pfn_register(p, O, log_bytes_out, 0);
}
return OK;
}
While I'm thinking about it, this reallly seems like something a lot of
modules could want. Are there any plans on abstracting this out of
mod_log_config to maybe an apr/apr-utll set of functions ? I might be
interested in doing it if there is interest.
Thanks for the continued help.
END
--
Philip M. Gollucci [EMAIL PROTECTED] 301.474.9294 301.646.3011 (cell)
Science, Discovery, the Universe (UMCP)
Webmaster Webship Teacher
URL: http://www.sdu.umd.edu
eJournalPress
Database/PERL Programmer System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.net/Resume
[PATCH] PR 13211 cookies are set twice
As stated earlier, the behaviour is caused by the internal_fast_redirect header overlay. Until we find a better general solution, I want to fix the bug in mod_usertrack now. The patch is rather small ;-). It only refuses to set the cookie in subrequests. It works for me, but I'm not sure, whether there may be situations in which the cookie won't set at all. Any thoughts or objections to apply this patch for now? (My testsuite: standard installation + mod_usertrack + CookieTRacking On (serverwide)); HEAD /manual/ HTTP/1.0. TIA, nd -- Flhacs wird im Usenet grundsätzlich alsfhc geschrieben. Schreibt man lafhsc nicht slfach, so ist das schlichtweg hclafs. Hingegen darf man rihctig ruhig rhitcgi schreiben, weil eine shcalfe Schreibweise bei irhictg nicht als shflac angesehen wird. -- Hajo Pflüger in dnq mod_usertrack.c.patch Description: Attached file: mod_usertrack.c.patch
Re: modules/loggers
My bad, I was looking for log_pfn_register not APR_OPTIONAL_FN_TYPE APR_RETRIEVE_OPTIONAL_FN Thanks again. On Monday 03 March 2003 19:00, Philip M. Gollucci wrote: While I'm thinking about it, this reallly seems like something a lot of modules could want. Are there any plans on abstracting this out of mod_log_config to maybe an apr/apr-utll set of functions ? I might be interested in doing it if there is interest. -- END -- Philip M. Gollucci [EMAIL PROTECTED] 301.474.9294 301.646.3011 (cell) Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu eJournalPress Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.net/Resume
Re: modules/loggers
Philip M. Gollucci wrote: My bad, I was looking for log_pfn_register not APR_OPTIONAL_FN_TYPE APR_RETRIEVE_OPTIONAL_FN Thanks again. On Monday 03 March 2003 19:00, Philip M. Gollucci wrote: While I'm thinking about it, this reallly seems like something a lot of modules could want. Are there any plans on abstracting this out of mod_log_config to maybe an apr/apr-utll set of functions ? I might be interested in doing it if there is interest. hi Philip. your nearly right. log_pfn_register is for registering a new option for printing out the log line. (which I think is what mod_logio uses to add I/O bytes to the line). I think you may be better off using the ap_log_writer/ap_log_writer_init hooks. These hooks allow you to change the logger from writing to a file to something your hook provides. The only downside (in the 2.0 release) is that there is no way to specificy that some log files are to be written to disk, and some to your DB-logger. I have addressed this in the 2.1 release in a (hopefully) not kludgy way. for an example on how to use it, check out how buffered logging is set up in mod_log_config. --Ian
Re: Security Audit
William A. Rowe, Jr. wrote: At 02:47 PM 3/3/2003, William A. Rowe, Jr. wrote: At 02:22 PM 3/3/2003, Juan Rivera wrote: Anybody has done a security audit for Apache? Wouldn't this be a question for [EMAIL PROTECTED] or even [EMAIL PROTECTED] Doh... of course I meant to say [EMAIL PROTECTED] or users@(same). Hi Juan. I believe that several security companies have done their own audits, and have found (and publicised) the vunerabilities they have found. (check the release notes of the some of the previous announcements or search bugtraq for more details) I don't know of any of the apache developers themselves doing a formal audit themselves. if you have a security question, or belive you have found something, please feel free to mail [EMAIL PROTECTED] with the details.
grep problem
Hi All, Solaris 5.9 Generic_112233-04, httpd 2.0.44 --- make produces errors like the following: /bin/bash /opt/local/src/httpd-2.0.44/srclib/apr/libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthreads -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAP_DEBUG -DAP_HAVE_DESIGNATED_INITIALIZER -I/opt/local/src/httpd-2.0.44/srclib/apr/include -I/usr/local/src/httpd-2.0.44/srclib/apr/include -I/opt/local/src/httpd-2.0.44/srclib/apr-util/include -I/usr/local/src/httpd-2.0.44/srclib/apr-util/include -I/opt/local/src/httpd-2.0.44/srclib/apr-util/xml/expat/lib -I. -I/usr/local/src/httpd-2.0.44/os/unix -I/usr/local/src/httpd-2.0.44/server/mpm/prefork -I/usr/local/src/httpd-2.0.44/modules/http -I/usr/local/src/httpd-2.0.44/modules/filters -I/usr/local/src/httpd-2.0.44/modules/proxy -I/usr/local/src/httpd-2.0.44/include -I/usr/local/src/httpd-2.0.44/modules/dav/main -export-dynamic -L/opt/local/src/httpd-2.0.44/srclib/apr-util/xml/expat/lib -o mod_rewrite.la -rpath /usr/local/apache_2.0.44/modules -module -avoid-version mod_rewrite.lo grep: illegal option -- e Usage: grep -hblcnsviw pattern file . . . grep: illegal option -- e Usage: grep -hblcnsviw pattern file . . . grep: illegal option -- e grep: illegal option -- L grep: illegal option -- / grep: illegal option -- o grep: illegal option -- p grep: illegal option -- t grep: illegal option -- / grep: illegal option -- o grep: illegal option -- a grep: illegal option -- / grep: illegal option -- r grep: illegal option -- / grep: illegal option -- t grep: illegal option -- t grep: illegal option -- p grep: illegal option -- d grep: illegal option -- - grep: illegal option -- 2 grep: illegal option -- . grep: illegal option -- 0 grep: illegal option -- . grep: illegal option -- 4 grep: illegal option -- 4 grep: illegal option -- / grep: illegal option -- r grep: illegal option -- / grep: illegal option -- a grep: illegal option -- p grep: illegal option -- r grep: illegal option -- - grep: illegal option -- u grep: illegal option -- t grep: illegal option -- / grep: illegal option -- x grep: illegal option -- m grep: illegal option -- / grep: illegal option -- e grep: illegal option -- x grep: illegal option -- p grep: illegal option -- a grep: illegal option -- t grep: illegal option -- / Usage: grep -hblcnsviw pattern file . . . gmake[4]: Leaving directory `/opt/local/src/httpd-2.0.44/modules/mappers' Sincerely, Jie
