Re: flood: responsescript patch, take 2
Jacek: Now that you've added this in, what exactly does it do? How does it hook into Flood to provide feedback from response data (or does it)? Do you have any example scripts that exhibit these properties? -Norman Tuttle [EMAIL PROTECTED] (OpenDemand Systems) PS: We have interest because we are also thinking of expanding the response template paradigm and do not want to duplicate work done already. On Mon, 25 Aug 2003, Jacek Prucia wrote: This is responsescript patch, but this time written around APR poll API. I'm not sure if I have got everything right, so APR gurus are welcome to take a look. I have tested this against a bunch of web pages, and didn't see any problem though. regards, Jacek Prucia
Re: flood: responsescript patch, take 2
On Mon, 25 Aug 2003 15:43:59 -0400 (EDT) Norman Tuttle [EMAIL PROTECTED] wrote: Jacek: Now that you've added this in, what exactly does it do? I didn't added this in yet -- this is just a proposal. If it's get accepted I'll comit this along with the docs update. Anyway, if url element has responsescript attribute, then flood tries to start whatever this attribute points to. If it's value happens to be valid system executable (say some perl script), then flood sets one way pipe -- it writes response buffer to script standard input. How does it hook into Flood to provide feedback from response data (or does it)? This is just one way ticket. The only way script can comunicate with flood is through exit system call. Exit code of 0 means response is OK, go on with testing, while any other value means response is bad... let's stop, so we can investigate this in detail. Do you have any example scripts that exhibit these properties? I have some, but I won't post them. We are sharing this mailing list with some perl gurus, and they'd probably kill me for how I write perl scripts ;)) Seriously, you just read standard input (STDIN in perl) any way you like, and check response for interesting stuff (header values, HTML body and the like). I'll update the docs with simple example in perl and/or python soon. regards, Jacek Prucia
Re: 2.1 Listen Broken [Was Re: Darwin and IPv6]
On Sun, Aug 24, 2003 at 03:45:40PM -0700, Justin Erenkrantz wrote: I just committed a variant of your patch. I had to add some things to get it to compile on Darwin. Please let me know how that works for you. I know it compiles on Linux, but the Linux box I have partial access to doesn't have IPv6 configured. Works and running for me :) Thanks! -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.stdlib.net/
Re: cvs commit: httpd-2.0/server listen.c
On Sun, Aug 24, 2003 at 10:43:36PM -, [EMAIL PROTECTED] wrote:
...
+#if APR_HAVE_IPV6
+int v6only_setting;
+/* If we are trying to bind to 0.0.0.0 and the previous listener
+ * was :: on the same port and in turn that socket does not have
+ * the IPV6_V6ONLY flag set; we must skip the current attempt to
+ * listen (which would generate an error). IPv4 will be handled
+ * on the established IPv6 socket.
+ */
+if (previous != NULL
+lr-bind_addr-family == APR_INET
+*((in_addr_t *)lr-bind_addr-ipaddr_ptr) == INADDR_ANY
+lr-bind_addr-port == previous-bind_addr-port
+previous-bind_addr-family == APR_INET6
+IN6_IS_ADDR_UNSPECIFIED(
+(struct in6_addr*)(previous-bind_addr-ipaddr_ptr))
This doesn't compile on some older Unixes since in_addr_t is a recent
invention; the casts aren't really necessary anyway.
Also the below conditional looks dubious - previous-bind_addr should be
lr-bind_addr, and the lr-next family is never checked? Attached a
patch which looks logically right and fixes the compile error, not
tested though - can you test it?
else {
+#if APR_HAVE_IPV6
+/* If we tried to bind to ::, and the next listener is
+ * on 0.0.0.0 with the same port, don't give a fatal
+ * error. The user will still get a warning from make_sock
+ * though.
+ */
+if (lr-next != NULL lr-bind_addr-family == APR_INET6
+IN6_IS_ADDR_UNSPECIFIED(
+(struct in6_addr*)(previous-bind_addr-ipaddr_ptr))
+lr-bind_addr-port == lr-next-bind_addr-port
+*((in_addr_t *)lr-next-bind_addr-ipaddr_ptr)
+== INADDR_ANY) {
Index: listen.c
===
RCS file: /home/cvs/httpd-2.0/server/listen.c,v
retrieving revision 1.90
diff -u -r1.90 listen.c
--- listen.c24 Aug 2003 22:43:36 - 1.90
+++ listen.c25 Aug 2003 08:14:39 -
@@ -355,11 +355,11 @@
*/
if (previous != NULL
lr-bind_addr-family == APR_INET
-*((in_addr_t *)lr-bind_addr-ipaddr_ptr) == INADDR_ANY
+lr-bind_addr-sa.sin.sin_addr.s_addr == INADDR_ANY
lr-bind_addr-port == previous-bind_addr-port
previous-bind_addr-family == APR_INET6
IN6_IS_ADDR_UNSPECIFIED(
-(struct in6_addr*)(previous-bind_addr-ipaddr_ptr))
+previous-bind_addr-sa.sin6.sin6_addr.s6_addr)
apr_socket_opt_get(previous-sd, APR_IPV6_V6ONLY,
v6only_setting) == APR_SUCCESS
v6only_setting == 0) {
@@ -382,10 +382,10 @@
*/
if (lr-next != NULL lr-bind_addr-family == APR_INET6
IN6_IS_ADDR_UNSPECIFIED(
-(struct in6_addr*)(previous-bind_addr-ipaddr_ptr))
+lr-bind_addr-sa.sin6.sin6_addr.s6_addr)
lr-bind_addr-port == lr-next-bind_addr-port
-*((in_addr_t *)lr-next-bind_addr-ipaddr_ptr)
-== INADDR_ANY) {
+lr-next-bind_addr-family == APR_INET
+lr-next-bind_addr-sa.sin.sin_addr.s_addr == INADDR_ANY) {
/* Remove the current listener from the list */
if (previous) {
Re: cvs commit: httpd-2.0/server listen.c
On Mon, Aug 25, 2003 at 09:27:03AM +0100, Joe Orton wrote:
Also the below conditional looks dubious - previous-bind_addr should be
lr-bind_addr, and the lr-next family is never checked?
*cough*, yes
-*((in_addr_t *)lr-bind_addr-ipaddr_ptr) == INADDR_ANY
+lr-bind_addr-sa.sin.sin_addr.s_addr == INADDR_ANY
lr-bind_addr-port == previous-bind_addr-port
previous-bind_addr-family == APR_INET6
IN6_IS_ADDR_UNSPECIFIED(
-(struct in6_addr*)(previous-bind_addr-ipaddr_ptr))
+previous-bind_addr-sa.sin6.sin6_addr.s6_addr)
That's what I had first, Justin added this to get it compiling on
Darwin, so unless I'm picking things up wrong I'd suggest leaving
it.
The rest looks better alright, attachted patch works and running for me.
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
--- /home/colmmacc/httpd-2.0/server/listen.cMon Aug 25 12:14:12 2003
+++ httpd-2.0/server/listen.c Mon Aug 25 12:22:09 2003
@@ -355,7 +355,7 @@
*/
if (previous != NULL
lr-bind_addr-family == APR_INET
-*((in_addr_t *)lr-bind_addr-ipaddr_ptr) == INADDR_ANY
+lr-bind_addr-sa.sin.sin_addr.s_addr == INADDR_ANY
lr-bind_addr-port == previous-bind_addr-port
previous-bind_addr-family == APR_INET6
IN6_IS_ADDR_UNSPECIFIED(
@@ -382,10 +382,10 @@
*/
if (lr-next != NULL lr-bind_addr-family == APR_INET6
IN6_IS_ADDR_UNSPECIFIED(
-(struct in6_addr*)(previous-bind_addr-ipaddr_ptr))
+(struct in6_addr*)(lr-bind_addr-ipaddr_ptr))
lr-bind_addr-port == lr-next-bind_addr-port
-*((in_addr_t *)lr-next-bind_addr-ipaddr_ptr)
-== INADDR_ANY) {
+lr-next-bind_addr-family == APR_INET
+lr-next-bind_addr-sa.sin.sin_addr.s_addr == INADDR_ANY) {
/* Remove the current listener from the list */
if (previous) {
[AIX 4.3.3] perl 5.6.1 + mod_perl 1.27 + apache 1.27 + libapreq 1.2 + HTML::Mason1.22 OK
Hi everybody, since the issue deals with mod_perl1, libapreq1 and Mason, I've chosen to cross-post. After spending hours trying to build various libapreq versions with no sucess, googling for a solution, I found out that the problems seems to be that the symbols cannot be found in the .exp, the .exp file being the httpd.exp I got the clue from http://www.mail-archive.com/[EMAIL PROTECTED]/msg34607.html so I try to build with perl Makefile.PL \ APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 \ USE_APACI=1 \ EVERYTHING=1 \ APACI_ARGS='--enable-module=so' make make test make install ant it worked fine for me. From there I succesfully installed HTML::Mason version 1.22. Should future versions of mod_perl 1 include a note for perl 5.6.1 AIX users to build with APACI_ARGS=' --enable-module=so' if they want to build Apache::Request ? Or maybe it should be a question/warning when running Makefile.PL ? However, If it's the only solution for perl 5.6.1, it should be documented at least in the installation Documentation for mod_perl1, libapreq1 and HTML::Mason. If you think it's a good idea, I'm ready to contribute patches. Regards José -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Custom SSL verification causes Apache to start using 100% CPU
William A. Rowe, Jr. wrote:
This looks like a bug fixed in the apache 2.1 tree (the current CVS Head
of the httpd-2.0 repository.)
I checked the CVS repository and found the fix you are referring to. Apparently
this was already backported to the 2.0 branch (2.0 diff attached). We patched
the Apache 2.0, but the problem is not fixed. Is this the only patch that is
needed?
The problem also only occurs when use our custom hook. The Apache process
does not hang when using standard CA auth.
We had not reset the BIO information to a blocking read in every possible
path through the filtering code (e.g. a read-back from the client during a
write operation was required to be a blocking read, but the last client read
state may have been blocking. We neglected to reset it.)
This is now fixed in the current code, and checking out the httpd-2.0
repository and building apache's current development tree will help us
to confirm the fix. Thank you for the note.
--
ir. Kris Verbeeck
Software Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.100.2.4
retrieving revision 1.100.2.5
diff -u -r1.100.2.4 -r1.100.2.5
--- httpd-2.0/modules/ssl/ssl_engine_io.c 2003/04/05 19:04:43 1.100.2.4
+++ httpd-2.0/modules/ssl/ssl_engine_io.c 2003/07/28 02:02:24 1.100.2.5
@@ -1275,6 +1275,8 @@
{
apr_status_t status = APR_SUCCESS;
ssl_filter_ctx_t *filter_ctx = f-ctx;
+bio_filter_in_ctx_t *inctx = (bio_filter_in_ctx_t *)
+ (filter_ctx-pbioRead-ptr);
if (f-c-aborted) {
apr_brigade_cleanup(bb);
@@ -1286,6 +1288,13 @@
return ap_pass_brigade(f-next, bb);
}
+/* When we are the writer, we must initialize the inctx
+ * mode so that we block for any required ssl input, because
+ * output filtering is always nonblocking.
+ */
+inctx-mode = AP_MODE_READBYTES;
+inctx-block = APR_BLOCK_READ;
+
if ((status = ssl_io_filter_connect(filter_ctx)) != APR_SUCCESS) {
return ssl_io_filter_error(f, bb, status);
}
@@ -1359,15 +1368,16 @@
filter_ctx-pbioRead = BIO_new(bio_filter_in_method);
filter_ctx-pbioRead-ptr = (void *)inctx;
-inctx-filter_ctx = filter_ctx;
inctx-ssl = ssl;
inctx-bio_out = filter_ctx-pbioWrite;
inctx-f = filter_ctx-pInputFilter;
-inctx-bb = apr_brigade_create(c-pool, c-bucket_alloc);
-
+inctx-rc = APR_SUCCESS;
+inctx-mode = AP_MODE_READBYTES;
inctx-cbuf.length = 0;
-
+inctx-bb = apr_brigade_create(c-pool, c-bucket_alloc);
+inctx-block = APR_BLOCK_READ;
inctx-pool = c-pool;
+inctx-filter_ctx = filter_ctx;
}
void ssl_io_filter_init(conn_rec *c, SSL *ssl)
Re: cvs commit: httpd-2.0/server listen.c
--On Monday, August 25, 2003 9:27 AM +0100 Joe Orton [EMAIL PROTECTED] wrote: This doesn't compile on some older Unixes since in_addr_t is a recent invention; the casts aren't really necessary anyway. They are required on Darwin since IN6_IS_ADDR_UNSPECIFIED is a macro that requires the types to be correct. The macros appear identically in FreeBSD's netinet6/in6.h, so I think this is a KAME/BSD thing. #define IN6_IS_ADDR_UNSPECIFIED(a) \ ((*(const u_int32_t *)(const void *)((a)-s6_addr[0]) == 0) \ (*(const u_int32_t *)(const void *)((a)-s6_addr[4]) == 0) \ (*(const u_int32_t *)(const void *)((a)-s6_addr[8]) == 0) \ (*(const u_int32_t *)(const void *)((a)-s6_addr[12]) == 0)) In order for the compiler to do anything, a has to be of a type that has s6_addr. So, I'm not sure what we can do. Which OSes exactly are broken? Perhaps we need to add some wrapper code in APR for this, but the casts are essential on *BSD. Also the below conditional looks dubious - previous-bind_addr should be lr-bind_addr, and the lr-next family is never checked? Attached a patch which looks logically right and fixes the compile error, not tested though - can you test it? I'll take a look at this. -- justin
Re: Semaphore bug
but is not apache who's living them opened ? Apache is installed on a low load server ( on a mandrake distro), and I'm shutting down cleanly apache each hour, so even after shutdown apache doesn't release anything, i think ... -pablo On Saturday 23 August 2003 17:42, Aaron Bannert wrote: You've simply exhausted your systemwide (or soft user limits) for that resource. Find out what type of lock you're using and increase the limit. -aaron On Friday, August 22, 2003, at 05:04 AM, Pablo Yaggi wrote: Hi, I notice the semaphore bug last night, is anybody working on it ? I saw is the last one on bugs report. The problem is apache left too many semaphores open, so it reuses to start with this kind of message (in my case) [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock is plenty space left on disk and if you check ipcs -s you'll notice a lot of apache's semaphores. cu Pablo
Re: [Mason] Can't locate object method new via package Apache::Request
K Old wrote: On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: On Sun, 24 Aug 2003, K Old wrote: Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 Compilation failed in require at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. BEGIN failed--compilation aborted at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. Compilation failed in require at (eval 4) line 3. That's a known linking problem. It has been fixed in the cvs, get the cvs instructions from http://httpd.apache.org/apreq/. Joe, may be a new 1.x version should be released? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: cvs commit: httpd-2.0/server listen.c
On Mon, Aug 25, 2003 at 08:28:10AM -0700, Justin Erenkrantz wrote: --On Monday, August 25, 2003 9:27 AM +0100 Joe Orton [EMAIL PROTECTED] wrote: This doesn't compile on some older Unixes since in_addr_t is a recent invention; the casts aren't really necessary anyway. They are required on Darwin since IN6_IS_ADDR_UNSPECIFIED is a macro that requires the types to be correct. The macros appear identically in FreeBSD's netinet6/in6.h, so I think this is a KAME/BSD thing. I committed a patch (different to the one I posted) which passes the right thing to the IN6_blah macro, so it should compile still on Darwin. Ta! joe
Re: [Mason] Can't locate object method new viapackage Apache::Request
On Mon, 2003-08-25 at 13:13, Stas Bekman wrote: K Old wrote: On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: On Sun, 24 Aug 2003, K Old wrote: Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 Compilation failed in require at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. BEGIN failed--compilation aborted at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. Compilation failed in require at (eval 4) line 3. That's a known linking problem. It has been fixed in the cvs, get the cvs instructions from http://httpd.apache.org/apreq/. Joe, may be a new 1.x version should be released? Stas, I've downloaded the CVS, unpacked, built and tested with a not root user, and still received the same errors as before. Here's the syntax I'm using for build, etc: (CVS version) perl Makefile.PL make make test (Module from CPAN) perl Makefile.PL make make test then ./configure --with-apache-includes=/usr/include/apache make make install perl Makefile.PL make make test Is there anything I'm not doing right? I've tried to disable the FrontPage stuff so that the non root user should be able to start apache without the errors, but either by root or non root user I get the same error messages regarding Cookie.so and so forth. Any ideas? Thanks, Kevin -- K Old [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method new via package Apache::Request
K Old wrote: On Mon, 2003-08-25 at 13:13, Stas Bekman wrote: K Old wrote: On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: On Sun, 24 Aug 2003, K Old wrote: Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 Compilation failed in require at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. BEGIN failed--compilation aborted at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. Compilation failed in require at (eval 4) line 3. That's a known linking problem. It has been fixed in the cvs, get the cvs instructions from http://httpd.apache.org/apreq/. Joe, may be a new 1.x version should be released? Stas, I've downloaded the CVS, unpacked, built and tested with a not root user, and still received the same errors as before. Here's the syntax I'm using for build, etc: (CVS version) perl Makefile.PL make make test (Module from CPAN) perl Makefile.PL make make test then ./configure --with-apache-includes=/usr/include/apache make make install perl Makefile.PL make make test Is there anything I'm not doing right? I've tried to disable the FrontPage stuff so that the non root user should be able to start apache without the errors, but either by root or non root user I get the same error messages regarding Cookie.so and so forth. That probably means that my patches weren't applied. K Old, see http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w=2 Does it solve the problem for you? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
